Subject: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-01.txt

From: [email-masked]
Date: Wed, 9 Apr 2008 09:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the vCard and CardDAV Working Group of the IETF.

	Title           : vCard Format Specification
	Author(s)       : P. Resnick, S. Perreault
	Filename        : draft-ietf-vcarddav-vcardrev-01.txt
	Pages           : 62
	Date            : 2008-04-09

This document defines the vCard data format for representing and
exchanging a variety of information about an individual (e.g.,
formatted and structured name and delivery addresses, email address,
multiple telephone numbers, photograph, logo, audio clips, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Wed, 9 Apr 2008 13:08:36 -0400

On Wednesday 09 April 2008 12:30:01 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the vCard and CardDAV Working
> Group of the IETF.
>
>

Here's the changelog. There are some very big changes. Comment away!

B.1.  Changes in -01

   o  Merged [RFC2739] in.

   o  Converted all foobar.com, abc.com, etc. to example.com.

   o  Fixed bugs in ABNF.

   o  Made explicit that coordinates in the GEO property are expressed
      in the WGS 84 reference system.

   o  Clarified folding issues with multi-byte characters.

   o  Made the value of TEL a URI.

   o  Added the UID parameter.

   o  Made the UID property's value type a URI.

   o  Added Section 8.

   o  Created IANA process for registering new parameters, value types,
      and properties.

   o  Created the initial IANA registries.

   o  Created vendor namespace based on text from RFC 4288.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 10 Apr 2008 03:54:02 -0300

Hi Simon

I agree with the changes in draft-ietf-vcarddav-vcardrev-01, but for 
choosing "UID parameter" instead of "PID parameter" (I was convinced the 
latter remarks the difference wrt. the UID property, although this is only 
my personal opinion after some discussion in the mailing list)

I have some other comments about this version:

6.  Property Parameters

uidparam is defined as

 uidparam = "uid" "=" URI  ; from Appendix A of [RFC3986]

We have also been discussing other alternatives with less overhead (such as 
using integers, at the expense of increased complexity for avoiding 
identifier collisions). While discussing these alternatives is out of scope 
for this document, the current syntax plainly forbids any non-URI approach.

---

7.6.4.  AGENT

The example reads:

AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:tel:+1-919-555-
 1234\nEMAIL\;INTERNET:[email-masked]\nEND:VCARD\n

It should include the mandatory VERSION:4.0 property (and could include the 
N property too, which is RECOMMENDED).

---

8. Synchronization

[[ The particular merging strategy is out of scope for this document. ]]

I agree. As far as we was discussing the strategy would depend on several 
factors and it is not clear which one is the best (or there is no "best" 
strategy at all... as I have just said, it depends on the application 
context). However, we have been discussing deeply about this subject. I 
think we could address it in an additional document with experimental or 
informational status . Is there interest on that? I think it could be useful 
for implementors trying to develop a particular merging mechanism.

For instance, we could expand on the advantages and disadvantages of sorted 
identifiers versus random identifiers, and try to elaborate about the 
semantics of merging and preferences for keeping properties introduced in 
that device, which requires tracking which device introduced each property.

Furthermore, we could set the basis for a UUID-like value-space with reduced 
length (either a shorter random sequence, or a shorter <whatever + node-id> 
pair)... actually we don't need a 100-nanosecond clock or "allocation rates 
of up to 10 million per second" (RFC 4122, Section 2). I repeat, this 
proposal would be out of scope for the "core" vCard specification.

---

9.  Formal Grammar

The word "property" should replace "type" in comments such as
"A vCard object MUST include the VERSION, FN and N types."

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Apr 2008 09:21:53 -0400

> for this document, the current syntax plainly forbids any non-URI approach.

On the contrary, I think it is *very* in scope.

"This revision shall include other vCard standardized extensions (RFC 2739,
4770) and extensions assisting synchronization technologies (for example, a
per-entry UUID or per-attribute sequence number)."

We need to have some kind of idea how people are going to make use of the 
synchronization extensions if we're going to design them correctly!

Now, I think it's been made clear, through discussion both on this mailing 
list and at the last WG meeting, that we need to be able to generate IDs that 
are guaranteed to be unique. Small integers won't work.

> N property too, which is RECOMMENDED).

As discussed previously, nested vCards will disappear in favor of reference by 
URI or UID. But thanks for the note, I'll keep that in mind when reworking 
that example.

> that device, which requires tracking which device introduced each property.

I believe these are different issues and that we need to now address "the 
advantages and disadvantages of sorted identifiers versus random 
identifiers". Not with the goal of producing text that will be included in 
vCard 4.0, but at least discuss it in the context of this WG so that we can 
decide what format to use for the property IDs.

> Furthermore, we could set the basis for a UUID-like value-space with
> reduced length (either a shorter random sequence, or a shorter <whatever +
> node-id> pair)... actually we don't need a 100-nanosecond clock or
> "allocation rates of up to 10 million per second" (RFC 4122, Section 2). I
> repeat, this proposal would be out of scope for the "core" vCard
> specification.

I'm really not sure about that. We need to plug *something* as the format of 
the property IDs. If we say "a URI or an integer", we're really not saying 
much and we're going to get huge interoperability problems if we get past 
implementors not knowing what to do with the spec.

> "A vCard object MUST include the VERSION, FN and N types."

Thanks, fixed for -02.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 10 Apr 2008 06:53:55 -0400

Le 08-04-10 à 02:54, Javier Godoy a écrit :
> informational status . Is there interest on that?

you are more than welcome to start one!

Marc.

IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 10 Apr 2008 16:57:40 -0300

Hi Marc,

On Thursday, April 10, 2008 7:53 AM, Marc Blanchet wrote:

>> I agree. As far as we was discussing the strategy would depend on
>> several factors and it is not clear which one is the best (or there is no 
>> "best"

> you are more than welcome to start one!

I will gather our former discussion about this issue, then I will try to 
outline a coherent proposal.

Best Regards

Javier

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 10 Apr 2008 16:57:20 -0300

Hi Simon,

> per-entry UUID or per-attribute sequence number)."

IMHO it is in scope according to the vcarddav charter, and certainly the 
most relevant part of this discussion is appropriate within the vCard 4.0 
specification (which could recommend some identifier scheme), but I don't 
think so for a detailed explanation or a proposal that is experimental in 
nature. *That* is what I consider out of scope for the "core" document, as 
in "the particular merging strategy is out of scope for this document." (-01 
draft, section 8.1). Merely this and nothing more.

> are guaranteed to be unique. Small integers won't work.

Yes it has been, and I understand that UUIDs are easily guaranteed to be 
unique. Indeed, when we started discussing this issue, I thought UUIDs were 
a good choice, until Cyrus commented thar UUIDs are unnecessarily long 
because global uniqueness is given by the instance UID, hence property IDs 
are only required to be locally unique[1]. The latter fact is already 
conveyed by section 8.1 [2] (if two property IDs are equal, but the 
enclosing vCard identifiers are different, the property are NOT 
representations of the same property instance) but we are not taking any 
advantage from this.

[1] http://www.ietf.org/mail-archive/web/vcarddav/current/msg00057.html

[2]: 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

> URI or UID. But thanks for the note, I'll keep that in mind when reworking

Yes, I forgot that.

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Apr 2008 18:31:47 -0400

> representations of the same property instance) but we are not taking any

Yes, but the problem is that of generating unique property IDs. Let's say on a 
PC and on a PDA you have copies of the same vCard (same UID). Then you add 
TEL properties on both. They need to generate new PIDs (note to self: rename 
UID parameter to PID) independently. The fact that they're part of the same 
vCard doesn't help.

