Subject: [VCARDDAV] New vcardrev draft

From: Simon Perreault <[email-masked]>
Date: Fri, 18 Jan 2008 12:56:36 -0500

Hi all,

The new vCard spec draft is out! Get it while it's hot!

So what we've done is merge 2425 and 2426. We've removed all the non-vcard 
parts of 2425 since nothing else ever used it it seems. The structure of the 
draft is what we'd like to get most feedback on. We'd like to keep the 
structure pretty much stable starting with 01 while the real content of the 
draft, i.e. the new vcard spec, is expected to be in flux a lot. But if you 
look closely there are a few new goodies in this draft for you to enjoy.

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : vCard Format Specification
> 	Author(s)       : P. Resnick, S. Perreault
> 	Filename        : draft-resnick-vcarddav-vcardrev-00.txt
> 	Pages           : 50
> 	Date            : 2008-01-18
>
> 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-resnick-vcarddav-vcardrev-00.txt

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

---

From: Mark Paterson <[email-masked]>
Date: Mon, 21 Jan 2008 13:27:08 -0500

Hi Simon,

Great job. Overall the format for the document looks good.

A few small suggestions:

- Section 5.3 might be more clear if it were labeled "Postal Addressing 
Properties". I think the word "Delivery" is a little confusing since I 
can deliver something as an email
- The LANG Property isn't just for Telecommunications. If I decide to 
pen a letter and mail it to someone (call me old fashioned) it's helpful 
to know what language they can read so perhaps LANG should be moved to 
"General Properties"
- In section 3 the Published specification refers to 
"draft-resnick-vcardbis-00" which I assume has been superseded by this 
draft.

For future work here is a list of things for people to consider

- As Cyrus suggested, being able to use N to refer to a company
- Be more clear about data formats for PHOTO, SOUND, etc.. that shoudl 
be acceptable
- Stricter descriptions of values for BDAY and DDAY (can my time of 
death really be floating??)
- New ADR format (UPU S42? other suggestions?)
- Be clearer on ADR type values that can be used.
- Have way to enumerate (or uniquely id) postal addressed if contact has 
more then one.
- Update TEL format (E.164 anyone?)
- Be clearer on TEL type values that can be used.
- Have way to enumerate (or uniquely id) telecommunication addresses if 
contact has more then one.
- BBS, PCS?
- Do we really need MAILER?
- Proper format for TZ values

Let the fun begin :-)

Mark

-- 

Oracle Email Signature Logo
Mark Paterson | Product Manager, Mobility & Search | 514.905.8649
Oracle Server Technologies - Collaboration
600 Blvd. de Maissoneuve West, Suite 1900, Montreal, Quebec, H3A 3J2
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Jan 2008 13:57:38 -0500

> can deliver something as an email

Maybe, but then how would you rephrase this?

""postal" to indicate a postal delivery address"

That's from the description of the TYPE parameter for the ADR property.

> to know what language they can read so perhaps LANG should be moved to

I don't agree that "General Properties" is the right place for LANG to be. It 
might be confused with the language of the vCard itself, which it isn't. LANG 
is used to provide information about *communicating* with the object the 
vCard represents, which is it was placed in Telecommunications.

Would it be a good thing to instead change "Telecommunications" 
to "Communications"?

> "draft-resnick-vcardbis-00" which I assume has been superseded by this

Thanks for pointing this out. It is in fact the old name of the very document 
you read, and doesn't refer to something that was published.

> - As Cyrus suggested, being able to use N to refer to a company

Well, to be precise, I don't think he did suggest that. What I think he 
suggested was keeping in mind that vCards might be used for representing 
things other than people, and that we should support it.

> - Be more clear about data formats for PHOTO, SOUND, etc.. that shoudl

Could you please elaborate on this?

> death really be floating??)

I don't understand what you mean. BDAY and DDAY have date types. Isn't that 
strict enough?

> contact has more then one.

Well, if there are multiple postal (resp. telecommunication) addresses you can 
of course use ADR (resp. TEL) multiple times. Having a unique ID for each one 
reminds me of synchronization. Is this what you mean?

> - Do we really need MAILER?

I vote for nuking it. ;) vCards are for so much more than just email.

> - Proper format for TZ values

I agree 100%. UTC offsets don't account for everything. Is there a standard 
for naming timezones? Can we use the Olson database?

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 21 Jan 2008 18:29:30 -0200

----- Original Message ----- 
From: "Simon Perreault" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 21, 2008 4:57 PM
Subject: Re: [VCARDDAV] New vcardrev draft

> I don't understand what you mean. BDAY and DDAY have date types. Isn't 

I don't understand too, but I would suggest allowing BDAY and DDAY to be 
reset to a single text value. This way we could represent BDAY and DDAY 
which are not exactly known, such as:

BDAY;VALUE=text: circa 1800.
DDAY;VALUE=text: 1845-12

The latter is not an instance of date type because date allows only complete 
representations.

> I vote for nuking it. ;) vCards are for so much more than just email.

(from Section 5.4.4) " Special notes:  This information can provide 
assistance to a
      correspondent regarding the type of data representation which can
      be used, and how they can be packaged ".

By reading something like "MAILER:PigeonMail 2.1" I cannot directly infer 
what types of data representation which can be used, and how they can be 
packaged.

Besides, it is possible that a single individual uses different mail 
software with different capabilities (for instance a POP3 client and a 
web-interface).
The allowed types may also depend on other software (such as installed 
plug-ins). At all, I'm more likely interested on such restriction than a 
particular software name and version.

Maybe something such as the HTTP Accept header could be used instead (RFC 
2616, Section 14.1).

EMAIL;ACCEPT=text/plain:[email-masked]

This also allows for user-preferences (not only software limitations):

EMAIL;ACCEPT=text/plain\;q=1,text/*\;q=0.75,application/ms-word\;q=0,*/*\;q=0.1;[email-masked]

