[VCARDDAV] Syncing and PIDs and UIDs (Oh my!)

[Pete Resnick <presnick at qualcomm.com>]

Try though I might to not get any work done in this group, I think I 
will try to break out of this pattern.

I've been going through the PID problem, and chatted with Simon, and 
I think I have come to a conclusion: PIDs must be monotonically 
increasing and unique throughout the vCard. That is:

     FN;PID=1:Jane Doe
     EMAIL;PID=1:jdoe3 at example.com

...wouldn't be acceptable. Instead, you'd need:

     FN;PID=1:Jane Doe
     EMAIL;PID=2:jdoe3 at example.com

Let me explain. If folks generally agree, I'll get to work on 
rewriting section 8.

First off, let me say that I've always felt that the vCard format 
should provide the tools so implementations that want to synchronize 
can do so. It does not mean that you're not going to have to write a 
bunch of code. It does not mean that there will not be duplicate or 
conflicting data that you have to deal with. It simply means that two 
devices that are playing by the same set of rules will have an easy 
time synchronizing and will not end up with data that makes the user 
crazy.

So, let's say that A and B are trying to sync what appear to be two 
identical vCards, and that they are the only two syncing devices (no 
triangles). The first time they sync, the two vCards might even have 
different UIDs which will be brought into sync. For this initial 
sync, neither PIDs nor UIDs buy you anything; we're having to figure 
out that these two vCards are actually one. However, once that's 
done, having a common UID for the two instances of the vCard and 
having identical PIDs is a big win. The next time we sync, it's easy 
to see what's changed, and I don't end up with duplicate properties, 
etc. (Note that we're only talking about two devices which actually 
support UIDs and PIDs. Devices that don't will have to do the 
"initial" syncing operation each time. Their loss.) However, we still 
do have the potential for a problem: If device A adds a new phone 
number, say:

           TEL;PID=10;TYPE=home:tel:+33-01-23-45-67

And unfortunately, device B adds a new phone number too:

           TEL;PID=10;TYPE=work:tel:+33-02-34-56-78

Let's say the REV on B's vCard is later than A's. Now, we go to sync. 
If we assume that those two properties are to be combined, we're 
going to do the wrong thing and end up throwing away A's new home 
phone number. What we want to have happen is for A to say, "B added a 
new phone number that it's calling PID 10" and for B to say the same 
of A and end up with both items. To accomplish this, A and B are both 
going to have to know which PIDs they've already synced and which are 
new. In order for that to work, PIDs are going to have to be 
increasing (I can't create PID 3 after I've created PID 4) and PIDs 
are going to have to be unique *throughout* the vCard (because 
otherwise I'm going to have to keep track of the last TEL PID, the 
last EMAIL PID, etc.).

This likely also means that, in addition to REV, we're going to need 
a LASTPID property.

So, before I go on to talk about the "triangle" problem, are people 
generally on board with the ideas I've talked about here?

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
VCARDDAV mailing list
VCARDDAV at ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav