Re: vCard and CardDAV strawman Charter

Cyrus Daboo <cyrus@daboo.name> Thu, 24 May 2007 14:10 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrE16-0003kp-DD; Thu, 24 May 2007 10:10:12 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HrE15-0003kc-Gj for discuss-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 10:10:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrE14-0003kQ-6k for discuss@apps.ietf.org; Thu, 24 May 2007 10:10:10 -0400
Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrE12-0002P9-S0 for discuss@apps.ietf.org; Thu, 24 May 2007 10:10:10 -0400
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l4OEA4ii022490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2007 10:10:07 -0400
Date: Thu, 24 May 2007 10:09:59 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Julian Reschke <julian.reschke@gmx.de>
Subject: Re: vCard and CardDAV strawman Charter
Message-ID: <A230C60290DF1DF737430998@caldav.corp.apple.com>
In-Reply-To: <4655509E.8010903@gmx.de>
References: <AFD8F8BC1C0185492E28E4AE@446E7922C82D299DB29D899F> <C019BF6AA8E2371571D627F5@caldav.corp.apple.com> <4655509E.8010903@gmx.de>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: discuss@apps.ietf.org, Chris Newman <Chris.Newman@Sun.COM>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Hi Julian,

--On May 24, 2007 10:45:18 AM +0200 Julian Reschke <julian.reschke@gmx.de> 
wrote:

> Cyrus Daboo wrote:
>> I agree that rolling up all the new properties defined in RFCs into one
>> document would be good. Also I think it would make sense to define an
>> IANA registry for properties along the lines of what iCalendar has (is)
>> doing.
>
> That registry exists at
> <http://www.iana.org/assignments/text-directory-registrations>; a
> revision of RFC2425 probably should cite that.

Hrmm - well that registry does not reference the vCard spec 2426, and 2426 
does not reference it (as you noted). Also the IANA registry is not 
populated with the registrations defined in 2425 itself, and it ought to 
include the items defined in 2426 too. So something definitely needs to be 
fixed.

Also, in CardDAV I used the MIME type text/vcard - but I note that does is 
not the registered type. Instead 'text/directory; profile=vcard' is. 
However, I am pretty sure I have seen text/vcard being used in email - it 
may be we want to register that too as part of vcard-bis.

I also question the utility of text/directory these days. It seems that the 
only thing that actually uses it is vCard. Does it still make sense to have 
that as a separate document, or should it be rolled up into the vCard-bis 
effort? At the very least it may be that 2425 needs some updating as well 
and should be something we discuss at the BOF and potentially include in 
the charter.

>> - One thing did get removed from CardDAV in the last revision - the
>> "synchronization" report feature. I removed this because a similar
>> feature is also needed by CalDAV, and is arguably applicable to WebDAV
>> as a whole. I was planning on writing that up as a separate spec (work
>> under way). I would like to see such a specification also be dealt with
>> by this group - I think it is in scope on the basis that it does touch
>> on synchronization issues (and more specifically for deployment -
>> performance).
>
> Having that stand-alone sounds right, please do it on the former WebDAV
> WG's mailing list...

Whilst this is a "generic" WebDAV extension, both CalDAV and CardDAV really 
need it, so I would like to see this be part of the work items for the 
proposed working group if it gets going.


-- 
Cyrus Daboo