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

Re: request for review: http extensions

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Wed, 20 Jan 1999 13:53:34 -0500
Message-Id: <>
To: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, discuss@apps.ietf.org
At 22:57 1/17/99 -0500, Jonathan Rosenberg wrote:

>I see; the problem though again is not in the BNF for the extension
>delcaration. What you are trying to say is that a header that belongs to
>an extension MUST have a dash after its extension number. Then, a header
>matches an extension if the extension number, with a dash appended to
>it, are a prefix of the header. This rule does not require the dash
>itself to be present in the BNF for the extension declaration. 

I think we are saying the same thing but represent it in two different
ways: should the "-" be part of the ns production or a part of the prefix
string matching algorithm. Either way is fine with me - one may argue that
not using the "-" in the BNF production is closer to the XML NS spec.

>I think this works so long as the application can parse the header
>fields to which the extension applies. If an extension is listed as
>mandatory, and a client doesn't know the extension, it just returns an
>error response. If it is mandatory, and the client does understand the
>extension, than presumably it knows how to parse the header to which the
>extension applies, using the new parameters. I guess the problem is with
>optional extensions, and that an application would still try to parse
>the extended header, not noticing its extended since the header looks
>the same. 

There is no guarantee that an application who knows the extension also
knows all header fields that it may be added to in the form of attributes.
Combined with the overhead of having to parse the whole message to find
these parameters, I would rather leave this out.

>I think extensions not being understood always takes precedence, since
>the extension could be defining a feature which is "ignore the lack of
>credentials for any other extensions", in which case if the extension
>was understood there would be no error for the other. If a mandatory
>extension is not understood, no other aspect of a request can be
>reliably parsed, so I still think it makes sense to report a 510 and
>list the extension that wasn't understood. But, I don't feel terribly
>strongly here, and if the group doesn't consider this an issue thats

I think this better belong in another spec (OPTIONS, for example?) which
can define a schema for passing metainformation about capabilities.


Henrik Frystyk Nielsen,
World Wide Web Consortium
Received on Wednesday, 20 January 1999 13:59:57 UTC

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