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

[Robert Sparks <[e-mail]>]

Inline
On 3/20/14, 3:32 PM, Philipp Kewisch wrote:
> 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
wfm
>
>
>> 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.
Please work with your AD on this one.
It's a little detail, not a big problem, but we do need to be clear 
about what the grammar actually is.
>
>> 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.
Provide that reference at the point it's used in the document please.
>
>> 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