[VCARDDAV] Comments about the vCard in JSON draft

Bert Greevenbosch <Bert.Greevenbosch@huawei.com> Mon, 19 November 2012 00:54 UTC

Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 67C0621F85C9 for <vcarddav@ietfa.amsl.com>; Sun, 18 Nov 2012 16:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id B40YYTTHz1Mb for <vcarddav@ietfa.amsl.com>; Sun, 18 Nov 2012 16:54:32 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7AB4221F85C1 for <vcarddav@ietf.org>; Sun, 18 Nov 2012 16:54:32 -0800 (PST)
Received: from (EHLO lhreml204-edg.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMX47645; Mon, 19 Nov 2012 00:54:31 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com ( by lhreml204-edg.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 00:54:08 +0000
Received: from SZXEML455-HUB.china.huawei.com ( by lhreml403-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 00:54:30 +0000
Received: from SZXEML509-MBX.china.huawei.com ([]) by SZXEML455-HUB.china.huawei.com ([]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 08:54:26 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: "ragbhat@cisco.com" <ragbhat@cisco.com>, "psaintan@cisco.com" <psaintan@cisco.com>
Thread-Topic: Comments about the vCard in JSON draft
Thread-Index: Ac3F8GtxxL9ayeTPRI6lNwHNnipSjA==
Date: Mon, 19 Nov 2012 00:54:25 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB629123E50@szxeml509-mbx>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "vcarddav@ietf.org" <vcarddav@ietf.org>
Subject: [VCARDDAV] Comments about the vCard in JSON draft
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2012 00:54:33 -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": "...",
	  "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:


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,