Benjamin Kaduk's No Objection on draft-ietf-httpbis-cache-16: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-httpbis-cache-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I made a PR with some editorial suggestions at
https://github.com/httpwg/http-core/pull/874 .

Section 1.3

   negative integer range.  If a cache receives a delta-seconds value
   greater than the greatest integer it can represent, or if any of its
   subsequent calculations overflows, the cache MUST consider the value
   to be 2147483648 (2^31) or the greatest positive integer it can
   conveniently represent.

Is that a free choice, MIN, or MAX?

Section 3.1

   Caches MAY either store trailer fields separate from header fields,
   or discard them.  Caches MUST NOT combine trailer fields with header
   fields.

IIRC, recipients are allowed to merge trailer fields into header fields
in some situations (e.g., if explicitly allowed by the field
definition).  I'm not entirely sure how that allowance is intended to
interact with this directive (perhaps that generic-recipient merging has
already occurred before this point?).

Section 4

   A cache that does not have a clock available MUST NOT use stored
   responses without revalidating them upon every use.

(Are we using the same qualifications for what counts as a clock as
specified in §10.2.2 of -semantics?)

Section 5.2.2.2

   The "must-revalidate" response directive indicates that once the
   response has become stale, a cache MUST NOT reuse that response to
   satisfy another request until it has been successfully validated by
   the origin, as defined by Section 4.3.
[...]
   The must-revalidate directive also permits a shared cache to reuse a
   response to a request containing an Authorization header field
   (Section 11.6.2 of [Semantics]), subject to the above requirement on
   revalidation (Section 3.5).

It seems like the combination of these two behaviors would allow a
shared cache to reuse a response to a request containing an
Authorization header field without revalidation, provided it does so
before the response has become stale.  That seems surprising to me,
though it's hard to pin down exactly why.

NITS

Section 4.2.3

   A response's age can be calculated in two entirely independent ways:

Just to confirm: this is something that could be said to be the
"intrinsic age" or "initial age" of the response, corresponding to the
age at the time it was generated/received, as distinct from the age at
the time of the calculation?  I wonder if adding an adjective would help
clarify that.

Appendix B

   The "public" and "private" cache directives were clarified, so that
   they do not make responses reusable under any condition.
   (Section 5.2.2)

I'm having a hard time figuring out what change this refers to.