which remains for:
- I prefer plain text
- other text types be acceptable
- ms-word attachments are not supported.
- other types might be accepted, but it would be better if a text type is 
used.

mmm... this sounds like "feature ACCEPT  must be in the base feature set 
because ...". I'm not sure about including this idea in the standard-track 
document.

> for naming timezones? Can we use the Olson database?

If names from the Olson database were used, there would be a normative 
reference to a document which is neither an RFC nor a third-party standard.
The only advantage I can recall about timezone names against UTC offsets is 
that the former are not DST-sensitive. This usually means a shift of only 
one hour.

IMHO, TZ is intended to give an idea about the individual local time. This 
is useful if one is going to call him/her, but I think it is not used for 
scheduling events, so I can live with the DST error.

Regards,

Javier

---

From: Mark Paterson <[email-masked]>
Date: Tue, 22 Jan 2008 10:42:19 -0500

> That's from the description of the TYPE parameter for the ADR property.
I honestly think the entire Special Notes section needs to be rewritten. 
How is a postal address different from a parcel address? What does dom 
and intl mean?? I woudl assume an address in Japan is domestic to 
someome in Japan but intl to someone in Canada. A good look at other 
standards which define how to specify an address should be examined for 
inspiration.
> vCard represents, which is it was placed in Telecommunications.
I am perhaps old fashioned but it would seem that I can "communicate" 
with someone by sending them a letter.
> you read, and doesn't refer to something that was published.
That's what I figured.
> things other than people, and that we should support it.
Yes, I was over generalizing. I just meant we should do something like 
you and Javier have been posting back and forth.
> Could you please elaborate on this?
For both PHOTO and SOUND the spec claims that a valid value would be 
"...or a non-standard image/audio format". So apparently you can put 
anything you want.

Imagine a mobile device that has to support any non standard format, not 
going to happen.
> I don't understand what you mean. BDAY and DDAY have date types. Isn't that 
Someone from Orange complained about this. Check out slide #8 in the DS 
presentation that was given a the vCard workshop...

http://www.openmobilealliance.org/ftp/Public_documents/DS/DS_DO/2007/OMA-DS-DS_DO-2007-0002R01-INP_vCard_workshop.zip

> reminds me of synchronization. Is this what you mean?
The UID is on the VCARD. What's needed is a UID (or some form of 
enumeration) on each ADR, TEL, EMAIL, etc...so that in cases where the 
vCard goes back and forth (like in synchronization) the receiver and 
sender can keep track of which value corresponds to which value.
> I vote for nuking it. ;) vCards are for so much more than just email.
+1
> for naming timezones? Can we use the Olson database?
Ay, there's the rub

CalConnect published recommendations on a time zone registry which is 
what we'd need here but nothing has really happened as far as I know.

http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf

Mark

--

---

From: "Javier Godoy" <[email-masked]>
Date: Tue, 22 Jan 2008 16:11:29 -0200

Mark Paterson wrote,

>>> Be more clear about data formats for PHOTO, SOUND, etc.. that shoudl
>>>be acceptable
>>
>>
>For both PHOTO and SOUND the spec claims that a valid value would be "...or
>a non-standard image/audio format". So apparently you can put anything you
>want.
>

If this is a concern then standard formats SHOULD be used... Extrapolating
this issue, an HTTP server may only offer application/x-foobar-qwerty
content (nothing prohibit it)... it conforms the specifications, but it is
unlikely that an user agent (particularly a simple one) will understand such
content. It is up to the server administrators (in our case, the vCard's
author).

>>Well, if there are multiple postal (resp. telecommunication) addresses you
>>can of course use ADR (resp. TEL) multiple times.
>>Having a unique ID for each one reminds me of synchronization.
>>Is this what you mean?
>
>vCard goes back and forth (like in synchronization) the receiver and sender
>can keep track of which value corresponds to which value

I like the idea. I think an UID parameter would be fine. It would be 
OPTIONAL for each repeatable property.

The value of such
parameter MUST be a globally unique identifier (this allows distributed
edition of a vCard identifying someone else). I'm not sure if we have to be
too lax about this identifiers...

What identifier should be used? I can think about three alternatives:
 - a UUID literal.
 - a UUID URN
 - any URI

Javier

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Jan 2008 15:05:22 -0500

Hi Javier,

--On January 21, 2008 6:29:30 PM -0200 Javier Godoy 
<[email-masked]> wrote:

>
> ----- Original Message ----- From: "Simon Perreault"
> <[email-masked]>
> To: <[email-masked]>
> The latter is not an instance of date type because date allows only
> complete representations.

This is a good idea. We don't need to be as strict about the value of these 
properties as we would have to be in iCalendar. value=text as a non-default 
alternative works well for this.

> because ...". I'm not sure about including this idea in the
> standard-track document.

This type of thing should be left out of the base spec - we can write 
extension properties defining user preferences for things like email, 
calendaring etc if we want. But I suspect there will be a lot of debate 
about what properties need to be exposed and what model to use. You could 
also argue something like this should be done via a service discovery 
protocol too...

> IMHO, TZ is intended to give an idea about the individual local time.
> This is useful if one is going to call him/her, but I think it is not
> used for scheduling events, so I can live with the DST error.

If the ADR is detailed enough it should be possible to map the location 
from that to a timezone. I don't think we need TZ at all. Better would be 
an iCalendar service that could return information about what TZ you expect 
to be in at any point in time - tied to free-busy information too. That has 
been discussed in Calconnect to some degree.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Jan 2008 15:10:58 -0500

Hi Mark,

> Imagine a mobile device that has to support any non standard format, not

But they already have to deal with this in email.

