Hypertext Transfer Protocol
charter-ietf-httpbis-09

Yes

Erik Kline
Gorry Fairhurst
Mike Bishop

No Objection

Andy Newton
Deb Cooley
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Mohamed Boucadair
Paul Wouters
Roman Danyliw

Note: This ballot was opened for revision 08-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Erik Kline
Yes
Comment (2025-09-13 for -08-00) Sent 
# Internet AD comments for charter-ietf-httpbis-08-00
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### "other areas"

* "substantial input from other areas ... coordinated through the
   appropriate bodies"

  You might see if there's a wording that incorporates the possibility of
  and/or need to coordinate with other SDOs (e.g. W3C, whatwg, ...).
  It doesn't change anything, just acknowledges that they too could be
  part of the process.
Gorry Fairhurst
Yes
Mike Bishop
Yes
Andy Newton
No Objection
Deb Cooley
No Objection
Comment (2025-09-25 for -08-02) Sent 
I agree with Paul's comment.  Otherwise, a short, and direct charter.  

Milestones need to be added.
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Mahesh Jethanandani
No Objection
Comment (2025-09-23 for -08-02) Sent 
Thanks for a short (and sweet) charter.
Mohamed Boucadair
No Objection
Comment (2025-09-23 for -08-02) Sent 
Hi all, 

Thanks for the revised update.

# "minor" vs "major"

I would expect some few words to clarify what is "minor" vs "major" extension.

Some minor nits:

# Cite STD 98 for consistency

OLD: Hypertext Transfer Protocol (HTTP) is an Internet Standard defined in STD 97 / RFC 9110, with caching behavior in RFC 9111.

NEW: Hypertext Transfer Protocol (HTTP) is an Internet Standard defined in STD 97 / RFC 9110, with caching behavior in STD 98/RFC 9111.

# Drafts

Maybe:

OLD: The Working Group may make minor revisions to the core HTTP drafts under the same criteria

NEW: The Working Group may make minor revisions to the core HTTP specifications under the same criteria

Cheers,
Med
Paul Wouters
No Objection
Comment (2025-09-24 for -08-02) Sent 
Note I find these bullet points a bit odd:

* The Working Group Chairs judge that there is consensus to take on the item; and

* The Area Director is informed of the addition.

The first bullet is always true for all items in a WG, and the second bullet point _should_ be true to if the AD does their job :)
Roman Danyliw
No Objection
Comment (2025-09-24 for -08-02) Sent 
** “Beyond specification work, the Working Group is a forum for implementers, practitioners, and researchers to discuss the protocol, its operation and evolution, to improve interoperability and ecosystem health. However, the chairs may ask that some discussions be moved off-list to avoid interfering with specification work.”

Sometimes discussions are acceptable, but sometimes not?  How is the scope determined? Is there a way to be more specific?

** Per, the “work mode” of “They are generic; i.e., not specific to one application using HTTP. Note that Web browsing by definition is a generic use” what new scope is given by this text given that the section prior said “This Working Group is charged with maintaining and developing the core specifications for HTTP and generic extensions to it (i.e., those that are not specific to one application).”

** Per the “work mode” of “The Working Group Chairs judge that there is consensus to take on the item”, how does this provide scope?  This is true of every adopted WG document.

** Per the “work mode” of “The Area Director is informed of the addition”, does the AD have to agree or are they just told this is happening?

** The currently approve -08 charter had the following considerations:
“In doing so, it should consider:
•	Implementer experience
•	Demonstrated use of HTTP
•	Impact on existing implementations and deployments”

Did the WG not find these important in scoping work?

** In reviewing the milestones, these are complete and can be marked as such.  Congrats on finishing the work.
 	Submit Client-Cert Header	rfc9440 (was draft-ietf-httpbis-client-cert-field)
        Submit Unprompted Auth	rfc9729 (was draft-ietf-httpbis-unprompted-auth)

** Are these still valid milestones?  They are for expired drafts:
	Submit Secondary Server Certs	draft-ietf-httpbis-secondary-server-certs
	Submit Retrofit Structured Fields	draft-ietf-httpbis-retrofit