Re: [VCARDDAV] LANGUAGE parameter vs. cardinality and PIDs

[Cyrus Daboo <[e-mail]>]

Hi Simon,

--On April 7, 2010 8:54:24 AM -0400 Simon Perreault 
<[e-mail]> wrote:

>> So the idea of "alternative" vCards for language is problematic.
>
> I'm not convinced of that yet.
>
> Isn't it basically the same idea as having alternative sub-components
> like in iCalendar?

I think there is a big problem with a client getting three vcards that are 
alternatives for the same person. How is the client going to know that (if 
the UIDs are different)? If the UIDs are the same it would need to know 
that they are alternatives by looking at the LANGUAGE property.

How would I send or publish multiple alternatives? Would I have to send 
them all via email when I don't know the recipient's preferred language? 
Would I have to have multiple links on a webpage for each variant?

The other big issue is with authoring these. Do the alternatives contain 
the same set of non-localized data? e.g., the TEL values are not likely to 
be different from alternative to alternative. Is a client really expected 
to keep the multiple alternative vcard objects in sync with every change to 
a non-localized property? I think that is asking too much of the client and 
would be a big waste of bandwidth for protocols like CardDAV. Keeping all 
the localized properties in the one vcard would be much more efficient.

The more I think about this from a client perspective the more I dislike 
the idea of multiple alternative vcards. Lets figure out a way to make the 
LANGUAGE parameter work.

-- 
Cyrus Daboo