Constrained Resource Identifiers

Constrained Resource Identifiers Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

CoRE Working Group The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 to add a note on how the "URI Schemes" registry of RFC 7595 cooperates with the "CRI Scheme Numbers" registry created by the present RFC. (This "cref" paragraph will be removed by the RFC editor:)
The present revision –19 addresses WGLC comments. About This Document Status information for this document may be found at . Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Uniform Resource Identifier (URI) and its most common usage, the URI reference, are the Internet standard for linking to resources in hypertext formats such as HTML or the HTTP "Link" header field. A URI reference is a sequence of characters chosen from the repertoire of US-ASCII characters (Section of RFC 3986 ). The individual components of a URI reference are delimited by a number of reserved characters, which necessitates the use of a character escape mechanism called "percent-encoding" when these reserved characters are used in a non-delimiting function. The resolution of URI references (Section of RFC 3986 ) involves parsing a character sequence into its components, combining those components with the components of a base URI, merging path components, removing dot-segments ("." and "..", see Section of RFC 3986 ), and recomposing the result back into a character sequence. Overall, the proper handling of URI references is quite intricate. This can be a problem especially in constrained environments , where nodes often have severe code size and memory size limitations. As a result, many implementations in such environments support only an ad-hoc, informally-specified, bug-ridden, non-interoperable subset of half of (aperçu adapted from ). This document defines the Constrained Resource Identifier (CRI) by constraining URIs to a simplified subset and representing their components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. Analogously, CRI references are to CRIs what URI references are to URIs. CRIs and CRI references allow typical operations on URIs and URI references such as parsing, comparison, and reference resolution (including all corner cases) to be implemented in a comparatively small amount of code and to be less prone to bugs and interoperability issues. As a result of simplification, however, CRIs are not capable of expressing all URIs permitted by the generic syntax of (hence the "constrained" in "Constrained Resource Identifier"). The supported subset includes all URIs of the Constrained Application Protocol (CoAP), most URIs of the Hypertext Transfer Protocol (HTTP), Uniform Resource Names (URNs), and other similar URIs. The exact constraints are defined in . CRI extensions () can be defined to address some of the constraints. This RFC creates a "CRI Scheme Numbers" registry and updates to add a note on how this new registry cooperates with the "URI Schemes" registry that describes.

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in () () when, and only when, they appear in all capitals, as shown here. In this specification, the term "byte" is used in its now customary sense as a synonym for "octet". Terms defined in this document appear in cursive where they are introduced (in the plaintext form of this document, they are rendered as the new term surrounded by underscores). The general structure of data items is shown in the Concise Data Definition Language (CDDL) including its control extensions. Specific examples are notated in CBOR Extended Diagnostic Notation (EDN), as originally introduced in Section of RFC 8949 and extended in . ( more rigorously defines and further extends EDN.)

From URIs to CRIs: Considerations and Constraints

The CRI interchange data model A Constrained Resource Identifier consists of the same five components as a URI: scheme, authority, path, query, and fragment. The components are subject to the following considerations and constraints:

The scheme name can be any Unicode string (see Definition D80 in ) that matches the syntax of a URI scheme (see Section of RFC 3986 , which constrains scheme names to ASCII) and is lowercase (see Definition D139 in ). The scheme is always present.
An authority is always a host identified by an IP address or registered name, along with optional port information, and optionally preceded by user information. Alternatively, the authority can be absent; the two cases for this defined in Section of RFC 3986 are modeled by two different values used in place of an absent authority:
- the path can be root-based (zero or more path segments that are each started in the URI with "/", as when the authority is present), or
- the path can be rootless, which requires at least one path segment.
(Note that, in , no-authority is marked as a feature, as not all CRI implementations will support authority-less URIs.)
A userinfo is a text string built out of unreserved characters (Section of RFC 3986 ) or "sub-delims" (Section of RFC 3986 ); any other character needs to be percent-encoded (). Note that this excludes the ":" character, which is commonly deprecated as a way to delimit a cleartext password in a userinfo.
An IP address can be either an IPv4 address or an IPv6 address (optionally with a zone identifier ; see ). Future versions of IP are not supported (it is likely that a binary mapping would be strongly desirable, and that cannot be designed ahead of time, so these versions need to be added as a future extension if needed).
A registered name is a sequence of one or more labels, which, when joined with dots (".") in between them, result in a Unicode string that is lowercase and in Unicode Normalization Form C (NFC) (see Definition D120 in and ). (The syntax may be further restricted by the scheme. As per Section of RFC 3986 , a registered name can be empty, for which case a scheme can define a default for the host.)
A port is always an integer in the range from 0 to 65535. Ports outside this range, empty ports (port subcomponents with no digits, see Section of RFC 3986 ), or ports with redundant leading zeros, are not supported.
If the scheme's port handling is known to the CRI creator, it is RECOMMENDED to omit the port if and only if the port would be the same as the scheme's default port (provided the scheme is defining such a default port) or the scheme is not using ports.
A path consists of zero or more path segments. Note that a path of just a single zero-length path segment is allowed — this is considered equivalent to a path of zero path segments by HTTP and CoAP, but this equivalence does not hold for CRIs in general as they only perform normalization on the Syntax-Based Normalization level (Section of RFC 3986 ), not on the scheme-specific Scheme-Based Normalization level (Section of RFC 3986 ). (A CRI implementation may want to offer scheme-cognizant interfaces, performing this scheme-specific normalization for schemes it knows. The interface could assert which schemes the implementation knows and provide pre-normalized CRIs. This can also relieve the application from removing a lone zero-length path segment before putting path segments into CoAP Options, i.e., from performing the check and jump in item 8 of . See also in .)
A path segment can be any Unicode string that is in NFC (), with the exception of the special "." and ".." complete path segments. Note that this includes the zero-length string. If no authority is present in a CRI, the leading path segment cannot be empty. (See also in .)
A query always consists of one or more query parameters. A query parameter can be any Unicode string that is in NFC . It is often in the form of a "key=value" pair. When converting a CRI to a URI, query parameters are separated by an ampersand ("&") character. (This matches the structure and encoding of the target URI in CoAP requests.) Queries are optional; there is a difference between an absent query and a single query parameter that is the empty string.
A fragment identifier can be any Unicode string that is in NFC . Fragment identifiers are optional; there is a difference between an absent fragment identifier and a fragment identifier that is the empty string.
The syntax of registered names, path segments, query parameters, and fragment identifiers may be further restricted and sub-structured by the scheme. There is no support, however, for escaping sub-delimiters that are not intended to be used in a delimiting function.
When converting a CRI to a URI, any character that is outside the allowed character range or is a delimiter in the URI syntax is percent-encoded. For CRIs, percent-encoding always uses the UTF-8 encoding form (see Definition D92 in ) to convert the character to a sequence of bytes, which are then converted to a sequence of %HH triplets.

