Re: Mandatory

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


Message-Id: <3.0.5.32.19980407102537.0083a540@localhost>
Date: Tue, 07 Apr 1998 10:25:37 +0900
To: hardie@thornhill.arc.nasa.gov (Ted Hardie) (by way of Henrik Frystyk Nielsen <frystyk@w3.org>), ietf-http-ext@w3.org
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: Re: Mandatory

At 23:58 04/06/98 +0900, Ted Hardie wrote:

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

Why is this? The recipient can still parse the headers without knowing
their semantics. This is exactly the same as for any other unknown header
fields. Whether the mandatory (or optional) header fields are passed before
or afterwards doesn't change this. If you feel that this should be an issue
on the issues list then please let me know.

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

I have two points here: First, I disagree that HTTP defines end-to-end to
mean from the user agent to the origin server. For example, the text in
13.5.1 says

	* End-to-end headers, which must be transmitted to the
	ultimate recipient of a request or response. End-to-end
	headers in responses must be stored as part of a cache
	entry and transmitted in any response formed from a
	cache entry.

Think of caching, for example. The client sends a set of header fields in
the request that it considers to be end-to-end, however, they may never
reach the origin server because a cache happens to be the "ultimate
recipient".

A difference in Mandatory is that the "ultimate recipient" of a declaration
doesn't have to be the same as for the rest of the message. But this is
already the case with PICS labels and authentication that also can be
handled by other parties than the origin server and the user agent. The
whole point is that it should be transparent - it is for the feature to
define who the appropriate recipient is for non-hop-by-hop extensions.

However, that being said - I don't want to upheld the draft on essentially
a question of terminology and if we can come up with another term than
end-to-end then let's do that. Other names are welcome - or if you can
provide wording that makes the distinction clear. I have added this as an
item on the issues list.

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

Good point. I would be inclined to remove the point entirely as it is
really only the extension that can determine whether this is the right
behavior. Do you agree - or do you have a proposed wording? I have added
this as an issue.

>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?

It is important that people can use registered names without being forced
to use full URIs. The current scheme allows us to transition from a
unregistered name to a registered one. It doesn't matter whether IANA has
multiple roots. Relative URIs are really just names within the IANA URI
space. A clarifying paragraph could be useful in section 8. I have added
this as an issue. 

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

They already do - servers ask you to download plug-ins, scripts etc. It
really depends on the ubiquity of the extension in question. If it is a
well-known extension saving a round trip is significant. If not then the
extra bytes on the wire may be wasted. An extension framework has to
support both.

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

Yep - now is the time!

Thanks for your comments - the issues list is not updated yet as I am a
long way from home.

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