RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Errata ID: 3488
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Angstadt
Date Reported: 2013-02-18
Held for Document Update by: Barry Leiba
Date Held: 2013-02-19

Throughout the document, when it says:

See notes

It should say:

See notes

Notes:

============================================
Verifier notes:
The report below is correct, and it's important that implementors understand that RFC 6350 has a number of errors here. The problem is that properly correcting the errors goes beyond the scope of the RFC errata system, and requires an updated document.

This errata report is, therefore, going to be marked "held for document update", but that designation should not be taken as downplaying the importance of this report and the errors it talks about. The verifier strongly encourages an effort to produce such an updated document soon. There will be significant interoperability problems if different implementations handle multi-valued parameters differently.
============================================

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).

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

Report New Errata