Re: First reactions to mandatory draft

At 13:54 2/9/98 EST, Ross Patterson wrote:

>Having finally finished analyzing the 20 January 1998 "Mandatory
>Extensions in HTTP" draft, I hope that's still the one you want comments
>on.  A few issues come to mind:

Yes indeed and thanks for the precise comments!

>   1) Section 3.1 "Header Field Prefixes" uses the term "agent", which
>      is new in the HTTP context.  I presume it to mean "a thing that
>      generates headers", and that it is explictly not the same as a
>      "server", although I can't figure out why.

In the HTTP/1.1 spec the equivalent is either "an HTTP application" or "an
application generating HTTP requests or responses". In the Mandatory draft,
it means "an HTTP application that implements the Mandatory extension
mechanism". That may become clearer if I change the last bullet in section
1. to say:

	An HTTP application that implements the Mandatory extension
	mechanism (an agent) declares the use of the extension by
	referencing its URI in an extension declaration (see
	section 3).

>   2) The same section says "Agents SHOULD NOT reuse header-prefix
>      values in the same message." I can see that this was carried over
>      from (at least) the 21 November 1997 PEP draft, but I think it
>      needs to be "MUST NOT".  After all, wouldn't reusing a header
>      prefix effectively alter the header-field-set associated with the
>      extension?

The reason why I didn't make it a MUST is that for certain types of
extensions adding or modifying a parameter makes sense. Take for example a
hit-meter style extension. In mandatory this can be modelled as an optional
end-to-end extension where caches that know about the extension may process
it and add its result to the existing set of parameters; caches that don't
can safely ignore it.

This, btw, ties in to your next comment about what is end-to-end, see below.

>   3) Section 4.1 "End-to-End Extensions" states that "Proxies MAT act
>      as both the initiator and the ultimate recipient of end-to-end
>      extension declarations." This is another carryover from the PEP
>      draft, but violates the normal IETF usage of "end-to-end".  I
>      think I understand the intent, but I believe another term is
>      needed for this "not-quite-end-to-not-quite-end" concept.  It may
>      even be necessary to differentiate between end-to-end and
>      sender-to-recipient extensions just as between end-to-end and
>      hop-by-hop.  I'm not proposing that, but I can see the logic.

The notion of end-to-end has been discussed in the HTTP WG, latest in the
authentication rewrite thread, I think:

	http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0181.html

Here it was brought up that proxies can act on behalf of others in certain
authentication models. Another example is a proxy that changes the
content-type on-the-fly from GIF to PNG. Hence, HTTP/1.1 already has
examples of this interpretation of end-to-end scope.

For Mandatory this means that the ultimate recipient of an extension may
differ from the ultimate recipient of the rest of the HTTP message. In both
cases, I think it makes sense to say that the extension indeed is received
by the ultimate recipient.

The current solution in Mandatory of leaving it to the extension to define
the ultimate recipient makes the extension model a lot simpler. For that
very reason I am reluctant to make it explicit in the protocol. The
complications of dealing with non-mandatory aware caches etc. are
significant in the general case, whereas they can be defined in the special
case for individual extensions.

Another possibility is to let extensions use the no-transform cache-control
directive to indicate when a proxy can or can not process an extension:

	Cache-Control: no-transform man

As this is an extended use of the no-transform, this would have to be
defined on a pr extension basis.

One could also imagine using the Warning header to indicate that the
message carried end-to-end extensions that were dealt with along the
message path. Unfortunately the Warning header has some rather strict
restrictions on it's use: It is a response header only and it can not
contain a URI to indicate which extension, we are talking about.

>   4) The example in section 13.2 "Server Uses ZipFlate Compression
>      Extension" is another simplified carry-over from the PEP draft,
>      but calls out some very interesting issues that don't arise
>      earlier in the document, at least not obviously:
>
>         A) Man and Opt headers are general headers, not request
>            headers.  That should have been implied by the example in
>            section 4.1, but it wasn't stated clearly.  All the other
>            uses in the document show only requests, not responses.  It
>            wasn't until I went back and reread the PEP draft that I
>            realized that Man and Opt were PEP and PEP-Info in sheep's
>            clothing, and therefore obviously general headers.

Good point - it was not my intent to hide it ;) It is stated in the
definition of the headers in section 4.1 and 4.2 but you are right that the
examples do not represent it well.

>         B) How can a Man header in a response to a GET be truly
>            mandatory?  The server has no in-band indication that the
>            client will honor the header instead of following HTTP 1.1
>            rules and simply ingoring it.  I don't see a way around this
>            short of increasing the HTTP version to at least 2.0.

There are many types of extensions that are enforced out-of-band:
Copyrights and other legal agreements are typical examples. In these, it
does make sense for the server to include a mandatory extension declaration
even though it doesn't know whether the client will obey it or not.

>All in all, I like this draft better than PEP as it's much less vague
>about intent and usage.

Good to hear! What do you think - should there be more explanations like
this in the spec or should we keep it separate? I would like to keep the
spec short and push the hows and whys into the extension guide line document.

Henrik

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

Received on Monday, 9 February 1998 20:48:22 UTC