UUID is just
 - many bits with
 - ways to guarantee uniqueness in generated IDs

We could reinvent UUID with not that many bits, but then we'd also have to 
redefine the generating algorithms. And having less bits would weaken the 
uniqueness guarantee.

One shortcut that we could mention in the document: do not generate IDs in 
that case. Assume that properties without IDs are never "representations of 
the same object". Only generate IDs when copying (that includes when 
synchronizing).

How about that last idea? Or is it playing with fire for no good reason?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 11 Apr 2008 14:25:43 -0300

Hi Simon,

> the problem is that of generating unique property IDs. Let's say on a

What does help is that two properties with the same PID but in two vCards
with *distinct* UID are not referring to the same object. Then, the 2^128
value-space of UUID PIDs is too much for identifying objects in such a
limited scope.

As currently stated, just including one or two PIDs would require as much
space as for storing an additional property... thus we will have 128-bit (at
best) identifiers for synchronizing few properties (if we avoid PIDs, we
would be able of storing more properties... when the storage capabilities
are a constraint, I think it is a huge price to pay).

How many properties could we expect will be *created* in a vCard lifetime?
If PIDs were only 32-bit random strings, one could generated 4096
identifiers for the same *property type*, and the collision probability
would be below one-millionth.

How many properties could we expect will be concurrentely present, in at
least one stored copy of a vCard?
As you keep creating and deleting properties, most of PIDs will be forgotten
(there will not be in any vCard on the universe with the same UID), and it
will be safe to reuse them.
If you have several properties if the same type you will have a huge
vCard... which could not be stored in a "limited storage capabilities"
device (and we would not be required to use short UIDs).

How many device would be working on a single vCard? A version 1 UUID gives
you 48-bit node identifier, a 60-bit clock and a 14-bit safeguard "clock
sequence" number. Do we *really* need that? I can't imagine 2^48 nodes
editing a replicated copies of single vCard instance, then synchronizing
it...

I think a 32-bit PID is enough for synchronizing a PC with a PDA (further,
it would be enough for synchronize a small LAN with some PDAs, expecting new
properties to be introduced by several sources). If that were not enough,
one will have to pay the 128-bit price. However, we cannot make 32 bits
URIs, thus my unconformity with URI-only PIDs.

Furthermore, any URI could be used as PID, not only urn:uuid. Therefore, a
fully compliant implementation should be prepared for dealing with longer
UIDs.
On the other hand, if only UIDs were used, they would be able to stored as
128-bit integers (instead of using plain-text).

Of course, by shortening PIDs one is also increasing the collision
probability. This matter should be dealt by the synchronization mechanisms
and/or identifier schemes.

> How about that last idea? Or is it playing with fire for no good reason?

For consistency one should always export the same property instance with the
same identifier. As I understand your proposal, the property identity will
be lost and the "newly generated PID" would be different, thus we are losing
functionality.

One could play around time-based UUIDs (e.g. since this PDA is always "this
PDA", one do not to *store* the node identifier along with each PID... and
we could map the longer node identifier to some shorter sequence) but that
becomes difficult when dealing with identifiers from other sources, other
UUID versions or variants, and other URI used as PID.

Hope that helps (I look forward to continue this exchange.)

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Fri, 11 Apr 2008 14:16:35 -0400

On Friday 11 April 2008 13:25:43 Javier Godoy wrote:
> it would be enough for synchronize a small LAN with some PDAs, expecting
> new properties to be introduced by several sources). If that were not
> enough, one will have to pay the 128-bit price.

Yes, I understand that argument. But 32 bits has 2^96 times higher chance of 
collision than 128. (!!!) In other words, this would make sense if we were 
generating 2^96 times less properties per vCard than the number of vCards 
that exist in the world (to get the same collision chance as UUIDs used for 
vCard UIDs). In other other words, if we have just one single property per 
each vCard in the world, we would need 2^96 generated vCards to keep the same 
odds. That's ~1e19 single-property vCards for everyone on the planet. Bottom 
line: 32 bits is not enough, unless we agree that UUIDs as vCard UIDs is 
already much more than what we need.

> However, we cannot make 32 
> bits URIs, thus my unconformity with URI-only PIDs.

Let's keep the discussion of URI-or-not for later ok? First let's figure out 
what we need to store in that field.

> 128-bit integers (instead of using plain-text).

I'm not following you. You mean using ASCII characters [0-9] instead of 
[0-9a-f]? That's less entropy per character, you're going to need more of 
them!

Surely you don't mean sticking binary in there? ;)

> and/or identifier schemes.

We must think about how to decrease the collision probability. What we're 
leaving up to the implementation is what to do when an actual collision 
happens. (Chances are they won't even know it happened!)

> For consistency one should always export the same property instance with
> the same identifier.

Do you mean hashing the property name + content and sticking that as the PID? 
Hmmm, that might actually make sense! It would collide when the content is 
the same, but that's actually a nice feature.

Let's say we take a 48 bit digest (assuming we determine that 48 bits is 
enough) of the name + content (+ parameters too, the whole unfolded line). We 
could write that in base64 with 8 characters. That's small!

TEL;PID=ifOPCMcL;TYPE=cell:tel:+1-555-555-1234

You can even tell if the property has changed since it was first created. That 
could be useful!

(I used the 48 low bits of a SHA-1 digest in this example.)

> As I understand your proposal, the property identity 
> will be lost and the "newly generated PID" would be different, thus we are
> losing functionality.

I'm really not following you here.

> Hope that helps (I look forward to continue this exchange.)

Sure me too. And I would like to hear from others! ;)
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Sat, 12 Apr 2008 16:43:47 -0300

Simon,

Maybe we should start discussing how much should we care about the 
identifier length... my proposal of shorter PIDs was because we have already 
discussed about UUIDs being too long for that purpose...  (Indeed, I have 
first been inclined towards PIDs as UUIDs, but later I got convinced of the 
opposite...) I think long identifiers will not be a problem in some years 
time, but it seems that avoiding them is a current requirement... isn't it?

On Friday, April 11, 2008 3:16 PM Simon Perreault wrote:

> collision than 128. (!!!)

I'm afraid we have both missed the birthday paradox (at least I had in my 
previous email)

"if more than h^(1/2) people choose independent random integers between
1 and h, there is significant probability that at least two people
will pick a common number." [1]

From the formula below it follows this "significant probability" is 0.3935; 
other authors use around 1.18*h^(1/2) which yields p~0.5
(not what we are looking for... but lower than n/2)

"(...) The conflict probability only depends on the size of the address 
space and the
number of nodes in the network: the larger the address space, the
lower the conflict probability. This probability can be calculated
in analogy to the well-known birthday paradox and is expressed
by (1) with n being the number of nodes and h size of the address
space.

  (1) P = 1- exp(-n)*(1-n/r)^(n-h-0.5)

" [2]

An analysis applying the birthay paradox to 128-bit random strings is given 
by [3]. However the author calculates the 0.5 probability. The subject turns 
rough with lower probabilities.

WHAT FOLLOWS IS MY OWN REASONING, PLEASE VERIFY (mistakes are likely lurking 
there ;-).

For big numbers, (1) cannot be computed without missing significative 
numbers, so we'll have to rewrite it.
(2) is a good approximation whose numerical behaviour is more stable (though 
it is not enough for n=2^33; h=2^128) [4].

(2) 1-exp(-n^2/2/h)

I looked for some other formulation of this problem that could be applied to 
big numbers. I didn't find any, then I gave up searching and tried to make 
one by myself (in the worst case it is wrong, but it serves as an starting 
point ;-)

