errata logo graphic

Found 23 records.

Status: Verified (13)

RFC6350, "vCard Format Specification", August 2011

Source of RFC: vcarddav (app)

Errata ID: 3086

Status: Verified
Type: Technical

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

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

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

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

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

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

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

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

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

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

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

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

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 (2)

RFC6350, "vCard Format Specification", August 2011

Source of RFC: vcarddav (app)

Errata ID: 4261

Status: Reported
Type: Technical

Reported By: Ivan Enderlin
Date Reported: 2015-02-05

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.


Errata ID: 4245

Status: Reported
Type: Technical

Reported By: Ivan Enderlin
Date Reported: 2015-01-27

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


Status: Held for Document Update (7)

RFC6350, "vCard Format Specification", August 2011

Source of RFC: vcarddav (app)

Errata ID: 3100

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.


Errata ID: 3138

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)


Errata ID: 3139

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.


Errata ID: 3488

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


Errata ID: 4213

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: 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.
======================================


Errata ID: 3005

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


Errata ID: 3062

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: 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: Rejected (1)

RFC6350, "vCard Format Specification", August 2011

Source of RFC: vcarddav (app)

Errata ID: 3199

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


Report New Errata