jCard: The JSON Format for vCard
RFC 7095

In the introduction shows twice this sentence.

   The purpose of this specification is to
   define "jCard", a JSON format for vCard data.  One main advantage to
   using a JSON-based format as defined in [RFC4627] over the classic
   vCard format is easier processing for JavaScript based widgets and
   libraries, especially in the scope of web-based applications.

I would like to see a response to the Gen-ART review from Ben Campbell on July 17th.

Just one please-clue-the-AD question ...

In 3.1.  Pre-processing

   vCard uses a line folding mechanism to limit lines of data to a
   maximum line length (typically 72 characters) to ensure maximum
   likelihood of preserving data integrity as it is transported via
   various means (e.g., email) - see Section 3.2 of [RFC6350].  Prior to
   converting vCard data into jCard all folded lines MUST be unfolded.

   vCard data uses an "escape" character sequence for text values and
   property parameter values.  See Section 3.4 of [RFC6350] as well as
   [RFC6868].  When such text elements are converted into jCard, the
   vCard escaping MUST be removed first.  The only escaping that may be
   applied is any escaping mandated by JSON.

Does the order here matter? Would "unfold and remove escapes" and "remove escapes and unfold" give you the same result?

I peeked at RFC 6350, and I don't THINK the order matters, but wasn't sure after reading Sections 3.2 and 3.4.

Thanks for adding the new security considerations
text. 

The comments below are on the earlier version, I
didn't check 'em to see if you handled 'em (but if
you did, thanks!). Let me know if I should look at
anything.

------------

- 3.4.3-3.4.5: Would it be worth pointing out a
preferred date/time form for applications that want
to use JOSE data integrity services? Not sure that'd
belong here really but I do wonder where it might
belong.

- 3.4.12 - I expected this to map to RFC 6350 section
5.1 but it doesn't. What if a 6350, 5.1 LANGUAGE
property parameter is present? Where's that go?

- section 6 is missing the boilerplate from rfc6982.
Maybe a bit late, but that's a pity. Is this section
supposed to be removed or kept in the RFC?

- please see the secdir review [1] from which it
seems some changes ought arise.

[1] http://www.ietf.org/mail-archive/web/secdir/current/msg04095.html

Abstract is a bit weak.  How about:
OLD:
   This specification defines "jCard", a JSON format for vCard data.
NEW:
   This specification defines "jCard", a JSON representation of the
   vCard data format.   The vCard data format is a text format for
   representing and exchanging information about individuals and
   other entities, for example telephone numbers, email addresses,
   structured names and delivery addresses.

In section 2:
   The underlying format used for jCard is JSON.  Consequently, the
   terms "object" and "array" as well as the four primitive types are to
   be interpreted as described in Section 1 of [RFC4627].

It would be relatively inexpensive to enumerate the names of those types here, and might make the reader's life a little easier, although I'm sure the type names are going to be familiar.

Given the round-tripping requirements mentioned in the introduction, I find the treatment of date and time formats confusing; RFC 6350 forbids the use of the extended format, and this document seems to require it, according to the last paragraph of section 3.1. I dove deeper into the spec to find clarification, but the text on dates and times later in the document didn't help me.

I am certain that this was a conscious decision of the working group, so I don't mean to suggest that this is a mistake, but the text in RFC 6350 talks about various sections of the ISO date specification and is very clear about which section is being referenced and which is being excluded; the text in this document is not specific in this way, so it's difficult to figure out how the specifications differ.

It would help when talking about dates and times if the text in this document could be written to more closely mirror the style of the similar sections in RFC 6350, so as to help make these differences clear. I wish I could offer text, but I don't actually know what the working group intended, which seems like the core of the problem.

From 5.3, I was surprised based on my reading of 5.2 that this:

   ["x-karma-points", {}, "integer", 95]

came out as this:

   X-KARMA-POINTS:95

and not this:

   X-KARMA-POINTS;VALUE=INTEGER:95

The explanatory text says:

   It is
   assumed that the parser has knowledge of the default data type for
   the "x-karma-points" property.

This explains why there's no value parameter in the vCard translation, but I don't know _why_ it is assumed that the parser has this knowledge, particularly given that 5.2 seems to say that the conversion should assume that the parser _doesn't_ have this knowledge. Am I missing something obvious?   If I'm missing something subtle, perhaps more text is called for... :)

It's really too late to make this criticism, since the working group has consensus on the document, but I think Appendix A is a really bad idea—if the text isn't normative, what good is it?   I understand why it wouldn't be normative, but generally speaking non-normative restatements of normative text are a bad idea because they inevitably wind up being treated as normative by some implementors.   This comment is based on real-world experience.   Appendix B seems much more helpful.

Thanks for writing this document—I can already envision using this format in my own code.