The model being adopted by IETF Lemonade is a CONVERT extension for IMAP 
that allows the client to request the image (or whatever) in the format 
that can be handled by that device. I would much rather see the access 
protocol side of this allow support for per-property content conversion 
than add restrictions as to what formats are allowed.

>> I agree 100%. UTC offsets don't account for everything. Is there a
>> standard  for naming timezones? Can we use the Olson database?
>>
> Ay, there's the rub
>

CalConnect has a technical committee currently working on formalizing the 
timezone registry and service protocols. The current thinking is that we 
would define a registry of timezone source names, e.g 'Olson', 'EU', 'NATO' 
etc. Those names would be the top-level namespace of iCalendar's TZID 
property, and the actual timezone name would follow: 
'/Olson/America/New_York'. That fits with definition of TZIDs in iCalendar.

My personal feeling is that TZ isn't needed in vCard. But if it is kept in, 
I think stating that it can be any valid iCalendar TZID value would be all 
we need to do.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Jan 2008 15:16:01 -0500

Hi Javier,

--On January 22, 2008 4:11:29 PM -0200 Javier Godoy 
<[email-masked]> wrote:

>> sender can keep track of which value corresponds to which value
>

I guess my big concern with this is that the UUID values will more often 
than not end up be more characters than the actual properties being 
"tagged". For limited bandwidth situations that is not ideal.

In reality a full-blown UUID is not needed. All that is needed is a token 
unique within the context of the enclosing vCard.

Another option is to also look into the property name prefix syntax allowed 
in vCard as a means of tagging items, e.g.:

TAG1.ADR:...
TAG2.ADR:...
TAG1.TEL:...
TAG2.TEL:...

That does being up the question about the use of property name prefixes in 
the spec. The one incompatibility between the iCalendar and vCard syntaxes 
is that construct - iCalendar does not have anything similar, which means 
it is not possible to embed an arbitrary vCard in an iCalendar object 
without doing some manipulations to remove the property name prefix. There 
are those that would like to embed vCard in iCalendar.
-- 
Cyrus Daboo

---

From: Mark Paterson <[email-masked]>
Date: Tue, 22 Jan 2008 15:33:16 -0500

Cyrus Daboo wrote:
> I guess my big concern with this is that the UUID values will more 
> often than not end up be more characters than the actual properties 
> being "tagged". For limited bandwidth situations that is not ideal.
>
> In reality a full-blown UUID is not needed. All that is needed is a 
> token unique within the context of the enclosing vCard.
If the VCARD has a UID that is globally unique then I don't think the 
UID's at the property level need to be globally unique. As Cyrus has 
indicated it only needs to be unique for that property within the vCARD
>
>
> Another option is to also look into the property name prefix syntax 
> allowed in vCard as a means of tagging items, e.g.:
>
> TAG1.ADR:...
> TAG2.ADR:...
> TAG1.TEL:...
> TAG2.TEL:...
I prefer the idea of using UID. Using the example from the draft....

BEGIN:VCARD
VERSION:4.0
UID:<This is a globally unique ID>
FN:Simon Perreault
N:Perreault;Simon;;;ing. jr.,M.Sc.
BDAY:1983-02-03
GENDER:M
ORG:Viagenie
ADR;UID=1;TYPE=work:;;2600 boul. Laurier\, suite 625;
       Quebec;QC;G1V 4W1;Canada
TEL;UID=1;TYPE=voice,work:+1-418-656-9254
TEL;UID=2;TYPE=fax,work:+1-418-656-9257
EMAIL;UID=1;TYPE=internet,work:[email-masked]
GEO:46.772673,-71.282945
CLASS:PUBLIC
KEY;VALUE=uri:http://www.viagenie.ca/simon.perreault/simon.asc
END:VCARD

>
> That does being up the question about the use of property name 
> prefixes in the spec. The one incompatibility between the iCalendar 
> and vCard syntaxes is that construct - iCalendar does not have 
> anything similar, which means it is not possible to embed an arbitrary 
> vCard in an iCalendar object without doing some manipulations to 
> remove the property name prefix. There are those that would like to 
> embed vCard in iCalendar.
I honestly never even realized you could do that with vCARD. Is it used 
much?

Mark

--

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 Jan 2008 15:43:25 -0500

Hi Mark,

> KEY;VALUE=uri:http://www.viagenie.ca/simon.perreault/simon.asc

I would actually prefer to use another name for the parameter, how about 
"PID" (property ID) - just to avoid any confusion with the UID property.

So if we use this scheme is there any need to track the old PIDs. e.g., in 
the example above, lets say one client deletes the TEL property with 
UID/PID=2. Then another client comes along and creates a new TEL property. 
Should the new one have PID=2 or PID=3? i.e. does it matter that PID=2 gets 
re-used for a "different" property? If there is a need to track old PIDs 
for deleted properties, then that would complicate things a lot.

> I honestly never even realized you could do that with vCARD. Is it used

Last I checked Apple's AddressBook does use this construct for tying 
together ADR locale information to the ADR value i.e. the UI allows the 
user to associate a locale with each mailing address so that the address is 
formatted for that locale - they put the locale in a property and need to 
make sure that property relates to a specific ADR. Of course a parameter on 
ADR could be used instead.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Jan 2008 15:48:25 -0500

On Tuesday 22 January 2008 15:33:16 Mark Paterson wrote:
> > prefixes in the spec.

They are officially called groups and are specified in RFC 2425. Their purpose 
is "to group related attributes together. The group name is a syntactic 
convention used to indicate that all type names prefaced with the same group 
name SHOULD be grouped together when displayed by an application. It has no 
other significance."

I doubt we can find a use for them in the wild, so I vote for nuking them.

---

From: Mark Paterson <[email-masked]>
Date: Tue, 22 Jan 2008 16:10:52 -0500

