> 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
Received on Wednesday, 23 July 2025 16:51:28 UTC