Subject: [VCARDDAV] vCard 4 - let's publish

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Sep 2010 09:53:25 -0400

Hi folks,
At this time my feeling is that we should go ahead with publication of 
vcard 4.0 (and the XML spec) as-is. These documents have been in 
development and review for several years now and everyone has had a chance 
to comment (of course IETF last call is still to be done so an opportunity 
to comment further naturally exists).

vCard 4 is based on the well-founded technology of earlier vCard 
specifications. It represents a comprehensive solution to contact 
information, and not just personal contacts (e.g., see the recent draft on 
calendar resource information that adds vCard properties specific to the 
calendaring process). It now has easy extensibility built-in, via IANA 
registrations, so new properties, for e.g., social networking, are easy to 
define and add by consensus.

I do believe that we should help other groups define simple mappings 
between their formats and vCard. At this point I do not believe that is a 
major effort - certainly not one that should hold up vCard 4 at this time.

So I would urge the chairs and ADs to move our working group documents 
along the standards process at this time. We can continue to work with OMA 
and W3C through liaisons and their participation in this open IETF working 
group.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Mon, 27 Sep 2010 13:51:58 -0400

I second this.

There are a number of implementations of vCard4 already in existence. 
For example, we (bedework) have a CardDAV server supporting the current 
draft. Also work is proceeding building on vCard4, for example the 
resource schema mentioned by Cyrus: 
http://tools.ietf.org/html/draft-cal-resource-schema-02 which is also 
supported by bedework. Other clients and systems have support for vCard 
4.0 and I believe we need a degree of stability so that we can all move 
forward.

I strongly believe that we need good support for social networking and 
other areas in vCard4 and that we should align the various 
specifications. However, unless there are some obvious incompatibilities 
that can be easily fixed, I would suggest we move ahead with the 
specification as it stands.

On 09/27/2010 09:53 AM, Cyrus Daboo wrote:
> development and review for several years now and everyone has had a 
> chance to comment (of course IETF last call is still to be done so an 
> opportunity to comment further naturally exists).
>
> information, and not just personal contacts (e.g., see the recent 
> draft on calendar resource information that adds vCard properties 
> specific to the calendaring process). It now has easy extensibility 
> built-in, via IANA registrations, so new properties, for e.g., social 
> networking, are easy to define and add by consensus.
>
> between their formats and vCard. At this point I do not believe that 
> is a major effort - certainly not one that should hold up vCard 4 at 
> this time.
>
> along the standards process at this time. We can continue to work with 
> OMA and W3C through liaisons and their participation in this open IETF 
> working group.
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Joseph Smarr <[email-masked]>
Date: Mon, 27 Sep 2010 11:06:54 -0700

With respect, I think we should give the renewed interest/effort in
alignment between vCard / PoCo / OMA / W3C / etc a bit more time to bear
fruit.

I worry that there are still some serious issues in the current vCard
proposal--ranging from incompatibility with vCard 3 (e.g. in how the N field
is carved up) to harmful legacy that hasn't been dropped (like the use of
pobox and extended-address sub-fields in adr) to missed opportunities to
make the spec simpler and more modern (of which there are numerous
examples).

vCard is still "the most widely known contact spec", and upgrading to a new
version of the spec is something that lots of people will take notice of. If
we miss this opportunity to address these issues, it will be a while before
we get another chance. I do not believe much of the design of vCard 4 or its
XML flavor have been widely reviewed or "field-tested" outside of this WG,
and I think it should be of concern to this WG that several other related
efforts all found serious problems with the current proposed spec, leading
to the current (and past) calls for better alignment and learning from the
progress that other efforts (like PoCo) have made in the wild with major
contact providers.

I haven't yet seen much substantive feedback from vCardDAV folks about the
issues of complexity, legacy, and scope that we've raised and that led to
the WGLC being postponed. So it's hard to tell if our input has been
considered and rejected (e.g. if you disagree that the current XML format of
<sex><integer>1</integer></sex> is sub-optimal) or whether it just hasn't
been given proper consideration. In absence of either, I don't think it's
advisable to just "go ahead with publication of vcard 4.0 (and the XML spec)
as-is".

