Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the following terminology from STRUCTURED-FIELDS to specify syntax and parsing: Integer and Byte Sequence.  This document uses the notation from QUIC. </del>  2.

Reviewer comments:
This nags at me a bit. I think you want to be crystal clear are what parts of Stuctured Fields you are and what you aren't. As far as I see, you want to use the aspect in order to reuse the serialization/deserialization, legal characters, legal range, etc., for the auth parameter values. But you don't need the aspect, which would allow you to parameterise the parameters. Does that sound accurate?
We added this sentence based on a URL from NAME Martin, do you have thoughts here? I think the intent was just to point out that we're in the new structured fields world even though Authorization hasn't been retrofitted yet
In , NAME pointed out that we can't simply use byte sequences from structured fields because authentication parameter values need to be which doesn't allow non-quoted colons. So I switched to double-quotes in dcc520544cf98cf634c9ca0a24119256fd18d58e, but that makes the usage of structured fields somewhat messy. Thoughts?
Copying my comment from the change
Good call. I now added both colons and double-quotes via 690ee072bb450ab631db5b32a23b457cec9bb6be
From Ilari Liusvaara on the : I renamed this issue to track whether we want to keep structured fields or not. Personally, I don't have a strong opinion either way.
I could live without structured fields here, presumably there are servers that already have to handle Authorization fields using the more-traditional encodings
I'll note however that if we go with we'll need to either double-quote it or explicitly ban padding, because is not allowed as part of
While base64 proper is often padded, it is more common for base64url to be unpadded (indeed, I think that the string "base64url" specifically refers to the unpadded version if you follow it to its origin, which I think is URL).
dates back at least as far as and that spec explicitly : None of which is a problem, we just need to be explicit. We know how to do that.
Right, the 7515 thing was what we ended up using in another context, where padding was explicitly not included. Clearly, we shouldn't use it here either[^1]. [^1]: I hold the view that it shouldn't be used in any situation, because if knowing the length is important, you would have a length prefix or delimiter, rendering padding pointless for anything other than protection against traffic analysis. And you can't arbitrarily pad with base64 padding, so that's no good.
I'd ideally want to align with draft-ietf-privacypass-auth-scheme. We reviewed this a lot with NAME and went back and forth and ended up with: So from a syntax standpoint, this is "base64url and you don't need quotes, but do include quotes if you have padding". If you define that you don't use padding, then you don't need quotes. So I think things can be consistent here.
Based on the conversation in the room at IETF 117, I'm inclined to make these no longer structured headers, and to use base64url without padding, without quotes, and without colons.

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  <ins> This document uses the notation from QUIC. </ins> 2.