Examples for URIs at or beyond the boundaries of these constraints are in in .

CRI References: The discard Component As with URI references and URIs, CRI references are a shorthand for a CRI that is expressed relative to a base CRI. URI and CRI references often discard part or all of the trailing path segments of the base URI or CRI. In a URI reference, this is expressed by syntax for its path component such as leading special path segments . and .. or a leading slash before giving the path segments to be added at the end of the (now truncated) base URI. For use in CRI references, we instead add in a discard component as an alternative to the scheme and authority components, making the specification of discarding base URI path segments separate from adding new path segments from the CRI reference. The discarding intent of a CRI reference is thus fully condensed to a single value in its discard component:

An unsigned integer as the discard component specifies the number of path segments to be discarded from the base CRI (note that this includes the value 0 which cannot be expressed in URI references that then add any path component);
the value true as the discard component specifies discarding all path segments from the base CRI.

If a scheme or authority is present in a CRI reference, the discard component is implicitly equivalent to a value of true and thus not included in the interchanged data item.

Constraints not expressed by the data model There are syntactically valid CRIs and CRI references that cannot be converted into a URI or URI reference, respectively. CRI references of this kind can be acceptable -- they still can be resolved and result in a valid full CRI that can be converted back. Examples of this are:

[0, ["p"]]: appends a slash and the path segment "p" to its base (and unsets the query and the fragment)
[0, null, []]: leaves the path alone but unsets the query and the fragment

(Full) CRIs that do not correspond to a valid URI are not valid on their own, and cannot be used. Normatively they are characterized by the process not producing a valid and syntax-normalized URI. For easier understanding, they are listed here:

CRIs (and CRI references) containing dot-segments (path segment "." or ".."). These segments would be removed by the remove_dot_segments algorithm of , and thus never produce a normalized URI after resolution. (In CRI references, the discard value is used to afford segment removal (see ), and with "." being an unreserved character, expressing them as "%2e" and "%2e%2e" is not even viable, let alone practical).
CRIs without authority whose path starts with a leading empty segment followed by at least one more segment. When converted to URIs, these would violate the requirement that in absence of an authority, a URI's path cannot begin with two slash characters. (E.g., two leading empty segments would be indistinguishable from a URI with a shorter path and a present but empty authority component.) (Compare .)
CRIs without authority that are rootless and have an empty path component (e.g., ["a", true, []]), which would be indistinguishable from its root-based equivalent (["a", null, []]) as both would have the URI a:.

Creation and Normalization In general, resource identifiers are generated when a resource is initially created or exposed under a certain resource identifier. The naming authority that creates a Constrained Resource Identifier SHOULD be the authority that governs the namespace of the resource identifier (see also ). For example, for the resources of an HTTP origin server, that server is responsible for creating the CRIs for those resources. If the naming authority creates a URI instead that can be obtained as a conversion result from a CRI () that CRI can be considered to have been created by the naming authority. The naming authority MUST ensure that any CRI created satisfies the required constraints defined in . The creation of a CRI fails if the CRI cannot be validated to satisfy all of the required constraints. If a naming authority creates a CRI from user input, it may need to apply the following (and only the following) normalizations to get the CRI more likely to validate:

map the scheme name to lowercase ();
map the registered name to NFC () and split it on embedded dots;
elide the port if it is the default port for the scheme ();
map path segments, query parameters, and the fragment identifier to NFC form (, , ).

Once a CRI has been created, it can be used and transferred without further normalization. All operations that operate on a CRI SHOULD rely on the assumption that the CRI is appropriately pre-normalized. (This does not contradict the requirement that, when CRIs are transferred, recipients must operate on as-good-as untrusted input and fail gracefully in the face of malicious inputs.) Note that the processing of CRIs does not imply that all the constraints continuously need to be checked and enforced. Specifically, the text normalization constraints (NFC) can be expanded as: The recipient of a CRI MAY reasonably expect the text labels to be in NFC form, but as with any input MUST NOT fail (beyond possibly not being able to process the specific CRI) if they are not. So the onus of fulfilling the expectation is on the original creator of the CRI, not on each processor (including consumer). This consideration extends to the sources the CRI creator uses in building the labels, which the CRI creator MAY in turn expect to be in NFC form if that expectation is reasonable. See for some background. CRIs have been designed with the objective that, after the above normalization, conversion of two distinct CRIs to URIs do not yield the "same" URI, including equivalence under syntax-based normalization (Section of RFC 3986 ), but not including protocol-based normalization. Note that this objective exclusively applies to (full) CRIs, not to CRI references: these need to be resolved relative to a base URI, with results that may be equivalent or not depending on the base.

Comparison One of the most common operations on CRIs is comparison: determining whether two CRIs are equivalent, without dereferencing the CRIs (i.e., using them to access their respective resource(s)). Determination of equivalence or difference of CRIs is based on simple component-wise comparison. If two CRIs are identical component-by-component (using code-point-by-code-point comparison for components that are Unicode strings) then it is safe to conclude that they are equivalent. This comparison mechanism is designed to minimize false negatives while strictly avoiding false positives. The constraints defined in imply the most common forms of syntax- and scheme-based normalizations in URIs, but do not comprise protocol-based normalizations that require accessing the resources or detailed knowledge of the scheme's dereference algorithm. False negatives can be caused, for example, by CRIs that are not appropriately pre-normalized and by resource aliases. When CRIs are compared to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) do not play a role and typically are excluded from the comparison.

CRI References The most common usage of a Constrained Resource Identifier is to embed it in resource representations, e.g., to express a hyperlink between the represented resource and the resource identified by the CRI. first defines the representation of CRIs in Concise Binary Object Representation (CBOR). When reduced representation size is desired, CRIs are often not represented directly. Instead, CRIs are indirectly referenced through CRI references. These take advantage of hierarchical locality and provide a very compact encoding. The CBOR representation of CRI references also is specified in . The only operation defined on a CRI reference is reference resolution: the act of transforming a CRI reference into a CRI. An application MUST implement this operation by applying the algorithm specified in (or any algorithm that is functionally equivalent to it). The reverse operation of transforming a CRI into a CRI reference is not specified in detail in this document; implementations are free to use any algorithm as long as reference resolution of the resulting CRI reference yields the original CRI. Notably, a CRI reference is not required to satisfy all of the constraints of a CRI; the only requirement on a CRI reference is that reference resolution MUST yield the original CRI. When testing for equivalence or difference, it is rarely appropriate for applications to directly compare CRI references; instead, the references are typically resolved to their respective CRI before comparison.

