Re: [VCARDDAV] Miscellaneous comments

"Javier Godoy" <> Mon, 19 July 2010 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF6A63A6B06 for <>; Mon, 19 Jul 2010 07:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.243
X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_50=0.001, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id USJUdumQ-Qlx for <>; Mon, 19 Jul 2010 07:41:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 34BF63A69B7 for <>; Mon, 19 Jul 2010 07:41:39 -0700 (PDT)
Received: from Javier2 ([]) (authenticated user by (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits)); Mon, 19 Jul 2010 11:41:48 -0300
Message-ID: <6C4A9E5CC56541FCBA403E46E32A4068@Javier2>
From: "Javier Godoy" <>
To: "Simon Perreault" <>, <>
References: <44A88E2F417F42C98A086014681E5586@Javier2> <>
Date: Mon, 19 Jul 2010 11:41:06 -0300
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
Subject: Re: [VCARDDAV] Miscellaneous comments
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Jul 2010 14:41:40 -0000

Simon Perreault wrote:

>On 2010-07-18 08:12, Javier Godoy wrote:
>> 1. In draft version 12 the property TYPE was splitted into TYPE (home/work)
>> and FMTTYPE (content type). However, there are some examples using TYPE
>> instead of FMTTYPE:
>> Section 6.4.1 (TYPE=text;TYPE=voice)
>That's not supposed to be FMTTYPE.

Oops... I don't know why I include it with the other occurrences. Sorry.

>> Section 6.7.5 (TYPE=audio/basic)
>> Section 6.8.2 (TYPE=application/pgp-keys)
>Good catch! Thanks.

>> 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
"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.

Best Regards