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: David Morris <dwm@xpasc.com>
Date: Sat, 2 Oct 2010 16:31:39 -0700 (PDT)
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.64.1010021621440.5884@egate.xpasc.com>

On Sat, 2 Oct 2010, Adam Barth wrote:

> On Sat, Oct 2, 2010 at 3:40 PM, Eric J. Bowman <eric@bisonsystems.net> wrote:
> > 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?
> 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.

I'm really confused by your argument ... I have no problem writing a 
parser for input generated by a clear specification as to how the input
should be generated. That is a sufficient specification for both the
generator and consumer of the data.

I really despise people insisting that I decode a parser specification so
I can figure out how to write my parser.

It is not necessary to state that this specification is from the
perspective of the server. It is a response header. QED from the server.

If the server generates the header and value as specified, the recipient
can process it. If the clients insisted on properly formed data, the
servers would be fixed rather quickly. Interoperability is about doing it
right, not agreeing on the secret sauce for how to handle garbage.

Dave Morris
Received on Saturday, 2 October 2010 23:32:15 UTC

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