Errata

Status:

Verified

Type:

Technical

Reported By:

Roberto Javier Godoy

Date Reported:

2012-01-09

Verified by:

Peter Saint-Andre

Date Verified:

2012-01-23

Section 6.2.6 says:

     ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text")
     ANNIVERSARY-value = date-and-or-time / text
       ; Value and parameter MUST match.

     ANNIVERSARY-param =/ altid-param / calscale-param / any-param
       ; calscale-param can only be present when ANNIVERSARY-value is
       ; date-and-or-time and actually contains a date or date-time.

It should say:

     ANNIVERSARY-param = ANNIVERSARY-param-date / ANNIVERSARY-param-text
     ANNIVERSARY-value = date-and-or-time / text
       ; Value and parameter MUST match.

     ANNIVERSARY-param-date = "VALUE=date-and-or-time"
     ANNIVERSARY-param-text = "VALUE=text" / language-param
     
     ANNIVERSARY-param =/ altid-param / calscale-param / any-param
       ; calscale-param can only be present when ANNIVERSARY-value is
       ; date-and-or-time and actually contains a date or date-time.

Notes:

language-param should be allowed when ANNIVERSARY is reset to a single text value (BDAY, defined in section 6.2.5 accepts language-param)

Status:

Verified

Type:

Technical

Reported By:

Kai Giebeler

Date Reported:

2012-02-25

Verified by:

Peter Saint-Andre

Date Verified:

2012-02-27

Section 3.3. says:

   QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE

   SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ";", ":"

   VALUE-CHAR = WSP / VCHAR / NON-ASCII
     ; Any textual character

It should say:

   QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE but including HTAB

   SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ";", ":" but including HTAB

   VALUE-CHAR = WSP / VCHAR / NON-ASCII
     ; Any textual character including HTAB

Notes:

The ABNF is inconsistent with the textual decription regarding the HTAB character which is part of WSP and CTL

Alternatively HTAB could be excluded by replacing WSP by SP in at least QSAFE-CHAR and SAFE-CHAR.

PSA: During discussion on the VCARDDAV list, Barry Leiba noted: "His point for the first two is that HTAB is a CTL (according to RFC 5234), so the comment "any character except CTLs" excludes HTAB.  But the grammar uses WSP, which *includes* HTAB (also RFC 5234).  So the comment is not consistent with the grammar.  Either change WSP to SP (thus excluding HTAB, as the comment says) or make the change he suggests to the comment, so it's consistent with the grammar. For the third item, VALUE-CHAR, I think the point is that it's not
clear whether HTAB is a "textual character", since that term isn't
formally defined.  By saying "including HTAB" in the comment (since
it's included by WSP), it's clearer." Agreement on list that this is a correct erratum. -- Peter Saint-Andre

Status:

Verified

Type:

Technical

Reported By:

Stefan Ganzer

Date Reported:

2012-10-12

Verified by:

Barry Leiba

Date Verified:

2012-10-12

Section 4 says:

component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
               / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E

It should say:

COMPONENT-CHAR = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
               / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
	   ; Backslashes, commas, semicolons, and newlines must be encoded.

component = *COMPONENT-CHAR

Notes:

The property value data type "component" should be defined analogous to "text".

Status:

Verified

Type:

Technical

Reported By:

Roberto Javier Godoy

Date Reported:

2013-02-17

Verified by:

Barry Leiba

Date Verified:

2013-02-18

Section 4 says:

time          = hour [minute [second]] [zone]
              /  "-"  minute [second]  [zone]
              /  "-"   "-"    second   [zone]

It should say:

time          = hour [minute [second]] [zone]
              /  "-"  minute [second]  
              /  "-"   "-"    second   

Notes:

Truncated time representations are defined in ISO 8601:2000 subclause 5.3.1.4

From ISO 8601:2000 subclauses 5.3.3 and 5.4.3.2, the UTC designator and utc-offset may only be applied to the representations specified in 5.3.1.1 through 5.3.1.3 (i.e. Complete representation, representations with reduced precision, and representation of decimal fractions). 

If follows that the UTC designator or utc-offset must not be written after a truncated representation (second and third line of the corrected ABNF). For instance, the following representation should not be allowed: --42Z (the 42th second of a minute in Coordinated Universal Time)

Status:

Verified

Type:

Technical

Reported By:

Michael Angstadt

Date Reported:

2013-08-29

Verified by:

Barry Leiba

Date Verified:

2013-08-29

Section 5.9 says:

           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;;

It should say:

           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;;

Notes:

The N properties in this example text are missing the "additional names" component.

Three of the properties have a "given name" component which contains two values.  For these properties, the second value should be used as the value of the additional names component.

The other three properties do not have any additional names.  For these properties, an empty component should be added (a semi-colon character should be added to the property value).

Status:

Verified

Type:

Technical

Reported By:

David Riggle

Date Reported:

2013-12-20

Verified by:

Barry Leiba

Date Verified:

2013-12-23

Section 6.2.4 says:

       PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

It should say:

       PHOTO:data:image/jpeg;base64\,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv

Notes:

Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The PHOTO property value in the example contains a comma. Therefore it must be escaped with a backslash. Note that there are several other uses of the "data:" URI scheme in the document that also need to be corrected.

Alternatively, a different format for base64 encoded data could be used in vCard 4.0. The ENCODING=b format used in vCard 3.0 wasn't so bad.


----- Verifier notes -----
This represents a difference from earlier versions of vCard, and the ABNF does not support escaping for URIs.  This errata report is correct and verified, but a full correction to the issue will have to wait for a document update.

Status:

Verified

Type:

Technical

Reported By:

David Riggle

Date Reported:

2013-12-20

Verified by:

Barry Leiba

Date Verified:

2013-12-23

Section 6.5.2 says:

           GEO:geo:37.386013,-122.082932

It should say:

           GEO:geo:37.386013\,-122.082932

Notes:

Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The GEO property value in the example contains a comma. Therefore it must be escaped with a backslash.

Status:

Verified

Type:

Technical

Reported By:

Charles Burkitt

Date Reported:

2023-01-23

Verified by:

Orie Steele

Date Verified:

2024-05-10

Section 5.4 says:

TITLE;ALTID=1;LANGUAGE=fr:Patron
TITLE:LANGUAGE=en:Boss
(Second line should probably have ALTID=1.)

It should say:

TITLE;ALTID=1;LANGUAGE=fr:Patron
TITLE;LANGUAGE=en:Boss
(Second line should probably have ALTID=1.)

Notes:

The colon between TITLE and LANGUAGE should be a semicolon.

Status:

Verified

Type:

Editorial

Reported By:

Mykyta Yevstifeyev

Date Reported:

2011-09-08

Verified by:

Peter Saint-Andre

Date Verified:

2011-09-09

Section 3.3 says:

   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

It should say:

   param-value = *SAFE-CHAR / ( DQUOTE *QSAFE-CHAR DQUOTE )

Notes:

This is to remove possibility of doubly understanding, eg.:

   param-value = ( *SAFE-CHAR / DQUOTE ) *QSAFE-CHAR DQUOTE

or

   param-value = *SAFE-CHAR / ( DQUOTE *QSAFE-CHAR DQUOTE )

with the latter being right.  See also http://www.ietf.org/mail-archive/web/vcarddav/current/msg02318.html.

Status:

Verified

Type:

Editorial

Reported By:

Mykyta Yevstifeyev

Date Reported:

2011-10-21

Verified by:

Peter Saint-Andre

Date Verified:

2011-11-12

Section 10.3.4 says:

   The following table is to be used to initialize the property values
   registry.

            +----------+------------+-------------------------+
            | Property | Value      | Reference               |
            +----------+------------+-------------------------+
            | BEGIN    | VCARD      | RFC 6350, Section 6.1.1 |
            | END      | VCARD      | RFC 6350, Section 6.1.2 |
            | KIND     | individual | RFC 6350, Section 6.1.4 |
            | KIND     | group      | RFC 6350, Section 6.1.4 |
            | KIND     | org        | RFC 6350, Section 6.1.4 |
            | KIND     | location   | RFC 6350, Section 6.1.4 |
            +----------+------------+-------------------------+

It should say:

   The following table is to be used to initialize the property values
   registry.

            +----------+------------+-------------------------+
            | Property | Value      | Reference               |
            +----------+------------+-------------------------+
            | BEGIN    | VCARD      | RFC 6350, Section 6.1.1 |
            | END      | VCARD      | RFC 6350, Section 6.1.2 |
            | KIND     | individual | RFC 6350, Section 6.1.4 |
            | KIND     | group      | RFC 6350, Section 6.1.4 |
            | KIND     | org        | RFC 6350, Section 6.1.4 |
            | KIND     | location   | RFC 6350, Section 6.1.4 |
            | VERSION  | 4.0        | RFC 6350, Section 6.7.9 |
            +----------+------------+-------------------------+

Notes:

Here the registration of "4.0" value for VERSION is added, as it was discussed on WG mailing list.  When the erratum is approved, I'll ask IANA to add an entry on the registry, correspondingly.

Status:

Verified

Type:

Editorial

Reported By:

Kai Giebeler

Date Reported:

2012-02-25

Verified by:

Peter Saint-Andre

Date Verified:

2012-02-27

Section 5.4. says:

The ALTID property MAY also be used in may contexts other than with
   the LANGUAGE parameter.

It should say:

The ALTID property MAY also be used in many contexts other than with
   the LANGUAGE parameter.

Status:

Verified

Type:

Editorial

Reported By:

Stefan Ganzer

Date Reported:

2012-10-01

Verified by:

Barry Leiba

Date Verified:

2012-10-01

Section 7.1.3 says:

BEGIN:VCARD
VERSION:4.0
EMAIL;PID=4.2,5.1:jdoe@example.com
CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
END:VCARD

BEGIN:VCARD
VERSION:4.0
EMAIL;PID=5.1,5.2:john@example.com
CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
END:VCARD

It should say:

BEGIN:VCARD
VERSION:4.0
FN:J. Doe
EMAIL;PID=4.2,5.1:jdoe@example.com
CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
END:VCARD

BEGIN:VCARD
VERSION:4.0
FN:J. Doe
EMAIL;PID=5.1,5.2:john@example.com
CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
END:VCARD

Notes:

Section 6.2.1 states that "[t]he [FN] property MUST be present in the vCard object."

Status:

Verified

Type:

Editorial

Reported By:

Philipp Kewisch

Date Reported:

2013-10-10

Verified by:

Barry Leiba

Date Verified:

2013-10-10

Section 10.3.3 says:

The following table has been used to initialize the parameters registry.

It should say:

The following table has been used to initialize the data types registry.

Notes:

This is a copy/paste failure from the previous section.

Status:

Verified

Type:

Editorial

Reported By:

Ivan Enderlin

Date Reported:

2015-01-28

Verified by:

Barry Leiba

Date Verified:

2015-02-01

Section 6.2.5 says:

             BDAY;19531015T231000Z

It should say:

             BDAY:19531015T231000Z

Notes:

A typo when declaring the third BDAY property example: It is a colon, not a semi-colon.

Status:

Reported

Type:

Technical

Reported By:

Rick van Rein

Date Reported:

2017-01-10

Section 10.1 says:

   IANA has registered the following Media Type (in
   <http://www.iana.org/>) and marked the text/directory Media Type as
   DEPRECATED.

...

      In addition, the following media types are known to have been used
      to refer to vCard data.  They should be considered deprecated in
      favor of text/vcard.

      *  text/directory
      *  text/directory; profile=vcard
      *  text/x-vcard

It should say:

   IANA has registered the following Media Type (in
   <http://www.iana.org/>).

...

      In addition, the following media types are known to have been used
      to refer to vCard data.  They should be considered deprecated in
      favor of text/vcard.

      *  text/directory
      *  text/directory; profile=vcard
      *  text/x-vcard

Notes:

The first section needs correction, I quoted the second without change because I believe it carries the true intention; this looks like a mix-up of language between author and IANA.

This is a specification of media type for the vCard data format.  Once vCards were carried along with the text/directory media type, and that _use_ is to be deprecated, but not the _entire_ media type.  This media type applies to a completely different topic, namely LDAP, and it can't be right that a (former) usage of this media type leads to its retraction.

I posted this with IANA too, correspondence with them should use [IANA #944546] in the subject header.

Status:

Reported

Type:

Technical

Reported By:

b4D8

Date Reported:

2021-11-19

Section 8 says:

TZ:-0500

It should say:

TZ;VALUE=utc-offset:-0500
or
TZ:EST

Notes:

As specified in section 6.5.1.: "The default is a single text value. It can also be reset to a single URI or utc-offset value." Accordingly, the "utc-offset" value data-type should be explicitely set or the property value should be interpreted as text.

The section 6.5.1. further states that "utc-offset values SHOULD NOT be used" so probably using the timezone as an example is more consistent.

Status:

Reported

Type:

Technical

Reported By:

Emily Love Mills (she/her)

Date Reported:

2022-01-06

Reported by:

RFC Editor

Section 6.2.7 says:

   Examples:

     GENDER:M
     GENDER:F
     GENDER:M;Fellow
     GENDER:F;grrrl
     GENDER:O;intersex
     GENDER:;it's complicated

It should say:

   Examples:

     GENDER:M
     GENDER:F
     GENDER:M;Transgender Man
     GENDER:F;Transfeminine
     GENDER:O;Intersex
     GENDER:;Agender

Notes:

This errata replaces the imaginary gender identities with examples of actual diverse gender identities.

Status:

Reported

Type:

Technical

Reported By:

James Benner

Date Reported:

2022-02-27

Section 6.1.3 says:

SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US

It should say:

SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen\,%20o=Babsco\,%20c=US

Notes:

Section 3.4 states that all property values must have COMMA characters escaped with a BACKSLASH character. The SOURCE property value in the example contains a comma. Therefore it must be escaped with a backslash.

Status:

Reported

Type:

Technical

Reported By:

Ken Murchison

Date Reported:

2022-07-29

Section 8 says:

    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

It should say:

    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

Notes:

While the given TYPE parameters are grammatically correct, in their current form they don't portray what I believe to be the intent of the example.  In their current form, both TYPE parameters have just a single value because of the quoting.  Since TYPE can be multi-valued, I believe the intent of the example was for these parameters to have 3 and 5 values respectively which is accomplished by the corrected text.

Unfortunately, even though examples are only informative (the ABNF is always normative), the mistake in the example has led to implementations in the wild that perform the same quoting but also assume that the parameter should be treated as multi-valued.

Status:

Reported

Type:

Technical

Reported By:

Gastón Mascareñas

Date Reported:

2024-09-03

Section 6.2 says:

(none - missing)

It should say:

(See notes)

Notes:

This RFC does not provide guidance nor an example of how to specify names for the N and FN Identification Properties when these contain special characters, for example as in my name Gastón Mascareñas.

Status:

Reported

Type:

Technical

Reported By:

Einhard Leichtfuß

Date Reported:

2024-09-19

Section 5.2 says:

                / iana-token  ; registered as described in section 12

It should say:

                / iana-token  ; registered as described in section 10.2

Notes:

I am uncertain of whether this should be a "technical" or "editorial" report. 

The currently referenced section 12 is the References section.

The reference should instead be to section 10.2 (or maybe 10.2.5).

Status:

Held for Document Update

Type:

Technical

Reported By:

Roberto Javier Godoy

Date Reported:

2012-01-30

Held for Document Update by:

Peter Saint-Andre

Section 5.6 says:

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

It should say:

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.

Status:

Held for Document Update

Type:

Technical

Reported By:

Kai Giebeler

Date Reported:

2012-02-25

Held for Document Update by:

Peter Saint-Andre

Section 3.3. says:

   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

   SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ";", ":"

It should say:

   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

   SAFE-CHAR = WSP / "!" / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ",", ";", ":"

Notes:

"5. Property Parameters" states: "Property parameter value elements that contain the COLON (U+003A), SEMICOLON (U+003B), or COMMA (U+002C) character separators MUST be specified as quoted-string text values."

So COMMA cannot be part of a non-quoted parameter value which should be reflected by the SAFE-CHAR declaration.

Otherwise a value of
X-PARAM=tel,fax
could be ambiguously interpreted as
"tel","fax" (separated values)
and "tel,fax" (combined value containing a COMMA)

Status:

Held for Document Update

Type:

Technical

Reported By:

Kai Giebeler

Date Reported:

2012-02-25

Held for Document Update by:

Peter Saint-Andre

Section 3.3. et. al. says:

3.3. ABNF Format Definition
   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE
   any-param  = (iana-token / x-name) "=" param-value *("," param-value)

5.6. TYPE
   type-param = "TYPE=" type-value *("," type-value)

5.9. SORT-AS
   sort-as-value = param-value *("," param-value)
   SORT-AS="Harten,Rene"

6.4.1. TEL
   TYPE=text;TYPE=voice
   TYPE="voice,fax"

It should say:

The semantics of of lists passed to/by parameters should be consistent
or clearly stated.

Notes:

(I'm unsure if this is a technical problem or simply needs to be clarified)

All of the following parameters seem to be allowed and seem to be (more or less) equivalent:
X-PARAM="tel,fax,mail"
X-PARAM="tel","fax","mail"
X-PARAM="tel",fax,"mail,pager"
X-PARAM="tel,fax";X-PARAM="mail",pager

The main advantage of quoting strings gets lost, if contained characters get a special meaning (like a comma for separation).

In my opinion quoted values should be considered to be some kind of atomic. Without that rule there's no generic approach to interpret unknown parameter values. e.g.
X-PARAM="doc1.txt?row=10,col=6","doc2.txt?row=3,col=5"

If "voice,fax" may be decomposed to "voice", "fax" the example could be decomposed to:
- "doc1.txt?row=10"
- "col=6"
- "doc2.txt?row=3"
- "col=5"
... which is clearly not the authors intention. By recomposing it could end up as
"doc1.txt?row=10,col=6,doc2.txt?row=3,col=5"

Preserving unknown parameters in a read-modify-write-process is nearly impossible to implement.

Status:

Held for Document Update

Type:

Technical

Reported By:

Michael Angstadt

Date Reported:

2013-02-18

Held for Document Update by:

Barry Leiba

Date Held for Document Update:

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

Status:

Held for Document Update

Type:

Technical

Reported By:

Eric Vought

Date Reported:

2014-12-28

Held for Document Update by:

Barry Leiba

Date Held for Document Update:

2015-01-02

Section 5.4 says:

"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names."

It should say:

"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names.

"Values for group and for the PREF parameter SHOULD be the same for all
alternative representations of the same property. The values of group
and PREF are not defined for a property if they differ among alternative
representations of the same logical property."

Notes:

The corrected text "not defined" is intended as a literal statement of the consequences of the current specification and not a change to the meaning of the current specification. The submitter recommends that the text "Values for the group and for the PREF parameter MUST be the same..." be considered for future versions of this document.

It is also requested that the example below be added to the "legal but questionable" list in section 5.4.

Section 3.3 contains the text:

"The group construct is used to group related properties together.
The group name is a syntactic convention used to indicate that all
property names prefaced with the same group name SHOULD be grouped
together when displayed by an application."

There is no valid interpretation available for an application if a logical property has more than one group (see example below) and clearly no way to display such properties together, therefore the group construct has no defined meaning for such a case. This is particularly troublesome when converting to formats such as the VCard XML Schema where the group is represented as an XML schema in which properties are contained.

Also, Section 5.3 states in reference to the PREF parameter:

"Note that the value of this parameter is to be interpreted only in
relation to values assigned to other instances of the same property
in the same vCard.  A given value, or the absence of a value, MUST
NOT be interpreted on its own."

The meaning of "instances of the same property" is not decipherable with respect to logical properties which differ in their PREF parameter value, therefore application behavior is also not defined for this case.

Example:

volunteer.ORG;ALTID=1;PREF=1;LANGUAGE=en:Doctors Without Borders
causes.ORG;ALTID=1;LANGUAGE=fr:Médecins Sans Frontières
volunteer.ORG:Community Emergency Response Team;Some County\, Some State
volunteer.ROLE:CERT Instructor
ORG;TYPE=WORK:Sometown Medical Center

The alternative representation of "Doctors Without Borders" is legal according to the current text but breaks the 'volunteer' grouping: the same logical property is requested by the VCard to appear in two places. Similarly, the PREF tag on "Doctors Without Borders" is legal but nonsensical. The logical application representation of the ORG properties with ALTID=1 as the same logical property breaks sort ordering or selection by PREF. Similarly, application representation of PREF as a priority queue of properties breaks for this case. The application is forced to drop consideration of PREF and group in these cases and should be explicitly allowed to do so (even though it may support PREF and grouping in the general case).

======================================
======================================

Verifier notes:

This is a complicated issue that needs discussion and that goes well beyond what errata can cover.  I'm marking this as "held for document update" to leave the introduction to the issue here, because the confusion about how to interoperate here is real.  But readers need to follow any subsequent discussion on the vcarddav mailing list.
======================================

Status:

Held for Document Update

Type:

Technical

Reported By:

Ivan Enderlin

Date Reported:

2015-01-27

Held for Document Update by:

Barry Leiba

Date Held for Document Update:

2015-03-02

Section 6.7.7 says:

   Value type:  A semicolon-separated pair of values.  The first field
      is a small integer corresponding to the second field of a PID
      parameter instance.  The second field is a URI.  The "uuid" URN
      namespace defined in [RFC4122] is particularly well suited to this
      task, but other URI schemes MAY be used.

It should say:

   Value type:  A single structured text value consisting of components
      separated by the SEMICOLON character (U+003B). The first
      component is a small integer corresponding to the second
      component of a PID parameter instance.  The second component is a
      URI. The "uuid" URN namespace defined in [RFC4122] is particularly
      well suited to this task, but other URI schemes MAY be used.

Notes:

A “semicolon-separated pair of values” is a structured text value. Moreover, the RFC6351 considers the CLIENTPIDMAP property with a structured text value (see the Relax NG Schema definition of property-clientpidmap).

----- Verifier Notes -----
The original text would not cause any real confusion or interoperability issues, so this is held for document update.  That said, the corrected text is more accurate and better represents the working group's consensus at the time the RFC was published.

Status:

Held for Document Update

Type:

Technical

Reported By:

Ivan Enderlin

Date Reported:

2015-02-05

Held for Document Update by:

Barry Leiba

Date Held for Document Update:

2015-03-02

Section 4.3 says:

In RFC6351 (Appendice A), we have a Relax NG Schema defining date and
time format:

# 4.3.1
value-date = element date {
    xsd:string { pattern = "\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d" }
  }

# 4.3.2
value-time = element time {
    xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

# 4.3.3
value-date-time = element date-time {
    xsd:string { pattern = "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

# 4.3.4
value-date-and-or-time = value-date | value-date-time | value-time

We assume this is the format from ISO.8601.2004 mentioned in RFC6350.
There is no link on ISO.8601.2004 because ISO documents are not free.
So this is our guess: These formats are very close based on different
examples in RFC6350 and RFC6351.

It should say:

See notes.

Notes:

Question: --10 is October or 10 seconds?

--10 can fit into value-date and value-time:

  * From value-date, the 3rd element in the disjunction is --\d\d(\d\d)?, so it matches --10,
  * From value-time, the last element in the first disjunction is --\d\d, so it matches --10.

value-date-and-or-time matches value-date before value-time. Conclusion: --10 is always October and never 10 seconds. Is it a technical error in the RFC.


PS: This erratum can be applied on RFC6350 and RFC6351.
PPS: Consider the following erratum http://www.rfc-editor.org/errata_search.php?rfc=6351&eid=4247 on value-time also.

----- Verifier Notes -----
This errata report highlights a real problem that was not foreseen by the working group at the time when the RFC was published. Interoperability issues could result, so it's important to take note of this.

Fixing the problem will require revising the RFC, possibly in a non-backward-compatible manner. The fix is not trivial and discussion and a document update will be necessary.

Status:

Held for Document Update

Type:

Editorial

Reported By:

David Keegel

Date Reported:

2011-10-25

Held for Document Update by:

Peter Saint-Andre

Section 6.5.1 says:

          Examples:

            TZ:Raleigh/North America

It should say:

          Examples:

            TZ:America/New_York

Notes:

The example given is not valid for the Olson/TZ database; it includes a space, it has the specific location (city) before the continent, neither city nor continent names are present for the current TZ database, and there isnt a separate time zone for Raleigh, NC (since Raleigh's clocks have always matched New York's since 1970, Raleigh uses America/New_York as its time zone name in the Olson database).

Status:

Held for Document Update

Type:

Editorial

Reported By:

Peter K. Sheerin

Date Reported:

2011-12-25

Held for Document Update by:

Pete Resnick

Date Held for Document Update:

2011-12-29

Section 6.4.2 says:

   Special notes:  The property can include tye "PREF" parameter to
      indicate a preferred-use email address when more than one is
      specified.

It should say:

   Special notes:  The property can include the "PREF" parameter to
      indicate a preferred-use email address when more than one is
      specified.

Notes:

Simple misspelling of "the"

Status:

Held for Document Update

Type:

Editorial

Reported By:

Ken Murchison

Date Reported:

2024-04-16

Held for Document Update by:

RFC Editor

Date Held for Document Update:

2024-04-17

Section A.4 says:

<Nonexistent>

It should say:

A.4.  Updated Property Value Data Types

   o  The syntax of the UTC-OFFSET property value type has changed from:
          "+" / "-" hour ":" minute
      to:
          "+" / "-" hour [minute]

   o  The default value type for the UID property has changed from TEXT to URI.

   o  The default value type for the PHOTO, LOGO, SOUND, and KEY properties
      has changed from BINARY to URI.

   o  The default value type for the TZ property has changed from UTC-OFFSET to TEXT.

   o  The value type for the GEO property has changed from a structured value
      of the form:
          float ";" float
      to a URI.

Notes:

Several property value data types were changed between RFCs 2425/2426 and 6350.  
Assuming that these changes were intentional, they were never spelled out in an appendix as was done for the new and removed elements.

I've listed the changes that I discovered here to inform a future document update.

Status:

Rejected

Type:

Technical

Reported By:

Larry Masinter

Date Reported:

2012-04-23

Rejected by:

Barry Leiba

Date Rejected:

2012-05-02

Section 3.1 and 10.1 says:

In Section 3.1:

  It is invalid to specify a value other than "UTF-8" in the
   "charset" MIME parameter (see Section 10.1).

In Section 10.1:

      "charset": as defined for text/plain [RFC2046]; encodings other
      than UTF-8 [RFC3629] MUST NOT be used.

It should say:

(none, delete both sentences)

Notes:

There is no "charset" parameter for text/vcard. Perhaps there used to be one, but it isn't listed and would serve no purpose if it did. Since there is no parameter, advice about its value is inappropriate.
 --VERIFIER NOTES-- 
   

Status:

Rejected

Type:

Editorial

Reported By:

Ryan Castellucci

Date Reported:

2024-03-18

Rejected by:

Orie Steele

Date Rejected:

2024-05-10

Section 6.2.7 says:

   Special notes:  The components correspond, in sequence, to the sex
      (biological), and gender identity.  Each component is optional.

It should say:

   Special notes:  The components correspond, in sequence, to the sex
      and gender identity.  Each component is optional.

Notes:

The term "biological" in regards to sex does not have a widely agreed upon meaning, and is primarily used to discriminate against transgender people.

Including the "biological" qualifier serves no purpose.
 --VERIFIER NOTES-- 
Rejected per: https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/

Note this topic has been better addressed in recent revisions:

https://datatracker.ietf.org/doc/html/rfc9554#section-3.2