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

Hi Mark, 

It seems that we converged on the main points. 

Looking forward seeing the outcome implemented in -06. Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : Mark Nottingham <mnot@mnot.net>
> Envoyé : vendredi 25 avril 2025 05:14
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> Cc : The IESG <iesg@ietf.org>; ietf-http-wg@w3.org;
> tpauly@apple.com
> Objet : 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw

> ww.mnot.net%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C0494
> 8cead43d4e6d0beb08dd83a73b39%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C638811476465108385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> fQ%3D%3D%7C0%7C%7C%7C&sdata=A4Y7jvhYFT1pn2l0CanDBWDvSN2Hr2Z4dPmNkPV
> HBZc%3D&reserved=0

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Received on Thursday, 22 May 2025 07:10:07 UTC