Re: [VCARDDAV] Miscellaneous comments

Tantek Çelik <tantek@cs.stanford.edu> Mon, 19 July 2010 22:29 UTC

Return-Path: <tantek@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 91B283A6B91 for <vcarddav@core3.amsl.com>; Mon, 19 Jul 2010 15:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
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 35IzuEDMrBY4 for <vcarddav@core3.amsl.com>; Mon, 19 Jul 2010 15:29:54 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 0719A3A6980 for <vcarddav@ietf.org>; Mon, 19 Jul 2010 15:29:53 -0700 (PDT)
Received: by pxi20 with SMTP id 20so2963752pxi.31 for <vcarddav@ietf.org>; Mon, 19 Jul 2010 15:30:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=CdLAm2HivDBWxrdkx2fZRLQfi1EUPaxMMkrRBEGhA3I=; b=DuaDLXSRL/5czc6lcQCNFCWyE/Xqbtmu49KHOTyghT1uXe9L9N7H3kCfvxRbvpj6k6 /sNDWeAFEhkE9rXGS2zL18b2qBRgSjcXktVcmieheCE/TM0PKIGdrLQkYVJprgUugDsB aX7G/HFi2h0h6qMdUS3dfmO2i3jXdm2BzSEg0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=gXKVrTrxeVB6o8JHABU0UC/WzpelB3gUpcY8dbh3bRFdWypWYqSI5GGeep6DfyzS28 K6wYQEhP0pCpwwGatpkFwDhCIvsd6g4Z9aAqtunxTrhMt6TcSFvVuodpkrx5Cb9wzFtI vgo7Mo+53d7VLGChO3Crc73wCLnDKqrOTKolQ=
Received: by 10.142.231.12 with SMTP id d12mr4015542wfh.341.1279578608595; Mon, 19 Jul 2010 15:30:08 -0700 (PDT)
MIME-Version: 1.0
Sender: tantek@gmail.com
Received: by 10.142.156.8 with HTTP; Mon, 19 Jul 2010 15:29:38 -0700 (PDT)
In-Reply-To: <4C44CF3A.6050902@atlantika-arts.net>
References: <44A88E2F417F42C98A086014681E5586@Javier2> <4C444698.4080603@viagenie.ca> <6C4A9E5CC56541FCBA403E46E32A4068@Javier2> <AANLkTimFzxZuJC5C-XMuY4kimJ1egXw37FTRvNGtWvnL@mail.gmail.com> <4C44CF3A.6050902@atlantika-arts.net>
From: =?UTF-8?Q?Tantek_=C3=87elik?= <tantek@cs.stanford.edu>
Date: Mon, 19 Jul 2010 15:29:38 -0700
X-Google-Sender-Auth: 1SQRsdq51wJ1ATwtSlJF4sAlw9w
Message-ID: <AANLkTimPviVgNLf7lAOrZiXKk1FNbbTeMWrlm_I9-iLM@mail.gmail.com>
To: Markus Lorenz <lorenz@atlantika-arts.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] Miscellaneous comments
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: Mon, 19 Jul 2010 22:29:55 -0000

On Mon, Jul 19, 2010 at 3:18 PM, Markus Lorenz
<lorenz@atlantika-arts.net> wrote:
> Am 20.07.2010 00:05, schrieb Daisuke Miyakawa:
>> Hi,
>>
>> 2010/7/19 Javier Godoy <rjgodoy@fich.unl.edu.ar
>> <mailto:rjgodoy@fich.unl.edu.ar>>
>>
>>             2. NAME. "The NAME property is used to convey the display
>>             name of the
>>             entity to which the directory information pertains"
>>
>>             Shouldn't the display name be choosen by the implementation?
>>             There is
>>             already a mandatory FN property from which the display name
>>             could be derived.
>>
>>             I remember this issue was discussed before, but I cannot
>>             find the rationale
>>             for not removing the NAME property.
>>
>>
>>         We inherited NAME from vCard 3.0
>>
>>
>>     NAME is inherited from RFC 2425, thus it should have been intended
>>     as a minimal profile-independent representation of the display name
>>     (not only for vCard but also for other "directory profiles" that
>>     never existed).
>>
>>
>>         I, for one, have no clue how it could be useful.
>>
>>         Does anyone know how it is being used currently?
>>
>>
>>         and I don't think its removal has ever been discussed.
>>
>>
>>     I agree it seems we never discussed it, though it was proposed
>>     http://www.vcarddav.org/issues.xhtml#176
>>     "The NAME (RFC2425) property is redundant with FN (RFC2426)"
>>     Closed without action on 2008-06-09
>>
>>     And yes, I said "+1" to closing it, but I cannot remember why... now
>>     I think we should do something about it.
>>
>>
>> +1 to do something. I prefer removing it, but there's no strong preference.
>>
>> I think one problem is that the name is too generic. If NAME is "a
>> minimal profile-independent representation of the display name", the
>> name should not be
>> NAME but SHORT-NAME, SN, or something more appropriate. We don't need to
>> inherit that name from vCard 3.0, but its intention.
>
> +1 to remove it. If no one knows how to use it, it can't bring any benefit.
>
> What could a SHORT-NAME be used for? I still can't see the intention.
> Was the plan to get at least some useful information out of a
> mime-directory format even if you don't understand the specific format?
> Are there other mime-directory formats than vCard?

+1 remove it.

NAME is defined in 2445 as

2.1.2 NAME Type

   If the NAME type is present, then its value is the displayable,
   presentation text associated with the **source** for the vCard, as
   specified in the SOURCE type.

**emphasis** added.

The source is not the vCard itself.

Thus repurposing NAME in vCard4 to mean display name for a vCard
itself is a backwards incompatible change (using an existing
vocabulary term to mean something new) and is thus very much a bad
idea.

Best to just remove it.

Thanks,

Tantek

-- 
http://tantek.com/
I made an HTML5 tutorial video/book! http://tantek.com/html5