Re: [VCARDDAV] JSON representation

Joe Hildebrand <jhildebr@cisco.com> Mon, 11 June 2012 18:35 UTC

Return-Path: <jhildebr@cisco.com>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC92E21F849A for <vcarddav@ietfa.amsl.com>; Mon, 11 Jun 2012 11:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.532
X-Spam-Level:
X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqO+DgbNDiR1 for <vcarddav@ietfa.amsl.com>; Mon, 11 Jun 2012 11:35:53 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 713FB21F848A for <vcarddav@ietf.org>; Mon, 11 Jun 2012 11:35:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=1251; q=dns/txt; s=iport; t=1339439753; x=1340649353; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=t72oClv83N40bLkmN2WxLJo20jMV59KBKakTNDWkxkk=; b=fRKY4IEyo1cJ29ZIiZr2aq2to0T/4ONA8vbRegRLto0Dldu0+gmB7njL bXnc5B3iQxytaKVkCPcRga4WOnP4JwSY01l0dHfGe5UAjhcFtmDp5kAxj +xhl49aBkdcjGaLeEKostllaR0cniF1LTkEzKSrBkF7ewmtiVES4m6Nk4 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMGAFI51k+tJXHB/2dsb2JhbABFihOrAwKBB4IYAQEBAwESAScCATwFDQEIGIEFAQEEDgUih2QFmGifYZENA4hAjF6OFYFmgn8
X-IronPort-AV: E=Sophos;i="4.75,751,1330905600"; d="scan'208";a="91449353"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jun 2012 18:35:53 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5BIZqVu022361; Mon, 11 Jun 2012 18:35:52 GMT
Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jun 2012 13:35:52 -0500
Received: from 64.101.74.200 ([64.101.74.200]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Jun 2012 18:35:52 +0000
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 11 Jun 2012 12:35:51 -0600
From: Joe Hildebrand <jhildebr@cisco.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Message-ID: <CBFB96A7.2C8CD%jhildebr@cisco.com>
Thread-Topic: [VCARDDAV] JSON representation
Thread-Index: Ac1IAQbOyvPZLfOFpkimrLMHhaDztA==
In-Reply-To: <4FD639EC.9080502@viagenie.ca>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2012 18:35:52.0769 (UTC) FILETIME=[07DCCB10:01CD4801]
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] JSON representation
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, 11 Jun 2012 18:35:54 -0000

I don't care about the order of properties.  The streaming use cases of
CardDAV don't really apply, except, perhaps, for a collection of vCards.


On 6/11/12 12:33 PM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:

> On 2012-06-11 14:18, Joe Hildebrand wrote:
>> I'm ok with relying on order in the places where vCard relies on order.  I
>> detest it as a protocol design decision, but it makes the interop much
>> easier, such that we don't have to come up with field names where none
>> exist.
> 
> The bigger issue IMHO is: should we insist that JSON preserve the order
> of properties? If we don't care about ordering, we may use a dictionary
> as the root data structure, as proposed in the draft. Otherwise,
> something more complex would be needed.
> 
> RFC6350 doesn't say anything about order, except that VERSION must come
> first. Any well-behaved vCard consumer needs to be able to handle any
> ordering. So if round-tripping between vCard and JSON wouldn't preserve
> order, we would still have the same vCard as far as RFC6350 is concerned.
> 
> As a aside, an RFC6350bis should say that ordering of properties and
> parameters is not to be relied on for any purpose.
> 
> Simon

-- 
Joe Hildebrand