Skip to main content

jCard: The JSON Format for vCard
RFC 7095


No Objection

(Adrian Farrel)
(Brian Haberman)
(Gonzalo Camarillo)
(Joel Jaeggli)
(Martin Stiemerling)
(Stewart Bryant)

Note: This ballot was opened for revision 04 and is now closed.

Barry Leiba Former IESG member
(was Discuss) Yes
Yes (2013-10-15) Unknown
UPDATE for -06: I find this version much easier to follow -- the organizational issues have been fixed, as I see it, and thanks very much for dealing with this -- I know it was a lot of work.

UPDATE for -07: And this version resolves all if my comments, including the minor issues that came out of the previous edit round.  I think it's ready to go.
Pete Resnick Former IESG member
Yes (2013-07-16 for -05) Unknown
Please confirm that these are all correct: Change "In jCal these properties" to "In jCard these properties"

10.1: None of the following are normative. Please move them to 10.2:

RFC 5545
RFC 6321
RFC 6351

10.2: RFC 4627 is normative. Please move it to section 10.1.
Richard Barnes Former IESG member
Yes (2013-07-18 for -05) Unknown
C1. In Section 3.1: It would be helpful to give a brief example of "escaping mandated by JSON"
OLD: "escaping mandated by JSON."
NEW: "escaping mandated by JSON (e.g., for control characters)."
C2. In Section 3.2.1: This sentence doesn't make sense to me: "The value could turn out to be a structured value, in which case the data type is an array."  It seems like the value could also be a number, boolean, null, or object; not just array.
Adrian Farrel Former IESG member
No Objection
No Objection (for -05) Unknown

Benoît Claise Former IESG member
No Objection
No Objection (2013-07-16 for -05) Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection (for -05) Unknown

Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -05) Unknown

Jari Arkko Former IESG member
No Objection
No Objection (2013-07-16 for -05) Unknown
I would like to see a response to the Gen-ART review from Ben Campbell on July 17th.
Joel Jaeggli Former IESG member
No Objection
No Objection (for -05) Unknown

Martin Stiemerling Former IESG member
No Objection
No Objection (for -05) Unknown

Spencer Dawkins Former IESG member
No Objection
No Objection (2013-07-15 for -05) Unknown
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.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-09-27 for -06) Unknown
Thanks for adding the new security considerations

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


- 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

- 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.

Stewart Bryant Former IESG member
No Objection
No Objection (for -05) Unknown

Ted Lemon Former IESG member
No Objection
No Objection (2013-07-17 for -05) Unknown
Abstract is a bit weak.  How about:
   This specification defines "jCard", a JSON format for vCard data.
   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:


and not this:


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.