Re: draft-reschke-rfc2231-in-http: section 4.2, Error Handling

[Julian Reschke <[e-mail]>]

On 24.02.2010 20:36, Thomas Roessler wrote:
> Reviewing http://www.ietf.org/id/draft-reschke-rfc2231-in-http-10.txt,
> section 4.2 says:
>
>     Header specifications that include parameters should also specify
>     whether same-named parameters can occur multiple times.  If
>     repetitions are not allowed (and this is believed to be the common
>     case), the specification should state whether regular or the extended
>     syntax takes precedence.  In the latter case, this could be used by
>     producers to use both formats without breaking recipients that do not
>     understand the syntax.
>
> Leaving the choice of precedence to the header specification implies
> that parsers need to special-case. It would seem reasonable to make a
> choice in this specification that for properties which can only occur
> once, the traditional syntax takes precedence.

That would rule out the use case where the traditional syntax is used as 
a fallback for clients that do not support the new syntax, as discussed 
in that section:

"Header specifications that include parameters should also specify 
whether same-named parameters can occur multiple times. If repetitions 
are not allowed (and this is believed to be the common case), the 
specification should state whether regular or the extended syntax takes 
precedence. In the latter case, this could be used by producers to use 
both formats without breaking recipients that do not understand the syntax.

Example:

   foo: bar; title="EURO exchange rates";
             title*=utf-8''%e2%82%ac%20exchange%20rates

In this case, the sender provides an ASCII version of the title for 
legacy recipients, but also includes an internationalized version for 
recipients understanding this specification -- the latter obviously 
should prefer the new syntax over the old one."

<http://greenbytes.de/tech/tc2231/#attfnboth2> is a test case that shows 
that using this technique, both variants can be served to clients, and 
those that understand the ext-parameter encoding will indeed pick the 
"better" parameter. Unfortunately, this appears to depend on parameter 
ordering, which I didn't want to mention in this spec. Maybe I should?

Best regards, Julian

PS: tracked as 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html#rfc.issue.handling-multiple>.