CoRE Working Group C. Bormann, Ed.
Internet-Draft Universität Bremen TZI
Updates: 7595 (if approved) H. Birkholz
Intended status: Standards Track Fraunhofer SIT
Expires: 4 September 2025 3 March 2025
Constrained Resource Identifiers
draft-ietf-core-href-19
Abstract
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
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-core-href/.
Discussion of this document takes place on the Constrained RESTful
Environments Working Group mailing list (mailto:core@ietf.org), which
is archived at https://mailarchive.ietf.org/arch/browse/core/.
Subscribe at https://www.ietf.org/mailman/listinfo/core/.
Source for this draft and an issue tracker can be found at
https://github.com/core-wg/href.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bormann & Birkholz Expires 4 September 2025 [Page 1]
Internet-Draft Constrained Resource Identifiers March 2025
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
2. From URIs to CRIs: Considerations and Constraints . . . . . . 5
2.1. The CRI interchange data model . . . . . . . . . . . . . 5
2.2. CRI References: The discard Component . . . . . . . . . . 8
2.3. Constraints not expressed by the data model . . . . . . . 8
3. Creation and Normalization . . . . . . . . . . . . . . . . . 9
4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. CRI References . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. CBOR Representation . . . . . . . . . . . . . . . . . . . 12
5.1.1. scheme-name and scheme-id . . . . . . . . . . . . . . 15
5.1.2. The discard Section . . . . . . . . . . . . . . . . . 15
5.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 16
5.1.4. Specific Terminology . . . . . . . . . . . . . . . . 16
5.2. Ingesting and encoding a CRI Reference . . . . . . . . . 17
5.2.1. Error handling and extensibility . . . . . . . . . . 17
5.3. Reference Resolution . . . . . . . . . . . . . . . . . . 19
6. Relationship between CRIs, URIs, and IRIs . . . . . . . . . . 19
6.1. Converting CRIs to URIs . . . . . . . . . . . . . . . . . 20
7. Extending CRIs . . . . . . . . . . . . . . . . . . . . . . . 23
Bormann & Birkholz Expires 4 September 2025 [Page 2]
Internet-Draft Constrained Resource Identifiers March 2025
7.1. Extended CRI: Accommodating Percent Encoding (PET) . . . 24
8. Integration into CoAP and ACE . . . . . . . . . . . . . . . . 26
8.1. Converting Between CoAP CRIs and Sets of CoAP Options . . 26
8.1.1. Decomposing a Request CRI into a set of CoAP
Options . . . . . . . . . . . . . . . . . . . . . . . 27
8.1.2. Composing a Request CRI from a Set of CoAP Options . 28
8.2. CoAP Options for Forward-Proxies . . . . . . . . . . . . 28
8.2.1. Proxy-CRI . . . . . . . . . . . . . . . . . . . . . . 29
8.2.2. Proxy-Scheme-Number . . . . . . . . . . . . . . . . . 29
8.3. ACE AIF . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11.1. CRI Scheme Numbers Registry . . . . . . . . . . . . . . 31
11.1.1. Instructions for the Designated Expert . . . . . . . 31
11.1.2. Structure of Entries . . . . . . . . . . . . . . . . 32
11.1.3. Initial Registrations . . . . . . . . . . . . . . . 33
11.2. Update to "Uniform Resource Identifier (URI) Schemes"
Registry . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3. CBOR Diagnostic Notation Application-extension Identifiers
Registry . . . . . . . . . . . . . . . . . . . . . . . . 33
11.4. CoAP Option Numbers Registry . . . . . . . . . . . . . . 33
11.5. Media-Type subparameters for ACE AIF . . . . . . . . . . 34
11.6. Content-Format for CRI in AIF . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Mapping Scheme Numbers to Scheme Names . . . . . . . 39
Appendix B. The Small Print . . . . . . . . . . . . . . . . . . 40
Appendix C. CBOR Extended Diagnostic Notation (EDN): The "cri"
Extension . . . . . . . . . . . . . . . . . . . . . . . . 42
C.1. cri: ABNF Definition of URI Representation of a CRI . . . 42
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction
The Uniform Resource Identifier (URI) [STD66] and its most common
usage, the URI reference, are the Internet standard for linking to
resources in hypertext formats such as HTML [W3C.REC-html52-20171214]
or the HTTP "Link" header field [RFC8288].
A URI reference is a sequence of characters chosen from the
repertoire of US-ASCII characters (Section 4.1 of RFC 3986 [STD66]).
The individual components of a URI reference are delimited by a
number of reserved characters, which necessitates the use of a
Bormann & Birkholz Expires 4 September 2025 [Page 3]
Internet-Draft Constrained Resource Identifiers March 2025
character escape mechanism called "percent-encoding" when these
reserved characters are used in a non-delimiting function. The
resolution of URI references (Section 5 of RFC 3986 [STD66]) 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 3.3 of
RFC 3986 [STD66]), 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
[RFC7228][I-D.ietf-iotops-7228bis], 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
[STD66] (aperçu adapted from [GREENSPUN-10]).
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) [STD94]
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 [STD66] (hence
the "constrained" in "Constrained Resource Identifier"). The
supported subset includes all URIs of the Constrained Application
Protocol (CoAP) [RFC7252], most URIs of the Hypertext Transfer
Protocol (HTTP) [STD97], Uniform Resource Names (URNs) [RFC8141], and
other similar URIs. The exact constraints are defined in Section 2.
CRI extensions (Section 7) can be defined to address some of the
constraints.
This RFC creates a "CRI Scheme Numbers" registry and updates RFC7595
to add a note on how this new registry cooperates with the "URI
Schemes" registry that RFC7595 describes.
Bormann & Birkholz Expires 4 September 2025 [Page 4]
Internet-Draft Constrained Resource Identifiers March 2025
1.1. 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
[BCP14] (RFC2119) (RFC8174) 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) [RFC8610] including its control extensions
[RFC9165]. Specific examples are notated in CBOR Extended Diagnostic
Notation (EDN), as originally introduced in Section 8 of RFC 8949
[STD94] and extended in Appendix G of [RFC8610].
([I-D.ietf-cbor-edn-literals] more rigorously defines and further
extends EDN.)
2. From URIs to CRIs: Considerations and Constraints
2.1. 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:
C1. The scheme name can be any Unicode string (see Definition D80
in [Unicode]) that matches the syntax of a URI scheme (see
Section 3.1 of RFC 3986 [STD66], which constrains scheme names
to ASCII) and is lowercase (see Definition D139 in [Unicode]).
The scheme is always present.
C2. 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 3.3 of RFC 3986 [STD66] are modeled by
two different values used in place of an absent authority:
Bormann & Birkholz Expires 4 September 2025 [Page 5]
Internet-Draft Constrained Resource Identifiers March 2025
* 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 Figure 2, no-authority is marked as a feature,
as not all CRI implementations will support authority-less
URIs.)
C3. A userinfo is a text string built out of unreserved characters
(Section 2.3 of RFC 3986 [STD66]) or "sub-delims" (Section 2.2
of RFC 3986 [STD66]); any other character needs to be percent-
encoded (Section 7.1). Note that this excludes the ":"
character, which is commonly deprecated as a way to delimit a
cleartext password in a userinfo.
C4. An IP address can be either an IPv4 address or an IPv6 address
(optionally with a zone identifier [RFC6874]; see Section 6.1,
Paragraph 2.4.7). 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).
C5. 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 [Unicode] and Section 3).
(The syntax may be further restricted by the scheme. As per
Section 3.2.2 of RFC 3986 [STD66], a registered name can be
empty, for which case a scheme can define a default for the
host.)
C6. 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 3.2.3 of RFC 3986 [STD66]), or ports
with redundant leading zeros, are not supported.
C7. 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.
C8. 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
Bormann & Birkholz Expires 4 September 2025 [Page 6]
Internet-Draft Constrained Resource Identifiers March 2025
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 6.2.2 of RFC 3986 [STD66]),
not on the scheme-specific Scheme-Based Normalization level
(Section 6.2.3 of RFC 3986 [STD66]).
(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
Section 6.4 of [RFC7252]. See also SP1 in Appendix B.)
C9. A path segment can be any Unicode string that is in NFC
(Section 3), 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 SP1 in Appendix B.)
C10. A query always consists of one or more query parameters. A
query parameter can be any Unicode string that is in NFC
Section 3. 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.
C11. A fragment identifier can be any Unicode string that is in NFC
Section 3. Fragment identifiers are optional; there is a
difference between an absent fragment identifier and a fragment
identifier that is the empty string.
C12. 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.
Bormann & Birkholz Expires 4 September 2025 [Page 7]
Internet-Draft Constrained Resource Identifiers March 2025
C13. 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 [Unicode]) 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 SP2 in Appendix B.
2.2. 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.
2.3. 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.
Bormann & Birkholz Expires 4 September 2025 [Page 8]
Internet-Draft Constrained Resource Identifiers March 2025
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 Section 6.1 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 [STD66], and thus never produce a normalized URI
after resolution.
(In CRI references, the discard value is used to afford segment
removal (see Section 2.2), 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 C9.)
* 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:.
3. Creation and Normalization
In general, resource identifiers are generated when a resource is
initially created or exposed under a certain resource identifier.
Bormann & Birkholz Expires 4 September 2025 [Page 9]
Internet-Draft Constrained Resource Identifiers March 2025
The naming authority that creates a Constrained Resource Identifier
SHOULD be the authority that governs the namespace of the resource
identifier (see also [BCP190]). 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 (Section 6.1)
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 Section 2. 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 (C1);
* map the registered name to NFC (C5) and split it on embedded dots;
* elide the port if it is the default port for the scheme (C7);
* map path segments, query parameters, and the fragment identifier
to NFC form (C9, C10, C11).
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 Appendix C of [MNU] for
some background.
Bormann & Birkholz Expires 4 September 2025 [Page 10]
Internet-Draft Constrained Resource Identifiers March 2025
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 6.2.2 of RFC 3986 [STD66]), 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.
4. 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
Section 2 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.
5. 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.
Section 5.1 first defines the representation of CRIs in Concise
Binary Object Representation (CBOR) [STD94]. 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 Section 5.1.
Bormann & Birkholz Expires 4 September 2025 [Page 11]
Internet-Draft Constrained Resource Identifiers March 2025
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 Section 5.3 (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.
5.1. 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 3.1 of RFC 8949 [STD94]). Figure 1 has a coarse
visualization of the structure of this array, without going into the
details of the elements.
cri-reference:
│├──╮── scheme ── authority ──╭── local-part ──┤│
│ │
╰──────── discard ────────╯
local-part:
╭─────────────────────>─────────────────────╮
│ │
│ ╭──────────────>──────────────╮ │
│ │ │ │
│ │ ╭──────>───────╮ │ │
│ │ │ │ │ │
│├──╯── path ──╯── query ──╯── fragment ──╰──╰──╰──┤│
Figure 1: Overall Structure of a CRI or CRI Reference
Figure 2 has a more detailed description of the structure, in CDDL.
Bormann & Birkholz Expires 4 September 2025 [Page 12]
Internet-Draft Constrained Resource Identifiers March 2025
; not expressed in this CDDL spec: trailing nulls to be left off
RFC-XXXX-Definitions = [CRI, CRI-Reference]
CRI = [
scheme,
authority / no-authority,
path, ; use [] for empty path
query / null,
fragment / null
]
CRI-Reference = [
((scheme / null, authority / no-authority)
// discard), ; relative reference
path / null,
query / [] / null, ; [] is explicit unset
fragment / null
]
scheme = scheme-name / scheme-id
scheme-name = text .regexp "[a-z][a-z0-9+.-]*"
scheme-id = nint ; -1 - scheme-number
no-authority = NOAUTH-ROOTBASED / NOAUTH-ROOTLESS
NOAUTH-ROOTBASED = null .feature "no-authority"
NOAUTH-ROOTLESS = true .feature "no-authority"
authority = [?userinfo, host, ?port]
userinfo = (false, text .feature "userinfo")
host = (host-ip // host-name)
host-name = (*text) ; lowercase, NFC labels
host-ip = (bytes .size 4 //
(bytes .size 16, ?zone-id))
zone-id = text
port = 0..65535
discard = DISCARD-ALL / 0..127
DISCARD-ALL = true
path = [*text]
query = [+text]
fragment = text
Figure 2: CDDL for CRI CBOR representation
Bormann & Birkholz Expires 4 September 2025 [Page 13]
Internet-Draft Constrained Resource Identifiers March 2025
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 Section 2. For use in CRI references, the discard section (see
also Section 2.2) 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 (Table 1) 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 Section 5.2, which essentially
copies the base CRI up to and including the path section,
unsetting query and fragment.
+-----------+---------------+
| Section | Default Value |
+-----------+---------------+
| scheme | – |
| authority | null |
| discard | 0 |
| path | [] |
| query | null |
| fragment | null |
+-----------+---------------+
Table 1: Default Values
for CRI Sections
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 3.4.5.2 of RFC
8949 [STD94]) or 108 (Section 2.1 of
[I-D.bormann-cbor-notable-tags]), which stand for text string
components but internally employ more compact byte string
Bormann & Birkholz Expires 4 September 2025 [Page 14]
Internet-Draft Constrained Resource Identifiers March 2025
representations, or (2) reference tags and simple values as defined
in [I-D.ietf-cbor-packed]. 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 3.2 of RFC 8949 [STD94]).
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.
5.1.1. 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 (Section 11.1). The relationship of a scheme number to its
scheme-id is as follows:
scheme-id = -1 - scheme-number
scheme-number = -1 - scheme-id
For example, the scheme-name coap has the (unsigned integer) scheme-
number 0 which is represented in a (negative integer) scheme-id -1.
5.1.2. 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
Section 5.3.
Bormann & Birkholz Expires 4 September 2025 [Page 15]
Internet-Draft Constrained Resource Identifiers March 2025
Most URI references that Section 4.2 of RFC 3986 [STD66] 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 4.2
of RFC 3986 [STD66]), which discard the entire path of the base CRI.
These CRI references never carry a discard section: the value of
discard defaults to true.
5.1.3. Examples
[-1, / scheme-id -- equivalent to "coap" /
[h'C6336401', / host /
61616], / port /
[".well-known", / path /
"core"]
]
Figure 3: CRI for coap://198.51.100.1:61616/.well-known/core
[true, / discard /
[".well-known", / path /
"core"],
["rt=temperature-c"] / query /
]
Figure 4: CRI Reference for /.well-known/core?rt=temperature-c
[-6, / scheme-id -- equivalent to "did" /
true, / authority = NOAUTH-ROOTLESS /
["web:alice:bob"] / path /
]
Figure 5: CRI for did:web:alice:bob
5.1.4. Specific Terminology
A CRI reference is considered _well-formed_ if it matches the
structure as expressed in Figure 2 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.
Bormann & Birkholz Expires 4 September 2025 [Page 16]
Internet-Draft Constrained Resource Identifiers March 2025
5.2. 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_
(Figure 2) 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 "").
5.2.1. 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,
Bormann & Birkholz Expires 4 September 2025 [Page 17]
Internet-Draft Constrained Resource Identifiers March 2025
* 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 Section 5.1.)
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 Section 7.1).
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 [RFC9170]: 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.
Bormann & Birkholz Expires 4 September 2025 [Page 18]
Internet-Draft Constrained Resource Identifiers March 2025
5.3. 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:
1. Establish the base CRI of the CRI reference (compare Section 5.1
of RFC 3986 [STD66]) and express it in the form of an abstract
(full) CRI reference.
2. Initialize a buffer with the sections from the base CRI.
3. 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.
4. 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.
5. 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.
6. Return the sections in the buffer as the resolved CRI.
6. Relationship between CRIs, URIs, and IRIs
CRIs are meant to replace both Uniform Resource Identifiers (URIs)
[STD66] and Internationalized Resource Identifiers (IRIs) [RFC3987]
in constrained environments [RFC7228][I-D.ietf-iotops-7228bis].
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.
Bormann & Birkholz Expires 4 September 2025 [Page 19]
Internet-Draft Constrained Resource Identifiers March 2025
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 Section 6.1.
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 Section 6.4 of [RFC7252]
and item 7 of Section 6.5 of [RFC7252] do not apply to CRI
processing. See SP1 in Appendix B for more details.
CRI to IRI
A CRI can be converted to an IRI by first converting it to a URI
as specified in Section 6.1, and then converting the URI to an IRI
as described in Section 3.2 of [RFC3987].
IRI to CRI
An IRI can be converted to a CRI by first converting it to a URI
as described in Section 3.1 of [RFC3987], 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.
6.1. 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 5.3 of RFC 3986 [STD66].
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 Section 5.1.1. Otherwise, the scheme component
is unset.
authority
Bormann & Birkholz Expires 4 September 2025 [Page 20]
Internet-Draft Constrained Resource Identifiers March 2025
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 2.3 of RFC 3986 [STD66]) or "sub-delims" (Section 2.2 of
RFC 3986 [STD66]) 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 2.3 of RFC 3986 [STD66]) or "sub-delims"
(Section 2.2 of RFC 3986 [STD66]) 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
| Section 4.1 of [RFC3490] as discussed in more detail in
| Section 3.1 of [RFC3987]. This should not be done if the
| next step of conversion is to an IRI as defined in Section 6
| (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 3.2.2 of
RFC 3986 [STD66]).
Any zone-id is appended to the string; the details for how this is
done are currently in flux in the URI specification: Section 2 of
[RFC6874] uses percent-encoding and a separator of "%25", while
proposals for a future superseding zone-id specification document
(such as [I-D.carpenter-6man-rfc6874bis]) 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
Bormann & Birkholz Expires 4 September 2025 [Page 21]
Internet-Draft Constrained Resource Identifiers March 2025
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 4.2 of RFC 3986 [STD66]).
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 3.3
of RFC 3986 [STD66]), 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 3.3 of RFC 3986 [STD66]), the conversion fails.
Bormann & Birkholz Expires 4 September 2025 [Page 22]
Internet-Draft Constrained Resource Identifiers March 2025
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 3.3 of
RFC 3986 [STD66]), 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.
7. 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 2.1 of RFC 3986
[STD66]) 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
https://alice/3%2f4-inch
is represented by the basic CRI
Bormann & Birkholz Expires 4 September 2025 [Page 23]
Internet-Draft Constrained Resource Identifiers March 2025
[-4, ["alice"], ["3/4-inch"]]
However, percent-encoding that is used at the application level is
not supported by basic CRIs:
did:web:alice:7%3A1-balun
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 Section 7.1.
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
Figure 2. 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 Section 5.2.1.
7.1. 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
userinfo = (false, text .feature "userinfo")
host-name = (*text)
path = [*text]
query = [+text]
fragment = text
are replaced with
Bormann & Birkholz Expires 4 September 2025 [Page 24]
Internet-Draft Constrained Resource Identifiers March 2025
userinfo = (false, text-or-pet .feature "userinfo")
host-name = (*text-or-pet)
path = [*text-or-pet]
query = [+text-or-pet]
fragment = text-or-pet
text-or-pet = text /
text-pet-sequence .feature "extended-cri"
; text1 and pet1 alternating, at least one pet1:
text-pet-sequence = [?text1, ((+(pet1, text1), ?pet1) // pet1)]
; pet is percent-encoded bytes
pet1 = bytes .ne ''
text1 = text .ne ""
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:
[-6, true, [["web:alice:7", ':', "1-balun"]]]
(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:
[-6, true, [["web:alice:", '7:', "1-balun"]]]
[-6, true, [["web:alice:7", ':1', "-balun"]]]
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.)
Bormann & Birkholz Expires 4 September 2025 [Page 25]
Internet-Draft Constrained Resource Identifiers March 2025
| Unlike the text elements of a path or a query, which through
| CoAP's heritage are designed to be processable element by
| element, a text-pet-sequence does not usually produce a
| semantically meaningful division into array elements. This
| consequence of the flexibility in delimiters offered in URIs is
| demonstrated by this example, which structurally singles out
| the one ':' that is _not_ a delimiter at the application level.
| Applications designed for using CRIs will generally avoid using
| the extended-cri feature. Applications using existing URI
| structures that require text-pet-sequence elements for their
| representation typically need to process them byte by byte.
8. Integration into CoAP and ACE
This section discusses ways in which CRIs can be used in the context
of the CoAP protocol [RFC7252] and of Authorization for Constrained
Environments (ACE), specifically the Authorization Information Format
(AIF) [RFC9237].
8.1. Converting Between CoAP CRIs and Sets of CoAP Options
This section provides an analogue to Sections 6.4 and 6.5 of
[RFC7252]: Computing a set of CoAP options from a request CRI
(Section 8.1.1) and computing a request CRI from a set of COAP
options (Section 8.1.2).
This section makes use of the mapping between CRI scheme numbers and
URI scheme names shown in Table 2:
+-------------------+-----------------+
| CRI scheme number | URI scheme name |
+-------------------+-----------------+
| 0 | coap |
| 1 | coaps |
| 6 | coap+tcp |
| 7 | coaps+tcp |
| 8 | coap+ws |
| 9 | coaps+ws |
+-------------------+-----------------+
Table 2: Mapping CRI scheme numbers
and URI scheme names
Bormann & Birkholz Expires 4 September 2025 [Page 26]
Internet-Draft Constrained Resource Identifiers March 2025
8.1.1. 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 (Section 7.1) in this item fails this algorithm.
1. If »cri« is not a full CRI, then fail this algorithm.
2. Translate the scheme-id into a URI scheme name as per
Section 5.1.1 and Table 2; 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.
3. If »cri« has a fragment component, then fail this algorithm.
4. 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 Section 6.1,
Paragraph 2.4.6.
5. 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.
6. If »port« does not equal the request's destination port, include
a Uri-Port Option and let that option's value be »port«.
7. 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.
Bormann & Birkholz Expires 4 September 2025 [Page 27]
Internet-Draft Constrained Resource Identifiers March 2025
8. 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.
8.1.2. 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.
1. Based on the variant of CoAP used in the request, choose a
scheme-id as per Section 5.1.1 and table Table 2. Use that as
the first value in the resulting CRI array.
2. 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.
3. 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.
4. 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.
5. 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.
8.2. 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
Section 5.10.2 of [RFC7252] that support requests to forward-proxies:
* Proxy-Uri, and
Bormann & Birkholz Expires 4 September 2025 [Page 28]
Internet-Draft Constrained Resource Identifiers March 2025
* 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.
8.2.1. Proxy-CRI
+--------+---+---+---+---+-----------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+--------+---+---+---+---+-----------+--------+--------+---------+
| TBD235 | x | x | - | | Proxy-Cri | opaque | 1-1023 | (none) |
+--------+---+---+---+---+-----------+--------+--------+---------+
Table 3: Proxy-Cri CoAP Option
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 Section 5.10.2 of [RFC7252]. 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).
8.2.2. Proxy-Scheme-Number
+--------+-+-+-+-+---------------------+--------+--------+---------+
| No. |C|U|N|R| Name | Format | Length | Default |
+--------+-+-+-+-+---------------------+--------+--------+---------+
| TBD239 |x|x|-| | Proxy-Scheme-Number | uint | 0-3 | (none) |
+--------+-+-+-+-+---------------------+--------+--------+---------+
Table 4: Proxy-Scheme-Number CoAP Option
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 Section 5.10.2 of [RFC7252]. 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 Section 3.2 of [RFC7252], 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 Section 5.1.1). 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.
Bormann & Birkholz Expires 4 September 2025 [Page 29]
Internet-Draft Constrained Resource Identifiers March 2025
8.3. ACE AIF
The AIF (Authorization Information Format, [RFC9237]) 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). Section 11.5 registers "CRI-local-part" as a
Toid. Together with _Tperm_, an extension point for a way to
indicate individual access rights (permissions), Section 2 of
[RFC9237] defines its general Information Model as:
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
Using the definitions in Figure 2 together with the [RFC9237] default
Tperm choice REST-method-set, this information model can be
specialized as in:
CRI-local-part = [path / null, ?query]
AIF-CRI = AIF-Generic<CRI-local-part, REST-method-set>
9. Implementation Status
(Boilerplate as per Section 2.1 of [RFC7942]:)
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 [RFC7942].
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 [RFC7942], "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".
Bormann & Birkholz Expires 4 September 2025 [Page 30]
Internet-Draft Constrained Resource Identifiers March 2025
With the exception of the authority=true fix, host-names split into
labels, and Section 7.1, 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
10. 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 10 of RFC 8949 [STD94] for additional security considerations
relating to CBOR.
The security considerations discussed in Section 7 of RFC 3986
[STD66] and Section 8 of [RFC3987] for URIs and IRIs also apply to
CRIs. The security considerations discussed for URIs in Section 6 of
[RFC9237] apply analogously to AIF-CRI Section 8.3.
11. IANA Considerations
11.1. CRI Scheme Numbers Registry
This specification defines a new "CRI Scheme Numbers" registry in the
"Constrained RESTful Environments (CoRE) Parameters" registry group
[IANA.core-parameters], with the policy "Expert Review" (Section 4.5
of RFC 8126 [BCP26]). 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.
11.1.1. Instructions for the Designated Expert
The expert is instructed to be frugal in the allocation of CRI scheme
number values whose scheme-id values (Section 5.1.1) 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
Section 11.2), 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.
Bormann & Birkholz Expires 4 September 2025 [Page 31]
Internet-Draft Constrained Resource Identifiers March 2025
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
Appendix A 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.
11.1.2. 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.
Bormann & Birkholz Expires 4 September 2025 [Page 32]
Internet-Draft Constrained Resource Identifiers March 2025
11.1.3. Initial Registrations
The initial registrations for the CRI Scheme Numbers registry are
provided in Appendix A.
11.2. Update to "Uniform Resource Identifier (URI) Schemes" Registry
RFC 7595 [BCP35] is updated to add the following note in the "Uniform
Resource Identifier (URI) Schemes" Registry [IANA.uri-schemes]:
| 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.
11.3. 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 Table 5 and defined in Appendix C.
+-----------------------+-------------+------------+-----------+
| Application-extension | Description | Change | Reference |
| Identifier | | Controller | |
+-----------------------+-------------+------------+-----------+
| cri | Constrained | IETF | RFC-XXXX, |
| | Resource | | Appendix |
| | Identifier | | C |
+-----------------------+-------------+------------+-----------+
Table 5: CBOR Extended Diagnostic Notation (EDN)
Application-extension Identifier for CRI
// RFC Ed.: throughout this section, please replace RFC-XXXX with the
// RFC number of this specification and remove this note.
11.4. CoAP Option Numbers Registry
In the "CoAP Option Numbers" registry in the "CoRE Parameters"
registry group [IANA.core-parameters], IANA is requested to register
the CoAP Option Numbers as described in Table 6 and defined in
Section 8.2.
Bormann & Birkholz Expires 4 September 2025 [Page 33]
Internet-Draft Constrained Resource Identifiers March 2025
+--------+---------------------+-----------+
| No. | Name | Reference |
+--------+---------------------+-----------+
| TBD235 | Proxy-Cri | RFC-XXXX |
| TBD239 | Proxy-Scheme-Number | RFC-XXXX |
+--------+---------------------+-----------+
Table 6: New CoAP Option Numbers
// RFC Ed.: throughout this section, please replace RFC-XXXX with the
// RFC number of this specification and remove this note.
11.5. 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.media-type-sub-parameters], IANA is requested to
register:
+-----------+----------------+---------------+-------------+
| Parameter | Name | Description/ | Reference |
| | | Specification | |
+-----------+----------------+---------------+-------------+
| Toid | CRI-local-part | local-part of | Section 8.3 |
| | | CRI | of RFC-XXXX |
+-----------+----------------+---------------+-------------+
Table 7: ACE AIF Toid for CRI
// RFC Ed.: throughout this section, please replace RFC-XXXX with the
// RFC number of this specification and remove this note.
11.6. 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
[IANA.core-parameters], as follows:
Bormann & Birkholz Expires 4 September 2025 [Page 34]
Internet-Draft Constrained Resource Identifiers March 2025
+------------------------------+----------------+-----+-----------+
| Content Type | Content Coding | ID | Reference |
+------------------------------+----------------+-----+-----------+
| application/ | - | TBD | RFC-XXXX |
| aif+cbor;Toid=CRI-local-part | | | |
+------------------------------+----------------+-----+-----------+
Table 8: Content-Format for ACE AIF with CRI-local-part Toid
// RFC Ed.: throughout this section, please replace RFC-XXXX with the
// RFC number of this specification and remove this note.
12. References
12.1. Normative References
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[BCP35] Best Current Practice 35,
<https://www.rfc-editor.org/info/bcp35>.
At the time of writing, this BCP comprises the following:
Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
Bormann & Birkholz Expires 4 September 2025 [Page 35]
Internet-Draft Constrained Resource Identifiers March 2025
[I-D.ietf-cbor-packed]
Bormann, C. and M. Gütschow, "Packed CBOR", Work in
Progress, Internet-Draft, draft-ietf-cbor-packed-14, 3
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-cbor-packed-14>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<https://www.iana.org/assignments/core-parameters>.
[IANA.media-type-sub-parameters]
IANA, "Media Type Sub-Parameter Registries",
<https://www.iana.org/assignments/media-type-sub-
parameters>.
[IANA.uri-schemes]
IANA, "Uniform Resource Identifier (URI) Schemes",
<https://www.iana.org/assignments/uri-schemes>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <https://www.rfc-editor.org/rfc/rfc3987>.
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing
IPv6 Zone Identifiers in Address Literals and Uniform
Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
February 2013, <https://www.rfc-editor.org/rfc/rfc6874>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9165] Bormann, C., "Additional Control Operators for the Concise
Data Definition Language (CDDL)", RFC 9165,
DOI 10.17487/RFC9165, December 2021,
<https://www.rfc-editor.org/rfc/rfc9165>.
[RFC9237] Bormann, C., "An Authorization Information Format (AIF)
for Authentication and Authorization for Constrained
Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237,
August 2022, <https://www.rfc-editor.org/rfc/rfc9237>.
[STD66] Internet Standard 66,
<https://www.rfc-editor.org/info/std66>.
At the time of writing, this STD comprises the following:
Bormann & Birkholz Expires 4 September 2025 [Page 36]
Internet-Draft Constrained Resource Identifiers March 2025
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
13.0.0", ISBN 978-1-936213-26-9, March 2020,
<https://www.unicode.org/versions/Unicode13.0.0/>.
12.2. Informative References
[BCP190] Best Current Practice 190,
<https://www.rfc-editor.org/info/bcp190>.
At the time of writing, this BCP comprises the following:
Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 8820, DOI 10.17487/RFC8820, June 2020,
<https://www.rfc-editor.org/info/rfc8820>.
[GREENSPUN-10]
Wikipedia, "Greenspun's tenth rule",
<https://en.wikipedia.org/wiki/Greenspun's_tenth_rule>.
[I-D.bormann-cbor-notable-tags]
Bormann, C., "Notable CBOR Tags", Work in Progress,
Internet-Draft, draft-bormann-cbor-notable-tags-12, 12
February 2025, <https://datatracker.ietf.org/doc/html/
draft-bormann-cbor-notable-tags-12>.
[I-D.carpenter-6man-rfc6874bis]
Carpenter, B. E., Cheshire, S., and R. M. Hinden,
"Representing IPv6 Zone Identifiers in Address Literals
and Uniform Resource Identifiers", Work in Progress,
Internet-Draft, draft-carpenter-6man-rfc6874bis-03, 8
February 2022, <https://datatracker.ietf.org/doc/html/
draft-carpenter-6man-rfc6874bis-03>.
Bormann & Birkholz Expires 4 September 2025 [Page 37]
Internet-Draft Constrained Resource Identifiers March 2025
[I-D.draft-ietf-core-href-18]
Bormann, C. and H. Birkholz, "Constrained Resource
Identifiers", Work in Progress, Internet-Draft, draft-
ietf-core-href-18, 3 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
href-18>.
[I-D.ietf-cbor-edn-literals]
Bormann, C., "CBOR Extended Diagnostic Notation (EDN)",
Work in Progress, Internet-Draft, draft-ietf-cbor-edn-
literals-16, 8 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cbor-
edn-literals-16>.
[I-D.ietf-iotops-7228bis]
Bormann, C., Ersue, M., Keränen, A., and C. Gomez,
"Terminology for Constrained-Node Networks", Work in
Progress, Internet-Draft, draft-ietf-iotops-7228bis-01, 8
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-iotops-7228bis-01>.
[MNU] Bormann, C., "Modern Network Unicode", Work in Progress,
Internet-Draft, draft-bormann-dispatch-modern-network-
unicode-06, 2 March 2025,
<https://datatracker.ietf.org/doc/html/draft-bormann-
dispatch-modern-network-unicode-06>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, DOI 10.17487/RFC3490, March 2003,
<https://www.rfc-editor.org/rfc/rfc3490>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/rfc/rfc4180>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/rfc/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
Bormann & Birkholz Expires 4 September 2025 [Page 38]
Internet-Draft Constrained Resource Identifiers March 2025
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/rfc/rfc8141>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/rfc/rfc8288>.
[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
December 2021, <https://www.rfc-editor.org/rfc/rfc9170>.
[STD97] Internet Standard 97,
<https://www.rfc-editor.org/info/std97>.
At the time of writing, this STD comprises the following:
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[W3C.REC-html52-20171214]
Danilo, A., Ed., Eicholz, A., Ed., Moon, S., Ed.,
Faulkner, S., Ed., and T. Leithead, Ed., "HTML 5.2", W3C
REC REC-html52-20171214, W3C REC-html52-20171214, 14
December 2017,
<https://www.w3.org/TR/2017/REC-html52-20171214/>.
Appendix A. 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 Appendix A of [I-D.draft-ietf-core-href-18] 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.)
Bormann & Birkholz Expires 4 September 2025 [Page 39]
Internet-Draft Constrained Resource Identifiers March 2025
The assignments from this table can be extracted from the XML form of
[I-D.draft-ietf-core-href-18] (when stored in a file "this.xml") into
CSV form [RFC4180] using this short Ruby program:
require 'rexml/document'; include REXML
XPath.each(Document.new(File.read("this.xml")),"/rfc/back//tr") {|r|
puts XPath.each(r,"td").map{|d|d.text()}[0..1].join(",")}
Appendix B. 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.
SP1. Initial (Lone/Leading) Empty Path Segments:
* _Lone empty path segments:_ As per [STD66], 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
Section 6.4 of [RFC7252]). As per item 7 of Section 6.5 of
[RFC7252], 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 6.2.3 of RFC 3986 [STD66]
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.
SP2. Constraints (Section 2) 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
Bormann & Birkholz Expires 4 September 2025 [Page 40]
Internet-Draft Constrained Resource Identifiers March 2025
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 Section 7.1) 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.)
Bormann & Birkholz Expires 4 September 2025 [Page 41]
Internet-Draft Constrained Resource Identifiers March 2025
Appendix C. CBOR Extended Diagnostic Notation (EDN): The "cri"
Extension
[I-D.ietf-cbor-edn-literals] more rigorously defines and further
extends the CBOR Extended Diagnostic Notation (EDN), as originally
introduced in Section 8 of RFC 8949 [STD94] and extended in
Appendix G of [RFC8610]. 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 (Section 11.3) 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 [STD66] or an IRI
Reference as per [RFC3987].
The value of the literal is a CRI reference that can be converted to
the text of the literal using the procedure of Section 6.1. 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
cri'https://example.com/bottarga/shaved'
is equivalent to
[-4, ["example", "com"], ["bottarga", "shaved"]]
See Appendix C.1 for an ABNF definition for the content of cri
literals.
C.1. 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 4.1 of RFC 3986 [STD66] with
certain re-arrangements taken from Figure 5 of
[I-D.ietf-cbor-edn-literals]; these are reproduced in Figure 6. If
the content is not ASCII only (i.e., for IRIs), first apply
Section 3.1 of [RFC3987] and apply this grammar to the result.
Bormann & Birkholz Expires 4 September 2025 [Page 42]
Internet-Draft Constrained Resource Identifiers March 2025
app-string-cri = URI-reference
; ABNF from RFC 3986:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
URI-reference = URI / relative-ref
absolute-URI = scheme ":" hier-part [ "?" query ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = [ userinfo "@" ] host [ ":" port ]
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
host = IP-literal / IPv4address / reg-name
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
; Use IPv6address, h16, ls32, IPv4adress, dec-octet as re-arranged
; for PEG Compatibility in Figure 5 of [I-D.ietf-cbor-edn-literals]:
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ h16 *1( ":" h16 ) ] "::" 3( h16 ":" ) ls32
/ [ h16 *2( ":" h16 ) ] "::" 2( h16 ":" ) ls32
/ [ h16 *3( ":" h16 ) ] "::" h16 ":" ls32
/ [ h16 *4( ":" h16 ) ] "::" ls32
/ [ h16 *5( ":" h16 ) ] "::" h16
/ [ h16 *6( ":" h16 ) ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
Bormann & Birkholz Expires 4 September 2025 [Page 43]
Internet-Draft Constrained Resource Identifiers March 2025
dec-octet = "25" %x30-35 ; 250-255
/ "2" %x30-34 DIGIT ; 200-249
/ "1" 2DIGIT ; 100-199
/ %x31-39 DIGIT ; 10-99
/ DIGIT ; 0-9
ALPHA = %x41-5a / %x61-7a
DIGIT = %x30-39
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; case insensitive matching, i.e., including lower case
reg-name = *( unreserved / pct-encoded / sub-delims )
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
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 = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Figure 6: ABNF Definition of URI Representation of a CRI
Bormann & Birkholz Expires 4 September 2025 [Page 44]
Internet-Draft Constrained Resource Identifiers March 2025
Appendix D. Change Log
This section is to be removed before publishing as an RFC.
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 RFC7595 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 Appendix B, 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 Section 2.3, Paragraph 5, Item
3 (rootless CRIs without authority that do not have a path
component)
* Generalize Section 7, discuss PET (percent-encoded text) extension
in more detail
* Add registry of URI scheme numbers (Appendix A, Section 11)
* Add user information to the authority ("userinfo" feature)
* Figure 2: Use separate rule for CRI, allow [] for query in CRI
Reference; generalize scheme numbers, add userinfo; add list of
additional requirements in prose (Section 5.1, Paragraph 7)
* Discuss Error handling and extensibility (Section 5.2.1)
* Conversion to URI: Handle : in first pathname component of a CRI-
Reference (Section 6.1, Paragraph 2.6.1)
Bormann & Birkholz Expires 4 September 2025 [Page 45]
Internet-Draft Constrained Resource Identifiers March 2025
* Add Christian Amsüss as contributor
* Add CBOR EDN application-extension "cri" (see Appendix C and
Section 11.3).
* 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
Section 6.1. 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 [STD66]). 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
Bormann & Birkholz Expires 4 September 2025 [Page 46]
Internet-Draft Constrained Resource Identifiers March 2025
* More explicitly discuss constraints (Section 2), add examples
(Appendix B, Paragraph 6, Item 1).
* 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 [RFC6874] 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.
Bormann & Birkholz Expires 4 September 2025 [Page 47]
Internet-Draft Constrained Resource Identifiers March 2025
* 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 Klaus Hartke 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 Christian Amsüss, Thomas Fossati, Ari Keränen, Jim Schaad,
Dave Thaler, and Marco Tiloca for helpful comments and discussions
that have shaped the document.
Contributors
Klaus Hartke
Ericsson
Torshamnsgatan 23
SE-16483 Stockholm
Sweden
Email: klaus.hartke@ericsson.com
Christian Amsüss
Hollandstr. 12/4
1020 Vienna
Austria
Email: christian@amsuess.com
Authors' Addresses
Bormann & Birkholz Expires 4 September 2025 [Page 48]
Internet-Draft Constrained Resource Identifiers March 2025
Carsten Bormann (editor)
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Bormann & Birkholz Expires 4 September 2025 [Page 49]