Subject: Re: [VCARDDAV] wg concensus to publish?

From: Renato Iannella <[email-masked]>
Date: Fri, 1 Oct 2010 20:35:46 +1000

On 29 Sep 2010, at 04:03, Marc Blanchet wrote:

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

YES

(I do have concerns, but they are mainly related to other groups who have not reused vCard and reinvented similar semantics...so by moving these forward, they may take notice (or not;-( )

Cheers

Renato Iannella
http://renato.iannella.it

---

From: Joseph Smarr <[email-masked]>
Date: Fri, 1 Oct 2010 07:11:24 -0700

To be clear, everyone is aware of vCard, so the fact that several groups
chose not to reuse these current drafts might make you "take notice" that
lots of people in this field find them unacceptable as is. :)

On Fri, Oct 1, 2010 at 3:35 AM, Renato Iannella <[email-masked]> wrote:

> > Question: do you think draft-ietf-vcarddav-vcardrev and
> draft-ietf-vcarddav-vcardxml should be sent to IETF last call?
>
> YES
>
> (I do have concerns, but they are mainly related to other groups who have
> not reused vCard and reinvented similar semantics...so by moving these
> forward, they may take notice (or not;-( )
>
> Cheers
>
> Renato Iannella
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 01 Oct 2010 10:18:43 -0400

Hi Joseph,

> lots of people in this field find them unacceptable as is. :)

Then why invent something new, as opposed to coming to the IETF and asking 
for vCard to be revised? Is there something so fundamentally flawed about 
vCard that prevents that?

Note this is not a criticism of what has been done, I am trying to get a 
feel for why different contact formats have arisen with the goal of 
figuring out whether there is a way to bring things back together.

-- 
Cyrus Daboo

---

From: Joseph Smarr <[email-masked]>
Date: Fri, 1 Oct 2010 07:48:16 -0700

Cyrus-I *did* come to the IETF and ask vCard to be revised! :)

See
http://josephsmarr.com/2009/03/25/portable-contacts-and-vcarddav-ietf-74/ --
I spoke over a year ago in detail with Marc, Simon, etc about the
opportunities to simplify and modernize and extend what vCard is doing.
Everyone was polite and thoughtful at the time, but then seems to have
ignored or rejected all the proposed improvements. I'm also frustrated that
we're having these more substantive discussions now much later, but they
still need to be had--not because the rest of us don't like vCard or don't
want it to succeed, but exactly the opposite--we really want vCard to be
great and get widespread adoption and end the fragmentation that has
persisted in the industry for so long. We have a lot of experience getting
that done, and we want to impart that knowledge to your team so that your
spec has a better shot at reaching its potential.

But in order for that to happen, the rest of the WG needs to think through
some of these fundamental trade-offs and decide where they stand:
- taking this opportunity to modernize (both in syntax and
semantics) vs. preserving legacy
- favoring simplicity/readability of the wire format (esp for XML) vs.
maximizing flexibility / automaticity of conversion
- expanding scope to more fields vs. sticking to "core address book" data

These are at the heart of the debate more so than just "convergence" per se.
I really believe that vCard would be more useful and more widely adopted if
it embraced the "left-hand side" of each of those points above, where as
currently they're following the right-hand side. This is not a theoretical
or ideological debate, it's one born out of pragmatism and experience and a
nuanced understanding of how developers large and small have been working
with contact info in the field for the past decade.

So yes, let's please try to use the IETF to revolve these issues. And if no
one else here is receptive to that, well that will also explain why so many
other, related standards efforts have been created along the way. :)

Thanks, js

On Fri, Oct 1, 2010 at 7:18 AM, Cyrus Daboo <[email-masked]> wrote:

> feel for why different contact formats have arisen with the goal of figuring
> out whether there is a way to bring things back together.
>
> --
> Cyrus Daboo
>
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Oct 2010 17:36:55 +0200

On 01.10.2010 16:48, Joseph Smarr wrote:
>...

Joseph,

*coming to the IETF* means sending feedback to the Working Group 
(sending emails to this very mailing list). Did you do that back then?

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 01 Oct 2010 12:28:08 -0400

Hi Joseph,

> Cyrus-I *did* come to the IETF and ask vCard to be revised! :) 

Yes, I was there too.

>
> See http://josephsmarr.com/2009/03/25/portable-contacts-and-vcarddav-iet
> f-74/ -- I spoke over a year ago in detail with Marc, Simon, etc about
> the opportunities to simplify and modernize and extend what vCard is
> doing. Everyone was polite and thoughtful at the time, but then seems to
> have ignored or rejected all the proposed improvements. I'm also
> frustrated that we're having these more substantive discussions now much
> later, but they still need to be had--not because the rest of us don't
> like vCard or don't want it to succeed, but exactly the opposite--we
> really want vCard to be great and get widespread adoption and end the
> fragmentation that has persisted in the industry for so long. We have a
> lot of experience getting that done, and we want to impart that knowledge
> to your team so that your spec has a better shot at reaching its
> potential.

I want to dispute the perceived lack of wide spread adoption of vcard. I 
believe that to be false. All the major desktop contact systems have 
support for vCard. Many, many mobile systems support it. vCards have been 
sent and processed via email for decades now. Widely adopted by web apps - 
well that is a different and valid question.

> But in order for that to happen, the rest of the WG needs to think
> through some of these fundamental trade-offs and decide where they stand:

> semantics) vs. preserving legacy

Let's leave syntax out - we now have both text and XML variants, and a JSON 
variant would be trivial to do too. As for preserving legacy, vCard does 
have a large legacy just because of how widespread its use is.

> maximizing flexibility / automaticity of conversion

I guess there is a fundamental difference here over how important 
"readability" is. Personally I find neither XML or JSON all that "readable" 
in the first place. What I care about is having a concrete well-defined 
schema that is easy to implement in code for the use cases I need to 
support. Yes there is a concern about unnecessary size, particularly given 
that we want to send these things to mobile devices, but on-the-wire 
compression is a big help.

> - expanding scope to more fields vs. sticking to "core address book" data

We already have this in v4. The new IANA registry allows for easy 
extensions to the schema. There are already several drafts doing that (one 
for social networking properties, one for calendaring and scheduling 
resource properties).

-- 
Cyrus Daboo

---

From: Renato Iannella <[email-masked]>
Date: Mon, 4 Oct 2010 19:36:44 +1000

On 2 Oct 2010, at 00:48, Joseph Smarr wrote:

> But in order for that to happen, the rest of the WG needs to think through some of these fundamental trade-offs and decide where they stand:
> - taking this opportunity to modernize (both in syntax and semantics) vs. preserving legacy

I think semantically, it does an OK job, wrt to legacy

> - favoring simplicity/readability of the wire format (esp for XML) vs. maximizing flexibility / automaticity of conversion

I agree here. I argued (unsuccessfully) for a simpler XML.

Perhaps we can create a new IETF draft that provides an alternate simpler/compact XML encoding?
Would that be possible?

> - expanding scope to more fields vs. sticking to "core address book" data

I think it should stick to the core and then allow anyone else to expand (eg add your Zodiac field for social networks) - as long as people actually do that (ie extend the core) then interoperability is assured at some level.

Cheers

Renato Iannella

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Oct 2010 11:39:46 +0200

> simpler/compact XML encoding?

It's always possible, if not even recommended, to post alternative 
proposals as Internet Drafts.

Best regards, Julian