Obviously I don't want to hold things up more than necessary, but I'm really
concerned that unless we take these issues more seriously in this WG, we're
going to end up being stuck with something that has lots of problems, which
will lead to less adoption, less interop, and less opportunity to change the
currently fragmented and non-standard world of contact/social information,
APIs, etc.

I would encourage anyone else with similar feelings to make yourselves heard
now, so that the WG can get an accurate sense of the current consensus (or
lack thereof) on whether the current proposed drafts are good enough as is
or whether we should address these complexity/interop/scope/etc issues more
first.

Thanks, js

On Mon, Sep 27, 2010 at 10:51 AM, Mike Douglass <[email-masked]> wrote:

>  I second this.
>
> There are a number of implementations of vCard4 already in existence. For
> example, we (bedework) have a CardDAV server supporting the current draft.
> Also work is proceeding building on vCard4, for example the resource schema
> mentioned by Cyrus:
> supported by bedework. Other clients and systems have support for vCard 4.0
> and I believe we need a degree of stability so that we can all move forward.
>
> other areas in vCard4 and that we should align the various specifications.
> However, unless there are some obvious incompatibilities that can be easily
> fixed, I would suggest we move ahead with the specification as it stands.
>
>
>> vcard 4.0 (and the XML spec) as-is. These documents have been in development
>> and review for several years now and everyone has had a chance to comment
>> (of course IETF last call is still to be done so an opportunity to comment
>> further naturally exists).
>>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Sep 2010 21:00:53 +0200

On 27.09.2010 20:06, Joseph Smarr wrote:
> ...

To get there, it would be nice to get concrete technical feedback on the 
Internet Draft.

> ...
> I haven't yet seen much substantive feedback from vCardDAV folks about
> the issues of complexity, legacy, and scope that we've raised and that
> led to the WGLC being postponed. So it's hard to tell if our input has
> been considered and rejected (e.g. if you disagree that the current XML
> format of <sex><integer>1</integer></sex> is sub-optimal) or whether it
> just hasn't been given proper consideration. In absence of either, I
> don't think it's advisable to just "go ahead with publication of vcard
> 4.0 (and the XML spec) as-is".
> ...

Simon Perreault answered this one over two weeks ago in 
<http://www.ietf.org/mail-archive/web/vcarddav/current/msg01681.html>.

>...

My 2 cents, from the point of somebody only following from a distance: 
it doesn't make sense to delay this again and again. Either people have 
feedback, then they should provide it right *now* (*). Or let the IETF 
process proceed (with the IETF LC being the next "official" opportunity 
for feedback).

Best regards, Julian

(*) But claiming it will come "soon", and then not sending it, is really 
a problem.

---

From: Mike Douglass <[email-masked]>
Date: Mon, 27 Sep 2010 15:12:16 -0400

On 09/27/2010 02:06 PM, Joseph Smarr wrote:

> alignment between vCard / PoCo / OMA / W3C / etc a bit more time to 
> bear fruit. 

If we are going to give it any more time I think we need deadlines. 
vCard 4.0 draft 00 was published March 17 2008.

I think you conflate 2 major issues
1. Is vcard 4.0 good enough as it stands?
2. What do we do about compatibility with other contact representations?

On 1 - we've had nearly 2.5 years of discussion. The result may be 
sub-optimal but there are implementations handling the v3/v4 
incompatibilities - even though we could all wish they didn't have to.

On 2 - We should probably map out all the mismatches and agree on a way 
to handle them - (though that hasn't really happened yet even for 
v3<->v4). I don't see such a process being over soon and the results are 
likely to still be reasonably compatible with V4

> been considered and rejected (e.g. if you disagree that the current 
> XML format of <sex><integer>1</integer></sex> is sub-optimal) or 
> whether it just hasn't been given proper consideration. In absence of 
> either, I don't think it's advisable to just "go ahead with 
> publication of vcard 4.0 (and the XML spec) as-is".

On this point - I would say I do disagree - but then I'm one of the 
authors of the icalendar in xml spec. In that specification we spent 
some time talking over verbosity over predictability and in the end 
decided that predictability wins. Having written code to generate and 
parse the 'verbose' form I'm glad we took that approach. There are 
almost no special cases (recurrences being the one) and no surprises. 
Extensions that fall into the pattern require no code changes.

