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

From: [email-masked]
Date: Wed, 25 Jun 2008 04:45: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)       : S. Perreault, P. Resnick
	Filename        : draft-ietf-vcarddav-vcardrev-02.txt
	Pages           : 64
	Date            : 2008-06-25

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-02.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, 25 Jun 2008 08:09:13 -0400

Here's the log of changes:

   o  Removed useless text in IMPP description.

   o  Added CalDAV-SCHED example to CALADRURI.

   o  Removed CAPURI property.

   o  Dashes in dates and colons in times are now mandatory.

   o  Allow for dates such as 2008 and 2008-05 and times such as 07 and
      07:54.

   o  Removed inline vCard value.

   o  Made AGENT only accept URI references instead of inline vCards.

   o  Added the MEMBER property.

   o  Renamed the UID parameter to PID.

   o  Changed the value type of the PID parameter to "a small integer."

   o  Changed the presence of UID and PID when synchronization is to be
      used from MUST to SHOULD.

   o  Added the RELATED (Section 7.6.7) property.

   o  Fixed many ABNF typos (issue #252).

   o  Changed formatting of ABNF comments to make them easier to read
      (issue #226).

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 25 Jun 2008 09:46:18 -0300

>   Added the RELATED (Section 7.6.7) property.

I would suggest replacing the AGENT property by a type of RELATED, since 
"agent" is a particular kind of relation, which may be described by the 
RELATED property.

The only difference with this approach (RELATED;type=agent) is that it will 
not be possible to "reset the value to single text". Do we really need this 
feature? (currently, RELATED only allows URI). If text values are required 
for AGENT, I think it will also be required for RELATED.

> Allow for dates such as 2008 and 2008-05 and times such as 07 and 07:54.

Which is the status of issue #236 (Suggestion for allowance of truncated 
date format in BDAY) ?

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 Jun 2008 09:01:36 -0400

> "agent" is a particular kind of relation, which may be described by the

+1

> for AGENT, I think it will also be required for RELATED.

I'm fine with either adding it to RELATED or removing it altogether.

> Which is the status of issue #236 (Suggestion for allowance of truncated

Not really. What is in -02 now was fairly straightforward because it only 
allows for truncation. Issue #236 is incorrectly named because it refers to 
more than just truncation. It lets one also remove fields from the beginning. 
This requires resolving the issue of whether we want to use field delimiters 
or not. Mark suggested we remove delimiters, which conflicts with allowing 
issue #236. Some discussion is still needed.

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 25 Jun 2008 10:37:57 -0300

----- Original Message ----- 
From: "Simon Perreault" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 25, 2008 10:01 AM
Subject: Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-02.txt

> more than just truncation. It lets one also remove fields from the

Well.. the definition of "truncated" in ISO 8601:2000 is "3.22 abbreviation
of a representation by omission of higher order components starting from the
left-hand side of the expression", hence this issue is correctly named.

Dates such as 2008 and 2008-05 are "representations with reduced precision"
(3.23: "abbreviation of a representation by omission of lower order
components starting from the right-hand side of the expression").

> or not.

Not necessarily... this is already resolved in ISO 8601: "using field
delimiters" is referred as "extended format" (e.g.: 2008-06-25) as opposite
to "basic format (e.g.: 20080625); for *truncated* dates, their
representation *does use* some delimiters in order to distinguish them from
the reduced precision case [section 5.2.1.3]:

--0625 (a truncated date in basic format)
--06-25 (a truncated date in extended format)

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 Jun 2008 09:52:27 -0400

On Wednesday 25 June 2008 09:37:57 Javier Godoy wrote:
> of a representation by omission of higher order components starting from
> the left-hand side of the expression", hence this issue is correctly named.
>

Thanks!

> --06-25 (a truncated date in extended format)

Thanks for clearing up the confusion that has been surrounding this issue for 
too long.

Now, one remaining issue for experts of that standard. According to Peter K. 
Sheerin, "ISO 8601:2000 has now been superseded by ISO 8601:2004 and deletes 
the ability to truncate the left side of a date." Are we supposed to specify 
ISO 8601:2004 and explicitly allow truncation as specified in ISO 8601:2000, 
or do we just specify ISO 8601:2000?

---

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 26 Jun 2008 10:05:13 -0400

Some comments:

1)
In section 6, there is the example:
FN;PID=8:Jane Doe

Since FN is unlikely to occur more than once per vCard (should it even be
allowed?), there is cost, without benefit in it ever having a PID.  In fact,
if FN is restricted to being single occurrence, I would prohibit it from
having a PID.

Thus either remove the "PID=8;" from the example, or use something that is
likely to have multiple instances, such as email or tel.

2)
Section 6.4 PID

It is suggested that the uniqueness qualities of PID be explicitly mentioned
(that it is not globally unique, but should be unique for each property
within a particular vCard), and that it be prohibited from all single
instance properties, whenever those are actually defined.  Note that UID
already cannot have a PID per the ABNF.

E.g.
"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."
Or:
"it MUST NOT appear on properties that only may have one instance per vCard.
PIDs should be locally unique, within all properties of a specific type." 

3)
Section 7.7.7 UID
The statement "The PID parameter MUST NOT be applied to this property" is
irrelevant.  UID is not allowed text-params per the ABNF, and thus can never
have a PID (as an x-name or a common property, were it to be defined).

4)
Section 8.1

Paragraph 1 includes: "  A
   missing UID property MUST NOT be considered equivalent to any other.
   Hence, the UID property SHOULD be present if synchronization is to be
   used."

The first sentence is incorrect, and needs to be removed.  

It is typical for a device to not store a UID (in fact, at one point 3GPP
required that SIM address book entries were required to NOT have one), and
thus it is common practice for a sync engine to match a vCard without a UID
with a vCard with a UID, based on the other properties in the vCard.
Following this rule would result in doubling the size of one's address book
every time one synchronized with a SIM card, or most devices on the market.

Regarding the second sentence, while it is helpful to have a UID for
synchronization, and thus certainly a recommended practice, in common
practice most synchronization occurs without one.  It seems questionable to
indicate with a SHOULD something that does not normally happen, no matter
how nice it would be.

Section 8.1 Paragraph 2:
" 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.  A missing PID
   parameter MUST NOT be considered equivalent to any other.  Hence, the
   PID parameter SHOULD be present if synchronization is to be used."

The first sentence neglects the possibility of PID conflicts.  In the case
of a PID conflict, a sync engine would deliberately identify properties with
the same PID as not being different (since they were received from different
sources, at different times, and contain different values).  Thus a Sync
engine would need to violate this sentence.

The second sentence will not work with clients that do not store the PID.
In this case the sync engine must be able to correlate parameters, whether
they were able to be resent from the client with the PID or not.  Following
the rules of this sentence would cause duplication of every value containing
a PID every time a sync engine received an update from a client that could
not store a PID.

The third sentence is reasonable, however since the prior sentences do not
support it, should be a simple declaration, or be in a reworded paragraph.

5)
Section 8.2
The first sentence has a Typo:
   Two vCards are to by synchronized:
"by" should be "be".

6)
Section 8.2

The text " Assuming the first one is the source and the other is the
   destination, "

Is discussing things in terms that generally do not apply to
synchronization.  Synchronization is between pairs, in both directions, or
else it is not synchronization.  It is not typically from one to another,
source to destination.  Source and destination only applies to backup and
restore, or a refresh operation - a one-way sync, in which no merging is
usually done.

7)
Section 8.2, the example vCards:
The FN has a PID, see comment 1 above.

8) 
Section 9: ABNF

The ABNF does not include PID as a common parameter.

9) 
Section 9: ABNF
The ABNF does not allow email to have PID.  Email is only allowed
email-params, and no extensions except for the values of TYPE= value.

Email is one of the 2 key properties that need PID.

10) 
Section 9: ABNF
The ABNF does not allow tel to have PID, or other extensions.  Tel is only
allowed tel-params, and no extensions except for the TYPE= value.

tel is one of the 2 key properties that need PID.

Thanks,
dgc

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Jun 2008 10:51:25 -0400

On Thursday 26 June 2008 10:05:13 Darryl Champagne wrote:
> allowed?), there is cost, without benefit in it ever having a PID.  In
> fact, if FN is restricted to being single occurrence, I would prohibit it
> from having a PID.
>

