Re: [VCARDDAV] Miscellaneous comments

Markus Lorenz <lorenz@atlantika-arts.net> Sun, 18 July 2010 14:18 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 99F673A6886 for <vcarddav@core3.amsl.com>; Sun, 18 Jul 2010 07:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.694
X-Spam-Level:
X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-1.905, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_44=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 PQktEtOjNQWZ for <vcarddav@core3.amsl.com>; Sun, 18 Jul 2010 07:18:18 -0700 (PDT)
Received: from host46.sitepush.net (server20.server-centrum.de [213.239.241.46]) by core3.amsl.com (Postfix) with ESMTP id 74E2F3A657C for <vcarddav@ietf.org>; Sun, 18 Jul 2010 07:18:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by host46.sitepush.net (Postfix) with ESMTP id 73BCC1FA0002 for <vcarddav@ietf.org>; Sun, 18 Jul 2010 16:18:27 +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 zT3iONboIyyZ for <vcarddav@ietf.org>; Sun, 18 Jul 2010 16:18:27 +0200 (CEST)
Received: from [192.168.0.101] (f053154016.adsl.alicedsl.de [78.53.154.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by host46.sitepush.net (Postfix) with ESMTP id 185651FA0001 for <vcarddav@ietf.org>; Sun, 18 Jul 2010 16:18:27 +0200 (CEST)
Message-ID: <4C430D33.3070508@atlantika-arts.net>
Date: Sun, 18 Jul 2010 16:18:27 +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: <44A88E2F417F42C98A086014681E5586@Javier2>
In-Reply-To: <44A88E2F417F42C98A086014681E5586@Javier2>
Content-Type: text/plain; charset=ISO-8859-15
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: Sun, 18 Jul 2010 14:18:19 -0000

Am 18.07.2010 14:12, schrieb Javier Godoy:
> 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.

I'm also confused about the purpose of the NAME property. I think it's
not useful to let the creator of a vCard file define the value with
which the contact information is displayed to the user by his address
book. But I'm not sure if that's what is meant. Every address book I
know let's the user specify the way it presents the contacts, mostly by
letting the user define which information is display in which column of
the list view.

Maybe the NAME property is more like an explanation of the vCards
content to the user? For example when he first opens the file. You could
give some information about what is included in the file, like "Babs
Jensen's very private contact details", "Babs Jensen's contact details
at Example, Inc.", or "VCARDDAV WG mailing list". So you don't have to
understand this from the data inside the vCard.

But I'm just guessing. If someone knows what the NAME property should be
used for, I would like to know.



> 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 remember Cyrus bringing up this topic:

Am 31.05.2010 19:38, schrieb Cyrus Daboo:
> * Section 5.6: The restriction on "work" and "home" usage related to
> presence and value of "KIND" seems a little odd. What is more, it does
> not use RFC2119 key words so it is not clear if this is a "real"
> requirement or not. This needs to be better defined, or the
> restriction should be removed.

I suggested to remove the restrictions. From my point of view it was
about a larger inconsistency of explicit restrictions. The purpose of
the restriction was to only use "home" and "work" with individuals. But
the restriction lacks completeness by just restricting it to the absence
of KIND or in case of presence to its value being "individual". You
could still use "home" and "work" for vCards by simply not using the
KIND property at all. Furthermore I think if the specification defines
such restriction it should do so for at best every similar case. It
would need restriction for type-values such as "sibling", "spouse", etc.
which also only make sense if the vCard represents an individual. But
then you have much more problems, as "agent" can be used "for a person
who may sometimes act on behalf of the individual or resource associated
with the vCard". So it may also apply to organisations and groups and
would need a different restriction than every other type-param-related
value.

I think this would become much to complex and incomplete. Thus I
favoured the removal of the restriction.



Regards


Markus