Subject: [VCARDDAV] PIDs, again.

From: "Darryl Champagne" <[email-masked]>
Date: Wed, 16 Jul 2008 19:48:19 -0400

Hi,
Well, it's been a week without a PID email, so let me see if I can summarize
where things stand related to PIDs.

- I'm not sure where we stand in the thread "Re: [VCARDDAV] Syncing and PIDs
and UIDs (Oh my!)" last discussed in
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00445.html.  I
don't think there is consensus around LASTPID at this time, but the
discussions are not finished.  

- A remaining issue was on what text to add to explain the choice of small
integers, and what the collision issues are.  Since explaining this on the
mailing list required a long explanation to address questions (see message
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00439.html), I am
reluctant to attempt this without knowing exactly what the existing text is,
and it is not clear to me if other people are planning on providing this
discussion or not.

- There were diverging threads about PID related updates.

The first thread started, relative to draft 1, and ended last, "Re:
[VCARDDAV] PIDs proposal", included that various sections were being
updated:
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00403.html.  The
thread continued with discussions about adding some discussion about
collision issues, and why small integers are used.

A thread that was completely contained within the above threads timeframe
also updated those same sections of the spec relative to draft 2, especially
as indicated in:
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00390.html (which
updated section 8.1), and
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00377.html, which
updated the rest of the sections. 

Common to both threads above, was an agreement to revise:

Topic 3)
Section 7.7.7 UID included the text:
   Special notes:  The type is used to uniquely identify the object that
      the vCard represents.  The "uuid" URN namespace defined in
      [RFC4122] is particularly well-suited to this task, but other URI
      schemes MAY be used.

      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 PID parameter MUST NOT be applied to this property.

The edits resulted in: 
   Special notes:  The type is used to uniquely identify the object that
      the vCard represents.  The "uuid" URN namespace defined in
      [RFC4122] is particularly well-suited to this task, but other URI
      schemes MAY be used.

      This property MUST NOT appear more than once in a given vCard.

Topic 5)
In section 8.2, relative to draft 2, the sentence:
   Two vCards are to by synchronized:
Was revised to:
   Two vCards are to be synchronized:

Topic 8)
Section 9: ABNF
Added was:

   pid-param    = ("PID" "=" 1*DIGIT)

   pid-param was added to NICKNAME, PHOTO, ADR, LABEL, TEL, EMAIL, TITLE, 
   ROLE, LOGO, AGENT, ORG, MEMBER, RELATED, CATEGORIES, NOTE, SOUND, URL, 
   and KEY.

(Although there was some additional discussion about where it might be
appropriate - I don't see any final changes)

Currently slightly Conflicted:

Topic 1)
section 6, in the earlier edit the example:
    FN;PID=8:Jane Doe (Draft 2)
Was revised as:
    FN:Jane Doe
In the later, but against draft 1 edit:
    FN;UID="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6":Jane Doe 
    (Draft 1)
Was deleted entirely.

I don't care either way about this.

Topic 2)
Section 6.4 PID

The edit relative to Draft 2 is:

    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.  Its value is a small integer.

The (later) edit relative to Draft 1 is the same, without the small integer
sentence.

My assumption is that we are going with the edit relative to Draft 2, but it
doesn't really matter to me.

Topic 4:
In the later edit, Section 8.1 was to be updated relative to draft 1 to be:

    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.

There was also some unconcluded discussion about explicitly talking about
matching vCards that do not have matching UIDs (as opposed to just not
talking about, like above).  I'm not sure where we stand on that.

In the edit relative to draft 2 section 8.1 was to be updated to be:

    Two vCards for which the UID properties are equivalent MUST be 
    considered representations of the same object.  Equivalence is 
    determined as specified in RFC 3986, Section 6. The UID property SHOULD 
    be present if synchronization is to be used.

    * Two vCards for which the PID properties are equivalent MUST be 
    considered representations of the same object.  Equivalence is 
    determined as specified in RFC 3986, Section 6. The PID property SHOULD 
    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.

* It is not clear to me if the above is what was meant, or if the "Likewise"
in the email was just referred to removing the original second sentence,
resulting in:

   Pairs of properties, one from each of a pair of vCards representing
   the same object, having equivalent names and PID parameter values
   MUST be considered representations of the same object.  The
   PID parameter SHOULD be present if synchronization is to be used.

** It is not clear to me if this third paragraph was expected to stay or
not.

I am assuming that the later edit relative to Draft 1 is what we are going
with, although it is probably desirable to add the SHOULD statements into
it, resulting in a merged statement similar to:

    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. The UID property SHOULD be 
    present if synchronization is to be used.

    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. The PID property SHOULD be present if 
    synchronization is to be used.

Topic 6) 7)
Section 8.2

Relative to Draft 2, the phrase:
   Assuming the first one is the source and the other is the
   destination, a synchronization engine may produce the following
   merged vCard:
Was revised to:
   A synchronization engine may produce the following merged vCard:

Relative to draft 2 the vCards were updated in both instances of:
     FN;PID=1:Jane Doe
To:
     FN:Jane Doe

The later revision relative to Draft 1 was to replace the entire section
with:
   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.

That is my understanding of where things stand.  If the text is stable and
well-understood, I could attempt at adding discussion about the choice of
using small integers, and collisions (although having something short, yet
meaningful seems difficult).

What I see as still needed is some mention about trying to not reuse PID
values once they are deleted (at least between the deletion operation and
the next sync).  My preference is to not specify any algorithm for choosing
new PIDs, just leave it open.  We just want to keep it very clear that they
are not globally unique, their purpose is to identify which particular
instance was deleted or modified, there will not be a lot of PIDs for each
property, and collisions and duplications of Adds must be dealt with somehow
(especially so loops can never start replicating things).  If there is a
strong preference to doing the LASTPID as a means of preventing reuse of
deleted PIDs, despite understanding the slightly worse behavior in
collisions, I wouldn't object, although I don't think it is worth doing.

Thanks,
dgc
--
Darryl G. Champagne
Technology Evangelist
Funambol
AIM/Y!/Skype: dgc03052
ph: +1 (603) 424-0323     Mob: +1 (603) 440-3621 (+ SMS)
[email-masked]          http://www.funambol.com 

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