I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . 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 ). 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.