CBOR Representation RFC Ed.: throughout this section, please replace RFC-XXXX with the RFC number of this specification and remove this note. A CRI or CRI reference is encoded as a CBOR array (Major type 4 in Section of RFC 8949 ). has a coarse visualization of the structure of this array, without going into the details of the elements.

Overall Structure of a CRI or CRI Reference ─────────────────────╮ │ │ │ ╭──────────────>──────────────╮ │ │ │ │ │ │ │ ╭──────>───────╮ │ │ │ │ │ │ │ │ │├──╯── path ──╯── query ──╯── fragment ──╰──╰──╰──┤│ ]]> has a more detailed description of the structure, in CDDL.

CDDL for CRI CBOR representation We call the elements of the top-level array sections. The sections containing the rules scheme, authority, path, query, fragment correspond to the components of a URI and thus of a CRI, as described in . For use in CRI references, the discard section (see also ) provides an alternative to the scheme and authority sections. This CDDL specification is simplified for exposition and needs to be augmented by the following rules for interchange of CRIs and CRI references:

Trailing default values () MUST be removed.
Two leading null values (scheme and authority both not given) MUST be represented by using the discard alternative instead.
An empty path in a CRI MUST be represented as the empty array []. Note that for CRI-Reference there is a difference between empty and absent paths, represented by [] and null, respectively.
An empty outer array ([]) is not a valid CRI. It is a valid CRI reference, equivalent to [0] as per , which essentially copies the base CRI up to and including the path section, unsetting query and fragment.

Default Values for CRI Sections

Section	Default Value
scheme	–
authority	`null`
discard	`0`
path	`[]`
query	`null`
fragment	`null`

Application specifications that use CRIs may explicitly enable the use of "stand-in" items (tags or simple values). These are data items used in place of original representation items such as strings or arrays, where the tag or simple value is defined to stand for a data item that can be used in the position of the stand-in item. Examples would be (1) tags such as 21 to 23 (Section of RFC 8949 ) or 108 (), which stand for text string components but internally employ more compact byte string representations, or (2) reference tags and simple values as defined in . Note that application specifications need to be explicit about which stand-in items are allowed; otherwise, inconsistent interpretations at different places in a system can lead to check/use vulnerabilities. For interchange as separate encoded data items, CRIs MUST NOT use indefinite length encoding (see Section of RFC 8949 ). This requirement is relaxed for specifications that embed CRIs into an encompassing CBOR representation that does provide for indefinite length encoding; those specifications that are selective in where they provide for indefinite length encoding are RECOMMENDED to not provide it for embedded CRIs.

