Subject: [VCARDDAV] [Technical Errata Reported] RFC6350 (3100)

From: RFC Errata System <[email-masked]>
Date: Mon, 30 Jan 2012 10:29:41 -0800 (PST)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3100

--------------------------------------
Type: Technical
Reported by: Roberto Javier Godoy <[email-masked]>

Section: 5.6

Original Text
-------------
type-param = "TYPE=" type-value *("," type-value)

Corrected Text
--------------
type-param =  "TYPE=" type-value *("," type-value)
type-param =/ "TYPE=" DQUOTE type-value *("," type-value) DQUOTE

Notes
-----
Section 6.4.1 states that TYPE parameter values can be specified
as a parameter list (e.g., TYPE=text;TYPE=voice) or as a value list (e.g.,
TYPE="text,voice"). 

Either the description is right (and the ABNF should be corrected), or the ABNF is right, and the description and examples in Sections 6.4.1 and 8 should be fixed.

Value lists in vCard 3.0 did not use quotes (e.g "TYPE=dom,postal" in Section 3.3.1 of RFC 2426). If the ABNF is fixed this would be a significant change from  RFC 2426 syntax.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6350 (draft-ietf-vcarddav-vcardrev-22)
--------------------------------------
Title               : vCard Format Specification
Publication Date    : August 2011
Author(s)           : S. Perreault
Category            : PROPOSED STANDARD
Source              : vCard and CardDAV
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Simon Perreault <[email-masked]>
Date: Mon, 30 Jan 2012 13:41:17 -0500

> Original Text

Well, all parameters can be implicitly quoted. So why restrict yourself 
to the TYPE parameter?

If the ABNF is to be fixed, it would need to be done implicitly for all 
parameters at once.

> Either the description is right (and the ABNF should be corrected), or the ABNF is right, and the description and examples in Sections 6.4.1 and 8 should be fixed.

The examples use quotes for parameters that don't absolutely need them. 
I think this is fine. The ABNF should allow it.

> Value lists in vCard 3.0 did not use quotes (e.g "TYPE=dom,postal" in Section 3.3.1 of RFC 2426). If the ABNF is fixed this would be a significant change from  RFC 2426 syntax.

Parameters with commas don't need to be quoted. So the examples are 
using superfluous quotes. Not a problem per se.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Jan 2012 11:47:26 -0700

On 1/30/12 11:41 AM, Simon Perreault wrote:
>> Either the description is right (and the ABNF should be corrected), or
>> the ABNF is right, and the description and examples in Sections 6.4.1
>> and 8 should be fixed.
> 
>> Value lists in vCard 3.0 did not use quotes (e.g "TYPE=dom,postal" in
>> Section 3.3.1 of RFC 2426). If the ABNF is fixed this would be a
>> significant change from  RFC 2426 syntax.
> 

So is this "Reject" or "Hold for Document Update"?

http://www.ietf.org/iesg/statement/errata-processing.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Perreault <[email-masked]>
Date: Mon, 30 Jan 2012 13:54:40 -0500

> So is this "Reject" or "Hold for Document Update"?

I was hoping to discuss it further, but if you want a verdict right now 
I'd say "Reject". It's clear that there is something wrong in the RFC, 
but the proposed fix is also wrong.

Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Jan 2012 11:57:10 -0700

> but the proposed fix is also wrong.

I'm not in a hurry. Discussion is good!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 30 Jan 2012 18:55:22 -0300

On 2012-01-30 15:41, Simon Perreault wrote:

> Well, all parameters can be implicitly quoted. So why restrict yourself to
> the TYPE parameter?

Because Section 5 specifies that "the property parameter can be multi-valued
in which case the property parameter value elements are separated by a COMMA"
and "property parameter value elements that contain the COLON, SEMICOLON, or
COMMA character separators MUST be specified as quoted-string text values".

As I understand Section 5, there are two value elements ("text" and "voice"),
and what must be quoted is not the property parameter *value* (as in
TYPE="text,voice"), but the property parameter value *elements* (as in
TYPE="text","voice").
.
Since TYPE is defined as "a comma-separated subset of a predefined
enumeration", not only there is no need to escape the comma, but the comma
MUST NOT be escaped since it is the list delimiter instead of a part of the
*parameter value element*.

This is similar to
 N;SORT-AS="Aboville,Marie,Christine":d'Aboville;Marie,Christine;;
instead of
 N;SORT-AS="Aboville","Marie,Christine":d'Aboville;Marie,Christine;;

> If the ABNF is to be fixed, it would need to be done implicitly for all

Most of the other parameters either must be quoted (and already allow DQUOTE
in ABNF), or are defined as a single element that cannot contain
comma/semicolon/colon (thus the implicit quote rule is harmless). Even most of
the list types are not ambiguous if the whole value is quoted, for instance
the integer-list value "+1234556790,432109876" can be understood as
"+1234556790","432109876", but there are no conflicting examples or
definitions in RFC 6350.

My concern is that quoting "text,voice" does not conforms Section 5, and
should be explicitly allowed. Whether the requirement of quoting value
elements per Section 5 remains as an implicit rule or it is explicitly stated
in the ABNF, is a separate issue that I didn't intend to discuss.

Best Regards

Javier