<?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>Sat, 30 May 2026 16:37:07 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 9993: RTP Payload Format for Haptics]]></title>
            <link>https://www.rfc-editor.org/info/rfc9993/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9993/</guid>
            <pubDate>Sat, 30 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This memo specifies an RTP payload format for MPEG-I haptic data. A haptic media stream is composed of MPEG-I Haptic Stream (MIHS) units including a MIHS unit header and zero or more MIHS packets. The RTP payload header format allows for packetization of a MIHS unit in an RTP packet payload as well as fragmentation of a MIHS unit into multiple RTP packets. The original subtype registration for 'haptics/hmpg' (RFC 9695) did not include any required or optional parameters. This memo updates RFC 9695 and the 'haptics/hmpg' registration to add optional parameters. It also provides Session Description Protocol (SDP) usage information for the 'haptics' media type.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9981: Resource Public Key Infrastructure (RPKI) Manifest Number Handling]]></title>
            <link>https://www.rfc-editor.org/info/rfc9981/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9981/</guid>
            <pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The Resource Public Key Infrastructure (RPKI) makes use of signed objects called "manifests", each of which includes a "manifest number". This document updates RFC 9286 by specifying issuer and Relying Party (RP) behaviour when a manifest number reaches the largest possible value, a situation not considered in RFC 9286.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9979: Registration of Further IMAP/JMAP Keywords and Mailbox Name Attributes]]></title>
            <link>https://www.rfc-editor.org/info/rfc9979/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9979/</guid>
            <pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document defines a number of keywords and mailbox name
   attributes that have been in use across different server and client
   implementations.  It defines the intended use of these keywords and
   mailbox name attributes.  This document registers all of these with
   IANA to avoid name collisions.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9977: Publishing End-Site Prefix Lengths]]></title>
            <link>https://www.rfc-editor.org/info/rfc9977/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9977/</guid>
            <pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen files, which are Comma-Separated Values (CSV) files used to specify end-site prefix lengths. This document also describes an optional mechanism that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen files.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9987: Secure Shell (SSH) Agent Protocol]]></title>
            <link>https://www.rfc-editor.org/info/rfc9987/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9987/</guid>
            <pubDate>Thu, 28 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies a key agent protocol for use in the Secure Shell (SSH) protocol.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9982: JSContact Version 2.0: A JSON Representation of Contact Data]]></title>
            <link>https://www.rfc-editor.org/info/rfc9982/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9982/</guid>
            <pubDate>Thu, 28 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document defines version "2.0" of JSContact. It defines the uid property of a Card object to be optional, rather than mandatory, as defined previously in version "1.0". All other definitions of JSContact version "1.0" remain as defined in RFC 9553. This document updates RFC 9555 by redefining how to convert the now optional uid property from and to vCard. It also registers the vCard JSCOMPS parameter at IANA, which was defined but not registered in RFC 9555.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9975: Clarifications on CDS/CDNSKEY and CSYNC Consistency]]></title>
            <link>https://www.rfc-editor.org/info/rfc9975/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9975/</guid>
            <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance" (RFC 7344) provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters that the parent can ingest. Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g., Registries and Registrars) can query these records from the child and, after validation, use them to update the parent-side Resource Record Sets (RRsets) of the delegation.

This document specifies under which conditions the target states expressed via CDS/CDNSKEY and CSYNC records are considered "consistent". Parent-side entities accepting such records from the child have to ensure that update requests retrieved from different authoritative nameservers satisfy these consistency requirements before taking any action based on them.

This document updates RFCs 7344 and 7477.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9966: Bootstrapped TLS Authentication with Proof of Knowledge]]></title>
            <link>https://www.rfc-editor.org/info/rfc9966/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9966/</guid>
            <pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a TLS server. Bootstrapping devices have a public/private key pair; this mechanism enables a TLS server to prove to the device that it knows the public key and enables the device to prove to the TLS server that it knows the private key. The mechanism leverages existing Device Provisioning Profile (DPP) and TLS standards and can be used in an Extensible Authentication Protocol (EAP) exchange with an EAP server.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9991: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting]]></title>
            <link>https://www.rfc-editor.org/info/rfc9991/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9991/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports", or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism.

 This document updates RFC 6591 and obsoletes RFC 7489.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting]]></title>
            <link>https://www.rfc-editor.org/info/rfc9990/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9990/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record.

 This document obsoletes RFC 7489.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9989/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9989/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol.

 DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail.

 This document obsoletes RFCs 7489 and 9091.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9983: OSPFv2 Anycast Property Advertisement]]></title>
            <link>https://www.rfc-editor.org/info/rfc9983/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9983/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[An IP prefix may be configured as anycast and, as such, the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast prefix.

 This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. The document also specifies a companion YANG module for managing this function.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9972: Advanced BGP Monitoring Protocol (BMP) Statistics Types]]></title>
            <link>https://www.rfc-editor.org/info/rfc9972/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9972/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The BGP Monitoring Protocol (BMP) described in RFC 7854 defines statistics message types to observe events that occur on a monitored router.  This document defines new statistics types to monitor BMP Adj-RIB-In and Adj-RIB-Out Routing Information Bases (RIBs).]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9969: Report from the IAB Workshop on AI-CONTROL]]></title>
            <link>https://www.rfc-editor.org/info/rfc9969/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9969/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The AI-CONTROL Workshop was convened by the Internet Architecture Board (IAB) in September 2024. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration and work.

 Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9965: The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning]]></title>
            <link>https://www.rfc-editor.org/info/rfc9965/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9965/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document defines the eap.arpa. domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers that use the NAI format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140.

 This document updates RFCs 5216 and 9190 to define an unauthenticated provisioning method. Those specifications suggest that such a method is possible, but they do not define how it would be done. This document also updates RFC 9140 to deprecate "eap-noob.arpa" and replace it with "@noob.eap.arpa".]]></description>
        </item>
    </channel>
</rss>