JSCalendar: A JSON Representation of Calendar Data
draft-ietf-calext-jscalendar-32

[[ questions ]]

[ section 1.4.5 ]

* Since non-zero fractional seconds is not the same as not having
  any trailing zeros, should the "to ensure there is only a single
  representation" guidance from UTCDateTime also apply here?

  In other words, is "PT1.300S" acceptable?

[ section 1.4.7 ]

* Should there be a reference to RFC 4122 here?

[ section 3(.0) ]

* Should the I-JSON reference be 7493?

[ section 6.3 ]

* Is this entries array really valid JSON?  I didn't think the map key
  could appear in the array like this (vis. the jstask entry).

[ section 6.9 ]

* Should the "excluded" value be true rather than "true"?


[[ nits ]]

[ section 4.2.6 ]

* It seems unlikely that a virtual event would have a "door access code".
  Perhaps "conference access code" or "meeting access code" or something?

I'm late on my reviews this week, and my colleagues have been mighty thorough, so I'll be blissfully brief.

To assuage some of the IESG's concerns about iCalendar and jCal, could we maybe include one of those Implementation Status sections?

Nice job on the IANA section here.

[For the IESG] How common is it to have a working group be the point of contact for a new registry?  What do we normally do if such a working group were to close?  I scanned RFC 8126 (rather quickly, I admit) and didn't see any guidance in there about this.

In Section 4.1.4, there's "SHOULD ensure that this is a globally unique identifier".  Why might an implementation choose not to do so (which SHOULD allows)?

All of the SHOULDs in 4.5.2 have me asking the same sort of thing: When would one not do this?   One way out here is to just drop the SHOULDs and say something like:

CURRENT:

The Relation object SHOULD set the "parent" relation type.

NEW:

The Relation object sets the "parent" relation type.

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

Thank you for resolving my COMMENTs.

Thank you for writing this document -- as someone who has written (horrible!) code to try and generate and parse iCalendar data, this seem like a very useful effort.
Like Eric I'm concerned about the https://xkcd.com/927/  effect, but I also feel that this standard might be more usable than the existing one(s). I suspect that it is much too early to think about Obsoleting jCal (although I must admit I've never run into jCal, so I have no idea if it is actually being used).

I think that it would be useful to have some more discussions around why / when PatchObjects should be used - they seem to add significant complexity to the design, and I'm really not convinced that the complexity outweighs the benefit; I'm guessing that I'm simply not fully understanding their utility. More examples would probably help...

Thanks again!
W

Thank you for the work put into this document. 

To be honest, after reading the abstract, https://xkcd.com/927/ sprang to my mind (even after being relieved by the explanations of section 1.1)... Let's hope that more tools/applications will use this new standard.

Please find below a couple of non-blocking COMMENTs and blocking DISCUSS points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.3  --
Is the wording 'type signature' well accepted in the JSON world ? I would have expected something like 'type description' 'type grammar'.

-- Section 1.48 --
As I find the 'patchObject' an interesting concept, I wonder whether it should not also be specified in another document ? (if not yet done of course, then I wonder why it is defined in this document)

-- Section 4.3 --
Just to write that this section about recurrence was well thought ;-)

-- Section 4.2.2 --
"This MUST be one of the following values, a value registered in the IANA JSCalendar Enum Registry, or a vendor-specific value:" I find it slightly confusing as the listed value (free/busy) are also part of the IANA table 5 later in the document. Suggest to use "This MUST be one of the value registered in the IANA JSCalendar Enum Registry (like the two listed below) or a vendor-specific value:"

Same applies also to section 4.4.3 and other places (such as 'roles').

Section 1.4.8

   Where "TimeZoneId" is given as a data type, it means a "String" that
   is either a time zone name in the IANA Time Zone Database [TZDB] or a
   custom time zone identifier in the "timeZones" property (see
   Section 4.7.2).

(nit?) I'd suggest 'custom time zone identifier defined in the
"timeZones" property'.

Section 4.7.1

   floating time.  This is either a name from the IANA Time Zone
   Database [TZDB] or the id of a custom time zone from the "timeZones"
   property (Section 4.7.2).  If omitted, this MUST be presumed to be

I think we probably want to say "the TimeZoneID of a custom time zone"
here since there seems to only be a colloquial tie between "id" and that
type.

Section 4.7.2

      Maps the TZNAME properties from iCalendar to a JSON set.  The set
      is represented as an object, with the keys being the names
      (excluding any "tznparam" component from iCalendar).  The value
      for each key in the map MUST be true.

I suggest moving the parenthetical to being offset by a comma -- it's a
normative requirement, not an aside.

Section 6.8

It looks like the change in location Id for the virtualLocation entry
was unintentional, since the localizations property contains a patch
object that still references the old Id.  (This would qualify as a
Discuss-level internal inconsistency but I am confident that the right
thing will happen.)

Section 7

   behavior within a known time window.  It's transmission and storage

nit: s/It's/Its/

Hi,

Thank you for this document.  I appreciate the effort to fix iCalendar and jCal, but also support Ben's questions regarding how this document relates to the iCalendar and jCal documents.  It seems that at least obsoleting jCal might be a good idea.

Ben's detailed review also seemed to throw up quite a lot of comments/clarifications, hence I have a slight concern about how robust the jsCalendar specification is.  The shepherd write up also doesn't seem to note what level of review has been received on this document.  The document states that it aims to fix the bugs in iCalendar because they cannot be fixed without breaking existing implementations.  I trust that the authors and WG are confident that history is not about to repeat itself ...

Regards,
Rob