Re: request for review: http extensions

Sorry for the late review (I hope its not too late). Hope its useful.

-Jonathan R.

Philipp Hoschka wrote:
> 
> Jonathan,
> could you review Henrik's http extensions proposal ?
> ftp://ftp.ietf.org/internet-drafts/draft-frystyk-http-extensions-01.txt
> 
> and send your review to
> discuss@apps.ietf.org
> 
> This is a prerequisite to move this to Proposed Standard level
> at the IETF.
> 
> Your review would be greatly appreciated
> 
> Happy Holidays
> 
> -Philipp

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

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.

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?

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?

5. The spec says unrecognized decl-ext parameters SHOULD be
ignored. What else can it do? Shouldn't this be a MUST?

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.

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"

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.

9. THe appendices start numbering at 14, essentially as continuations
of section numbers. They should probably start over at 1 or A.

10. (See section 4.1 and 4.2, and appendix 14
for a table of interactions with origin servers and proxies.)

This is gramatically incorrect. Should be:

(See sections 4.1 and 4.2; also see appendix 14 which has a table
of....)

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.

12. "The ultimate recipient of a mandatory end-to-end extension declaration

MUST handle that extension declaration as described in section 5 and
6."

Extra carriage return in the middle of the sentence.

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. Also, MUST the header fields
declared in the extension also be protected by a COnnection header?

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.

15. "The Ext and the C-Ext header fields are not mutually exclusive, they can
both occur within the same message as described in section 5.1."

The comma should be a semicolon.

16. Why does the method name need to be prefixed with an M? Is this
for compatibility with HTTP implementations which don't understand
this extension mechanism?

17. "It is strongly recommended that the integrity and persistence of the
extension identifier be maintained and kept unquestioned"

RECOMMENDED

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.

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:

GET <address>
Man: ext1, ext2, ext3

510 Not Extended
Unsupported: ext1, ext3

This would allow a client to reformulate the request without the
extension, if possible. Besides this, the draft seems to be a
reasonably complete solution for extensions.

Received on Wednesday, 6 January 1999 02:12:25 UTC