Agreed, done.

> 2)
> Section 6.4 PID
>
> It is suggested that the uniqueness qualities of PID be explicitly
> mentioned (that it is not globally unique, but should be unique for each
> property within a particular vCard), and that it be prohibited from all
> single instance properties, whenever those are actually defined.  Note that
> UID already cannot have a PID per the ABNF.
>
> E.g.
> "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."
> Or:
> "it MUST NOT appear on properties that only may have one instance per
> vCard. PIDs should be locally unique, within all properties of a specific
> type."

Agreed, done. I chose the first one because the second one implies that a UA 
should somehow choose a "locally unique" PID, while it has no way to enforce 
that.

> irrelevant.  UID is not allowed text-params per the ABNF, and thus can
> never have a PID (as an x-name or a common property, were it to be
> defined).

Right, removed.

> indicate with a SHOULD something that does not normally happen, no matter

Would changing MUST NOT to SHOULD NOT be an acceptable compromise? I get the 
feeling you want a standard knowing that nobody will adhere to it.

> of a PID conflict, a sync engine would deliberately identify properties
> with the same PID as not being different (since they were received from
> different sources, at different times, and contain different values).  Thus
> a Sync engine would need to violate this sentence.

Yes, but how would it detect conflicts?

> the rules of this sentence would cause duplication of every value
> containing a PID every time a sync engine received an update from a client
> that could not store a PID.

Same as above: Would changing MUST NOT to SHOULD NOT be an acceptable 
compromise?

> support it, should be a simple declaration, or be in a reworded paragraph.

What do you mean by "do not support it"?

>    Two vCards are to by synchronized:

Fixed, thanks.

> restore, or a refresh operation - a one-way sync, in which no merging is

I was thinking on a per-property basis. Of course the value of one peer will 
be propagated toward the other.

I just removed the sentence because it was unnecessary and confusing.

> The FN has a PID, see comment 1 above.

Removed.

> The ABNF does not include PID as a common parameter.

I created

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

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

> tel is one of the 2 key properties that need PID.

:)

---

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 26 Jun 2008 12:28:48 -0400

Thanks for the changes.  Regarding the open issues.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Thursday, June 26, 2008 10:51 AM
> To: [email-masked]

> feeling you want a standard knowing that nobody will adhere to it.

Last point first - it's not my standard - UID has been around for a long
time.  I wouldn't be heartbroken if it was removed, but I am not advocating
that - I am just recognizing that very few devices use or store it today.
If we are talking about a PC/*nix or other server system, I expect UID to be
used, and when both sides use it, it is useful.  But absence of proof (that
items are the same) is not the same as proof of absence/difference.

For the first point, SHOULD NOT is just as pointless - I SHOULD NOT match my
vCard with a UID, with the vCard from the device that does not have or
support UID (or had an error and had to recreate the vCard based on internal
data), which doesn't have the UID?  That means nothing would ever match with
such a device - instant addressbook = addressbook*2.  Or is a sufficient
reason for an exception that it doesn't send me a UID?  That means that if I
receive a vCard without a UID it is ok for me to not apply the rule about
vCards without UIDs?  That makes no sense.

- Something with a UID should usually match something with the same UID.
- Something without a UID needs to be checked for duplication with other
things, either with or without the UID.  That's a core sync function - don't
say we shouldn't do it.

Duplicating every address is someone's address book is evil.

Refer to text I provided earlier - it was phrased that way for a reason.
The wording can be improved, but what is a positive declaration, versus a
negative declaration was very deliberate.

> Yes, but how would it detect conflicts?

Simple, I detect a _potential_ conflict when I receive a vCard from one
client with a particular PID on a particular value, and I then sync to a
different client that sends me an update with the matching PID, with a
different value.

I know I didn't send that PID to either client.  I know the two other
clients haven't synced somehow since one of them last edited it (or else
they wouldn't have different values).  Either they both created a new value
and got the same PID by chance, or I hit a very specific sequencing issue
involving at least 4 parties (since they would need to go through another
server, or one of them act as a server), with the syncs and edits occurring
in a particular sequence.

I also have additional information not available to anyone else, such as
when I last synced with each client, and the timeframe that I usually sync
with them.  

If any of those times are short, like they should be, it is pretty darn
unlikely that the two clients were able to talk to each other (probably via
someone else), AND then have the user then go in and edit something, before
I got to talk to them, so they are probably different data items, which
happened to get a PID conflict.

On the other hand, if you haven't talked to one of the clients for a long
time, then you may just want to go with the new value.

Additionally, sync engines have all sorts of other data available to them,
which might even include the time of last edit, which I can also fit into
the time of last syncs.

And of course there are all sorts of other variations.
 
Your mileage and product may vary - but that's the difference between a
mediocre sync product and a good one.  Do what the user wants, not what they
say :-).  

> Same as above: Would changing MUST NOT to SHOULD NOT be an acceptable

Same as first item above, but less often.  In any kind of error case, or
using an alternate or upgraded sync client, I might get back data without
any custom stuff, like PIDs.  Then to be an effective product I must make a
best guess at matching.

If I need to do it to be an effective product, then it SHOULD NOT be against
the standard.  A typical recovery process shouldn't be considered invalid.

> What do you mean by "do not support it"?

If the previous sentences are updated to reflect my changes, or deleted
since they are wrong, then you can't say Hence without something relevant
before it.

That's all folks,
dgc

---

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 26 Jun 2008 16:43:27 -0400

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

Umm, seeing Javier's email with just this section made me realize...

Being a little sarcastic, are we?

When I said small integer, I also had text that talked about the realistic
odds of a 1 in 256, or one in 64K collision possibility - as in an 8 bit
integer, or 16 bit integer.

That requires slightly more than one character digit.  

And if one digit instead of at least 3 is a big deal, then at least give me
a SAFE-CHAR, OK?

dgc

---

From: Simon Perreault <[email-masked]>
Date: Thu, 26 Jun 2008 16:49:00 -0400

> That requires slightly more than one character digit.

1*DIGIT means "at least one digit".

I almost wish I had forgot the *, that would have been very funny.

;-)

---

From: "Darryl Champagne" <[email-masked]>
Date: Thu, 26 Jun 2008 17:25:59 -0400

I'm sorry, I misread it.
dgc

> Sent: Thursday, June 26, 2008 4:49 PM
> To: [email-masked]

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 27 Jun 2008 09:37:15 -0400

Hi,
Since I haven't heard back about this part, I want to follow up on this
before my next round of flights, hotels, and meetings.  Hopefully I might be
slightly more coherent after finally getting a decent night's sleep.

Regarding the text in 8.2:

E.g. Paragraph 1 includes: "  A
   missing UID property MUST NOT be considered equivalent to any other.
   Hence, the UID property SHOULD be present if synchronization is to be
   used."

And similar text about PIDs.

Here is the problem.

I as a server get a vCard from somewhere (created locally, or from a high
end device), that has a UID.

I sync/send it to a lower end device, which promptly tosses the UID out.

The lower-end device has an issue, such as losing its change log
information.  A typical scenario for this is when a low end device syncs
against 2 different servers - it might only have a single dirty bit per
entry, which was reset during the last successful sync.  This is not the
typical case, but not a rare case either.

I sync again with the lower end device, which now sends me every item,
without any UIDs, since it doesn't know which objects have changed since I
last did a sync with it.

I know have my list of objects, with UIDs, and the list from the client,
without any UIDs.

What should any reasonable server implementation do at this point?

Should it MUST NOT compare the two lists, to try and match them back up?
Should it SHOULD NOT compare the two lists, to try and match them back up?

NO.  If it doesn't compare the two sets of data, the vCards without UIDs
against the vCards with UIDs, you will end up with twice as many vCards as
before, and a very pissed off user.  Sync again, and every vCard with a UID
will again get duplicated, so you have a tripled address book, and so on
until one or the other system runs out of memory, or the user uninstalls
your software because it sucks so bad.  This is a catastrophic failure mode
for a mild error, or rare use case, whatever you want to call it.

Almost any reasonable implementation SHOULD try to match a vCard without a
UID against the vCards that it has that do have UIDs.

The next question is if it cannot be MUST NOT, and it cannot be SHOULD NOT,
should it be a SHOULD?

My answer is no - that is a product specific issue.  If you are running a
paranoid about data loss server, or you have other reasons to believe that
this shouldn't be happening (like you believe the client on the other end
should have preserved the UIDs), then you don't have to perform a match.
The criteria for a server running on a personal machine, versus a trusted
machine in a secure environment talking only to other trusted machines in a
secure environment (such as a Telephony Carrier's data center) are very
different.  It's not up to the standard to care about those issues, or try
to force one means of operation.  Products may have perfectly valid reasons
to not want to try and do matching.

Thus MUST NOT is totally wrong.
SHOULD NOT is still wrong, and not a compromise.

All that you can say is that if both sides have a UID, then it matters.  

Note that even then - if I receive vCards from different data sources, with
identical data except for different UIDs, during initial or recovery syncs I
am likely to still want to do matching, and merge them - if this is the
first sync I ever make with both a users phone, and their PDA, and they both
have a John Doe entry, then the user probably only wants one John Doe entry,
whether the initial devices created UIDs or not.

And that is why in my proposed text I only required that if two vCards have
the same UID they be considered equal - I made no requirement that if the
UIDs were different they not be considered equal.

Regarding PIDs, the same logic follows, just with slightly different
examples of why you might encounter the situation - like an upgraded client,
or using a different sync client from a particular device.

That is why the new proposal for section 8.2 is still totally wrong.
dgc
 
> Behalf Of Darryl Champagne
> Sent: Thursday, June 26, 2008 12:29 PM
> To: 'Simon Perreault'; [email-masked]
> > > thus it is common practice for a sync engine to match a vCard without
> a
> > UID
> > > practice most synchronization occurs without one.  It seems
> questionable
> > to

---

From: Simon Perreault <[email-masked]>
Date: Fri, 27 Jun 2008 10:15:17 -0400

> I sync/send it to a lower end device, which promptly tosses the UID out.

I see that's where you were going with your previous proposal. ;)

> SHOULD NOT is still wrong, and not a compromise.

I agree. Here's a new proposal.

Old text:

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. A missing UID property MUST NOT be considered 
equivalent to any other.  Hence, the UID property SHOULD be present if 
synchronization is to be used.

New text:

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.

Likewise for PID.

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 27 Jun 2008 11:34:22 -0400

That text is reasonable.  It is good for PIDs.  For UIDs I am concerned that
a SHOULD would decrease/slow adoption on lower end devices, but whatever.
I'll leave that for the majority view.

dgc

> Sent: Friday, June 27, 2008 10:15 AM
> To: [email-masked]
> Subject: Re: [VCARDDAV] Section 8.2 - was RE: I-DAction:draft-ietf-
> vcarddav-vcardrev-02.txt
>

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 27 Jun 2008 15:57:42 -0400

Hi,

--On June 26, 2008 12:28:48 PM -0400 Darryl Champagne <[email-masked]> 
wrote:

>> >    Hence, the UID property SHOULD be present if synchronization is to
>> >    be used."
>> >
> time.  I wouldn't be heartbroken if it was removed, but I am not
> advocating that - I am just recognizing that very few devices use or
> store it today. If we are talking about a PC/*nix or other server system,
> I expect UID to be used, and when both sides use it, it is useful.  But
> absence of proof (that items are the same) is not the same as proof of
> absence/difference.

One data point: CardDAV requires UIDs on all vCard objects stored on the 
server. This does place a requirement on clients to preserve that 
information, so wel behaved vCard clients will have to do that.

Overall I also think it would be of great benefit to promote the use of 
UIDs for synchronization. So use of UID ought to be a (strong) SHOULD. But 
the text describing what to do in the absence of a UID property can say, as 
you want, that the client/engine is free to attempt a field-by-field match 
against existing vCards. I am sure a carefully worded statement here will 
make it clear to anyone that using UIDs makes life considerably easier when 
synchronizing.

As Mark pointed out in another thread, not many devices have switched to 
vcard 3.0 because of a perceived lack of benefit. 4.0 really does need to 
show some clear benefits to be adopted. A strong push on using and 
persisting UID, and the PID for multiple occurring field detection should 
be two strong arguments in favor of 4.0.

-- 
Cyrus Daboo