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

I have just uploaded a new version of the document, it contains all
considerations from the Gen-ART and secdir review, as well as changes
based on the IESG evaluations.

http://www.ietf.org/internet-drafts/draft-ietf-jcardcal-jcal-10.txt

There are still 1-2 issues where I am waiting on email replies, but I
wanted to have a version ready for the IESG Telechat tomorrow.

To jcarcal folks: I'd apprecicate if you could take a look at
http://trac.tools.ietf.org/wg/jcardcal/trac/ and comment on the
outstanding issues.

Philipp

On 3/26/14, 9:43 AM, Philipp Kewisch wrote:
> 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 <rjsparks@nostrum.com> 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
>>> Gen-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/gen-art
>> _______________________________________________
>> jcardcal mailing list
>> jcardcal@ietf.org
>> https://www.ietf.org/mailman/listinfo/jcardcal