[VCARDDAV] Alignment of CUTYPE and KIND

Mike Douglass <douglm@rpi.edu> Tue, 13 July 2010 18:59 UTC

Return-Path: <douglm@rpi.edu>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1733A6849; Tue, 13 Jul 2010 11:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level:
X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_50=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMg47O93Sjry; Tue, 13 Jul 2010 11:59:31 -0700 (PDT)
Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by core3.amsl.com (Postfix) with ESMTP id 7AA333A6832; Tue, 13 Jul 2010 11:59:31 -0700 (PDT)
Received: from [128.113.124.94] (decapod-09.dynamic.rpi.edu [128.113.124.94]) (authenticated bits=0) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id o6DIxcsv021682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 14:59:39 -0400
Message-ID: <4C3CB79A.6050604@rpi.edu>
Date: Tue, 13 Jul 2010 14:59:38 -0400
From: Mike Douglass <douglm@rpi.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b2pre Thunderbird/3.0.4
MIME-Version: 1.0
To: vcarddav@ietf.org, calsify@ietf.org
References: <AANLkTilx6XgI2iosuKf5zmHnLggkmYe4EeeN-PijvI5K@mail.gmail.com> <36FF8BB750F3694C0400EAC1@caldav.corp.apple.com> <4C3C8815.4010304@viagenie.ca>
In-Reply-To: <4C3C8815.4010304@viagenie.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RPI-SA-Score: undef - SENDER Whitelisted (douglm@rpi.edu: Mail from user authenticated via SMTP AUTH allowed always)
X-CanItPRO-Stream: outgoing
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225
Subject: [VCARDDAV] Alignment of CUTYPE and KIND
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 13 Jul 2010 18:59:32 -0000

While implementing calendar client support using carddav for attendee 
lookup we came across the inconsistencies in vcard KIND and attendee 
CUTYPE which I believe ought to be addressed.

KIND has

      KIND-param = "VALUE=text" / any-param
      KIND-value = "individual" / "group" / "org" / "location" / "thing"


CUTYPE has

        cutypeparam        = "CUTYPE" "="
                           ("INDIVIDUAL"   ; An individual
                          / "GROUP"        ; A group of individuals
                          / "RESOURCE"     ; A physical resource
                          / "ROOM"         ; A room resource
                          / "UNKNOWN"      ; Otherwise not known
                          / x-name         ; Experimental type
                          / iana-token)    ; Other IANA-registered
                                           ; type
        ; Default is INDIVIDUAL

So INDIVIDUAL and GROUP align OK
CUTYPE.RESOURCE = KIND.thing?

No CUTYPE equivalent for KIND.ORG
KIND.LOCATION is better than CUTYPE.ROOM (an event might take place on a 
sports field)




On 07/13/2010 11:36 AM, Simon Perreault wrote:
> On 2010-07-13 10:59, Cyrus Daboo wrote:
>    
>> So there is a real problem here. For example, if in the future I define
>> a new property FOO that uses a ;-delimited compound value, then I want
>> to be sure that clients not aware of this property will properly
>> "round-trip" it. So if I send such a client this:
>>
>> FOO:delimited;text\;string
>>      
> Right, there is a problem with the current text.
>
> Assume we specify that semicolons that are not component separators MUST
> be escaped. Then a client can correctly interpret this unknown property
> as having two components. And it will always output it exactly the way
> it received it. That fixes the problem, right?
>
> If so, this would point toward the acceptance of proposal 1.
>
> Simon
>    

-- 

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180