Re: Mohamed Boucadair's No Objection on draft-ietf-httpbis-cache-groups-05: (with COMMENT)

Hi Med,

Responses below.

> On 24 Apr 2025, at 3:16 pm, mohamed.boucadair@orange.com wrote:

[...]
>>> # Same origin
>>> 
>>> CURRENT:
>>>  These mechanisms operate within a single cache, across the
>> stored
>>>  responses associated with a single origin server .
>>> 
>>> Do we need to say how that "single origin server" is identified?
>> 
>> This is formally specified under "Identifying Grouped Responses".
> 
> [Med] Can we add a pointer to that sections? Thanks.

I've added a forward pointer.

>>> Also, shouldn’t the validation be based on RFC8941 to avoid
>> redundant
>>> behaviors? That is, do we need this MUST?
>> 
>> Structured Fields discourages specifications from disallowing
>> Parameters, but does not preclude it (see Section 2.2).
>> 
> 
> [Med] The text that actually triggered my comment is this part of 8914:
> 
> " Recipients MUST ignore members whose keys that are
>   undefined or unknown, unless the field's specification specifically
>   disallows them. "
> 
> As we don't have exception here, that base behavior suffice. The extra MUST seems redundant to me.

Fair enough - I've softened to "Unrecognised Parameters are to be ignored."

>> In general we avoid documenting rationale for choices in
>> specifications, as that would greatly expand their size and make
>> them less useable to implementers.
> 
> [Med] I hear that but having an appendix that records the rationale would be helpful.

Thinking about other HTTP and QUIC specifications I've been involved in, I can't recall another case where we explained the rationale for a value in-specification, especially when it's a floor for interoperability like this. 

>>> Can this be configurable? How one can retrieve what is supported
>> by a given implementation?
>> 
>> No, and you can't. The point here is to support a floor for
>> interoperability.
> 
> [Med] My comment may not be clear, but I was asking how an admin/owner of the server can access this information for local management purposes.

Ah. I suspect that's entirely implementation dependant, isn't it?

>>> # Interaction with proxies
>>> 
>>> How this mechanism interacts with proxies? Are those allowed to
>>> inject/alter what is set by a server?
>>> 
>>> May be adding a reference where such «generic» matters are
>> covered
>>> would be useful here.
>> 
>> It depends on the deployment of the proxy; if it's acting on behalf
>> of the origin server or user, this is reasonable.
>> 
>> This is a subtle issue that's out of the scope of this
>> specification; it's not specified explicitly anywhere, but is
>> widely understood in HTTP.
> 
> [Med] Can we have a short mention that basically echoes what you clarified?

The IETF has defined many dozens of HTTP header fields without going into this detail. I don't see a compelling reason to start now. If we want to go into this it should be considered as a standalone update to HTTP, not a one-off.

>>> # Management
>>> 
>>> CURRENT:
>>>  (sometimes referred to as "shared hosting") might allow one
>> party to
>>>  group its resources with those of others, or to send signals
>> which
>>>  have side effects upon them.
>>> 
>>> How that is managed by a "party" in practice? Is it a
>> configuration action?
>> 
>> The next paragraph explains how:
>> 
>>> Shared hosts that wish to mitigate these risks can control access
>> to the header fields defined in this specification.
>> 
> 
> [Med] Thanks, but not sure this is related to the "party" mentioned in that excerpt.

It is related -- the shared host (which the parties are using) is responsible for assuring that abuse of the mechanism doesn't take place.

>>> # Cascaded effect
>>> 
>>> If we have an entry that belongs to A/B, another that belongs to
>> B/C,
>>> and a third to C/D. If A group is invalidated, this will impact
>> the
>>> second entry per the rules in 2.2.1. However, does this impact
>> the
>>> third one as well is it shares a group with the second
>> invalidated one?
>> 
>> This is an interesting question. It's reasonable to assume that
>> *any* invalidation (including that triggered by a group
>> invalidation) is eligible, but some implementers may reasonable
>> wish to avoid allowing such a 'cascade' for efficiency reasons.
>> 
>> I tend to think that we should explicitly specify that an
>> invalidation triggered by a group invalidation does NOT trigger
>> group invalidations itself; i.e., there is no "cascading."
> 
> [Med] Please record whatever outcome for the cascading in the document. We need to be explicit on this. Thanks.

Will do.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 25 April 2025 03:14:02 UTC