Re: Looking for comments on the HTTP Extension draft

I am wondering whether the design of this extensions mechanism
is different enough from the base design of HTTP 1.x to require
a rev in the protocol number.  In particular:

1) Headers in HTTP 1.x can be processed in any order; headers in the
extension model may be required to be processed in the order
determined by the extension, and the namespace designation header
*must* be processed first.  We have talked informally about how this
affects the use of "headers" in footers, but that needs to be formally
specified and it does differ from 1.x for chunked encodings.
 

2) The semantics of the M- methods derive from their originals to the
extent that the semantics of those originals get applied *first*, but
there is no restriction on the semantics applied after.  Think of a
GET which increments a counter, for example, like the baker's order
number machine--the semantics of GET are applied first, but the
secondary semantics make it very different from a traditional GET.

3) The treatment of URIs as identifiers is very different from
what many will expect--there is currently an expectation in the
web community that a single URI can reference changing resources,
and its use in this context needs to be very well specified.  Think,
for example, of vendors who commonly refer to a product by a single
name no matter what patch rev it is; quashing that so that specific
revs are always matched by changes to the URI needs real work.

4) The content negotiation implied by the document is also not
workable within the current CONNEG framework, because the set
intersection model CONNEG uses presumes that the resource is intended
for a single purpose; it has no provision for a resource that is a
token, a description, and machine-usable code.  In the current
framework, a device selects among multiple values in a set
intersection by q-value, not purpose.  It can't really select "one for
this and one for that" in the same operation.

I would not normally see the need for a protocol rev for an optional
extension, but the current draft says that a server can send these
when they are fully optional or based on "a priori" knowledge.  That,
to me, shouts that the possibility of their use must be somehow
indicated up front.  Revving the protocol does that; there may, of
course, be other ways which would serve just as well, and I would be
open to them.
			regards,
				Ted Hardie
				hardie@equinix.com
		





> At 10:20 12/21/98 PST, Larry Masinter wrote:
> >I don't know whether this design rationale belongs in the document
> >before it's published as an RFC. Probably a brief paragraph to that
> >effect would be useful, if only to point out that this isn't an
> >example that is necessarily to be followed for other protocols.
> 
> Sounds good to me.
> 
> Henrik
> --
> Henrik Frystyk Nielsen,
> World Wide Web Consortium
> http://www.w3.org/People/Frystyk
>

Received on Tuesday, 22 December 1998 15:22:04 UTC