Subject: Re: [VCARDDAV] PIDs proposal

From: Simon Perreault <[email-masked]>
Date: Wed, 2 Jul 2008 14:45:03 -0400

Sorry for not replying to this email earlier. It got buried and lost in my 
TODO folder.

On Saturday 21 June 2008 16:32:32 Darryl Champagne wrote:
> I basically agree with Mark here, vCard specs don't need to explain how to
> write a sync engine, there are other protocols that describe that,
> including examples, overviews of what is needed to sync, issues, and so on
> (and there is at least one book as well).
>
> [...]
>
> Overall, a brief overview seems sufficient.

I agree.

> Revise the example in section 6, from the unlikely possibility of multiple
> FN's:
>
>      FN;UID="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6":Jane Doe
>
> To a more typical case of multiple Tels:
>
>      TEL;PID=3;TYPE=home:tel:+33-01-23-45-67

Well, this example is specifically designed to showcase the usage of double 
quotes around parameter values, not PIDs. With UUID-based PIDs gone, I can't 
think of a good example where a quoted string would be needed, so I'm just 
going to remove it. It's obvious enough what's intended anyway.

> I do want to mention that the use of URI's with their embedded colons is
> slightly confusing with the use of colon's to signify the start of the data
> - ":tel:".  It's not a real issue, it just seems less elegant.

Yes, and it was mentioned earlier on this list. Nobody objected though.

> Of course, update the ABNF, from uidparam to pidparam.

Thanks for catching this.

> Section 6.4 is updated as described below, including deleting the phrase ",
> and MUST be present if synchronization is to be used."
>
> The result would be something like:
>
> 6.4 PID
>
> The "pid" parameter is used to identify a specific property among multiple
> instances.  It plays a role analogous to the UID property (Section 7.7.7)
> on a per-property instead of per-vCard basis. It MUST NOT appear more than
> once in a given property.  It MUST NOT appear on properties that only may
> have one instance per vCard.  Note that the "pid" parameter is not globally
> unique, so it is possible for duplicate values to be created.

Applied with the added sentence "Its value is a small integer."

> Update the end of section 7.7.7 UID from:
>
> This property MUST NOT appear more than once in a given vCard, and MUST be
> present if synchronization is to be used.  See Section 8.
>
> The UID parameter MUST NOT be applied to this property.
>
> To just:
>
> This property MUST NOT appear more than once in a given vCard.
>
> or perhaps:
>
> This property MUST NOT appear more than once in a given vCard.  This
> property is well-suited for synchronization.  See Section 8.

Applied the first form.

> Note that we must not require UID, as some devices that expect to be
> synchronized will not be able to preserve it.

Note that this goes against issue #225. There have been no comment either way 
on the list, but there have been many arguments for making it required during 
the WG meeting in Philadelphia.

I will reopen the issue to give it a chance to be discussed appropriately.

> 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.
>
> Pairs of properties, one from each of a pair of vCards representing the
> same object, having equivalent names and UID parameter values MUST be
> considered representations of the same object.  A missing UID parameter
> MUST NOT be considered equivalent to any other.  Hence, the UID parameter
> MUST be present if synchronization is to be used.
>
> It is expected that a synchronization engine will exploit such property
> associations by e.g. overwriting the destination property value and
> parameters with the source destination property value and parameters.  The
> particular merging strategy is out of scope for this document.
>
> 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.
>
> Updates to vCards with multiple instances of particular properties may use
> the PID associated with each property to aid in determining what values
> have changed.  Since PIDs are not globally unique, they can only be used as
> guidelines to synchronization engine logic.  Such logic is out of scope for
> this document.

Applied with uppercase MAYs.

