Many thanks for your review, Ben! These reviews are very helpful for me to form an opinion about the draft in the IESG telechat. Authors, do you have thoughts on the issues that Ben raises here?
Jari On Jul 17, 2013, at 12:27 AM, Ben Campbell <[email protected]> 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 wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-jcardcal-jcard-04 > Reviewer: Ben Campbell > Review Date: 2013-07-16 > IETF LC End Date: 2013-07-18 > IESG Telechat date: 2013-07-18 > > Note: This draft is on the IESG Telechat agenda on the same date as it > completes IETF Last Call. Therefore, this review serves both purposes. > > Summary: This draft is almost ready for publication as a proposed standard. > There are a few minor issues and editorial nits that should be considered > prior to publication. > > Major issues: > > -- None > > Minor issues: > > -- Section 1, design considerations: > > You mention that the semantic results should survive round-tripping, but the > order of fields might not. I gather there are other changes that might occur > from the literal text, right? (e.g. Case changes, some optional parameter > usage). If so, it might be worth clarifying that. > > -- 3.1, 2nd paragraph: > > I assume the removal of escaping means that one renders the escaped text, not > simply removes it, right? Is that as simple as removing the escape characters > in vCards? I assume this doesn't apply to any content-specific escaping > inside vCard fields, e.g. URI escaping, right? If so, it might be worth > mentioning. > > -- 3.2.1.1: > > What happens for future versions of vCard? Do you simply use the new version > number, or would we need a new version of this spec? I suspect the latter. If > true, it might be worth mentioning that, or somewhere early in the draft > mention that this spec is for vCard 4.0 only. > > -- sections 3.4.3 and 3.4.4: > > Is the included ABNF a quotation of that in the referenced RFCs, or is it new > and authoritative? If the former, it would be helpful to mention that in the > text. (I note you did say that about the ABNF in the appendix). > > -- 3.4.11: > > If RFC6350 says that use of the timezone offset is NOT RECOMMENDED, can you > elaborate on why it's included here? (I can guess it's because people may > still use it in vCards since it was a "MUST NOT", but it would be good to say > something to that effect in the text.) > > Nits/editorial comments: > > -- Section 1, paragraph 1: > > Please expand JSON on first mention. > > -- Section 1, paragraph 3: > > This paragraph seems redundant to paragraph 1. > > -- 1, paragraph 7: " Preserve the semantics of the vCard data." > > Imperative form sentence is confusing in context, and inconsistent with > surrounding text. > > -- 1, paragraph 8: > > Sentence Fragment. > > -- 3.2, Last Paragraph: "... for a parser check the data type..." > > Missing "to"? > > -- 3.2.1.2, last paragraph before example: > > Should the "iCalendar" reference be "vCard" instead? > > -- 3.2.1.3, Last Paragraph: > > RFCTODO? I gather in the IANA section, that may be a placeholder for "this > RFC", but that doesn't seem to fit here. > > -- 3.3.2: "Example 1:" > > Other examples are not numbered. > > -- 5: > > More occurrences of RFCTODO > > > > > > > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
