Last Call Review of draft-ietf-jcardcal-jcal-09
review-ietf-jcardcal-jcal-09-genart-lc-sparks-2014-03-11-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-jcardcal-jcal-09
Reviewer: Robert Sparks
Review Date: 11Mar2014
IETF LC End Date: 12Mar2014
IESG Telechat date: 27Mar2014

Summary: Ready with nits

This is a solid document, and its development has left good artifacts
showing a pattern of careful review.
(such as <http://trac.tools.ietf.org/wg/jcardcal/trac/report/6>).

Here are some nits to consider:

I agree with moving the reference to RFC4627 to normative, as already
discussed.

Please consider adding a reference to clarify "JSON escaping" where it
is mentioned in the 2nd paragraph of page 5.
Perhaps section 2.5 of rfc4627 would be a good reference?

The MUST in the third paragraph of 3.4.1.1 stuck out - is looks like a
restatement of RFC5545 - that spec doesn't _allow_ anything but a
semicolon for this particular separator. Would this be better written
without 2119?
Perhaps: "When converting from jCal to iCalendar, be careful to use a
semi-colon as the separator between the two values as required by RFC5545."

(This may be more than a nit): In the ABNF in section 3.6.5, where is
the implementer supposed to go to find the definition of 'zone'? (Or the
other production names?) I think _this_ chunk of ABNF (as opposed to
that compiled in the appendix) is intended to be normative, yes? FWIW,
it's not reflected in Appendix B.

I haven't extracted the BNF in appendix B and verified it, but it must
fail - there is at least one typo. The expansion of param-multi includes
"value-separtor" which should have been "value-separator".
Where is value-separator defined?

Just curious - has anyone tried converting a document from
iCal->xCal->jCal->iCal? That might turn up some interesting corners that
simple round-tripping might mask.

To try to save other reviewers some time, here are a couple of things I
flagged that turned out to be non-issues:
* I was concerned with whether there would be issues with the forced
conversion between upper and lower case. A little digging shows there is
no issue - all the names this is done to are limited to the
ascii-compatible characters.
* I verified that the syntax numbers with fractional parts is the same
in both iCal in jCal. Specifically "4." is not valid in either grammar,
so there is no need to discuss something like adding a 0 or remove the
decimal point during conversion.