RFC Errata
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.