Re: request for review: http extensions

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.

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

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

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

>Or better:
>The header-prefix is a dynamically generated string. All header fields
>in the message that match this string, using string prefix-matching,
>belong to that extension declaration.


>> That would be true if it wasn't for the problem that some existing
>> applications in some situations ignore the M- method name prefix and send
>> back a 200 OK regardless. This is particularly the case for many resources
>> services by CGI scripts. 99.9% (my rough estimate) of all CGI scripts don't
>> look at the method name handed to them by the server and returns a normal
>> response regardless of the method. This has been discussed in [4].
>I see. Thats kind of scary, though.. I'm assuming then that the CGI
>scripts treat all methods as GET? In that case, its a broader problem
>since you might send a PUT method with no extensions and get a 200 OK
>even though it wasn't really fulfilled properly. You'd think that the
>server would only pass GET requests to CGI scripts.
>In any case, a bit of motivation about why this header is needed,
>basically what you mention above, would be useful in the document.


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

Henrik Frystyk Nielsen,
World Wide Web Consortium

Received on Friday, 15 January 1999 20:14:19 UTC