Subject: [VCARDDAV] difference in UID between vCard 3.0 and vCard 4.0 / relationship to CardDAV

From: Arnaud Quillaud <[email-masked]>
Date: Tue, 18 Jan 2011 16:34:59 +0100

Hello,

The UID property has moved between vCard 3.0 and 4.0 from text (although 
a type parameter could be specified) to uri and only uri.

In the context of a server which wanting to handle both formats (e.g. 
supporting 
http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-10#section-5.1.1), this 
is rather problematic.
For example, if a contact is originally created using a vCard 3.0 client 
(using a simple text UID value), the server has to:
* either store the UID value as is but return different UID values 
depending on the client making the request (vcard 3.0 or vcard 4.0 client).
* or change the UID value from under the client when first storing the 
vCard on the server, to make it a URI.
None of those options seems satisfactory.

So while I see the removal of the type parameter as a good thing (there 
is no point in trying to interpret/parse its value since its only 
purpose is to uniquely define the resource), I don't understand the need 
to force the value to be a URI.

Couldn't we simply make the recommendation that the text value be a URI 
while still allowing any value ?

Arnaud Quillaud

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Jan 2011 17:01:27 +0100

On 18.01.2011 16:34, Arnaud Quillaud wrote:
> ...
> ...

Can't the server map non-URI parameters to a special URI, and reverse 
that when needed?

Best regards, Julian

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 18 Jan 2011 08:37:40 -0800

Why break backwards-compatibility with vCard 3 here? I agree that saying
SHOULD be a URI is plenty, unless there's some serious issue this causes
that I'm not aware of. UIDs just need to be stable and globally unique, not
necessarily URLs per se, right? Thanks, js

On Tue, Jan 18, 2011 at 8:01 AM, Julian Reschke <[email-masked]>wrote:

> Can't the server map non-URI parameters to a special URI, and reverse that
> when needed?
>
> Best regards, Julian
>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Jan 2011 17:46:56 +0100

On 18.01.2011 17:37, Joseph Smarr wrote:
> that I'm not aware of. UIDs just need to be stable and globally unique,
> not necessarily URLs per se, right? Thanks, js

You can't have "globally unique" without specifying the syntax.

If you have something that is supposed to be globally unique, simply 
escape it properly, and append it to a server-defined base-URI to 
generate a URI.

Best regards, Julian

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 18 Jan 2011 10:00:01 -0800

Meh, URIs don't ensure globally unique state either (it assumes everyone has
and uses their own unique domain name--but what do I do when I export my
local outlook address book?), and in practice people invent random schemes
to generate UIDs all the time and it works fine. I see no requirement that
the UID values be interoperable or contain some predictable internal
structure, which is what calling for URIs does.

On Tue, Jan 18, 2011 at 8:46 AM, Julian Reschke <[email-masked]>wrote:

> If you have something that is supposed to be globally unique, simply escape
> it properly, and append it to a server-defined base-URI to generate a URI.
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Jan 2011 19:04:30 +0100

On 18.01.2011 19:00, Joseph Smarr wrote:
> Meh, URIs don't ensure globally unique state either (it assumes everyone
> has and uses their own unique domain name--but what do I do when I

It doesn't guarantee it, but simply enables it. If you hand-wave about 
what the syntax is then getting reliable uniqueness is much harder.

Best regards, Julian

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 18 Jan 2011 10:47:57 -0800

I don't think it's hand-waving to say "UIDs should be stable and globally
unique. URIs are thus recommended as the UID format to use." But it doesn't
mean that vCard 3 UIDs suddenly become illegal vCard 4 vCards, which IMO
will cause more harm than good (and we're so close to preserving backwards
compat at this point).

On Tue, Jan 18, 2011 at 10:04 AM, Julian Reschke <[email-masked]>wrote:

> It doesn't guarantee it, but simply enables it. If you hand-wave about what
> the syntax is then getting reliable uniqueness is much harder.
>
>  ...
>>
>
> Best regards, Julian
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Jan 2011 14:12:31 -0500

On 2011-01-18 13:47, Joseph Smarr wrote:
> But it doesn't mean that vCard 3 UIDs suddenly become illegal vCard 4
> vCards, which IMO will cause more harm than good (and we're so close to
> preserving backwards compat at this point).

Why should

UID;VALUE=text:A vCard 3 UID

be preferred over

UID:data:A vCard 3 UID

?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 18 Jan 2011 14:55:27 -0800

I'm worried about all the existing vCards with lines like this:

UID:Some-unique-but-non-standard-value

I don't see why a strict vCard4 parser should reject this, i.e. why should
decide to declare this valid vCard3 an invalid vCard 4.

---

From: Royer Software and Services <[email-masked]>
Date: Tue, 18 Jan 2011 17:34:11 -0700

The UID identifies the original object.

If someone reads some translated into V4-UID with  a V3-VCARD client, 
your going to have a mess
of duplicate cards in your address book.

*Doug - Royer Software and Services*
Project-Contracting.com <http://Project-Contracting.com>
+1-714-989-6135 <tel:+1-714-989-6135>

On 1/18/2011 15:55, Joseph Smarr wrote:
> I don't see why a strict vCard4 parser should reject this, i.e. why 
> should decide to declare this valid vCard3 an invalid vCard 4.
>
> On Tue, Jan 18, 2011 at 11:12 AM, Simon Perreault 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Arnaud Quillaud <[email-masked]>
Date: Wed, 19 Jan 2011 11:19:44 +0100

> UID;VALUE=text:A vCard 3 UID
I dont think the debate is around preferring one over another but rather 
that the current spec forces a change from one value *to* the other when 
translating from vCard 3 to vCard 4. As a consequence, the original UID 
value is lost and there is no longer a way to correlate the old vcard 
with the new one which is the point of having a UID property.
As mentioned by Doug, this may lead to duplicate entries because UID 
values are no longer round tripped between vCard 3 and vCard 4 clients.

