Subject: [calsify] WGLC draft-ietf-calext-jscalendar

From: Daniel Migault <[email-masked]>
Date: Tue, 6 Nov 2018 08:47:00 -0500

Hi,

Given the support, I believe we can start the WGLC today. This email starts
a 2 weeks Working Group Last Call period. for draft-ietf-calext-jscalendar
[1].  Please state on the mailing list whether you believe the draft is
ready to be shipped to the IESG or raise your concerns if you have any.

In order to write the shepherd, it would be helpful to list the
implementations you are aware of. For now I have 3 implementation from
fastmail (Javascript client, Perl proxy, C backend).

Yours,
Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/

---

From: Daniel Migault <[email-masked]>
Date: Fri, 16 Nov 2018 10:15:57 -0500

Hi,

Please find my comments of the document. I expect other review to be
provided by the end of the WGLC so the document can be moved forward.

Yours,
Daniel

1.2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The underlying format used for this specification is JSON.
   Consequently, the terms "object" and "array" as well as the four
   primitive types (strings, numbers, booleans, and null) are to be
   interpreted as described in Section 1 of [RFC8259].

   Some examples in this document contain "partial" JSON documents used
   for illustrative purposes.  In these examples, three periods "..."
   are used to indicate a portion of the document that has been removed
   for compactness.

<mglt>
The document is using some non-standard notations such as @type and *word*.
It may be good to clarify there meaning in this section.
</mglt>

2.1.  JSEvent

   MIME type: "application/calendar+json;type=jsevent"

<mglt>
I might be wrong, but my interpretation of the MIME type is that
"calendar+json" indicates jstypes share the same IANA space as jCal object.
As jCal re-uses the iCalendar types, these jCal registry is derived from
iCalendar, there is no specific jCal IANA registry.

The types defined in this section are expected to be part of the IANA
registry because of the data exchange, thus I would expecting a new
registry "@type" with the following types: jsevent, jstask, jsgroup

I come with the same/similar questions in the IANA section. Maybe that
woudl be good to provide an indication of where these type stands in teh
jCal, iCalendar registries and reference the IANA section for more
explanation.
</mglt>

3.2.5.  Identifiers

   If not noted otherwise, properties and object keys that define
   identifiers MUST be string values, MUST be at least 1 character in
   length and maximum 256 octets in size, and MUST only contain
   characters from the "URL and Filename safe" Base 64 Alphabet, as
   defined in section 5 of [RFC4648].  This is the ASCII alphanumeric
   characters (A-Za-z0-9), hyphen (-), and underscore (_).

<mglt>
Ther might a reasons to do so, but otherwise mixing character and octets
for length seems strange. Is this intentional ? The reason this looks
confusing to me is that characters might be encoded on multiple bytes.
</mglt>

4.3.1.  recurrenceRule

   Type: "Recurrence"

   Defines a recurrence rule (repeating pattern) for recurring calendar
   objects.

   A *Recurrence* object is a JSON object mapping of a RECUR value type
   in iCalendar, see [RFC5545] and[RFC7529].  A JSEvent recurs by
   applying the recurrence rule (and *recurrenceOverrides*) to the
   *start* date/time.  A JSTask recurs by applying the recurrence rule
   (and *recurrenceOverrides*) to its *start* date/time, if defined.  If
   the task does not define a start date-time, it recurs by its *due*
   date-time.  If it neither defines a start or due date-time, it MUST
   NOT define a *recurrenceRule*.

<mglt>maybe we could also mention it MUST be ignored by the interpreter.
</mglt>

7.8.  Event with multiple locations and localization

   This example illustrates an event that happens at both a physical and
   a virtual location.  Fans can see a live convert on premises or
   online.  The event title and descriptions are localized.  (Note: the
   localization of the event description contains an UTF-8 encoded
   German Umlaut.  This character may have been replaced with ASCII
   characters in the plain-text rendering of this RFC document)

<mglt>
RFCv3 uses UTF-8 and should support non-ascii character [RFC7997]. größte
with umlaud and ess-tset should be able to appear. I would recommend to
make an Note for the Editor at that place.
It seems that the following page enables the generation of RFCv3 format:
https://xml2rfc.tools.ietf.org/experimental.html
</mglt>