From (2) we obtain (3), which approximates (4) when p ~ ln (1+p) = - ln 
(1-p). Replacing p = 2^(-P), h= 2^H in (4) we get (5)

 (3) n = (-2h ln (1-p))^{1/2}
 (4) n ~ (2h p)^{1/2} when
 (5) log_2 n ~ (H - P + 1)/2

[1] Weniger. PACMAN: passive autoconfiguration for mobile ad hoc network,
IEEE Journal on Selected Areas in Communications,  pp. 507-519, vol 23(3), 
2005
http://ieeexplore.ieee.org/iel5/49/30451/01402580.pdf

[2] Privacy and authentication: An introduction to cryptography
Diffie, W.; Hellman, M.E.;
Proceedings of the IEEE
Volume 67,  Issue 3,  March 1979 Page(s):397 - 427
http://ieeexplore.ieee.org/iel5/5/31275/01455525.pdf

[3] The Birthday Paradox and Microsoft GUIDs or How I use Mathematica to 
Reassure Myself to Go Back to Sleep at Nights.
http://www.atriumtech.com/pongskorn/birthdayparadox/birthdayparadox.htm

[4] I just found the approximation in Wikipedia. 
http://en.wikipedia.org/wiki/Birthday_paradox
As far as I can compute both of equations (and until significative digits 
are lost), the error is quite small as n<<h. About the reliability of 
Wikipedia on this subject, I found it is referred as "an excellent 
description" by http://mit.edu/6.033/2005/wwwdocs/assignments/crypto.html

> In other words, this would make sense if we were
> vCard UIDs).

Now, when h=2^128 and n=2^33 we have p=2^-63 (P=128-66+1)

> In other other words, if we have just one single property per
> odds. That's ~1e19 single-property vCards for everyone on the planet.

(I assume there is a typo in the exponent, since the more properties we 
have, the more collisions we are blamed for.)

Anyway, if we had just one single property per each vCard in the world we 
would have no collision (unless everyone each vCard on the planet refers to 
the *same* entity)

> Bottom line: 32 bits is not enough, unless we agree that UUIDs as vCard 
> UIDs is

For h=2^32, p=2^-63, we have n=2^-15 (instead of n = 2^-63 ~ 1e-19).

Either 2^-63 is such a low probability we could increase without risk, or 
2^32 are too few bytes (for instance, with 82 bytes one would have 2^10).

// --- end of suspicious part

------

Further note:

Actually, not every bit in every UUID is random: for the Leach-Salz variant, 
that is true only when dealing with random UUIDs; on the other hand, 
hash-based UUIDs depends on the

RFC 4122 version 1 (time-based) UUIDs use
 version and variant (fixed): 6 bits
 timestamp: 60 bits
 sequence: 14 bits
 node identifier: 48 bits

At any given point of time two nodes will generate the same clock value
(I assume the clocks are perfectly shyncronized, though this do not 
invalidates the argument. Anyway, clock numbers are strongly correlated.)

Besides, from RFC 4122, section 4.2.1.2:  [[If UUIDs do not need to be 
frequently generated, the timestamp can simply be the system time multiplied 
by the number of 100-nanosecond intervals per system time interval.]]

---

> what we need to store in that field.

OK.

---

> Surely you don't mean sticking binary in there? ;)

Not when encoding the vCard , but only when *storing* it in some with 
constrained capacity (for instance, an implementation could store an 8-byte 
integer, then create the Base16 encoded UUID when exporting the vCard). 
UUIDs have a compact representation in memory, while supporting "any URI" 
would require additional resources and would be a problem if the storage 
capacity is limited. This comment does NOT affect the specification (since 
the latter does not deal with the implementation), it was only about what we 
could or could not do about PIDs..

Of course, you can create 8-byte hashes from other URIs, but it is not 
possible to recover the original URI from the hash. This argument is not 
enough for discarding other URI schemes, but we should recognize it does 
exists.

Maybe this issue should be discussed later.

---

> happens. (Chances are they won't even know it happened!)

If using 128-bit UIDs + 128-bit PIDs chances are collisions would never 
happen in the humankind  lifespan (unless UUID were intentionally forged, or 
created by buggy implementations... we could address these issues but it not 
necessarily related with the length of the identifiers).

--- 

> the same, but that's actually a nice feature.

No, I didn't (it was related with your idea of only generating IDs when 
copying) ... but it is a nice feature ;-)

> (I used the 48 low bits of a SHA-1 digest in this example.)

I have mixed feelings about this, but it worth the trouble to be considered.
(btw, there are hash-based UUIDs, both SHA-1 and MD5)

> I'm really not following you here.

You have written: [[One shortcut that we could mention in the document: do 
not generate IDs in
 that case. Assume that properties without IDs are never "representations of 
the same object". Only generate IDs when copying (that includes when 
synchronizing).]]

which I understand  as: "a device could delete all PIDs then generate them 
when copying..."

I think I didn't catch your proposal about this issue...

Best Regards

Javier

---

From: <[email-masked]>
Date: Mon, 14 Apr 2008 10:11:31 +0300

Hi Simon,
I am not against having a longer ID - and not in favour of it, either - , but without a registry in place, you have a chance of collission regardless of ID length.
The question is:
 - do we want to allow collission?
 - if we allow collission, what's the point of having unique IDs?
 - if there is a collission, how can we resolve it?
 - if we do not allow collission, who will maintain/handle registry/allocation of the IDs?

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Simon Perreault
>Sent: 11 April, 2008 21:17
>To: [email-masked]
>Subject: [VCARDDAV] Format of PID field
>
>> I think a 32-bit PID is enough for synchronizing a PC with a PDA 
>> (further, it would be enough for synchronize a small LAN with some 
>> PDAs, expecting new properties to be introduced by several sources). 
>> If that were not enough, one will have to pay the 128-bit price.
>
>Yes, I understand that argument. But 32 bits has 2^96 times 
>higher chance of collision than 128. (!!!) In other words, 
>this would make sense if we were generating 2^96 times less 
>properties per vCard than the number of vCards that exist in 
>the world (to get the same collision chance as UUIDs used for 
>vCard UIDs). In other other words, if we have just one single 
>property per each vCard in the world, we would need 2^96 
>generated vCards to keep the same odds. That's ~1e19 
>single-property vCards for everyone on the planet. Bottom
>line: 32 bits is not enough, unless we agree that UUIDs as 
>vCard UIDs is already much more than what we need.
>
>Let's keep the discussion of URI-or-not for later ok? First 
>let's figure out what we need to store in that field.
>
>> On the other hand, if only UIDs were used, they would be able to 
>> stored as 128-bit integers (instead of using plain-text).
>
>I'm not following you. You mean using ASCII characters [0-9] 
>instead of [0-9a-f]? That's less entropy per character, you're 
>going to need more of them!
>
>> probability. This matter should be dealt by the synchronization 
>> mechanisms and/or identifier schemes.
>
>We must think about how to decrease the collision probability. 
>What we're leaving up to the implementation is what to do when 
>an actual collision happens. (Chances are they won't even know 
>it happened!)
>
>> For consistency one should always export the same property instance 
>> with the same identifier.
>
>Hmmm, that might actually make sense! It would collide when 
>the content is the same, but that's actually a nice feature.
>
>enough) of the name + content (+ parameters too, the whole 
>unfolded line). We could write that in base64 with 8 
>characters. That's small!
>
>You can even tell if the property has changed since it was 
>first created. That could be useful!
>
>> As I understand your proposal, the property identity will be 
>lost and 
>> the "newly generated PID" would be different, thus we are losing 
>> functionality.
>

