<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title>Recent RFCs</title>
        <link>https://www.rfc-editor.org</link>
        <description>Recently published RFCs</description>
        <lastBuildDate>Mon, 03 Aug 2026 16:59:55 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://www.npmjs.com/package/feed</generator>
        <language>en-us</language>
        <item>
            <title><![CDATA[RFC 10029: DNS Multiple QTYPEs]]></title>
            <link>https://www.rfc-editor.org/info/rfc10029/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10029/</guid>
            <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the Question section of a DNS QUERY (OpCode=0).]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10022: IMAP UIDBATCHES Extension]]></title>
            <link>https://www.rfc-editor.org/info/rfc10022/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10022/</guid>
            <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve Unique Identifier (UID) ranges that partition a mailbox's messages into equally sized batches. This enables clients to perform operations such as FETCH, SEARCH, and STORE on specific message batches, providing better control over resource usage and response sizes. The extension is particularly useful with the UIDONLY mode where sequence numbers are unavailable.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10023: The "_for-sale" Underscored and Globally Scoped DNS Node Name]]></title>
            <link>https://www.rfc-editor.org/info/rfc10023/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10023/</guid>
            <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document defines an operational convention that uses the</p><p>reserved underscored DNS leaf node name "_for-sale" to indicate the</p><p>parent domain name is available for purchase.</p><p>The convention can be deployed without disrupting existing</p><p>operations, and it may be applied even when the domain name is still</p><p>actively in use.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10019: Zeroconf Multicast Address Allocation Problem Statement and Requirements]]></title>
            <link>https://www.rfc-editor.org/info/rfc10019/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10019/</guid>
            <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration (zeroconf) networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination.</p><p>The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10013: Entity Attestation Token (EAT) Measured Component]]></title>
            <link>https://www.rfc-editor.org/info/rfc10013/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10013/</guid>
            <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the measured component and two associated data models. This separation is intentional: The JSON and Concise Binary Object Representation (CBOR) serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9996: Media Types for Protocol Buffers]]></title>
            <link>https://www.rfc-editor.org/info/rfc9996/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9996/</guid>
            <pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document registers media types for Protocol Buffers, a common</p><p>extensible mechanism for serializing structured data.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10026: Operational Recommendations for DNSSEC Delegation Signer (DS) Automation]]></title>
            <link>https://www.rfc-editor.org/info/rfc10026/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10026/</guid>
            <pubDate>Thu, 23 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, and 9615) requires the Parental Agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9997: YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders]]></title>
            <link>https://www.rfc-editor.org/info/rfc9997/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9997/</guid>
            <pubDate>Thu, 23 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>YANG-CBOR (RFC 9254, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)") defines YANG Schema Item iDentifiers (YANG SIDs), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 ("YANG Schema Item iDentifier (YANG SID)") defines ways to allocate these SIDs using IANA registries.</p><p>The present specification employs these SID allocation mechanisms to allocate ranges of 100 000 SIDs (representation size 64 bits) to each holder of an IANA Private Enterprise Number (PEN) of a value below 1 000 000. Holders of PENs of values smaller than 100 000 are also allocated ranges of 10 000 SIDs (representation size 32 bits).</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10004: Certificate Management over CMS (CMC): Compliance Requirements]]></title>
            <link>https://www.rfc-editor.org/info/rfc10004/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10004/</guid>
            <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document provides a set of compliance statements about the Certificate Management over CMS (CMC) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents (RFCs 10002 and 10003). This document provides the information needed to make a compliant version of CMC.</p><p>This document obsoletes RFCs 5274 and 6402.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10003: Certificate Management over CMS (CMC): Transport Protocols]]></title>
            <link>https://www.rfc-editor.org/info/rfc10003/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10003/</guid>
            <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document defines a number of transport mechanisms that are used to move Certificate Management over CMS (CMC) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP.</p><p>This document obsoletes RFCs 5273 and 6402.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10002: Certificate Management over CMS (CMC)]]></title>
            <link>https://www.rfc-editor.org/info/rfc10002/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10002/</guid>
            <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</p><p>CMC also requires the use of the transport document (RFC 10003) and the requirements usage document (RFC 10004) along with this document for a full definition.</p><p>This document obsoletes RFCs 5272 and 6402.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2]]></title>
            <link>https://www.rfc-editor.org/info/rfc10015/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc10015/</guid>
            <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman (DH) over a finite field and RSA. It also discourages the use of static Elliptic Curve Diffie-Hellman (ECDH) cipher suites.</p><p>These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.)</p><p>This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 to either deprecate or discourage the use of cipher suites using the above key exchange methods in (D)TLS 1.2 connections.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9955: Hybrid Signature Spectrums]]></title>
            <link>https://www.rfc-editor.org/info/rfc9955/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9955/</guid>
            <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, and Simultaneous Verification (SV).]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9852: New Protocols Using TLS Must Require TLS 1.3]]></title>
            <link>https://www.rfc-editor.org/info/rfc9852/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9852/</guid>
            <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[<p>TLS 1.3 is widely used, has had comprehensive security proofs, and improves both security and privacy deficiencies in TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.</p><p>This document updates RFC 9325. It discusses post-quantum cryptography and the security and privacy improvements in TLS 1.3 as the rationale for the update.</p>]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9973: TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key]]></title>
            <link>https://www.rfc-editor.org/info/rfc9973/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9973/</guid>
            <pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC obsoletes RFC 8773, which was an Experimental RFC.]]></description>
        </item>
    </channel>
</rss>