Re: Comment on draft-reschke-rfc2231-in-http-10 section 4.3

On 23.03.2010 00:32, Chris Newman wrote:
> RFC 2231 did not allow two parameters with the same name but different
> languages, at least in the context of continuations that was impossible.
> Absent continuations, RFC 2231 was otherwise silent on that topic.
>
> So section 4.3 adds a new feature over and above what RFC 2231 did. It's
> a feature that will make implementations significantly more complex and
> is likely to cause interoperability problems.
>
> Much of the experience with deployment of both language tagging and
> language variants in the IETF seems to result in unnecessary complexity.
> While there are good abstract arguments for language tagging in theory,
> it seems more often than not that the parties in the exchange are unable
> to put anything useful in the field in which case it falls into the
> realm of unnecessary complexity. In addition, we have experience where
> we attempted to allow language variants (multipart/alternative) and not
> only did that usage not deploy, it is actively broken despite being an
> explicit example in RFC 1766.
>
> The one place where I've seen language variants mostly work is when the
> language tag is actually included in the attribute name (LDAP does this)
> and the "search" mechanism allows wildcarding of languages. But having
> two attributes with the same name seems dangerous.
>
> My recommendation is to remove this feature as I believe it will not be
> used in practice and will add unnecessary complexity that is likely to
> create interoperability problems.
>
> - Chris

Yes, this is indeed a problem. Proposal:

- state the issue
- rephrase 4.2 accordingly
- remove 4.3

This would change Section 4 to:

-- snip --
4.  Guidelines for Usage in HTTP Header Field Definitions

    Specifications of HTTP header fields that use the extensions defined
    in Section 3.2 should clearly state that.  A simple way to achieve
    this is to normatively reference this specification, and to include
    the ext-value production into the ABNF for that header field.

    For instance:

      foo-header  = "foo" LWSP ":" LWSP token ";" LWSP title-param
      title-param = "title" LWSP "=" LWSP value
                  / "title*" LWSP "=" LWSP ext-value
      ext-value   = <see RFCxxxx, Section 3.2>

    [[rfcno: Note to RFC Editor: in the figure above, please replace
    "xxxx" by the RFC number assigned to this specification.]]

       Note: The Parameter Value Continuation feature defined in Section
       3 of [RFC2231] makes it impossible to have multiple instances of
       extended parameters with identical parmname components, as the
       processing of continuations would become ambiguous.  Thus,
       specifications using this extension are RECOMMENDED to disallow
       this case for compatibility with RFC 2231.

4.1.  When to Use the Extension

    Section 4.2 of [RFC2277] requires that protocol elements containing
    text are able to carry language information.  Thus, the ext-value
    production should always be used when the parameter value is of
    textual nature and its language is known.

    Furthermore, the extension should also be used whenever the parameter
    value needs to carry characters not present in the US-ASCII
    ([USASCII]) character set (note that it would be unacceptable to
    define a new parameter that would be restricted to a subset of the
    Unicode character set).

4.2.  Error Handling

    Header field specifications need to define whether multiple instances
    of parameters with identical parmname components are allowed, and how
    they should processed.  It is recommended that a parameter using the
    extended syntax takes precedence.  This could be used by producers to
    use both formats without breaking recipients that do not understand
    the extended syntax yet.

    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.

       Note: at the time of this writing, many implementations failed to
       ignore the form they do not understand, or prioritize the ASCII
       form although the extended syntax was present.

-- snip --

Best regards, Julian

Received on Monday, 29 March 2010 15:23:36 UTC