See draft-nottingham-bikeshed-length.

When one document references a field defined in another document, is there any preference of style? For example, should I say

• the "Content-Location" header field

• the "Content-Location" field

• the Content-Location header field

• the Content-Location field

• ...

Here's what I've used:

venue:
  group: httpbis
  type: Working
  mail: [email protected]
  arch: https://lists.w3.org/Archives/Public/ietf-http-wg/
  github: httpwg/http-extensions

https://tools.ietf.org/html/draft-davidben-tls-alps-half-rtt

https://tools.ietf.org/html/draft-nottingham-http-grease

See draft-snell-search-method.

Artwork that is too wide is a pain. How can document authors address that?

Right now, Signatures and Digest are both using NOTE: '\' line wrapping per RFC 8792, is this something the style guide should recommend?

Has there ever been discussion for a status code that means "this URL does not exist, but let me redirect you to a URL that does and might help you"?

Especially for URLs that are meant to be human-readable this would be really helpful. Or if you want to help the user by eliding punctuation that might have ended up at the end of a URL due to bad auto-linking. (And in practice I've seen this implemented with a 3xx status code and I suppose 301 kinda fits the bill, but it's a little strange?)

(This also applies a bit to 410 and maybe other 4xx status codes.)

(Sorry if this is the wrong place.)

So, HTTP/2 was one of the first big IETF efforts that used GitHub, and we gave it its own GitHub org:
https://github.com/http2

If we're going to start working on bis, we should figure out the status of this org.

I'm thinking we should move the following repos to the httpwg organisation:

• http2-spec
• compression-test (this is still useful for testing other ways of compressing things)
• http_samples ?

The rest of the repos can stay there and be archived, with the exception of the Web site, which should be update to point to the HTTP WG home page (migrating some material, possibly). And we'd probably put some text in the org description pointing people to httpwg.

Does all of that make sense? Other thoughts?

@martinthomson, I see that you forked http2-spec for your bis proposal; my assumption is that that will eventually turn into a PR against httpwg/http2-spec.

The only thing that's giving me slight pause here is that if we use the same repo for h2bis, the issues will become intermingled. I don't currently see how that would cause problems (because we can filter by dates, etc.).

/cc @tfpauly

See draft-polli-ratelimit-headers.

https://tools.ietf.org/html/draft-sahib-451-new-protocol-elements-03

https://mnot.github.io/I-D/draft-nottingham-http-structure-retrofit.html

On existing and new repos.

See GitHub info. They recommend waiting until later this year for migration, but new repos should start with main.

That would make it easier to watch and participate in just what is of interest to you.

https://datatracker.ietf.org/doc/draft-pauly-httpbis-geohash-hint/

https://datatracker.ietf.org/doc/draft-nottingham-cache-trailers/

The Concealed auth draft defines new HTTP authentication parameters. Over in httpwg/http-extensions#2801 we realized that the syntax for how to define new parameters and how to refer to those parameters wasn't consistent. I went to check the style guide, and there was no guidance. I picked something consistent for that draft, but it would be good to provide guidance in the style guide, similar to the guidance we provide for header field names.

For what it's worth, what I picked in that draft was:

• when defining a new parameter:

The REQUIRED "s" (signature) Parameter is an integer that specifies...

• when referencing the parameter:

The key ID sent in the k Parameter...

Note that "Parameter" is uppercase here, would be good to suggest whether upper- vs lower-case is preferred.

https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability

See draft-handte-httpbis-dict-sec.

See draft-toomim-httpbis-braid-http.

@martinthomson should this be relatively straightforward?

/cc @MikeBishop

See, eg, https://datatracker.ietf.org/doc/draft-martin-http-carbon-emissions-scope-2/

https://datatracker.ietf.org/doc/draft-gupta-httpbis-per-resource-events/

https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-altsvc-quic

Question

In https://github.com/httpwg/admin/blame/main/style-guide.md#L33 I was guessing - once a field has been defined which is the benefit to repeat in more than one place the term "field", "header field", ... .
My impression is that backticks eg Content-Location, Content-Type improve readability a lot wrt just having unquoted strings followed by "header field".

Under the header https://http2.github.io/faq/#is-the-priority-example-in-section-532-incorrect

The broken link: http://http2.github.io/http2-spec/#rfc.section.5.3.2

In context:

Consequently, as the specification states: stream B ideally receives one-third of the resources allocated to stream C.

https://tools.ietf.org/html/draft-cdn-control-header

