Re: New issue: Header type for JWT format values

> I don't believe that is true.

This was also my take - Structured Fields should be used where the field
value is in any way 'complex', but if it's just a single value, it can (and
maybe should) be used as-is.

JWTs are a relatively new but also common standard and hence my suggestion
that you simply define the Txn-Token field as a basic unquoted string which
allows any characters, so it can be passed as:

Txn-Token: eyJhbGciOiJ...mqJp-QV30

(on the assumption that the sender passes a valid JWT). Or you could define
the field value as a valid JWT (three strings delimited by dots, with
appropriate character sets for the two Base64 Url-encoded sections and for
the key).

Rory

On Wed, Jul 23, 2025 at 9:51 AM Roy T. Fielding <fielding@gbiv.com> wrote:

> On Jul 22, 2025, at 2:14 PM, Darrel Miller <darrel@tavis.ca> wrote:
>
> The current guidance is that all new HTTP fields are defined using
> structured field values.
>
>
> I don't believe that is true.
>
> If a new field would benefit from having a structured field value,
> the usual suspects will ask for reasons why it isn't structured. That is,
> structured fields have a known set of benefits for many potential
> definitions
> and the folks defining a new field may not be aware of those benefits.
>
> OTOH, there are many common fields for which structured field values
> would be a waste of processing time and extra bytes on the wire.
> Other usual suspects will ask for justification before wasting internets
> on a syntax that isn't useful.
>
> Neither one is ensured by the current review process, which typically
> allows
> anyone to mint any field name with any arbitrary syntax, provided that
> there
> is some document that describes it. Not everything starts out as an I-D.
>
> IMO, the field described here is not suitable as a structured field value
> because the structure has already been encoded as a token. I don't think
> adding quotes around it is useful.
>
> Better questions are whether encoding the data as a token is a good idea,
> given the alternative of using a structured list, and whether the data
> contains credentials?
>
>   https://www.rfc-editor.org/rfc/rfc9110.html#name-credentials
>
> Credentials belong inside the existing auth fields, not in extension
> fields.
> They need to be separated from other data to avoid compression and
> other problematic handling/storage of extension fields.
>
> ....Roy
>
>

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt