Subject: Re: [VCARDDAV] PIDs proposal

From: "Javier Godoy" <[email-masked]>
Date: Thu, 3 Jul 2008 01:11:25 -0300

(apologies for using this account, our SMTP server has been experiencing 
some problems today)

Simon Perreault wrote:

> On Saturday 21 June 2008 16:32:32 Darryl Champagne wrote:
>
>> In section 8.1, revise from:
>>
>> Two vCards for which the UID properties (Section 7.7.7) are equivalent
>> MUST
>> be considered representations of the same object. Equivalence is
>> determined
>> as specified in [RFC3986], Section 6.  A missing UID property MUST NOT be
>> considered equivalent to any other. Hence, the UID property MUST be
>> present
>> if synchronization is to be used.
(...)
>>
>> To something like:
>>
>> Two vCards for which the UID properties (Section 7.7.7) are equivalent
>> MUST
>> be considered representations of the same object. Equivalence is
>> determined
>> as specified in [RFC3986], Section 6.
>>
>> vCards without a UID property may be matched to vCards with a UID
>> property
>> where a synchronization engine determines there is sufficient similarity
>> to
>> assume equivalence.  The particular strategy and criteria used is out of
>> scope for this document.

In general, different URIs do not imply different resources (even though a
given vCard instance may have at most one UID property). The converse,
however, is true (two globally unique references which are equal are
references to the same object)

I think this was already discussed in this list, but think about the
following use case:

- client A creates a vCard with some UID,
- client B "synchronizes" with A but do not store the UID (let's say someone
has just imported the instance from client A, since importing has copy
semantics and do not implies synchronization engines).
- then client C "synchronizes" (or copies) the instance from client B and
assigns a UID to that instance (this behavior is allowed because the UID
value will be globally unique and that instance had no URI as far as client
C knows).
- now instances in A and C are representations of the same object, but with
different UIDs. A synchronization engine should not be forbidden to treat
both instances as refering to the same object.

Having said so, consider the following replacement for the paragraph 2
above:
[[
vCards without a UID property may be matched to vCards with a UID property
**and vCards with different UID MAY be considered representations of the
same object,**
where a synchronization engine determines there is sufficient similarity to
assume equivalence.  The particular strategy and criteria used is out of
scope for this document.
]]

Best Regards

Javier

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Thu, 3 Jul 2008 08:13:16 -0400

On Thursday 03 July 2008 00:11:25 Javier Godoy wrote:
> - client B "synchronizes" with A but do not store the UID (let's say
> someone has just imported the instance from client A, since importing has
> copy semantics and do not implies synchronization engines).

This is basically buggy behavior. If a device does not support importing UIDs, 
it should not output any either.

> assume equivalence.  The particular strategy and criteria used is out of

I'm really not comfortable with this change. It would make UID as weak as 
PIDs, but we cannot justify this weakness based on a high collision potential 
as we did for PIDs.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Mark Paterson <[email-masked]>
Date: Thu, 03 Jul 2008 09:44:49 -0400

Javier Godoy wrote:
> (apologies for using this account, our SMTP server has been 
> experiencing some problems today)
>
> Simon Perreault wrote:
>
>
> someone
That seems ok. Some sync solutions will actually do this already. 
Getting duplicate contacts in your address book is one of the biggest 
pet peeves users of sync technologies have so most implementations do 
their best to avoid duplications at all costs.

Mark

-- 

Oracle Email Signature Logo
Mark Paterson | Product Manager, UC & Mobile Services | 514.905.8649
Oracle Server Technologies - Collaboration
600 Blvd. de Maissoneuve West, Suite 1900, Montreal, Quebec, H3A 3J2
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Mark Paterson <[email-masked]>
Date: Thu, 03 Jul 2008 09:59:28 -0400

> it should not output any either.
I don't think Javier mean that B spits out a UID but rather C receives 
it without a UID and hence assigns its own. This is fairly typical 
behaviour amongst implementations that I know.

What Javier is describing is a dreaded sync triangle, aaaaahhhh!!!. 
Those of us involved with sync hate triangles :-)
> PIDs, but we cannot justify this weakness based on a high collision potential 

In cases where a triangle is occurring failure for a sync server to do 
so will result in repeated duplicates. To extend Javier's example 
further, A now sends what it thinks is a new contact to B (who drops the 
UID). It is then sent to C (who assigns a UID), it is then sent to A as 
new, and so on, and so on. The only way the loop stops is if A and/or C 
recognizes that something is the same as something they already have 
(even if there is no UID or a UID that seems new).

Of course the other solution that many sync solutions deploy is to tell 
users, DON"T DO THAT!!!!!!!!!!!!!!! :-)

Mark

--

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 03 Jul 2008 10:06:35 -0400

Hi Mark,

--On July 3, 2008 9:59:28 AM -0400 Mark Paterson <[email-masked]> 
wrote:

>> This is basically buggy behavior. If a device does not support importing
>> UIDs,  it should not output any either.
>>
> I don't think Javier mean that B spits out a UID but rather C receives it
> without a UID and hence assigns its own. This is fairly typical behaviour
> amongst implementations that I know.

And would be required behavior for a CardDAV client that MUST store vCards 
with a UID.

The bottom line is that duplicates are bound to occur. Even taking sync out 
of the equation, it is quite possible for two people to author separately a 
vCard for the same third party and thus end up with two different UIDs. If 
those vCards are in a public address book searchable by the two authors, 
they will see duplicates. At that point it is up to the client software or 
the server to decide how best to handle duplicates and whether or not to 
involve the users.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 3 Jul 2008 10:18:29 -0400

> behaviour amongst implementations that I know.

Oh, I understand now.

How about this then:

If it is used, the UID property MUST be added to the vCard only at creation 
time. The UID property MUST NOT be assigned to a vCard where it is missing at 
any later time.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 3 Jul 2008 10:19:33 -0400

On Thursday 03 July 2008 10:18:29 Simon Perreault wrote:
> time. The UID property MUST NOT be assigned to a vCard where it is missing
> at any later time.

Forget it it was a stupid idea.

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 4 Jul 2008 20:06:45 -0400

_____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Paterson
Sent: Thursday, July 03, 2008 9:59 AM
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [VCARDDAV] PIDs proposal

What Javier is describing is a dreaded sync triangle, aaaaahhhh!!!. Those of
us involved with sync hate triangles :-)

.

And PIDs will fix it so triangles work, but quadrilaterals' and up might or
might not.  Hmmm, how to document that, or not ;)

And of course the other requirement - don't ever use anyone else's sync
product with ours - _it_ will wreck your data (when combined with ours)..

Mark

--