> Thanks, js
>
> On Mon, Sep 27, 2010 at 10:51 AM, Mike Douglass <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>      I second this.
>
>     There are a number of implementations of vCard4 already in
>     existence. For example, we (bedework) have a CardDAV server
>     supporting the current draft. Also work is proceeding building on
>     vCard4, for example the resource schema mentioned by Cyrus:
>     http://tools.ietf.org/html/draft-cal-resource-schema-02 which is
>     also supported by bedework. Other clients and systems have support
>     for vCard 4.0 and I believe we need a degree of stability so that
>     we can all move forward.
>
>     I strongly believe that we need good support for social networking
>     and other areas in vCard4 and that we should align the various
>     specifications. However, unless there are some obvious
>     incompatibilities that can be easily fixed, I would suggest we
>     move ahead with the specification as it stands.
>
>
>         At this time my feeling is that we should go ahead with
>         publication of vcard 4.0 (and the XML spec) as-is. These
>         documents have been in development and review for several
>         years now and everyone has had a chance to comment (of course
>         IETF last call is still to be done so an opportunity to
>         comment further naturally exists).
>
>         vCard 4 is based on the well-founded technology of earlier
>         vCard specifications. It represents a comprehensive solution
>         to contact information, and not just personal contacts (e.g.,
>         see the recent draft on calendar resource information that
>         adds vCard properties specific to the calendaring process). It
>         now has easy extensibility built-in, via IANA registrations,
>         so new properties, for e.g., social networking, are easy to
>         I do believe that we should help other groups define simple
>         mappings between their formats and vCard. At this point I do
>         not believe that is a major effort - certainly not one that
>         should hold up vCard 4 at this time.
>
>         So I would urge the chairs and ADs to move our working group
>         documents along the standards process at this time. We can
>         continue to work with OMA and W3C through liaisons and their
>         participation in this open IETF working group.
>
>
>     -- 
>
>     Mike Douglass [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

--

---

From: Mark Paterson <[email-masked]>
Date: Tue, 28 Sep 2010 09:44:48 -0400

The proposal in the liaison statement is as follows

OMA-COM-CAB SWG would like to suggest IETF VCARDDAV to consider contact 
fields defined in OMA CAB format in a further evolution of vCard (e.g. 
4.1 or 5.0).

OMA-COM-CAB SWG will be interested in collaborating (e.g. via joint 
meetings or conf calls between IETF VCARDDAV and OMA COM-CAB SWG) with 
IETF VCARDDAV for this work and providing any guidance that IETF 
VCARDDAV may request.

As such they are not asking to delay vcard 4.0.

There is some excellent work that has gone into this and their are 
solutions ready to embrace it so I  would also suggest proceeding with 
last call. If a 4.1 or some form of extension is needed for the OMA-CAB 
work then so be it.

On 27/09/2010 3:12 PM, Mike Douglass wrote:
> On 2 - We should probably map out all the mismatches and agree on a 
> way to handle them - (though that hasn't really happened yet even for 
> v3<->v4). I don't see such a process being over soon and the results 
> are likely to still be reasonably compatible with V4
>
>>
>> I haven't yet seen much substantive feedback from vCardDAV folks 
>> about the issues of complexity, legacy, and scope that we've raised 
>> and that led to the WGLC being postponed. So it's hard to tell if our 
>> input has been considered and rejected (e.g. if you disagree that the 
>> current XML format of <sex><integer>1</integer></sex> is sub-optimal) 
>> or whether it just hasn't been given proper consideration. In absence 
>> of either, I don't think it's advisable to just "go ahead with 
>>     also supported by bedework. Other clients and systems have
>>     support for vCard 4.0 and I believe we need a degree of stability
>>     so that we can all move forward.
>>
>>     I strongly believe that we need good support for social
>>     networking and other areas in vCard4 and that we should align the
>>     various specifications. However, unless there are some obvious
>>         adds vCard properties specific to the calendaring process).
>>         It now has easy extensibility built-in, via IANA
>>         registrations, so new properties, for e.g., social
> Mike [email-masked]

-- 

Oracle Email Signature Logo
Mark Paterson | Director of Product Management, Beehive Enterprise 
Messaging | 514.905.8649
Oracle Server Technologies - Collaboration
600 Blvd. de Maisonneuve West, Suite 1900, Montreal, Quebec, H3A 3J2

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 28 Sep 2010 14:03:38 -0400

Hello,
  I would like to get a wg concensus feel on this.

Question: do you think draft-ietf-vcarddav-vcardrev and 
draft-ietf-vcarddav-vcardxml should be sent to IETF last call?

Please reply to the mailing list by adding a simple YES or NO at the end 
of the subject line of this message.

If there is no clear concensus, then I'm thinking of proposing a webex 
teleconf before Beijing to discuss and try to get concensus.

Marc, co-chair.

Le 10-09-27 09:53, Cyrus Daboo a écrit :
> information, and not just personal contacts (e.g., see the recent draft
> on calendar resource information that adds vCard properties specific to
> the calendaring process). It now has easy extensibility built-in, via
> IANA registrations, so new properties, for e.g., social networking, are
> easy to define and add by consensus.
>
> between their formats and vCard. At this point I do not believe that is
> a major effort - certainly not one that should hold up vCard 4 at this
> time.
>

-- 
=========
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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 28 Sep 2010 14:20:57 -0400

(With some minor fixes I've been accumulating.)

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Sep 2010 12:43:06 -0600

> last call. If a 4.1 or some form of extension is needed for the OMA-CAB

Mark, that seems like a reasonable approach. The conclusion I draw is
that this WG can move ahead with its work on vCard4 (next step: IETF
Last Call) and in parallel continue the productive conversation that's
started among the IETF, W3C, OMA, and PoCo communities. That ongoing
conversation might result in additional work items for this WG, in a
form that is yet to be determined, but need not hold up finalization of
vCard4 at this late stage in the process.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Sep 2010 12:47:27 -0600

Given my reply just now to Mark Paterson and my general sense of the
list discussion over the last month or so, I say "yes".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Thewlis <[email-masked]>
Date: Tue, 28 Sep 2010 11:55:36 -0700

On Sep 28, 2010, at 11:03 AM, Marc Blanchet wrote:

> Question: do you think draft-ietf-vcarddav-vcardrev and draft-ietf-vcarddav-vcardxml should be sent to IETF last call?
> 
> Please reply to the mailing list by adding a simple YES or NO at the end of the subject line of this message.
> 
> If there is no clear concensus, then I'm thinking of proposing a webex teleconf before Beijing to discuss and try to get concensus.
> 
> Marc, co-chair.
>

---

From: Daisuke Miyakawa <[email-masked]>
Date: Tue, 28 Sep 2010 12:08:45 -0700

YES

2010/9/28 Peter Saint-Andre <[email-masked]>

-- 
Daisuke Miyakawa (宮川大輔)
[email-masked]

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 28 Sep 2010 15:08:43 -0400

Hi Marc,

YES
-- 
Cyrus Daboo

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 28 Sep 2010 14:57:02 -0700

NO

(for the reasons we've been discussing).

On Tue, Sep 28, 2010 at 12:08 PM, Cyrus Daboo <[email-masked]> wrote:

> Hi Marc,
>
> --On September 28, 2010 2:03:38 PM -0400 Marc Blanchet <
> [email-masked]> wrote:
>

---

From: Kevin Marks <[email-masked]>
Date: Tue, 28 Sep 2010 15:40:39 -0700

NO
Convergence concerns aren't fully addressed.

---

From: Andy Mabbett <[email-masked]>
Date: Wed, 29 Sep 2010 01:58:04 +0100

Yes; good luck.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

---

From: Kepeng Li <[email-masked]>
Date: Wed, 29 Sep 2010 09:23:23 +0800

No.

Although from OMA CAB's LS, they don't want to delay vCard 4. 

It is still better to leave some time to make good collaborations with OMA
work and W3C work.

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Marc Blanchet
发送时间: 2010年9月29日 2:04
收件人: [email-masked]
主题: [VCARDDAV] wg concensus to publish?

Hello,

Marc, co-chair.

---

From: Andrew McMillan <[email-masked]>
Date: Thu, 30 Sep 2010 12:06:49 +1300

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
         Flexibility is overrated.  Constraints are liberating.
------------------------------------------------------------------------

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 30 Sep 2010 22:15:48 -0700

> Question: do you think draft-ietf-vcarddav-vcardrev and draft-ietf-vcarddav-vcardxml should be sent to IETF last call?

Yes.

-- Kurt