Re: request for review: http extensions

At 02:09 1/6/99 -0500, Jonathan Rosenberg wrote:
>Sorry for the late review (I hope its not too late). Hope its useful.

Very useful - thanks for a very detailed review! Too bad that you haven't
been in on the mailing list discussions [1] as many of your questions have
been discussed there at length.

>1.  o Some party designs and specifies an extension; the party assigns
>    the extension a globally unique address (URI)
>
>This would seem to imply that a URI = a globally unique address, which
>it does not (it may not contain an address). Rather, what this means
>to say is that a globally unique identifer is assigned, and that the
>identifer also specifies a resource which is the definition of the
>extension itself.

No, what is meant is that only URIs that in fact are globally unique
identifiers can be used. I will change the wording to "globally unique URI".

>2. The usage of the - as part of the BNF for header prefix seems
>uneccesary. Rather, the BNF need only define the numeric value of the
>namespace. An implementation then takes this number, appends the dash,
>and then adds the actual header name when placing extension headers in
>the message. In the BNF, it serves neither as a conveyer of
>information nor as a separator between elements.

It must be there as a separator (in fact any non-digit character would do).
Otherwise an application can potentially block the whole prefix name space.
This was discussed on the list [2].

>3. THe usage of the field-name for ext-decl seems odd. The ext-decl
>must be a globally unique identifier which points to a definition of
>the extension. If this extension is documented in an RFC, then really
>it is also a URI, probably a urn like urn:ietf:rfc:2141 (see
>draft-ietf-urn-ietf). Why add this extra field-name parameter when a
>URN will suffice?

The problem is exactly the "probably". There is no current resolution for
what the name space for RFCs and the like should be. And in case it should
be based on URNs then they themselves are not yet resolved. Whether that
will happen is another discussion altogether. 

Ted Hardie checked on the current status of the header field registration
work in the drums working group and came up with this:

	Jacob Palme on this and he tells me that DRUMs decided
	at it's last meeting to delay working on this until the
	821bis and 822bis documents are ready. I personally believe
	that this means we cannot count on this registry existing
	in the form specified by draft-ietf-drums-MHregistry-03.txt
	any time soon.

This is the reason we went with the current solution which allows for a
smooth transition from local extension to standards track RFC without
having to resolve the problem of defining the URI space for IANA registered
tokens and documents.

>4. The spec allows for declaration extension parameters, but none are
>defined and there is no guidelines regarding what they might actually
>be useful for. What is their purpose?

What do you mean "none are defined" - they are intended for extending the
extension declarations with (by definition) optional parameters. I am not
sure what you mean?

>5. The spec says unrecognized decl-ext parameters SHOULD be
>ignored. What else can it do? Shouldn't this be a MUST?

The SHOULD is really more a guideline for what to do with unknown
parameters. The only strict requirement is that it must not be removed if
forwarded. I will here refer to Larry Masinter's thoughts on
MAY/SHOULD/MUST [7]. 

>6. "The header-prefix are dynamically generated header field prefix strings
>that can be used to indicate that all header fields in the message
>matching the header-prefix value using string prefix-matching are
>introduced by this extension instance." 
>
>This sentence is a run on and is confusing, but it conveys some really
>important information. Cleanup would be useful.

What about:

	The header-prefix is a dynamically generated string
	indicating that all header fields in the message matching the
	header-prefix string using string prefix-matching belong to
	that extension declaration.

>7. The spec should probably say something specific about requirements for the
>prefix strings; something like "prefix strings for different
>extensions, or for different instances of the same extension, MUST be
>different, but SHOULD otherwise be the same from request to request"

You don't think this is expressed in

	Agents MUST NOT reuse header-prefix values in the same
	message unless explicitly allowed by the extension
	(see section 4.1 for a discussion of the ultimate
	recipient of an extension declaration).

	Clients SHOULD be as consistent as possible when generating
	header-prefix values as this facilitates use of the Vary
	header field in responses that vary as a function of the
	request extension declaration(s) (see [5], section 13.6).

>8. The term "ultimate recipient" is used a lot, but I didn't find a
>definition of who it is. I think that for hop by hop, its the next
>proxy that receives the message, and for end to end, its the origin
>server or cache. Not sure if this is right, though. You should define
>this term more clearly.

Sigh - this has been discussed more times than I care (or can) to keep
track of.  The term "ultimate recipient" is introduced in the introduction:

o The HTTP application which the extension declaration is intended for
(hereafter called the ultimate recipient) can deduce how to properly
interpret the extended message based on the extension declaration.

It has been a constant source of confusion that the ultimate recipient in
HTTP in general (not only HTTP extensions) can be a proxy in the middle and
not necessarily has to be the user agent or origin server, see [5], section
13.5.1:

	End-to-end headers, which are 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 MUST
	be transmitted in any response formed from a cache entry.

