Re: Roman Danyliw's No Objection on charter-ietf-httpbis-08-02: (with COMMENT)

Hi Roman,

Just speaking for myself re the below --

> On 25 Sep 2025, at 5:07 am, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> ** “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?

Because of the broad uses of HTTP, the protocol's popularity, and the long history of the list, we sometimes get discussions on-list that get far into the weeds of a specific application, deployment, or use case.  This text is setting expectations and enabling the chairs to gently move such discussions elsewhere if they start to impact the work. Of course that is also enabled by specific RFCs and policies, but it seemed reasonable to remind folks of this in the charter, given the nature of the list.

> ** 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).”

Since we're not currently revising the core documents, they've been removed from the charter, with the implication that if we want to start a new HTTP revision, we'll need to recharter.

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

This isn't a scoping statement; it's just outlining the process for adoption for the readers' convenience.

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

They need to be told, with the implication that they have an opportunity to ask questions or ask for a pause.

The current charter has "The Area Director approves the addition and add corresponding milestones." That extra formalism hasn't added much value, and can introduce significant delays. Since a Call for Adoption will also be issued, the AD has an opportunity to raise concerns or ask for additional discussion -- this is just giving them a prompt to look at the document, assuring that they won't miss the CfA.

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

Those considerations were regarding the HTTP/1.1 revision, which is now complete. Many of the extensions we work on do not yet have implementation or use evident.

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

We'll work with the AD to update the milestones separately.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 24 September 2025 23:35:37 UTC