* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #54 (closed design: fixed)

Opened 7 years ago

Last modified 5 years ago

Definition of 1xx Warn-Codes

Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: 08
Component: p6-cache Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/86EDC3963F04D546BED8996F77D290F6049D117A9F@NA-EXMSG-C138.redmond.corp.microsoft.com

Description

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.
  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.
  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).

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

Proposal:

  1. pick one, and use it everywhere. I'm partial to 1xx myself :).
  2. "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. 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.

comment:2 Changed 7 years ago by mnot@pobox.com

  • Component set to cache
  • Milestone set to unassigned

comment:3 Changed 5 years ago by mnot@pobox.com

(1) and (2) addressed in p6-06;

o 1xx Warnings that describe the freshness or validation status of

the response, and so MUST be deleted by caches after validation. They MUST NOT be generated by a cache except when validating a cached entry, and MUST NOT be generated by clients.

comment:4 Changed 5 years ago by mnot@pobox.com

  • Priority set to normal
  • Severity set to Active WG Document
  • Milestone changed from unassigned to 08

Proposal:

They can only be generated by a cache that is validated a stored entry, and MUST NOT be generated in any other situation.

It's also probably worth putting in a reference to this from 2.4 Validation Model.

comment:5 Changed 5 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to fixed

Changeset [709] closes.

Note: See TracTickets for help on using tickets.