Mandatory

From: Ted Hardie (hardie@thornhill.arc.nasa.gov)
Date: Mon, Apr 06 1998


Message-Id: <3.0.5.32.19980406235843.0083fb50@localhost>
Date: Mon, 06 Apr 1998 23:58:43 +0900
To: ietf-http-ext@w3.org
From: hardie@thornhill.arc.nasa.gov (Ted Hardie) (by way of Henrik Frystyk Nielsen <frystyk@w3.org>)
Subject: Mandatory

I agree with almost all of Yaron's recent comments on the Mandatory,
but there are a few issues I'd like to put a slightly different
spin on.

The mandatory draft presumes that the mandatory header will be
processed before any of the two digit headers it names; that
should be made *really* clear in the draft, as it is a big
change.

End-to-End's current use needs to be re-thought.  I think it
would be much cleaner to have communications meant for
non-next hop proxies to have a different header, as hop-by-hop
does.  Consumed in the middle does not mean end-to-end and
planning for either with the same header doesn't make sense
to me.

The layered approach in 5.0 seems to imply that the last
step is to apply the semantics of the method without M-;
since that is not what is meant, the language needs to 
be tightened to indicate that the semantics may be derived
from the base method, but they should not be assumed.

In 3.0 the relative URIs relating to IANA don't seem to
match real IANA URIs (rfcs have .txt appended, for example)
and IANA runs several registries, so it is not clear which
one a specific relative URI would relate to.  It seems
likely that others will want to use IANA registered tokens,
rather than URIs if this "out" is left in.  Given that
relative URIs can only have one root here, why not just bite
the bullet and require full URIs?

In Section 6.0, the spec says that a host can send a resource
with a manadatory extension without knowing if the requesting
user can deal with the extension.  That strikes me as pretty
bad design, as it wastes a *lot* of bits on the wire.  Given
the number of "You must have X to read this site" sites, I'm
afraid that it might be a fairly common case that people would
pre-emptively require extensions.  An "extension required"
response followed by a new request strikes me as a better bet.

In general, I want to acknowledge that everyone needed a
method to extend HTTP yesterday or the day before, and
to applaud all the work that has been done on it.  Let's
remember how long we'll have to live with it, though, and
make sure we give it a really strong going-over.
			regards,
				Ted Hardie
				NASA NIC