---

From: "Darryl Champagne" <[email-masked]>
Date: Mon, 14 Apr 2008 03:21:13 -0400

Hi,

All of these PID values seem like massive overkill for Synchronization
purposes - which is what I thought was driving this.  For Sync, the primary
use case is to be able to identify which of a couple of parameters have
changed.  That's it - typically just did the first, or the second, or the
third telephone number get changed / deleted, or is this value new since the
last successful sync.  In particular, it matters for the OMA-DS partial
update capability (delete Tel-2).  If you are talking about a roughly 15
character value that gets stored (including + and -, otherwise we are
talking 10+ characters), adding some massive identifier is just not going to
happen on a mobile device.  They don't even store the real type info, they
just stick it into their closest approximation - usually picking just one of
something like Work, Home, Main, Mobile, Fax, Pager (or delete Fax, Pager
and Main, and add email). 

The collision case is only where multiple parties have added a new parameter
of a particular type since a previous successful synchronization, and that
happens to get the same PID value, and _might_ be confused as being two
different versions of the same value, leading to incorrectly discarding one
of them, depending upon the implementation.  I stress might, because many
implementations can be configured to keep all values anyway.  Also, I stress
that users are actually doing this, usually for a reason, and do not
generally add a large amount of random data - these parameters have meanings
- like someone's phone number.

In any of the implementations that I have been involved in, this can only
apply if this also occurs when the synchronizations also occur through a
third party, never directly - because there is no point in assigning an ID
until after you have either received or sent the record to someone else.
Also note that in almost all three-party synchronizations that occur today,
there are major problems due to incompatible mappings already, since few
implementations store the actual vCard.  Realistically, an 8-BIT value is
likely good-enough for the use cases I have seen.  99% of the time that a
value is added to both sides in a sync, it was because the user tried to add
the same value through two different UIs, and the only conflict is that one
side gives it one type, while the other side gives it a different type, or
that one UI put a +1 in, and the other side didn't, and the application
needs to intelligently merge them anyway.

E.g.
The vCard is originally created on party A with Tel-1, and Tel-2, and is
synchronized between two parties A & B, where B is a very limited device,
like a phone - and definitely does not store the full vCard, UUID, etc.
Party A adds a Tel, and Party B adds a Tel.
Party A syncs with Party C, and thus assigns its new Tel value as Tel-3.
Party B also syncs with Party C, and thus assigns its new Tel Value as
Tel-3.

Party C is now in the situation of having received a vCard from party B,
which is extremely limited - holding just what parts the mobile device chose
to keep, and party C now has to first detect that these 2 records are in
fact the same identity, and then would get a conflict for Tel-3, and have to
pick which value it uses, whereas it should have kept both.

If instead of going through Party C, parties A & B did a sync, then when
party B sends its record to party A (most syncs have the clients send to the
servers), party B's Tel-3 would be received, and party A would then add it's
Tel as Tel-4, and send that change back to party B, and there would be no
conflict - even just by using consecutive numbers, not even a random 8 bit
value (which can be checked to ensure there is no match with any existing
values - so it is not a regular Birthday issue).

Now, sure, it is theoretically possible to go through many parties, all of
whom keep the full vCard info, and you want to merge values added multiple
places along some long chain of pairwise-syncs, but that isn't realistic.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Javier Godoy
> Sent: Saturday, April 12, 2008 3:44 PM
> To: Simon Perreault; [email-masked]
> Subject: Re: [VCARDDAV] Format of PID field
> 
> 
> with

Using any kind of Hash of contents value defeats the purpose of using it for
Synchronization (unless you propose to only send the PID).  For sync, I want
to say that I am changing the property that _used_ to have a particular
value, into a different value, or no value at all.  If the identifier
relates to the current value, that use is lost.

The best use case for hash values in sync is to be able to send the hash
value instead of the actual data - so it is meaningless unless the size of
the hash is significantly smaller than the size of the data (like a hash
value for the entire vCard).

> > enough) of the name + content (+ parameters too, the whole unfolded
> line).
> > We
> > You can even tell if the property has changed since it was first
created.
> > That

No, see the example above.  Only values created since the last successful
sync matter.  If a device lost all PIDs, it presumably lost the sync anchor
of when it had a last successful sync as well, and someone is doing an
initial sync, checking everything for duplicates - and no UUID has been
preserved either.

> I think I didn't catch your proposal about this issue...

Thanks,
dgc
--
Darryl G. Champagne
Technology Evangelist
Funambol
Vice-Chair, OMA-DS
[email-masked]          http://www.funambol.com

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2008 07:30:21 -0400

> I am not against having a longer ID - and not in favour of it, either - , but without a registry in place, you have a chance of collission regardless of ID length.

Are you saying that we should worry about collisions despite uniqueness 
guarantees such as those in UUID (i.e. time and name-based generation 
algorithms) combined with a large enough address space?

>  - do we want to allow collission?

I think it's unavoidable.

>  - if we allow collission, what's the point of having unique IDs?

 From an engineering point of view, we want to make them so extremely 
unlikely that we can just ignore that possibility.

>  - if there is a collission, how can we resolve it?

How would you distinguish a collision and a correct match?

>  - if we do not allow collission, who will maintain/handle registry/allocation of the IDs?

I think I can safely say that there will be no such registry.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2008 07:46:14 -0400

> needs to intelligently merge them anyway.

I don't get it. Here's a very simple, two-device use case that will 
break incrementing PIDs:

dev1 and dev2 are synchronized with TEL;PID=1:blah1.
dev1 adds TEL;PID=2:blah2.
dev2 adds TEL;PID=2:blah3.
dev1 and dev2 sync.

If the implementations rely on the value of PID (let's not even consider 
the others because they basically choose to ignore what we're currently 
designing), they will mistakenly associate the two new properties as 
being the same, and one of the values will overwrite the other, 
depending on the direction of the sync.

Ok, here's a new proposition: PID could have an opaque string value that 
could be compared for identity with others but nothing more. 
Implementations would be free to assign whatever content they wish to 
that PID. Then someone could write an informational RFC on the ways of 
creating a PID value.

> relates to the current value, that use is lost.

Exactly. It was implied that you would use the hash for initial creation 
of the PID, but the PID would remain intact across modifications.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Darryl Champagne" <[email-masked]>
Date: Mon, 14 Apr 2008 15:57:17 -0400

That ignores my precondition:
"because there is no point in assigning an ID until after you have either
received or sent the record to someone else."

Therefore the scenario you describe is instead:

dev1 and dev2 are synchronized with TEL;PID=1:blah1. - Also note this is not
sufficient granularity - it was created on just one side, and sent to the
other.  Sync cannot occur without 2 separate data transfers (even if the
second one is just a status that says the original data is correct).

dev1 adds TEL;blah2.
dev2 adds TEL;blah3.

dev1 and dev2 sync - which has to be done in stages - dev1 sends its copy to
dev2, at which point it time it assigns TEL;PID-2:blah2, while dev2 still
has no PID on its new TEL.  When dev2 receives PID-2, it knows to create a
new PID with something other than 1 or 2.  Therefore it sends back
TEL;PID=3;blah3, and there is no problem at all.

dgc

> Behalf Of Simon Perreault
> Sent: Monday, April 14, 2008 7:46 AM
> To: [email-masked]
> >>> Do you mean hashing the property name + content and sticking that as
> the
> >>> PID?
> >>> Hmmm, that might actually make sense! It would collide when the
> content
> >> is

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 14 Apr 2008 16:10:58 -0400

