Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-12.txt

[Markus Lorenz <[e-mail]>]

Am 21.07.2010 20:12, schrieb Cyrus Daboo:
> Hi Simon,
> 
> --On July 21, 2010 11:02:30 AM -0400 Simon Perreault
> <[e-mail]> wrote:
> 
>>>    One must be particularly careful when using LANGUAGE parameters with
>>>    properties that may have cardinality greater than one.  If a LANGUAGE
>>>    parameter is specified on ANY instance of such a property, then one
>>>    MUST be specified on ALL instances that are translations of the same
>>>    property value.
>>
>> +1, with "and MUST have a PID parameter with the same value".
>>
>> The PID parameter is useful in case you have this:
>>
>> TITLE;LANGUAGE=fr:Directeur de la recherche
>> TITLE;LANGUAGE=en:Director of Research
>> TITLE;LANGUAGE=fr:Président, groupe de travail vCardDAV
>> TITLE;LANGUAGE=en:Chair, vCardDAV working group
>>
>> Here you can't reliably know which one goes with which without the PID
>> parameter. Better:
>>
>> TITLE;LANGUAGE=fr;PID=1:Directeur de la recherche
>> TITLE;LANGUAGE=en;PID=1:Director of Research
>> TITLE;LANGUAGE=fr;PID=2:Président, groupe de travail vCardDAV
>> TITLE;LANGUAGE=en;PID=2:Chair, vCardDAV working group
> 
> What about the group prefix? That could also be used to group language
> variants:
> 
> GRP1.TITLE;LANGUAGE=fr:Directeur de la recherche
> GRP1.TITLE;LANGUAGE=en:Director of Research
> GRP2.TITLE;LANGUAGE=fr:Président, groupe de travail vCardDAV
> GRP2.TITLE;LANGUAGE=en:Chair, vCardDAV working group

Section 3.2 says:

   The group name is a syntactic convention used to indicate that all
   property names prefaced with the same group name SHOULD be grouped
   together when displayed by an application.  It has no other
   significance.  Implementations that do not understand or support
   grouping MAY simply strip off any text before a "." to the left of
   the type name and present the types and values as normal.

For my understanding the group construct should only be used to build
groups of properties which have a meaning to the user.

   [...] grouped together when displayed [...]. It has no other
   significance.

Therefore I don't think we should use groups to solve internal issues.

There would also be a problem for implementations that don't understand
or support the grouping, which is allowed. Those implementations
wouldn't be able to handle the LANGUAGE parameter correctly.

Best regards


Markus