- From: Justin Richer <jricher@mit.edu>
- Date: Fri, 4 Oct 2024 01:45:10 +0000
- To: Mark Nottingham <mnot@mnot.net>, Brian Campbell <bcampbell@pingidentity.com>
- CC: Working Group HTTP <ietf-http-wg@w3.org>, "iana-questions@iana.org" <iana-questions@iana.org>
- Message-ID: <LV8PR01MB8677990AC7C54EA44F7B66AABD722@LV8PR01MB8677.prod.exchangelabs.com>
Thanks for bringing this up, Brian! And let's not forget the two from 9530, which I think are both dictionaries. - Justin ________________________________ From: Mark Nottingham <mnot@mnot.net> Sent: Tuesday, October 1, 2024 1:03 PM To: Brian Campbell <bcampbell@pingidentity.com> Cc: Working Group HTTP <ietf-http-wg@w3.org>; iana-questions@iana.org <iana-questions@iana.org> Subject: Re: Structured type of Client-Cert and Client-Cert-Chain It’s in my inbox now - that’ll do. Sent from my iPhone On 1 Oct 2024, at 9:55 am, Brian Campbell <bcampbell@pingidentity.com> wrote: Thanks Mark, Does this constitute asking? Or is a more formal or polite ask needed? On Tue, Oct 1, 2024 at 8:20 AM Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote: Just ask your friendly local registry expert (eg me). Cheers Sent from my iPhone On 1 Oct 2024, at 5:06 am, Brian Campbell <bcampbell@pingidentity.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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. 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 Friday, 4 October 2024 01:45:17 UTC