> For section 8.2, update from:
>
>    Two vCards are to by synchronized:
> ...
> Etc.
> ...
>
> to:
>
>    Two vCards are to be synchronized:
>
>      BEGIN:VCARD
>      VERSION:4.0
>      UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da
>      FN:Jane Doe
>      TEL;PID=1;TYPE=home:tel:+33-01-23-45-67
>      TEL;PID=3;TYPE=home:tel:+1-800-555-1234
>      EMAIL;PID=1:[email-masked]
>      IMPP;TYPE=personal,pref:xmpp:[email-masked]
>      END:VCARD
>
>      BEGIN:VCARD
>      VERSION:4.0
>      FN:Jane Doe
>      TEL;PID=1;TYPE=home:tel:+33-01-23-45-67
>      TEL;PID=4;TYPE=home:tel:+1-800-555-5678
>      EMAIL;PID=1:[email-masked]
>      IMPP;TYPE=personal,pref:xmpp:[email-masked]
>      END:VCARD
>
>    Assuming a synchronization engine is presented with the two vCards, it
> may decide based upon logic out of scope of this document, that both vCards
> are representations of the same object, and create a merged vCard such as:
>
>      BEGIN:VCARD
>      VERSION:4.0
>      UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da
>      FN:Jane Doe
>      TEL;PID=1;TYPE=home:tel:+33-01-23-45-67
>      TEL;PID=3;TYPE=home:tel:+1-800-555-1234
>      TEL;PID=4;TYPE=home:tel:+1-800-555-5678
>      EMAIL;PID=1:[email-masked]
>      IMPP;TYPE=personal,pref:xmpp:[email-masked]
>      END:VCARD
>
> If the synchronization engine then is presented with an updated vCard such
> as:
>
>      BEGIN:VCARD
>      VERSION:4.0
>      UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da
>      FN:Jane Doe
>      TEL;PID=1;TYPE=home:tel:+33-01-23-45-67
>      TEL;PID=4;TYPE=home:tel:+1-800-555-5678
>      EMAIL;PID=1:[email-masked]
>      IMPP;TYPE=personal,pref:xmpp:[email-masked]
>      END:VCARD
>
> It may use the PIDs on each property to determine that the 2nd phone number
> in the sequence has been deleted.  Note that there may be data beyond what
> is available within a vCard, such as a SpeedDial number, that is specific
> to each individual property instance, which is why providing a correlation
> between versions is significant.
>
> This is just a suggestion, meant to show an example of merging a vCard
> without a UID with one that has one, and also showing a specific instance
> of a property being modified.  A lot of this could be worded better, but
> this is just a quick first pass to show the main ideas.

I applied it verbatim. I find it clear and concise.

> I hope this helps.

Absolutely. Many thanks.

-- 
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: Simon Perreault <[email-masked]>
Date: Wed, 2 Jul 2008 15:36:15 -0400

On Monday 23 June 2008 17:50:42 you wrote:
> There are some very clear examples in previous emails, where it matters
> during sync to know which particular property was changed - because going
> from a list of X values to a new list of Y values conveys no information as
> to which item was actually changed or deleted.  What about this was not
> understood?

The examples are very good, but could be accompanied by two paragraphs or so 
about "what do we do about collisions". It seems to be an important concern 
as evidenced by the amount of related discussion on this mailing list. 
Specifically:

- When collisions happen, what do we do? We must not crash and burn. 
Collisions should be detectable. This issue was dodged by describing PIDs as 
simply a hint to the sync engine, contrary to UIDs. So there is no collision 
until the sync engine decides so, and PIDs are only a hint.

- Won't collisions be generated often enough so as to make PIDs useless? It 
was mentioned that collisions would only happen in four-party scenarios. PIDs 
are not designed for synchronizing vCards disseminated on the Internet at 
large, they are designed for synchronizing among small personal devices.

If these two explanations are correct, I will expand them a bit and propose 
specific text.

---

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

> until the sync engine decides so, and PIDs are only a hint.

Any objection to call them "a strong evidence" ? IMHO, something whose
failure (collision) requires a not-so-trivial use case, a long time without
synchronizing, and/or several properties being created in different clients
is much more than a mere "hint" (though it is not absolute certainty
either). On the other side, different PIDs are only a hint because
properties with different PIDs may or may not refer to the same object (the
use case for them doing so only requires 2 clients).

(and please Darryl, please do not get angry if I'm missing something you
have already said ;-)

> large, they are designed for synchronizing among small personal devices.

That, and some rationale about why did we decide using small integers
instead of UUID. I'm afraid that people will recur to this issue and they
will be eager to say that "PID are useless" instead of searching through
months-long threads. Of course, this doesn't change the validity of the
chosen approach, but (I hope) it will (may?) encourage implementors to
accept PIDs for what they are meant.

> If these two explanations are correct, I will expand them a bit and

I think they are.

Best Regards

Javier

---

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

> I will reopen the issue to give it a chance to be discussed appropriately.
I think there is general agreement that if a contact is going to be 
passed back and forth between two stores (or multiple stores) and 
reconciliation/synchronization of some sort is gong to occur via VCard 
objects being exchanged using a protocol such as OMA DS or CardDAV then 
the use of UID is going to make that experience better (or at least 
easier on the implementors).

