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, 06 Jan 1999 02:09:32 -0500
Message-ID: <36930C2C.AB6C4632@dnrc.bell-labs.com>
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
CC: jdrosen@bell-labs.com, henrik@w3.org, discuss@apps.ietf.org
>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
>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
>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
>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
>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"
>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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:05 UTC