The problem is also about the fact that a strict vCard 4 parser may now 
reject vCard 3 entries just because of this change.

Arnaud Quillaud

---

From: Arnaud Quillaud <[email-masked]>
Date: Wed, 19 Jan 2011 12:25:36 +0100

On 01/18/2011 07:00 PM, Joseph Smarr wrote:
> Meh, URIs don't ensure globally unique state either (it assumes 
> everyone has and uses their own unique domain name--but what do I do 
> when I export my local outlook address book?), and in practice people 
> invent random schemes to generate UIDs all the time and it works fine.
Exactly. Is there any evidence that the vCard 3 definition of UID has 
ever been problematic in the field ?

 From looking at the mailing list archive, the change of definition was 
*not* driven by a problem around uniqueness but rather it was to get rid 
of the following section:

<<

The type can include the type parameter "TYPE" to specify the format
    of the identifier. The TYPE parameter value should be an IANA
    registered identifier format. The value can also be a non-standard
    format.

(see http://www.ietf.org/mail-archive/web/vcarddav/current/msg00094.html 
- of course I may have missed some other justifications for the change)

As rightly pointed out in the thread, UIDs do not need such flexibility. 
And in practice, most if not all vCard 3 UIDs have no type parameter and 
are just random strings.

What do we loose by changing the current definition to something like:

<<

Purpose:  To specify a value that represents a globally unique
       identifier corresponding to the individual or resource associated
       with the vCard

Value type:  A single text value.

    Cardinality:  (0,1)

    Special notes:  This property is used to uniquely identify the object
       that the vCard represents. The "uuid" URN namespace defined in
       [RFC4122  <http://tools.ietf.org/html/rfc4122>] is particularly well-suited to this task, but other
       schemes (based on URI or not) MAY be used.

    ABNF:

      UID-param = "VALUE=text" / any-param
      UID-value = text

?

Arnaud Quillaud
> I see no requirement that the UID values be interoperable or contain 
> some predictable internal structure, which is what calling for URIs does.
>
> On Tue, Jan 18, 2011 at 8:46 AM, Julian Reschke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     If you have something that is supposed to be globally unique,
>     simply escape it properly, and append it to a server-defined
>     base-URI to generate a URI.
>
>     Best regards, Julian
>
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2011 14:28:27 +0100

> with the new one which is the point of having a UID property.

Well, there can be a way. The WG just needs to specify it.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2011 14:44:19 +0100

> Well, there can be a way. The WG just needs to specify it.

Speaking of which, in 
<http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-15#section-4.2>:

    "uri": The "uri" value type should be used to identify values that
    are referenced by a URI (including a Content-ID URI), instead of
    encoded in-line.  These value references might be used if the value
    is too large, or otherwise undesirable to include directly.  The
    format for the URI is as defined in [RFC3986].  Note that the value
    of a property of type "uri" is what the URI points to, not the URI
    itself.

...it would be good to be more precise what ABNF production in RFC 3986 
is meant. Such as:

   "The format for the URI is as defined by the "URI" production in 
Section 3 of [RFC3986]."

Best regards, Julian

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Jan 2011 08:52:22 -0500

> Value type:  A single text value.

I would prefer to encourage URIs going forward, while keeping backwards
compatibility.

Alternative proposal: uri by default, MAY be reset to a text value.

OK?

Simon

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2011 15:01:45 +0100

> Alternative proposal: uri by default, MAY be reset to a text value.

Which of course raised the question how you detect which is which. Is

   "Juliansrandomnumbers:4-8-15-16-23-42"

a URI?

Best regards, Julian

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Jan 2011 09:10:34 -0500

On 2011-01-19 09:01, Julian Reschke wrote:
> Which of course raised the question how you detect which is which.

With the VALUE parameter.

UID:This:is a URI
UID;VALUE=uri:This:is also a URI

UID;VALUE=text:This is free-form text

Simon

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2011 15:34:19 +0100

> UID;VALUE=text:This is free-form text

I see :-)

Anyway, we could easily define a mapping of any text value to a specific 
URI (in a way so that it's round-tripping).

Best regards, Julian

---

From: Arnaud Quillaud <[email-masked]>
Date: Wed, 19 Jan 2011 17:22:37 +0100

> UID;VALUE=text:This is free-form text
This won't solve the vCard 3 backward compatibility issue since most 
vCard 3 will just have

UID:This is free form text

which will be considered as invalid.

Arnaud Quillaud

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Jan 2011 11:31:17 -0500

Hi Arnaud,

> which will be considered as invalid.

There is also the question of what a vcard v3 client will do with 
UID;VALUE=URI:xxx - will it preserve the parameter? If not, then CardDAV 
servers are going to have to cope with re-writing UID to/from vcard 3 
clients.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Jan 2011 11:35:03 -0500

> which will be considered as invalid.

I don't get it. Are you suggesting that just changing VERSION:3.0 to
VERSION:4.0 should produce a valid vCard 4?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Jan 2011 11:37:01 -0500

> servers are going to have to cope with re-writing UID to/from vcard 3

That's forward compatibility, which is different from backward
compatibility. If the WG decides it also wants forward compatibility,
there is a lot of work ahead of us.

Simon

---

From: Joseph Smarr <[email-masked]>
Date: Wed, 19 Jan 2011 08:39:26 -0800

Agreed. I just want valid vCard 3 files to also be valid vCard 4 files,
since in practice there is and will continue to be a lot of legacy out
there, so the bar to declare previously valid stuff suddenly invalid should
be quite high, and forcing UIDs to be URIs doesn't come close to that, IMO.