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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 22 Sep 2020 11:57:37 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-calext-jscalendar-30: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for responding to the SECDIR review (and thank you to Phillip
Hallam-Baker for doing it).

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

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

** 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.”?

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

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

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

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

** Section 7.  s/man-in-the-middle/on-path/

** Section 7.  I recommend further emphasizing the sensitive nature of this data

OLD
Calendaring and scheduling information is very privacy-sensitive.
   Its transmission must be done carefully to protect it from possible …

NEW
Calendaring and scheduling information is very privacy-sensitive.  It can
reveal the social network of a user; location information of this user and
those in their social network; identity and credentials information; and the
patterns of behavior of the user in both the physical and cyber realm. 
Additionally, calendar events and tasks can could influence the physical
location of a user or their cyber behavior within a known time window.  It’s
transmission and storage must be done carefully to protect it from possible …

** Editorial Nits

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

-- 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).

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 30 Sep 2020 13:35:58 +1000

Hi Roman,

Many thanks for your review.

> 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

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).*

> normative language be appropriate here – “… the offset before the transition

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.  I recommend further emphasizing the sensitive nature of this data

Updated, thanks.

> (to make the examples be closer to the publish date of this draft).

Thanks, I've updated all of these

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

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 30 Sep 2020 12:52:12 +0000

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

Hi Roman,

** Section 1.

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

Sure, done.

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.

Done.

Updated, thanks.

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

Cheers,
Neil.