Re: mandatory / extensions / options

From: Henrik Frystyk Nielsen (frystyk@w3.org)
Date: Sat, Apr 11 1998


Message-Id: <3.0.5.32.19980411182024.007cb640@localhost>
Date: Sat, 11 Apr 1998 18:20:24 +0900
To: Jeffrey Mogul <mogul@pa.dec.com>
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: "'ietf-http-ext@w3.org'" <ietf-http-ext@w3.org>
Subject: Re: mandatory / extensions / options 

At 15:03 3/23/98 PST, Jeffrey Mogul wrote:

>    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.
>    
>Hmm.  To me, this seems to be just putting all of the hard issues
>off to another day.  Perhaps you could give me a specific scenario by
>which one could actually accomplish this example?  Or do you simply
>expect all interesting extensions to be "specified" in executable code?

For which resources and for how long to apply an extension is what I call
metadata. The metadata part of the PEP specification dealt with issues like
for how long and where to apply an extension but that was not popular. Now
I hope that OPTIONS or some other metadata mechanism will provide the
necessary support.

All Mandatory does is to declare when an extension has been applied. This
is not metainformation but transaction information.

>    >	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?
>
>No, I am saying that "RFC2068" is a particularly bad example
>as a name for reliably specifying an extension, since it has
>no clear meaning.  If we can't come up with a decent naming
>scheme.   The Mandatory draft basically punts on this
>problem, which is fine ***as a long as someone is willing to
>solve it***.  I.e., it's fine for the Mandatory proposal to
>ignore this problem, but it's silly for the WG to ignore it.
>
>    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.
>
>If you leave the naming problem up to the individual extension
>designers, it won't be solved.  At the very least, as is clearly
>suggested in draft-ietf-httpext-guidelines, someone needs to create
>an "IANA Considerations" section (or document) for this stuff.
>It won't work if the only thing we say about namespace management
>is "care should be taken."

I didn't formulate myself clearly - what I meant was that I don't think it
will affect the Mandatory mechanism directly as I expect the naming problem
can be solved within the current framework. It does indeed require further
thought. 

Henrik

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