Cyrus Daboo wrote:
> The model being adopted by IETF Lemonade is a CONVERT extension for 
> IMAP that allows the client to request the image (or whatever) in the 
> format that can be handled by that device. I would much rather see the 
> access protocol side of this allow support for per-property content 
> conversion than add restrictions as to what formats are allowed.
I know and I agree but some time in the future you'll be at some form of 
test event testing IOP and this will come up. It would be nice if there 
were some examples or informative guidance pushing implementors to do 
something that makes sense :-) that doesn't actually restrict things.
>> http://www.calconnect.org/publications/timezoneregistryandservicerecommen 
>>
>> dationsv1.0.pdf
>>
>
> CalConnect has a technical committee currently working on formalizing 
> the timezone registry and service protocols. The current thinking is 
> that we would define a registry of timezone source names, e.g 'Olson', 
> 'EU', 'NATO' etc. Those names would be the top-level namespace of 
> iCalendar's TZID property, and the actual timezone name would follow: 
> My personal feeling is that TZ isn't needed in vCard. But if it is 
> kept in, I think stating that it can be any valid iCalendar TZID value 
> would be all we need to do.
Having people figure out the TZ based on the ADR I think might be a 
little much to ask so I think there is value in still having the TZ (or 
maybe add TZID to ADR). I really like the idea of making it any valid 
iCal TZID since this way the issue can be solved in one place.

Mark

--

---

From: Mark Paterson <[email-masked]>
Date: Tue, 22 Jan 2008 16:26:20 -0500

Cyrus Daboo wrote:
> I would actually prefer to use another name for the parameter, how 
> about "PID" (property ID) - just to avoid any confusion with the UID 
> property.
Fine by me. As long as there is a mechanism in place to do it.
>
> So if we use this scheme is there any need to track the old PIDs. 
> e.g., in the example above, lets say one client deletes the TEL 
> property with UID/PID=2. Then another client comes along and creates a 
> new TEL property. Should the new one have PID=2 or PID=3? i.e. does it 
> matter that PID=2 gets re-used for a "different" property? If there is 
> a need to track old PIDs for deleted properties, then that would 
> complicate things a lot.
I would much rather see the access protocol side of things dictate as to 
wether these PIDs can be recycled. From an OMA DS perspective (which is 
of course where my thinking comes from) my first instinct is to say that 
they shouldn't be reccyled but as I think through some of the use cases 
it might be possible. I'd really need to think through them some more.

> together ADR locale information to the ADR value i.e. the UI allows 
> the user to associate a locale with each mailing address so that the 
> address is formatted for that locale - they put the locale in a 
> property and need to make sure that property relates to a specific 
> ADR. Of course a parameter on ADR could be used instead.
>
Sounds kind of like they did it because ADR didn't let them do what they 
wanted. I've voiced my opinion in the past that the ADR format should be 
rethought completely.

Mark

--

---

From: Mark Paterson <[email-masked]>
Date: Tue, 22 Jan 2008 16:26:58 -0500

> I doubt we can find a use for them in the wild, so I vote for nuking them.
That's kind of what I was thinking :-)

Mark

--

---

From: "Javier Godoy" <[email-masked]>
Date: Tue, 22 Jan 2008 23:50:53 -0200

Hi Cyrus,

----- Original Message ----- 
From: "Cyrus Daboo" <[email-masked]>
To: "Javier Godoy" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 22, 2008 6:16 PM
Subject: Re: [VCARDDAV] New vcardrev draft

>> I think an UID parameter would be fine. It would be

Looks good since

TEL;PID=1;TYPE=voice,work:+1-418-656-9254

is shorter than

TEL;UID=4c583204-c94f-11dc-95ff-000cf1d1120d;
 TYPE=voice,work:+1-418-656-9254

I think locally global identifiers are OK, but for the problem discussed 
below.

----- Original Message ----- 
From: "Cyrus Daboo" <[email-masked]>
To: "Mark Paterson" <[email-masked]>
Cc: "Javier Godoy" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 22, 2008 6:43 PM
Subject: Re: [VCARDDAV] New vcardrev draft

+1

>for deleted properties, then that would complicate things a lot.

I think it matters. Otherwise, what are PID for? I have understood they were 
for distinguishing whether a property was modified, or it was deleted and a 
new (unrelated) property was inserted at a later time (I'm not sure if my 
reasoning is correct?).

In any case, there is no need for tracking all removed PIDs. If PIDs are 
increasing integers, then knowledge of the "last used PID" would be enough. 
If no "last used PID" is given, it would be assumed to be the greater PID 
present in the vCard.

Had PIDs been globally unique they would have been only reused on purpose, 
and this problem would have been avoided (at the expense of several bytes, 
as Cyrus said).

Javier

---

From: "Darryl Champagne" <[email-masked]>
Date: Tue, 22 Jan 2008 22:23:35 -0500

_____  

