From: email@example.com (Koen Holtman) Message-Id: <199803261901.UAA06003@wsintt15.win.tue.nl> To: firstname.lastname@example.org (Dave Kristol) Date: Thu, 26 Mar 1998 20:01:34 +0100 (MET) Cc: email@example.com, firstname.lastname@example.org Subject: Re: comments on draft-ietf-http-ext-mandatory-00.txt Here are my comments on draft-ietf-http-ext-mandatory-00. I apologise if this duplicates anything, I lost some mail in a system crash. In general, I think that the draft is very clear, and nicely delineates its scope. One exception to this is the `passed to upper layers' thing in section 3 which Dave already noted: this seems to be a requirement on the internals of an agent, and I do not know what to make of it exactly anyway. Specific comments: - Section 3: `Relative extension identifiers are interpreted relative to the IANA registry (see RFC 1808).' I can't find in 1808 how to `interpreted relative to the IANA registry', and in general I am at a loss as to what you mean here. Could you give an example? - 3.1 Header Field Prefixes BNF problem: what is called `header-Prefix' here was simply called `prefix' earlier. - also in 3.1: `Agents SHOULD 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).' The parenthetical remark is a bit strange (why is that discussion relevant to that rule?), but the rule itself is clear. However, I realised yesterday that this rule alone will not prevent all possible clashes of header-prefix values. A case where it can still go wrong: 1. suppose a 1.x proxy cache (which is not aware of the mandatory spec) has cached a response with the headers opt: "blex"; ns=123 123-p: t in it 2. suppose the cache is caused to to revalidate this response: it sends a conditional request towards the origin server 3. the response is still fresh so the origin server sends a 304 4. some intermediate party tacks an extension onto the 304 response, adding the headers opt: "zoiks"; ns=123 123-q: f 5. on receipt, the proxy follows this part of the 1.1 spec: # If a cache uses a received 304 response to update a cache entry, the # cache MUST update the entry to reflect any new field values given in # the response. to the headers in the updated response are, I guess: opt: "zoiks"; ns=123 123-p: t 123-q: f 6. the zoiks extension in the ultimate recipient of the response may proceed to do the wrong thing on seeing `123-p: t' I guess this problem can be fixed by forbidding the use of header prefixes in 304 responses. This should not be too big a loss I think. Overall however (and I have said this before), I think the whole dynamic header allocation stuff is just useless cruft which should be removed rather than fixed. It is both easier to code and more efficient to use ext-extensions if one needs to convey extension parameters. - section 5: `...by performing the following actions in the order they occur:' I think you mean `in the order they are listed below'. - 7. 510 Not Extended It is not immediately clear from context that this section defines a status code. Also: `The server SHOULD send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.' Either delete this SHOULD or specify the information sending mechanism. Also: `If the initial request already included the extensions requested in the 510 response, then the response indicates that access has been refused for those extension declarations.' I think you should allocate a separate status code for this case, or define some header which allows the recipient to distinguish between the two cases. [Note: I did not proofread the non-normative appendices carefully] Koen.