jCal: The JSON Format for iCalendar
draft-ietf-jcardcal-jcal-10

[Ballot comment]
Some changes are being discussed due to Robert Spark's gen-art review, but I do not see a new draft. Shouldn't that appear before we make the final approval of this document?

[Ballot comment]

section 1: this is odd: "Extensions to the underlying
iCalendar specification must not lead to requiring an update
to jCal." How are you going to prevent that happening?  I
think the best you can do is point out how such an extension
could break jcal and recommend to not do that.

[Ballot comment]
I'm good with this assuming the gen-art points and Barry's issues get resolved. One nit in section 3.5.2:

"To ease processing in jCal, the value to such parameters
  MUST be represented in an array containing the separated values."
 
I think this is supposed to say "of such parameters".

[Ballot discuss]
I very much like this document, and will switch to "Yes" after we resolve a couple of easy points.

RFC 4627 is clearly a normative reference, not an informative one.  Apart from that, the replacement to 4627 is in the RFC Editor queue, and will become an RFC before this document does.  I strongly suggest replacing the 4627 reference with one to the I-D, so the new RFC gets dropped in by the RFC Editor.  (If you do that, the eval() advice in Section 6 needs to change accordingly.)

-- Section 4 --

  Character escaping and line folding MUST be applied to the resulting
  iCalendar data as required by [RFC5545] and [RFC6868].

The line folding part is in conflict with Section 3.1:

  The reverse order applies when converting from jCal to iCalendar.
  First, JSON escaping MUST be unescaped.  Afterwards, iCalendar
  escaping MUST be applied.  Finally, long lines SHOULD be folded as
  described in [RFC5545].

Which is meant, SHOULD (Section 3.1) or MUST (Section 4) ?

[Ballot comment]
Non-blocking comments to consider:

-- Appendix B --
I'm quite unhappy with using raw ABNF to describe JSON payloads.  You're duplicating the ABNF in the JSON spec, and it's prone to errors, not to mention being hard to read.  What you want to do here is to specify JSON structures, not to specify the JSON syntax itself.

Look at RFC 7071 Section 6.2 for one way that this has been handled.  http://tools.ietf.org/html/draft-newton-json-content-rules-01 specifies another way.  Please consider changing to one of those.

I know that Cyrus has responded that he's reluctant to change this now, but please consider it: I think this section is essentially useless as it stands.  On the other hand, note that this is a non-blocking comment, so I will not hold anything up if you decide to leave it be.

-- Section 3 --
Pedantic nit pet peeve:

  In [RFC5545], iCalendar objects are comprised of a set of
  "components", "properties", "parameters" and "values".

In correct usage, the whole "comprises" the parts.  So:

NEW
  In [RFC5545], an iCalendar object comprises a set of
  "components", "properties", "parameters" and "values".
END

(If you don't like that, use "is composed of" instead of "is comprosed of".)

[Ballot comment]
Sounds like the document editor has the GenArt and SecDir reviews in hand and is working through the issues. No showstoppers in there as far as I see, but we will make sure to address those before publication.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-jcardcal-jcal-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are two
actions which IANA must complete.

ACTION 1:
This document requests adding a media type to the applications media type registry located at:

http://www.iana.org/assignments/media-types/application/index.html

The media type to be added are:

calendar+json


ACTION: 2:
in the Value Data Types  Values subregistry of the iCalendar Element
Registries located at:

http://www.iana.org/assignments/icalendar

the following three registrations will be added:

Value Data Type: UNKNOWN
Status: Reserved - Do not use
Reference: [ RFC-to-be, section 5 ]

IANA understands these two actions to be the only one required upon
approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (jCal: The JSON format for iCalendar) to Proposed Standard


The IESG has received a request from the JSON data formats for vCard and
iCalendar WG (jcardcal) to consider the following document:
- 'jCal: The JSON format for iCalendar'
  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
ietf@ietf.org mailing lists by 2014-03-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines "jCal", a JSON format for iCalendar data.
  The iCalendar data format is a text format for capturing and
  exchanging information normally stored within a calendaring and
  scheduling application, for example tasks and events.  JSON is a
  lightweight, text-based, language-independent data interchange format
  commonly used in internet applications.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcal/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcal/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd's write-up for draft-ietf-jcardcal-jcal-08

1. Summary

The shepherd for this document is Peter Saint-Andre. The responsible
Area Director is Pete Resnick.

This document defines an alternative representation for iCalendar
data (RFC 5545), structured using the JSON data interchange format
(RFC 4627). Defining this "jCal" representation for iCalendar allows
easier integration of such data with web or other Javascript-based
applications, and other JSON-based protocols being developed within
the IETF.

Because jCal is amenable to multiple technical implementations and
interoperability testing, the document is Standards Track.

2. Review and Consensus

The document emerged from discussion within the XML-JSON technical
committee of the Calendaring and Scheduling Consortium, where it
experienced early review from at least three participants in that
forum.  Upon adoption by the JCARDCAL WG, another half a dozen
individuals reviewed and commented on the specification.

Although it might appear that the document has not received "wide"
review, the population of implementers interested in the topic is
relatively small (only ~50 people are subscribed to the JCARDCAL WG
discussion list). In addition, the jCal specification was preceded into
WG Last Call, IETF Last Call, and IESG review by "jCard", a sister
specification defining the JSON representation of vCard data.  As a
result, many issues surrounding jCal were first ironed out through work
on jCard (e.g., handling of unknown structured values), thus leading to
fewer open issues related to jCal specifically.

The calendaring and scheduling community is very interested in this
specification, there are several implementations, and there is good
consensus to advance the specification to Proposed Standard.

3. Intellectual Property

All three of the authors have confirmed that they do not have direct,
personal knowledge of any IPR related to this document.

There are no IPR disclosures related to this document.

4. Other Points

According to the IDnits tool, there are no downward references.

This document adds one entry to the iCalendar Data Types registry
(parallel to the "UNKNOWN" entry already added to the vCard Value Data
Types registry) and also registers a new media type "calendar+json".
Review of the media type registration was requested on the media-types
list on January 6, 2014:

http://www.ietf.org/mail-archive/web/media-types/current/msg00563.html

There was no special controversy about this specification within the
JCARDCAL WG, and in the shepherd's opinion both jCard and jCal are
rather straightforward alternative representations of existing data
models.  The two main points of focus in this work have been ensuring
that the JSON representations use JSON in appropriate ways and are
consistent with the existing textual and XML representations.  Much
attention has been paid to these issues within the JCARDCAL WG, and the
shepherd is satisfied that these considerations have been addressed in
draft-ietf-jcardcal-jcal-08.

END