Hi Darryl,

--On April 14, 2008 3:57:17 PM -0400 Darryl Champagne <[email-masked]> 
wrote:

> dev1 and dev2 are synchronized with TEL;PID=1:blah1. - Also note this is
> not sufficient granularity - it was created on just one side, and sent to
> the other.  Sync cannot occur without 2 separate data transfers (even if
> the second one is just a status that says the original data is correct).
>
> dev1 adds TEL;blah2.
> dev2 adds TEL;blah3.
>
> dev1 and dev2 sync - which has to be done in stages - dev1 sends its copy
> to dev2, at which point it time it assigns TEL;PID-2:blah2, while dev2
> still has no PID on its new TEL.  When dev2 receives PID-2, it knows to
> create a new PID with something other than 1 or 2.  Therefore it sends
> back TEL;PID=3;blah3, and there is no problem at all.

Well maybe for the two client case, but as soon as you add a third client, 
this breaks down. e.g. in your scenario if dev1 had sync'd its change with 
dev3 (who had the same starting state as the other two and did not make any 
changes) the dev1 would have assigned pid=2 to the new item, so that when 
the change from dev2 came it it would have overwritten the tel property 
rather than added it.

Note though that this depends on the order in which the sync is done 
between dev1 and dev2. In your example you had dev2 send its change to dev1 
first. If it had been the other way around, then the correct behavior would 
have happened - two new tel's would appear on all clients.

But clearly we cannot depend on the order in which these exchanges are made.

-- 
Cyrus Daboo

---

From: "Darryl Champagne" <[email-masked]>
Date: Mon, 14 Apr 2008 17:23:15 -0400

Umm, Yes, which is exactly what I said in the email before that one (Mon
4/14/2008 3:21 AM EST)...

"soon as you add a third client, this breaks down."
Vs.
"this can only apply if this also occurs when the synchronizations also
occur through a third party"

And I'll also reiterate:
"Also, I stress that users are actually doing this, usually for a reason,
and do not generally add a large amount of random data - these parameters
have meanings - like someone's phone number.", and
"99% of the time that a value is added to both sides in a sync, it was
because the user tried to add the same value through two different UIs, and
the only conflict is that one side gives it one type, while the other side
gives it a different type, or that one UI put a +1 in, and the other side
didn't, ..."

And I'll also remind people that as soon as you add a third client, most of
the time today things blow-up horribly, because each pair-wise combo maps
their internal data into transport vCards differently - just use SyncML
between any two points, and then run Hotsync or Activesync, and watch
everything double, or otherwise get really screwed up...

We are talking about scenarios where multiple address books are in sync, and
between syncs, the same type of information is added in multiple places.
This is almost always because it actually is the same information - it is
rather rare for me to get 2 mobile numbers at the same time, and give one
out to a person's device, and a different one out to the person's portal
application (Facebook, or the group secretary, or whatever).  Sure, it can
happen, but let's be realistic - I don't go through dozens of phone numbers
per year, and I don't beam a different "new" phone number to a person's
device from what I enter in a portal app that the person has access to.  And
if a different number got entered in each place, probably one of them has a
typo, and we can't tell which...

Now, sure, we can theorize about pathological cases, where I don't sync
something during the time that someone changed jobs multiple times, but then
we are trying to sync things from rather different eras, and dates and such
should matter...

I think if we try for absolute correctness, it will be absolutely unused by
lower capability devices - e.g. the vast majority of which still refuse to
use vCard 3.0, or iCal.  Impose a significant memory burden, and forget
getting them to upgrade.

dgc

> From: Cyrus Daboo [mailto:[email-masked]]
> Sent: Monday, April 14, 2008 4:11 PM
> To: Darryl Champagne; 'Simon Perreault'; [email-masked]

---

From: Aki Niemi <[email-masked]>
Date: Tue, 15 Apr 2008 12:57:06 +0300

> could be compared for identity with others but nothing more.

Sort of like the property value itself? ;-)

I don't see the point in trying to device uniqueness into the fields
beyond the actual data carried in the field.

If I understood the problem statement correctly in the last meeting, the
problem is mainly with information loss, i.e., syncing devices drop
parameters they don't understand or use themselves. This ambiguates the
changes made, which causes all sorts of problems in the reverse
direction.

But IMHO, this behavior is a bug in the implementation, not in the
specification. If all syncing parties retained all information so that
deletions or additions are all explicit and unambiguous, then I don't
see the problem.

Further more, if efficient syncing is required, then I'd think that a
diff format would be enough, as I think Cyrus was proposing as an
alternative.

Cheers,
Aki

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2008 06:59:38 -0400

> Sort of like the property value itself? ;-)

No, because the PID remains constance once it is created while the 
property value may change.

> changes made, which causes all sorts of problems in the reverse

That's not the problem we're trying to fix with PIDs.

The synchronization problem is that devices, looking at two vCards to be 
synchronized, have no clue as to which property in vCard 1 is the same 
property in vCard 2. They then just merge the two vCards by 
concatenating them. When the device knows that prop 1 is tied to prop 2, 
they can just overwrite one of them with the other, depending on the 
direction of the merge. That's new info we want to provide to the 
synchronization engine with PIDs. Otherwise it's just heuristics.

> deletions or additions are all explicit and unambiguous, then I don't

You're right, and at the moment there are no propositions for fixing 
that in vCard.

> diff format would be enough, as I think Cyrus was proposing as an

Yes, I'd like to hear more on that from the OMA folks. A device would 
retain the data from the last sync along with the current version. When 
syncing, it would generate a diff and send that to the server using OMA. 
What is wrong with that?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Tue, 15 Apr 2008 08:14:08 -0300

Hi Aki,

> changes made, which causes all sorts of problems in the reverse

This remembers me of a requirement in Section 8.1: "A missing UID property 
MUST NOT be considered equivalent to any other. Hence, the UID parameter 
MUST be present if synchronization is to be used."

I think "SHOULD NOT ... SHOULD" would better describe the situation where 
"intelligent merges" treat two properties as equivalent, even though one of 
them has no PID, or if no PID is present at all.

> deletions or additions are all explicit and unambiguous, then I don't

I agree, but it is a bug that implementors actually want (because vCard 3.0 
fails to address their requirements).

IIRC, vCard 2.0 had defined MAY/MUST requirements for "vCard readers" and 
"vCard writers", about each property type (e.g. vCard readers MUST 
understand the XXX property, vCard writers MAY generate the XXX property). 
IMHO, some statements in that direction may help (at least you will know 
what will be preserved by a "good" implementation, and you will be aware of 
possible loss of information).

Best Regards

Javier

---

From: Aki Niemi <[email-masked]>
Date: Tue, 15 Apr 2008 15:07:30 +0300

On ti, 2008-04-15 at 06:59 -0400, ext Simon Perreault wrote:
> property in vCard 2. 

Can you give an example where this matching is overly complicated just
based on the property alone, without any additional unique parameters?

> They then just merge the two vCards by 

And if both parties modified the same property, then it would be human
intervention time or up to the clever heuristics in any case.

So instead of looking at the property *value* for a match, you come up
with another must-implement parameter that needs to be compared for
finding a match? I find that of dubious value given how much cruft it
brings to the format.

I'm sorry, but:

     BEGIN:VCARD
     VERSION:4.0
     UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da
     FN;UID="urn:uuid:dade7896-81bd-4a3c-950e-bdfc04f15b61":Jane Doe
     EMAIL;UID="urn:uuid:69531f4a-c34d-4a1e-8922-bd38a9476a53":
      [email-masked]
     EMAIL;UID="urn:uuid:48a28f93-d4a4-4430-a7c6-a784ecb3f865":
      [email-masked]
     END:VCARD