The reason being that proxies can change the content on the fly (if not
explicitly prohibited by a cache-control directive). Examples are image
converting proxies, PICS proxies, anonymizing proxies, etc. I had an
explanation of this property of HTTP but this caused more confusion than
clarity so it was decided to take it out [6].

>9. THe appendices start numbering at 14, essentially as continuations
>of section numbers. They should probably start over at 1 or A.

ok

>10. (See section 4.1 and 4.2, and appendix 14
>for a table of interactions with origin servers and proxies.)
>
>This is gramatically incorrect. Should be:
>
>(See sections 4.1 and 4.2; also see appendix 14 which has a table
>of....)

ok

>11. "Mandatory declarations MUST be applied to a
>request message as described in section 5 and to a response message as
>described in section 6."
>
>Mandatory declarations MUST be applied only when a mandatory extension
>has been applied. This sentence just says that you must always apply
>mandatory declarations to requests and responses.

What about:

	(see section 5 for how to apply mandatory extension
	declarations to requests and section 6 for how to apply
	them to responses)

>12. "The ultimate recipient of a mandatory end-to-end extension declaration
>
>MUST handle that extension declaration as described in section 5 and
>6."
>
>Extra carriage return in the middle of the sentence.

Hmm, I wonder where that came from - could be a formatting problem while
printing the test only version.

>13. "That is, the header fields are
>to be included as Connection header field directives (see [5], section
>14.10)."
>
>are to be included -> MUST be included.

This is really just an explanation of how the requirement expressed in the
preceding sentence is fulfilled in HTTP/1.1:

	In HTTP/1.1, the C-Man and the C-Opt header field MUST be
	protected by a Connection header field. That is, the header
	fields are to be included as Connection header field directives
	(see [5], section 14.10)

I am reluctant to add a MUST here as the mechanism is defined by HTTP/1.1
and should not be redefined by this spec.

> Also, MUST the header fields declared in the extension also be protected
by a COnnection header?

Good point - what about:

Hop-by-hop extension declarations are meaningful only for a single HTTP
connection. In HTTP/1.1, C-Man, C-Opt and all header fields with matching
header-prefix values defined by C-Man and C-Opt MUST be protected by a
Connection header field. That is, these header fields are to be included as
Connection header field directives (see [5], section 14.10). The two header
fields have the following grammar:

>14. Its not clear why you need the Ext and M-Ext headers. According to
>section 5, a request is responded to with a 510 if any mandatory
>extension is not understood. So, if a client or proxy receives a
>response that is not 510, it knows that every mandatory and hop by hop
>was understood, so the Ext and M-Ext headers convey no useful
>information. If a 510 is received, the request was not fulfilled and
>neither the end to end or hop by hop mandatory extensions were
>fulfilled.

That would be true if it wasn't for the problem that some existing
applications in some situations ignore the M- method name prefix and send
back a 200 OK regardless. This is particularly the case for many resources
services by CGI scripts. 99.9% (my rough estimate) of all CGI scripts don't
look at the method name handed to them by the server and returns a normal
response regardless of the method. This has been discussed in [4].

>15. "The Ext and the C-Ext header fields are not mutually exclusive, they can
>both occur within the same message as described in section 5.1."
>
>The comma should be a semicolon.

ok

>16. Why does the method name need to be prefixed with an M? Is this
>for compatibility with HTTP implementations which don't understand
>this extension mechanism?

yes, exactly

>17. "It is strongly recommended that the integrity and persistence of the
>extension identifier be maintained and kept unquestioned"
>
>RECOMMENDED

I don't think this will change anything

>18. The examples in appendix 15 would be more useful if they were more
>complete. In particular, if the C-Opt, C-Man, Opt, and Man header
>fields were formulated properly.

I agree that putting in complete URIs would be a help but I don't think
adding more "normal HTTP stuff" will help understanding the scenarios.

>19. You might want to consider a header called Unsupported for 510
>responses (its used in SIP. It could be used to list those mandatory
>extensions which were not understood:

The problem with this is that there may be other reasons why extensions are
not accepted which can not be expressed by such a header field (they can
have the wrong parameters, be combined in unacceptable ways, etc.). As this
is really a function of the extensions, this is better expressed by them
than by the extension protocol.

>Besides this, the draft seems to be a
>reasonably complete solution for extensions.

Thanks!

Henrik

[1] http://lists.w3.org/Archives/Public/ietf-http-ext/
[2] http://lists.w3.org/Archives/Public/ietf-http-ext/1998AprJun/0003.html
[3] http://www.egroups.com/list/http-wg/mg601080931.html
[4] http://lists.w3.org/Archives/Public/ietf-http-ext/1998JulSep/0004.html
[5] http://lists.w3.org/Archives/Public/ietf-http-ext/1998AprJun/0029.html
[6] http://lists.w3.org/Archives/Public/ietf-http-ext/1998AprJun/0027.html
[7] http://www.egroups.com/list/http-wg/mg752462118.html
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Friday, 8 January 1999 18:09:31 UTC