[VCARDDAV] Miscellaneous comments

"Javier Godoy" <rjgodoy@fich.unl.edu.ar> Sun, 18 July 2010 12:13 UTC

Return-Path: <rjgodoy@fich.unl.edu.ar>
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 A65503A68A7 for <vcarddav@core3.amsl.com>; Sun, 18 Jul 2010 05:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.526
X-Spam-Level:
X-Spam-Status: No, score=0.526 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_50=0.001, J_CHICKENPOX_44=0.6, STOX_REPLY_TYPE=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 KS9ZYomn3DWx for <vcarddav@core3.amsl.com>; Sun, 18 Jul 2010 05:13:18 -0700 (PDT)
Received: from fich.unl.edu.ar (fich.unl.edu.ar [168.96.132.90]) by core3.amsl.com (Postfix) with ESMTP id 7A28E3A676A for <vcarddav@ietf.org>; Sun, 18 Jul 2010 05:13:17 -0700 (PDT)
Received: from Javier2 ([190.193.109.175]) (authenticated user rjgodoy@fich.unl.edu.ar) by fich.unl.edu.ar (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits)) for vcarddav@ietf.org; Sun, 18 Jul 2010 09:13:29 -0300
Message-ID: <44A88E2F417F42C98A086014681E5586@Javier2>
From: "Javier Godoy" <rjgodoy@fich.unl.edu.ar>
To: <vcarddav@ietf.org>
Date: Sun, 18 Jul 2010 09:12:40 -0300
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
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: [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 12:13:19 -0000

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)
 Section 6.7.5 (TYPE=audio/basic)
 Section 6.8.2 (TYPE=application/pgp-keys)



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.



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.


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.


Best Regards

Javier