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

From: RFC Errata System <[email-masked]>
Date: Mon, 18 Feb 2013 19:29:59 -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=3488

--------------------------------------
Type: Technical
Reported by: Michael Angstadt <[email-masked]>

Section: GLOBAL

Original Text
-------------
See notes

Corrected Text
--------------
See notes

Notes
-----
Multiple errata have been submitted that draw attention to an inconsistency in how multi-valued parameters are represented in the ABNF and how they are represented in various examples throughout the specification (errata IDs 3100, 3138, 3139).  The purpose of this submission is to help upgrade this issue from "Held for Document Update" to "Verified" by offering additional, reenforcing arguments.

It is the opinion of this author that it is the ABNF, not the examples, which should be declared correct, since the ABNF allows for comma characters to be included in parameter values.

To briefly review the issue, in the example below, the TYPE parameter only has one value according to the ABNF, since all of the parameter values are surrounded in double quotes.  This is the way that many multi-valued parameters are represented in the specification.

ADR;TYPE="home,dom,work":

According to the ABNF, the correct way to encode this list of values would be to either remove the double quotes, since none of the values contain special characters, or to enclose selected, individual values in double quotes.  The properties below are all ABNF-valid:

ADR;TYPE="home","dom","work":
ADR;TYPE=home,dom,work:
ADR;TYPE=home,"dom",work:

The example in section 6.3.1 on page 34 is a good example of why the ABNF should be followed:

     ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
      Mail Drop: TNE QB\n123 Main Street\nAny Town, CA  91921-1234\n
      U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.

The GEO and LABEL parameters are enclosed in double quotes because their values contain special characters (colons and commas).  If the ABNF is followed, then the parameters are correctly parsed as follows:

GEO
  (1) geo:12.3457,78.910
LABEL
  (1) Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\nU.S.A.

However, if these parameters were to be parsed according to the other method, then their values would be incorrectly split up, since they each contain a comma character.

GEO
  (1) geo:12.345778.910
  (2) 78.910
LABEL
  (1) Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 Main Street\nAny Town
  (2) CA 91921-1234\nU.S.A.

It is suggested that the following corrections be made to the specification:

===========

1. Section 5.9, pages 21-22

           FN:Rene van der Harten
           N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N.
           FN:Robert Pau Shou Chang
           N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;;
           FN:Osamu Koura
           N;SORT-AS="Koura,Osamu":Koura;Osamu;;
           FN:Oscar del Pozo
           N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;
           FN:Chistine d’Aboville
           N;SORT-AS="Aboville,Christine":d’Aboville;Christine;;
           FN:H. James de Mann
           N;SORT-AS="Mann,James":de Mann;Henry,James;;

should be

           FN:Rene van der Harten
           N;SORT-AS=Harten,Rene:van der Harten;Rene,J.;Sir;R.D.O.N.
           FN:Robert Pau Shou Chang
           N;SORT-AS=Pau Shou Chang,Robert:Shou Chang;Robert,Pau;;
           FN:Osamu Koura
           N;SORT-AS=Koura,Osamu:Koura;Osamu;;
           FN:Oscar del Pozo
           N;SORT-AS=Pozo,Oscar:del Pozo Triscon;Oscar;;
           FN:Chistine d’Aboville
           N;SORT-AS=Aboville,Christine:d’Aboville;Christine;;
           FN:H. James de Mann
           N;SORT-AS=Mann,James:de Mann;Henry,James;;

===========

2. Section 6.4.1, page 35

      The default type is "voice".  These 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").  The default can be
      overridden to another set of values by specifying one or more
      alternate values.  For example, the default TYPE of "voice" can be
      reset to a VOICE and FAX telephone number by the value list
      TYPE="voice,fax".

should be

      The default type is "voice".  These 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).  The default can be
      overridden to another set of values by specifying one or more
      alternate values.  For example, the default TYPE of "voice" can be
      reset to a VOICE and FAX telephone number by the value list
      TYPE=voice,fax.

===========

3. Section 6.4.1, page 36

   Example:
     TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
     TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67

should be

   Example:
     TEL;VALUE=uri;PREF=1;TYPE=voice,home:tel:+1-555-555-5555;ext=5555
     TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67

===========

4. Section 8, page 57

    TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
    TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501

should be

    TEL;VALUE=uri;TYPE=work,voice;PREF=1:tel:+1-418-656-9254;ext=102
    TEL;VALUE=uri;TYPE=work,cell,voice,video,text:tel:+1-418-262-6501

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: Barry Leiba <[email-masked]>
Date: Tue, 19 Feb 2013 01:04:15 -0500

> Multiple errata have been submitted that draw attention to an inconsistency in how
> multi-valued parameters are represented in the ABNF and how they are represented
> in various examples throughout the specification (errata IDs 3100, 3138, 3139).  The
> purpose of this submission is to help upgrade this issue from "Held for Document
> Update" to "Verified" by offering additional, reenforcing arguments.

Michael, thanks for having the passion to do this, but I think what
you're doing comes from a misunderstanding of the HFDU designation.
It's not a "penalty" designation that says the report is incorrect
(that would be "Rejected").  Quite the opposite: it acknowledges that
the report is correct (at least partially, and perhaps completely),
but that either it's insignificant (in the case of reports of typos)
or the proper resolution of the reported error involves more than we
want to do by using the errata system.

With the HFDU vCard errata the issue is that there are a number of
intertwined errors that pervade the document, and we really *do* need
to handle the corrections in an updated document.  If you'd like to
get some people together and work on such an update, that would be the
best way to get the problems corrected quickly.

Barry

---

From: Simon Perreault <[email-masked]>
Date: Tue, 19 Feb 2013 13:20:37 +0100

In addition to what Barry said, I'd like to point out that the 
corrections below are all correct.

What would be needed in an RFC revision is some text discussing the 
issue. I'm sure there are interoperability issues that need to be 
documented.

I consider this a huge mistake. I'm ashamed and very sorry.

Simon

---

From: Michael Angstadt <[email-masked]>
Date: Tue, 19 Feb 2013 07:21:32 -0500

Barry,

I guess my point is to have the various examples which I've listed in the
errata acknowledged as "typos" that vendors must be aware of when writing
their implementations.  My understanding of HFDU is that it basically
means, "That's a good point, but lets address it later."

The multi-valued parameter thing is fairly big IMO.  If the examples in the
spec are to be taken seriously, then you basically have to support two ways
of parsing parameters--one for TYPE and SORT-AS, and another for everything
else.  If anyone agrees/disagrees, please shoot an email to the group.

Thanks,
-Mike
http://code.google.com/p/ez-vcard

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Feb 2013 17:14:46 -0500

> their implementations.  My understanding of HFDU is that it basically means,
> "That's a good point, but lets address it later."

Yes, I see that that's how you understand it.  I will be sure to add a
verifier note to make it clear that the report is correct and
important, but the full resolution of the issues goes beyond the
errata system, and a document update *soon* is needed.

Does everyone think that's appropriate?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Feb 2013 17:45:15 -0500

> Does everyone think that's appropriate?

Specifically, look at the errata report as I've edited it (it's still
in "Reported" state):
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3488

Barry

---

From: Michael Angstadt <[email-masked]>
Date: Tue, 19 Feb 2013 22:10:58 -0500

Thanks for adding the note.  So, the issue is too large to be
corrected through normal errata submissions?

Simon don't be ashamed :'( :'(