is just nauseating to look at, and the S/N ratio is horrible. Especially
since a simple string comparison would work equally well in all of these
properties.

You really need to come up with better justification than this.

> You're right, and at the moment there are no propositions for fixing 

Good, because there's nothing to fix. :)

Cheers,
Aki

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2008 08:57:51 -0400

> based on the property alone, without any additional unique parameters?

Well, that's simple:

PROP:value1

PROP:value2

Are they tied or not? If they are, then that means that one of them was 
modified. In a sync, you would propagate the modification, giving 
something like

PROP:value2

PROP:value2

If they are not tied, then you would concatenate them, giving

PROP:value1
PROP:value2

PROP:value1
PROP:value2

> intervention time or up to the clever heuristics in any case.

Yes, absolutely.

> finding a match? I find that of dubious value given how much cruft it

I'm interested in how you would resolve the above example without PIDs.

> is just nauseating to look at, and the S/N ratio is horrible.

ABSOLUTELY! I wrote something down because that's the best way to get 
people to react and produce ideas.

> Especially

No. See above example.

> You really need to come up with better justification than this.

I'm sorry, it doesn't work this way. I'm not trying to get approval for 
my propositions. I'm trying to get to a consensus, which means 
understanding what people want. If you don't want that, please suggest 
an alternative.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Aki Niemi <[email-masked]>
Date: Tue, 15 Apr 2008 18:23:45 +0300

> modified. In a sync, you would propagate the modification, giving 

What do you mean tied? If instead of PROP you were using a real
property, this might be self-evident. For instance, I would expect N or
FN properties to be "tied".

<snip>
> I'm interested in how you would resolve the above example without PIDs.

Hmm... The synchronization protocol I use daily seems to work fine
without PIDs. So I don't quite see what there is to solve.

> understanding what people want. If you don't want that, please suggest 

My alternative is not to add the feature. 

It's not clear what problem it is trying to solve. We're not designing a
sync protocol here. For instance, rsync or any other delta encoding
works on plain text files just fine.

Oh, and the PIDs are only capable of recognizing that a specific element
was modified or added; to detect it was deleted would require
maintaining a copy of all the PIDs that ever appeared in a vcard with
some DELETED parameter, NULL value or some other exotic extension.

Please, let's focus on the format and not design a poor man's delta
encoding scheme or sync protocol.

Cheers,
Aki

---

From: "Chris Bryant" <[email-masked]>
Date: Tue, 15 Apr 2008 11:51:27 -0400

> Simon Perreault wrote:
Can you give a better example, using an actual property?  I think what you 
are intending is something like:

TEL:value1
TEL:value2

but when you have simple items like this, there really should be some 
additional distinguisher, like:

TEL;TYPE=WORK:value1
TEL:TYPE=HOME:value2

So you really need to show examples where there would be duplicates using 
the existing parameters.

I don't like the idea of attaching any kind of unique id to every attribute.

I think that if two applications each have a single idea of a contact's home 
telephone number, then there is no issue.  There only seems to be a problem 
when one application has multiple values for an attribute and another 
application has only one value.  Maybe we could find some additional 
parameters to better define these few cases where people will actually have 
multiples that can't be distinguished with the current parameters.  What 
attributes are we really having issues with?  I would guess EMAIL, TEL, and 
IM, but are there more?

Chris

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2008 11:58:47 -0400

On Tuesday 15 April 2008 11:23:45 you wrote:
> What do you mean tied?

Here's what I mean by "tied": they stem from the same single property 
instance. For example, they could be tied if the second property is a copy 
from the first which got modified on the second device. They would not be 
tied if they were created independently on two different devices.

> If instead of PROP you were using a real 

Here's the same example with real property names and values:

EMAIL:[email-masked]

EMAIL:[email-masked]

EMAIL:[email-masked]

EMAIL:[email-masked]

EMAIL:[email-masked]
EMAIL:[email-masked]

EMAIL:[email-masked]
EMAIL:[email-masked]

> without PIDs. So I don't quite see what there is to solve.

Does it work by sending diffs then?

> works on plain text files just fine.

That's because you're thinking in terms of diffs. It seemed clear at one point 
that PIDs were needed instead of diffs, but I don't quite remember the 
argument. The more we delve into PIDs, the more I think diffs would be 
simpler (and outside the scope of vCard).

> some DELETED parameter, NULL value or some other exotic extension.

You're right, that's a very important limitation.

> encoding scheme or sync protocol.

Here's what I *think* the argument pushing for PIDs was: since devices mangle 
values and parameters because they, as a rule, don't conply with the spec, 
the OMA folks wanted to refer to particular properties by using PIDs in their 
partial update (let's call this diff from now one because that's really what 
it is) protocol. So you'd get messages like

<delete>
	<prop>EMAIL</prop>
	<pid>1</prop>
</delete>

instead of

<delete>
	<prop>EMAIL:[email-masked]</prop>
</delete>

Is that what the initial motivation was?

If so, I think this discussion has made clear that PIDs are a bad idea and not 
a fix for not complying with the spec.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Darryl Champagne" <[email-masked]>
Date: Tue, 15 Apr 2008 21:19:02 -0400

Here is one OMA opinion - diffs would suck if they were required...

> Sent: Tuesday, April 15, 2008 7:00 AM
> To: [email-masked]

A delta format is great is you are going from a known state to a new common
state.  They suck horribly if you want to go from any of the last dozen
changes to some new merged state or from some unknown state to a new merged
state without a large increase in storage.

The only way a delta would work reliably is if every sync client and server
kept a pretty big set of version control info.

E.g. I have a server (e.g., at an ISP), which syncs to a number of different
clients - all the user's devices, including their PC applications, and even
some other portal apps (e.g social).

I (the user) sync regularly between the server and the PC, whenever the PC
is online.  My handheld device syncs moderately regularly when I am in my
home network, but I don't let it do that while I'm roaming.

Additionally, I one way sync (in) my device to other servers sporadically,
such as to a corporate global address book.

So if I'm on the road for a while, entering contact info for the people I
meet, my server is at version N-1, my PC is at version N, my handheld is at
N-10, and the client & PC are both 30 days behind the corporate address book
(on a different server).

Now how much information are each of these implementations supposed to
store, beyond just the current info being displayed?  The server has to
scale to support large numbers, and the clients are extremely limited - if
each vCard required storing an extra vCards worth of data that frequently
means I can only have half as many vCards...

Today, with OMA-DS, I could store an ordered list flagging the changes that
have occurred over time (or I store a last modified date per object, and
search on that).  Storage requirements would be both the time and however
many internal IDs (e.g. an integer per change), or the time and the ID
modified to hold some minor state info like the Tel changed versus the Addr,
or a time value per object plus search cost.

When my server goes to sync to something, that something gives me its sync
anchor, which tells me where in that ordered list/whatever I should go, to
send all records from that point in time until now that I should sync with
that device.  If I kept extra state info (e.g. 4 bits), I could choose to
send a partial record, such as just the current set of telephone numbers.

Now, since my server is responsible for communicating with 6 digit (or
occasionally higher) numbers of clients (fortunately, many of which do not
sync very frequently), it matters a lot to me to just store a single integer
per change (especially since OMA-DS also supports arbitrary objects - emails
with large attachments, file systems, whatever).  Some implementations may
want to store the full history, and support roll-back to any date as a
feature, and that is great - but that cannot be required of all of them.

