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

From: Thomas Roessler <[email-masked]>
Date: Wed, 24 Feb 2010 20:36:20 +0100

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.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Feb 2010 17:04:11 +0100

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

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 26 Feb 2010 18:42:59 +0100

On Fri, Feb 26, 2010 at 5:04 PM, Julian Reschke <[email-masked]> wrote:

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

That's a compelling argument for choosing "new style takes precedence"
in the spec; I don't know of good arguments the other way.

My main point is that I think we should make a choice (and either of
the possible choices sounds reasonable), not which of the specific
choices it should be.