Re: mandatory / extensions / options

Henrik 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.

Scott's approach is valuable.  However, it is (A) not yet written
(aside from the abstract and one sentence about self-terminating
encodings), and (2) it is NOT a set of requirements for the
function(s) of an extension mechanism; it is a set of guidelines
for the form of extensions. 

It is precisely this confusion between form and function that I
find confusing (and that I believe Josh was questioning).
    
    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.
    
I'm not trying to say that the Mandatory proposal is a bad one.
And it does seem to cover a large subset of the issues that I
listed (although I believe it is inaccurate to say that it
is "quite explicit" about some of them).

But the Mandatory specification has inherently taken a position
on several of these issues that limits the set of choices.  For
example, as far as I can tell, there is absolutely no way in
the Mandatory for a server to declare that a particular feature
is supported for longer than the duration of one connection.

I'm not saying that the Mandatory proposal has necessarily
taken the wrong approach on these issues, but perhaps it would
be a useful excercise to at least consider Josh's request:

   I do think we need to have a set of requirements or goals for
   what we expect for extensions mechs for HTTP.

before declaring victory.

    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?

    >	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."

-Jeff

Received on Monday, 23 March 1998 18:03:54 UTC