Now, if all I know is that the TEL (or just TEL;WORK) numbers in this vCard
have changed since the last time, and 3 TEL's of a particular type are sent,
the other side needs to figure out which previous TEL/Email whatever has
changed - and the user wants it done consistently - so if the list of tel's
was 3 numbers in order, and the first one (which has been configured solely
with the internal device UI - not data stored in the vCard, and not ever
sent off the device, and maybe it is flagged in red or something) has been
changed to something new, the display will now show the first one as
something different, and if the 2nd one was deleted, that slot in the UI is
now blank, while the 3rd number stays in the 3rd UI position.  Also, it can
be different between a PC and phone 1 and phone 2 - the order of the numbers
is NOT what is important here - it is the association between whatever was
done in that slot in that device before, so if Tel-2 is changed, the new
Tel-2 is recognized as using the old Tel-2's extra info.

--
Additionally, getting back to uniqueness, my uniqueness requirements are
based on how many objects of the identical type occur in a single vCard, and
how many of times the number is increased - which is extremely limited.
Based upon some of the vCards I have (about 800, which I have kept for up to
15 years), the number of times I have increased the number (as opposed to
re-use a prior slot) - so we are talking about the maximum number of items I
have ever kept in a single vCard, is something like 8 - where I kept old
email addresses for people until all the emails from that address has aged
out to my archive system.  This is also a techie's address book.
Salespeople typically have more objects, but keep less data in each (old
info is tossed more quickly). 

That means for a single vCard, over 15 years, at most I added 4 objects of
the same type over what was there before - and almost all of those were
added on the same system, and thus have no conflict possibilities, and
almost always these were widely spaced in time, and thus also not an issue.
If our uniqueness criteria can prevent 2 new objects each added to 2
separate systems from getting new PIDs most of the time, then that is
sufficiently unique to have met my requirements over the lifetime of the
vCard (and remember, when I add the 2nd object to a particular system, it
knows to avoid the other IDs already on that system).

Since this is the Max, which only has happened for a couple of the vCards -
if we can prevent a duplicate value from being selected for 4 of 800 vCards,
perhaps for a couple of fields, where 2 values were selected from a pool
without duplicating 2 other new values, that is adequately unique.  For 256
values, the odds were something like (256-4-2)/(256-4) (selecting a new 5th
value which does not conflict with 2 other new values) * 249/251 (selecting
a new 6th value) ** (nVcards=4 * nFields=2).  I get an 88% chance of not
incurring a collision for my use case with just 256 values (12% possible
collision).  From approximation. for 16 bits, this drops to 4.7 * 10**-4,
for 32 bits, to 7.15 * 10**-9 of a single collision for a given user over 15
years (actually, for 32 bits it is 2.56*10**-9, but that's close enough).

AND that is assuming I do all my syncs through 3 parties (which is very rare
- since it fails for most current implementations any), since 2 party syncs
do not show the issue.  Even for where they successfully work, it still
requires a three party sync to occur in just the right direction to fail
during the time interval of creating new objects in multiple locations, so
realistically I would drop the odds to less than 1% of the above (probably
way less).

And even beyond that, collisions are not even that big of a deal - most
implementations would take a conflict and apply heuristics anyway (like they
have to do in many other situations).  I personally am fine with the 8 bit
option - a 12% chance of collision reduced by the rarity of doing three
party syncs - a well under 1% chance of a single collision (itself a minor
issue) once per lifetime per power user...

Even if 100 users of the ISP hit it per year, since there a 10's of
thousands of them doing major screw-ups all on their own (like letting their
little kid play with their device, and then syncing, and being surprised at
all the random junk or deletions that shows up), and the issue is generally
mild, I just would not worry about it - give me a random number from 1-256,
excluding any number already in use, and I would be fine - make it 16 bits
just to allow someone to have more than 256 emails in a single vCard, and it
has been more than satisfied. 

Dgc
OMA-DS Vice-chair

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Apr 2008 15:41:33 -0400

> means I can only have half as many vCards...

Is this really a limitation? Would just storing the original plus the diff 
solve it?

> have changed since the last time, and 3 TEL's of a particular type are
> sent, the other side needs to figure out which previous TEL/Email whatever
> has changed - and the user wants it done consistently - so if the list of
> tel's was 3 numbers in order, and the first one (which has been configured
> solely with the internal device UI - not data stored in the vCard, and not
> ever sent off the device, and maybe it is flagged in red or something) has
> been changed to something new, the display will now show the first one as
> be different between a PC and phone 1 and phone 2 - the order of the
> numbers is NOT what is important here - it is the association between
> whatever was done in that slot in that device before, so if Tel-2 is
> changed, the new Tel-2 is recognized as using the old Tel-2's extra info.

I'm sorry, I tried reading many times your example but I fail to see the 
point. Can you constrain it to the minimum number of devices necessary to 
explain why PIDs are desirable?

Meanwhile, here's a counter-example. Take your vCard and stick it into a 
distributed source code versioning system (e.g. git is all the rage 
nowadays). There's your PID-less sync protocol.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Darryl Champagne" <[email-masked]>
Date: Wed, 16 Apr 2008 20:36:28 -0400

> Sent: Wednesday, April 16, 2008 3:42 PM
> To: [email-masked]

First, most clients do not store a vCard at all - they store the vCard
mapped into their internal formal (including Outlook, Lotus Notes, etc.).
If it isn't open source, it probably does not have a actual vCard stored in
it. Phones also have a number of internal applications, which they are not
willing to change without compelling reasons, so if they don't have a clean
API that would hide any versioning stuff, it would be required to only store
the current value, with diffs backward.  Kind of a trivial difference, but
just to keep terminology straight.

Second, diff against what version?  As shown in the previous email, the
clients were syncing against multiple servers, so you need a diff for the
last known state of every server.  So no, just storing a single diff would
not take care of it.

Third, the original statement above is essentially a truism - if they store
twice as much data per entry, they will only have half as many possible
entries.  So any debate is more about how much extra data are you talking
about.  The cost of having diffs against just a couple of contacts, versus a
fixed 4 bytes per entry can easily balance out depending upon the exact
details.  The real difference is between a fixed allocation scheme vs.
variable.  The former has a smaller code size, and always works.  The latter
has a slightly larger code base, and runtime cost (slightly less battery
life), and a variable failure mode - as limited devices do run out of
memory.  

Now, I personally could care less about the difference - since syncing a
large number of contacts over the air usually takes longer than batteries
last, but these are marketing numbers, just like the exact number of minutes
of battery life is.  Every minute of battery life that can be optimized
matters, so there is a general preference towards fixed allocation, limiting
the use of pointers, accessing fewer regions of memory (= how much has to be
powered up), and so on. There is also a ridiculous amount of legacy software
on many of the phone manufacturers systems that things have to work with
(Like 6 year old sync clients that have only had trivial tweaks for the
latest device).  How much any of this matters, I can't say - it depends upon
the exact device - but it does matter at times.

dgc

---

From: "Darryl Champagne" <[email-masked]>
Date: Wed, 16 Apr 2008 20:36:42 -0400

> > Now, if all I know is that the TEL (or just TEL;WORK) numbers in this
...
> explain why PIDs are desirable?

Take 2 devices.  A Phone, and a PC running Outlook.
Also allow for additional devices, such as my wife syncing her entries with
me. 

In both systems I have 2 work phone numbers:
If I export to vCard from Outlook, I get a vCard 2.1 that includes for
telephones:
TEL;WORK;VOICE:603 440-xx21
TEL;WORK;VOICE:(603) 325-xx37

