Skip to content

Commit b6b8146

Browse files
mnotmnot
committed
update var
1 parent 35f01f3 commit b6b8146

File tree

3 files changed

+317
-9
lines changed

3 files changed

+317
-9
lines changed

‎var/rfc-index.xml‎

Lines changed: 232 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -20708,6 +20708,7 @@
2070820708
<current-status>INTERNET STANDARD</current-status>
2070920709
<publication-status>INTERNET STANDARD</publication-status>
2071020710
<stream>Legacy</stream>
20711+
<errata-url>https://www.rfc-editor.org/errata/rfc867</errata-url>
2071120712
<doi>10.17487/RFC0867</doi>
2071220713
</rfc-entry>
2071320714
<rfc-entry>
@@ -57849,8 +57850,8 @@
5784957850
<kw>format</kw>
5785057851
<kw>bitmap</kw>
5785157852
</keywords>
57852-
<abstract><p>This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</p></abstract>
57853-
<current-status>INFORMATIONAL</current-status>
57853+
<abstract><p>This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement for GIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.</p><p> PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also, PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.</p><p> This specification defines the Internet Media Type image/png.</p></abstract>
57854+
<current-status>HISTORIC</current-status>
5785457855
<publication-status>INFORMATIONAL</publication-status>
5785557856
<stream>Legacy</stream>
5785657857
<errata-url>https://www.rfc-editor.org/errata/rfc2083</errata-url>
@@ -126168,7 +126169,6 @@
126168126169
<doc-id>RFC1738</doc-id>
126169126170
</updates>
126170126171
<updated-by>
126171-
<doc-id>RFC6874</doc-id>
126172126172
<doc-id>RFC7320</doc-id>
126173126173
<doc-id>RFC8820</doc-id>
126174126174
</updated-by>
@@ -126884,6 +126884,7 @@
126884126884
<draft>draft-ietf-ipv6-scoping-arch-02</draft>
126885126885
<updated-by>
126886126886
<doc-id>RFC7346</doc-id>
126887+
<doc-id>RFC9844</doc-id>
126887126888
</updated-by>
126888126889
<current-status>PROPOSED STANDARD</current-status>
126889126890
<publication-status>PROPOSED STANDARD</publication-status>
@@ -226344,9 +226345,9 @@
226344226345
<page-count>10</page-count>
226345226346
<abstract><p>This document describes how the zone identifier of an IPv6 scoped address, defined as &lt;zone_id&gt; in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.</p></abstract>
226346226347
<draft>draft-ietf-6man-uri-zoneid-06</draft>
226347-
<updates>
226348-
<doc-id>RFC3986</doc-id>
226349-
</updates>
226348+
<obsoleted-by>
226349+
<doc-id>RFC9844</doc-id>
226350+
</obsoleted-by>
226350226351
<current-status>PROPOSED STANDARD</current-status>
226351226352
<publication-status>PROPOSED STANDARD</publication-status>
226352226353
<stream>IETF</stream>
@@ -252787,6 +252788,9 @@
252787252788
<obsoletes>
252788252789
<doc-id>RFC6122</doc-id>
252789252790
</obsoletes>
252791+
<updated-by>
252792+
<doc-id>RFC9844</doc-id>
252793+
</updated-by>
252790252794
<current-status>PROPOSED STANDARD</current-status>
252791252795
<publication-status>PROPOSED STANDARD</publication-status>
252792252796
<stream>IETF</stream>
@@ -269885,6 +269889,9 @@
269885269889
<updates>
269886269890
<doc-id>RFC1738</doc-id>
269887269891
</updates>
269892+
<updated-by>
269893+
<doc-id>RFC9844</doc-id>
269894+
</updated-by>
269888269895
<current-status>PROPOSED STANDARD</current-status>
269889269896
<publication-status>PROPOSED STANDARD</publication-status>
269890269897
<stream>IETF</stream>
@@ -286686,6 +286693,9 @@
286686286693
<obsoletes>
286687286694
<doc-id>RFC5751</doc-id>
286688286695
</obsoletes>
286696+
<updated-by>
286697+
<doc-id>RFC9788</doc-id>
286698+
</updated-by>
286689286699
<current-status>PROPOSED STANDARD</current-status>
286690286700
<publication-status>PROPOSED STANDARD</publication-status>
286691286701
<stream>IETF</stream>
@@ -334330,6 +334340,107 @@ decency, and respect.</p><p> This document is a product of the Internet Research
334330334340
<wg_acronym>bess</wg_acronym>
334331334341
<doi>10.17487/RFC9786</doi>
334332334342
</rfc-entry>
334343+
<rfc-entry>
334344+
<doc-id>RFC9787</doc-id>
334345+
<title>Guidance on End-to-End Email Security</title>
334346+
<author>
334347+
<name>D. K. Gillmor</name>
334348+
<title>Editor</title>
334349+
</author>
334350+
<author>
334351+
<name>A. Melnikov</name>
334352+
<title>Editor</title>
334353+
</author>
334354+
<author>
334355+
<name>B. Hoeneisen</name>
334356+
<title>Editor</title>
334357+
</author>
334358+
<date>
334359+
<month>August</month>
334360+
<year>2025</year>
334361+
</date>
334362+
<format>
334363+
<file-format>HTML</file-format>
334364+
<file-format>TEXT</file-format>
334365+
<file-format>PDF</file-format>
334366+
<file-format>XML</file-format>
334367+
</format>
334368+
<page-count>53</page-count>
334369+
<keywords>
334370+
<kw>cryptography</kw>
334371+
<kw>encryption</kw>
334372+
<kw>signature</kw>
334373+
<kw>signing</kw>
334374+
<kw>usability</kw>
334375+
<kw>MIME</kw>
334376+
<kw>confidentiality</kw>
334377+
<kw>integrity</kw>
334378+
<kw>authenticity</kw>
334379+
</keywords>
334380+
<abstract><p>End-to-end cryptographic protections for email messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for Mail User Agent (MUA) implementers to help mitigate those risks and to make end-to-end email simple and secure for the end user. It provides a useful set of vocabulary as well as recommendations to avoid common failures. It also identifies a number of currently unsolved usability and interoperability problems.</p></abstract>
334381+
<draft>draft-ietf-lamps-e2e-mail-guidance-17</draft>
334382+
<current-status>INFORMATIONAL</current-status>
334383+
<publication-status>INFORMATIONAL</publication-status>
334384+
<stream>IETF</stream>
334385+
<area>sec</area>
334386+
<wg_acronym>lamps</wg_acronym>
334387+
<doi>10.17487/RFC9787</doi>
334388+
</rfc-entry>
334389+
<rfc-entry>
334390+
<doc-id>RFC9788</doc-id>
334391+
<title>Header Protection for Cryptographically Protected Email</title>
334392+
<author>
334393+
<name>D. K. Gillmor</name>
334394+
</author>
334395+
<author>
334396+
<name>B. Hoeneisen</name>
334397+
</author>
334398+
<author>
334399+
<name>A. Melnikov</name>
334400+
</author>
334401+
<date>
334402+
<month>August</month>
334403+
<year>2025</year>
334404+
</date>
334405+
<format>
334406+
<file-format>HTML</file-format>
334407+
<file-format>TEXT</file-format>
334408+
<file-format>PDF</file-format>
334409+
<file-format>XML</file-format>
334410+
</format>
334411+
<page-count>218</page-count>
334412+
<keywords>
334413+
<kw>Header Protection</kw>
334414+
<kw>Header Confidentiality Policy</kw>
334415+
<kw>HCP</kw>
334416+
<kw>cryptographic email</kw>
334417+
<kw>email encryption</kw>
334418+
<kw>encryption</kw>
334419+
<kw>encrypt</kw>
334420+
<kw>signature</kw>
334421+
<kw>sign</kw>
334422+
<kw>S/MIME</kw>
334423+
<kw>PGP/MIME</kw>
334424+
<kw>Legacy Display</kw>
334425+
<kw>Legacy Display Element</kw>
334426+
<kw>MIME</kw>
334427+
<kw>Privacy</kw>
334428+
<kw>HP-Outer</kw>
334429+
<kw>hp-legacy-display</kw>
334430+
<kw>hp</kw>
334431+
</keywords>
334432+
<abstract><p>S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of email message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message.</p><p> This document updates the S/MIME specification (RFC 8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling email messages with cryptographic protection of message headers.</p><p> The Header Protection scheme defined here is also applicable to messages with PGP/MIME (Pretty Good Privacy with MIME) cryptographic protections.</p></abstract>
334433+
<draft>draft-ietf-lamps-header-protection-25</draft>
334434+
<updates>
334435+
<doc-id>RFC8551</doc-id>
334436+
</updates>
334437+
<current-status>PROPOSED STANDARD</current-status>
334438+
<publication-status>PROPOSED STANDARD</publication-status>
334439+
<stream>IETF</stream>
334440+
<area>sec</area>
334441+
<wg_acronym>lamps</wg_acronym>
334442+
<doi>10.17487/RFC9788</doi>
334443+
</rfc-entry>
334333334444
<rfc-entry>
334334334445
<doc-id>RFC9789</doc-id>
334335334446
<title>MPLS Network Actions (MNAs) Framework</title>
@@ -335584,6 +335695,121 @@ Protocol (EPP) that allows EPP clients to manage the Time-to-Live
335584335695
<wg_acronym>sidrops</wg_acronym>
335585335696
<doi>10.17487/RFC9829</doi>
335586335697
</rfc-entry>
335698+
<rfc-entry>
335699+
<doc-id>RFC9837</doc-id>
335700+
<title>The IPv6 VPN Service Destination Option</title>
335701+
<author>
335702+
<name>R. Bonica</name>
335703+
</author>
335704+
<author>
335705+
<name>X. Li</name>
335706+
</author>
335707+
<author>
335708+
<name>A. Farrel</name>
335709+
</author>
335710+
<author>
335711+
<name>Y. Kamite</name>
335712+
</author>
335713+
<author>
335714+
<name>L. Jalil</name>
335715+
</author>
335716+
<date>
335717+
<month>August</month>
335718+
<year>2025</year>
335719+
</date>
335720+
<format>
335721+
<file-format>HTML</file-format>
335722+
<file-format>TEXT</file-format>
335723+
<file-format>PDF</file-format>
335724+
<file-format>XML</file-format>
335725+
</format>
335726+
<page-count>10</page-count>
335727+
<keywords>
335728+
<kw>IPv6</kw>
335729+
<kw>Destination Option</kw>
335730+
<kw>VPN</kw>
335731+
</keywords>
335732+
<abstract><p>This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option. The experimental IPv6 Destination Option is called the VPN Service Option.</p><p> One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment.</p></abstract>
335733+
<draft>draft-ietf-6man-vpn-dest-opt-11</draft>
335734+
<current-status>EXPERIMENTAL</current-status>
335735+
<publication-status>EXPERIMENTAL</publication-status>
335736+
<stream>IETF</stream>
335737+
<area>int</area>
335738+
<wg_acronym>6man</wg_acronym>
335739+
<doi>10.17487/RFC9837</doi>
335740+
</rfc-entry>
335741+
<rfc-entry>
335742+
<doc-id>RFC9839</doc-id>
335743+
<title>Unicode Character Repertoire Subsets</title>
335744+
<author>
335745+
<name>T. Bray</name>
335746+
</author>
335747+
<author>
335748+
<name>P. Hoffman</name>
335749+
</author>
335750+
<date>
335751+
<month>August</month>
335752+
<year>2025</year>
335753+
</date>
335754+
<format>
335755+
<file-format>HTML</file-format>
335756+
<file-format>TEXT</file-format>
335757+
<file-format>PDF</file-format>
335758+
<file-format>XML</file-format>
335759+
</format>
335760+
<page-count>10</page-count>
335761+
<keywords>
335762+
<kw>Unicode</kw>
335763+
<kw>UTF-8</kw>
335764+
<kw>Surrogates</kw>
335765+
<kw>Noncharacters</kw>
335766+
<kw>Control characters</kw>
335767+
</keywords>
335768+
<abstract><p>This document discusses subsets of the Unicode character repertoire for use in protocols and data formats and specifies three subsets recommended for use in IETF specifications.</p></abstract>
335769+
<draft>draft-bray-unichars-15</draft>
335770+
<current-status>PROPOSED STANDARD</current-status>
335771+
<publication-status>PROPOSED STANDARD</publication-status>
335772+
<stream>IETF</stream>
335773+
<wg_acronym>NON WORKING GROUP</wg_acronym>
335774+
<doi>10.17487/RFC9839</doi>
335775+
</rfc-entry>
335776+
<rfc-entry>
335777+
<doc-id>RFC9844</doc-id>
335778+
<title>Entering IPv6 Zone Identifiers in User Interfaces</title>
335779+
<author>
335780+
<name>B. Carpenter</name>
335781+
</author>
335782+
<author>
335783+
<name>B. Hinden</name>
335784+
</author>
335785+
<date>
335786+
<month>August</month>
335787+
<year>2025</year>
335788+
</date>
335789+
<format>
335790+
<file-format>HTML</file-format>
335791+
<file-format>TEXT</file-format>
335792+
<file-format>PDF</file-format>
335793+
<file-format>XML</file-format>
335794+
</format>
335795+
<page-count>8</page-count>
335796+
<abstract><p>This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture specification (RFC 4007), should be entered into a user interface. This document obsoletes RFC 6874 and updates RFCs 4007, 7622, and 8089.</p></abstract>
335797+
<draft>draft-ietf-6man-zone-ui-10</draft>
335798+
<obsoletes>
335799+
<doc-id>RFC6874</doc-id>
335800+
</obsoletes>
335801+
<updates>
335802+
<doc-id>RFC4007</doc-id>
335803+
<doc-id>RFC7622</doc-id>
335804+
<doc-id>RFC8089</doc-id>
335805+
</updates>
335806+
<current-status>PROPOSED STANDARD</current-status>
335807+
<publication-status>PROPOSED STANDARD</publication-status>
335808+
<stream>IETF</stream>
335809+
<area>int</area>
335810+
<wg_acronym>6man</wg_acronym>
335811+
<doi>10.17487/RFC9844</doi>
335812+
</rfc-entry>
335587335813
<std-entry>
335588335814
<doc-id>STD0001</doc-id>
335589335815
<title>[STD number 1 is retired. It was "Internet Official Protocol Standards". See BCP 9 / RFC 7100 for more information.]</title>

‎var/rfc-index.xml.etag‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
W/"e05fd7-63cf0fd979623-gzip"
1+
W/"e08723-63cffa791c4cc-gzip"

0 commit comments

Comments
 (0)