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/