Re: mandatory / extensions / options

At 11:54 3/23/98 PST, Jeffrey Mogul wrote:

What are you suggesting? Scott sent out a long time ago a very
rough/initial draft of how people should and shouldn't extend HTTP:

http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-ietf-httpext-guidelines

I am all for extending and finishing this draft if that is what you are
referring to.

On the other hand, Mandatory is quite explicit about the following:

	support vs. want
	direction
	end-to-end vs. hop-by-hop
	granularity of support
	duration of support
	feature naming

as well as allowing multiple extensions (and instances thereof) to coexist
and to allow for local as well as global extensions.

Note that there is an important difference between not being explicit and
allowing extensions to decide their own rules if so inclined. This is a
question of keeping the extension framework simple.

The tradeoff in Mandatory was exactly to make it very simple and very clear
what it means to add an extension declaration to a message. If an extension
needs to say: this extension is mandatory for a month for the third proxy
then this is for the extension to describe.

>	feature grouping
>		can we group features into named sets without
>		getting too confused?  (E.g., "RFC2068" is
>		problematic especially if we don't specify
>		whether we mean MUST-level or SHOULD-level).

Again, I am not sure what you are saying - do you mean that RFC2068 doesn't
make it clear which features are MUST, SHOULD, or MAY and so you want the
extension framework to be applicable to each parameter of an arbitrary
extension instance in order to avoid interoperability problems?

Although this is indeed a valid concern, I don't think it is the task of
the extension mechanism to solve it but rather for the extension designers.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Monday, 23 March 1998 15:56:45 UTC