From: Mark Paterson [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2008 4:26 PM
To: Cyrus Daboo
Cc: [email-masked]
Subject: Re: [VCARDDAV] New vcardrev draft

Cyrus Daboo wrote: 

Hi Mark, 

--On January 22, 2008 3:33:16 PM -0500 Mark Paterson
<mailto:[email-masked]> <[email-masked]> wrote: 

TAG1.ADR:... 
TAG2.ADR:... 
TAG1.TEL:... 
TAG2.TEL:... 

BEGIN:VCARD 
VERSION:4.0 

So if we use this scheme is there any need to track the old PIDs. e.g., in
the example above, lets say one client deletes the TEL property with
UID/PID=2. Then another client comes along and creates a new TEL property.
Should the new one have PID=2 or PID=3? i.e. does it matter that PID=2 gets
re-used for a "different" property? If there is a need to track old PIDs for
deleted properties, then that would complicate things a lot. 

I would much rather see the access protocol side of things dictate as to
wether these PIDs can be recycled. From an OMA DS perspective (which is of
course where my thinking comes from) my first instinct is to say that they
shouldn't be reccyled but as I think through some of the use cases it might
be possible. I'd really need to think through them some more.

If we _really_ want to be accommodating for Sync, we should be able to
clearly specify that we are only sending changes, rather than a replacement
for the entire vCard - that really cuts down on the data transferred (and
matches current practice in OMA DS).

Thus for example, to declare that this is an update from the 1997 version,
where phone 1 is changed, and phone 2 is deleted, one could have:

BEGIN:VCARD 
VERSION:4.0 
UID;TYPE=delta;LASTREV=1997-12-25:<This is that same globally unique ID as
before> 

TEL;PID=1;TYPE=voice,work:+1-418-656-1234

TEL;PID=2;

REV:2007-12-25 
END:VCARD 

In this example I included TYPE=delta in UID, but there are protocols (like
DS) that specify UIDs outside the vCard, so UID could be dropped.  However,
that would require a separate parameter to hold delta vs. add vs. full (or
whatever, plus the default could always be full).  Similarly the revision
that this is a delta off of (LASTREV above) would need to go elsewhere, as
another explanatory property.

I do realize that this opens a large can of worms (called sync :-) ) - I
personally would even be fine with a new type declaration, like /text/vcard;
type=delta (or whatever), which could even drop the BEGIN:VCARD etc. and
really be stripped down, but that is not my preference.

Regarding PID reuse, probably a SHOULD NOT be reused for new entries, keep
incrementing, would be best.

Thanks,

dgc

--

Darryl G. Champagne

Technology Evangelist

Funambol

AIM/Y!/Skype: dgc03052

ph: +1 (603) 424-0323     Mob: +1 (603) 440-3621 (+ SMS)

[email-masked]          http://www.funambol.com

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 23 Jan 2008 10:35:30 -0200

Darryl Champagne wrote,

> clearly specify that we are only sending changes, rather than a
> replacement for the entire vCard - that really cuts down on the data
> transferred (and matches current practice in OMA DS).
>
>UID;TYPE=delta;LASTREV=1997-12-25:
> <This is that same globally unique ID as before>

If I don't know the 1997 vCard I cannot recover it. This is not an issue if
I did and explicit request of a delta vCard, but it depends on the protocol
by means of which I'm accessing the vCard.
Do we want to send some reference to the full vCard? If that is the case, a
SOURCE parameter might be used.

Some incompatibilities between the proposed example and the current syntax:

* The FN property is REQUIRED, it has to be included even if we are
representing an "update" (unless it is made OPTIONAL).

* The empty values are not allowed (at least they are not allowed for most
properties). I think it must be allowed if we are going to deal with delta
vCard.

> In this example I included TYPE=delta in UID,

I would have used a different parameter name, since TYPE is already used for
overriding the default value type. Maybe REVISION?

>but there are protocols
> (like DS) that specify UIDs outside the vCard, so UID could be dropped.

Other protocols don't specify outer UIDs, therefore I would not drop it.
Since UID is an OPTIONAL property, it can be ommited if it is not
significant for the application context.

> However, that would require a separate parameter to hold delta vs. add vs.
> full (or whatever, plus the default could always be full).  Similarly the
> revision that this is a delta off of (LASTREV above) would need to go
> elsewhere, as another explanatory property.

I think them apply to the vCard as a whole, not only the UID property. Then
it would be better to include them as a property instead of a parameter
(same argument as used for the KIND property some days ago)

REVISION;lastrev=1997-12-25;delta

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 23 Jan 2008 10:38:36 -0200

Hi Cyrus,

On January 22, 2008 6:05 PM Cyrus Daboo wrote,

> This type of thing should be left out of the base spec

+1, then shoot the mailer.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Jan 2008 08:33:11 -0500

> incrementing, would be best.

I have the awful feeling that I'm going to say something stupid, but here 
goes:

If you just increment, the chances of a collision are very high. Example: I 
take one vcard, I have one copy of it on my phone and another on my PDA. I 
add one EMAIL on each. Bam, collision. If instead the PIDs had been a random 
integer taken from a large distribution then the chances of collision would 
have been much lower.

Ok, now let me say something even stupider: I don't understand how PIDs would 
be of any help in synchronization. Can someone enlighten me?

---

From: "Darryl Champagne" <[email-masked]>
Date: Wed, 23 Jan 2008 09:23:37 -0500

Hi,
The use case for PIDs and Sync ties in with only sending what has changed
(like OMA DS).  If I have 5 phone numbers, and one of them changes, what is
the minimum set of information that I can send?  If I can uniquely identify
which phone number changed (PID=5), then I could just send an update to that
one.  If I cannot uniquely identify the items, I must send all items in that
class, in this case send all 5 phone numbers again.  While that might not be
a huge amount of data in this example, it applies to every type of data that
might have multiples.

Regarding collision, that really is not a new issue, and I don't think
anything more than an incrementing number is needed (since you are talking
about a delta from something else).  If you are synchronizing data that has
been changed in multiple places, any and all data might be conflicting or
partially or fully replicated, and must be intelligently merged.
Additionally, in the mobile world there are lots of limitations on what can
be stored.  In the OMA DS world, it was recognized that there is no right
solution for this - it ends up being product specific.

For example, if you synchronize a simple phone and a more complicated
device, there is a frequent scenario where someone receives a phone call,
and stores the phone number with some simple tag (like dgc), and also
receives a business card (or gets emailed a vCard, if we want to be
optimistic), which ends up being stored on the more capable device.  In many
cases, the sync server needs to be able to figure out that these 2 records
are referring to the same entity and merge them (perhaps moving the dgc to
be a nickname).  What the user generally does not want is to now have 2
records with the same phone number.

