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

From: The IESG <[email-masked]>
Date: Tue, 18 May 2021 08:39:08 -0700

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
[email-masked] mailing lists by 2021-06-01. Exceptionally, comments may
be sent to [email-masked] 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.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 19 May 2021 08:17:48 -0400

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?

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 20 May 2021 11:19:46 +1000

> *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" ?

I would read that identically. What do you understand as the semantic difference between "so" and "therefore" here?
* *

> 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?

Yeah, it's a little clumsy. I think we could replace "of the participant" with "to use".

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Wed, 19 May 2021 22:47:14 -0400

On 5/19/21 21:19, Neil Jenkins wrote:
>> *For recurring events and tasks, the UID is associated with the 
>> master object and so is the ^^  same for all occurrences;*
>>
> I would read that identically. What do you understand as the semantic 
> difference between "so" and "therefore" here?

"so" has the sense "as a result"

"therefore" has the sense  of "that is why" or "as a consequence"

So (or therefore) I think I agree with Ken

>> The above doesn't sound right to me.  Perhaps "This is the email 
>> address used to contact the participant..." is better?
>>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 20 May 2021 13:48:47 +1000

> So (or therefore) I think I agree with Ken

OK, I have no objection to changing it.

Neil.