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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