In another case, you can have an already merged record (say with 3 phone
numbers), and you add one phone number on the device, and another on the
PC/Portal.  If the device has a fixed UI with an ordered view, then because
the user entered the number on the device in the 4th tel line, you want to
keep the device's new number as the 4th number, and make sure the
PC/Portal's new number becomes the 5th.  If the device can only
display/store 4 numbers, this may involve the server just keeping the 5th
number to itself.  What the user doesn't generally want is to lose the 4th
number, that was entered on the device.

As an example of device limitations, there are plenty of devices that have
limited number of possible phone numbers, limited lengths for various
fields, and so on.  What you must avoid is having a record be changed on the
device, and then sending that limited vCard back to the PC/Portal, and now
having a number of fields be truncated or deleted.  Adding a new phone
number should not truncate all the other fields, or the users get unhappy.
Unfortunately, from a protocol standpoint there is no way to identify that
the vCard from the device has had storage problems, so all sorts of extra
work is generally required from a Sync Server.

Hope this helps,
dgc

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2008 8:33 AM
To: [email-masked]
Subject: Re: [VCARDDAV] New vcardrev draft

Ok, now let me say something even stupider: I don't understand how PIDs
would 
be of any help in synchronization. Can someone enlighten me?

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Jan 2008 09:40:46 -0500

> The use case for PIDs and Sync ties in with only sending what has changed

Thanks a lot for the detailed info, I've been enlightened!

So if I understand correctly, the use case for PIDs implies sending partial 
vCards as updates. Otherwise there is no use for PIDs. Right?

If so, then we must also figure out how those updates will be represented. As 
Javier pointed out, you can't just use a plain vCard otherwise you'll be 
missing required properties that you don't necessarily want to send in the 
case of an update. Do we want something brand new, like BEGIN:VCDELTA or 
whatever, that is defined as a container for a vCard update? It would have 
different property requirements than a plain vCard.

How does that tie in with CardDAV? The current draft says explicitly that 
partial updates are not supported.

---

From: Mark Paterson <[email-masked]>
Date: Wed, 23 Jan 2008 10:03:40 -0500

> vCards as updates. Otherwise there is no use for PIDs. Right?
I wouldn't say that. If a server sends a device a vcard with 3 telephone 
numbers and later gets it sent back also with 3 telephone numbers there 
is no guarantee that the numbers are being sent back in the same order 
they were sent originally (there are some devices that reverse them). If 
they were all nicely tagged with UID=1, 2, 3 then it will be easy to 
match them up.

--

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 23 Jan 2008 13:12:04 -0200

It seems the requirements vary a lot depending on which context we are
deploying vCards.

----- Original Message ----- 
From: "Darryl Champagne" <[email-masked]>
To: "'Simon Perreault'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 23, 2008 12:23 PM
Subject: RE: [VCARDDAV] New vcardrev draft

> partially or fully replicated, and must be intelligently merged.

Here a timestamp on each property may help... it allows "intelligent merges"
but it requires a full date-time value *and* a PID.

> If you synchronize a simple phone and a more complicated

But the user may want to have different records for different people with
the same phone number... UID, or at least some other field such as FN or N
should match before concluding both record represent the same entity. I'm
afraid no solution is possible without side-effects.

The easier solution would be
1. Sync from device.
2. Merge both records (as specified by the user).
3. Sync again.

> number, that was entered on the device.

This could be achieved when synchronizing the device. It would detect there
are more numbers than it can handle, and no number was deleted, then it
would keep those which are already stored. It is an implementation feature.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Jan 2008 10:18:48 -0500

> they were all nicely tagged with UID=1, 2, 3 then it will be easy to

Yes, but what's the problem with getting back a vcard with properties not in 
the same order? Order shouldn't matter in a world without partial updates.

If the server sends

TEL;PID=1:1-418-656-1234
TEL;PID=2:1-418-656-5678

and gets back

TEL;PID=2:1-418-656-1234
TEL;PID=1:1-418-656-5678

what should it do?

---

From: Mark Paterson <[email-masked]>
Date: Wed, 23 Jan 2008 11:04:41 -0500

The issue is more when something like this happens.

If the server sends

TEL;TYPE=home:1-418-656-1234
TEL;TYPE=mobile:1-418-656-5678

and gets back as part of a REPLACE action

TEL:1-418-656-1234
TEL:1-418-656-5678

what should it do?

most servers will end up changing the home number to the mobile number and vice versa and the user is left trying to figure out what happened.

If the server sends

TEL;TYPE=home;UID=1:1-418-656-1234
TEL;TYPE=mobile;UID=2:1-418-656-5678

and gets back as part of a REPLACE action

TEL;UID=2:1-418-656-1234
TEL;UID=1:1-418-656-5678

The server can match things up properly.

Mark

--

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 23 Jan 2008 11:20:50 -0500

may I suggest to set the subject to some more precise subject instead  
of the last ~50 messages on "New vcardrev draft"?

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

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 23 Jan 2008 14:28:50 -0200

----- Original Message ----- 
  From: Mark Paterson 
  To: Simon Perreault 
  Cc: [email-masked] 
  Sent: Wednesday, January 23, 2008 2:04 PM
  Subject: Re: [VCARDDAV] New vcardrev draft

If the server sends

TEL:1-418-656-1234
TEL:1-418-656-5678

what should it do?

If the server sends

TEL;UID=2:1-418-656-1234
TEL;UID=1:1-418-656-5678

