Re: [VCARDDAV] Miscellaneous comments

Simon Perreault <simon.perreault@viagenie.ca> Mon, 19 July 2010 12:40 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 1DC1A3A6895 for <vcarddav@core3.amsl.com>; Mon, 19 Jul 2010 05:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level:
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001]
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 O+lTohKzr37V for <vcarddav@core3.amsl.com>; Mon, 19 Jul 2010 05:40:55 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C3F9C3A6894 for <vcarddav@ietf.org>; Mon, 19 Jul 2010 05:40:54 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:819b:ca5e:af45:c91b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6FEA521CA5 for <vcarddav@ietf.org>; Mon, 19 Jul 2010 08:41:08 -0400 (EDT)
Message-ID: <4C444698.4080603@viagenie.ca>
Date: Mon, 19 Jul 2010 08:35:36 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5
MIME-Version: 1.0
To: vcarddav@ietf.org
References: <44A88E2F417F42C98A086014681E5586@Javier2>
In-Reply-To: <44A88E2F417F42C98A086014681E5586@Javier2>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
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 12:40:59 -0000

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.

> 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.
> FN accepts values in multiple languages, while NAME doesn't (that is
> relevant
> if the vCard instance has a FN value for the user-preferred language, while
> NAME is written in another language/script)
> 
> For instance, given the example provided in the draft
> NAME:Babs Jensen's Contact Information
> and assuming that
> FN:Babs Jensen
> 
> I would prefer to present the user with "Información de contacto para Babs
> Jensen" (spanish). The example is even most interesting if NAME is not
> written
> in the latin alphabet (the user will probably find the "display name" is
> unreadable)
> 
> 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 and I don't think its removal has ever
been discussed.

I, for one, have no clue how it could be useful.

Does anyone know how it is being used currently?

> 3. RELATED, DDAY, BDAY value may be uri or text, but LANGUAGE parameter
> is not
> allowed when they are "text", thus alternative values in different
> languages
> cannot be specified. I think LANGUAGE should be allowed, at least for the
> RELATED property.

I think you're right. I changed the ABNF so that it is allowed for all
three of them when using a text value.

> 4. I notice the restriction of "work" and "home" being used only when
> the KIND
> property is absent or its value is "individual" was removed in draft-12.
> The
> meaning of the "home" type is undefined when KIND is not "individual"
> because
> "the home value implies that the property is related to an individual's
> personal life". I would recommend rephrasing the requirement as a SHOULD
> NOT
> instead of removing it, or providing a broader definition of "home" for
> locations, groups and organizations, so that implementations can use it
> consistently.

I'm not too sure what to do here. If people care about this, speak up.
Otherwise we'll stay with what we have.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org