scheme-name and scheme-id In the scheme section, a CRI scheme can be given by its scheme-name (a text string giving the scheme name as in URIs' scheme section, mapped to lower case), or as a negative integer scheme-id derived from the scheme number. Scheme numbers are unsigned integers that are mapped to and from URI scheme names by the "CRI Scheme Numbers" registry (). The relationship of a scheme number to its scheme-id is as follows: For example, the scheme-name coap has the (unsigned integer) scheme-number 0 which is represented in a (negative integer) scheme-id -1.

The discard Section The discard section can be used in a CRI reference when neither a scheme nor an authority is present. It then expresses the operations performed on a base CRI by CRI references that are equivalent to URI references with relative paths and path prefixes such as "/", "./", "../", "../../", etc.
"." and ".." are not available in CRIs and are therefore expressed using discard after a normalization step, as is the presence or absence of a leading "/". E.g., a simple URI reference "foo" specifies to remove one leading segment from the base URI's path, which is represented in the equivalent CRI reference discard section as the value 1; similarly "../foo" removes two leading segments, represented as 2; and "/foo" removes all segments, represented in the discard section as the value true. The exact semantics of the section values are defined by . Most URI references that Section of RFC 3986 calls "relative references" (i.e., references that need to undergo a resolution process to obtain a URI) correspond to the CRI reference form that starts with discard. The exception are relative references with an authority (called a "network-path reference" in Section of RFC 3986 ), which discard the entire path of the base CRI. These CRI references never carry a discard section: the value of discard defaults to true.

Examples

CRI for coap://198.51.100.1:61616/.well-known/core

CRI Reference for /.well-known/core?rt=temperature-c

CRI for did:web:alice:bob

Specific Terminology A CRI reference is considered well-formed if it matches the structure as expressed in in CDDL, with the additional requirement that trailing null values are removed from the array. A CRI reference is considered a full CRI if it is well-formed and the sequence of sections starts with a non-null scheme. A CRI reference is considered relative if it is well-formed and the sequence of sections is empty or starts with a section other than those that would constitute a scheme.

Ingesting and encoding a CRI Reference From an abstract point of view, a CRI reference is a data structure with six sections: scheme, authority, discard, path, query, fragment We refer to this as the abstract form, while the interchange form () has either two sections for scheme and authority or one section for discard, but never both of these alternatives. Each of the sections in the abstract form can be unset ("null"), except for discard, which is always an unsigned integer or true. If scheme and/or authority are non-null, discard is set to true. When ingesting a CRI reference that is in interchange form, those sections are filled in from interchange form (unset sections are filled with null), and the following steps are performed:

If the array is empty, replace it with [0].
If discard is present in interchange form (i.e., the outer array starts with true or an unsigned integer), set scheme and authority to null.
If scheme and/or authority are present in interchange form (i.e., the outer array starts with null, a text string, or a negative integer), set discard to true.

Upon encoding the abstract form into interchange form, the inverse processing is performed: If scheme and/or authority are not null, the discard value is not transferred (it must be true in this case). If they are both null, they are both left out and only discard is transferred. Trailing null values are removed from the array. As a special case, an empty array is sent in place for a remaining [0] (URI reference "").

Error handling and extensibility It is recommended that specifications that describe the use of CRIs in CBOR-based protocols use the error handling mechanisms outlined in this section. Implementations of this document MUST adhere to these rules unless a containing document overrides them. When encountering a CRI that is well-formed in terms of CBOR, but that

is not well-formed as a CRI,
does not meet the other requirements on CRIs that are not covered by the term "well-formed", or
uses features not supported by the implementation,

the CRI is treated as "unprocessable". When encountering an unprocessable CRI, the processor skips the entire CRI top-level array, including any CBOR items contained in there, and continues processing the CBOR items surrounding the unprocessable CRI. (Note: this skipping can be implemented in bounded memory for CRIs that do not use indefinite length encoding, as mandated in .) The unprocessable CRI is treated as an opaque identifier that is distinct from all processable CRIs, and distinct from all unprocessable CRIs with different CBOR representations. It is up to the implementation whether unprocessable CRIs with identical representations are treated as identical to each other or not. Unprocessable CRIs cannot be dereferenced, and it is an error to query any of their components. This mechanism ensures that CRI extensions (using originally defined features or later extensions) can be used without extending the compatibility hazard to the containing document. For example, if a collection of possible interaction targets contains several CRIs, some of which use the "no-authority" feature, an application consuming that collection that does not support that feature can still offer the supported interaction targets. The duty of checking validity is with the recipients that rely on this validity. An intermediary that does not use the detailed information in a CRI (or merely performs reference resolution) MAY pass on a CRI/CRI reference without having fully checked it, relying on the producer having generated a valid CRI/CRI reference. This is true for both basic CRIs (e.g., checking for valid UTF-8) and for extensions (e.g., checking both for valid UTF-8 and the minimal use of PET elements in extended-cris as per ). A system that is checking a CRI for some reason but is not its ultimate recipient needs to consider the tension between security requirements and the danger of ossification : If the system rejects anything that it does not know, it prevents the other components from making use of extensions. If it passes through extensions unknown to it, that might allow semantics pass through that the system should have been designed to filter out.

Reference Resolution The term "relative" implies that a "base CRI" exists against which the relative reference is applied. Aside from fragment-only references, relative references are only usable when a base CRI is known. The following steps define the process of resolving any well-formed CRI reference against a base CRI so that the result is a full CRI in the form of an CRI reference:

Establish the base CRI of the CRI reference (compare Section of RFC 3986 ) and express it in the form of an abstract (full) CRI reference.
Initialize a buffer with the sections from the base CRI.
If the value of discard is true in the CRI reference (which is implicitly the case when scheme and/or authority are present in the reference), replace the path in the buffer with the empty array, unset query and fragment, and set a true authority to null. If the value of discard is an unsigned integer, remove as many elements from the end of the path array; if it is non-zero, unset query and fragment. Set discard to true in the buffer.
If the path section is set in the CRI reference, append all elements from the path array to the array in the path section in the buffer; unset query and fragment.
Apart from the path and discard, copy all non-null sections from the CRI reference to the buffer in sequence; unset query in the buffer if query is the empty array [] in the CRI reference; unset fragment in the buffer if query is non-null in the CRI reference.
Return the sections in the buffer as the resolved CRI.

Relationship between CRIs, URIs, and IRIs CRIs are meant to replace both Uniform Resource Identifiers (URIs) and Internationalized Resource Identifiers (IRIs) in constrained environments . Applications in these environments may never need to use URIs and IRIs directly, especially when the resource identifier is used simply for identification purposes or when the CRI can be directly converted into a CoAP request. However, it may be necessary in other environments to determine the associated URI or IRI of a CRI, and vice versa. Applications can perform these conversions as follows:

CRI to URI: A CRI is converted to a URI as specified in .
URI to CRI: The method of converting a URI to a CRI is unspecified; implementations are free to use any algorithm as long as converting the resulting CRI back to a URI yields an equivalent URI. Note that CRIs are defined to enable implementing conversions from or to URIs analogously to processing URIs into CoAP Options and back, with the exception that item 8 of and item 7 of do not apply to CRI processing. See in for more details.
CRI to IRI: A CRI can be converted to an IRI by first converting it to a URI as specified in , and then converting the URI to an IRI as described in .
IRI to CRI: An IRI can be converted to a CRI by first converting it to a URI as described in , and then converting the URI to a CRI as described above.

Everything in this section also applies to CRI references, URI references, and IRI references.

Converting CRIs to URIs Applications MUST convert a CRI reference to a URI reference by determining the components of the URI reference according to the following steps and then recomposing the components to a URI reference string as specified in Section of RFC 3986 .

scheme: If the CRI reference contains a scheme section, the scheme component of the URI reference consists of the value of that section, if text (scheme-name); or, if a negative integer is given (scheme-id), the lower case scheme name corresponding to the scheme-id as per . Otherwise, the scheme component is unset.
authority: If the CRI reference contains a host-name or host-ip item, the authority component of the URI reference consists of a host subcomponent, optionally followed by a colon (":") character and a port subcomponent, optionally preceded by a userinfo subcomponent. Otherwise, the authority component is unset. The host subcomponent consists of the value of the host-name or host-ip item. The userinfo subcomponent, if present, is turned into a single string by appending a "@". Otherwise, both the subcomponent and the "@" sign are omitted. Any character in the value of the userinfo element that is not in the set of unreserved characters (Section of RFC 3986 ) or "sub-delims" (Section of RFC 3986 ) or a colon (":") MUST be percent-encoded. The host-name is turned into a single string by joining the elements separated by dots ("."). Any character in the elements of a host-name item that is not in the set of unreserved characters (Section of RFC 3986 ) or "sub-delims" (Section of RFC 3986 ) MUST be percent-encoded. If there are dots (".") in such elements, the conversion fails (percent-encoding is not able to represent such elements, as normalization would turn the percent-encoding back to the unreserved character that a dot is.)
Implementations with scheme-specific knowledge MAY convert individual elements by using the ToASCII procedure as discussed in more detail in . This should not be done if the next step of conversion is to an IRI as defined in (CRI to IRI).
The value of a host-ip item MUST be represented as a string that matches the "IPv4address" or "IP-literal" rule (Section of RFC 3986 ). Any zone-id is appended to the string; the details for how this is done are currently in flux in the URI specification: uses percent-encoding and a separator of "%25", while proposals for a future superseding zone-id specification document (such as ) are being prepared; this also leads to a modified "IP-literal" rule as specified in these documents. While the discussion about the representation of zone-id information in URIs is ongoing, CRIs maintain a position in the grammar for it (zone-id). This can be used by consenting implementations to exchange zone information without being concerned by the ambiguity at the URI syntax level. The assumption is that the present specification (1) either will be updated eventually to obtain consistent URI conversion of zone-id information (2) or there will be no representation of zone-id information in URIs. If the CRI reference contains a port item, the port subcomponent consists of the value of that item in decimal notation. Otherwise, the colon (":") character and the port subcomponent are both omitted.
path: If the CRI reference contains a discard item of value true, the path component is considered rooted. If it contains a discard item of value 0 and the path item is present, the conversion fails. If it contains a positive discard item, the path component is considered unrooted and prefixed by as many "../" components as the discard value minus one indicates. If the discard value is 1 and the first element of the path contains a :, the path component is prefixed by "./" (this avoids the first element to appear as supplying a URI scheme; compare path-noscheme in Section of RFC 3986 ). If the discard item is not present and the CRI reference contains an authority that is true, the path component of the URI reference is considered unrooted. Otherwise, the path component is considered rooted. If the CRI reference contains one or more path items, the path component is constructed by concatenating the sequence of representations of these items. These representations generally contain a leading slash ("/") character and the value of each item, processed as discussed below. The leading slash character is omitted for the first path item only if the path component is considered "unrooted". Any character in the value of a path item that is not in the set of unreserved characters or "sub-delims" or a colon (":") or commercial at ("@") character MUST be percent-encoded. If the authority component is present (not null or true) and the path component does not match the "path-abempty" rule (Section of RFC 3986 ), the conversion fails. If the authority component is not present, but the scheme component is, and the path component does not match the "path-absolute", "path-rootless" (authority == true) or "path-empty" rule (Section of RFC 3986 ), the conversion fails. If neither the authority component nor the scheme component are present, and the path component does not match the "path-absolute", "path-noscheme" or "path-empty" rule (Section of RFC 3986 ), the conversion fails.
query: If the CRI reference contains one or more query items, the query component of the URI reference consists of the value of each item, separated by an ampersand ("&") character. Otherwise, the query component is unset. Any character in the value of a query item that is not in the set of unreserved characters or "sub-delims" or a colon (":"), commercial at ("@"), slash ("/"), or question mark ("?") character MUST be percent-encoded. Additionally, any ampersand character ("&") in the item value MUST be percent-encoded.
fragment: If the CRI reference contains a fragment item, the fragment component of the URI reference consists of the value of that item. Otherwise, the fragment component is unset. Any character in the value of a fragment item that is not in the set of unreserved characters or "sub-delims" or a colon (":"), commercial at ("@"), slash ("/"), or question mark ("?") character MUST be percent-encoded.

Extending CRIs CRIs have been designed to relieve implementations operating on CRIs from string scanning, which both helps constrained implementations and implementations that need to achieve high throughput. The CRI structure described up to this point is termed the Basic CRI. It should be sufficient for all applications that use the CoAP protocol, as well as most other protocols employing URIs. However, Basic CRIs have one limitation: They do not support URI components that require percent-encoding (Section of RFC 3986 ) to represent them in the URI syntax, except where that percent-encoding is used to escape the main delimiter in use. E.g., the URI is represented by the basic CRI However, percent-encoding that is used at the application level is not supported by basic CRIs: Extended forms of CRIs may be defined to enable these applications. They will generally extend the potential values of text components of URIs, such as userinfo, hostnames, paths, queries, and fragments. One such extended form is described in the following . Consumers of CRIs will generally notice when an extended form is in use, by finding structures that do not match the CDDL rules given in . Future definitions of extended forms need to strive to be distinguishable in their structures from the extended form presented here as well as other future forms. Extensions to CRIs MUST NOT allow indefinite length items. This provision ensures that recipients of CRIs can deal with unprocessable CRIs as described in .

Extended CRI: Accommodating Percent Encoding (PET) This section presents a method to represent percent-encoded segments of userinfo, hostnames, paths, and queries, as well as fragments. The four CDDL rules are replaced with That is, for each of the host-name, path, and query segments, and for the userinfo and fragment components, an alternate representation is provided besides a simple text string: a non-empty array of alternating non-blank text and byte strings, the text strings of which stand for non-percent-encoded text, while the byte strings retain the special semantics of percent-encoded text without actually being percent-encoded. The above DID URI can now be represented as: (Note that, in CBOR diagnostic notation, single quotes delimit literals for byte strings, double quotes for text strings.) To yield a valid extended-cri, the use of byte strings MUST be minimal. Both the following examples are therefore not valid: An algorithm for constructing a valid text-pet-sequence might repeatedly examine the byte sequences in each byte string; if such a sequence stands for an unreserved ASCII character, or constitutes a valid UTF-8 character ≥ U+0080, move this character over into a text string by appending it to the end of the preceding text string, prepending it to the start of the following text string, or splitting the byte string and inserting a new text string with this character, all while preserving the order of the bytes. (Note that the properties of UTF-8 make this a simple linear process.)

Integration into CoAP and ACE This section discusses ways in which CRIs can be used in the context of the CoAP protocol and of Authorization for Constrained Environments (ACE), specifically the Authorization Information Format (AIF) .

Converting Between CoAP CRIs and Sets of CoAP Options This section provides an analogue to Sections and of : Computing a set of CoAP options from a request CRI () and computing a request CRI from a set of COAP options (). This section makes use of the mapping between CRI scheme numbers and URI scheme names shown in : Mapping CRI scheme numbers and URI scheme names

CRI scheme number	URI scheme name
0	coap
1	coaps
6	coap+tcp
7	coaps+tcp
8	coap+ws
9	coaps+ws

Decomposing a Request CRI into a set of CoAP Options The steps to parse a request's options from a CRI »cri« are as follows. These steps either result in zero or more of the Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options being included in the request or they fail. Where the following speaks of deriving a text-string for a CoAP Option value from a data item in the CRI, the presence of any text-pet-sequence subitem () in this item fails this algorithm.

If »cri« is not a full CRI, then fail this algorithm.
Translate the scheme-id into a URI scheme name as per and ; if a scheme-id that corresponds to a scheme number not in this list is being used, or if a scheme-name is being used, fail this algorithm. Remember the specific variant of CoAP to be used based on this URI scheme name.
If »cri« has a fragment component, then fail this algorithm.
If the host component of »cri« is a host-name, include a Uri-Host Option and let that option's value be the text string value of the host-name. If the host component of »cri« is a host-ip, check whether the IP address given represents the request's destination IP address (and, if present, zone-id). Only if it does not, include a Uri-Host Option, and let that option's value be the text value of the URI representation of the IP address, as derived in .
If »cri« has a port component, then let »port« be that component's unsigned integer value; otherwise, let »port« be the default port number for the scheme.
If »port« does not equal the request's destination port, include a Uri-Port Option and let that option's value be »port«.
If the value of the path component of »cri« is empty or consists of a single empty string, then move to the next step. Otherwise, for each element in the »path« component, include a Uri-Path Option and let that option's value be the text string value of that element.
If »cri« has a query component, then, for each element in the query component, include a Uri-Query Option and let that option's value be the text string value of that element.

Composing a Request CRI from a Set of CoAP Options The steps to construct a CRI from a request's options are as follows. These steps either result in a CRI or they fail.

Based on the variant of CoAP used in the request, choose a scheme-id as per and table . Use that as the first value in the resulting CRI array.
If the request includes a Uri-Host Option, insert an authority with its value determined as follows: If the value of the Uri-Host Option is a reg-name, include this as the host-name. If the value is an IP-literal or IPv4address, extract any zone-id, and represent the IP address as a byte string of the correct length in host-ip, followed by any zone-id extracted if present. If the value is none of the three, fail this algorithm. If the request does not include a Uri-Host Option, insert an authority with host-ip being the byte string that represents the request's destination IP address and, if one is present in the request's destination, add a zone-id.
If the request includes a Uri-Port Option, let »port« be that option's value. Otherwise, let »port« be the request's destination port. If »port« is not the default port for the scheme, then insert the integer value of »port« as the value of port in the authority. Otherwise, elide the port.
Insert a path component that contains an array built from the text string values of the Uri-Path Options in the request, or an empty array if no such options are present.
Insert a query component that contains an array built from the text string values of the Uri-Query Options in the request, or an empty array if no such options are present.

CoAP Options for Forward-Proxies Apart from the above procedures to convert CoAP CRIs to and from sets of CoAP Options, two additional CoAP Options are defined in that support requests to forward-proxies:

Proxy-Uri, and
its more lightweight variant, Proxy-Scheme

This section defines analogues of these that employ CRIs and the URI Scheme numbering provided by the present specification.

Proxy-CRI Proxy-Cri CoAP Option

No.	C	U	N	R	Name	Format	Length	Default
TBD235	x	x	-		Proxy-Cri	opaque	1-1023	(none)

The Proxy-CRI Option carries an encoded CBOR data item that represents a full CRI. It is used analogously to Proxy-Uri as defined in . The Proxy-Cri Option MUST take precedence over any of the Uri-Host, Uri-Port, Uri-Path or Uri-Query options, as well as over any Proxy-Uri Option (each of which MUST NOT be included in a request containing the Proxy-Cri Option).

Proxy-Scheme-Number Proxy-Scheme-Number CoAP Option

No.	C	U	N	R	Name	Format	Length	Default
TBD239	x	x	-		Proxy-Scheme-Number	uint	0-3	(none)

The Proxy-Scheme-Number Option carries a CRI Scheme Number represented as a CoAP unsigned integer. It is used analogously to Proxy-Scheme as defined in . The Proxy-Scheme-Number Option MUST take precedence over any Proxy-Scheme Option, which MUST NOT be included in a request containing the Proxy-Scheme-Number Option. As per , CoAP Options are only defined as one of empty, (text) string, opaque (byte string), or uint (unsigned integer). The Option therefore carries an unsigned integer that represents the CRI scheme-number (which relates to a CRI scheme-id as defined in ). For instance, the scheme name "coap" has the scheme-number 0 and is represented as an unsigned integer by a zero-length CoAP Option value.

ACE AIF The AIF (Authorization Information Format, ) defined by ACE by default uses the local part of a URI to identify a resource for which authorization is indicated. The type and target of this information is an extension point, briefly called Toid (Type of object identifier). registers "CRI-local-part" as a Toid. Together with Tperm, an extension point for a way to indicate individual access rights (permissions), defines its general Information Model as: = [* [Toid, Tperm]] ]]> Using the definitions in together with the default Tperm choice REST-method-set, this information model can be specialized as in: ]]>

