Re: [calsify] Roman Danyliw's No Objection on draft-ietf-calext-jscalendar-30: (with COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Neil!

Thanks for making these changes in -31 and talking me through why my other comments don’t apply.  Please consider all of my feedback resolved.

Regards,
Roman

From: iesg <[e-mail]> On Behalf Of Neil Jenkins
Sent: Tuesday, September 29, 2020 11:36 PM
To: Roman Danyliw <[e-mail]>; iesg <[e-mail]>
Cc: Daniel Migault <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Roman Danyliw's No Objection on draft-ietf-calext-jscalendar-30: (with COMMENT)

Hi Roman,

Many thanks for your review.

** Section 1.
The data model should be compatible with the iCalendar data format
      [RFC5545] [RFC7986] and extensions, but the specification should
      add new attributes where the iCalendar format currently lacks
      expressivity, and drop seldom-used, obsolete, or redundant
      properties.  This means translation with no loss of semantics
      should be easy with most common iCalendar files.

Some of these goals seem to conflict.  If JSCalender drops support for things
in the iCalender format how can it be compatible?  Is it possible to easily
enumerate what JSCalender no longer supports that iCalendar did?

It's easily translatable without fidelity loss with the vast majority of common usage. However, iCalendar allows some things like arbitrary parameters on properties. To maintain the ability to fully translate these you basically end up having to do just a different syntactical representation of iCalendar – that's what jCal is, and it's horrible to use because it's unlike any regular JSON API and makes simple things complicated.

Redundant properties refers to things like the ability to specify either a "duration" or an "end". This in turn leads to confusion over things like how recurrences work (because even if your master event specifies an "end", the recurrences actually inherit the "duration" in iCalendar – this is not explicitly mentioned anywhere in the spec!) We have fixed things like this (in JSCalendar you can only use duration, not end, and it's explict how this is inherited). You can easily change an "end" into a "duration" when translating from iCalendar.

** Section 1.4.4.  What is the “associated property” from which the time zone
should come?

I have clarified this. It now reads:

The time zone to associate with the LocalDateTime comes from the "timeZone" property of the JSCalendar object (see Section 4.7.1).

** Section 1.4.4.   Per “When converting local date-times that fall in the
discontinuity to UTC, the offset before the transition is used”, would
normative language be appropriate here – “… the offset before the transition
MUST be used.”?

Sure, done.

** Section 4.1.2.  Shouldn’t “uid” be of type “Id” (per Section 1.4.7)?

That would be nice in theory, but unfortunately while most major calendar providers do generate UIDs that conform to the Id type, the iCalendar spec itself does not restrict the characters like this (indeed the examples include an @ symbol) and this is definitely an area we need to maintain easy compatibility.

** Section 4.2.5.  timeZone.  Is there a reason this isn't type “Time Zones” instead of “String”?

Good point. I have made TimeZoneId a real data type in the document and updated the relevant type signatures to use this.

** Section 4.2.6.  uri.  Provide a reference for “URI” (RFC3986)

Done.

** Section 4.4.4.  Does “web” method imply that only http and https URIs are acceptable as a value?

Yes; I have now made this explicit.

** Section 7.  s/man-in-the-middle/on-path/
** Section 7.  I recommend further emphasizing the sensitive nature of this data

Updated, thanks.

-- Section 1.4.3.  Editorial.  Colloquial language. s/is OK/is conformant/

-- Section 1.4.4.  Editorial.  s/see duration semantics below/see duration
semantics in Section 1.4.5/

-- Section 4.1.4.  Typo. s/knows/known/

-- Section 4.3.  s/compelete/complete/

-- Section 4.4.5.  Typo. s/themself/themselves/

-- Section 6.  Editorial.  Replace any dates in 2018 to be 2020 in the examples
(to make the examples be closer to the publish date of this draft).

Thanks, I've updated all of these

-- Section 1.4.7.  Editorial.  Per “… a UUID is typically a good choice”, I’m
not sure this is needed given the more detailed text in Section 4.1.2

It's a different context, so I'm going to leave it. This is talking about ids that need only be unique with the self-contained JSCalendar object, so while a UUID is a fine choice it's not required. The uid property described in Section 4.1.2 however needs to be globally unique across all JSCalendar objects, hence the much stronger recommendation.

I have published a revised draft<https://tools.ietf.org/html/draft-ietf-calext-jscalendar-31> incorporating the IESG feedback.

Cheers,
Neil.