7.10.  Recurring event with participants

<mglt>
I suspect a typo here. Shouldn't we have instead:
     "recurrenceOverrides": {
       "2018-03-08T09:00:00": {
         "participants": {
            [email-masked]: {
              participationStatus": "declined"
              }
          }
        }
    }
</mglt>

9.  IANA Considerations

   This document amends the "application/calendar" MIME media type
   defined in [RFC7265].

   New optional parameter: "type" with value being one of "jsevent",
   "jstask", "jsgroup".  The parameter MUST NOT occur more than once.

<mglt>
I think that the IANA section needs to be clarified. I understand that
"jsevent", "jstask", "jsgroup" needs to be registered and are expected to
appear in the following page:
https://www.iana.org/assignments/icalendar/icalendar.xhtml#parameters

However, if I am correct, it is not clear to me if you woudl like to add
these new types to an existing registry or if you would like to create a
new registry. I expect the latest, but the text mentions parameters so I
suspect I could be the "Parameters" registry.
For my information, I would be happy to understand the rational for adding
parameters to iCalendar instead of having a separate registration for the
JSCalendar that I see as defining a new model on the top of iCalendar.

As I can see, Parameters only requires experts review.

In case, parameters needs to be registered, the registration should follow
the templates provided in RFC5545.
https://tools.ietf.org/html/rfc5545#section-8.2.4
The registration procedure is describe din RFC5545 section 8.2.1, so
templates will be sent to [email-masked] and [email-masked] for a review
from the designated experts.
 </mglt>
Yours,
Daniel

On Tue, Nov 6, 2018 at 8:47 AM Daniel Migault <[email-masked]>
wrote:

> Hi,
>
> Given the support, I believe we can start the WGLC today. This email
> starts a 2 weeks Working Group Last Call period. for
> draft-ietf-calext-jscalendar [1].  Please state on the mailing list whether
> you believe the draft is ready to be shipped to the IESG or raise your
> concerns if you have any.
>

---

From: Robert Stepanek <[email-masked]>
Date: Tue, 20 Nov 2018 17:14:03 +0100

Hi Daniel,

thanks a lot for your feedback. I have updated the working copy of the
RFC draft at
https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/jscalendar

> 1.2.  Notational Conventions

I have updated text formatting in the document, using the verb, emph and
strong styles consistently. I have also added a description of the
styles to this section. 
> 3.2.5.  Identifiers
> Ther might a reasons to do so, but otherwise mixing character and
> octets for length seems strange. Is this intentional ? The reason
> this looks confusing to me is that characters might be encoded on
> multiple bytes.
I have updated this section to define identifier length and allowed
values in characters. Because JSCalendar requires I-JSON (RFC7493), all
strings must be UTF-encoded, and due to the restricted identifier
character set this results in a maximum length of 256 octets. This
section now includes an according note.
> 
> 4.3.1.  recurrenceRule
> 
>    Type: "Recurrence"
> [...] If it neither defines a start or due date-time, it MUST
> <mglt>maybe we could also mention it MUST be ignored by the
> interpreter. </mglt>
I'm not sure I understand. Do you mean, it should be ignored if the
object erroneously contains a recurrenceRule?
> RFCv3 uses UTF-8 and should support non-ascii character [RFC7997]
> </mglt>

I have just tested with RFCv3 and it indeed renders the Umlaute
correctly. Thanks for the hint, I have removed the caveat from the
example description.
>               participationStatus": "declined"

No, but the example wasn't correct either. It used an email address, but
the latest specification requires to only use URL-safe base64
characters. I have updated the example.
>    "jstask", "jsgroup".  The parameter MUST NOT occur more than once.> 
> <mglt>
> "jsevent", "jstask", "jsgroup" needs to be registered and are expected
> to appear in the following page:> https://www.iana.org/assignments/icalendar/icalendar.xhtml#parameters
This link refers to iCalendar parameters within the iCalendar object
definition. What we would like to do is to update the media type for
application/json. RFC 6838 defines how to register a media type, I'm not
sure if its section 5 also applies for changes to an existing IANA media
type entry?
Cheers,
Robert

