RFC Publications

{
  "url": "https://www.rfc-editor.org/info/rfc9966/",
  "title": "Bootstrapped TLS Authentication with Proof of Knowledge",
  "rfc_id": "RFC9966",
  "abstract": "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.",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9966,
  "published_at": "2026-05-26T00:00:00.000Z"
}

{
  "url": "https://www.rfc-editor.org/info/rfc9975/",
  "title": "Clarifications on CDS/CDNSKEY and CSYNC Consistency",
  "rfc_id": "RFC9975",
  "abstract": "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 C",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9975,
  "published_at": "2026-05-26T00:00:00.000Z"
}

{
  "url": "https://www.rfc-editor.org/info/rfc9982/",
  "title": "JSContact Version 2.0: A JSON Representation of Contact Data",
  "rfc_id": "RFC9982",
  "abstract": "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.",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9982,
  "published_at": "2026-05-28T00:00:00.000Z"
}

{
  "url": "https://www.rfc-editor.org/info/rfc9987/",
  "title": "Secure Shell (SSH) Agent Protocol",
  "rfc_id": "RFC9987",
  "abstract": "This document specifies a key agent protocol for use in the Secure Shell (SSH) protocol.",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9987,
  "published_at": "2026-05-28T00:00:00.000Z"
}

{
  "url": "https://www.rfc-editor.org/info/rfc9977/",
  "title": "Publishing End-Site Prefix Lengths",
  "rfc_id": "RFC9977",
  "abstract": "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.",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9977,
  "published_at": "2026-05-29T00:00:00.000Z"
}

{
  "url": "https://www.rfc-editor.org/info/rfc9979/",
  "title": "Registration of Further IMAP/JMAP Keywords and Mailbox Name Attributes",
  "rfc_id": "RFC9979",
  "abstract": "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.",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9979,
  "published_at": "2026-05-29T00:00:00.000Z"
}

{
  "url": "https://www.rfc-editor.org/info/rfc9981/",
  "title": "Resource Public Key Infrastructure (RPKI) Manifest Number Handling",
  "rfc_id": "RFC9981",
  "abstract": "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.",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9981,
  "published_at": "2026-05-29T00:00:00.000Z"
}

{
  "url": "https://www.rfc-editor.org/info/rfc9993/",
  "title": "RTP Payload Format for Haptics",
  "rfc_id": "RFC9993",
  "abstract": "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.",
  "standard": "ietf_rfc",
  "categories": [],
  "rfc_number": 9993,
  "published_at": "2026-05-30T00:00:00.000Z"
}