Re: [VCARDDAV] vcardrev+xml next steps

[Kevin Marks <[e-mail]>]

I broadly concur with Tantek's analysis here.

I differ on KIND -
We do need a way to distinguish individuals from organisations and utility
addresses, but the current draft does not provide good examples of the
differnt kinds, and 'thing' is too vague. The point is to make functionally
useful distinctions, not arbitrary categories.

The value may be one of: "individual" for a single
      person, "group" for a group, "org" for an organization, "location"
      for a named geographical place, "thing" for an inanimate object
      (e.g. a device, a server, etc.), an x-name or an iana-token.  If
      this property is absent, "individual" MUST be assumed as default.

Replace 'individual' with 'person'.

Drop 'group' and add 'list' for mailing lists and similar addresses
that need different treatment by user-agents (eg gmail's category
error of insistently trying to invite mailing lists to gtalk).

Drop 'thing' and add 'automated' for the kinds of auto responder email
addresses that updates from social networks, banks and the like.

Giving:


The value may be one of: "person" for a single person, "list" for an
address corresponding to a list of people (eg a mailing list), "org"
for an organization, "location" for a named geographical place,
"automated" for an automated system (eg a social network notifier,
bank address), an x-name or an iana-token.  If this property is
absent, "person" MUST be assumed as default



On Sun, Oct 10, 2010 at 8:53 AM, Tantek Çelik <[e-mail]>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.
>
> 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.
>
> 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.
> * 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.
>
> 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)
> * calendar contact extension (FBURL, CALADRURI, CALURI)
>
>
> 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.
>
> Thanks for your consideration,
>
> Tantek Çelik
> Mozilla
>
>
> On Fri, Oct 1, 2010 at 10:24 AM, Marc Blanchet
> <[e-mail]> wrote:
> > After the concensus call about whether or not sending the vcardrev+xml
> > drafts to IETF Last Call, there were a number of NOs that were expressed.
> >
> > Given the late status of vcard, significant review over the years and
> > current charter specific deliverables, there is no place for a major
> change
> > of vcard. And there is no place for delaying the process forever.
> >
> > However, if the NOs proponents can write a short description of the
> specific
> > and actionable issues, then we can improve the specifications. Moreover,
> the
> > best way to bring this input is to propose alternate text to the current
> > text.
> >
> > Since we are approaching next IETF, the deadline is set to October 11th,
> in
> > order to find resolution on the issues and to give the document editors
> > enough time to incorporate WG consensus regarding technical issues before
> > the document submission deadline on 2010-10-25
> > <http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79>
> >
> > Therefore, this is a call to the NOs proponents to do the following:
> > - provide a short description of the specific and actionable issues
> > - provide alternate text to the current text
> > - by October 11th 23h59 GMT.
> > - each issue sent separately to the mailing list with a specific subject.
> >
> > Regards,
> > Marc, co-chair.
> >
> > --
> > =========
> > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
> > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
> > DTN news service: http://reeves.viagenie.ca
> > NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca
> >
> >
>
>
>
> --
> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
>