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

Hi Mark,

Thank you for the follow-up. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>
> Envoyé : dimanche 20 avril 2025 10:40
> À : 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 Mohammed,
> 
> Thank you for the feedback. Responses below; note that I generally
> incorporate typographical, grammar, and word choice changes at the
> RFC Editor stage, as they are authoritative on those matters.
> 

[Med] ACK

> 
> > On 18 Apr 2025, at 10:44 pm, Mohamed Boucadair via Datatracker
> <noreply@ietf.org> 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.

> 
> > # Mention the section where to look at
> >
> > CURRENT:
> >   The Cache-Groups HTTP Response Header is a List of Strings
> >   [STRUCTURED-FIELDS].
> >
> > and
> >
> > CURRENT:
> >   The Cache-Group-Invalidation response header field is a List of
> >   Strings [STRUCTURED-FIELDS].
> >
> > Please add a reference to the exact section to look at.
> >
> > As we don’t have a clear reference, I don't know whether we allow
> empty values?
> > Same value repeated several times? upper case, etc.
> 
> Done.

[Med] Thanks.

> 
> > # Parameters
> >
> > CURRENT:
> >   The ordering of members is not significant.  Unrecognised
> Parameters
> >   MUST be ignored.
> >
> > Which parameters?
> 
> 'Parameter' is a defined term in Structured Fields.

[Med] ACK.

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

> > # Lack of reasoning
> >
> > CURRENT:
> >   Implementations MUST support at least 32 groups in a field
> value ,
> >   with up to at least 32 characters in each member.  Note that
> generic
> >   limitations on HTTP field lengths may constrain the size of
> this
> >   field value in practice.
> >
> > and
> >
> > CURRENT:
> >   Implementations MUST support at least 32 groups in a field
> value,
> >   with up to at least 32 characters in each member.  Note that
> generic
> >   limitations on HTTP field lengths may constrain the size of
> this
> >   field value in practice.
> >
> > What is the rationale for picking these values?
> 
> See discussion starting at:
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl

> ists.w3.org%2FArchives%2FPublic%2Fietf-http-
> wg%2F2025JanMar%2F0206.html&data=05%7C02%7Cmohamed.boucadair%40oran
> ge.com%7C72db86b0a0f0440d3d7908dd7fe6ec85%7C90c7a20af34b40bfbc48b92
> 53b6f5d20%7C0%7C0%7C638807351976574850%7CUnknown%7CTWFpbGZsb3d8eyJF
> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2lHJttpcOvIrQhDlZhxZaJOe4m
> A0H4YFHSya%2BAo4izE%3D&reserved=0
> 

[Med] Thanks for the pointer.

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

> 
> > What is currently supported by existing implementations?
> 
> Implementations are just emerging, but previous practice was to
> support many more (as discussed in the thread linked above).

[Med] Thanks.

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

> 
> > # Comparison logic
> >
> > CURRENT:
> >   1.  They both contain a Cache-Groups response header field that
> >       contains the same String (in any position in the List),
> when
> >       compared character-by-character .
> >
> > Is the comparison case-sensitive? Or do we rely on rfc8941 for
> these
> > matters, e.g., to prevent upper case to be used in a list item?
> 
> Changed to explicitly specify case sensitivity.

[Med] Thanks.

> 
> > # Reasoning again
> >
> > CURRENT:
> >   A cache that receives a Cache-Group-Invalidation header field
> on a
> >   response to an unsafe request MAY invalidate any stored
> responses
> >   that share groups (per Section 2.1) with any of the listed
> groups.
> >
> > What is the rationale for the MAY here?
> 
> We can't place new MUST-level requirements on caches, of which
> there is an unknowable number of deployments existent. This is an
> optional extension, not something that you can rely upon.

[Med] Fair.

> 
> > # 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?

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

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

> What do others think?
> 
> 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%7C72db
> 86b0a0f0440d3d7908dd7fe6ec85%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C638807351976587867%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> fQ%3D%3D%7C0%7C%7C%7C&sdata=Pej7ONhhJRXrQhpbVuziKJbR%2BVOSWZPNLolUn
> KWZuTI%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