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

From: Simon Perreault <[email-masked]>
Date: Tue, 06 Apr 2010 08:53:52 -0400

Dearest working group,

Florian Zeitz uncovered a big problem related to the LANGUAGE parameter:

> I'm a bit unclear on the usage of the LANGUAGE param. Is it
> possible/intended to have the same property in different languages?
> E.g.:
> BIRTH;LANGUAGE=de-DE:Köln
> BIRTH;LANGUAGE=en-US:Cologne
> If it is this won't integrate nicely with properties with Cardinality
> (0,1) or (1,1) and PIDs.
> If this usage is however not expected I think it would be useful to
> explicitly state this.

He's referring to this text specifying the PID parameter:

> It MUST NOT appear on properties that only may have one instance per vCard.

It turns out that BIRTH is specified with cardinality (0,1) and so 
cannot have a PID, but the above example should be allowed.

So what do we do? I see two options:

1. Replace the LANGUAGE parameter with a LANGUAGE property, making 
vCards monolingual.

2. Specify how the LANGUAGE parameter affects cardinality (i.e. 
cardinality applies to same-language sets of property instances). Allow 
PID to apply to all properties.

Is the language tag very much used currently? Do we think it is 
important that a vCard can be multilingual?

I think a LANGUAGE property would have more chance of being used. And 
since it simplifies things, and I like simplicity, I like #1 more at 
this point.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Apr 2010 00:09:12 -0400

> I think a LANGUAGE property would have more chance of being used. And since
> it simplifies things, and I like simplicity, I like #1 more at this point.

D'accord.

Barry

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 7 Apr 2010 08:05:11 -0300

Hi Simon,

----- Original Message ----- 
From: "Simon Perreault" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 06, 2010 9:53 AM
Subject: [VCARDDAV] LANGUAGE parameter vs. cardinality and PIDs

>It turns out that BIRTH is specified with cardinality (0,1) and so cannot 
>have a PID, but the above example should be allowed.
>
>1. Replace the LANGUAGE parameter with a LANGUAGE property, making vCards 
>monolingual.
>

The problem with this approach is that versions in different languages may be 
out of sync (for instance, I modify EMAIL or TEL in the en-vCard, but I don't 
in the es-vCard or the fr-vCard)

If #1 is applied, we also need a new value for the RELATED type, such as 
"translation" or "self", for linking vCards instances describing the same 
individual in diferent languages.

RELATED;TYPE=self:http://example.com/directory/en/jdoe.vcf
RELATED;TYPE=self:http://example.com/directory/fr/jdoe.vcf
RELATED;TYPE=self:http://example.com/directory/en/jdoe.vcf

Note that clients won't know which vCard is in which language, before 
retrieving the instance (we might add a language-param for this case)

Content-negotiation MAY be used, if it is defined for the URI scheme. In that 
case we would have just one "self" vCard URI.
RELATED;TYPE=self:http://example.com/directory/jdoe.vcf

>2. Specify how the LANGUAGE parameter affects cardinality (i.e. cardinality 
>applies to same-language sets of property instances). Allow PID to apply to 
>all properties.
>
>Is the language tag very much used currently? Do we think it is important 
>that a vCard can be multilingual?
>

Best Regards,

Javier

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Apr 2010 07:58:59 -0400

On 2010-04-07 07:05, Javier Godoy wrote:
> The problem with this approach is that versions in different languages
> may be out of sync (for instance, I modify EMAIL or TEL in the en-vCard,
> but I don't in the es-vCard or the fr-vCard)

Yes, but the same problem could also happen for multiple instances of 
the same property in different languages...

> "translation" or "self", for linking vCards instances describing the
> same individual in diferent languages.
>

I think that's a good idea.

> retrieving the instance (we might add a language-param for this case)

With CardDAV we can retrieve only the LANGUAGE property for all the 
related vCards in a single REPORT query with addressbook-multiget. So I 
don't see this as a problem. (And not repeating data could be considered 
desirable.)

> Content-negotiation MAY be used, if it is defined for the URI scheme. In
> that case we would have just one "self" vCard URI.

Yes, but that's implementation-specific.

I would also envision using urn:uuid: URIs instead of http: URIs...

Thanks,
Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 07 Apr 2010 08:41:07 -0400

Hi Simon,

> don't see this as a problem. (And not repeating data could be considered

One big question is what would the UID values be for all the "alternative" 
cards? Are they all the same or different. If they are the same that would 
pose a big problem for CardDAV as that requires the UID values to be unique 
within an address book collection. But the definition of UID in the draft 
implies that it is unique to "the individual or resource associated with 
the vCard" - which would suggest that the alternatives all have the same 
UID.

So the idea of "alternative" vCards for language is problematic.

In iCalendar we have been thinking about how to handle multiple languages 
(the event publishing folks are very keen to present multi-lingual event 
information). One option we have in iCalendar is to create new 
"sub-components" for the language variants, e.g.:

