errata logo graphic

Found 19 records.

Status: Verified (12)

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.


Status: Held for Document Update (6)

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