Re: [calsify] SECOND Last Call: <draft-ietf-calext-jscalendar-32.txt> (JSCalendar: A JSON representation of calendar data) to Proposed Standard

[Ken Murchison <[e-mail]>]

Overall, the changes look fine to me.

A couple of nits however.

Section 4.1.2:

*For recurring events and tasks, the UID is associated with the master 
object and so is the ^^  same for all occurrences; *

Should this be "therefore" instead of "so" ?

**

Section 4.4.6, "email":

This is the email address*of the participant to contact the participant...*

**

The above doesn't sound right to me. Perhaps "This is the email address 
used to contact the participant..." is better?


On 5/18/21 11:39 AM, The IESG wrote:
> The IESG has received a request from the Calendaring Extensions WG (calext)
> to consider the following document: - 'JSCalendar: A JSON representation of
> calendar data'
>    <draft-ietf-calext-jscalendar-32.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2021-06-01. Exceptionally, comments may
> be sent to [e-mail] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> This second last call is specifically on the following diff:
>
> https://www.rfc-editor.org/authors/rfc8984-ad2-diff.html
>
> And on the following technical additions to the document:
>
> * "features" in section 4.2.6
> * "recurrenceIdTimeZone" in section 4.3.2
> * "sentBy" in section 4.4.5. and 4.4.6
> * "requestStatus" in 4.4.7
> * as a consequence, updates to the IANA registries in 8.2.6 and 8.4.3.
>
> The document was with the RFC Editor since November 2020. However, last minute implementation attempts found some edge cases of incompatibility between jscalendar and icalendar data models, which resulted in wg discussion and the changes above. The additions were discussed extensively at IETF 110 and confirmed during a following interim.
>
> Abstract
>
>
>     This specification defines a data model and JSON representation of
>     calendar data that can be used for storage and data exchange in a
>     calendaring and scheduling environment.  It aims to be an alternative
>     and, over time, successor to the widely deployed iCalendar data
>     format, and to be unambiguous, extendable, and simple to process.  In
>     contrast to the jCal format, which is also JSON-based, JSCalendar is
>     not a direct mapping from iCalendar, but defines the data model
>     independently and expands semantics where appropriate.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>