---

From: Daniel Migault <[email-masked]>
Date: Wed, 21 Nov 2018 22:07:46 +0000

Thanks for the responses, please see my comments in line. I believe we need to clarify the IANA section with the IANA.

Yours,
Daniel

From: calsify <[email-masked]> On Behalf Of Robert Stepanek
Sent: Tuesday, November 20, 2018 11:14 AM
To: [email-masked]
Subject: Re: [calsify] WGLC draft-ietf-calext-jscalendar

Hi Daniel,

thanks a lot for your feedback. I have updated the working copy of the RFC draft at https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/jscalendar

I have updated text formatting in the document, using the verb, emph and strong styles consistently. I have also added a description of the styles to this section.

3.2.5.  Identifiers
Ther might a reasons to do so, but otherwise mixing character and octets for length seems strange. Is this intentional ? The reason this looks confusing to me is that characters might be encoded on multiple bytes.

I have updated this section to define identifier length and allowed values in characters. Because JSCalendar requires I-JSON (RFC7493), all strings must be UTF-encoded, and due to the restricted identifier character set this results in a maximum length of 256 octets. This section now includes an according note.

4.3.1.  recurrenceRule

   Type: "Recurrence"

<mglt>maybe we could also mention it MUST be ignored by the interpreter. </mglt>

I'm not sure I understand. Do you mean, it should be ignored if the object erroneously contains a recurrenceRule?
<mglt>
Yes, that is it. What the other party if it sees an erroneous recurrneceRule.
</mglt>

I have just tested with RFCv3 and it indeed renders the Umlaute correctly. Thanks for the hint, I have removed the caveat from the example description.

<mglt>
I suspect a typo here. Shouldn't we have instead:
     "recurrenceOverrides": {
       "2018-03-08T09:00:00": {
         "participants": {
            [email-masked]<mailto:[email-masked]>: {
              participationStatus": "declined"
              }
          }
        }
    }
</mglt>

No, but the example wasn't correct either. It used an email address, but the latest specification requires to only use URL-safe base64 characters. I have updated the example.

9.  IANA Considerations

<mglt>
I think that the IANA section needs to be clarified. I understand that "jsevent", "jstask", "jsgroup" needs to be registered and are expected to appear in the following page:
https://www.iana.org/assignments/icalendar/icalendar.xhtml#parameters

This link refers to iCalendar parameters within the iCalendar object definition. What we would like to do is to update the media type for application/json. RFC 6838 defines how to register a media type, I'm not sure if its section 5 also applies for changes to an existing IANA media type entry?

<mglt>
So I understand you would like to register under application/json [1] and not application/calendar+json [2]. We need to clarify that with the IANA.
[1] https://www.iana.org/assignments/media-types/application/json
[2] https://www.iana.org/assignments/media-types/application/calendar+json
</mglt>

Cheers,
Robert

---

From: Daniel Migault <[email-masked]>
Date: Wed, 21 Nov 2018 17:15:16 -0500

Hi,

We need more review for the draft to be moved forward. If you supported the
draft please review the latest version [1] or the one published on github
[2]

Yours,
Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/
[2] https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/jscalendar

---

From: Robert Stepanek <[email-masked]>
Date: Thu, 22 Nov 2018 14:59:43 +0100

All,

I have just submitted an updated version of the JSCalendar RFC draft.

This version includes the changes following Daniel's review, as well as
Neil's update to RRULEs for non-gregorian rscales. It also defines the
default "rel" property value of Link object to be "enclosure".
We do not have any remaining open issues or changes planned.

I kindly ask for your review and feedback to conclude this last call.

Please also let us know if you currently use a variant of JSCalendar, or
if you plan to or work on an implementation. At FastMail, we use
JSCalendar for our beta users. The open-source Cyrus IMAP project
includes a C implementation to translate from and to iCalendar. I'm
assessing if we can make this a stand-alone library.
Thanks,
Robert