Implementation Status (Boilerplate as per :) This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". With the exception of the authority=true fix, host-names split into labels, and , CRIs are implemented in https://gitlab.com/chrysn/micrurus. A golang implementation of version -10 of this document is found at: https://github.com/thomas-fossati/href

Security Considerations Parsers of CRI references must operate on input that is assumed to be untrusted. This means that parsers MUST fail gracefully in the face of malicious inputs. Additionally, parsers MUST be prepared to deal with resource exhaustion (e.g., resulting from the allocation of big data items) or exhaustion of the call stack (stack overflow). See Section of RFC 8949 for additional security considerations relating to CBOR. The security considerations discussed in Section of RFC 3986 and for URIs and IRIs also apply to CRIs. The security considerations discussed for URIs in apply analogously to AIF-CRI .

IANA Considerations

CRI Scheme Numbers Registry This specification defines a new "CRI Scheme Numbers" registry in the "Constrained RESTful Environments (CoRE) Parameters" registry group , with the policy "Expert Review" (Section of RFC 8126 ). The objective is to have CRI scheme number values registered for all registered URI schemes (Uniform Resource Identifier (URI) Schemes registry), as well as exceptionally for certain text strings that the Designated Expert considers widely used in constrained applications in place of URI scheme names.

Instructions for the Designated Expert The expert is instructed to be frugal in the allocation of CRI scheme number values whose scheme-id values () have short representations (1+0 and 1+1 encoding), keeping them in reserve for applications that are likely to enjoy wide use and can make good use of their shortness. When the expert notices that a registration has been made in the Uniform Resource Identifier (URI) Schemes registry (see also ), the expert is requested to initiate a parallel registration in the CRI Scheme Numbers registry. CRI scheme number values in the range between 1000 and 20000 (inclusive) should be assigned unless a shorter representation in CRIs appears desirable. The expert exceptionally also may make such a registration for text strings that have not been registered in the Uniform Resource Identifier (URI) Schemes registry if and only if the expert considers them to be in wide use in place of URI scheme names in constrained applications. (Note that registrations in the CRI Scheme Numbers registry are oblivious to the details of any URI Schemes registry registration, so if a registration is later made in the URI Schemes registry that uses such a previously unregistered text string as a name, the CRI Scheme Numbers registration simply stays in place, even if the URI Schemes registration happens to be for something different from what the expert had in mind at the time for the CRI Scheme Numbers registration. Also note that the initial registrations in already include such registrations for the text strings "mqtt" and "mqtts".) A registration in the CRI Scheme Numbers registry does not imply that a URI scheme under this name exists or has been registered in the Uniform Resource Identifier (URI) Schemes registry -- it essentially is only providing an integer identifier for an otherwise uninterpreted text string. Any questions or issues that might interest a wider audience might be raised by the expert on the core-parameters@ietf.org mailing list for a time-limited discussion.

