The HTTP QUERY Method
draft-ietf-httpbis-safe-method-w-body-14

[Ballot comment]
Thanks for the work done in this document, it is easy to read and could be useful indeed.

Probably because I am far from being an HTTP expert, I fail to spot the expected behaviour of a server that receives a non-idempotent QUERY ? (i.e., the client MUST use a POST and not a QUERY)

-éric

[Ballot comment]
Hi Julian, James, and Mike,

The changes made in -14 [1] look good.

Thank you for the discussion and for taking care of the previous review [2].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-httpbis-safe-method-w-body-14

[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2025OctDec/0185.html

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

## Please move [URI] to be listed as normative.

[Ballot comment]
# Please consider adding some few words about how QUERY differs from the SEARCH method (RFC5323).

# Caching/Server Operational considerations

## 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 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 there are readily-available studies on these matters, these would be useful to cite as informative references.

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

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

# Private agreements

RFC9110 has the following for GET:

  An origin server SHOULD
  NOT rely on private agreements to receive content, since participants
  in HTTP communication are often unaware of intermediaries along the
  request chain.

Would that caution be needed for QUERY?

# Error Codes

## Content Negotiation (2.1)

What if the query instructions are not valid?

Can the text cite, for example, 422 (Unprocessable Content) and 413 (Content Too Large) as they seem to be relevant for QUERY?

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

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

# nits

## Abstract: these are distinct properties

OLD: safe/idempotent manner

NEW: safe and idempotent manner

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

Cheers,
Med

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

Please find below few DISCUSS points:

# Unlike 9110 which uses a clear language about the expected error codes, the specification is ambiguous (for some aspects) for a PS document. The document uses “can” in many places while I think a better clarity is needed. For example,

CURRENT:
  *  If a media type is specified, but is inconsistent with the actual
      request content, a 400 (Bad Request) can be returned.  That is, a
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      server is not allowed to infer a media type from the request
      content and then override a missing or "erroneous" value ("content
      sniffing").

  *  If the media type is specified, is understood, and the content is
      indeed consistent with the type, but the query cannot be processed
      due to the actual contents of the query, the status 422
      (Unprocessable Content) can be used.  An example would be a
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      syntactically correct SQL query that identifies a non-existent
      table.

Or

  A server can assign a URI to the equivalent resource (Section 2.2) of
            ^^^^^^^^^^^^
  a QUERY request.  If the server does so, the URI of that resource can
                                                                    ^^^
  be included in the Location header field of the 2xx response (see
  ^^
  Section 10.2.2 of [HTTP]).

Any reason why a less ambiguous language (e.g., normative language) is not used here (and other similar parts of the spec)?

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

## Please move [URI] to be listed as normative.

[Ballot comment]
# Please consider adding some few words about how QUERY differs from the SEARCH method (RFC5323).

# Caching/Server Operational considerations

## 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 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 there are readily-available studies on these matters, these would be useful to cite as informative references.

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

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

# Error Codes

## Content Negotiation (2.1)

What if the query instructions are not valid?

Can the text cite, for example, Can 422 (Unprocessable Content) and 413 (Content Too Large) as they seem to be relevant for QUERY?

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

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

# nits

## Abstract: these are distinct properties

OLD: safe/idempotent manner

NEW: safe and idempotent manner

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

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-httpbis-safe-method-w-body-12. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Hypertext Transfer Protocol (HTTP) Method Registry located at:

https://www.iana.org/assignments/http-methods/

a single new method will be registered as follows:

Method Name: QUERY
Safe: Yes
Idempotent: Yes
Reference: [ RFC-to-be; Section 2 ]

Second, in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

a single new field name will be registered as follows:

Field Name: Accept-Query
Status: permanent
Structured Type: List
Reference: [ RFC-to-be; Section 3 ]
Comments:

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This draft was extensively discussed over a long period of time, and has had diverse input.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not particularly.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No. This is a new semantic protocol element, so implementation is a bit 'chicken and egg' -- people don't want to implement until it's blessed as a standard.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

It has been exposed to W3C and WHATWG folks.

There was a detailed httpdir review by Roy Fielding, after which the I-D was revised, and WGLC'ed to confirm these changes.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No/yAng.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The impact of this draft is relatively contained to the areas that the HTTP WG usually operates within; we have discussed security and operability aspects of the method as part of WG discussion.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS. As a HTTP method definition, this is required.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; authors have been reminded.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All good.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It's two straightforward registrations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

The following Last Call announcement was sent out (ends 2025-11-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-safe-method-w-body@ietf.org, gorry@erg.abdn.ac.uk, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The HTTP QUERY Method) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'The HTTP QUERY Method'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-11-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines the QUERY method for HTTP.  A QUERY
  requests that the request target process the enclosed content in a
  safe/idempotent manner and then respond with the result of that
  processing.  This is similar to POST requests but can be
  automatically repeated or restarted without concern for partial state
  changes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This draft was extensively discussed over a long period of time, and has had diverse input.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not particularly.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No. This is a new semantic protocol element, so implementation is a bit 'chicken and egg' -- people don't want to implement until it's blessed as a standard.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Not particularly. It has been exposed to W3C and WHATWG folks.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No/yAng.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The impact of this draft is relatively contained to the areas that the HTTP WG usually operates within; we have discussed security and operability aspects of the method as part of WG discussion.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS. As a HTTP method definition, this is required.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; authors have been reminded.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All good.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It's two straightforward registrations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This draft was extensively discussed over a long period of time, and has had diverse input.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Not particularly.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No. This is a new semantic protocol element, so implementation is a bit 'chicken and egg' -- people don't want to implement until it's blessed as a standard.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Not particularly. It has been exposed to W3C and WHATWG folks.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No/yAng.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The impact of this draft is relatively contained to the areas that the HTTP WG usually operates within; we have discussed security and operability aspects of the method as part of WG discussion.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

PS. As a HTTP method definition, this is required.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; authors have been reminded.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

All good.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It's two straightforward registrations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/