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

Re: request for review: http extensions

From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Date: Wed, 20 Jan 1999 16:02:12 -0500
Message-ID: <36A64454.5B5E301F@dnrc.bell-labs.com>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
CC: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, discuss@apps.ietf.org
Henrik Frystyk Nielsen wrote:
> 
> 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 don't feel too strongly here, preferring slightly to leave the - out
of the BNF. 
 
> 
> >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.

Fine.

> 
> >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
> >fine.
> 
> I think this better belong in another spec (OPTIONS, for example?) which
> can define a schema for passing metainformation about capabilities.

Fine.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen
Received on Wednesday, 20 January 1999 16:05:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:25 GMT