Re: Comments on draft-ietf-httpbis-content-disp

* Adam Barth wrote:
>1) I'm aware that there are more implementors of user agents than
>browsers.  I'm not interested in being reminded of that fact.  Browser
>user agents, however, are one important group of user agents.
>
>2) I'm aware that this working group does not share my perspective on
>what constitutes a useful specification for user agent implementors.
>I'm not interested in discussing whether the level of precision I'm
>requesting is valuable.

If you are not interested in discussing these points then simply don't
do so, but please do not attempt to discourage others discussing them;
this is an IETF mailing list where we seek to resolve issues through
open discourse and rough consensus.

>3) I'm aware that this document reflects business-as-usual in the
>IETF.  My position is that business-as-usual does not meet the needs
>of browser user agent implementors, largely because browser user agent
>implements have been effectively absent from the IETF process for the
>better part of a decade.

As I recall the previous discussion, most other participants in this
Working Group find it more important to focus on real-life problems.
That's http://code.google.com/p/chromium/issues/detail?id=52577#c1
not an uncommon position among actual browser developers either, to
pick the first Chromium bug listed on Julian's page.

>This section defines a grammar for the Content-Disposition header
>field.  However, the document does not define how a user agent should
>interpret Content-Disposition header fields that do not conform to
>this grammar.  To foster interoperability between user agent
>implementations, the document should define how user agents are to
>process every sequence of bytes they could receive in a
>Content-Disposition header field.

There is no basis for interpreting Content-Disposition header values
beyond what is defined in the draft; interpreting headers beyond what
is defined in the draft would be a proprietary extension of the pro-
tocol. Browser developers should not add their proprietary extensions
to standard protocols, that really goes without saying.

I propose browser developers remove their proprietary extensions from
their implementations and publish whatever problems they encounter in
doing so, so the protocol can be revised accordingly if needed. That's
something only the browser developers are properly equipped to do, we
would just risk specifying something that they find they cannot or do
not care to implement if it is not based on their factual findings.

Note in particular that we cannot assume, because something works in a
certain way in some browsers, that it is safe to require that; it may
very well be that the browsers that do something else cannot be up-
dated to match the behavior due to servers doing user agent sniffing,
in which case mandating the particular behavior was pointless and mis-
leading.

>=> Parameter names MUST NOT be repeated.
>
>The document should not phrase normative requirements in the passive
>voice.  Instead, the document should make clear which protocol
>partipants are bound by each requirement.  For example, this
>requirement probably should read "servers MUST NOT generate
>Content-Disposition header field values with multiple instances of the
>same parameter name."

It does not matter how a Content-Disposition header came to have more
than one parameter using the same name, as such it would be incorrect
to phrase this as a requirement for a particular actor.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 1 November 2010 18:10:41 UTC