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

Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Sat, 2 Oct 2010 16:40:54 -0600
To: Adam Barth <w3c@adambarth.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, Bjoern Hoehrmann <derhoermi@gmx.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <20101002164054.547e3d2b.eric@bisonsystems.net>
Adam Barth wrote:
> Right, this document is useful to folks who would like to generate
> this header.  It's a generative profile.  As such, its a profile for
> servers.  I'm just asking that the document be upfront about that.

Is Last Call for this draft the appropriate venue to agitate for change
to the way RFCs are generally written?  What you're suggesting sounds
like wholesale change to HTTP, such that all descriptions of MIME
header syntax are based on byte-code-level parsing models to encompass
current non-HTTP-conformant usage of those headers within HTTP messages.
Should this change be made for all other specs browsers may implement
which re-use MIME, as well?

I don't see how C-D isn't allowing a sender to define processing intent
for user agents, or how a user agent couldn't determine processing
intent from an HTTP-conformant C-D header.  It seems much more
confusing to me to describe a conformant C-D header for HTTP in terms
of a parsing model encompassing every unspecified usage of C-D
encountered so far in the wild.  Why *can't* interoperability be based
on conformant syntax, instead of agreeing how to handle nonconformant

> One the other hand, this document isn't very helpful to folks who
> would like to consume these headers.  Consumers will likely need to
> implement the full protocol, not just the well-behaved profile.

I understand the stakeholder concern, but I don't understand why the
solution is to define conformant syntax in terms of a parsing model
based on all possible mangling of the syntax ever seen.  What problem
does that solve?  Why can't that solution be implementation-specific
instead of standardizing how to parse unstandardized syntax, which is
not germane to any use case except for browsers?  I fail to see what
interoperability concern exists for anyone generating this header in a
conformant fashion, or why such concerns are in-scope to this draft.

> As such, we're still missing a specification for what user agents
> should do with these headers...

I don't understand the problem with drawing a bright line between what
everybody agrees on as a standard, and declaring everything else as
unspecified behavior.  Why should the existence of nonconformant syntax
have any bearing on how to handle conformant syntax?  Why are we
holding up C-D for being written like every other RFC I've ever read?

Received on Saturday, 2 October 2010 22:42:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC