RFC 6350, "vCard Format Specification", August 2011

Note: This RFC has been updated by RFC 6868

Errata ID: 3139
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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.

Report New Errata