On Wed, Nov 21, 2018, at 11:15 PM, Daniel Migault wrote:
> Hi, 
> 
> We need more review for the draft to be moved forward. If you
> supported the draft please review the latest version [1] or the one
> published on github [2]> 
> Yours, 
> Daniel
> 
> [2] https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/jscalendar> 
> 
> 
> On Tue, Nov 6, 2018 at 8:47 AM Daniel Migault
> <[email-masked]> wrote:>> Hi, 
>> 
>> starts a 2 weeks Working Group Last Call period. for draft-ietf-calext-
>> jscalendar [1].  Please state on the mailing list whether you believe
>> the draft is ready to be shipped to the IESG or raise your concerns
>> if you have any.>> 
>> implementations you are aware of. For now I have 3 implementation
>> from fastmail (Javascript client, Perl proxy, C backend).>> 
>> Yours, 
>> Daniel
>> 
> _________________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Marten Gajda <[email-masked]>
Date: Fri, 23 Nov 2018 00:09:29 +0100

FTR: at SchedJoules we're using an early draft of this spec in our API
and various client implementations of it and we're planning on switching
to the final version once it's ratified.

At dmfs we're also planning on implementing this in our CalDAV-Sync app.
In addition we're currently drafting a new product which is going to use
this format for data exchange and internal storage.

Cheers,

Marten

Am 22.11.18 um 14:59 schrieb Robert Stepanek:
> This version includes the changes following Daniel's review, as well
> as Neil's update to RRULEs for non-gregorian rscales. It also defines
> the default "rel" property value of Link object to be "enclosure".
>
> Please also let us know if you currently use a variant of JSCalendar,
> or if you plan to or work on an implementation. At FastMail, we use
>> published on github [2]
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>>     Given the support, I believe we can start the WGLC today. This
>>     email starts a 2 weeks Working Group Last Call period. for
>>     draft-ietf-calext-jscalendar [1].  Please state on the mailing
>>     list whether you believe the draft is ready to be shipped to the
>>     IESG or raise your concerns if you have any.
>>
>>     from fastmail (Javascript client, Perl proxy, C backend).
>>
>>     Yours,
>>     Daniel
>>
>> [email-masked] <mailto:[email-masked]>
> _______________________________________________
> calsify mailing list
> [email-masked]

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 22 Nov 2018 20:17:37 -0500

Obviously, I'm "just another FastMail person" - my plan is to update Net::CalDAVTalk perl module to the latest version, and split the API conversion logic out into a separate module at the same time, so there's a perl implementation of JSCalendar conversion to/from VEVENT files. 
 
Bron. 
 
On Thu, Nov 22, 2018, at 09:15, Daniel Migault wrote: 
> Hi,  
>  
> We need more review for the draft to be moved forward. If you supported the draft please review the latest version [1] or the one published on github [2] 
>  
> Yours,  
> Daniel 
>  
> On Tue, Nov 6, 2018 at 8:47 AM Daniel Migault <[email-masked]> wrote: 
>> Hi,  
>>  
>> Given the support, I believe we can start the WGLC today. This email starts a 2 weeks Working Group Last Call period. for draft-ietf-calext-jscalendar [1]. Please state on the mailing list whether you believe the draft is ready to be shipped to the IESG or raise your concerns if you have any.  
>>  
>> In order to write the shepherd, it would be helpful to list the implementations you are aware of. For now I have 3 implementation from fastmail (Javascript client, Perl proxy, C backend).  
>>  
>> Yours,  
>> Daniel 
>>  
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [email-masked]

---

From: Keith Harris <[email-masked]>
Date: Tue, 27 Nov 2018 10:40:01 +0000

Hi,

Here at YouCanBook.me we've been following the project with close interest
and while we have no production impementation of the proposals, many
changes we have made to our API have been tightly informed by the ideas and
structures described in the draft.  Seeing the standard accpeted would be
of great value to us and our users.

We strongly support the draft's progress.

Keith Harris
https://youcanbook.me

On Wed, 21 Nov 2018 at 22:15, Daniel Migault <[email-masked]>
wrote:

> Hi,
>
> We need more review for the draft to be moved forward. If you supported
> the draft please review the latest version [1] or the one published on
> github [2]
>
> Yours,
> Daniel
>