RE: HTTP Ext Working Group Submission: Mandatory Extensions in HT TP

It does not appear that the examples match the extension grammar. For
example the first one should be: "rfc2068";;ns = SetCookie2

It is traditional to delineate URIs with "<" ">" not <">.

There is no reason given in the draft for why parameters should be included
in the extension declaration. It appears to be to be sufficient to just give
a list of URIs identifying various extensions along with prefixes. It is
then up to each of the extension definitions to define how to pass in
parameters, if any.

Given the previous comments I think the BNF should be:

Mandatory = "mandatory" ":" 1*Extend
Extend = "<" URI ">" [Name-Prefix]
Name-Prefix = 2*DIGIT

Note that while I have removed the explicit "-" I support requiring that
there be a "-" in all names. So if you have: mandatory: <urn:mommy>01 means
that any headers associated with <urn:mommy> MUST be of the form
01-Iamamommyheader.

I also think that the draft needs some language explaining that the prefixes
are dynamically generated, one does not associate a particular prefix with a
particular URI as a permanent mapping. Rather, when someone adds a mandatory
header they need to be required to check the current message, see what
prefixes if any are already in use, and pick a prefix that isn't already
used in that particular message. We really need to warn people against hard
coding a prefix.

The term "end to end" as I understand it in HTTP means client to server and
back. Proxies can not be, by definition, a recipient of an "end to end"
message because if they were then they are a server or a client, not a
proxy. As such the language at the end of 4.1 should either be removed or a
new term introduced whose meaning in this context is clearly defined.

If we are going to have mandatory response headers then it seems to me that
the proper client behavior upon receiving a mandatory response it does not
understand is to treat the response as a 500 response which contains no
headers or body. In fact we should probably introduce 3xx, 4xx, and 5xx
responses for use with Mandatory so that the server can choose how the
client will treat a mandatory response in the case that the client does not
support mandatory in general or one of the mandatory extensions in
particular.

The second and third paragraphs in section 7 really confuse me. Could you
please clarify?

Also the document should explain the relationship between mandatory and the
expect header. (Thanks Paul)

Reference 7 is Y.Y. Goland! Y. Goland is my father. =)

		Yaron Y. Goland

Received on Monday, 30 March 1998 19:35:22 UTC