Hello Martine, Thank you for your reply. We have noted your approval of the document format on the AUTH48 page (https://www.rfc-editor.org/auth48/rfc9952). Note: Please refresh to access the lastdiff files.
We now await approval of the document format (i.e., the XML file and its outputs) from Christian, Thomas, and Matthias. —Files (please refresh)— XML file: https://www.rfc-editor.org/authors/rfc9952.xml Output files: https://www.rfc-editor.org/authors/rfc9952.html https://www.rfc-editor.org/authors/rfc9952.pdf https://www.rfc-editor.org/authors/rfc9952.txt Lastdiff of the text (shows only the format changes): https://www.rfc-editor.org/authors/rfc9952-lastdiff.html https://www.rfc-editor.org/authors/rfc9952-rfclastdiff.html (side by side) Comprehensive diff file of the text: https://www.rfc-editor.org/authors/rfc9952-diff.html https://www.rfc-editor.org/authors/rfc9952-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9952 Thank you, Karen Moore RFC Production Center > On Mar 21, 2026, at 3:18 AM, Martine Sophie Lenders > <[email protected]> wrote: > > Hi everyone, > > from what I can see from my own diff (find attached; sadly the lastdiff links > lead to a 404), there are only comments and removeInRFC-attributed tags > stripped, references imported from https://bib.ietf.org/, and the reference > PRE-RFC9953 renamed to RFC9953 in the new XML. This results in the expected > changes in the HTML and TXT outputs (links and and reference names change, > some CSS in HTML changes non-breakingly, diff not attached). I did not look > into the changes of the PDF in detail, as the default output of the GitHub > Tooling is completely different (based on the TXT while the RFC editor output > is based on the HTML). However, based on the fact that all three output file > formats should be derived from the same XML, I trust that the PDF output also > aligns with the TXT and HTML. > > As such, I approve the format. > > Best > Martine > > On 3/21/26 00:32, Karen Moore wrote: >> Hello authors, >> We have converted the kramdown-rfc file to RFCXML. Note that there is a >> placeholder for RFC-to-be 9953 since it will move forward in the publication >> process with this document once it has completed AUTH48. >> Please review the XML file and its TXT, HTML, and PDF outputs, and let us >> know if any changes are required or if you approve the RFC for publication. >> While this is your approval of the XML and its outputs, we consider this >> your final assent that the document is ready for publication. To request >> changes or approve your RFC for publication, please reply to this email. >> Please use ‘REPLY ALL’, as all the parties CCed on this message need to see >> your approval. >> Note that we will only make changes in the XML file from this point on. >> XML file: >> https://www.rfc-editor.org/authors/rfc9952.xml >> Output files: >> https://www.rfc-editor.org/authors/rfc9952.html >> https://www.rfc-editor.org/authors/rfc9952.pdf >> https://www.rfc-editor.org/authors/rfc9952.txt >> Lastdiff of the text (shows only the format changes): >> https://www.rfc-editor.org/authors/rfc9952-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9952-rfclastdiff.html (side by side) >> Comprehensive diff file of the text: >> https://www.rfc-editor.org/authors/rfc9952-diff.html >> https://www.rfc-editor.org/authors/rfc9952-rfcdiff.html (side by side) >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9952 >> Thank you, >> Karen Moore >> RFC Production Center >>> On Mar 19, 2026, at 5:51 PM, Karen Moore <[email protected]> >>> wrote: >>> >>> Hi Mike, >>> >>> Thank you for your review. We have noted your approval on the AUTH48 >>> status page (https://www.rfc-editor.org/auth48/rfc9952). >>> >>> Authors, now that we have received all necessary approvals of the content, >>> we will be proceeding with Part 2 of AUTH48; we will contact you shortly >>> regarding the format of the XML and output files. >>> >>> Best regards, >>> >>> Karen Moore >>> RFC Production Center >>> >>>> On Mar 18, 2026, at 1:43 PM, Mike Bishop <[email protected]> wrote: >>>> >>>> Approved. Thank you for your work on this, everyone! >>>> >>>> >>>> From: Karen Moore <[email protected]> >>>> Sent: Wednesday, March 18, 2026 2:09:27 PM >>>> To: Mike Bishop <[email protected]>; Martine Sophie Lenders >>>> <[email protected]>; Matthias Waehlisch >>>> <[email protected]>; [email protected] >>>> <[email protected]>; [email protected] >>>> <[email protected]> >>>> Cc: [email protected] <[email protected]>; >>>> [email protected] <[email protected]>; [email protected] >>>> <[email protected]>; [email protected] <[email protected]>; >>>> [email protected] <[email protected]> >>>> Subject: [AD] Re: [auth48] AUTH48: RFC-to-be 9952 >>>> <draft-ietf-core-coap-dtls-alpn-05> for your review Dear Martine, >>>> Thomas, Matthias, Christian, and *Mike (AD), >>>> >>>> Thank you for your replies. We have noted all of your approvals on the >>>> AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9952). Once Mike >>>> approves the beyond editorial changes, we will contact you regarding >>>> approving the format of the document. >>>> >>>> *Mike, as AD, please review the text added to the Acknowledgements section >>>> and let us know if you approve. The change can be viewed here: >>>> <https://www.rfc-editor.org/authors/rfc9953-auth48diff.html>. >>>> >>>> >>>> —Files (please refresh)— >>>> >>>> For details of the AUTH48 process in kramdown-rfc (including the two-part >>>> approval process), see >>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. >>>> >>>> Updated MD file: >>>> https://www.rfc-editor.org/authors/rfc9952.md >>>> >>>> Updated output files: >>>> https://www.rfc-editor.org/authors/rfc9952.html >>>> https://www.rfc-editor.org/authors/rfc9952.pdf >>>> https://www.rfc-editor.org/authors/rfc9952.txt >>>> >>>> Diff files of the text: >>>> https://www.rfc-editor.org/authors/rfc9952-diff.html (all changes) >>>> https://www.rfc-editor.org/authors/rfc9952-rfcdiff.html (all changes side >>>> by side) >>>> https://www.rfc-editor.org/authors/rfc9952-auth48diff.html (AUTH48 changes) >>>> https://www.rfc-editor.org/authors/rfc9952-auth48rfcdiff.html (AUTH48 >>>> changes side by side) >>>> >>>> Diff files of the kramdown: >>>> https://www.rfc-editor.org/authors/rfc9952-md-diff.html (all changes) >>>> https://www.rfc-editor.org/authors/rfc9952-md-rfcdiff.html (all changes >>>> side by side) >>>> https://www.rfc-editor.org/authors/rfc9952-md-auth48diff.html (AUTH48 >>>> changes) >>>> https://www.rfc-editor.org/authors/rfc9952-md-auth48rfcdiff.html (AUTH48 >>>> changes side by side) >>>> >>>> Best regards, >>>> >>>> Karen Moore >>>> RFC Production Center >>>> >>>>> On Mar 17, 2026, at 10:55 PM, Martine Sophie Lenders >>>>> <[email protected]> wrote: >>>>> >>>>> Hi Karen and team, >>>>> >>>>> thanks for processing this. >>>>> >>>>> The current version looks good to. I approve of the publication. >>>>> >>>>> Best >>>>> Martine >>>>> >>>>> On 3/17/26 22:21, Karen Moore wrote: >>>>>> Hi Martine, >>>>>> Thank you for your reply. We have updated our files accordingly. Note >>>>>> that we marked “CoAP” as well known on the Abbreviations List >>>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list> and >>>>>> removed the expansion from the title. Please review and let us know if >>>>>> any further changes are needed or if you approve the document in its >>>>>> current form. >>>>>> Note that we will await approvals from each author prior to moving >>>>>> forward with formatting updates. >>>>>> —Files— >>>>>> Note that it may be necessary for you to refresh your browser to view >>>>>> the most recent version. Please review the contents of the document >>>>>> carefully as we do not make changes once it has been published as an RFC. >>>>>> For details of the AUTH48 process in kramdown-rfc (including the >>>>>> two-part approval process), see >>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. >>>>>> Updated MD file: >>>>>> https://www.rfc-editor.org/authors/rfc9952.md >>>>>> Updated output files: >>>>>> https://www.rfc-editor.org/authors/rfc9952.html >>>>>> https://www.rfc-editor.org/authors/rfc9952.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9952.txt >>>>>> Diff files of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9952-diff.html (all changes) >>>>>> https://www.rfc-editor.org/authors/rfc9952-rfcdiff.html (all changes >>>>>> side by side) >>>>>> https://www.rfc-editor.org/authors/rfc9952-auth48diff.html (AUTH48 >>>>>> changes) >>>>>> https://www.rfc-editor.org/authors/rfc9952-auth48rfcdiff.html (AUTH48 >>>>>> changes side by side) >>>>>> Diff files of the kramdown: >>>>>> https://www.rfc-editor.org/authors/rfc9952-md-diff.html (all changes) >>>>>> https://www.rfc-editor.org/authors/rfc9952-md-rfcdiff.html (all changes >>>>>> side by side) >>>>>> https://www.rfc-editor.org/authors/rfc9952-md-auth48diff.html (AUTH48 >>>>>> changes) >>>>>> https://www.rfc-editor.org/authors/rfc9952-md-auth48rfcdiff.html (AUTH48 >>>>>> changes side by side) >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9952 >>>>>> Best regards, >>>>>> Karen Moore >>>>>> RFC Production Center >>>>>>> On Mar 16, 2026, at 4:25 PM, Martine Sophie Lenders via auth48archive >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Dear RFC editor team, >>>>>>> >>>>>>> sorry for the late reply. Find our answers and additional requests >>>>>>> inline. >>>>>>> >>>>>>> On 3/6/26 04:05, [email protected] wrote: >>>>>>>> Authors, >>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>> necessary) the following questions, which are also in the source file. >>>>>>>> 1) <!-- [rfced] FYI - We updated [I-D.ietf-core-dns-over-coap] to >>>>>>>> [PRE-RFC9953] >>>>>>>> for now. We will make the final updates in RFCXML (i.e., remove >>>>>>>> "PRE-"). >>>>>>>> --> >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>>> 2) <!--[rfced] Author Names >>>>>>>> a) Thomas, we note "T. C. Schmidt" in the document header; however, the >>>>>>>> majority of past RFCs have used "T. Schmidt". Which form do you prefer? >>>>>>> >>>>>>> From Thomas offline: I prefer "T. C. Schmidt". >>>>>>> >>>>>>>> b) Martine, please confirm if you prefer "M. S. Lenders" or "M. >>>>>>>> Lenders" >>>>>>>> in the document header. >>>>>>>> Note that we will apply your responses to both this document and >>>>>>>> RFC-to-be 9953. >>>>>>>> --> >>>>>>> >>>>>>> Yes, I prefer "M. S. Lenders". Please also make sure, that my initials >>>>>>> are spelled out as "M. S. Lenders" in the "[DoC-paper]" reference of >>>>>>> RFC-to-be 9953. As far as I can tell, this is already the case for >>>>>>> IETF-internal references, but please check also in the other references. >>>>>>> >>>>>>>> 3) <!--[rfced] Document Title >>>>>>>> a) Please note that the document title has been updated as follows. >>>>>>>> Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC >>>>>>>> Style >>>>>>>> Guide"). >>>>>>>> In addition, is "Specification" essential to the title or may it be >>>>>>>> removed >>>>>>>> for conciseness? >>>>>>>> Original (document title): >>>>>>>> ALPN ID Specification for CoAP over DTLS >>>>>>>> Current: >>>>>>>> The Application-Layer Protocol Negotiation (ALPN) ID Specification >>>>>>>> for >>>>>>>> the Constrained Application Protocol (CoAP) over DTLS >>>>>>>> Perhaps: >>>>>>>> Application-Layer Protocol Negotiation (ALPN) ID for >>>>>>>> the Constrained Application Protocol (CoAP) over DTLS >>>>>>> >>>>>>> Please consider CoAP for inclusion in the list of abbreviations that >>>>>>> are well-known >>>>>>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list). There >>>>>>> have been over 20 RFCs in which it has been expanded, exceeding (for >>>>>>> example) the number of published documents on the well-known 6LoWPAN. >>>>>>> For people only tangentially familiar with the topic (say, someone >>>>>>> coming from competing technologies), chances are they are even *more* >>>>>>> familiar with the acronym than the expansion. >>>>>>> >>>>>>> This document would be a particularly good starting point for treating >>>>>>> it as well-known because the document is of no use to anyone who is not >>>>>>> already familiar with CoAP. Our preferred title would be >>>>>>> >>>>>>> Application-Layer Protocol Negotiation (ALPN) ID for CoAP over DTLS >>>>>>> >>>>>>> If that is really no option, we like the second proposal better. >>>>>>> >>>>>>> Application-Layer Protocol Negotiation (ALPN) ID for the Constrained >>>>>>> Application Protocol (CoAP) over DTLS >>>>>>> >>>>>>> See also >>>>>>> https://mailarchive.ietf.org/arch/msg/auth48archive/jNx8TbolOmUX39l-Hgq2BRNmuV4/ >>>>>>> >>>>>>>> b) For the short title that spans the header of the PDF file, should >>>>>>>> "CoRE >>>>>>>> ALPN" be updated to "ALPN ID for CoAP over DTLS" to more closely match >>>>>>>> the >>>>>>>> document title? >>>>>>>> Original (short title): >>>>>>>> CoRE ALPN >>>>>>>> Perhaps: >>>>>>>> ALPN ID for CoAP over DTLS >>>>>>>> --> >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>>> 4) <!-- [rfced] Abstract: Should the abstract mention DTLS? >>>>>>>> Original: >>>>>>>> This document specifies an Application-Layer Protocol Negotiation >>>>>>>> (ALPN) ID for transport-layer-secured Constrained Application >>>>>>>> Protocol (CoAP) services. >>>>>>>> Perhaps (similar to text in the Introduction): >>>>>>>> This document specifies an Application-Layer Protocol Negotiation >>>>>>>> (ALPN) ID for Constrained Application >>>>>>>> Protocol (CoAP) services that are secured by DTLS. >>>>>>>> --> >>>>>>> >>>>>>> ACK. >>>>>>> >>>>>>>> 5) <!-- [rfced] Introduction: We updated "by transport layer security >>>>>>>> using DTLS" >>>>>>>> to "by TLS using DTLS" here. Would further updating as shown below >>>>>>>> improve >>>>>>>> this sentence? >>>>>>>> Original: >>>>>>>> This document >>>>>>>> specifies an ALPN ID for CoAP services that are secured by transport >>>>>>>> layer security using DTLS. >>>>>>>> Current: >>>>>>>> This document >>>>>>>> specifies an ALPN ID for CoAP services that are secured by TLS >>>>>>>> using DTLS. >>>>>>>> Perhaps: >>>>>>>> This document >>>>>>>> specifies an ALPN ID for CoAP services that are secured >>>>>>>> by DTLS. >>>>>>>> --> >>>>>>> >>>>>>> Please use the "Perhaps" version since the text in the "Current" >>>>>>> version is technically incorrect. >>>>>>> >>>>>>>> 6) <!--[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. >>>>>>>> Note that our script did not flag any words in particular, but this >>>>>>>> should >>>>>>>> still be reviewed as a best practice. >>>>>>>> --> >>>>>>> >>>>>>> Thanks! To the best of our abilities, we did not find any potentially >>>>>>> remaining non-inclusive wordings in the document. >>>>>>> >>>>>>> -------------------------------------- >>>>>>> >>>>>>> ## Additional Requests >>>>>>> >>>>>>> Please append the following sentence to the acknowledgements: >>>>>>> >>>>>>>> This work was supported in parts by the German Federal Ministry of >>>>>>>> Research, Technology, and Space (BMFTR) under the grant numbers >>>>>>>> 16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the >>>>>>>> research project PIVOT and under the grant numbers 16KIS1694K (TU >>>>>>>> Dresden) and 16KIS1695 (HAW Hamburg) within the research project >>>>>>>> C-ray4edge. >>>>>>> >>>>>>>> Thank you. >>>>>>> >>>>>>> Thank you! >>>>>>> Martine >>>>>>> >>>>>>>> Karen Moore and Rebecca VanRheenen >>>>>>>> RFC Production Center >>>>>>>> On Mar 5, 2026, at 6:59 PM, [email protected] wrote: >>>>>>>> *****IMPORTANT***** >>>>>>>> Updated 2026/03/05 >>>>>>>> RFC Author(s): >>>>>>>> -------------- >>>>>>>> Your document has now entered AUTH48. >>>>>>>> The document was edited in kramdown-rfc as part of the RPC pilot test >>>>>>>> (see >>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc) >>>
--- rfc9952-md-gen.xml 2026-03-21 10:58:30.719256310 +0100 +++ rfc9952-rfc-ed.xml 2026-03-21 10:58:50.107334876 +0100 @@ -1,14 +1,13 @@ -<?xml version='1.0' encoding='utf-8'?> +<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> -<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.32 (Ruby 3.4.8) --> + <rfc xmlns:xi="http://www.w3.org/2001/XInclude"; ipr="trust200902" docName="draft-ietf-core-coap-dtls-alpn-05" category="info" consensus="true" submissionType="IETF" number="9952" tocInclude="true" sortRefs="true" symRefs="true" version="3"> - <!-- xml2rfc v2v3 conversion 3.32.0 --> + <link href="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn-05"; rel="prev"/> <front> <title abbrev="ALPN ID for CoAP over DTLS">Application-Layer Protocol Negotiation (ALPN) ID for CoAP over DTLS</title> @@ -66,47 +65,9 @@ <abstract> <?line 87?> -<!-- [rfced] FYI - We updated [I-D.ietf-core-dns-over-coap] to [PRE-RFC9953] -for now. We will make the final updates in RFCXML (i.e., remove "PRE-"). ---> - -<!-- [I-D.ietf-core-dns-over-coap] - RFC 9953 -draft-ietf-core-dns-over-coap-20 -Companion document (C554) ---> - -<!--[rfced] Document Title - -a) Please note that the document title has been updated as follows. -Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style -Guide"). - -In addition, is "Specification" essential to the title or may it be removed -for conciseness? - -Original (document title): - ALPN ID Specification for CoAP over DTLS - -Current: - The Application-Layer Protocol Negotiation (ALPN) ID Specification for - the Constrained Application Protocol (CoAP) over DTLS - -Perhaps: - Application-Layer Protocol Negotiation (ALPN) ID for - the Constrained Application Protocol (CoAP) over DTLS ---> - <t>This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for Constrained Application Protocol (CoAP) services that are secured by DTLS.</t> </abstract> - <note removeInRFC="true"> - <name>Discussion Venues</name> - <t>Discussion of this document takes place on the - Constrained RESTful Environments Working Group mailing list ([email protected]), - which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/core/"/>.</t> - <t>Source for this draft and an issue tracker can be found at - <eref target="https://github.com/core-wg/coap-dtls-alpn"/>.</t> - </note> </front> <middle> <?line 122?> @@ -115,7 +76,7 @@ <name>Introduction</name> <t>Application-Layer Protocol Negotiation (ALPN) enables communicating parties to agree on an application-layer protocol during a Transport Layer Security (TLS) handshake using an ALPN ID <xref target="RFC7301"/>. This ALPN ID can be discovered for services as part of Service Bindings (SVCBs) via the DNS, using SVCB resource records with the "alpn" Service Parameter Keys <xref target="RFC9460"/>. -As an example, applications that use the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> can obtain this information as part of the discovery of DNS over CoAP (DoC) servers (see <xref section="3.2" sectionFormat="of" target="PRE-RFC9953"/>) that deploy TLS 1.3 <xref target="RFC8446"/> as well as Datagram Transport Layer Security (DTLS) 1.2 or 1.3 <xref target="RFC6347"/> <xref target="RFC9147"/> to secure their messages. +As an example, applications that use the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> can obtain this information as part of the discovery of DNS over CoAP (DoC) servers (see <xref section="3.2" sectionFormat="of" target="RFC9953"/>) that deploy TLS 1.3 <xref target="RFC8446"/> as well as Datagram Transport Layer Security (DTLS) 1.2 or 1.3 <xref target="RFC6347"/> <xref target="RFC9147"/> to secure their messages. This document specifies an ALPN ID for CoAP services that are secured by DTLS. An ALPN ID for CoAP services secured by TLS has already been specified in <xref target="RFC8323"/>.</t> </section> @@ -165,116 +126,24 @@ <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> - <reference anchor="RFC6347"> - <front> - <title>Datagram Transport Layer Security Version 1.2</title> - <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> - <author fullname="N. Modadugu" initials="N." surname="Modadugu"/> - <date month="January" year="2012"/> - <abstract> - <t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t> - </abstract> - </front> - <seriesInfo name="RFC" value="6347"/> - <seriesInfo name="DOI" value="10.17487/RFC6347"/> - </reference> - <reference anchor="RFC7252"> - <front> - <title>The Constrained Application Protocol (CoAP)</title> - <author fullname="Z. Shelby" initials="Z." surname="Shelby"/> - <author fullname="K. Hartke" initials="K." surname="Hartke"/> - <author fullname="C. Bormann" initials="C." surname="Bormann"/> - <date month="June" year="2014"/> - <abstract> - <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t> - <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t> - </abstract> - </front> - <seriesInfo name="RFC" value="7252"/> - <seriesInfo name="DOI" value="10.17487/RFC7252"/> - </reference> - <reference anchor="RFC7301"> - <front> - <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title> - <author fullname="S. Friedl" initials="S." surname="Friedl"/> - <author fullname="A. Popov" initials="A." surname="Popov"/> - <author fullname="A. Langley" initials="A." surname="Langley"/> - <author fullname="E. Stephan" initials="E." surname="Stephan"/> - <date month="July" year="2014"/> - <abstract> - <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t> - </abstract> - </front> - <seriesInfo name="RFC" value="7301"/> - <seriesInfo name="DOI" value="10.17487/RFC7301"/> - </reference> - <reference anchor="RFC9147"> - <front> - <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title> - <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> - <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> - <author fullname="N. Modadugu" initials="N." surname="Modadugu"/> - <date month="April" year="2022"/> - <abstract> - <t>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> - <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t> - <t>This document obsoletes RFC 6347.</t> - </abstract> - </front> - <seriesInfo name="RFC" value="9147"/> - <seriesInfo name="DOI" value="10.17487/RFC9147"/> - </reference> - <reference anchor="RFC9460"> - <front> - <title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title> - <author fullname="B. Schwartz" initials="B." surname="Schwartz"/> - <author fullname="M. Bishop" initials="M." surname="Bishop"/> - <author fullname="E. Nygren" initials="E." surname="Nygren"/> - <date month="November" year="2023"/> - <abstract> - <t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.</t> - </abstract> - </front> - <seriesInfo name="RFC" value="9460"/> - <seriesInfo name="DOI" value="10.17487/RFC9460"/> - </reference> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> - <reference anchor="RFC8323"> - <front> - <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title> - <author fullname="C. Bormann" initials="C." surname="Bormann"/> - <author fullname="S. Lemay" initials="S." surname="Lemay"/> - <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> - <author fullname="K. Hartke" initials="K." surname="Hartke"/> - <author fullname="B. Silverajan" initials="B." surname="Silverajan"/> - <author fullname="B. Raymor" initials="B." role="editor" surname="Raymor"/> - <date month="February" year="2018"/> - <abstract> - <t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t> - <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t> - </abstract> - </front> - <seriesInfo name="RFC" value="8323"/> - <seriesInfo name="DOI" value="10.17487/RFC8323"/> - </reference> - <reference anchor="RFC8446"> - <front> - <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> - <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> - <date month="August" year="2018"/> - <abstract> - <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> - <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> - </abstract> - </front> - <seriesInfo name="RFC" value="8446"/> - <seriesInfo name="DOI" value="10.17487/RFC8446"/> - </reference> - <reference anchor="PRE-RFC9953" target="https://www.rfc-editor.org/info/rfc9953";> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> + +<!-- [I-D.ietf-core-dns-over-coap] - RFC 9953 +draft-ietf-core-dns-over-coap-20 +Companion document (C554) +--> + <reference anchor="RFC9953" target="https://www.rfc-editor.org/info/rfc9953";> <front> - <title>DNS over the Constrained Application Protocol (DoC)</title> + <title>DNS over CoAP (DoC)</title> <author fullname="Martine Sophie Lenders"> <organization/> </author> @@ -292,24 +161,10 @@ </author> <date year="2026" month="March"/> </front> - <seriesInfo name="RFC" value="PRE-9953"/> - <seriesInfo name="DOI" value="10.17487/PRE-RFC9953"/> - </reference> - <reference anchor="RFC4944"> - <front> - <title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title> - <author fullname="G. Montenegro" initials="G." surname="Montenegro"/> - <author fullname="N. Kushalnagar" initials="N." surname="Kushalnagar"/> - <author fullname="J. Hui" initials="J." surname="Hui"/> - <author fullname="D. Culler" initials="D." surname="Culler"/> - <date month="September" year="2007"/> - <abstract> - <t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t> - </abstract> - </front> - <seriesInfo name="RFC" value="4944"/> - <seriesInfo name="DOI" value="10.17487/RFC4944"/> + <seriesInfo name="RFC" value="9953"/> + <seriesInfo name="DOI" value="10.17487/RFC9953"/> </reference> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/> </references> </references> <?line 162?> @@ -322,64 +177,4 @@ <t>This work was supported in parts by the German Federal Ministry of Research, Technology, and Space (BMFTR) under the grant numbers 16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the research project PIVOT and under the grant numbers 16KIS1694K (TU Dresden) and 16KIS1695 (HAW Hamburg) within the research project C-ray4edge.</t> </section> </back> - <!-- ##markdown-source: -H4sIAAAAAAAAA7VY3XLbuBW+51OgykzHmjEZWbLlWNNuI1txVhPb8VjKpp1M -LiASkrCmCC4AWlEcP0tv+hh7lz5YvwOQtORV3Did+sKSQOCc7/x954BhGAZW -2lT0WKOf56mMuZUqC8/4Smh2qZVVsUrZhZgpK90jttM/u7xosuGATZVmJ6p/ -ydQNNg/GZ6NGwCcTLW5IGnZ9axOUQKBe9ZjMpioIEhVnfAEMieZTG0php2Gs -tMA/noeJTU3I0zwLWweBKSYLaQyA2FWOE8NX49MgKxYToXvs6OigHRR5AvGm -F6iJUalwX2OVGZGZwvSY1YUIZK7dN2PbrdZRqx3kssc+wNZdZlYLLaYGX5S2 -9O1jQPJ6rN1qd8NWJ4BxnYBrwXvs/XAcLJW+nmlV5D1GkINrscJS0gtYCLuv -XvnP/iV9jn45OaZP8gJ9ko+CIOCFnSvtTrBpkabeF+dcW5kJNlL5XAp2JrJE -aBMw/Ck967HxuwEbaGESkbF3mYR3jbQrpqZsLOJ5plI1W7ndVUjG76r9btnA -OmF77GeRLuYqtZ+xELG9lnsYQ1RvY3usEoAahK29VveoXCkyS0F8LfSCZ16Z -WHCZ9tjCg49Sj/qlLcLEC4sS4Qz1Rp7MtTTIrIz1F+br78asC4mrhy/5whTC -mChWiwdeGs/Vght2ErFRPF/IxFYO4pn87BIWFvbfs5/5YlLo2Yblx0KnAKnZ -GDl6uGb3+ubKbkqU/263jYyH8XLOl+Hcy9k0+ZxbO5fA/P7rv+apxP6nxZT9 -mR1zfT3nBVKaDTN4yBb2G5F+ZPP/N/7Rkgtv3YPYB5nCbgvbkPDs6vSk29k/ -ROWjyPfafuWwfdCmauJ5+bvT2usxYgD/+2ivPtEpV/a7rR4zN/EkCIhSNjW8 -6LQ7Xl5o41Lmi/39LsLlRDxjbBgOonvaSTITEl05/oEmFePQ5dWrkFQdHXR6 -ztSwesJYSaE/uR/0N7gYecKzc4Hyh981R6olbI1k7+l1Z6BOml4Q1zMKytza -3PSeP18ul5GexqFIpFU6QpI8J/ueY42A+EAKLYWh5V6tH0B7DnG9y6F6O+wh -wtHe4f6Lw+drBrkdnuZAO/HckZ1PqYqbyOBa0Hex1Lbt2+t9606RXbPXX3/P -EvXvf/Lsm/u2E8B2qFsKDw7YP9rf77FuikYUhGGIKqJoxTYI/vIn/PwAX4vk -Izv9xxBF/F4w32AS9uGRpPnIrGIf1jz8MaBGmKllRCKWMk3BkdfC5cdUZjwt -xRq0RAL19/MztiMjEe0yLRaQyxokrdGMgPGnCtqjCEKSw1x4H/bVjZ2gtuBE -LXIwJpISKV0sRGbZzsnBwX7zXlvlh0G1YUxJj+7VZJep4EbAOksGceusqgW5 -4mBzOH4iQEKV+/B7qtJULU0U9B1x+QHDYCvMdXvFJ6BKsDlHKY1E7MqmE3WJ -Ecm4w067zXYa9HVkV0DzupCJICcFw4zxBFWDE7tMGtYY5SKW07L2GgztBOAk -HI9IEV4PE0Fa8BWTFgBKzycudBghYokjOPe3IHir5cxFbWfTzKarlGr22VC5 -ZRIKgpNCaxx2p8YA8eQZ7A8qSNL3kQ5haa6DuRR6zkE7zoQfGAZ/XLVLsvEc -YardabxhKAgiix9B870wwJ83MoYil7qY7LASFxqnJisHL/K8AHJJKOGfoY9a -rZLCpWMQPA2cyPgkhTKMMosic+eyGcuJRgmCYnyGvsxwAHbzNdGpE51XopNC -00HOxppnJsewyrzyEYGnqWEH0Jsopiwxc6KawrgDWZ2et7durL67i7zvq/UY -e5D9CSiSQgRHUOrWbkLhElyqwZFfY8cySyDcsB0acU2ToZZdKqAP7paK6Qkq -yqhCx1RaIKLEgAnt3O1sEJRGLfGSa5C2hT1vxMoQVOruBLXvMkJ84os8Fbvr -LiojiFHnSWkI2USDd3fOcDWxOAIB0rB6lKBo3Fvt2K10jhvO6m7vytt1c+cu -dEK2YxDN29t78mrTiRB5fnfX9IATkadqxRAuthd1CI+bSwAISpcCrQKfA26R -GXzxSLwHLuB7pEFXkvxcBVHVdxKLLPMpTqZIMB5Ijc+EiR6twYcXuu+om/5j -x9Z2k+nUIHiKe1Wy8uRfaU+oJZZBogGOkgBF+FROMEFwusHAULq7bhhZLqYu -XQClQeoaW1Qj/9AdsBntDi3mRhoqaPKpFlXqGeTuhuUcCTOdCu0aRR1AV9L3 -GDxprTcIUqPFDCOTK0MHBsMTdy6o5N/wFJcj3zVvuJYODi5eMzuPHpg88DYz -Myf17iDaZ6waTdLE0Y3pap7skgNcBVBF8BslQQGazygpvFeRwiepJGtwfUhB -WlniShc6/EKVUoQ5XivETFi6MZeFj+vXdUlsG/Jx+y4whQJF90y9v+xfUBAw -oTm7x6quvm2JuDWzvTryqKq8QHEqXVhHm8wgd1QUiHgmNIBRKtKFIl1hlsiC -OsS49tD90Y0y+MjABnhWc2Wd4pV2cmyQCBNrOanzuiK28UNa2WKcBgTqDZWa -svQXuB1ifDMLQ3FURU1TkJYL/2OtsF391LxBPImpSXsORV7BjFpyvPHQmemc -VtJa2UCaPgG2Mny105uJnalRjrVXfvJ6iGvYv+g/wMRun7msx1RHDx1TJDQW -uunZDZHUYQRdR6txrkHBfhpH1M+QEY2y7iDQdQMS+HijffXJioxeTK2fdW+G -YNaXe+Ff2DChybMe2kbit0Jk8NgXdiUcR9B3HPHdpC7cJja0PnU79G9ale2X -+/a1W837bZy+7fmB9K//ox8AyZvSYM8sMcseonBRD/r3vTNRwlOi51DnMqLD -MhFd0hAUUbmpmmDcmEBPkGpZ2SXroeVhR6q1UL7PhE+fiQD3SVeAlBKFud8m -DIGWZu6KUxc0eaXS3bsUwLkCrFrzi7I1b/QZN/lNeHztWk58jRtcKhLHVAZO -LjL/7lEkcAtd7FSRJqUGykOOS+zt7e2VBJuNePr5Dp6iGiKjcbkRmkr6Rool -FbXLMmKfitlLQga46F64q58/aDhXcxBSwo5VEfOES02ayB94doxmisvxEuPL -OgDQo+AaZegRkB/xRLD3r1FdKnfDbcUcZuOaUcp9Za4VG8hfr+8o+bBQ3sVP -FUjXSrdabqW3Cgo3RrJnE8JUiIT863bSUEyejcrbALUKtoRIU+RUeZ4zaQ4z -NDaQw/zLJ3YqiC1Sdi4zX3l0QxRG0NuM3bW3Zx7RKOeosZ3j89PxVZMV9M7C -CcOAhSTzITVsr/tmONrrvOi+QYnXr9Q811XPDtnO2uvFpmP6kjB0qZ5m9l+R -Y+xy+MvbsTv9uMbu0f43NXaPDp6g8STUfLWPfEUh/Qcsvsbg6xcAAA== - ---> - </rfc>
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
