Dear Alanna, I also approve.
Regards, Jonathan On Wed, 12 Feb 2025, 21:55 David Oliver, <da...@guardianproject.info> wrote: > Alanna, I approve of the formatting as well as the content > > > David M. Oliver | da...@guardianproject.info | > https://guardianproject.info | @davidmoliver | +1 970 368 2366 > > > On Tue, Feb 11, 2025 at 6:23 PM Alanna Paloma < > apal...@staff.rfc-editor.org> wrote: > >> Hi David, >> >> Thank you. Your approval has been noted: >> https://www.rfc-editor.org/auth48/rfc9729 >> >> We ask that both David and Jonathan also review and approve of the >> formatting. >> >> Best regards, >> RFC Editor/ap >> >> > On Feb 11, 2025, at 3:02 PM, David Schinazi <dschinazi.i...@gmail.com> >> wrote: >> > >> > Thanks Alanna. >> > >> > I updated our local copy to use the shorter IANA links per the style >> guide. >> > I was then able to confirm that the TXT diff between our copy and yours >> is now empty. >> > I also checked the formatting on other files and there were no >> surprises. >> > >> > You have my approval to publish. Do you also need other authors to >> reapprove or is one enough here? >> > >> > Thanks, >> > David >> > >> > On Tue, Feb 11, 2025 at 2:46 PM Alanna Paloma < >> apal...@staff.rfc-editor.org> wrote: >> > Hi David, >> > >> > > 1) IANA registries. I see that the links to the registries no longer >> include the anchor that points to the registry. Was that intentional? >> > >> > Yes, this was intentional. This update was made per guidance from IANA >> that that only the short version of the URL should be used. Please see the >> Web Portion of the Style Guide < >> https://www.rfc-editor.org/styleguide/part2/#ref_iana_reg> and IANA’s >> Guidance for RFC Authors <https://www.iana.org/help/protocol-registration> >> for more information. >> > >> > > 2) The MASQUE-ORIGINAL reference was changed from >> draft-schinazi-masque-00 to draft-schinazi-masque-02. Please revert to >> draft-schinazi-masque-00. The goal here is to show the earliest prior art, >> so we intentionally want the older version. -02 is particularly wrong >> because the auth component had been removed at that point. >> > >> > We reverted this update to point to draft-schinazi-masque-00. >> > >> > ... >> > The files have been posted here (please refresh): >> > https://www.rfc-editor.org/authors/rfc9729.xml >> > https://www.rfc-editor.org/authors/rfc9729.txt >> > https://www.rfc-editor.org/authors/rfc9729.html >> > https://www.rfc-editor.org/authors/rfc9729.pdf >> > >> > Best regards, >> > RFC Editor/ap >> > >> > > On Feb 11, 2025, at 2:13 PM, David Schinazi <dschinazi.i...@gmail.com> >> wrote: >> > > >> > > Hi Alanna, >> > > >> > > I looked at the diff between the version we reviewed and the latest >> one, and found some unexpected changes. >> > > >> > > 1) IANA registries. I see that the links to the registries no longer >> include the anchor that points to the registry. Was that intentional? >> > > >> > > 2) The MASQUE-ORIGINAL reference was changed from >> draft-schinazi-masque-00 to draft-schinazi-masque-02. Please revert to >> draft-schinazi-masque-00. The goal here is to show the earliest prior art, >> so we intentionally want the older version. -02 is particularly wrong >> because the auth component had been removed at that point. >> > > >> > > Thanks, >> > > David >> > > >> > > On Tue, Feb 11, 2025 at 1:32 PM Alanna Paloma < >> apal...@staff.rfc-editor.org> wrote: >> > > Authors, >> > > >> > > We have noted Jonathan’s approval on the AUTH48 status page: >> > > https://www.rfc-editor.org/auth48/rfc9729 >> > > >> > > As the content of the document has been approved, we now ask that >> each author review and approve of the formatting in the output files below. >> > > >> > > The files have been posted here (please refresh): >> > > https://www.rfc-editor.org/authors/rfc9729.xml >> > > https://www.rfc-editor.org/authors/rfc9729.txt >> > > https://www.rfc-editor.org/authors/rfc9729.html >> > > https://www.rfc-editor.org/authors/rfc9729.pdf >> > > >> > > Once we have receive approval of the formatting, we will move this >> document forward in the publication process. >> > > >> > > Best regards, >> > > RFC Editor/ap >> > > >> > > > On Feb 11, 2025, at 8:00 AM, Jonathan Hoyland < >> jonathan.hoyl...@gmail.com> wrote: >> > > > >> > > > Hi Alanna, >> > > > I've just gone through the document again, and you have my approval >> too. >> > > > Thanks, >> > > > Jonathan >> > > > >> > > > On Mon, 10 Feb 2025, 16:32 Alanna Paloma, < >> apal...@staff.rfc-editor.org> wrote: >> > > > Hi David, >> > > > >> > > > Thank you for your reply. Your approval has been noted: >> > > > https://www.rfc-editor.org/auth48/rfc9729 >> > > > >> > > > We await Jonathan’s approval of the content. >> > > > >> > > > Best regards, >> > > > RFC Editor/ap >> > > > >> > > > > On Feb 9, 2025, at 7:56 AM, David Oliver < >> da...@guardianproject.info> wrote: >> > > > > >> > > > > Wonderful. You have my approval on the recent updates on RFC9729. >> > > > > >> > > > > David M. Oliver | da...@guardianproject.info | >> https://guardianproject.info | @davidmoliver | +1 970 368 2366 >> > > > > >> > > > > >> > > > > On Wed, Feb 5, 2025 at 12:49 PM Alanna Paloma < >> apal...@staff.rfc-editor.org> wrote: >> > > > > Hi David, >> > > > > >> > > > > Thank you for your reply. We have updated the files with your >> additional tweaks and noted your approval on the AUTH48 status page: >> > > > > https://www.rfc-editor.org/auth48/rfc9729 >> > > > > >> > > > > The updated files have been posted here (please refresh): >> > > > > https://www.rfc-editor.org/authors/rfc9729.md >> > > > > >> > > > > https://www.rfc-editor.org/authors/rfc9729-diff.html >> (comprehensive text diff) >> > > > > https://www.rfc-editor.org/authors/rfc9729-auth48diff.html >> (AUTH48 text diff) >> > > > > >> > > > > (Note: We have adjusted the wrapping to now have a width of 80.) >> > > > > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html >> (comprehensive md diff) >> > > > > https://www.rfc-editor.org/authors/rfc9729-mdauth48diff.html >> (AUTH48 md diff) >> > > > > https://www.rfc-editor.org/authors/rfc9729-mdlastdiff.html >> (last version to this one) >> > > > > >> > > > > We will now await approvals of the content from David M. Oliver >> and Jonathan Hoyland. >> > > > > >> > > > > Best regards, >> > > > > RFC Editor/ap >> > > > > >> > > > > >> > > > > > On Feb 4, 2025, at 4:08 PM, David Schinazi < >> dschinazi.i...@gmail.com> wrote: >> > > > > > >> > > > > > Thanks Alanna! >> > > > > > >> > > > > > I went through the document in detail, and I think the changes >> look great. I made three small tweaks to your version, and uploaded them >> here: >> > > > > > >> https://github.com/httpwg/http-extensions/commit/03cd6dc3b6588b30a40ce74f59843ed96a15555c >> > > > > > >> > > > > > Apart from that, I think this is good to go. >> > > > > > >> > > > > > Doing the review in markdown made it incredibly seamless. I >> have a couple incredibly minor points about the markdown diff: >> > > > > > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html >> > > > > > >> > > > > > 1) it points out a change in the lines surrounding >> diagrams/sourcecode blocks: it says that "~~" was changed to "~~~" even >> though both versions contain "~~~". >> > > > > > 2) it seems to be set to a column width of 78. That causes a >> few lines to wrap for documents where we use a width of 80 (which I think >> is the default?). >> > > > > > >> > > > > > Thanks! >> > > > > > David >> > > > > > >> > > > > > On Tue, Feb 4, 2025 at 1:53 PM Alanna Paloma < >> apal...@staff.rfc-editor.org> wrote: >> > > > > > Hi David, >> > > > > > >> > > > > > Thank you for your reply. We have updated as requested. >> > > > > > >> > > > > > > 4) <!-- [rfced] We see that the capitalization of "Key ID" is >> inconsistent. Please let how we should update it. >> > > > > > > --> >> > > > > > > >> > > > > > > I think the inconsistency is intentional: "key ID" refers to >> the concept, whereas "Key ID" refers to the eponymous field in the Key >> Exporter Context structure. Does that work or do you think it reduces >> clarity? >> > > > > > >> > > > > > ) Thank you for clarifying. The reasoning makes sense, and it >> should be clear enough from the context within the document. We have left >> the capitalization as is. >> > > > > > >> > > > > > >> > > > > > The updated files have been posted here (please refresh): >> > > > > > https://www.rfc-editor.org/authors/rfc9729.md >> > > > > > >> > > > > > https://www.rfc-editor.org/authors/rfc9729-diff.html >> (comprehensive text diff) >> > > > > > https://www.rfc-editor.org/authors/rfc9729-auth48diff.html >> (AUTH48 text diff) >> > > > > > >> > > > > > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html >> (comprehensive md diff side-by-side) >> > > > > > https://www.rfc-editor.org/authors/rfc9729-mdauth48diff.html >> (AUTH48 md diff side-by-side) >> > > > > > >> > > > > > >> > > > > > Please review the document carefully and contact us with any >> further updates you may have. Note that we do not make changes once a >> document is published as an RFC. >> > > > > > >> > > > > > We will await approvals from each author of the content in the >> markdown prior to converting the markdown to RFCXML and asking each authors >> to review and approve the final files. >> > > > > > >> > > > > > For the AUTH48 status of this document, please see: >> > > > > > https://www.rfc-editor.org/auth48/rfc9729 >> > > > > > >> > > > > > Thank you, >> > > > > > RFC Editor/ap >> > > > > > >> > > > > > > On Feb 3, 2025, at 7:43 PM, David Schinazi < >> dschinazi.i...@gmail.com> wrote: >> > > > > > > >> > > > > > > Hi RFC Editor(s), >> > > > > > > >> > > > > > > First off, I really wanted to thank you for doing this AUTH48 >> in markdown - it's a huge life improvement :-) >> > > > > > > >> > > > > > > Please find answers to your questions inline below. Let me >> know when you've incorporated those and I'll do a full pass of the document >> as soon as I can in the next few days. >> > > > > > > >> > > > > > > Thanks, >> > > > > > > David >> > > > > > > >> > > > > > > On Fri, Jan 31, 2025 at 12:18 PM <rfc-edi...@rfc-editor.org> >> wrote: >> > > > > > > Authors, >> > > > > > > >> > > > > > > While reviewing this document during AUTH48, please resolve >> (as necessary) the following questions, which are also in the XML file. >> > > > > > > >> > > > > > > 1) <!-- [rfced] FYI, we have added the following sentence to >> Section 1.1 >> > > > > > > ("Conventions and Definitions") in order to include a >> citation for RFC 8792 in the text. Please let us know of any objections. >> > > > > > > >> > > > > > > Current: >> > > > > > > Various examples in this document contain long lines that >> may be folded, >> > > > > > > as described in [RFC8792]. >> > > > > > > --> >> > > > > > > >> > > > > > > Sounds good. >> > > > > > > >> > > > > > > 2) <!--[rfced] Throughout the text, "Concealed HTTP >> authentication scheme" and "Concealed authentication scheme" appear to be >> used inconsistently. Please review these occurrences and let us know if/how >> they be made consistent. Some examples are listed here: >> > > > > > > >> > > > > > > Original: >> > > > > > > When a client wishes to use the Concealed HTTP >> authentication scheme >> > > > > > > with a request, it SHALL compute the authentication proof >> using a TLS >> > > > > > > keying material exporter with the following parameters: >> > > > > > > ... >> > > > > > > If a frontend is configured to check the Concealed >> authentication >> > > > > > > scheme, it will parse the Authorization (or >> Proxy-Authorization) >> > > > > > > header field. >> > > > > > > --> >> > > > > > > >> > > > > > > I think that the defining statement at the start of section 2 >> > > > > > > <<This document defines the "Concealed" HTTP authentication >> scheme.>> >> > > > > > > should include "HTTP" to be extra clear when defining it. I'm >> happy for all other uses to be consistent. >> > > > > > > So maybe we make them all <<Concealed HTTP authentication >> scheme>>? >> > > > > > > >> > > > > > > 3) <!-- [rfced] Please review sourcecode types within the >> markdown file, and let us know if they should be set and/or have been set >> correctly. >> > > > > > > >> > > > > > > The current list of preferred values for sourcecode types is >> available at >> > > > > > > < >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >> > > > > > > If the current list does not contain an applicable type, feel >> free to >> > > > > > > suggest additions for consideration. Note that it is also >> acceptable >> > > > > > > to leave the sourcecode type not set. >> > > > > > > --> >> > > > > > > >> > > > > > > They look correct to me. It might be useful to define a new >> type for the QUIC presentation format given how common it's becoming (since >> we have one for the TLS presentation format), but for this document those >> can stay empty since it doesn't exist yet. >> > > > > > > >> > > > > > > 4) <!-- [rfced] We see that the capitalization of "Key ID" is >> inconsistent. Please let how we should update it. >> > > > > > > --> >> > > > > > > >> > > > > > > I think the inconsistency is intentional: "key ID" refers to >> the concept, whereas "Key ID" refers to the eponymous field in the Key >> Exporter Context structure. Does that work or do you think it reduces >> clarity? >> > > > > > > >> > > > > > > 5) <!--[rfced] As "Signature Algorithm" is being used in a >> general way and not as a field name, may we make it lowercase in this >> sentence? >> > > > > > > >> > > > > > > Original: >> > > > > > > The encoding of the public key is determined by the >> Signature >> > > > > > > Algorithm in use as follows: >> > > > > > > >> > > > > > > Perhaps: >> > > > > > > The encoding of the public key is determined by the >> signature >> > > > > > > algorithm in use as follows: >> > > > > > > --> >> > > > > > > >> > > > > > > Agreed, that one's not the field name so lowercase makes >> sense. >> > > > > > > >> > > > > > > 6) <!--[rfced] For clarity, may we update "which" to "that" >> here? It depends on the intended meaning, as noted below. >> > > > > > > >> > > > > > > Original: >> > > > > > > The public key is an RSAPublicKey structure >> > > > > > > [PKCS1] encoded in DER [X.690]. BER encodings which are >> not DER >> > > > > > > MUST be rejected. >> > > > > > > >> > > > > > > Perhaps (restrictive "that", meaning some BER encodings): >> > > > > > > The public key is an RSAPublicKey structure >> > > > > > > [PKCS1] encoded in DER [X.690]. BER encodings that are >> not DER >> > > > > > > MUST be rejected. >> > > > > > > >> > > > > > > Or (nonrestrictive "which", meaning all BER encodings): >> > > > > > > The public key is an RSAPublicKey structure >> > > > > > > [PKCS1] encoded in DER [X.690]. BER encodings, which are >> not DER, >> > > > > > > MUST be rejected. >> > > > > > > --> >> > > > > > > >> > > > > > > You're correct, let's use "that" here. Some BER encodings are >> DER, and those are valid and must not be rejected. >> > > > > > > >> > > > > > > 7) <!-- [rfced] We having difficulty parsing the following >> sentence. >> > > > > > > Does the key ID authenticate or does the client? >> > > > > > > >> > > > > > > Current: >> > > > > > > For example, the key ID "basement" authenticating using >> Ed25519 >> > > > > > > [ED25519] could produce the following header field >> > > > > > > >> > > > > > > Perhaps: >> > > > > > > For example, a client authenticating with the key ID >> "basement" >> > > > > > > and using Ed25519 [ED25519] could produce the following >> header >> > > > > > > field >> > > > > > > --> >> > > > > > > >> > > > > > > You're correct that the key ID doesn't authenticate. However, >> "authenticate" is somewhat annoying as a verb in that the concept of "the >> client is proving to the server that it is who it says it is" can be said >> as "the server authenticated the client" or "the client authenticated to >> the server" - and not everyone agrees that they're both valid. How about we >> sidestep the issue with something like this: >> > > > > > > <<For example, a client using the key ID "basement" and the >> signature algorithm Ed25519 [ED25519] could produce the following header >> field:>> >> > > > > > > >> > > > > > > 8) <!-- [rfced] RFC 8941 has been obsoleted by RFC 9651. May >> we replace RFC 8941 with RFC 9651? >> > > > > > > --> >> > > > > > > >> > > > > > > Yes, please. >> > > > > > > >> > > > > > > 9) <!-- [rfced] Please review the "Inclusive Language" >> portion of the online Style Guide < >> https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let >> us know if any changes are needed. Updates of this nature typically result >> in more precise language, which is helpful for readers. >> > > > > > > --> >> > > > > > > >> > > > > > > I didn't find any instances of non inclusive language, but >> let me know if you noticed any. >> > > > > > > >> > > > > > > 10) <!--[rfced] References. May we add the following URL to >> this reference for the ease of the reader? >> > > > > > > >> > > > > > > https://www.itu.int/rec/T-REC-X.690 >> > > > > > > >> > > > > > > Current: >> > > > > > > >> > > > > > > [X.690] ITU-T, "Information technology - ASN.1 encoding >> Rules: >> > > > > > > Specification of Basic Encoding Rules (BER), >> Canonical >> > > > > > > Encoding Rules (CER) and Distinguished Encoding >> Rules >> > > > > > > (DER)", ITU-T Recommendation X690, ISO/IEC >> 8825-1:2021, >> > > > > > > February 2021. >> > > > > > > --> >> > > > > > > >> > > > > > > Sounds good. >> > > > > > > >> > > > > > > Thank you. >> > > > > > > >> > > > > > > RFC Editor/ap/jm >> > > > > > > >> > > > > > > >> > > > > > > On 1/31/25 2:14 PM, rfc-edi...@rfc-editor.org wrote: >> > > > > > > *****IMPORTANT***** >> > > > > > > >> > > > > > > Updated 2025/01/31 >> > > > > > > >> > > > > > > RFC Author(s): >> > > > > > > -------------- >> > > > > > > >> > > > > > > Instructions for Completing AUTH48 >> > > > > > > >> > > > > > > Your document has now entered AUTH48. Once it has been >> reviewed and >> > > > > > > approved by you and all coauthors, it will be published as an >> RFC. >> > > > > > > If an author is no longer available, there are several >> remedies >> > > > > > > available as listed in the FAQ ( >> https://www.rfc-editor.org/faq/). >> > > > > > > >> > > > > > > You and you coauthors are responsible for engaging other >> parties >> > > > > > > (e.g., Contributors or Working Group) as necessary before >> providing >> > > > > > > your approval. >> > > > > > > >> > > > > > > Planning your review >> > > > > > > --------------------- >> > > > > > > >> > > > > > > Please review the following aspects of your document: >> > > > > > > >> > > > > > > * RFC Editor questions >> > > > > > > >> > > > > > > Please review and resolve any questions raised by the RFC >> Editor >> > > > > > > that have been included in the .md file as comments marked >> as >> > > > > > > follows: >> > > > > > > >> > > > > > > <!-- [rfced] ... --> >> > > > > > > >> > > > > > > These questions will also be sent in a subsequent email. >> > > > > > > >> > > > > > > * Changes submitted by coauthors >> > > > > > > >> > > > > > > Please ensure that you review any changes submitted by >> your >> > > > > > > coauthors. We assume that if you do not speak up that you >> > > > > > > agree to changes submitted by your coauthors. >> > > > > > > >> > > > > > > * Content >> > > > > > > >> > > > > > > Please review the full content of the document, as this >> cannot >> > > > > > > change once the RFC is published. Please pay particular >> attention to: >> > > > > > > - IANA considerations updates (if applicable) >> > > > > > > - contact information >> > > > > > > - references >> > > > > > > >> > > > > > > * Copyright notices and legends >> > > > > > > >> > > > > > > Please review the copyright notice and legends as defined >> in >> > > > > > > RFC 5378 and the Trust Legal Provisions >> > > > > > > (TLP – https://trustee.ietf.org/license-info). >> > > > > > > >> > > > > > > * Semantic markup >> > > > > > > >> > > > > > > Please review the markup in the XML file to ensure that >> elements of >> > > > > > > content are correctly tagged. For example, ensure that >> <sourcecode> >> > > > > > > and <artwork> are set correctly. See details at >> > > > > > > <https://authors.ietf.org/rfcxml-vocabulary>. >> > > > > > > >> > > > > > > * Formatted output >> > > > > > > >> > > > > > > Please review the PDF, HTML, and TXT files to ensure that >> the >> > > > > > > formatted output, as generated from the markup in the XML >> file, is >> > > > > > > reasonable. Please note that the TXT will have formatting >> > > > > > > limitations compared to the PDF and HTML. >> > > > > > > >> > > > > > > >> > > > > > > Submitting changes >> > > > > > > ------------------ >> > > > > > > >> > > > > > > To submit changes, please reply to this email using ‘REPLY >> ALL’ as all >> > > > > > > the parties CCed on this message need to see your changes. >> The parties >> > > > > > > include: >> > > > > > > >> > > > > > > * your coauthors >> > > > > > > >> > > > > > > * rfc-edi...@rfc-editor.org (the RPC team) >> > > > > > > >> > > > > > > * other document participants, depending on the stream >> (e.g., >> > > > > > > IETF Stream participants are your working group chairs, >> the >> > > > > > > responsible ADs, and the document shepherd). >> > > > > > > >> > > > > > > * auth48archive@rfc-editor.org, which is a new archival >> mailing list >> > > > > > > to preserve AUTH48 conversations; it is not an active >> discussion >> > > > > > > list: >> > > > > > > >> > > > > > > * More info: >> > > > > > > >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> > > > > > > >> > > > > > > * The archive itself: >> > > > > > > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> > > > > > > >> > > > > > > * Note: If only absolutely necessary, you may >> temporarily opt out >> > > > > > > of the archiving of messages (e.g., to discuss a >> sensitive matter). >> > > > > > > If needed, please add a note at the top of the >> message that you >> > > > > > > have dropped the address. When the discussion is >> concluded, >> > > > > > > auth48archive@rfc-editor.org will be re-added to the >> CC list and >> > > > > > > its addition will be noted at the top of the message. >> > > > > > > >> > > > > > > You may submit your changes in one of two ways: >> > > > > > > >> > > > > > > An update to the provided .md file >> > > > > > > — OR — >> > > > > > > An explicit list of changes in this format >> > > > > > > >> > > > > > > Section # (or indicate Global) >> > > > > > > >> > > > > > > OLD: >> > > > > > > old text >> > > > > > > >> > > > > > > NEW: >> > > > > > > new text >> > > > > > > >> > > > > > > You do not need to reply with both an updated file and an >> explicit >> > > > > > > list of changes, as either form is sufficient. >> > > > > > > >> > > > > > > We will ask a stream manager to review and approve any >> changes that seem >> > > > > > > beyond editorial in nature, e.g., addition of new text, >> deletion of text, >> > > > > > > and technical changes. Information about stream managers can >> be found in >> > > > > > > the FAQ. Editorial changes do not require approval from a >> stream manager. >> > > > > > > >> > > > > > > >> > > > > > > Approving for publication >> > > > > > > -------------------------- >> > > > > > > >> > > > > > > This document is being edited in kramdown-rfc markdown. Once >> the content >> > > > > > > is approved, the markdown will be converted to RFCXML and >> formatted as an >> > > > > > > RFC. You will be asked to review and approve the XML and >> output formats. >> > > > > > > Your final approval means you approve both the content and >> format. >> > > > > > > >> > > > > > > To approve your RFC for publication, please reply to this >> email stating >> > > > > > > that you approve this RFC for publication. Please use ‘REPLY >> ALL’, >> > > > > > > as all the parties CCed on this message need to see your >> approval. >> > > > > > > >> > > > > > > >> > > > > > > Files >> > > > > > > ----- >> > > > > > > >> > > > > > > The files are available here: >> > > > > > > https://www.rfc-editor.org/authors/rfc9729.md >> > > > > > > https://www.rfc-editor.org/authors/rfc9729.html >> > > > > > > https://www.rfc-editor.org/authors/rfc9729.pdf >> > > > > > > https://www.rfc-editor.org/authors/rfc9729.txt >> > > > > > > >> > > > > > > Diff file of the text: >> > > > > > > https://www.rfc-editor.org/authors/rfc9729-diff.html >> > > > > > > https://www.rfc-editor.org/authors/rfc9729-rfcdiff.html >> (side by side) >> > > > > > > >> > > > > > > Diff of the markdown: >> > > > > > > https://www.rfc-editor.org/authors/rfc9729-mdrfcdiff.html >> > > > > > > >> > > > > > > >> > > > > > > Tracking progress >> > > > > > > ----------------- >> > > > > > > >> > > > > > > The details of the AUTH48 status of your document are here: >> > > > > > > https://www.rfc-editor.org/auth48/rfc9729 >> > > > > > > >> > > > > > > Please let us know if you have any questions. >> > > > > > > >> > > > > > > Thank you for your cooperation, >> > > > > > > >> > > > > > > RFC Editor >> > > > > > > >> > > > > > > -------------------------------------- >> > > > > > > RFC9729 (draft-ietf-httpbis-unprompted-auth-12) >> > > > > > > >> > > > > > > Title : The Concealed HTTP Authentication Scheme >> > > > > > > Author(s) : D. Schinazi, D. Oliver, J. Hoyland >> > > > > > > WG Chair(s) : Mark Nottingham, Tommy Pauly >> > > > > > > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini >> > > > > > > >> > > > > > > >> > > > > > >> > > > >> > > >> > >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