Structure of Entries Each entry in the registry must include:

CRI scheme number:: An unsigned integer unique in this registry
URI scheme name:: a text string that would be acceptable for registration as a URI Scheme Name in the Uniform Resource Identifier (URI) Schemes registry
Reference:: a reference to a document, if available, or the registrant

The Reference field can simply be a copy of the reference field for the URI-Scheme registration if that exists. If not, it can contain helpful information (including the name of the registrant) that may be available for the registration, with the expectation that this will be updated if a URI-Scheme registration under that URI scheme name is later made.

Initial Registrations The initial registrations for the CRI Scheme Numbers registry are provided in .

Update to "Uniform Resource Identifier (URI) Schemes" Registry RFC 7595 is updated to add the following note in the "Uniform Resource Identifier (URI) Schemes" Registry :

The CRI Scheme Numbers Registry registers numeric identifiers for what essentially are URI Scheme names. Registrants for the Uniform Resource Identifier (URI) Schemes Registry are requested to make a parallel registration in the CRI Scheme Numbers registry. The number for this registration will be assigned by the Designated Expert for that registry.

CBOR Diagnostic Notation Application-extension Identifiers Registry In the "Application-Extension Identifiers" registry in the "CBOR Diagnostic Notation" registry group [IANA.cbor-diagnostic-notation], IANA is requested to register the application-extension identifier cri as described in and defined in . CBOR Extended Diagnostic Notation (EDN) Application-extension Identifier for CRI

Application-extension Identifier	Description	Change Controller	Reference
cri	Constrained Resource Identifier	IETF	RFC-XXXX,

RFC Ed.: throughout this section, please replace RFC-XXXX with the RFC number of this specification and remove this note.

CoAP Option Numbers Registry In the "CoAP Option Numbers" registry in the "CoRE Parameters" registry group , IANA is requested to register the CoAP Option Numbers as described in and defined in . New CoAP Option Numbers

No.	Name	Reference
TBD235	Proxy-Cri	RFC-XXXX
TBD239	Proxy-Scheme-Number	RFC-XXXX

RFC Ed.: throughout this section, please replace RFC-XXXX with the RFC number of this specification and remove this note.

Media-Type subparameters for ACE AIF In the "Sub-Parameter Registry for application/aif+cbor and application/aif+json" in the "Media Type Sub-Parameter Registries" registry group , IANA is requested to register: ACE AIF Toid for CRI

Parameter	Name	Description/Specification	Reference
Toid	CRI-local-part	local-part of CRI	of RFC-XXXX

RFC Ed.: throughout this section, please replace RFC-XXXX with the RFC number of this specification and remove this note.

Content-Format for CRI in AIF IANA is requested to register a Content-Format identifier in the "CoAP Content-Formats" registry (range 256-999), within the "Constrained RESTful Environments (CoRE) Parameters" registry group , as follows: Content-Format for ACE AIF with CRI-local-part Toid

Content Type	Content Coding	ID	Reference
application/aif+cbor;Toid=CRI-local-part	-	TBD	RFC-XXXX

RFC Ed.: throughout this section, please replace RFC-XXXX with the RFC number of this specification and remove this note.

References Normative References Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internationalized Resource Identifiers (IRIs) This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers This document describes how the zone identifier of an IPv6 scoped address, defined as 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. Guidelines and Registration Procedures for URI Schemes This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. Uniform Resource Identifier (URI) Schemes IANA Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Media Type Sub-Parameter Registries IANA An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things. This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path. Constrained RESTful Environments (CoRE) Parameters IANA Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Unicode Standard, Version 13.0.0 The Unicode Consortium Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Additional Control Operators for the Concise Data Definition Language (CDDL) The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. Packed CBOR Universität Bremen TZI TUD Dresden University of Technology The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // The present version (-14) adds additional stand-in items to the // previously updated implementation draft -13, with minor editorial // improvements. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Internationalizing Domain Names in Applications (IDNA) Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK] Terminology for Constrained-Node Networks The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. Terminology for Constrained-Node Networks Universität Bremen TZI Ericsson Universitat Politecnica de Catalunya The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Uniform Resource Names (URNs) A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. Web Linking This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. URI Design and Ownership Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic. This document provides guidance on the specification of URI substructure in standards. This document obsoletes RFC 7320 and updates RFC 3986. HTML 5.2 CBOR Extended Diagnostic Notation (EDN) Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present // revision (–16) addresses the first half of the WGLC comments, // except for the issues around the specific way how to best achieve // pluggable ABNF grammars for application-extensions. It is // intended for use as a reference document for the mid-WGLC CBOR WG // interim meeting on 2025-01-08. Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers Apple Inc. Check Point Software This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> 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 and Internationalized Resource Identifier specifications (RFC 3986, RFC 3987) accordingly, and obsoletes RFC 6874. Notable CBOR Tags Universität Bremen TZI The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 190 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. Constrained Resource Identifiers Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of in a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 to add a note on how the URI Schemes registry RFC 7595 describes cooperates with the CRI Scheme Numbers registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –18 integrates two small changes from the CoRE // interim on 2025-01-29 and should be ready for WGLC. Long-Term Viability of Protocol Extension Mechanisms The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. Greenspun's tenth rule Wikipedia Modern Network Unicode Universität Bremen TZI BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Common Format and MIME Type for Comma-Separated Values (CSV) Files This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community.

Mapping Scheme Numbers to Scheme Names RFC Ed.: throughout this section, please replace RFC-XXXX with the RFC number of this specification and remove this note. Table 8 in lists the initial mapping from CRI scheme numbers to URI scheme names. (This table was developed with a previous revision of the Internet-Draft of the RFC derived from this document but is not copied into the current draft or the actual RFC because it will be out-of-date quickly, and because the IANA registry should be the focal point for users of this registry, anyway.) The assignments from this table can be extracted from the XML form of (when stored in a file "this.xml") into CSV form using this short Ruby program:

The Small Print This appendix lists a few corner cases of URI semantics that implementers of CRIs need to be aware of, but that are not representative of the normal operation of CRIs.

Initial (Lone/Leading) Empty Path Segments:

Lone empty path segments: As per , s://x is distinct from s://x/ -- i.e., a URI with an empty path ([] in CRI) is different from one with a lone empty path segment ([""]). However, in HTTP and CoAP, they are implicitly aliased (for CoAP, in item 8 of ). As per item 7 of , recomposition of a URI without Uri-Path Options from the other URI-related CoAP Options produces s://x/, not s://x -- CoAP prefers the lone empty path segment form. Similarly, after discussing HTTP semantics, Section of RFC 3986 states:

In general, a URI that uses the generic syntax for authority with an empty path should be normalized to a path of "/".

Leading empty path segments without authority: Somewhat related, note also that URIs and URI references that do not carry an authority cannot represent leading empty path segments (i.e., that are followed by further path segments): s://x//foo works, but in a s://foo URI or an (absolute-path) URI reference of the form //foo the double slash would be mis-parsed as leading in to an authority.

