Re: request for review: http extensions

Henrik Frystyk Nielsen wrote:
> >1.  o Some party designs and specifies an extension; the party assigns
> >    the extension a globally unique address (URI)
> >
> >This would seem to imply that a URI = a globally unique address, which
> >it does not (it may not contain an address). Rather, what this means
> >to say is that a globally unique identifer is assigned, and that the
> >identifer also specifies a resource which is the definition of the
> >extension itself.
> No, what is meant is that only URIs that in fact are globally unique
> identifiers can be used. I will change the wording to "globally unique URI".


> >2. The usage of the - as part of the BNF for header prefix seems
> >uneccesary. Rather, the BNF need only define the numeric value of the
> >namespace. An implementation then takes this number, appends the dash,
> >and then adds the actual header name when placing extension headers in
> >the message. In the BNF, it serves neither as a conveyer of
> >information nor as a separator between elements.
> It must be there as a separator (in fact any non-digit character would do).
> Otherwise an application can potentially block the whole prefix name space.
> This was discussed on the list [2].

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. Or, do you have some other definition of
hogging? Even if the BNF was 1*2DIGIT followed by a dash, there would be
100 possible extensions in a message, and this would be the same if it
was 1*2DIGIT without the dash, so it doesn't seem to do much.

> >3. THe usage of the field-name for ext-decl seems odd. The ext-decl
> >must be a globally unique identifier which points to a definition of
> >the extension. If this extension is documented in an RFC, then really
> >it is also a URI, probably a urn like urn:ietf:rfc:2141 (see
> >draft-ietf-urn-ietf). Why add this extra field-name parameter when a
> >URN will suffice?
> The problem is exactly the "probably". There is no current resolution for
> what the name space for RFCs and the like should be. And in case it should
> be based on URNs then they themselves are not yet resolved. Whether that
> will happen is another discussion altogether.
> Ted Hardie checked on the current status of the header field registration
> work in the drums working group and came up with this:
>         Jacob Palme on this and he tells me that DRUMs decided
>         at it's last meeting to delay working on this until the
>         821bis and 822bis documents are ready. I personally believe
>         that this means we cannot count on this registry existing
>         in the form specified by draft-ietf-drums-MHregistry-03.txt
>         any time soon.
> 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.

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

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

> >6. "The header-prefix are dynamically generated header field prefix strings
> >that can be used to indicate that all header fields in the message
> >matching the header-prefix value using string prefix-matching are
> >introduced by this extension instance."
> >
> >This sentence is a run on and is confusing, but it conveys some really
> >important information. Cleanup would be useful.
> What about:
>         The header-prefix is a dynamically generated string
>         indicating that all header fields in the message matching the
>         header-prefix string using string prefix-matching belong to
>         that extension declaration.

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.

> >7. The spec should probably say something specific about requirements for the
> >prefix strings; something like "prefix strings for different
> >extensions, or for different instances of the same extension, MUST be
> >different, but SHOULD otherwise be the same from request to request"
> You don't think this is expressed in
>         Agents MUST NOT reuse header-prefix values in the same
>         message unless explicitly allowed by the extension
>         (see section 4.1 for a discussion of the ultimate
>         recipient of an extension declaration).
>         Clients SHOULD be as consistent as possible when generating
>         header-prefix values as this facilitates use of the Vary
>         header field in responses that vary as a function of the
>         request extension declaration(s) (see [5], section 13.6).

Must have been confused when reading it; this seems fine.

> >8. The term "ultimate recipient" is used a lot, but I didn't find a
> >definition of who it is. I think that for hop by hop, its the next
> >proxy that receives the message, and for end to end, its the origin
> >server or cache. Not sure if this is right, though. You should define
> >this term more clearly.
> Sigh - this has been discussed more times than I care (or can) to keep
> track of.  The term "ultimate recipient" is introduced in the introduction:
> o The HTTP application which the extension declaration is intended for
> (hereafter called the ultimate recipient) can deduce how to properly
> interpret the extended message based on the extension declaration.
> It has been a constant source of confusion that the ultimate recipient in
> HTTP in general (not only HTTP extensions) can be a proxy in the middle and
> not necessarily has to be the user agent or origin server, see [5], section
> 13.5.1:
>         End-to-end headers, which are transmitted to the ultimate
>         recipient of a request or response. End-to-end headers in
>         responses MUST be stored as part of a cache entry and MUST
>         be transmitted in any response formed from a cache entry.
> The reason being that proxies can change the content on the fly (if not
> explicitly prohibited by a cache-control directive). Examples are image
> converting proxies, PICS proxies, anonymizing proxies, etc. I had an
> explanation of this property of HTTP but this caused more confusion than
> clarity so it was decided to take it out [6].


> >11. "Mandatory declarations MUST be applied to a
> >request message as described in section 5 and to a response message as
> >described in section 6."
> >
> >Mandatory declarations MUST be applied only when a mandatory extension
> >has been applied. This sentence just says that you must always apply
> >mandatory declarations to requests and responses.
> What about:
>         (see section 5 for how to apply mandatory extension
>         declarations to requests and section 6 for how to apply
>         them to responses)


> >13. "That is, the header fields are
> >to be included as Connection header field directives (see [5], section
> >14.10)."
> >
> >are to be included -> MUST be included.
> This is really just an explanation of how the requirement expressed in the
> preceding sentence is fulfilled in HTTP/1.1:
>         In HTTP/1.1, the C-Man and the C-Opt header field MUST be
>         protected by a Connection header field. That is, the header
>         fields are to be included as Connection header field directives
>         (see [5], section 14.10)
> I am reluctant to add a MUST here as the mechanism is defined by HTTP/1.1
> and should not be redefined by this spec.


> > Also, MUST the header fields declared in the extension also be protected
> by a COnnection header?
> Good point - what about:
> Hop-by-hop extension declarations are meaningful only for a single HTTP
> connection. In HTTP/1.1, C-Man, C-Opt and all header fields with matching
> header-prefix values defined by C-Man and C-Opt MUST be protected by a
> Connection header field. That is, these header fields are to be included as
> Connection header field directives (see [5], section 14.10). The two header
> fields have the following grammar:

Sounds good.

> >14. Its not clear why you need the Ext and M-Ext headers. According to
> >section 5, a request is responded to with a 510 if any mandatory
> >extension is not understood. So, if a client or proxy receives a
> >response that is not 510, it knows that every mandatory and hop by hop
> >was understood, so the Ext and M-Ext headers convey no useful
> >information. If a 510 is received, the request was not fulfilled and
> >neither the end to end or hop by hop mandatory extensions were
> >fulfilled.
> 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.

> >17. "It is strongly recommended that the integrity and persistence of the
> >extension identifier be maintained and kept unquestioned"
> >
> I don't think this will change anything

I guess since its not a protocol issue but a process issue thats fine.

> >18. The examples in appendix 15 would be more useful if they were more
> >complete. In particular, if the C-Opt, C-Man, Opt, and Man header
> >fields were formulated properly.
> I agree that putting in complete URIs would be a help but I don't think
> adding more "normal HTTP stuff" will help understanding the scenarios.


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

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

Received on Tuesday, 12 January 1999 01:45:48 UTC