W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

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

From: Adam Barth <ietf@adambarth.com>
Date: Mon, 1 Nov 2010 12:20:11 -0700
Message-ID: <AANLkTingDXcjuqKU92GWeT_wK_Xpc74MppXFpr4Lr4vQ@mail.gmail.com>
To: "Eric J. Bowman" <eric@bisonsystems.net>
Cc: httpbis <ietf-http-wg@w3.org>
On Mon, Nov 1, 2010 at 11:37 AM, Eric J. Bowman <eric@bisonsystems.net> wrote:
>> I'm not requesting that any of that information in the document be
>> removed or have its presentation altered.  I'm requesting that the
>> document either clarify that it is intended for that specific
>> audience or that more information be added to the document so that it
>> is useful to another audience.
>
> The nature of your request is to change the document to break with MIME
> syntax re-used by HTML headers, in a way which breaks back-compatibility
> for anyone who correctly assumed '%' would be taken literally, and
> claiming that it's unusable otherwise, to make it *only* usable to
> those coding browsers, while blithely ignoring that C-D may be used by
> HTTP-based package management systems having nothing to do with
> browsing the Web.  I see nothing wrong with approving C-D as an RFC as
> worded, or how it's only relevant to the server side.  As I've stated
> before, you haven't made a compelling case to hold up this draft for
> being written like any other RFC I was able to teach myself the
> Internet by reading.

Do you expect browser user agents to change their behavior w.r.t. the
% character in filename parameter in Content-Disposition header
fields?  I don't see an evidence that they will.  It's disingenuous to
claim this document specifies the Content-Disposition header field
when it ignores how that header field is processed by user agents used
by hundreds of millions of users.

>> We are perfectly capable, of course, of ignoring the IETF and forming
>> our own standards body to write specifications of HTTP,
>> Content-Disposition, URLs, etc, that meet our needs, as you suggest.
>> There are certainly folks who would prefer that we went down that
>> road.  However, I'd rather we were more engaged in the IETF process,
>> but that means influencing the IETF to produce documents that are
>> useful to us, which is the goal of my previous message.
>
> Please don't twist my words into a strawman.  Actually, the standards
> effort I suggest would be right up the w3c's alley, and wouldn't come
> anywhere near re-writing the HTTP spec, even C-D.  The problem is, the
> HTTP spec can't assume that "user-agent" implies rendering content.  In
> fact, many user agents (googlebot) only interpret content.  Many of the
> issues you're suggesting HTTP be changed to account for, simply don't
> apply to user-agents *unless* they're rendering content.

I don't see a connection between the ability to compute the requested
file name from a Content-Disposition header field value and rendering
content.  Presumably the requested file name is part of the semantics
of this header field value.  Shouldn't the specification define what
that file name the header field requests?

> But that's a separate concern from the semantics of messaging between
> connectors, and one worthy of another specification effort catering
> specifically to that small minority of those implementers actually
> developing browsers or otherwise dealing with the rendering rather than
> the interpretation of payloads.  There's really no need to conflate the
> term "user-agent" with "browser" when the notion of interpreting vs.
> rendering is external to HTTP entirely, because while the result may
> please browser vendors it makes the spec incomprehensible except as
> understood within that context, which is unapproachable to the vast
> majority of those who need to be able to understand the HTTP spec.

It sounds like you're advocating for resolution (2), which I think is fine.

Adam
Received on Monday, 1 November 2010 19:21:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT