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).
It is also important for the people on
this list to realize that there are real world scenarios where there is no
single correct answer – sync engines may do different things based upon
the target audience, or many other factors. For example, many sync engines
will refuse to delete a majority of items, even if that is exactly what was
done on one device, because it is typically caused by user error (such as
allowing one’s children to play with the device), rather than really
being what was desired. Similarly, many cases where a property has been
added to multiple devices between syncs are because the user attempted to enter
the same data in multiple places, so duplication is rarely desired, even if
that is what is technically the most correct choice.
Overall, a brief overview seems
sufficient.
Specifically:
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
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.
Of course, update the ABNF, from uidparam
to pidparam.
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.
Also,
note that I think several properties in addition to UID should have prohibition
against having multiple instances, such as the REV property (or I am just
missing it) – and is it really settled regarding multiple entries in a
single vCard? By specifying the restriction generically, we can eliminate
the specific prohibition against having UID/PID on the UID param.
.
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.
Note that we must not require UID, as some
devices that expect to be synchronized will not be able to preserve it.
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.
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:jdoe at example.com
IMPP;TYPE=personal,pref:xmpp:alice at example.com
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:jdoe at example.com
IMPP;TYPE=personal,pref:xmpp:alice at example.com
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:jdoe at example.com
IMPP;TYPE=personal,pref:xmpp:alice at example.com
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:jdoe at example.com
IMPP;TYPE=personal,pref:xmpp:alice at example.com
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 hope this helps.
dgc
From: vcarddav-bounces at ietf.org [mailto:vcarddav-bounces at ietf.org]
On Behalf Of
Sent: Wednesday, June 04, 2008
11:03 AM
To: Simon Perreault
Cc: vcarddav at ietf.org
Subject: Re: [VCARDDAV] PIDs
proposal
Simon Perreault wrote:
Hello all, Here's a proposal for -02: - Rename UID parameter to PID.- Change PID value type to "a small integer."- Adapt examples so that they match the above. As far as the vCard format is concerned, this is pretty much all we need to specify. But if you only read that document and you want to implement a synchronization engine, you will be absolutely lost as to how to make use of the PID parameter. So we will need either to expand the Synchronization section or write a separate informational document.
Or have the specifications that call for its use
describe its usage for their particular context (e.g the OMA DS Enabler
Specifications)
Mark
What's missing is the mechanisms: - How UA's should handle PID values when - Creating a new property. - Synchronizing with another party.- The situations that give rise to conflicts in PID values.- How conflicts in PID values are detected and handled.- A rationale for why PIDs are "small integers" and why it is sufficient. I would gladly add that to the Synchronization section, but right now I have no idea how one could write a good synchronization engine with only small integers._______________________________________________VCARDDAV mailing listVCARDDAV at ietf.orghttps://www.ietf.org/mailman/listinfo/vcarddav
--
Oracle
Server Technologies - Collaboration
600 Blvd. de Maissoneuve West,