NEW ISSUE: 13.1.2's Definition of 1xx Warn-Codes

(Supporting references at the end of the message)

The offending part of section 13.1.2 (Warnings, page 77) reads:

   [...]

   1xx  Warnings that describe the freshness or revalidation status of
     the response, and so MUST be deleted after a successful
     revalidation. 1XX [sic] warn-codes MAY be generated by a cache only
     when validating a cached entry. It MUST NOT be generated by clients.

   [...]


The problems, in order from simplest to the most complex:

1. 1XX should be 1xx (or vice-versa) everywhere.

Proposed fix: pick one, and use it everywhere. I'm partial to 1xx myself :).


2. The use of MAY in the offending part of 13.1.2 conflicts with the MUST
   requirements in section 14.46 and the definition of MAY in BCP14.

Proposed fix: "1xx warn-codes MUST NOT be added to any messages except cache
entries, and MUST NOT be added to cache entries except in response to a
validation attempt." (As a side note, a definition of a cache entry would be
nice.)


3. One would think that proxies could include caches (though I have yet to
   find where this is permitted with a true BCP14 MAY). However, the wording
   in the offending part of 13.1.2 makes it impossible to satisfy the
   requirements of a cache and the requirements of a client (and, by
   extension, proxy) simultaneously. A cache is not an independent program;
   it is part of a program (as per the 1.3 definition). A client is a
   program, and it can contain a cache (again, from 1.3), but this limits
   the cache's behavior to the set intersection of allowed behaviors for
   caches and clients (due to how "client" is defined). This leads to a
   conflict where the cache MUST generate a 1xx code, but a client MUST NOT
   generate a 1xx code. Thus, we're left having to conclude that caches can
   exist only as part of independent servers (which have their content
   pushed to them, or delivered through some out-of-band method).

Proposed fix: Maybe "Clients that do not incorporate a cache MUST NOT
generate 1xx warn-codes", but I'm not sure what problem the original clause
was trying to prevent. The proposed fix in (2) above might cover everything, allowing the deletion of this sentence altogether.


-- Travis

--- Supporting References ---

Section 14.46 (Warning, page 149) reads:

   [...]

   110 Response is stale
     MUST be included whenever the returned response is stale.

   111 Revalidation failed
     MUST be included if a cache returns a stale response because an
     attempt to revalidate the response failed, due to an inability to
     reach the server.

   [...]

   113 Heuristic expiration
     MUST be included if the cache heuristically chose a freshness
     lifetime greater than 24 hours and the response's age is greater
     than 24 hours.

   [...]

Some definitions from section 1.3 (Terminology, pages 9-10):

   [...]

   client
      A program that establishes connections for the purpose of sending
      requests.

   [...]

   proxy
      An intermediary program which acts as both a server and a client
      for the purpose of making requests on behalf of other clients. [...]
      A proxy MUST implement both the client and server requirements of this
      specification. [...]

   cache
      A program's local store of response messages and the subsystem
      that controls its message storage, retrieval, and deletion. A
      cache stores cacheable responses in order to reduce the response
      time and network bandwidth consumption on future, equivalent
      requests. Any client or server may include a cache, though a cache
      cannot be used by a server that is acting as a tunnel.

   [...]

Received on Friday, 22 December 2006 21:54:41 UTC