Subject: [VCARDDAV] Comments about the vCard in JSON draft

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 19 Nov 2012 00:54:25 +0000

Hi Raghurama and Peter,

I have reviewed the JSON representation for vCard draft.

The draft is in good shape. It is indeed quite similar to the XML representation document (RFC 6351), so I think most work can be done similarly.

I have the following comments:

(1) In section 5, there is a translation of the grouping mechanism. Especially:

	contact.FN=...
	contact.EMAIL=...

becomes

	"contact": {
	  "fn": "...",
	  "email: "..."
	}

This is in-line with the XML way of doing it. However, I am wondering what happens when somebody chooses a grouping name that is similar to a reserved keyword. In vCard, this can be detected through the '.' in the name. However, how to do this in JSON? Notice that the case-insensitiveness makes the chance on this a bit bigger.

For example, if somebody in vCard has specified:

	email.FN=...
	email.EMAIL=...

Then the JSON code would become

	"email": {
	  "fn": "...",
	  "email": "..."
	}

Of course the best would be for designers to avoid this case by not using similar names for groups and properties, but the vCard specification does not forbid this.

(2) The example in figure 5 misses the "VERSION" property.

(3) Concerning extensibility: in-line with the XML representation you split properties that have structured values into a JSON element with various sub-elements. The names for already defined properties can be adopted from the XML representation, but how about future structured properties?

Maybe it would be good to explicitly state that not just unknown JSON elements should be ignored, but their sub-elements too. Conversion between JSON (or XML) and "native vCard" of future structured properties would need specification when those future properties are defined.

I hope this helps.

Best regards,
Bert