Note I do not condone, forgive, or justify any part of this, including the
lack of export of vCard 3.0 support.  Realistically, most Sync Clients for
Outlook bypass all that junk, and directly access the internal data, and
create their own private vCards, and keep whatever private data they need.

In the Outlook User Interface, it shows these:

Business: 603 440-xx21
Business 2: (603) 325-xx37

The user interface contains a drop down box containing the word
Business/Business2/Mobile/16_other_choices for any of the 4 user interface
positions.  Note that Outlook only allows one of each of the possible 19
descriptors.  In other words, since Business and Business2 are the only ones
that say Business, I cannot have a Business3 - I must pick something else.
This leads to each sync client implementation picking its own choice for the
third work number, but that is its own problem.

On my Phone, I have a list of all phone numbers.
I have an entry with my Name, 
It has an entry labeled Work, which is 603 440-xx21, and has speed-dial
position 6.
It has a second entry labeled Work, which is (603) 325-xx37, and has
speed-dial position 7.

For reference, each user interface position has a choice of 1 of 6: Work,
Home, Main, Mobile, Fax, or Pager, and duplicates are allowed - so I can
have any number of work numbers.

Now, suppose I switch companies.  The two work numbers will now have to
change.

When I change the numbers, I want the Business Number in Outlook (this is my
personal machine) to continue to have Speed-dial position 6 on my phone, and
the Business2 number in Outlook to continue to have Speed-dial position 7 on
my phone.  I do not want the software picking some new random association
for me, and I do not want to have to change my phone dialing habits.  I
personally consider Business as my main number, and Business 2 as an
alternate.

I do not know of any current attribute that would conveniently handle
speed-dial position, and even if there is one, it is not exactly a globally
unique value, and is unlikely to be what my wife wants.

I do not know of any good attribute for Business vs. Business2 in the
Outlook user interface, other than adding a simple PID. 

IF we allow the vCard to contain something on the order of:
TEL;WORK;VOICE;PID=1:603 440-xx21
TEL;WORK;VOICE;PID=2:(603) 325-xx37

Then receiving an update with:

TEL;WORK;VOICE;PID=1:603 555-xx21
TEL;WORK;VOICE;PID=2:(603) 555-xx37

Will keep the mapping (in whichever direction it is sent).  PID=1 will have
speed-dial position 6 on the phone, and be listed as Business in Outlook,
and PID=2 will have speed-dial position 7 of the phone, and be listed as
Business2 in Outlook.

That is an example of the extra, local to the device information that needs
to be preserved.  I do not expect it to be stuck into a vCard.  If it's not
preserved, then I will get some random order, such as listing entries in the
last edited order (or picking the next available speed dial number, based
upon doing a delete and an add), and I as the user will not be pleased.
Unfortunately, certain of these products do have an actual significant
market presence, and have to be dealt with.

dgc

---

From: "Darryl Champagne" <[email-masked]>
Date: Wed, 16 Apr 2008 20:37:19 -0400

> nowadays). There's your PID-less sync protocol.

Umm, are you really serious?
That's a fine technical solution, and works fine for a university, but are
you expecting some master registry to be accepted by everyone?  Or separate
registries/git systems for each "owner" of contact info?  That I would be
able to point my corporate Blackberry at my home server/system as the
official source of my contact info?  That my corporate network would allow
any sharing at all with outside sources?  Sync my phone with my house to get
my contact info, and also to a corporate VPN to get the global address book?
That I would be able to tell my mother how to update/sync my contact book
entry on her PC?

I know some of the places I have worked at anything like that would have
corporate IT screaming, and cursing the day that I got enough manager's
signatures to even be allowed admin rights on my Laptop.  We need solutions
such that random consumers can install software, hit a sync button, and
actually have it work.

Also, do you have any idea the resource issues of having a system support 6
and 7 figure numbers of users?  Those are the number of users in a typical
carrier or ISP deployment - its one thing to say it is distributed, but
someone still has to install the software, and provide the resources, and
that ain't free.

dgc

---

From: Mark Paterson <[email-masked]>
Date: Thu, 17 Apr 2008 10:31:49 -0400

>> Some comments on the new calendar section

7.9.  Calendar Properties

   These properties are further specified in [RFC2739].

7.9.1.  FBURL

   Purpose:  To specify the URI for a user's busy time in a vCard
      object.

   Value type:  A single URI value.

   Special notes:  Where multiple FBURL properties are specified, the
      default FBURL property is indicated with the PREF parameter.  The
      FTP or HTTP type of URI points to an iCalendar object associated
      with a snapshot of the last six weeks of the user's busy time
      data.  If the iCalendar object is represented as a file or
      document, it's file type should be "ifb".

   Examples:

     FBURL;PREF:http://www.example.com/busy/janedoe
     FBURL:FTP://ftp.example.com/busy/project-a.ifb

7.9.2.  CALADRURI

   Purpose:  To specify the location to which an event request should be
      sent for the user.

   Value type:  A single URI value.

 >> We should instead use "single URI.  The type of the URI indicates the
      protocol that can be used for the event request" as is done for IMPP

   Special notes:  Where multiple CALADRURI properties are specified,
      the default CALADRURI property is indicated with the PREF
      parameter.

   Example:

     CALADRURI;PREF:mailto:[email-masked]

 >> We should have a CalDAV-SCHED example

7.9.3.  CAPURI

   Purpose:  To specify a protocol independent location from which a
      calendaring and scheduling client (i.e., CUA) can communicate with
      a user's entire calendar.

   Value type:  A single URI value.

   Special notes:  Where multiple CAPURI properties are specified, the
      default CAPURI property is indicated with the PREF parameter.

 >> Although it claims that this is for a protocol location it was 
clearly meant for CAP and CAP was switched over the the experimental 
track so I'd suggest that this property is not needed.

7.9.4.  CALURI

   Purpose:  To specify the URI for a user's calendar in a vCard object.

   Value type:  A single URI value.

   Special notes:  Where multiple CALURI properties are specified, the
      default CALURI property is indicated with the PREF parameter.  The
      property should contain a URI pointing to an iCalendar object
      associated with a snapshot of the user's calendar store.  If the
      iCalendar object is represented as a file or document, it's file
      type should be "ics".

   Examples:

     CALURI;PREF:http://cal.example.com/calA
     CALURI:ftp://ftp.example.com/calA.ics

 >> We should have a CalDAV example

Thanks,
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: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 21 Apr 2008 10:51:40 +0200

Hi Simon,

>       in the WGS 84 reference system.

Maybe i'm overlooking it somewhere else, but section 5.5.2 does not
contain corresponding text. Also, A full text search over the -01 draft
does not yield a single match for "WGS"...

thanks

Alex

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Apr 2008 09:53:08 -0400

>       protocol that can be used for the event request" as is done for IMPP

I think it's redundant. Obviously you need to interpret the URI scheme if 
you're going to use it.

I instead removed that useless text from IMPP.

>  >> We should have a CalDAV-SCHED example

Yes, how about this?

CALADRURI:http://example.com/calendar/jdoe

> track so I'd suggest that this property is not needed.

Agreed. Removed.

>  >> We should have a CalDAV example

The first URI is indistinguishable from a CalDAV URI.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Apr 2008 10:45:09 -0400

> does not yield a single match for "WGS"...

Are you sure you're looking at the right document? It's 
draft-ietf-vcarddav-vcardrev-01. Note the "ietf" instead of "resnick" (we 
were upgraded).
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 21 Apr 2008 16:48:36 +0200

> draft-ietf-vcarddav-vcardrev-01. Note the "ietf" instead of 

oops. You're right, i looked at the individual draft, not the WG item.
Sorry for the hassle.

Alex