Re: [VCARDDAV] JSON representation
Peter Saint-Andre <stpeter@stpeter.im> Thu, 07 June 2012 19:19 UTC
Return-Path: <stpeter@stpeter.im>
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 2FCB721F8594 for <vcarddav@ietfa.amsl.com>; Thu, 7 Jun 2012 12:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level:
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, USER_IN_WHITELIST=-100]
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 0Ua-0o4jHKa1 for <vcarddav@ietfa.amsl.com>; Thu, 7 Jun 2012 12:19:53 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2C21F852C for <vcarddav@ietf.org>; Thu, 7 Jun 2012 12:19:53 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 863274010C; Thu, 7 Jun 2012 13:36:46 -0600 (MDT)
Message-ID: <4FD0FED7.7010109@stpeter.im>
Date: Thu, 07 Jun 2012 13:19:51 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <4FCFFECA.8010507@stpeter.im> <4FD0C14D.1010406@viagenie.ca> <4FD0D27F.5070706@stpeter.im> <4FD0DB04.6040604@viagenie.ca>
In-Reply-To: <4FD0DB04.6040604@viagenie.ca>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: Thu, 07 Jun 2012 19:19:54 -0000
On 6/7/12 10:47 AM, Simon Perreault wrote: > On 2012-06-07 12:10, Peter Saint-Andre wrote: >>>> "gender": { "sex" : "M" }, >>> >>> This is super ugly. I know that's how it is in xCard, but xCard is what >>> it is and is super ugly in various other ways. It would be nice if we >>> could have simply: >>> >>> "gender": "M" >> >> I like the simplicity, but I wonder if we're losing information. Would >> you suggest that we do the same thing for all properties? For example: >> >> "bday": "--0203" >> >> "anniversary": "20090808T1430-0500" > > bday and anniversary are different from gender. They are single > date-and-or-time values by default. Whereas gender is a compound property. > > The gender examples from vCard could be expressed like this: > > GENDER:M > GENDER:F > GENDER:M;Fellow > GENDER:F;grrrl > GENDER:O;intersex > GENDER:;it's complicated > > "gender": "M" > "gender": "F" > "gender": ["M", "Fellow"] > "gender": ["F", "grrrl"] > "gender": ["O", "intersex"] > "gender": ["", "it's complicated"] > > or even possibly: > "gender": "it's complicated" > > You can see I'm not arguing for regularity... > >>>> "org": { >>>> "type": "work", >>>> "text": "Viagenie" >>>> }, >>> >>> Shouldn't this be >>> >>> "org": { >>> "type": "work", >>> "text": ["Viagenie"] >>> }, >>> >>> ? >>> >>> I hope not. What you have is fine. But it needs justification. >> >> Why would use an array (an ordered collection of values) when there is >> only one value? We were aiming for simplicity. > > I guess regularity would dictate using an array even for a single value > because there is the possibility of multiple values... Yes, it would. >>> Maybe add an IANA consideration to the effect that in the future >>> parameter names and value type names must not clash? >> >> Wouldn't that belong in rfc6350bis? > > Yes, but if jCard depends on it then maybe it would be quicker to just > add it to jCard. Well, if we're asking IANA to change its registration procedures for vCard parameter names and value type names, then that belongs in 6350bis. If we're making a note regarding criteria that expert reviewers and the IESG might want to take into account, then it seems acceptable to do that in the jCard spec (perhaps flagging it as something that needs to be addressed more officially in 6350bis). Peter -- Peter Saint-Andre https://stpeter.im/
- Re: [VCARDDAV] JSON representation Simon Perreault
- [VCARDDAV] JSON representation Peter Saint-Andre
- Re: [VCARDDAV] JSON representation Joe Marcus Clarke
- Re: [VCARDDAV] JSON representation Raghurama Bhat (ragbhat)
- Re: [VCARDDAV] JSON representation Cyrus Daboo
- Re: [VCARDDAV] JSON representation Joe Marcus Clarke
- Re: [VCARDDAV] JSON representation Julian Reschke
- Re: [VCARDDAV] JSON representation Peter Saint-Andre
- Re: [VCARDDAV] JSON representation Peter Saint-Andre
- Re: [VCARDDAV] JSON representation Peter Saint-Andre
- Re: [VCARDDAV] JSON representation Cyrus Daboo
- Re: [VCARDDAV] JSON representation Simon Perreault
- Re: [VCARDDAV] JSON representation Raghurama Bhat (ragbhat)
- Re: [VCARDDAV] JSON representation Simon Perreault
- Re: [VCARDDAV] JSON representation Raghurama Bhat (ragbhat)
- Re: [VCARDDAV] JSON representation Julian Reschke
- Re: [VCARDDAV] JSON representation Simon Perreault
- Re: [VCARDDAV] JSON representation Peter Saint-Andre
- Re: [VCARDDAV] JSON representation Simon Perreault
- Re: [VCARDDAV] JSON representation Raghurama Bhat (ragbhat)
- Re: [VCARDDAV] JSON representation Simon Perreault
- Re: [VCARDDAV] JSON representation Joe Hildebrand
- Re: [VCARDDAV] JSON representation Joe Hildebrand
- Re: [VCARDDAV] JSON representation Raghurama Bhat (ragbhat)
- Re: [VCARDDAV] JSON representation Simon Perreault