[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-----
- [VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Possib… Florian Zeitz
- Re: [VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Po… Simon Perreault
- Re: [VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Po… Florian Zeitz
- Re: [VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Po… Simon Perreault
- Re: [VCARDDAV] draft-ietf-vcarddav-vcardrev-10 Po… Darryl Champagne