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