If that is the case why not Mandate that it MUST be used in such cases?

The problem is that I think there is also general agreement that the way 
in which many existing implementations work this is not going to 
necessarily be practical and hence the retreat back to the more soft 
line approach a stating that it SHOULD be used in such cases.

Ultimately, whether or not we state it MUST or SHOULD be used in such 
scenarios will have no real bearing on whether vendors actually do 
decide to support it within their implementations. If they have a 
perceived problem that they feel they can solve by supporting UID then 
hopefully they will take advantage of it. That is the best we can hope for.

Thanks,
Mark

P.S.: There would be nothing stopping a protocol specification such as 
that for CardDAV mandating the use of UIDs for CardDAV clients and servers.
-- 

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:39:49 -0400

> until the sync engine decides so, and PIDs are only a hint.
Yes, the sync engine will decide what it should do.
> large, they are designed for synchronizing among small personal devices.
I think this statement really does a good job of illustrating where the 
arguments concerning UUID vs PID have arisen. If you publish a Vcard 
like some sort of global directory entry that anyone can use and edit 
and you publish new copies periodically then collisions with those 
copies others have picked up and passed around, etc.. seems inevitable 
BUT in the scenario where a user is making use of solutions that use OMA 
DS or CardDAV the pid collision issue is far less likely and as stated 
above the sync engine logic can do what it thinks is best.
> If these two explanations are correct, I will expand them a bit and propose 
OK seems reasonable.

Mark

--

---

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

Javier Godoy wrote:
>> Collisions should be detectable. This issue was dodged by describing 
>> PIDs
>> as
Not sure I really see any difference in calling them hints vs strong 
evidence.
> accept PIDs for what they are meant.
I understand your rational but explaining why in a spec sometimes 
becomes a bit if a slippery slope. I'll refrain from commenting until 
there is some proposed text.
>> If these two explanations are correct, I will expand them a bit and
Agreed.

Mark

--

---

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

Hi Mark,

> that for CardDAV mandating the use of UIDs for CardDAV clients and

An indeed CardDAV does do that:

   vCard components in an address book collection MUST have a UID
   property value that MUST be unique in the scope of the address book
   collection in which it is contained.

-- 
Cyrus Daboo

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 3 Jul 2008 16:15:43 -0300

Mark Paterson wrote:
  Javier Godoy wrote: 

      - When collisions happen, what do we do? We must not crash and burn. 
      Collisions should be detectable. This issue was dodged by describing PIDs 
      as simply a hint to the sync engine, contrary to UIDs. So there is no 
      collision until the sync engine decides so, and PIDs are only a hint. 

    Any objection to call them "a strong evidence" ? 
  Not sure I really see any difference in calling them hints vs strong evidence.

It was a sudden thought... Not really worthy.

      - Won't collisions be generated often enough so as to make PIDs useless? 
      It 
      was mentioned that collisions would only happen in four-party scenarios. 
      PIDs 
      are not designed for synchronizing vCards disseminated on the Internet at 
      large, they are designed for synchronizing among small personal devices. 

  I understand your rational but explaining why in a spec sometimes becomes a bit if a slippery slope. I'll refrain from commenting until there is some proposed text.

It is absolutely not a priority, and I understand your point too: it will be a RFC, not a tutorial. However, paraphrasing Fermat, "we have a truly marvellous reason for making PIDs small integers instead of UUIDs, but this RFC is too narrow to contain it".

I will also refrain from commenting about it, in order to focus discussion in other topics.

Best Regards

Javier

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 4 Jul 2008 19:57:51 -0400

Hi,
There now have been multiple, out-of-order, overlapping updates to the same
sections.  

Could the "current" text for these please be posted?
Specifically sections 6.4, 7.7.7, and all of section 8.

The email to which Simon replied to below was sent (which included before
and after sections), later draft 2 was posted, then a message thread "Re:
[VCARDDAV] Section 8.2 - was
RE:I-DAction:draft-ietf-vcarddav-vcardrev-02.txt" (and it's predecessor) was
done with this exact same list of items redone, which was followed by
modifications, different substitutions, and so on, and now the out of order
reply below.  It is not clear to me which text is being modified, or what it
now looks like.

Thanks,
dgc

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Wednesday, July 02, 2008 2:45 PM
> To: [email-masked]
> Subject: Re: [VCARDDAV] PIDs proposal
>