Re: comments on draft-ietf-http-ext-mandatory-00.txt

From: Koen Holtman (koen@win.tue.nl)
Date: Thu, Mar 26 1998


From: koen@win.tue.nl (Koen Holtman)
Message-Id: <199803261901.UAA06003@wsintt15.win.tue.nl>
To: dmk@research.bell-labs.com (Dave Kristol)
Date: Thu, 26 Mar 1998 20:01:34 +0100 (MET)
Cc: frystyk@w3.org, ietf-http-ext@w3.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[4]).'

  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.