W3C home > Mailing lists > Public > ietf-discuss@w3.org > January 1999

Some comments on draft-frystyk-http-extensions-01.txt

From: Anup Rao <anrao@cisco.com>
Date: Tue, 19 Jan 1999 19:57:11 -0800
Message-ID: <36A55417.15983060@cisco.com>
To: discuss@apps.ietf.org
CC: hoschka@w3.org, henrik@w3.org
Had opportunity to read the draft, and had the following comments and
questions :

Section 3 (Extension declarations)

I found it somewhat confusing and a little premature to be talking about
the grammar for an extension declaration here. What I am saying is that
the reader hasn't been told that these declarations are actually made
inside of a special header that is not yet discussed. May be a good idea
to do it the other way around - ie. talk about the new headers first and
then the extension declaration grammar. Likewise with 3.1.
Alternatively, one could just add some text in the beginning of the
section 3 that the declarations and prefixes are placed in special
headers defined in section 4.

Also felt that the choice of name "decl-ext"(for an extended extension)
is dubious, given that we call the extension "ext-decl"
Section 3, but this is a nit.

Section 3

In a mandatory extension request , are the decl-ext parameters mandatory
as well ? What happens if a server supports the extension but not the
decl-ext ?

Section 4.2 Hop-by-Hop extensions

"the C-Man and the C-Opt header field MUST be protected..."
should be 
"the C-Man and the C-Opt header fields MUST  be protected..." ?

Section 6
If a client is the ultimate recipient of a mandatory HTTP response
containing mandatory extension declarations that either the client does
not understand or does not want to use, then it SHOULD discard the
complete response as if it were a 500 (Internal Server Error) response.

Shouldn't this be "MUST".

Section 7
This is a pretty basic question :
This status code seems to convey that "the client did not access the
resource with the required extension". Could it not also convey "the
server does not support the extension requested by the client"  ? One
could argue that many extensions would be applicable to any resource.

If a client request declares 2 mandatory extensions, and the server
supports only 1, unless I misunderstood something, there does not seem
to be a way of conveying which one was not supported. 
This will be necessary in practice. Ideally it should be conveyed in the
510 or another 5xx response.

Received on Tuesday, 19 January 1999 23:02:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:05 UTC