BEGIN:VEVENT
...
SUMMARY:English
...
BEGIN:LOCALE
LANGUAGE:fr_FR
SUMMARY: Francais
...
END:LOCALE
BEGIN:LOCALE
LANGUAGE:de_DE
SUMMARY:Deutsch
...
END:LOCALE
END:VEVENT

Clients that were aware of the new components could use the properties in 
their locale-specific one to "override" the values in the "base" component. 
Clients unaware would just fall back to using the "base" values. There are 
lots of issues that would have to be worked out with this approach, but it 
is convenient in that the entire event and all localizations are contained 
in one component.

Unfortunately, in vCard we don't (currently) have the concept of a 
sub-component that would allow us to easily do something like this.

At the end of the day I think we need to find a way to make the current 
LANGUAGE parameter work. If that means stating up front that the 
"cardinality" of properties can be "overridden" by LANGUAGE alternatives, I 
think that is fine.

However, one issue with the current scheme is dealing with items with 
cardinality > 1. For example I could today have multiple ORG properties 
with different LANGUAGE parameters. Does that mean they are alternatives, 
or separate? To resolve that ambiguity there would need to be a unique 
identifier on properties that would be the same on LANGUAGE alternatives.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Apr 2010 08:54:24 -0400

On 2010-04-07 08:41, Cyrus Daboo wrote:
> One big question is what would the UID values be for all the
> "alternative" cards? Are they all the same or different.

I was assuming they would be different...

 > But the
> definition of UID in the draft implies that it is unique to "the
> individual or resource associated with the vCard" - which would suggest
> that the alternatives all have the same UID.

We can fix that description easily enough.

> 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?

> with different LANGUAGE parameters. Does that mean they are
> alternatives, or separate? To resolve that ambiguity there would need to
> be a unique identifier on properties that would be the same on LANGUAGE
> alternatives.

Yes! That's a big problem that would be solved by replacing the LANGUAGE 
parameter with a LANGUAGE property.

Simon

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 7 Apr 2010 12:20:23 -0300

Hi Simon,

> Yes, but the same problem could also happen for multiple instances of the 
> same property in different languages...

It is not the same problem, as I'm not talking about modifying the 
language-versioned property, but another different property that is intended 
to have the same value in every instance. For example, modifying EMAIL in:

BEGIN:VCARD
VERSION:4.0
FN:John Doe
EMAIL:: [email-masked]
END:VCARD

BEGIN:VCARD
VERSION:4.0
FN:John Doe
EMAIL:: [email-masked]
END:VCARD

Clearly it is not an issue if multiple instances of the same property in 
different languages are allowed:

BEGIN:VCARD
VERSION:4.0
FN:John Doe
EMAIL:: [email-masked]
END:VCARD

> With CardDAV we can retrieve only the LANGUAGE property for all the related 
> vCards in a single REPORT query with addressbook-multiget. So I don't see 
> this as a problem. (And not repeating data could be considered desirable.)

What do you mean by "not repeating data"? Actually this approach asks for 
repeating data, as FN and EMAIL in my example above.

> Yes, but that's implementation-specific.

Yes and no. The value of RELATED would not be a URI identifying a single vCard 
instance (as I understand it is the intent of RELATED), but a *set* of 
instances (with the actual instance being decided by the negotiation 
mechanism). If it is allowed, it should be explicitly stated.

Best regards

Javier

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 7 Apr 2010 12:57:34 -0300

Hi Simom

From: "Simon Perreault" <[email-masked]>
Sent: Wednesday, April 07, 2010 9:54 AM

> I was assuming they would be different...

Me too. They would be alternative independent instances about the same 
individual.

>> be a unique identifier on properties that would be the same on LANGUAGE

May we reuse PID? (assuming that the cardinality restriction is relaxed)
This would require including the value of LANGUAGE into the definition of 
"same property" according to the syncrhonization mechanism

Hence
  ORG;PID=1;LANGUAGE=en-US
would be a different from
  ORG;PID=1;LANGUAGE=en-AR

> parameter with a LANGUAGE property.

No, it is still an issue. In the following example:
 - ¿Which is the translation of "Organization 1" and "Organization 2" in the 
es-AR vCard? (suppose I was fired from "Organization 1" and I want to remove 
thar value from all my instances)
 - If "Organization 3" is not translated into Spanish, does it means that I'm 
member of 3 organizations for users with en-US locale, and I'm member of 2 
organization for users with es-AR locale? Or it is just that Organization 3 
was not translated into Spanish, though I'm a member of that organization?

BEGIN:VCARD
VERSION:4.0
UID:urn:uuid:aad6190c-7193-4daf-a670-0090713aa006
RELATED;TYPE=self:urn:uuid:23e20f71-57f9-49fa-9455-f905d27d2382
FN:John Doe
ORG: Organization 1
ORG: Organization 2
ORG: Organization 3 (which I forgot to translate into Spanish)
LANGUAGE:en-US
END:VCARD

BEGIN:VCARD
VERSION:4.0
UID:urn:uuid:23e20f71-57f9-49fa-9455-f905d27d2382
RELATED;TYPE=self:urn:uuid:aad6190c-7193-4daf-a670-0090713aa006
FN:John Doe
ORG: Organización 1
ORG: Organización 2
LANGUAGE:es-AR
END:VCARD

BEGIN:VCARD
VERSION:4.0
UID:urn:uuid:8cbf72b1-d10d-475f-a4b4-52174af50e2c
FN:John Doe
ORG;PID=1;LANGUAGE=es-AR: Organización 1
ORG;PID=2;LANGUAGE=es-AR: Organización 2
ORG;PID=1;LANGUAGE=en-US: Organization 1
ORG;PID=2;LANGUAGE=en-US: Organization 2
ORG;PID=3;LANGUAGE=en-US: Organization 3 (which I forgot to translate into 
Spanish)
END:VCARD

Best Regards

Javier

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 07 Apr 2010 12:10:54 -0400

Hi Simon,

> Isn't it basically the same idea as having alternative sub-components

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Apr 2010 12:18:31 -0400

On 2010-04-07 11:20, Javier Godoy wrote:
> language-versioned property, but another different property that is
> intended to have the same value in every instance. For example,
> modifying EMAIL in:
>
> BEGIN:VCARD
> VERSION:4.0
> FN:John Doe
> EMAIL:: [email-masked]

Ok I understand.

But this issue would be solved by the client application, which would 
present a unified interface with only a single email field.

> What do you mean by "not repeating data"? Actually this approach asks
> for repeating data, as FN and EMAIL in my example above.

You're right. I was referring to the LANGUAGE property in each vCard and 
your proposed LANGUAGE parameter for the RELATED property. Clearly there 
would be more repeated data with separate vCards, and I don't like this.

> Yes and no. The value of RELATED would not be a URI identifying a single
> vCard instance (as I understand it is the intent of RELATED), but a
> *set* of instances (with the actual instance being decided by the
> negotiation mechanism). If it is allowed, it should be explicitly stated.

Ah, right. If we choose to go this way, I'll make sure to mention it.

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Apr 2010 12:21:17 -0400

On 2010-04-07 11:57, Javier Godoy wrote:
> - ¿Which is the translation of "Organization 1" and "Organization 2" in
> the es-AR vCard? (suppose I was fired from "Organization 1" and I want
> to remove thar value from all my instances)
> - If "Organization 3" is not translated into Spanish, does it means that
> I'm member of 3 organizations for users with en-US locale, and I'm
> member of 2 organization for users with es-AR locale? Or it is just that
> Organization 3 was not translated into Spanish, though I'm a member of
> that organization?

You're right.

At this moment I have no idea how to resolve this issue, and I think it 
is important enough that we cannot go with the LANGUAGE property solution.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Apr 2010 12:29:54 -0400

On 2010-04-07 12:10, Cyrus Daboo wrote:
> the idea of multiple alternative vcards. Lets figure out a way to make
> the LANGUAGE parameter work.

Agreed.

Would the following be sufficient?

Properties with different LANGUAGE parameters that represent the same 
data...
   - ...count as 1 toward cardinality.
   - ...have the same PID value if the PID parameter is used.

Therefore, since BIRTH has cardinality (0,1), this would be legal:

BIRTH;LANGUAGE=fr:Ville de Québec
BIRTH;LANGUAGE=en:Quebec City

while these three would not:

BIRTH;PID=1;LANGUAGE=fr:Ville de Québec
BIRTH;PID=1;LANGUAGE=en:Quebec City

BIRTH;PID=1;LANGUAGE=fr:Ville de Québec
BIRTH;PID=2;LANGUAGE=en:Quebec City

BIRTH;LANGUAGE=fr:Ville de Québec
BIRTH:Quebec City

Simon

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 8 Apr 2010 08:20:54 -0300

>   - ...have the same PID value if the PID parameter is used.

+1 for me.

* It allows several instances of a property with cardinality (0,1), as long as 
each instance has its own language. This makes sense because every instance of 
BIRTH is sematically equivalent to any other instance of BIRTH, then it is 
still (0,1) from that point of view.

* It also applies to properties with cardinality (0,n) such as ORG, and helps 
processing translations of a property (e.g. removing all the instances of 
ORG;PID:1).

* Synchronization is well defined (the same properties on matching vCard and 
with the same PID match if both has no LANGUAGE parameter, or the value of the 
LANGUAGE parameter is the same). Alternatively, it might be defined that the 
same properties with the same PID match "as a whole" (e.g. the set of ORG 
properties with PID 1, or the set of BIRTH properties), and that the action to 
be performed over each property instance is left at the discretion of the 
synchronization engine.

> BIRTH;LANGUAGE=fr:Ville de Québec

I would add the following case to the set of illegal values:
BIRTH;LANGUAGE=fr:Ville de Québec
BIRTH;LANGUAGE=en:Quebec City
BIRTH;LANGUAGE=en:Anything

(otherwise it would mean that cardinality is not 0,1)

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Apr 2010 07:56:33 -0400

> BIRTH;LANGUAGE=en:Anything

Thanks, that's a very good example!

Simon