Re: [VCARDDAV] [Technical Errata Reported] RFC6350 (3139)

[Simon Perreault <[e-mail]>]

This is a good example of parameter value quoting brokenness.

Suggested status: held for document update

Thanks,
Simon

On 2012-02-25 21:35, RFC Errata System wrote:
> The following errata report has been submitted for RFC6350,
> "vCard Format Specification".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3139
>
> --------------------------------------
> Type: Technical
> Reported by: Kai Giebeler<[e-mail]>
>
> Section: 3.3. et. al.
>
> Original Text
> -------------
> 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"
>
>
> Corrected Text
> --------------
> 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.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6350 (draft-ietf-vcarddav-vcardrev-22)
> --------------------------------------
> Title               : vCard Format Specification
> Publication Date    : August 2011
> Author(s)           : S. Perreault
> Category            : PROPOSED STANDARD
> Source              : vCard and CardDAV
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG


-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca