draft-ietf-httpbis-retrofit-04.txt | draft-ietf-httpbis-retrofit-latest.txt | |||
---|---|---|---|---|
Network Working Group M. Nottingham | Network Working Group M. Nottingham | |||
Internet-Draft June 8, 2022 | Internet-Draft June 22, 2022 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: December 10, 2022 | Expires: December 24, 2022 | |||
Retrofit Structured Fields for HTTP | Retrofit Structured Fields for HTTP | |||
draft-ietf-httpbis-retrofit-04 | draft-ietf-httpbis-retrofit-latest | |||
Abstract | Abstract | |||
This specification nominates a selection of existing HTTP fields as | This specification nominates a selection of existing HTTP fields as | |||
having syntax that is compatible with Structured Fields, so that they | having syntax that is compatible with Structured Fields, so that they | |||
can be handled as such (subject to certain caveats). | can be handled as such (subject to certain caveats). | |||
To accommodate some additional fields whose syntax is not compatible, | To accommodate some additional fields whose syntax is not compatible, | |||
it also defines mappings of their semantics into new Structured | it also defines mappings of their semantics into new Structured | |||
Fields. It does not specify how to negotiate their use. | Fields. It does not specify how to negotiate their use. | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on December 10, 2022. | This Internet-Draft will expire on December 24, 2022. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | |||
2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Compatible Fields . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Mapped Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3. ETags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.4. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.5. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
6. Normative References . . . . . . . . . . . . . . . . . . . . 11 | 6. Normative References . . . . . . . . . . . . . . . . . . . . 12 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1. Introduction | 1. Introduction | |||
Structured Field Values for HTTP [STRUCTURED-FIELDS] introduced a | Structured Field Values for HTTP [STRUCTURED-FIELDS] introduced a | |||
data model with associated parsing and serialization algorithms for | data model with associated parsing and serialization algorithms for | |||
use by new HTTP field values. Fields that are defined as Structured | use by new HTTP field values. Fields that are defined as Structured | |||
Fields can realise a number of benefits, including: | Fields can realise a number of benefits, including: | |||
o Improved interoperability and security: precisely defined parsing | o Improved interoperability and security: precisely defined parsing | |||
and serialisation algorithms are typically not available for | and serialisation algorithms are typically not available for | |||
skipping to change at page 4, line 49 ¶ | skipping to change at page 4, line 49 ¶ | |||
| CDN-Loop | List | | | CDN-Loop | List | | |||
| Clear-Site-Data | List | | | Clear-Site-Data | List | | |||
| Connection | List | | | Connection | List | | |||
| Content-Encoding | List | | | Content-Encoding | List | | |||
| Content-Language | List | | | Content-Language | List | | |||
| Content-Length | List | | | Content-Length | List | | |||
| Content-Type | Item | | | Content-Type | Item | | |||
| Cross-Origin-Resource-Policy | Item | | | Cross-Origin-Resource-Policy | Item | | |||
| Expect | Dictionary | | | Expect | Dictionary | | |||
| Expect-CT | Dictionary | | | Expect-CT | Dictionary | | |||
| Forwarded | Dictionary | | ||||
| Host | Item | | | Host | Item | | |||
| Keep-Alive | Dictionary | | | Keep-Alive | Dictionary | | |||
| Max-Forwards | Item | | | Max-Forwards | Item | | |||
| Origin | Item | | | Origin | Item | | |||
| Pragma | Dictionary | | | Pragma | Dictionary | | |||
| Prefer | Dictionary | | | Prefer | Dictionary | | |||
| Preference-Applied | Dictionary | | | Preference-Applied | Dictionary | | |||
| Retry-After | Item | | | Retry-After | Item | | |||
| Sec-WebSocket-Extensions | List | | | Sec-WebSocket-Extensions | List | | |||
| Sec-WebSocket-Protocol | List | | | Sec-WebSocket-Protocol | List | | |||
skipping to change at page 6, line 7 ¶ | skipping to change at page 6, line 6 ¶ | |||
Strings only escape "\" and DQUOTE. Compatibility can be improved | Strings only escape "\" and DQUOTE. Compatibility can be improved | |||
by unescaping other characters before parsing. | by unescaping other characters before parsing. | |||
Token limitations: In Structured Fields, tokens are required to | Token limitations: In Structured Fields, tokens are required to | |||
begin with an alphabetic character or "*", whereas HTTP tokens | begin with an alphabetic character or "*", whereas HTTP tokens | |||
allow a wider range of characters. This prevents use of mapped | allow a wider range of characters. This prevents use of mapped | |||
values that begin with one of these characters. For example, | values that begin with one of these characters. For example, | |||
media types, field names, methods, range-units, character and | media types, field names, methods, range-units, character and | |||
transfer codings that begin with a number or special character | transfer codings that begin with a number or special character | |||
other than "*" might be valid HTTP protocol elements, but will not | other than "*" might be valid HTTP protocol elements, but will not | |||
be able to be parsed as Structured Field Tokens. | be able to be represented as Structured Field Tokens. | |||
Integer limitations: Structured Fields Integers can have at most 15 | Integer limitations: Structured Fields Integers can have at most 15 | |||
digits; larger values will not be able to be represented in them. | digits; larger values will not be able to be represented in them. | |||
IPv6 Literals: Fields whose values contain IPv6 literal addresses | IPv6 Literals: Fields whose values contain IPv6 literal addresses | |||
(such as CDN-Loop, Host, and Origin) are not able to be | (such as CDN-Loop, Host, and Origin) are not able to be | |||
represented as Structured Fields Tokens, because the brackets used | represented as Structured Fields Tokens, because the brackets used | |||
to delimit them are not allowed in Tokens. | to delimit them are not allowed in Tokens. | |||
Empty Field Values: Empty and whitespace-only field values are | Empty Field Values: Empty and whitespace-only field values are | |||
skipping to change at page 7, line 28 ¶ | skipping to change at page 7, line 28 ¶ | |||
+------------------+---------------------+ | +------------------+---------------------+ | |||
| Field Name | Mapped Field Name | | | Field Name | Mapped Field Name | | |||
+------------------+---------------------+ | +------------------+---------------------+ | |||
| Content-Location | SF-Content-Location | | | Content-Location | SF-Content-Location | | |||
| Location | SF-Location | | | Location | SF-Location | | |||
| Referer | SF-Referer | | | Referer | SF-Referer | | |||
+------------------+---------------------+ | +------------------+---------------------+ | |||
Table 2: URL Fields | Table 2: URL Fields | |||
For example, a Location field could be mapped as: | For example, this Location field | |||
Location: https://example.com/foo | ||||
could be mapped as: | ||||
SF-Location: "https://example.com/foo" | SF-Location: "https://example.com/foo" | |||
3.2. Dates | 3.2. Dates | |||
The field names in Table 3 (paired with their mapped field names) | The field names in Table 3 (paired with their mapped field names) | |||
have values that can be mapped into Structured Fields by parsing | have values that can be mapped into Structured Fields by parsing | |||
their payload according to Section 5.6.7 of [HTTP] and representing | their payload according to Section 5.6.7 of [HTTP] and representing | |||
the result as an Integer number of seconds delta from the Unix Epoch | the result as an Integer number of seconds delta from the Unix Epoch | |||
(00:00:00 UTC on 1 January 1970, excluding leap seconds). | (00:00:00 UTC on 1 January 1970, excluding leap seconds). | |||
+---------------------+-------------------+ | +---------------------+------------------------+ | |||
| Field Name | Mapped Field Name | | | Field Name | Mapped Field Name | | |||
+---------------------+-------------------+ | +---------------------+------------------------+ | |||
| Date | SF-Date | | | Date | SF-Date | | |||
| Expires | SF-Expires | | | Expires | SF-Expires | | |||
| If-Modified-Since | SF-IMS | | | If-Modified-Since | SF-If-Modified-Since | | |||
| If-Unmodified-Since | SF-IUS | | | If-Unmodified-Since | SF-If-Unmodified-Since | | |||
| Last-Modified | SF-LM | | | Last-Modified | SF-Last-Modified | | |||
+---------------------+-------------------+ | +---------------------+------------------------+ | |||
Table 3: Date Fields | Table 3: Date Fields | |||
For example, an Expires field could be mapped as: | For example, an Expires field could be mapped as: | |||
SF-Expires: 1571965240 | SF-Expires: 1571965240 | |||
3.3. ETags | 3.3. ETags | |||
The field value of the ETag header field can be mapped into the SF- | The field value of the ETag header field can be mapped into the SF- | |||
ETag Structured Field by representing the entity-tag as a String, and | ETag Structured Field by representing the entity-tag as a String, and | |||
the weakness flag as a Boolean "w" parameter on it, where true | the weakness flag as a Boolean "w" parameter on it, where true | |||
indicates that the entity-tag is weak; if 0 or unset, the entity-tag | indicates that the entity-tag is weak; if 0 or unset, the entity-tag | |||
is strong. | is strong. | |||
For example: | For example, this: | |||
SF-ETag: "abcdef"; w=?1 | ETag: W/"abcdef" | |||
If-None-Match's field value can be mapped into the SF-INM Structured | SF-ETag: "abcdef"; w | |||
Field, which is a List of the structure described above. | ||||
If-None-Match's field value can be mapped into the SF-If-None-Match | ||||
Structured Field, which is a List of the structure described above. | ||||
When a field value contains "*", it is represented as a Token. | ||||
Likewise, If-Match's field value can be mapped into the SF-If-Match | ||||
Structured Field in the same manner. | ||||
For example: | For example: | |||
SF-INM: "abcdef"; w=?1, "ghijkl" | SF-If-None-Match: "abcdef"; w, "ghijkl", * | |||
3.4. Links | 3.4. Links | |||
The field value of the Link header field [RFC8288] can be mapped into | The field value of the Link header field [RFC8288] can be mapped into | |||
the SF-Link List Structured Field by considering the URI-Reference as | the SF-Link List Structured Field by considering the URI-Reference as | |||
a String, and link-param as Parameters. | a String, and link-param as Parameters. | |||
For example: | For example, this: | |||
Link: </terms>; rel="copyright"; anchor="#foo" | ||||
can be mapped to: | ||||
SF-Link: "/terms"; rel="copyright"; anchor="#foo" | SF-Link: "/terms"; rel="copyright"; anchor="#foo" | |||
3.5. Cookies | 3.5. Cookies | |||
The field values of the Cookie and Set-Cookie fields [COOKIES] can be | The field values of the Cookie and Set-Cookie fields [COOKIES] can be | |||
mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie | mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie | |||
Structured Field (a Dictionary), respectively. | Structured Field (a List), respectively. | |||
In each case, cookie names are Tokens. Their values are Strings, | In each case, a cookie is represented as an Inner List containing two | |||
unless the value can be successfully parsed as the textual | Items; the cookie name and value. The cookie name is always a | |||
representation of another, bare Item structured type (e.g., Byte | String; the cookie value is a String, unless it can be successfully | |||
Sequence, Decimal, Integer, Token, or Boolean). | parsed as the textual representation of another, bare Item structured | |||
type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean). | ||||
Set-Cookie parameters map to Parameters on the appropriate SF-Set- | Cookie attributes map to Parameters on the Inner List, with the | |||
Cookie member, with the parameter name being forced to lowercase. | parameter name being forced to lowercase. Cookie attribute values | |||
Set-Cookie parameter values are Strings unless a specific type is | are Strings unless a specific type is defined for them. This | |||
defined for them. This specification defines the parameter types in | specification defines types for existing cookie attributes in | |||
Table 4. | Table 4. | |||
+----------------+-----------------+ | +----------------+-----------------+ | |||
| Parameter Name | Structured Type | | | Parameter Name | Structured Type | | |||
+----------------+-----------------+ | +----------------+-----------------+ | |||
| Domain | String | | ||||
| HttpOnly | Boolean | | | HttpOnly | Boolean | | |||
| Expires | Integer | | | Expires | Integer | | |||
| Max-Age | Integer | | | Max-Age | Integer | | |||
| Path | String | | ||||
| Secure | Boolean | | | Secure | Boolean | | |||
| SameSite | Token | | | SameSite | Token | | |||
+----------------+-----------------+ | +----------------+-----------------+ | |||
Table 4: Set-Cookie Parameter Types | Table 4: Set-Cookie Parameter Types | |||
Expires is mapped to an Integer representation of parsed-cookie-date | The Expires attribute is mapped to an Integer representation of | |||
(see Section x.x of [COOKIES]) expressed as a number of seconds delta | parsed-cookie-date (see Section 5.1.1 of [COOKIES]) expressed as a | |||
from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap | number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 | |||
seconds). | January 1970, excluding leap seconds). | |||
Note that although this mapping is very similar to the syntax of | For example, these unstructured fields: | |||
Cookie and Set-Cookie headers, cookies in both fields are separated | ||||
by commas, not semicolons, and multiple cookies can appear in each | ||||
field. | ||||
For example: | Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT; | |||
samesite=Strict; secure | ||||
Cookie: SID=31d4d96e407aad42; lang=en-US | ||||
can be mapped into: | ||||
SF-Set-Cookie: lang="en-US"; expires="Wed, 09 Jun 2021 10:18:14 GMT"; | SF-Set-Cookie: ("lang" "en-US"); expires=1623233894; | |||
samesite=Strict; secure=?1 | samesite=Strict; secure | |||
SF-Cookie: SID="31d4d96e407aad42", lang="en-US" | SF-Cookie: ("SID" "31d4d96e407aad42"), ("lang" "en-US") | |||
4. IANA Considerations | 4. IANA Considerations | |||
Please add the following note to the "Hypertext Transfer Protocol | Please add the following note to the "Hypertext Transfer Protocol | |||
(HTTP) Field Name Registry": | (HTTP) Field Name Registry": | |||
The "Structured Type" column indicates the type of the field (per | The "Structured Type" column indicates the type of the field (per | |||
RFC8941), if any, and may be "Dictionary", "List" or "Item". A | RFC8941), if any, and may be "Dictionary", "List" or "Item". A | |||
prefix of "*" indicates that it is a retrofit type (i.e., not | prefix of "*" indicates that it is a retrofit type (i.e., not | |||
natively Structured); see [this specification]. | natively Structured); see [this specification]. | |||
skipping to change at page 10, line 13 ¶ | skipping to change at page 11, line 5 ¶ | |||
fields that refer to it; see [this specification]. | fields that refer to it; see [this specification]. | |||
Then, add a new column, "Structured Type", with the values from | Then, add a new column, "Structured Type", with the values from | |||
Section 2 assigned to the nominated registrations, prefixing each | Section 2 assigned to the nominated registrations, prefixing each | |||
with "*" to indicate that it is a retrofit type. | with "*" to indicate that it is a retrofit type. | |||
Then, add the field names in Table 5, with the corresponding | Then, add the field names in Table 5, with the corresponding | |||
Structured Type as indicated, a status of "permanent" and referring | Structured Type as indicated, a status of "permanent" and referring | |||
to this document. | to this document. | |||
+---------------------+-----------------+ | +------------------------+-----------------+ | |||
| Field Name | Structured Type | | | Field Name | Structured Type | | |||
+---------------------+-----------------+ | +------------------------+-----------------+ | |||
| SF-Content-Location | String | | | SF-Content-Location | Item | | |||
| SF-Cookie | List | | | SF-Cookie | List | | |||
| SF-Date | Item | | | SF-Date | Item | | |||
| SF-ETag | Item | | | SF-ETag | Item | | |||
| SF-Expires | Item | | | SF-Expires | Item | | |||
| SF-IMS | Item | | | SF-If-Match | List | | |||
| SF-INM | List | | | SF-If-Modified-Since | Item | | |||
| SF-IUS | Item | | | SF-If-None-Match | List | | |||
| SF-Link | List | | | SF-If-Unmodified-Since | Item | | |||
| SF-LM | Item | | | SF-Link | List | | |||
| SF-Location | String | | | SF-Last-Modified | Item | | |||
| SF-Referer | String | | | SF-Location | Item | | |||
| SF-Set-Cookie | Dictionary | | | SF-Referer | Item | | |||
+---------------------+-----------------+ | | SF-Set-Cookie | List | | |||
+------------------------+-----------------+ | ||||
Table 5: New Fields | Table 5: New Fields | |||
Finally, add the indicated Structured Type for each existing registry | Then, add the indicated Structured Type for each existing registry | |||
entry listed in Table 6. | entry listed in Table 6. | |||
+------------------------------------------+-----------------+ | +------------------------------------------+-----------------+ | |||
| Field Name | Structured Type | | | Field Name | Structured Type | | |||
+------------------------------------------+-----------------+ | +------------------------------------------+-----------------+ | |||
| Accept-CH | List | | | Accept-CH | List | | |||
| Cache-Status | List | | | Cache-Status | List | | |||
| CDN-Cache-Control | Dictionary | | | CDN-Cache-Control | Dictionary | | |||
| Cross-Origin-Embedder-Policy | Item | | | Cross-Origin-Embedder-Policy | Item | | |||
| Cross-Origin-Embedder-Policy-Report-Only | Item | | | Cross-Origin-Embedder-Policy-Report-Only | Item | | |||
| Cross-Origin-Opener-Policy | Item | | | Cross-Origin-Opener-Policy | Item | | |||
| Cross-Origin-Opener-Policy-Report-Only | Item | | | Cross-Origin-Opener-Policy-Report-Only | Item | | |||
| Origin-Agent-Cluster | Item | | | Origin-Agent-Cluster | Item | | |||
| Priority | Dictionary | | | Priority | Dictionary | | |||
| Proxy-Status | List | | | Proxy-Status | List | | |||
+------------------------------------------+-----------------+ | +------------------------------------------+-----------------+ | |||
Table 6: Existing Fields | Table 6: Existing Fields | |||
Finally, add a new column to the "Cookie Attribute Registry" | ||||
established by [COOKIES] with the title "Structured Type", using | ||||
information from Table 4. | ||||
5. Security Considerations | 5. Security Considerations | |||
Section 2 identifies existing HTTP fields that can be parsed and | Section 2 identifies existing HTTP fields that can be parsed and | |||
serialised with the algorithms defined in [STRUCTURED-FIELDS]. | serialised with the algorithms defined in [STRUCTURED-FIELDS]. | |||
Variances from existing parser behavior might be exploitable, | Variances from existing parser behavior might be exploitable, | |||
particularly if they allow an attacker to target one implementation | particularly if they allow an attacker to target one implementation | |||
in a chain (e.g., an intermediary). However, given the considerable | in a chain (e.g., an intermediary). However, given the considerable | |||
variance in parsers already deployed, convergence towards a single | variance in parsers already deployed, convergence towards a single | |||
parsing algorithm is likely to have a net security benefit in the | parsing algorithm is likely to have a net security benefit in the | |||
longer term. | longer term. | |||
skipping to change at page 11, line 30 ¶ | skipping to change at page 12, line 30 ¶ | |||
they have negotiated support for them with their peer. This | they have negotiated support for them with their peer. This | |||
specification does not define such a mechanism, but any such | specification does not define such a mechanism, but any such | |||
definition needs to consider the implications of doing so carefully. | definition needs to consider the implications of doing so carefully. | |||
6. Normative References | 6. Normative References | |||
[COOKIES] Chen, L., Englehardt, S., West, M., and J. Wilander, | [COOKIES] Chen, L., Englehardt, S., West, M., and J. Wilander, | |||
"Cookies: HTTP State Management Mechanism", draft-ietf- | "Cookies: HTTP State Management Mechanism", draft-ietf- | |||
httpbis-rfc6265bis-10 (work in progress), April 2022. | httpbis-rfc6265bis-10 (work in progress), April 2022. | |||
[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP | [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Semantics", draft-ietf-httpbis-semantics-19 (work in | Ed., "HTTP Semantics", STD 97, RFC 9110, | |||
progress), September 2021. | DOI 10.17487/RFC9110, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9110>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
End of changes. 27 change blocks. | ||||
69 lines changed or deleted | 91 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |