Hi Robert, Thank you for your valuable comments. > I agree with moving the reference to RFC4627 to normative, as already > discussed. Done.
> > 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? Sounds good. Here is my suggestion: OLD When converting from iCalendar to jCal, first iCalendar lines MUST be unfolded. Afterwards, any iCalendar escaping MUST be unescaped. Finally JSON escaping (e.g., for control characters) MUST be applied. The reverse order applies when converting from jCal to iCalendar. First, JSON escaping MUST be unescaped. Afterwards, iCalendar escaping MUST be applied. Finally, long lines SHOULD be folded as described in [RFC5545]. NEW When converting from iCalendar to jCal, first iCalendar lines MUST be unfolded. Afterwards, any iCalendar escaping MUST be unescaped. Finally JSON escaping, as described in [RFC7195] Section 7, MUST be applied. The reverse order applies when converting from jCal to iCalendar. First, JSON escaping MUST be unescaped. Afterwards, iCalendar escaping MUST be applied. Finally, long lines SHOULD be folded as described in [RFC5545]. END > > 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." Thanks for the suggestion, I've changed it locally. > > (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. Indeed, there are some shortcomings here. For the year/month/day/hour/minute/second production names I can add an explicit reference to ISO.8601.2004 Section 2.2. The zone designator is only marginally mentioned in ISO.8601.2004 Section 4.3.2. The exact date format is not reflected in Appendix B because the Appendix does not intend to capture the structure of each different property type. As the two jcardcal drafts are my first rfc documents, I am not quite sure when its a good idea to make the ABNF normative. I could probably declare it informative by virtue of the reference to ISO 8601 and RFC5545. The ABNF was added in draft 08, in alignment with the changes we've made in jcard (rfc7095). There was a lot of discussion on the jcardcal list on the date formats and it became clear that the specific variations of ISO 8601 2001 and 2004 used in iCalendar and vCard make it hard to grasp. By explicitly mentioning the date format I wanted to counteract. I'd appreciate some feedback on how to further handle this issue. > > 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? I've fixed two typos and run it through <http://www.apps.ietf.org/content/chris-newmans-abnf-validator>. Validation was successful. value-separator is defined in section 2 of rfc 7159. > > 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. I haven't tried that, it might be interesting though. My library cannot convert xCal to jCal (yet), but maybe Cyrus' library does it and he can take a look. Regards, Philipp _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
