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
- vCard and CardDAV strawman Charter Chris Newman
- Re: vCard and CardDAV strawman Charter Cyrus Daboo
- Re: vCard and CardDAV strawman Charter Julian Reschke
- Re: vCard and CardDAV strawman Charter Cyrus Daboo
- Re: vCard and CardDAV strawman Charter Julian Reschke
- Re: vCard and CardDAV strawman Charter Julian Reschke