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

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

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 1 Nov 2010 12:37:10 -0600
To: Adam Barth <ietf@adambarth.com>
Cc: httpbis <ietf-http-wg@w3.org>
Message-Id: <20101101123710.15ee6e42.eric@bisonsystems.net>
Adam Barth wrote:
> 
> It's clear from this discussion that you're most familiar with the
> concerns of server operators, which I imagine is the case for most
> participants in this working group.
>

No, I have plenty of experience dealing with user agents, and helping
others with their XHR scripting or Xforms in terms of HTTP.  Of probably
a thousand conversations regarding HTTP, it's probably a 60/40 split in
favor of server-side development, but not once in 17 years have I ever
discussed HTTP in terms of developing a browser.  Browsers may be
ubiquitous, but in terms of those who need to understand HTTP, browser
developers are, in reality, an edge case.

>
> I appreciate that server operators desire specifications that can
> read by a large number of people because there are a large number of
> server operators.
>

Again, I've coded or consulted on a variety of non-browser user agents,
as well as client-side development within browsers.  You can't really
dismiss my concerns of approachability of the spec as something which
is only of concern to server developers.  RFCs need to continue to be
accessible to all, because there's no evidence the Internet or the Web
would even exist today if they hadn't been from the start.  Don't fix
what isn't broken, or gamble the future on a wholly unproven style of
authoring RFCs.

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

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

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.

-Eric
Received on Monday, 1 November 2010 18:37:45 GMT

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