Re: request for review: http extensions

Henrik Frystyk Nielsen wrote:
> 
> At 01:42 1/12/99 -0500, Jonathan Rosenberg wrote:
> 
> >I read this message and followed the thread a bit; I agree with Dave
> >Kristol here and still don't see your point. I am assuming your
> >definition of hogging the space is something like:
> >
> >Man: "myextension";ns=00-,"myextension";ns=01-,"myextension";ns=02-
> >
> >and so on.
> >
> >Now, with or without the dash, its impossible to hog the space since the
> >number of digits is unbounded.
> 
> Nope, it is still possible: 11 will match not only 11- but also 111,
> 111mynewheader, etc. That is, without the non digit separator, you can hog
> the space using 100 prefixes.

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. 

In other words:

Man: "my-extension";ns=00
00-Header1: value
000-Header1: value2

Based on the rules, a dash is appended to the header extension number
for my-extension, yielding 00-, and then a prefix search is done on the
header fields. Only the first one matches, so this one belongs to the
my-extension extension. 

> 
> >> This is the reason we went with the current solution which allows for a
> >> smooth transition from local extension to standards track RFC without
> >> having to resolve the problem of defining the URI space for IANA registered
> >> tokens and documents.
> >
> >Understandable. In that case, an implementors note saying that the URI
> >space for RFC's would be preferrable, once available, would be useful.
> 
> ok - it now says:
> 
>         The support for header field names as extension identifiers
>         provides a transition strategy from decentralized extensions
>         to extensions defined by IETF Standards Track RFCs until a
>         persistent mapping has been defined between the globally unique
>         URI space and features defined in IETF Standards Track RFCs.

Sounds good.

> 
> >> >4. The spec allows for declaration extension parameters, but none are
> >> >defined and there is no guidelines regarding what they might actually
> >> >be useful for. What is their purpose?
> >>
> >> What do you mean "none are defined" - they are intended for extending the
> >> extension declarations with (by definition) optional parameters. I am not
> >> sure what you mean?
> >
> >I mean, what would be an example of an optional parameter that someone
> >might try to use in the future?
> >
> >> >5. The spec says unrecognized decl-ext parameters SHOULD be
> >> >ignored. What else can it do? Shouldn't this be a MUST?
> >>
> >> The SHOULD is really more a guideline for what to do with unknown
> >> parameters. The only strict requirement is that it must not be removed if
> >> forwarded. I will here refer to Larry Masinter's thoughts on
> >> MAY/SHOULD/MUST [7].
> >
> >On more thought, its sort of strange that the only possibility is for
> >unknown decl-ext parameters to be ignored (i.e., the declaration
> >extension is optional). What happens if the declaration extension must
> >be understood in order to process the request?
> 
> The decl-ext extensions are only intended to extend the extension framework
> itself (the declaration) and not any of the extensions that it is used to
> declare. If you want an mandatory extension to the extension framework, you
> use the extension itself to introduce the new extension. Only one mandatory
> bit is sufficient.
> 
> Maybe this is not clear from the context so I have added:
> 
>         An agent MAY use the decl-extensions mechanism to include
>         optional extension declaration parameters but cannot assume
>         these parameters to be recognized by the recipient. This
>         mechanism MUST NOT be used to pass extension instance data,
>         which MAY be passed using header field prefix values
>         (see section 3.1). Unrecognized decl-ext parameters SHOULD
>         be ignored and MUST NOT be removed by proxies when
>         forwarding the extension declaration.

OK.

> 
> >On a related note, the extension mechanism really only allows you to
> >define new header extensions. However, extensions could also include new
> >values for existing headers or new parameters, and so on. Might be
> >useful to extend the concept to cover these cases as well. For example:
> >
> >Man: "my-extension"; ns=11-
> >Cache-Control: 11-new-cache-mechanism
> 
> This is intentional - otherwise it would require that every HTTP extension
> application knows how to parse all existing (as well as any new) header
> fields which is not possible. Because of the way MIME works, the unit of an
> extension must be a header field and not a header field parameter.

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. 


> >> >19. You might want to consider a header called Unsupported for 510
> >> >responses (its used in SIP. It could be used to list those mandatory
> >> >extensions which were not understood:
> >>
> >> The problem with this is that there may be other reasons why extensions are
> >> not accepted which can not be expressed by such a header field (they can
> >> have the wrong parameters, be combined in unacceptable ways, etc.). As this
> >> is really a function of the extensions, this is better expressed by them
> >> than by the extension protocol.
> >
> >This seem more an argument for a different response code than anything
> >else; in other words, 510 is sent ONLY when the problem was that a
> >mandatory extension was not understood since its not implemented (along
> >with the Unsupported header). If it was understood (i.e., the server
> >knows and implements it) but the values or parameters malformed, a
> >different response code would be used (perhaps a 400).
> 
> But then you have all the combinations of the two - imagine two extensions
> where one wasn't fulfilled because of lack of credentials and the other was
> not understood. I still think leaving the whole thing to the extensions is
> better.

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.

-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 Sunday, 17 January 1999 23:00:42 UTC