Last Call Review of draft-ietf-jcardcal-jcard-04
review-ietf-jcardcal-jcard-04-genart-lc-campbell-2013-07-17-00

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