- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Tue, 01 Oct 2024 15:43:27 +0100
- To: "Mark Nottingham" <mnot@mnot.net>
- Cc: "Brian Campbell" <bcampbell@pingidentity.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
- Message-Id: <98b462ce-d4cf-4e5b-9fed-d13d073bd103@app.fastmail.com>
On Tue, Oct 1, 2024, at 15:38, Mark Nottingham wrote: > We did do it all in one go - at time of submission. A period of adjustment is unavoidable, thanks to the long queue lags. Ah that would explain why Priority has a value, thanks! > > Re retrofit: the spec suggests one IIRC, but it isn’t an RFC yet. > > Sent from my iPhone > >> On 1 Oct 2024, at 7:34 am, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: >> >> So strangely, the Priority header already has a value in the column, and I don't know why. >> >> On Tue, 1 Oct 2024, 15:24 Mark Nottingham, <mnot@mnot.net> wrote: >>> Just ask your friendly local registry expert (eg me). >> >> Could we just do them all on one go please? Right now, it's not clear if an entry is empty because it's not a Structured Field or because it hasn't been updated. Also, should we think about adding a qualifier to disambiguate retrofit structured fields? >> >> Cheers >> Lucas >>> >>> Cheers >>> >>> Sent from my iPhone >>> >>>> On 1 Oct 2024, at 5:06 am, Brian Campbell <bcampbell@pingidentity.com> wrote: >>>> >>>> Hi folks of HTTP and IANA, >>>> >>>> Are there (hopefully not heavyweight) procedures or processes available to add values for the newish "Structured Type" column in the HTTP Field Name Registry for fields, like those from RFC 9440 and 9421, which were defined as structured types per RFC 8941 before the "Structured Type" column was available on the registry? >>>> >>>> >>>> ---------- Forwarded message --------- >>>> From: *Takahiko Kawasaki* <taka@authlete.com> >>>> Date: Mon, Sep 30, 2024 at 9:40 PM >>>> Subject: Re: Structured type of Client-Cert and Client-Cert-Chain >>>> To: Brian Campbell <bcampbell@pingidentity.com> >>>> >>>> >>>> HI Brian, >>>> >>>> Thank you for explaining the field name registry. I wasn't aware of RFC 9651 at all! >>>> >>>> And of course, I don’t mind if you forward my message. In addition to Client-Cert and Client-Cert-Chain, the structured data types for the Signature field and the Signature-Input field (from RFC 9421) have been explicitly defined as Dictionary. It would be great if this information could also be registered. >>>> >>>> >>>> On Tue, Oct 1, 2024 at 9:41 AM Brian Campbell <bcampbell@pingidentity.com> wrote: >>>>> Hi Taka, >>>>> >>>>> I think that column was only recently added to the Field Name registry by the draft that only very very recently became RFC 9651. I'd think/hope it wouldn't be an issue to update the registry entries from RFC 9440 too. Do you mind if I forward your message to some IANA and/or HTTP people to ask about getting things updated? >>>>> >>>>> On Fri, Sep 27, 2024 at 3:32 PM Takahiko Kawasaki <taka@authlete.com> wrote: >>>>>> Hi Brian, >>>>>> >>>>>> How are you? >>>>>> >>>>>> The RFC 9440 Client-Cert HTTP Header Field <https://www.rfc-editor.org/rfc/rfc9440.html>, which you authored, defines the Client-Cert and Client-Cert-Chain fields. The specification explicitly states that their structured data types are Item (Byte Sequence) and List, respectively. However, this information is not reflected in the IANA Hypertext Transfer Protocol (HTTP) Field Name Registry <https://www.iana.org/assignments/http-fields/http-fields.xhtml>. It would be great if you could use your influence to have IANA update the information. >>>>>> >>>>>> The reason for this request is that such information is useful for developers considering support for the `sf` flag, which is defined in Section 2.1. HTTP Fields <https://www.rfc-editor.org/rfc/rfc9421.html#section-2.1> of RFC 9421 HTTP Message Signatures <https://www.rfc-editor.org/rfc/rfc9421.html>, based on the official source. >>>>>> >>>>>> Thank you in advance! >>>>>> >>>>>> -- >>>>>> *Takahiko Kawasaki* >>>>>> Co-Founder >>>>>> taka@authlete.com >>>>>> Authlete >>>>>> authlete.com <https://www.authlete.com/> |Linkedin <https://www.linkedin.com/company/authlete/> >>>>>> Palo Alto, Tokyo, London, Dubai >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*
Received on Tuesday, 1 October 2024 14:43:58 UTC