RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 20 records.

Status: Verified (13)

RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 3086
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Roberto Javier Godoy
Date Reported: 2012-01-09
Verifier Name: 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)

Errata ID: 3136
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Kai Giebeler
Date Reported: 2012-02-25
Verifier Name: 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

Errata ID: 3377
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Stefan Ganzer
Date Reported: 2012-10-12
Verifier Name: 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".

Errata ID: 3484
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Roberto Javier Godoy
Date Reported: 2013-02-17
Verifier Name: 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)

Errata ID: 3713
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Michael Angstadt
Date Reported: 2013-08-29
Verifier Name: 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).

Errata ID: 3846
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: David Riggle
Date Reported: 2013-12-20
Verifier Name: 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.

Errata ID: 3845
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: David Riggle
Date Reported: 2013-12-20
Verifier Name: 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.

Errata ID: 2964
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Mykyta Yevstifeyev
Date Reported: 2011-09-08
Verifier Name: 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.

Errata ID: 3000
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Mykyta Yevstifeyev
Date Reported: 2011-10-21
Verifier Name: 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.

Errata ID: 3137
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Kai Giebeler
Date Reported: 2012-02-25
Verifier Name: 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.

Errata ID: 3368
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Stefan Ganzer
Date Reported: 2012-10-01
Verifier Name: 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."

Errata ID: 3748
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Philipp Kewisch
Date Reported: 2013-10-10
Verifier Name: 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.

Errata ID: 4246
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Enderlin
Date Reported: 2015-01-28
Verifier Name: 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 (7)

RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Source of RFC: vcarddav (app)

Errata ID: 4901
Status: Reported
Type: Technical
Publication Format(s) : TEXT

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.

Errata ID: 6746
Status: Reported
Type: Technical
Publication Format(s) : TEXT

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.

Errata ID: 6812
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Emily Love Mills (she/her)
Date Reported: 2022-01-06
Edited 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.

Errata ID: 6864
Status: Reported
Type: Technical
Publication Format(s) : TEXT

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.

Errata ID: 7061
Status: Reported
Type: Technical
Publication Format(s) : TEXT

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.

Errata ID: 7316
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Charles Burkitt
Date Reported: 2023-01-23

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.

Errata ID: 7856
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ryan Castellucci
Date Reported: 2024-03-18

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.

Report New Errata



Advanced Search