Re: [VCARDDAV] vcardrev+xml next steps

Cyrus Daboo <cyrus@daboo.name> Tue, 12 October 2010 13:54 UTC

Return-Path: <cyrus@daboo.name>
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 BF25D3A6982 for <vcarddav@core3.amsl.com>; Tue, 12 Oct 2010 06:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.523
X-Spam-Level:
X-Spam-Status: No, score=-101.523 tagged_above=-999 required=5 tests=[AWL=-1.220, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 CZkcKD9hvnht for <vcarddav@core3.amsl.com>; Tue, 12 Oct 2010 06:54:42 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id B28B63A696E for <vcarddav@ietf.org>; Tue, 12 Oct 2010 06:54:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A06CB1A3D4DE8; Tue, 12 Oct 2010 09:55:55 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiKgxD4N0sxP; Tue, 12 Oct 2010 09:55:50 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 391C91A3D4161; Tue, 12 Oct 2010 09:55:47 -0400 (EDT)
Date: Tue, 12 Oct 2010 09:55:42 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Tantek Çelik <tantek@cs.stanford.edu>, CardDAV <vcarddav@ietf.org>
Message-ID: <0082910B06B23E66DA70472D@caldav.corp.apple.com>
In-Reply-To: <AANLkTimytRt6UYN-_86CR3Mpep5ac_dX9SpayxzKxZ6S@mail.gmail.com>
References: <4CA61957.9020906@viagenie.ca> <AANLkTimytRt6UYN-_86CR3Mpep5ac_dX9SpayxzKxZ6S@mail.gmail.com>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size="4389"
Cc: Rohit@khare.org, Mike Hanson <mhanson@mozilla.com>
Subject: Re: [VCARDDAV] vcardrev+xml next steps
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, 12 Oct 2010 13:54:43 -0000

Hi Tantek,

--On October 10, 2010 8:53:34 AM -0700 Tantek Çelik 
<tantek@cs.stanford.edu> wrote:

> Based on a thorough section by section review[1], the changes and
> feedback I have for vCard4 draft 13 fall into a general outline as
> follows.
>
>
> 1. Explicitly state as a goal to have vCard4 be reasonably backward
> compatible (i.e. with current implementations) of vCard3, both
> syntactically, and from a schema perspective (e.g. don't mess with
> structure of properties like N). This kind of practical backward
> compat enabled publishers to start posting vCard3 even when most
> consuming applications still only supported vCard2.1. The presence of
> vCard3 data then encouraged consuming applications over time to adopt
> it as well. I'd like to see the same successful adoption occur for
> vCard4.

I would not object to reverting N back to the v3 definition. However, I do 
want to see TEL kept as a URI - or at least have the uri be the preferred 
form. Given that the tel: URI provides a syntactically well-defined way to 
do things like intl prefixes, extensions, access codes, all of which are 
heavily used today, I think it is vital to make this change.

> 2. Keep the vCard4 core set of properties down to a minimum that has
> been well established either in:
> * Popular address book programs (e.g. ANNIVERSARY)
> * Current well adopted mature RFCs (e.g. IMPP)
> * Common additions by OpenID / Portable Contacts that have seen
> adoption (e.g. SEX/GENDER, LANGUAGE, ACCOUNTS)
> I believe this too will encourage better vCard4 adoption.

I am not convinced that splitting the spec at this point makes sense, but I 
would not oppose that idea either. Frankly multiple specs adds significant 
processing overhead that we could do without.

> 3. Drop other new vCard4 properties from the core and if they seem to
> make sense, move them to extension specifications instead where they
> can prove themselves out, e.g.:

> * KIND - vCard should not expand scope like this. For new kinds of
> objects new vThings should be created, and can be, outside the vCard
> spec.

I consider KIND a requirement. Even now most vCard clients try and make a 
distinction between a "individual" card and a "org" card. Most of the time 
clients have to invent their own way to figure out which is which. KIND 
fixes that and gives us some other key items ("location" is particularly 
important).

> * XML - bad idea. Don't violate DRY. This encourages breaking interop
> by potentially allowing implementations to look only at the XML or at
> the actual properties in a vCard. Same on the publishing side.

I consider XML to be a requirement too. There is a lot of effort going on 
to embed vCard (and also iCalendar) in XML and an XML format makes it much 
easier to manage and manipulate with standard XML tools.

> Potential Extensions:
> * genealogy extension (BIRTH location, DEATH location, DDAY datetime
> of death, maybe more from GEDCOM)

> * social networking extension (MEMBER, RELATED, maybe more from PoCo)

MEMBER is not strictly a social networking property, but rather a 
"directory" property. Instead what you could use is 
RELATED;TYPE="affiliation" (new TYPE value or perhaps "social network").

Also, I do think RELATED should be a "core" property. It is not just 
"social" but also "business" and "family". Many apps today provide ways to 
identify and link to family member or co-worker cards.

> * calendar contact extension (FBURL, CALADRURI, CALURI)

Calendar information is becoming more and more important I would urge that 
these remain part of the "core".

>
> vCard4 Section by section critique/feedback/suggestions.
>
> I've written up my section by section feedback for vCard4 draft 13
> here with short descriptions of the specific and actionable issues and
> alternate text to the current text as well:
>
> [1] https://wiki.mozilla.org/VCard4#draft_13_section_by_section_review
>
> If necessary, I can send an email per section (or per feedback item
> per section) to the mailing list with a specific subject, however that
> will result in a lot of emails, and I wanted to avoid overloading the
> group with such email if possible.  But if that's the preference of
> the group/list/editors, I'm willing to go along and do so.

I will take a look at your review and comment where I feel I need to. 
Thanks for taking the time to do this.

-- 
Cyrus Daboo