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

Markus Lorenz <lorenz@atlantika-arts.net> Wed, 21 July 2010 18:40 UTC

Return-Path: <lorenz@atlantika-arts.net>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566023A6A6B for <vcarddav@core3.amsl.com>; Wed, 21 Jul 2010 11:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP4xZz7ByXoD for <vcarddav@core3.amsl.com>; Wed, 21 Jul 2010 11:40:51 -0700 (PDT)
Received: from host46.sitepush.net (server20.server-centrum.de [213.239.241.46]) by core3.amsl.com (Postfix) with ESMTP id A947F3A6A15 for <vcarddav@ietf.org>; Wed, 21 Jul 2010 11:40:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by host46.sitepush.net (Postfix) with ESMTP id BAFAC1FA0003 for <vcarddav@ietf.org>; Wed, 21 Jul 2010 20:41:05 +0200 (CEST)
Received: from host46.sitepush.net ([127.0.0.1]) by localhost (server20.server-centrum.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Bdz0Z1sZZv for <vcarddav@ietf.org>; Wed, 21 Jul 2010 20:41:05 +0200 (CEST)
Received: from [192.168.0.101] (g224237171.adsl.alicedsl.de [92.224.237.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by host46.sitepush.net (Postfix) with ESMTP id 70BC41FA0001 for <vcarddav@ietf.org>; Wed, 21 Jul 2010 20:41:05 +0200 (CEST)
Message-ID: <4C473F3D.4040404@atlantika-arts.net>
Date: Wed, 21 Jul 2010 20:41:01 +0200
From: Markus Lorenz <lorenz@atlantika-arts.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1
MIME-Version: 1.0
To: vcarddav@ietf.org
References: <20100712153053.60EA53A699C@core3.amsl.com> <4C3B3F2D.1000708@viagenie.ca> <4C3B63B8.80507@viagenie.ca> <4C431086.2080706@atlantika-arts.net> <5334F2C6D20F4495800A900F77F205A9@Javier2> <AANLkTinP7Gt7-6kJ4XrGg2kfIHXvTSeyArODHArUoUwR@mail.gmail.com> <4C470C06.4030108@viagenie.ca> <96E5AEAD8BC1B8D3AE8D0217@caldav.corp.apple.com>
In-Reply-To: <96E5AEAD8BC1B8D3AE8D0217@caldav.corp.apple.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-12.txt
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 18:40:52 -0000

Am 21.07.2010 20:12, schrieb Cyrus Daboo:
> Hi Simon,
> 
> --On July 21, 2010 11:02:30 AM -0400 Simon Perreault
> <simon.perreault@viagenie.ca> 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