Last Call Review of draft-ietf-jcardcal-jcal-09
review-ietf-jcardcal-jcal-09-genart-lc-sparks-2014-04-04-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.