RE: Mohamed Boucadair's Discuss on draft-ietf-httpbis-safe-method-w-body-13: (with DISCUSS and COMMENT)

Re-,

Looks good to me. Thanks.

Will clear once the new version is out.

Cheers,
Med

> -----Message d'origine-----
> De : Julian Reschke <julian.reschke@greenbytes.de>
> Envoyé : mardi 18 novembre 2025 10:28
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> Julian Reschke <julian.reschke@greenbytes.de>; The IESG
> <iesg@ietf.org>
> Cc : draft-ietf-httpbis-safe-method-w-body@ietf.org; httpbis-
> chairs@ietf.org; ietf-http-wg@w3.org; mnot@mnot.net
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-httpbis-
> safe-method-w-body-13: (with DISCUSS and COMMENT)
> 
> 
> Am 18.11.2025 um 07:58 schrieb mohamed.boucadair@orange.com:
> > Hi Julian,
> >
> > Thank you for the follow-up.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> 
> Thanks.
> 
> >> -----Message d'origine-----
> >> De : Julian Reschke <julian.reschke@greenbytes.de> Envoyé :
> lundi 17
> >> novembre 2025 18:19 À : BOUCADAIR Mohamed INNOV/NET
> >> <mohamed.boucadair@orange.com>; The IESG <iesg@ietf.org> Cc :
> >> draft-ietf-httpbis-safe-method-w-body@ietf.org; httpbis-
> >> chairs@ietf.org; ietf-http-wg@w3.org; mnot@mnot.net Objet : Re:
> >> Mohamed Boucadair's Discuss on draft-ietf-httpbis-
> >> safe-method-w-body-13: (with DISCUSS and COMMENT)
> >>
> >> Hi Mohamed,
> >>
> >> thanks for the review. I believe we can get these
> questions/issues
> >> resolved quickly.
> >>
> >> I have opened a few tickets that I can work on (URIs added
> inline).
> >> For the other points, I'll comment in this mail for now.
> >>
> >> Am 17.11.2025 um 10:29 schrieb Mohamed Boucadair via
> Datatracker:
> >>> Mohamed Boucadair has entered the following ballot position
> for
> >>> draft-ietf-httpbis-safe-method-w-body-13: Discuss
> >>>
> >>> 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.)
> >>> --------------------------------------------------------------
> --
> >>> DISCUSS:
> >>> --------------------------------------------------------------
> --
> >>>
> >>> Hi Julian, James, and Mike,
> >>>
> >>> Thank you for the effort put into this specification. Great to
> >> see
> >>> this feature progressing in the standardization process. I'm
> >> always
> >>> impressed by the perseverance and sustained effort required to
> >> push an extension over a decade.
> >>> Also, interesting to see that a similar feature was
> standardized
> >> in
> >>> CoAP (FETCH
> >>> method) since 2017.
> >>>
> >>> The document is well-written with the design motivation and
> >> approach
> >>> well-articulated.
> >>>
> >>> Thanks to Mark for clarifying the language use for code
> errors.
> >>>
> >>> # URI
> >>>
> >>> Section 2.4 says:
> >>>      A server can assign a URI to the equivalent resource
> >> (Section 2.2) of
> >>>      a QUERY request.
> >>>
> >>> Section 4:
> >>>      If a server creates a temporary resource to represent the
> >> results of
> >>>      a QUERY request (e.g., for use in the Location or
> Content-
> >> Location
> >>>      field) and the request contains sensitive information
> that
> >> cannot be
> >>>      logged, then the URI of this resource SHOULD be chosen
> such
> >> that it
> >>>      does not include any sensitive portions of the original
> >> request
> >>>      content.
> >>>
> >>> ## Unless I'm missing something, the second except assumes
> that
> >> a URI
> >>> is always assigned which seems to contradict the text in 2.4.
> >>
> >> - yes, that's a good catch.
> >
> > [Med] ACK
> 
> Fixed with
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fgithub.com%2Fhttpwg%2Fhttp-
> extensions%2Fpull%2F3334&data=05%7C02%7Cmohamed.boucadair%40orange
> .com%7C4c5b5e6cd9774797f2ea08de2684e644%7C90c7a20af34b40bfbc48b925
> 3b6f5d20%7C0%7C0%7C638990549451783947%7CUnknown%7CTWFpbGZsb3d8eyJF
> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UWvm724%2FVBDsHfOWrZgsgx
> %2F0ppZ%2F%2BafvowT43CSRjt0%3D&reserved=0>.
> 
> 
> >>> ## Please move [URI] to be listed as normative.
> >> - one could argue that all
> >> uses of "URI" are sufficiently specified indirectly through
> HTTP, but
> >> I agree this is much clearer.
> >
> > [Med] Thanks
> 
> Fixed in
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fgithub.com%2Fhttpwg%2Fhttp-
> extensions%2Fcommit%2F67ab0ccb8969e6657c2f2610dc746d569075f2a6&dat
> a=05%7C02%7Cmohamed.boucadair%40orange.com%7C4c5b5e6cd9774797f2ea0
> 8de2684e644%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638990549
> 451808645%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> C%7C%7C&sdata=Zbu3W%2FZftgBFi6fMmgBc1CVdquyXPwjFaEbMzyNlazY%3D&res
> erved=0>
> (no PR).
> 
> (I believe these two changes address all DISCUSSes)
> 
> >>> --------------------------------------------------------------
> --
> >>> COMMENT:
> >>> --------------------------------------------------------------
> --
> >>>
> >>> # Please consider adding some few words about how QUERY
> differs
> >> from
> >>> the SEARCH method (RFC5323).
> >>
> >> That would be an appendix; possibly a bit lenghty. From my POV,
> the
> >> answer really is: it really doesn't differ that much. We could
> have
> >> updated/replaced SEARCH as well (an that's how this spec
> started).
> >> It's just that many perceive "SEARCH" as that ancient WebDAV
> thing,
> >> so there was some pressure to use something new.
> >>
> >> Not sure that this would be a sufficient explanation :-)
> >
> > [Med] Converting this into words that fits an RFC would suffice
> for me
> > ;-)
> 
> Reluctantly opened
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fgithub.com%2Fhttpwg%2Fhttp-
> extensions%2Fissues%2F3337&data=05%7C02%7Cmohamed.boucadair%40oran
> ge.com%7C4c5b5e6cd9774797f2ea08de2684e644%7C90c7a20af34b40bfbc48b9
> 253b6f5d20%7C0%7C0%7C638990549451827225%7CUnknown%7CTWFpbGZsb3d8ey
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=a7NlKCGfjK8apqsDJL9t46
> Bqk%2Fd9i3wyGiuOuRcyN34%3D&reserved=0>.
> 
> >> FWIW, the same question could be asked about PROPFIND and
> REPORT
> >> which share the same properties (safe and with request
> content).
> >
> > [Med] Thanks. Up to you if you want to mention those in an note
> as well.
> >
> >>
> >>> # Caching/Server Operational considerations
> >>
> >> (maybe our caching expert want's to comment as well, hint
> hint).
> >> I'll do my best to answer those:
> >>
> >>> ## The specification clearly indicates that caching
> >> considerations are
> >>> more complex compared to other methods. However, it seems to
> me
> >> that
> >>> some proposed optimizations require content format awareness
> by
> >> cache
> >>> elements and thus
> >>
> >> That's what we already say in the list of potential
> optimizations.
> >>
> >>> imposes some deployment constraints. There might be
> implications
> >> on
> >>> the dimensioning of the cache and server infrastructures. It
> >> would be
> >>> useful to record such matters in a dedicated "Operational
> >>> Considerations" section. If
> >>
> >> "The cache key for a QUERY request (see Section 2 of [HTTP-
> >> CACHING]) MUST incorporate the request content (Section 6 of
> >> [HTTP-CACHING]) and related metadata (Section 8 of [HTTP-
> CACHING])."
> >>
> >> Also, at the end of 2.8: "Note that caching QUERY method
> responses is
> >> inherently more complex than caching responses to GET, as
> complete
> >> reading of the request's content is needed in order to
> determine the
> >> cache key."
> >
> > [Med] Agree this covers the point somehow. I was looking for a
> flavor with a deployment focus.
> >
> >>
> >>> there are readily-available studies on these matters, these
> >> would be
> >>> useful to cite as informative references.
> >>
> >> I'm not aware of this kind of studies. Mark?
> >>
> >>> ## The caching efficiency may also depend on the order used in
> >> the
> >>> parameters enclosed in the QUERY payload. I think the text
> >> should at
> >>> least recommend that, independent of the format type, the same
> >> order
> >>> is preserved by a client when it re-does the same query?
> >>
> >> Yes, for a subsequent request (with the same semantics) it's
> wise not
> >> to change the content. But that's not specific to QUERY.
> >
> > [Med] Can we then say it explicitly?
> 
> I'm reluctant to state things that are evident and not different
> from RFC 9110 (GET).
> 
> >>> ## Maybe worth calling out that complicated query payloads may
> >> consume
> >>> more server resources. Policies/configuration are expected to
> be
> >>> provided to servers to control allowed operations to prevent
> >> operational effects of random queries.
> >>
> >> Again, this doesn't seem to be different from, for instance,
> POST.
> >
> > [Med] I failed to find where similar concern was discussed for
> POST. I think this is worth calling out.
> 
> See above.
> 
> > ...
> 
> >>> ## Applicability of POST exceptions
> >>>
> >>> Given that we indicate the non-applicability for redirect
> >> matters vs.
> >>> POST in, e.g.,
> >>>
> >>> CURRENT:
> >>>      Note that the exceptions for redirecting a POST as a GET
> >> request
> >>>      after a 301 or 302 response do not apply to QUERY
> requests.
> >>>
> >>> and that RFC9110 says:
> >>>      appropriate status code depending on the result of
> >> processing the
> >>>      POST request; almost all of the status codes defined by
> this
> >>>      specification could be received in a response to POST
> (the
> >> exceptions
> >>>      being 206 (Partial Content), 304 (Not Modified), and 416
> >> (Range Not
> >>>      Satisfiable)).
> >>>
> >>> I wonder whether we can call out restriction or lack of
> >> restriction
> >>> with regards to the applicability of error codes for QUERY.
> >>
> >> I believe that's exactly what we do in that sentence.
> >
> > [Med] That sentence was for redirect, not other codes in the
> 9110 excerpt.
>  > ...
> 
> Aha. The exceptions listed over there do not apply to QUERY (two
> are specific to the lack of range request support, the other one
> specific to a non-safe method (in which indeed the response code
> could be 304).
> 
> As such, I don't think there's anything to say here.
> 
> >>> # Future request
> >>>
> >>> CURRENT (2.4):
> >>>
> >>>      This resource's
> >>>      URI might be temporary; if a future request fails, the
> >> client can
> >>>      retry using the original QUERY request target and the
> >> previously
> >>>      submitted content.
> >>>
> >>> Do we mean future request with that URI as request URI? Please
> >> update
> >>> the text for better clarity.
> >>
> >> Yes.
> >
> > [Med] I trust this will be reworded.
> 
> "if a future request fails, the client can retry using the
> original QUERY request target and the previously submitted
> content."
> 
> That's what it says, no? The request target *is* the URI used in
> the original QUERY.
> 
> >>> # nits
> >>>
> >>> ## Abstract: these are distinct properties
> >>>
> >>> OLD: safe/idempotent manner
> >>>
> >>> NEW: safe and idempotent manner
> >>
> >> Yes.
> > [Med] ACK.
> 
> Will be done in
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fgithub.com%2Fhttpwg%2Fhttp-
> extensions%2Fpull%2F3336&data=05%7C02%7Cmohamed.boucadair%40orange
> .com%7C4c5b5e6cd9774797f2ea08de2684e644%7C90c7a20af34b40bfbc48b925
> 3b6f5d20%7C0%7C0%7C638990549451844889%7CUnknown%7CTWFpbGZsb3d8eyJF
> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=An%2FbetAj2G5uiulbt2rEay
> soSxPzFMGxvZrn9dqp0hM%3D&reserved=0>.
> 
> >>> ## Introduction: too voluminous
> >>>
> >>> I think the flow of this part can be made better by avoid
> >> redundant statement.
> >>> For example:
> >>>
> >>> OLD:
> >>>      Most often, this is desirable when the data conveyed in a
> >> request is
> >>>      too voluminous to be encoded into the request's URI.  A
> >> common query
> >>>      pattern is:
> >>>
> >>>      GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
> >>>      Host: example.org
> >>>
> >>>      However, when the data conveyed is too voluminous to be
> >> encoded in
> >>>      the request's URI, this pattern becomes problematic:
> >>>
> >>> NEW:
> >>>      A common query pattern with a GET method is:
> >>>
> >>>      GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
> >>>      Host: example.org
> >>>
> >>>      However, when the data conveyed is too voluminous to be
> >> encoded in
> >>>      the request's URI, this pattern becomes problematic:
> >>
> >> Yes.
> >
> > [Med] Thanks.
> 
> In
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fgithub.com%2Fhttpwg%2Fhttp-
> extensions%2Fpull%2F3336&data=05%7C02%7Cmohamed.boucadair%40orange
> .com%7C4c5b5e6cd9774797f2ea08de2684e644%7C90c7a20af34b40bfbc48b925
> 3b6f5d20%7C0%7C0%7C638990549451861266%7CUnknown%7CTWFpbGZsb3d8eyJF
> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BHKG4mc5YrqIKaGYTo5Mb9mN
> %2B7BbrwXCosGUylkKoJU%3D&reserved=0>.
> 
> In general, the verbosity of the spec mostly is a matter of taste.
> There are always reviewers asking for more, and others asking for
> less.
> 
> >> (summary ticket for nits:
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >> github.com%2Fhttpwg%2Fhttp-
> >>
> extensions%2Fissues%2F3333&data=05%7C02%7Cmohamed.boucadair%40oran
> >>
> ge.com%7C1905897227ca40fd79d808de25fd7b20%7C90c7a20af34b40bfbc48b9
> >>
> 253b6f5d20%7C0%7C0%7C638989967778431586%7CUnknown%7CTWFpbGZsb3d8ey
> >>
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> >>
> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CFtvnV3epxfvBUPTVP4qQT
> >> wxJ4JTFcpds2AmSv5J58Y%3D&reserved=0)
> >>
> >> Best regards and thanks for the feecback,
> >>
> >> Julian
> 
> With that, and the pending change for
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fgithub.com%2Fhttpwg%2Fhttp-
> extensions%2Fissues%2F3337&data=05%7C02%7Cmohamed.boucadair%40oran
> ge.com%7C4c5b5e6cd9774797f2ea08de2684e644%7C90c7a20af34b40bfbc48b9
> 253b6f5d20%7C0%7C0%7C638990549451881927%7CUnknown%7CTWFpbGZsb3d8ey
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=X5rtDXJxAiG8ZZW3UUDGpX
> SBJNv7A4y3W%2Bm7wCtSArw%3D&reserved=0> (which I'll work on next) I
> believe we're done.
> 
> Best regards, Julian
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
> Amtsgericht Münster: HRB5782

____________________________________________________________________________________________________________
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 Tuesday, 18 November 2025 10:15:58 UTC