I will upload a new draft today that incorporates changes from various reviews.
Philipp On 3/26/14, 7:28 AM, Jari Arkko wrote: > Thanks for the review, Robert. Some changes are being discussed, but I do not > see a new draft. Shouldn't that appear before we make the final approval of > this document? > > Jari > > On Mar 12, 2014, at 2:55 AM, Robert Sparks <[email protected]> wrote: > >> 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. >> >> >> >> >> >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ > jcardcal mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jcardcal _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