https://datatracker.ietf.org/doc/draft-cedik-http-warning/

https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-http2bis-00

Mailing list thread:
https://www.w3.org/mid/[email protected]

See draft-bdc-something-something-certificate.

Do we want a spec to refer to SF every time it uses a term, like this:

Each member of the Foo header (a Dictionary, per {{Section 3.2 of STRUCTURED-HEADERS}})
is an Integer (see {{Section 3.3.1 of Structured Headers}}).

Or just rely on declaration of terminology in Notational Conventions (and capitalisation), so that it would be:

Each member of the Foo header (a Dictionary) is an Integer.

?

I'm leaning towards the latter...

The latest revision to HTTP/2, RFC 9112, deprecated a few things that turned out to be duds but it didn't go as far as making any breaking changes.

What if we had infinite scope to change the wire image in a breaking way? What would you like to see removed altogether, changed, or newly added as a mandatory feature? Here's my starter list:

1. Improve stream concurrency control (e.g. MAX_STREAMS)
2. Remove server push
3. Remove RFC 7540 priorities (recommend RFC 9218?)
4. Restrict SETTINGS to once per connection at the start
5. Mandate extended CONNECT
6. Use QUIC variable-length integers (expand from 32-bit to 64-bit integers)
7. Grease every extension code point
8. Remove frame flags field - replace this with frame type instead (similar to QUIC and HTTP/3)
9. Remove CONTINUATION frames (larger frame sizes obviate them)
10. Mandate TLS; remove cleartext and upgrade (and hence avoid complications related to cleartext)
11. Remove prior knowledge and the preface stuff. (ALPN is enough to determine what a connection is being used for)
12. Tweak so that stream errors allow to elicit an error HTTP response rather than just a RST_STREAM

any comments or suggestions?

We explicitly say not to <tt> / ` field names on reference. Do we want that enclosure when we're explicitly citing a field name and value pair? That is:

...by sending a Vary: Client-Cert response header.

or

...by sending a "Vary: Client-Cert" response header.

or

...by sending a Vary: Client-Cert response header.

I'm inclined to think that quotes are the most clear, since they appear in the text output, but ignoring text output my preference would be for <tt>

I've so far been looking at the markdown version, which does a nice job of differentiating instruction from example. However, over on https://httpwg.org/admin/editors/style-guide, things are less clear and it looks more like a wall of text. It would help to make the examples look more like examples.

https://tools.ietf.org/html/draft-bishop-httpbis-grease

https://github.com/httpwg/admin/blob/main/style-guide.md#references is IMO not very clear to a casual observer. I think it might just be better to state that named references are preferred over RFC numbers, and then list concrete examples of common documents that HTTP WG docs are likely to need. For instance, when referencing HTTP semenantics I think the preference is HTTP rather than SEMANTICS. Structured Fields will also similarly be referenced a lot and a common way to ref it might help things.

As a proposal for addition to RFC6265bis:
https://tools.ietf.org/html/draft-west-cookie-incrementalism

I ended up putting one here for a review. Is this a reasonable location?

https://mnot.github.io/I-D/draft-nottingham-binary-structured-headers.html

My mailing list subscription application has been in the following status since about Nov 25th. Approved but can neither receive nor send.

ID already processed

Error: The message with id: xxx has already been processed (approved).

And what about pseudo-header fields? The style guide says no quotes except when defining for header fields, and I'm inclined to follow that, but the fact that pseudo-headers don't have a title-casing convention and begin with a non-letter character makes them feel substantially more awkward in the text. If nothing else, the style guide should explicitly cover that case.

Originally posted by @MikeBishop in #32 (comment)

A few things that spring to mind are frames (and flags), settings, streams (including termination), pseudo-headers, stream 0 (H2) and control stream (H3).

In https://github.com/httpwg/admin/blob/main/style-guide.md#header-and-trailer-fields the guidance says

If the field is specific to headers, trailers, requests, and/or responses, the definition should include the relevant terms, as above.

and

Subsequent occurrences should be unquoted, but always be followed by "field", "header field", or "trailer field" as appropriate.

Content-Digest, for example, is all of these things. So ends up being defined as "the Content-Digest request and response header and trailer field". We refreain from saying "header and trailer" everywhere though. Should we really just be saying "field" or does that gloss over the definition of the field too much?

Perhaps the style guide would benefit from the explicit counter case in the guidance along the lines of "if a field applies to multiple categories, those categories can be ommited and only "field" used. Or some other guidance if I'm not on the money,