RFC 6350, "vCard Format Specification", August 2011Source of RFC: vcarddav (app)
Errata ID: 3139
Status: Held for Document Update
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.
(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:
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.
If "voice,fax" may be decomposed to "voice", "fax" the example could be decomposed to:
... which is clearly not the authors intention. By recomposing it could end up as
Preserving unknown parameters in a read-modify-write-process is nearly impossible to implement.