Mark1. If I want to remove type info (because I'm weird)
should I submit
  TEL;TYPE=;UID=1:1-418-656-1234
?

2. If I send a replace with
  TEL;TYPE=fax;UID=1:1-418-656-1234

what would be stored?
  TEL;TYPE=home,fax;UID=1:1-418-656-1234
or
  TEL;TYPE=fax;UID=1:1-418-656-1234

I think the latter makes sense, but one would have to repeat types which are already stored.

---

From: "Darryl Champagne" <[email-masked]>
Date: Wed, 23 Jan 2008 15:50:54 -0500

_____  

From: Javier Godoy [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2008 11:29 AM
To: [email-masked]
Subject: Re: [VCARDDAV] New vcardrev draft

----- Original Message ----- 

From:  <mailto:[email-masked]> Mark Paterson 

To:  <mailto:[email-masked]> Simon Perreault 

Cc:  <mailto:[email-masked]> [email-masked] 

 
If the server sends

 
TEL:1-418-656-1234
TEL:1-418-656-5678
 
what should it do?
 
most servers will end up changing the home number to the mobile number and
vice versa and the user is left trying to figure out what happened.
 
If the server sends

 
TEL;UID=2:1-418-656-1234
TEL;UID=1:1-418-656-5678

Mark

1. If I want to remove type info (because I'm weird)

should I submit

?

Two comments about this:

1)       The comment about returning less information than was originally
sent is a major issue with the vast majority of current phones.  It hasn't
been something desired, but rather something we have been stuck with.
Having seen how long it takes for features to propagate into mobile phones
(like all of the ones that still use vCal), my focus is on allowing simple
implementations to also be able to support the new format for communication,
while still allowing them to use their own internal representation.  Mass
market phones can easily track that the first slot in the UI/internal record
format will be called (x)ID 1, and has a single type (mobile, email, home).
All other information ends up being thrown away.

That is a reason that a simple ID seems better than a time-date stamp for
every field, and so on - we don't want to create a vast explosion in the
amount of data that would have to be stored.  One can argue that they won't
upgrade their format at all, so why bother to support low end phones, but
that would definitely be a self-fulfilling prophecy.  

Additionally, there are lots of big software applications that also use
their own internal record format, with all of its quirks (think Outlook).
Simple ID's can easily be supported by the implementation that accesses the
information, without adding a requirement for a lot of other data, that
likely is not ever collected.

2)       To support deltas, removing type information does need to be
addressed via changes, such as your example, and specifying empty values in
other places.

what would be stored?

or

I think the latter makes sense, but one would have to repeat types which are
already stored.

If you actually look at the semantics - you are saying REPLACE the first
number's type from "home", to be of type "fax" - you are not specifying to
merge them, so it definitely should be the latter.  

Note that it would be possible to define another type - merge vs. replace,
saying to take the new information and create a new superset of all the
information.  Not sure if that really has much value though, although one
could use it to send new information updates out without worrying about what
data people previously had - the classic "here is my new email address", put
it at the top of the list to use, but keep all the old info if you want
anyway. 

A trickier example is to start with:

And send a replace of:

  TEL;TYPE=fax;UID=2:1-418-656-1234

Phones want to be able to uniquely display contact information when they
receive a caller ID on an incoming call, so some of them do not allow the
same number to exist multiple times (anywhere).  On a slow sync (full sync,
backup, whatever your terminology is), you might get any of:

or:

or:

  TEL;TYPE=fax;UID=2:1-418-656-1234

Or the related permutations of ID and type.

dgc

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Jan 2008 16:38:39 -0500

On Tuesday 22 January 2008 16:10:52 Mark Paterson wrote:
> I really like the idea of making it any valid

I've been hacking at this a bit.

- Marc mentioned privately the existence of RFC 4833. It uses either POSIX TZ 
strings or the Olson database. And the Olson database is cited as a normative 
reference. So we're in the clear if we want to go that way.

- Using an iCalendar TZID value implies that the reader of the vCard can 
locate the corresponding VTIMEZONE component. How? We're not in an iCalendar 
context here, even if vCard and iCalendar are close cousins.

My gut feeling is that it's better to copy RFC 4833. It seems that there will 
be less ambiguity when restricted to POSIX TZ strings or Olson database 
entries. This way you can't say "Oh my vCard server defines America/Montreal 
to be something and your vCard server defines it otherwise but it's alright 
because the standard allows it." No. We want that string to have a meaning 
that all vCard users can agree on.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 29 Jan 2008 09:39:21 -0500

> "...or a non-standard image/audio format". So apparently you can put

I figured that the original wording wasn't clear enough. I changed it to "The 
TYPE parameter value MUST be an image media type as specified in [RFC4288]." 
So it would probably end up being image/jpeg in the case of PHOTO, but sure 
you can use image/x-wavelets-rule and we want to allow this. An 
implementation isn't expected to implement all existing image formats (!!!).

But there is a problem. PHOTO and LOGO use image media types, SOUND uses audio 
media types, but what does KEY use? The original text says "This parameter 
should specify an IANA registered public key or authentication certificate 
format." Where does IANA register those? Maybe it's because I'm a newbie, but 
I couldn't find that place. I've seen one implementation output "TYPE=PGP". 
That same implementation outputs "TYPE=image/jpeg" for PHOTO, which makes me 
doubt the validity of "PGP" as a format identifier.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 29 Jan 2008 10:10:06 -0500

Hi Simon,

--On January 29, 2008 9:39:21 AM -0500 Simon Perreault 
<[email-masked]> wrote:

> I figured that the original wording wasn't clear enough. I changed it to
> "The  TYPE parameter value MUST be an image media type as specified in
> [RFC4288]."  So it would probably end up being image/jpeg in the case of
> PHOTO, but sure  you can use image/x-wavelets-rule and we want to allow
> this. An
> But there is a problem. PHOTO and LOGO use image media types, SOUND uses
> audio  media types, but what does KEY use? The original text says "This
> parameter  should specify an IANA registered public key or authentication
> certificate  format." Where does IANA register those? Maybe it's because
> I'm a newbie, but  I couldn't find that place. I've seen one
> implementation output "TYPE=PGP".  That same implementation outputs
> "TYPE=image/jpeg" for PHOTO, which makes me  doubt the validity of "PGP"
> as a format identifier.

application/pgp-keys is defined in RFC3156. That covers PGP certs.

application/pkcs7-mime is defined in RFC2311 (Section 3.6). That covers 
S/MIME certs.

There is also:

application/pkix-cert is defined in RFC2585.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 29 Jan 2008 12:17:31 -0500

> standards which define how to specify an address should be examined for

I had a bit of fun with the ADR property. Here are some problems I identified:

- What is "extended address"? Is it an English idiom? At least one 
implementation of vCard 3.0 never uses it. I cannot find any reference to it 
in X.520.

Instead, X.520 has the house identifier field:

"The House Identifier attribute type specifies a linguistic construct used to 
identify a particular building, for example a house number or house name 
relative to a street, avenue, town or city, etc."

This is strange because it's redundant with the street address. Anyway, is 
this what is referred as extended address? If so, we should change the 
wording. If not, and nobody knows, and we cannot find an implementation that 
uses this field, we should change it to house identifier anyway because 1) it 
would make sense and 2) we'd be closer to X.520, which is a good thing.

