Ticket #54 (closed design: fixed)
Definition of 1xx Warn-Codes
|Reported by:||email@example.com||Owned by:|
|Component:||p6-cache||Severity:||Active WG Document|
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:
- 1XX should be 1xx (or vice-versa) everywhere.
- 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.
- 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).
- Priority set to normal
- Severity set to Active WG Document
- Milestone changed from unassigned to 08