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

[Philipp Kewisch <[e-mail]>]

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