W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: HTTP/1.2 topics and beyond

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Wed, 24 Jul 1996 12:27:44 -0700
To: Martin Hamilton <martin@mrrl.lut.ac.uk>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9607241227.aa04577@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1168
> | An implementation guide should be just that -- go through the steps
> | of typical and non-typical scenarios and describe how one might implement
> | each step according to the standard.  When that is done and approved by
> | actual implemeters of the protocol, go through the RFC (hopefully it will
> | be one by then) and decide what has been duplicated.
> Here's another way of thinking about the problem...  Over on the
> www-proxy list we were discussing how to make the Web a bit more
> resilient, in the proxy sense at least.  This seems to mean
> things like browsers supporting fallback proxy servers and the
> proxying of new protocol schemes, HTTP clients in general making
> use of multiple A records and SRV when available, and honouring
> TTLs in cached DNS lookups.  As an organization, we could really
> use HTTP implementations which were smart enough to do at least
> some of the more elementary things.  Heck, support for multiple
> A records would be a *big* step forward for certain vendors'
> software...
> So, does this sort of thing belong in the HTTP specification ?

No, but it does belong in an implementation guide.  In fact, one
of the big advantages of writing an implementation guide is that
you don't have to restrict the discussion to HTTP, nor do you have
to consider all possible underlying transport mechanisms for HTTP.

> The spec has lots of implementation related info in it already,
> so there is precedent.  Dilemma: it's already quite big.  Is the
> new stuff really important enough that it should be included ?
> Just another five pages or so ?  OK, maybe ten :-)

The HTTP specification defines HTTP (not DNS, bind, TCP/IP, etc.).
The only times that the draft discusses things outside HTTP is when they
are part of the design rationale of the protocol or security considerations.
Some of those descriptions are more verbose than they would need to be
if there was a separate implementation guide to reference, but they
would still be referenced from the spec.  Other things, like the discussion
of handling broken connections, could be moved to an impementation guide
without affecting the definition of HTTP.  However, it is important to
note that they are only part of the HTTP specification if they appear
inside the specification or some other RFC that updates the specification
(the set of standards-track documents associated with the protocol).

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Wednesday, 24 July 1996 13:31:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC