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

Barry Leiba <barryleiba.mailing.lists@gmail.com> Wed, 21 July 2010 14:55 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
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 397B83A687A for <vcarddav@core3.amsl.com>; Wed, 21 Jul 2010 07:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.436
X-Spam-Level:
X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_05=-1.11, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6]
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 qqXYDdPnSFcE for <vcarddav@core3.amsl.com>; Wed, 21 Jul 2010 07:55:29 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C4F2A3A6774 for <vcarddav@ietf.org>; Wed, 21 Jul 2010 07:55:28 -0700 (PDT)
Received: by ewy22 with SMTP id 22so2606841ewy.31 for <vcarddav@ietf.org>; Wed, 21 Jul 2010 07:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xE6uVdNrob7fqhbJzaWwrBbjNhGnc3kXpgvno2zYxug=; b=doq36CPdf1emPTbZntA0h/tbtsWeerN+Hxo2BFviqlDWYuO+NYn4nUlL6uBBlLPMZf lDTWXbT5moC1gymKSWGD+G4jq3D0soTVkSCdHHyHcOfM/fRRH7zVwalQl5IfTRrGfsB+ s6N8w7XUhtO6yOqKrGU7bvJyml2n+3vOFbUpc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=wpRbb7ZyHBJlqaf1rf7yN9IxAYEe+Rw6Ya8TTGfK4yRsqbTC50sZyWez1SF5jR6S+u QFKU4vaTK64+P/G4y7eW2MBuXKZNAdg3nUbVDX2lJJ4HhBSCSNZKI/QA3o41/k8VN8D3 lY/Dfo/XrGH7xLfM8Dh8ezINnt9jL+O9nhfQo=
MIME-Version: 1.0
Received: by 10.213.108.71 with SMTP id e7mr353364ebp.19.1279724144602; Wed, 21 Jul 2010 07:55:44 -0700 (PDT)
Received: by 10.42.1.136 with HTTP; Wed, 21 Jul 2010 07:55:44 -0700 (PDT)
In-Reply-To: <5334F2C6D20F4495800A900F77F205A9@Javier2>
References: <20100712153053.60EA53A699C@core3.amsl.com> <4C3B3F2D.1000708@viagenie.ca> <4C3B63B8.80507@viagenie.ca> <4C431086.2080706@atlantika-arts.net> <5334F2C6D20F4495800A900F77F205A9@Javier2>
Date: Wed, 21 Jul 2010 10:55:44 -0400
Message-ID: <AANLkTinP7Gt7-6kJ4XrGg2kfIHXvTSeyArODHArUoUwR@mail.gmail.com>
From: Barry Leiba <barryleiba.mailing.lists@gmail.com>
To: vcarddav@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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
Reply-To: barryleiba@computer.org
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 14:55:30 -0000

> Note however that the following example is legal because there are two
> instances of TITLE:
>
> TITLE;LANGUAGE=fr:Patron
> TITLE:Something else

I worry about this situation, because (1) it feels like an error --
and it's likely that it would usually be an error, rather than an
intended situation, and (2) it's an error that's very easily made.

The problem is that I *can* see situations where it would be
intentional.  For example, if we expand the example above:

  TITLE;LANGUAGE=fr:Directeur de la recherche
  TITLE;LANGUAGE=en:Director of Research
  TITLE:Chair, vCardDAV working group

Here we clearly have two different titles, one of which is presented
in two languages, and the other of which is presented in an
unspecified language.

On the other hand, this one is clearly an error ("clearly", as the
eye, not the computer, sees it):

  TITLE;LANGUAGE=fr:Directeur de la recherche
  TITLE;LANGUAGE=en:Director of Research
  TITLE:Direktor für Forschung

If the default language for this vCard is German, we can see how this
happened.  The trouble is that the computer can't distinguish these
cases, and we have to rely on the creator of the vCard to get it
right.  Hm.  How has that worked out for us in the past?

>> The specification says in "5.1. LANGUAGE":
>>
>>  Properties with different LANGUAGE parameters that represent the same
>>  data count as 1 toward cardinality [...]
>>
>> From this one could assume that the same data could be represented by
>> two entries of the same property with one present and one absent
>> LANGUAGE parameter, because the LANGUAGE parameters are obviously
>> different. The value for the absent LANGUAGE parameter (if needed at
>> all) could come from the MIME header.
>
> I think your interpretation is technically right, but I wouldn't like
> depending on an external MIME header in order to determine the validity of
> the vCard instance.
> For instance, the following example would be legal only if Content-Language
> is different from "fr":
> BIRTH;LANGUAGE=fr:Ville de Quebec
> BIRTH:Quebec City
>
> Perhaps we should require that [[
> Properties with no PID and no LANGUAGE parameters are logically different
> from any other property, thus each occurence count as 1 towards cardinality.
> ]]

How about this text, just to really drive the point home:
-----------------------------------------
OLD
   Properties with different LANGUAGE parameters that represent the same
   data count as 1 toward cardinality and MUST have the same PID value
   if the PID parameter is used.  This is because there is logically a
   single property which is expressed in multiple languages.

   Therefore, since BIRTH [...]

NEW
   Properties with different LANGUAGE parameters that represent the same
   data count as 1 toward cardinality and MUST have the same PID value
   if the PID parameter is used.  This is because there is logically a
   single property which is expressed in multiple languages. Properties with
   no PID and no LANGUAGE parameters are logically different from any
   other property, thus each occurence count as 1 towards cardinality.

   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.  An absent (or erroneously missing) LANGUAGE parameter
   creates a new value, unrelated to the others (or constitutes an error, if the
   PID parameters are the same).

   For example, this represents someone with two different titles, the first of
   which is presented in two languages:
      TITLE;LANGUAGE=fr:Directeur de la recherche
      TITLE;LANGUAGE=en:Director of Research
      TITLE:Chair, vCardDAV working group

   This represents someone with one title, presented in three languages:
      TITLE;LANGUAGE=fr:Directeur de la recherche
      TITLE;LANGUAGE=en:Director of Research
      TITLE:LANGUAGE=de:Direktor für Forschung

   And this is probably an error, because the German version is missing its
   LANGUAGE parameter:
      TITLE;LANGUAGE=fr:Directeur de la recherche
      TITLE;LANGUAGE=en:Director of Research
      TITLE:Direktor für Forschung

   Because such errors are not automatically detectable, extra care is
   needed to get this right.

   Since BIRTH [...]
-----------------------------------------

Barry