[VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Possible Errata/Questions

Florian Zeitz <florob@babelmonkeys.de> Thu, 01 April 2010 00:44 UTC

Return-Path: <florob@babelmonkeys.de>
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 6F2D33A6916 for <vcarddav@core3.amsl.com>; Wed, 31 Mar 2010 17:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.79
X-Spam-Level: *
X-Spam-Status: No, score=1.79 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_SORBS_WEB=0.619]
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 P9b010oeBwdG for <vcarddav@core3.amsl.com>; Wed, 31 Mar 2010 17:44:57 -0700 (PDT)
Received: from babelmonkeys.de (v64231.topnetworks.de [82.197.159.233]) by core3.amsl.com (Postfix) with ESMTP id 0CC103A6A97 for <vcarddav@ietf.org>; Wed, 31 Mar 2010 17:44:33 -0700 (PDT)
Received: from xdsl-81-173-172-90.netcologne.de ([81.173.172.90] helo=[192.168.0.38]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <florob@babelmonkeys.de>) id 1Nx8Wt-0000if-AQ for vcarddav@ietf.org; Thu, 01 Apr 2010 02:45:03 +0200
Message-ID: <4BB3EC89.5080809@babelmonkeys.de>
Date: Thu, 01 Apr 2010 02:44:57 +0200
From: Florian Zeitz <florob@babelmonkeys.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100322 Thunderbird/3.0.3
MIME-Version: 1.0
To: vcarddav@ietf.org
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
Subject: [VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Possible Errata/Questions
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: Thu, 01 Apr 2010 00:44:58 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just finished reading through draft-ietf-vcarddav-vcardrev-10 and have
some comments/questions/nitpicks:

Section 3.3. Property Value Escaping:
»A property instance may contain one or more values delimited by a
   COMMA character (ASCII decimal 44).«
This is IMHO somewhat misleading because (if I'm not mistaken) not all
properties can contain more than one value. This could be rephrased as
"Instances of some properties may contain [...]"

»Finally, newline (ASCII decimal 10) and backslash (ASCII decimal 92)
   characters in values MUST be escaped by prefixing them with a
   backslash character.«
Is this intended? While it is not unheard of to prefix newline
characters with a backslash character to escaping it I would have
expected that "\n" is used here for consistency.

Section 4. Property Value Data Types:
»text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)«
I suspect this was supposed to say
"text-list = 1*TEXT-LIST-CHAR *("," 1*TEXT-LIST-CHAR)"
so that empty list entries are not allowed.
If it was on purpose it could also be rewritten as
"text-list = *(*"," *TEXT-LIST-CHAR)"
admittedly this is not beautiful, but would make it clearer that empty
list entries are allowed and might avoid misinterpretation.

Section 4.7. BINARY:
»The "binary" value type specifies that the type value is
   inline, encoded binary data.«
Honestly I'm not even sure what this is supposed to mean. Would
'The "binary" value type specifies that the properties value
   inline, encoded binary data.'
be an equivalent statement?

Section 5. Property Parameters
»Property parameter values that are not in quoted strings are case
   insensitive.«
Earlier it is mentioned in Section 3.2 that whether a parameter is case
sensitive depends on it's definition, which IMHO slightly contradicts
this. I also wonder if assuming that quoted strings are case sensitive
is correct (this should probably be explicitly mentioned in any case).

Only for the VALUE (5.3) and PREF (5.4) parameter it is explicitly
specified that they are optional. My understanding is that all
parameters are optional unless otherwise specified for a certain
property. If this is correct this statement is IMHO misleading and/or
unnecessary.

I'm a bit unclear on the usage of the LANGUAGE param. Is it
possible/intended to have the same property in different languages?
E.g.:
BIRTH;LANGUAGE=de-DE:Köln
BIRTH;LANGUAGE=en-US:Cologne
If it is this won't integrate nicely with properties with Cardinality
(0,1) or (1,1) and PIDs.
If this usage is however not expected I think it would be useful to
explicitly state this.

Section 6.6.4 ORG:
»Value type: A single structured text value consisting of components
      separated the SEMI-COLON character (ASCII decimal 59).«
Should probably say "separated by"

PID/CLIENTPIDMAP:
The specification is IMHO a bit confusing in regard to PIDs and
CLIENTPIDMAP. It is said that a PID can be either of the form "n" or
"n.m" where n and m are small numbers. CLIENTPIDMAPs however seem to
assume a PID always has 2 fields the second being a "PID source
identifier". Does that mean a PID of the form "n" can not be mapped to a
UUID? Is there any reason to allow this form at all? None of the
examples seem to use it.

Section 7.2.5. Global Context Simplification:
I wonder what is up with this section... It introduces a completely new
concept to which there is no normative reference whatsoever within an
example.
When I read it, it sounded like a good idea at first. Reduces size,
makes vCard better readable (at least for humans), etc. But on second
thought this seams *very* error prone especially since it is unspecified.
It will IMHO fail if you sync more than 2 devices (not necessarily at
the same time), not all of the devices perform the simplification and
probably in many other cases.
If this section is kept I think there should be some normative text
explaining how this process should be implemented.

- --
Florian Zeitz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkuz7IkACgkQ0JXcdjR+9YSZuQCgvCvjEP75tVf/IZ/hRZJxsW9c
X/oAoJmk2zD/BhxA4yxlTAX8leb3P7or
=KboL
-----END PGP SIGNATURE-----