[Jcardcal] Genart LC review: draft-ietf-jcardcal-jcal-09

[Robert Sparks <[e-mail]>]

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.