idnits 2.17.1 draft-ietf-core-href-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 May 2021) is 1079 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Hartke 3 Internet-Draft Ericsson 4 Intended status: Standards Track C. Bormann, Ed. 5 Expires: 8 November 2021 Universitaet Bremen TZI 6 7 May 2021 8 Constrained Resource Identifiers 9 draft-ietf-core-href-04 11 Abstract 13 The Constrained Resource Identifier (CRI) is a complement to the 14 Uniform Resource Identifier (URI) that serializes the URI components 15 in Concise Binary Object Representation (CBOR) instead of a sequence 16 of characters. This simplifies parsing, comparison and reference 17 resolution in environments with severe limitations on processing 18 power, code size, and memory size. 20 Note to Readers 22 This note is to be removed before publishing as an RFC. 24 The issues list for this Internet-Draft can be found at 25 . 27 A reference implementation and a set of test vectors can be found at 28 . 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 8 November 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 65 2. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Creation and Normalization . . . . . . . . . . . . . . . . . 5 67 4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. CRI References . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. CBOR Serialization . . . . . . . . . . . . . . . . . . . 7 70 5.2. Reference Resolution . . . . . . . . . . . . . . . . . . 8 71 6. Relationship between CRIs, URIs and IRIs . . . . . . . . . . 10 72 6.1. Converting CRIs to URIs . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 9.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 79 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 The Uniform Resource Identifier (URI) [RFC3986] and its most common 85 usage, the URI reference, are the Internet standard for linking to 86 resources in hypertext formats such as HTML [W3C.REC-html52-20171214] 87 or the HTTP "Link" header field [RFC8288]. 89 A URI reference is a sequence of characters chosen from the 90 repertoire of US-ASCII characters. The individual components of a 91 URI reference are delimited by a number of reserved characters, which 92 necessitates the use of a character escape mechanism called "percent- 93 encoding" when these reserved characters are used in a non-delimiting 94 function. The resolution of URI references involves parsing a 95 character sequence into its components, combining those components 96 with the components of a base URI, merging path components, removing 97 dot-segments, and recomposing the result back into a character 98 sequence. 100 Overall, the proper handling of URI references is quite intricate. 101 This can be a problem especially in constrained environments 102 [RFC7228], where nodes often have severe code size and memory size 103 limitations. As a result, many implementations in such environments 104 support only an ad-hoc, informally-specified, bug-ridden, non- 105 interoperable subset of half of RFC 3986. 107 This document defines the Constrained Resource Identifier (CRI) by 108 constraining URIs to a simplified subset and serializing their 109 components in Concise Binary Object Representation (CBOR) [RFC8949] 110 instead of a sequence of characters. This allows typical operations 111 on URI references such as parsing, comparison and reference 112 resolution (including all corner cases) to be implemented in a 113 comparatively small amount of code. 115 As a result of simplification, however, CRIs are not capable of 116 expressing all URIs permitted by the generic syntax of RFC 3986 117 (hence the "constrained" in "Constrained Resource Identifier"). The 118 supported subset includes all URIs of the Constrained Application 119 Protocol (CoAP) [RFC7252], most URIs of the Hypertext Transfer 120 Protocol (HTTP) [RFC7230], Uniform Resource Names (URNs) [RFC8141], 121 and other similar URIs. The exact constraints are defined in 122 Section 2. 124 1.1. Notational Conventions 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 In this specification, the term "byte" is used in its now customary 133 sense as a synonym for "octet". 135 Terms defined in this document appear in _cursive_ where they are 136 introduced (rendered in plain text as the new term surrounded by 137 underscores). 139 2. Constraints 141 A Constrained Resource Identifier consists of the same five 142 components as a URI: scheme, authority, path, query, and fragment. 143 The components are subject to the following constraints: 145 C1. The scheme name can be any Unicode string (see Definition D80 146 in [Unicode]) that matches the syntax of a URI scheme (see 147 Section 3.1 of [RFC3986]) and is lowercase (see Definition D139 148 in [Unicode]). 150 C2. An authority is always a host identified by an IP address or 151 registered name, along with optional port information. User 152 information is not supported. 154 C3. An IP address can be either an IPv4 address or an IPv6 address. 155 IPv6 scoped addressing zone identifiers and future versions of 156 IP are not supported. 158 C4. A registered name can be any Unicode string that is lowercase 159 and in Unicode Normalization Form C (NFC) (see Definition D120 160 in [Unicode]). (The syntax may be further restricted by the 161 scheme.) 163 C5. A port is always an integer in the range from 0 to 65535. 164 Empty ports or ports outside this range are not supported. 166 C6. The port is omitted if and only if the port would be the same 167 as the scheme's default port (provided the scheme is defining 168 such a default port) or the scheme is not using ports. 170 C7. A path consists of zero or more path segments. A path must not 171 consist of a single zero-length path segment, which is 172 considered equivalent to a path of zero path segments. 174 C8. A path segment can be any Unicode string that is in NFC, with 175 the exception of the special "." and ".." complete path 176 segments. It can be the zero-length string. No special 177 constraints are placed on the first path segment. 179 C9. A query always consists of one or more query parameters. A 180 query parameter can be any Unicode string that is in NFC. It 181 is often in the form of a "key=value" pair. When converting a 182 CRI to a URI, query parameters are separated by an ampersand 183 ("&") character. (This matches the structure and encoding of 184 the target URI in CoAP requests.) Queries are optional; there 185 is a difference between an absent query and a single query 186 parameter that is the empty string. 188 C10. A fragment identifier can be any Unicode string that is in NFC. 189 Fragment identifiers are optional; there is a difference 190 between an absent fragment identifier and a fragment identifier 191 that is the empty string. 193 C11. The syntax of registered names, path segments, query 194 parameters, and fragment identifiers may be further restricted 195 and sub-structured by the scheme. There is no support, 196 however, for escaping sub-delimiters that are not intended to 197 be used in a delimiting function. 199 C12. When converting a CRI to a URI, any character that is outside 200 the allowed character range or is a delimiter in the URI syntax 201 is percent-encoded. For CRIs, percent-encoding always uses the 202 UTF-8 encoding form (see Definition D92 in [Unicode]) to 203 convert the character to a sequence of bytes (that is then 204 converted to a sequence of %HH triplets). 206 3. Creation and Normalization 208 In general, resource identifiers are created on the initial creation 209 of a resource with a certain resource identifier, or the initial 210 exposition of a resource under a particular resource identifier. 212 A Constrained Resource Identifier SHOULD be created by the naming 213 authority that governs the namespace of the resource identifier (see 214 also [RFC8820]). For example, for the resources of an HTTP origin 215 server, that server is responsible for creating the CRIs for those 216 resources. 218 The naming authority MUST ensure that any CRI created satisfies the 219 constraints defined in Section 2. The creation of a CRI fails if the 220 CRI cannot be validated to satisfy all of the constraints. 222 If a naming authority creates a CRI from user input, it MAY apply the 223 following (and only the following) normalizations to get the CRI more 224 likely to validate: 226 * map the scheme name to lowercase (C1); 228 * map the registered name to NFC (C4); 230 * elide the port if it is the default port for the scheme (C6); 232 * elide a single zero-length path segment (C7); 234 * map path segments, query parameters and the fragment identifier to 235 NFC (C8, C9, C10). 237 Once a CRI has been created, it can be used and transferred without 238 further normalization. All operations that operate on a CRI SHOULD 239 rely on the assumption that the CRI is appropriately pre-normalized. 240 (This does not contradict the requirement that when CRIs are 241 transferred, recipients must operate on as-good-as untrusted input 242 and fail gracefully in the face of malicious inputs.) 244 4. Comparison 246 One of the most common operations on CRIs is comparison: determining 247 whether two CRIs are equivalent, without dereferencing the CRIs 248 (using them to access their respective resource(s)). 250 Determination of equivalence or difference of CRIs is based on simple 251 component-wise comparison. If two CRIs are identical component-by- 252 component (using code-point-by-code-point comparison for components 253 that are Unicode strings) then it is safe to conclude that they are 254 equivalent. 256 This comparison mechanism is designed to minimize false negatives 257 while strictly avoiding false positives. The constraints defined in 258 Section 2 imply the most common forms of syntax- and scheme-based 259 normalizations in URIs, but do not comprise protocol-based 260 normalizations that require accessing the resources or detailed 261 knowledge of the scheme's dereference algorithm. False negatives can 262 be caused, for example, by CRIs that are not appropriately pre- 263 normalized and by resource aliases. 265 When CRIs are compared to select (or avoid) a network action, such as 266 retrieval of a representation, fragment components (if any) should be 267 excluded from the comparison. 269 5. CRI References 271 The most common usage of a Constrained Resource Identifier is to 272 embed it in resource representations, e.g., to express a hyperlink 273 between the represented resource and the resource identified by the 274 CRI. 276 This section defines the serialization of CRIs in Concise Binary 277 Object Representation (CBOR) [RFC8949]. To reduce representation 278 size, CRIs are not serialized directly. Instead, CRIs are indirectly 279 referenced through _CRI references_. These take advantage of 280 hierarchical locality and provide a very compact encoding. The CBOR 281 serialization of CRI references is specified in Section 5.1. 283 The only operation defined on a CRI reference is _reference 284 resolution_: the act of transforming a CRI reference into a CRI. An 285 application MUST implement this operation by applying the algorithm 286 specified in Section 5.2 (or any algorithm that is functionally 287 equivalent to it). 289 The reverse operation of transforming a CRI into a CRI reference is 290 unspecified; implementations are free to use any algorithm as long as 291 reference resolution of the resulting CRI reference yields the 292 original CRI. Notably, a CRI reference is not required to satisfy 293 all of the constraints of a CRI; the only requirement on a CRI 294 reference is that reference resolution MUST yield the original CRI. 296 When testing for equivalence or difference, applications SHOULD NOT 297 directly compare CRI references; the references should be resolved to 298 their respective CRI before comparison. 300 5.1. CBOR Serialization 302 A CRI reference is encoded as a CBOR array [RFC8949], with the 303 structure as described in the Concise Data Definition Language (CDDL) 304 [RFC8610] as follows: 306 CRI-Reference = [ 307 (authority // discard), 308 *path, 309 ? (([], fragment) ; include array only if 310 //([+query], ?fragment)) ; at least one query and/or fragment 311 ] 313 authority = (?scheme, ?(host, ?port)) 314 scheme = (scheme-name 315 // COAP // COAPS // HTTP // HTTPS) 316 scheme-name = (false, text .regexp "[a-z][a-z0-9+.-]*") 317 COAP = -1 COAPS = -2 HTTP = -3 HTTPS = -4 318 host = (host-name // host-ip) 319 host-name = (true, text) 320 host-ip = bytes .size 4 / bytes .size 16 321 port = 0..65535 322 discard = 0..127 323 path = text 324 query = text 325 fragment = text 327 The rules "scheme", "host", "port", "path", "query", "fragment" 328 correspond to the (sub-)components of a CRI, as described in 329 Section 2, with the addition of the "discard" element. While 330 "scheme" and "host" can comprise two array elements, we will treat 331 such a combination as a single "element" in the following exposition. 332 (The combination is needed to disambiguate what would otherwise be a 333 leading text string as a scheme, host, or path element.) The 334 "discard" element or its absence can be used to express path prefixes 335 such as "/", "./", "../", "../../", etc. The exact semantics of the 336 element values are defined by Section 5.2. 338 Examples: 340 [-1, / scheme -- equivalent to ...false, "coap",... / 341 h'C6336401', / host / 342 61616, / port / 343 ".well-known", / path / 344 "core"] / path / 346 [".well-known", / path / 347 "core", / path / 348 ["rt=temperature-c"]] / query / 350 A CRI reference is considered _well-formed_ if it matches the CDDL 351 structure. 353 A CRI reference is considered _absolute_ if it is well-formed and the 354 sequence of elements starts with a "scheme". 356 A CRI reference is considered _relative_ if it is well-formed and the 357 sequence of elements is empty or starts with an element other than 358 those that would constitute a "scheme". 360 5.2. Reference Resolution 362 The term "relative" implies that a "base CRI" exists against which 363 the relative reference is applied. Aside from fragment-only 364 references, relative references are only usable when a base CRI is 365 known. 367 The following steps define the process of resolving any well-formed 368 CRI reference against a base CRI so that the result is a CRI in the 369 form of an absolute CRI reference: 371 1. Establish the base CRI of the CRI reference and express it in the 372 form of an absolute CRI reference. (The base CRI can be 373 established in a number of ways; see Section 5.1 of [RFC3986].) 374 Assign each element an element number according to the number E 375 for that element in Table 1. 377 2. Determine the values of two variables, T and E, based on the 378 first element in the sequence of elements of the CRI reference to 379 be resolved, according to Table 1. 381 3. Initialize a buffer with all the elements from the base CRI where 382 the element number is less than the value of E. 384 4. If the value of T is greater than 0, remove the last T-many 385 "path" elements from the end of the buffer (up to the number of 386 "path" elements in the buffer). 388 5. Append all the elements from the CRI reference to the buffer, 389 except for any "discard" element. 391 6. If the number of "path" elements in the buffer is one and the 392 value of that element is the zero-length string, remove that 393 element from the buffer. 395 7. Return the sequence of elements in the buffer as the resolved 396 CRI. 398 +=====================+===============+===+ 399 | First Element | T | E | 400 +=====================+===============+===+ 401 | (scheme) | 0 | 0 | 402 +---------------------+---------------+---+ 403 | (host) | 0 | 1 | 404 +---------------------+---------------+---+ 405 | (discard) | element value | 3 | 406 +---------------------+---------------+---+ 407 | (path) | 0 | 2 | 408 +---------------------+---------------+---+ 409 | (query) | 0 | 3 | 410 +---------------------+---------------+---+ 411 | (fragment) | 0 | 4 | 412 +---------------------+---------------+---+ 413 | none/empty sequence | 0 | 4 | 414 +---------------------+---------------+---+ 416 Table 1: Values of the Variables T and E 418 6. Relationship between CRIs, URIs and IRIs 420 CRIs are meant to replace both Uniform Resource Identifiers (URIs) 421 [RFC3986] and Internationalized Resource Identifiers (IRIs) [RFC3987] 422 in constrained environments [RFC7228]. Applications in these 423 environments may never need to use URIs and IRIs directly, especially 424 when the resource identifier is used simply for identification 425 purposes or when the CRI can be directly converted into a CoAP 426 request. 428 However, it may be necessary in other environments to determine the 429 associated URI or IRI of a CRI, and vice versa. Applications can 430 perform these conversions as follows: 432 CRI to URI 433 A CRI is converted to a URI as specified in Section 6.1. 435 URI to CRI 436 The method of converting a URI to a CRI is unspecified; 437 implementations are free to use any algorithm as long as 438 converting the resulting CRI back to a URI yields an equivalent 439 URI. 441 CRI to IRI 442 A CRI can be converted to an IRI by first converting it to a URI 443 as specified in Section 6.1, and then converting the URI to an IRI 444 as described in Section 3.2 of [RFC3987]. 446 IRI to CRI 447 An IRI can be converted to a CRI by first converting it to a URI 448 as described in Section 3.1 of [RFC3987], and then converting the 449 URI to a CRI as described above. 451 Everything in this section also applies to CRI references, URI 452 references and IRI references. 454 6.1. Converting CRIs to URIs 456 Applications MUST convert a CRI reference to a URI reference by 457 determining the components of the URI reference according to the 458 following steps and then recomposing the components to a URI 459 reference string as specified in Section 5.3 of [RFC3986]. 461 scheme 462 If the CRI reference contains a "scheme" element, the scheme 463 component of the URI reference consists of the value of that 464 element. Otherwise, the scheme component is unset. 466 authority 467 If the CRI reference contains a "host-name" or "host-ip" element, 468 the authority component of the URI reference consists of a host 469 subcomponent, optionally followed by a colon (":") character and a 470 port subcomponent. Otherwise, the authority component is unset. 472 The host subcomponent consists of the value of the "host-name" or 473 "host-ip" element. 475 Any character in the value of a "host-name" element that is not in 476 the set of unreserved characters (Section 2.3 of [RFC3986]) or 477 "sub-delims" (Section 2.2 of [RFC3986]) MUST be percent-encoded. 479 The value of a "host-ip" element MUST be represented as a string 480 that matches the "IPv4address" or "IP-literal" rule (Section 3.2.2 481 of [RFC3986]). 483 If the CRI reference contains a "port" element, the port 484 subcomponent consists of the value of that element in decimal 485 notation. Otherwise, the colon (":") character and the port 486 subcomponent are both omitted. 488 path 489 If the CRI reference is an empty sequence of elements or starts 490 with a "port" element, a "path" element, or a "discard" element 491 where the value is not 0, the conversion fails. 493 If the CRI reference contains a "host-name" element, a "host-ip" 494 element or a "discard" element, the path component of the URI 495 reference is prefixed by a slash ("/") character. Otherwise, the 496 path component is prefixed by the zero-length string. 498 If the CRI reference contains one or more "path" elements, the 499 prefix is followed by the value of each element, separated by a 500 slash ("/") character. 502 Any character in the value of a "path" element that is not in the 503 set of unreserved characters or "sub-delims" or a colon (":") or 504 commercial at ("@") character MUST be percent-encoded. 506 If the authority component is defined and the path component does 507 not match the "path-abempty" rule (Section 3.3 of [RFC3986]), the 508 conversion fails. 510 If the authority component is unset and the scheme component is 511 defined and the path component does not match the "path-absolute", 512 "path-rootless" or "path-empty" rule (Section 3.3 of [RFC3986]), 513 the conversion fails. 515 If the authority component is unset and the scheme component is 516 unset and the path component does not match the "path-absolute", 517 "path-noscheme" or "path-empty" rule (Section 3.3 of [RFC3986]), 518 the conversion fails. 520 query 521 If the CRI reference contains one or more "query" elements, the 522 query component of the URI reference consists of the value of each 523 element, separated by an ampersand ("&") character. Otherwise, 524 the query component is unset. 526 Any character in the value of a "query" element that is not in the 527 set of unreserved characters or "sub-delims" or a colon (":"), 528 commercial at ("@"), slash ("/") or question mark ("?") character 529 MUST be percent-encoded. Additionally, any ampersand character 530 ("&") in the element value MUST be percent-encoded. 532 fragment 533 If the CRI reference contains a fragment element, the fragment 534 component of the URI reference consists of the value of that 535 element. Otherwise, the fragment component is unset. 537 Any character in the value of a "fragment" element that is not in 538 the set of unreserved characters or "sub-delims" or a colon (":"), 539 commercial at ("@"), slash ("/") or question mark ("?") character 540 MUST be percent-encoded. 542 7. Security Considerations 544 Parsers of CRI references must operate on input that is assumed to be 545 untrusted. This means that parsers MUST fail gracefully in the face 546 of malicious inputs. Additionally, parsers MUST be prepared to deal 547 with resource exhaustion (e.g., resulting from the allocation of big 548 data items) or exhaustion of the call stack (stack overflow). See 549 Section 10 of [RFC8949] for additional security considerations 550 relating to CBOR. 552 The security considerations discussed in Section 7 of [RFC3986] and 553 Section 8 of [RFC3987] for URIs and IRIs also apply to CRIs. 555 8. IANA Considerations 557 This document has no IANA actions. 559 9. References 561 9.1. Normative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, 565 DOI 10.17487/RFC2119, March 1997, 566 . 568 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 569 Resource Identifier (URI): Generic Syntax", STD 66, 570 RFC 3986, DOI 10.17487/RFC3986, January 2005, 571 . 573 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 574 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 575 January 2005, . 577 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 578 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 579 May 2017, . 581 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 582 Definition Language (CDDL): A Notational Convention to 583 Express Concise Binary Object Representation (CBOR) and 584 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 585 June 2019, . 587 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 588 Representation (CBOR)", STD 94, RFC 8949, 589 DOI 10.17487/RFC8949, December 2020, 590 . 592 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 593 13.0.0", ISBN 978-1-936213-26-9, March 2020, 594 . 596 9.2. Informative References 598 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 599 Constrained-Node Networks", RFC 7228, 600 DOI 10.17487/RFC7228, May 2014, 601 . 603 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 604 Protocol (HTTP/1.1): Message Syntax and Routing", 605 RFC 7230, DOI 10.17487/RFC7230, June 2014, 606 . 608 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 609 Application Protocol (CoAP)", RFC 7252, 610 DOI 10.17487/RFC7252, June 2014, 611 . 613 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 614 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 615 . 617 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 618 DOI 10.17487/RFC8288, October 2017, 619 . 621 [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, 622 RFC 8820, DOI 10.17487/RFC8820, June 2020, 623 . 625 [W3C.REC-html52-20171214] 626 Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and 627 S. Moon, "HTML 5.2", World Wide Web Consortium 628 Recommendation REC-html52-20171214, 14 December 2017, 629 . 631 Appendix A. Change Log 633 This section is to be removed before publishing as an RFC. 635 Changes from -03 to -04: 637 * Minor editorial improvements. 639 * Renamed path.type/path-type to discard. 641 * Renamed option to element. 643 * Simplied Table 1. 645 * Use the CBOR structure inspired by Jim Schaad's proposals. 647 Changes from -02 to -03: 649 * Expanded the set of supported schemes (#3). 651 * Specified creation, normalization and comparison (#9). 653 * Clarified the default value of the "discard" option (#33). 655 * Removed the "append-relation" discard option (#41). 657 * Renumbered the remaining discards. 659 * Renumbered the option numbers. 661 * Restructured the document. 663 * Minor editorial improvements. 665 Changes from -01 to -02: 667 * Changed the syntax of schemes to exclude upper case characters 668 (#13). 670 * Minor editorial improvements (#34 #37). 672 Changes from -00 to -01: 674 * None. 676 Acknowledgements 678 Thanks to Christian Amsüss, Ari Keränen, Jim Schaad and Dave Thaler 679 for helpful comments and discussions that have shaped the document. 681 Authors' Addresses 683 Klaus Hartke 684 Ericsson 685 Torshamnsgatan 23 686 SE-16483 Stockholm 687 Sweden 689 Email: klaus.hartke@ericsson.com 691 Carsten Bormann (editor) 692 Universitaet Bremen TZI 693 Postfach 330440 694 D-28359 Bremen 695 Germany 697 Phone: +49-421-218-63921 698 Email: cabo@tzi.org