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

[Roman Danyliw via Datatracker <[e-mail]>]

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