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

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

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Wed, 20 Jan 1999 14:06:25 -0500
Message-Id: <>
To: anrao@cisco.com, discuss@apps.ietf.org
Cc: hoschka@w3.org
At 19:57 1/19/99 -0800, Anup Rao wrote:
>Had opportunity to read the draft, and had the following comments and
>questions :

Hi Anup,

Thanks for the comments - I am just about wrapping up a new revision which
I hope to submit today.

>Section 3 (Extension declarations)
>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.

I have just done exactly this!

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

It's for extending the declaration, not for passing extension instance
data. This has been made clear in the new revision.

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

They are by definition optional which makes sense when you know that they
are not part of the extension itself but of the extension declaration. This
has also been  clarified.

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

Depends on what you mean by "discard" - it is OK for the client to save it
as long as it doesn't try to interpret the response. I don't think it
matters here really.

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

All it says is that the request could not be fulfilled but it doesn't
provide any information to as why. However, the requirement is that the
server sends back enough information so that the client at least has a
mechanism for trying again. However, as has been discussed, it is hard for
the extension framework to know extensions are to be used and it is
therefore left to the extensions and the server to describe what is needed
in order to access the resource.


Henrik Frystyk Nielsen,
World Wide Web Consortium
Received on Wednesday, 20 January 1999 14:12:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:59 UTC