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 17:23:49 -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: <20101002172349.03b9e6e7.eric@bisonsystems.net>
Adam Barth wrote:
> 
> I'm not agitating for a change to how RFCs are generally written.  I'm
> saying that this document defines a profile of an existing protocol
> element.  The profile is useful to servers.  The profile is not useful
> for user agents.  The document should be clear about it's scope.
> 

Not answering my questions fails to convince me of your position.  Most
folks are perfectly capable of generating conformant syntax from this
spec.  User agents will already interpret conformant syntax correctly.
The fact that *some* user agents desire to engage in error prevention
by also interpreting nonconformant syntax which will only be generated
in a minority of cases, sounds like an extreme edge case, not enough to
warrant making an incredibly confusing change to the spec to state that
it "isn't useful for user agents" when in fact it will be, 99% of the
time.  You've failed to explain to me why browsers can't take a "must
ignore" approach to nonconformant syntax, let alone any rationale
behind standardizing an error-prevention parsing model instead of
leaving that up to implementations.

>
> > What you're suggesting sounds like wholesale change to HTTP,
> 
> That's not what I'm suggesting.  HTTP is not a profile of another
> protocol.
> 

But its headers are; they're re-used from MIME just like C-D, so I
don't see how your concerns about parsing nonstandardized syntax don't
also apply to *all* HTTP headers regardless of where they're defined,
not to mention *all* other specs which re-use MIME.  You seem to be
claiming that ABNF isn't precise enough to spec out one header in one
protocol (because it fails to define parsing for nonconformant syntax),
which seems like a concern which applies to all headers across many
protocols.

-Eric
Received on Saturday, 2 October 2010 23:24:36 GMT

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