- I couldn't find any reference to the address types (i.e. postal, parcel, 
intl, etc.) in X.520. It looks like something vCard-specific. The values 
obviously lack non-ambiguous descriptions. X.520 doesn't list anything like 
that.

In my experience, a postal address is a postal address. Types 
like "dom", "intl", "postal", and "parcel" seem like they could be useful for 
someone doing some kind of heavy shipment of merchandise. Not something for 
which you would use vCard I guess. Do you people disagree?

So if we agree on that I propose to remove them from the base spec altogether. 
The types "work", "home", and "pref" would remain.

---

From: "Javier Godoy" <[email-masked]>
Date: Tue, 29 Jan 2008 15:45:26 -0200

Hi Simon,

----- Original Message ----- 
From: "Simon Perreault" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 29, 2008 12:39 PM
Subject: [VCARDDAV] Media type for PHOTO, LOGO, SOUND, and KEY

> "The

+1

> you can use image/x-wavelets-rule and we want to allow this.

Strictly, it is not allowed because TYPE values are required to be IANA
*registered* image types, (per ABNF rules for img-refer-param and
img-inline-param). As implied by your modification above, the x- subtypes,
which are not registered, should be allowed too.

> audio

Actually, we have:

  keytype      = "X509" / "PGP" / iana-token / x-name

   iana-token   = 1*(ALPHA / DIGIT / "-")
      ; identifier registered with IANA

  x-name       = "x-" 1*(ALPHA / DIGIT / "-")

As Cyrus wrote,

>application/pkix-cert is defined in RFC2585.

They are not "tokens" (because of the "/" character). Besides, the token
"x-foo-key" is allowed (per x-name), but "application/x-foo-key" is not,
because it matches neither iana-token nor x-name.
(Btw, the "x-name" sounds as reinventing the experimental tree for media
types).

Since iana-token is also used in other productions, such as "param-name" and
the "CLASS" value, it would be unwise to change it. The solution used by
img-inline-param et al. is specifying

  param-value  = ptext / quoted-string

plus restrictions in natural language.

We might define a construction (e.g., "iana-type") in the ABNF for dealing
with this situations. With this modification, the keytype can be expressed
as

keytype      = "X509" / "PGP" / iana-type

;I didn't found this ABNF in RFC 4288
iana-type = type-name "/" subtype-name

;from RFC 4288
type-name = reg-name
subtype-name = reg-name

reg-name = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" /
                       "#" / "$" / "&" / "." /
                       "+" / "-" / "^" / "_"

Note: this drops iana-token / x-name from keytype...

Javier

---

From: "Javier Godoy" <[email-masked]>
Date: Tue, 29 Jan 2008 16:14:22 -0200

On Tuesday, January 29, 2008 3:17 PM Simon Perreault wrote,

> would make sense and 2) we'd be closer to X.520, which is a good thing.

It could serve for distinguish apartments, floors, offices, etc., which are 
in the same building (i.e., at the same street address). I don't know how 
they are represented in X.520, but it would be the only place within ADR 
where I would write them.

+1

---

From: Simon Perreault <[email-masked]>
Date: Tue, 29 Jan 2008 14:03:08 -0500

> which are not registered, should be allowed too.

Thanks for pointing this out. I modified the ABNF rules as follows:

  img-inline-param     = ("VALUE" "=" "binary")
                        / ("ENCODING" "=" "b")
                        / ("TYPE" "=" param-value
        ;TYPE value MUST be an image media type as defined in RFC 4288

  img-refer-param      = ("VALUE" "=" "uri")
                        / ("TYPE" "=" param-value)
        ;TYPE value MUST be an image media type as defined in RFC 4288

> with this situations. With this modification, the keytype can be expressed

Currently I changed keytype to simply be a param-value.

    keytype      = param-value
         ; Type MUST be a media type as defined in RFC 4288

I think specifying the syntactic details of a media type name is not going to 
be useful for a vCard parser writer, and it might make the spec overly 
complicated.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 29 Jan 2008 14:22:06 -0500

> where I would write them.

I see at 
http://209.85.207.104/search?q=cache:Ep2yAsjmUt4J:www.cellml.org/meeting_minutes/archive/20010406_meeting_minutes.pdf/download+vcard+adr+%22extended+address%22&hl=en&ct=clnk&cd=9&gl=ca&client=firefox-a 
that "This is used to include the company or institution name."

Hmmm... dubious.

Examples of using extended address for apartment or suite number:
http://nutrun.com/weblog/category/microformats/
http://www.imc.org/pdi/vcard-21.txt

I agree that this makes the most sense from an implementor point of view. So I 
suggest we just tag the description with "(e.g. apartment or suite number)" 
and be done with it.

> > The types "work", "home", and "pref" would remain.

BTW, the same will be done for LABEL.