Constraints () of CRIs/basic CRIs While most URIs in everyday use can be converted to CRIs and back to URIs matching the input after syntax-based normalization of the URI, these URIs illustrate the constraints by example:
- https://host%ffname, https://example.com/x?data=%ff All URI components must, after percent decoding, be valid UTF-8 encoded text. Bytes that are not valid UTF-8 show up, for example, in BitTorrent web seeds. These URIs can be expressed when using the extended-cri feature.
- https://example.com/component%3bone;component%3btwo, http://example.com/component%3dequals While delimiters can be used in an escaped and unescaped form in URIs with generally distinct meanings, basic CRIs (i.e., without percent-encoded text ) only support one escapable delimiter character per component, which is the delimiter by which the component is split up in the CRI. Note that the separators . (for authority parts), / (for paths), & (for query parameters) are special in that they are syntactic delimiters of their respective components in CRIs. Thus, the following examples are convertible to basic CRIs without the extended-cri feature: https://example.com/path%2fcomponent/second-component https://example.com/x?ampersand=%26&questionmark=?
- https://alice@example.com/ The user information can be expressed in CRIs if the "userinfo" feature is present. The URI https://@example.com is represented as [-4, [false, "", "example", "com"]]; the false serves as a marker that the next element is the userinfo. The rules explicitly cater for unencoded ":" in userinfo (without needing the extended-cri feature). (We opted for including this syntactic feature instead of disabling it as a mechanism against potential uses of colons for the deprecated inclusion of unencrypted secrets.)

CBOR Extended Diagnostic Notation (EDN): The "cri" Extension more rigorously defines and further extends the CBOR Extended Diagnostic Notation (EDN), as originally introduced in Section of RFC 8949 and extended in . Among others, it provides an extension point for "application-extension identifiers" that can be used to notate CBOR data items in application-specific ways. The present document defines and registers () the application-extension identifier "cri", which can be used to notate an EDN literal for a CRI reference as defined in this document. The text of the literal is a URI Reference as per or an IRI Reference as per . The value of the literal is a CRI reference that can be converted to the text of the literal using the procedure of . Note that there may be more than one CRI reference that can be converted to the URI/IRI reference given; implementations are expected to favor the simplest variant available and make non-surprising choices otherwise. As an example, the CBOR diagnostic notation is equivalent to See for an ABNF definition for the content of cri literals.

cri: ABNF Definition of URI Representation of a CRI The syntax of the content of cri literals can be described by the ABNF for URI-reference in Section of RFC 3986 with certain re-arrangements taken from of ; these are reproduced in . If the content is not ASCII only (i.e., for IRIs), first apply and apply this grammar to the result.

ABNF Definition of URI Representation of a CRI segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":" pchar = unreserved / pct-encoded / sub-delims / ":" / "@" query = *( pchar / "/" / "?" ) fragment = *( pchar / "/" / "?" ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" ]]>

Change Log Changes from -16 to -17 (Provisional integration of active PRs, please see github.) Changes from -15 to -16

Add note that CRI Scheme Number registrations are oblivious of the actual URI Scheme registrations (if any).
Add information about how this RFC updates to abstract and introduction.

Changes from -14 to -15

Make scheme numbers unsigned and map them to negative numbers used as scheme-id values

Changes from -09 to -14

Editorial changes; move some examples to , break up railroad diagram; mention commonalities with (and tiny difference from) CoAP Options; mention failure of percent-encoding for dots in host-name components
Explicitly mention invalid case in (rootless CRIs without authority that do not have a path component)
Generalize , discuss PET (percent-encoded text) extension in more detail
Add registry of URI scheme numbers (, )
Add user information to the authority ("userinfo" feature)
: Use separate rule for CRI, allow [] for query in CRI Reference; generalize scheme numbers, add userinfo; add list of additional requirements in prose ()
Discuss ()
Conversion to URI: Handle : in first pathname component of a CRI-Reference ()
Add Christian Amsüss as contributor
Add CBOR EDN application-extension "cri" (see and ).
Add Section on CoAP integration (and new CoAP Options Proxy-Cri and Proxy-Scheme-Number).

Changes from -08 to -09

Identify more esoteric features with a CDDL ".feature".
Clarify that well-formedness requires removing trailing nulls.
Fragments can contain PET.
Percent-encoded text in PET is treated as byte strings.
URIs with an authority but a completely empty path (e.g., http://example.com): CRIs with an authority component no longer always produce at least a slash in the path component. For generic schemes, the conversion of scheme://example.com to a CRI is now possible because CRI produces a URI with an authority not followed by a slash following the updated rules of . Schemes like http and coap do not distinguish between the empty path and the path containing a single slash when an authority is set (as recommended in ). For these schemes, that equivalence allows implementations to convert the just-a-slash URI to a CRI with a zero length path array (which, however, when converted back, does not produce a slash after the authority). (Add an appendix "the small print" for more detailed discussion of pesky corner cases like this.)

Changes from -07 to -08

Fix the encoding of NOAUTH-NOSLASH / NOAUTH-LEADINGSLASH
Add URN and DID schemes, add example.
Add PET
Remove hopeless attempt to encode "remote trailing nulls" rule in CDDL (which is not a transformation language).

Changes from -06 to -07

More explicitly discuss constraints (), add examples ().
Make CDDL more explicit about special simple values.
Lots of gratuitous changes from XML2RFC redefinition of <tt> semantics.

Changes from -05 to -06

rework authority:
- split reg-names at dots;
- add optional zone identifiers to IP addresses

Changes from -04 to -05

Simplify CBOR structure.
Add implementation status section.

Changes from -03 to -04:

Minor editorial improvements.
Renamed path.type/path-type to discard.
Renamed option to section, substructured into items.
Simplified the table "resolution-variables".
Use the CBOR structure inspired by Jim Schaad's proposals.

Changes from -02 to -03:

Expanded the set of supported schemes (#3).
Specified creation, normalization and comparison (#9).
Clarified the default value of the path.type option (#33).
Removed the append-relation path.type option (#41).
Renumbered the remaining path.types.
Renumbered the option numbers.
Restructured the document.
Minor editorial improvements.

Changes from -01 to -02:

Changed the syntax of schemes to exclude upper case characters (#13).
Minor editorial improvements (#34 #37).

Changes from -00 to -01:

None.

Acknowledgements CRIs were developed by for use in the Constrained RESTful Application Language (CoRAL). The current author team is completing this work with a view to achieve good integration with the potential use cases, both inside and outside of CoRAL. Thanks to , , , , , and for helpful comments and discussions that have shaped the document.

Contributors Ericsson

Torshamnsgatan 23 Stockholm 16483 Sweden klaus.hartke@ericsson.com

Hollandstr. 12/4 Vienna 1020 Austria christian@amsuess.com