draft-ietf-core-href-05.txt   draft-ietf-core-href-06.txt 
CoRE Working Group C. Bormann, Ed. CoRE Working Group C. Bormann, Ed.
Internet-Draft Universit├Ąt Bremen TZI Internet-Draft Universit├Ąt Bremen TZI
Intended status: Standards Track H. Birkholz Intended status: Standards Track H. Birkholz
Expires: 13 January 2022 Fraunhofer SIT Expires: 26 January 2022 Fraunhofer SIT
12 July 2021 25 July 2021
Constrained Resource Identifiers Constrained Resource Identifiers
draft-ietf-core-href-05 draft-ietf-core-href-06
Abstract Abstract
The Constrained Resource Identifier (CRI) is a complement to the The Constrained Resource Identifier (CRI) is a complement to the
Uniform Resource Identifier (URI) that serializes the URI components Uniform Resource Identifier (URI) that serializes the URI components
in Concise Binary Object Representation (CBOR) instead of a sequence in Concise Binary Object Representation (CBOR) instead of a sequence
of characters. This simplifies parsing, comparison and reference of characters. This simplifies parsing, comparison and reference
resolution in environments with severe limitations on processing resolution in environments with severe limitations on processing
power, code size, and memory size. power, code size, and memory size.
Note to Readers Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
The issues list for this Internet-Draft can be found at Discussion of this document takes place on the Constrained RESTful
<https://github.com/core-wg/coral/labels/href>. Environments Working Group mailing list (core@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/core/
A reference implementation and a set of test vectors can be found at (https://mailarchive.ietf.org/arch/browse/core/). Source for this
<https://github.com/core-wg/coral/tree/master/binary/python>. draft and an issue tracker can be found at https://github.com/core-
wg/href (https://github.com/core-wg/href)
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 January 2022. This Internet-Draft will expire on 26 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5.3. Reference Resolution . . . . . . . . . . . . . . . . . . 10 5.3. Reference Resolution . . . . . . . . . . . . . . . . . . 10
6. Relationship between CRIs, URIs and IRIs . . . . . . . . . . 11 6. Relationship between CRIs, URIs and IRIs . . . . . . . . . . 11
6.1. Converting CRIs to URIs . . . . . . . . . . . . . . . . . 12 6.1. Converting CRIs to URIs . . . . . . . . . . . . . . . . . 12
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. CDDL specification . . . . . . . . . . . . . . . . . 16 Appendix A. CDDL specification . . . . . . . . . . . . . . . . . 16
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Uniform Resource Identifier (URI) [RFC3986] and its most common The Uniform Resource Identifier (URI) [RFC3986] and its most common
usage, the URI reference, are the Internet standard for linking to usage, the URI reference, are the Internet standard for linking to
resources in hypertext formats such as HTML [W3C.REC-html52-20171214] resources in hypertext formats such as HTML [W3C.REC-html52-20171214]
or the HTTP "Link" header field [RFC8288]. or the HTTP "Link" header field [RFC8288].
A URI reference is a sequence of characters chosen from the A URI reference is a sequence of characters chosen from the
repertoire of US-ASCII characters. The individual components of a repertoire of US-ASCII characters. The individual components of a
skipping to change at page 4, line 28 skipping to change at page 4, line 28
and is lowercase (see Definition D139 in [Unicode]). The and is lowercase (see Definition D139 in [Unicode]). The
scheme is always present. scheme is always present.
C2. An authority is always a host identified by an IP address or C2. An authority is always a host identified by an IP address or
registered name, along with optional port information. User registered name, along with optional port information. User
information is not supported. The authority can be absent; in information is not supported. The authority can be absent; in
[RFC3986], in this case the path can be rootless or, as when he [RFC3986], in this case the path can be rootless or, as when he
authority is present, begin with a root ("/"); this is modelled authority is present, begin with a root ("/"); this is modelled
by two different values for an absent authority. by two different values for an absent authority.
C3. An IP address can be either an IPv4 address or an IPv6 address. C3. An IP address can be either an IPv4 address or an IPv6 address,
IPv6 scoped addressing zone identifiers and future versions of optionally with a zone identifier [RFC6874]. Future versions
IP are not supported. of IP are not supported.
C4. A registered name can be any Unicode string that is lowercase C4. A registered name is a sequence of one or more _labels_, which,
and in Unicode Normalization Form C (NFC) (see Definition D120 when joined with dots (".") in between them, result in a
in [Unicode]). (The syntax may be further restricted by the Unicode string that is lowercase and in Unicode Normalization
scheme.) Form C (NFC) (see Definition D120 in [Unicode]). (The syntax
may be further restricted by the scheme.)
C5. A port is always an integer in the range from 0 to 65535. C5. A port is always an integer in the range from 0 to 65535.
Empty ports or ports outside this range are not supported. Empty ports or ports outside this range are not supported.
C6. The port is omitted if and only if the port would be the same C6. The port is omitted if and only if the port would be the same
as the scheme's default port (provided the scheme is defining as the scheme's default port (provided the scheme is defining
such a default port) or the scheme is not using ports. such a default port) or the scheme is not using ports.
C7. A path consists of zero or more path segments. A path must not C7. A path consists of zero or more path segments. A path must not
consist of a single zero-length path segment, which is consist of a single zero-length path segment, which is
skipping to change at page 6, line 4 skipping to change at page 6, line 4
The naming authority MUST ensure that any CRI created satisfies the The naming authority MUST ensure that any CRI created satisfies the
constraints defined in Section 2. The creation of a CRI fails if the constraints defined in Section 2. The creation of a CRI fails if the
CRI cannot be validated to satisfy all of the constraints. CRI cannot be validated to satisfy all of the constraints.
If a naming authority creates a CRI from user input, it MAY apply the If a naming authority creates a CRI from user input, it MAY apply the
following (and only the following) normalizations to get the CRI more following (and only the following) normalizations to get the CRI more
likely to validate: likely to validate:
* map the scheme name to lowercase (C1); * map the scheme name to lowercase (C1);
* map the registered name to NFC (C4); * map the registered name to NFC (C4) and split it on embedded dots;
* elide the port if it is the default port for the scheme (C6); * elide the port if it is the default port for the scheme (C6);
* elide a single zero-length path segment (C7); * elide a single zero-length path segment (C7);
* map path segments, query parameters and the fragment identifier to * map path segments, query parameters and the fragment identifier to
NFC (C8, C9, C10). NFC (C8, C9, C10).
Once a CRI has been created, it can be used and transferred without Once a CRI has been created, it can be used and transferred without
further normalization. All operations that operate on a CRI SHOULD further normalization. All operations that operate on a CRI SHOULD
skipping to change at page 8, line 22 skipping to change at page 8, line 22
fragment / null fragment / null
] ]
scheme = scheme-name / scheme-id scheme = scheme-name / scheme-id
scheme-name = text .regexp "[a-z][a-z0-9+.-]*" scheme-name = text .regexp "[a-z][a-z0-9+.-]*"
scheme-id = (COAP / COAPS / HTTP / HTTPS / other-scheme) scheme-id = (COAP / COAPS / HTTP / HTTPS / other-scheme)
.within nint .within nint
COAP = -1 COAPS = -2 HTTP = -3 HTTPS = -4 COAP = -1 COAPS = -2 HTTP = -3 HTTPS = -4
other-scheme = nint .feature "scheme-id-extension" other-scheme = nint .feature "scheme-id-extension"
authority = host / [host, port] authority = [host, ?port]
host = host-name / host-ip host = (host-name // host-ip)
host-name = text host-name = (*text) ; lowercase, NFC labels
host-ip = bytes .size 4 / bytes .size 16 host-ip = (bytes .size 4 //
(bytes .size 16, ?zone-id))
zone-id = text
port = 0..65535 port = 0..65535
discard = true / 0..127 discard = true / 0..127
path = [*text] path = [*text]
query = [*text] query = [*text]
fragment = text fragment = text
This CDDL specification is simplified for exposition and needs to be This CDDL specification is simplified for exposition and needs to be
augmented by the following rule for interchange: Trailing null values augmented by the following rule for interchange: Trailing null values
are removed, and two leading null values (scheme and authority both are removed, and two leading null values (scheme and authority both
skipping to change at page 12, line 37 skipping to change at page 12, line 32
authority authority
If the CRI reference contains a "host-name" or "host-ip" item, the If the CRI reference contains a "host-name" or "host-ip" item, the
authority component of the URI reference consists of a host authority component of the URI reference consists of a host
subcomponent, optionally followed by a colon (":") character and a subcomponent, optionally followed by a colon (":") character and a
port subcomponent. Otherwise, the authority component is unset. port subcomponent. Otherwise, the authority component is unset.
The host subcomponent consists of the value of the "host-name" or The host subcomponent consists of the value of the "host-name" or
"host-ip" item. "host-ip" item.
Any character in the value of a "host-name" item that is not in The "host-name" is turned into a single string by joining the
the set of unreserved characters (Section 2.3 of [RFC3986]) or elements separated by dots ("."). Any character in the value of a
"sub-delims" (Section 2.2 of [RFC3986]) MUST be percent-encoded. "host-name" item that is not in the set of unreserved characters
(Section 2.3 of [RFC3986]) or "sub-delims" (Section 2.2 of
[RFC3986]) MUST be percent-encoded.
The value of a "host-ip" item MUST be represented as a string that 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 matches the "IPv4address" or "IP-literal" rule (Section 3.2.2 of
[RFC3986]). [RFC3986]). Any zone-id is appended to the string, separated by
"%25" as defined in Section 2 of [RFC6874], or as specified in a
successor zone-id specification document; this also leads to a
modified "IP-literal" rule as specified in these documents.
If the CRI reference contains a "port" item, the port subcomponent If the CRI reference contains a "port" item, the port subcomponent
consists of the value of that item in decimal notation. consists of the value of that item in decimal notation.
Otherwise, the colon (":") character and the port subcomponent are Otherwise, the colon (":") character and the port subcomponent are
both omitted. both omitted.
path path
If the CRI reference contains a "discard" item of value "true", If the CRI reference contains a "discard" item of value "true",
the path component is prefixed by a slash ("/") character. If it the path component is prefixed by a slash ("/") character. If it
contains a "discard" item of value "0" and the "path" item is contains a "discard" item of value "0" and the "path" item is
skipping to change at page 14, line 15 skipping to change at page 14, line 15
component of the URI reference consists of the value of that item. component of the URI reference consists of the value of that item.
Otherwise, the fragment component is unset. Otherwise, the fragment component is unset.
Any character in the value of a "fragment" item that is not in the Any character in the value of a "fragment" item that is not in the
set of unreserved characters or "sub-delims" or a colon (":"), set of unreserved characters or "sub-delims" or a colon (":"),
commercial at ("@"), slash ("/") or question mark ("?") character commercial at ("@"), slash ("/") or question mark ("?") character
MUST be percent-encoded. MUST be percent-encoded.
7. Implementation Status 7. Implementation Status
With the exception of the authority=true fix, CRIs are implemented in With the exception of the authority=true fix and host-names split
"https://gitlab.com/chrysn/micrurus". into labels, CRIs are implemented in "https://gitlab.com/chrysn/
micrurus".
8. Security Considerations 8. Security Considerations
Parsers of CRI references must operate on input that is assumed to be Parsers of CRI references must operate on input that is assumed to be
untrusted. This means that parsers MUST fail gracefully in the face untrusted. This means that parsers MUST fail gracefully in the face
of malicious inputs. Additionally, parsers MUST be prepared to deal of malicious inputs. Additionally, parsers MUST be prepared to deal
with resource exhaustion (e.g., resulting from the allocation of big with resource exhaustion (e.g., resulting from the allocation of big
data items) or exhaustion of the call stack (stack overflow). See data items) or exhaustion of the call stack (stack overflow). See
Section 10 of [RFC8949] for additional security considerations Section 10 of [RFC8949] for additional security considerations
relating to CBOR. relating to CBOR.
skipping to change at page 15, line 5 skipping to change at page 15, line 9
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <https://www.rfc-editor.org/info/rfc3987>. January 2005, <https://www.rfc-editor.org/info/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/info/rfc6874>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
skipping to change at page 16, line 35 skipping to change at page 17, line 24
) )
] ]
scheme = scheme-name / scheme-id scheme = scheme-name / scheme-id
scheme-name = text .regexp "[a-z][a-z0-9+.-]*" scheme-name = text .regexp "[a-z][a-z0-9+.-]*"
scheme-id = (COAP / COAPS / HTTP / HTTPS / other-scheme) scheme-id = (COAP / COAPS / HTTP / HTTPS / other-scheme)
.within nint .within nint
COAP = -1 COAPS = -2 HTTP = -3 HTTPS = -4 COAP = -1 COAPS = -2 HTTP = -3 HTTPS = -4
other-scheme = nint .feature "scheme-id-extension" other-scheme = nint .feature "scheme-id-extension"
authority = host / [host, port] authority = [host, ?port]
host = host-name / host-ip host = (host-name // host-ip)
host-name = text host-name = (*text) ; lowercase, NFC labels
host-ip = bytes .size 4 / bytes .size 16 host-ip = (bytes .size 4 //
(bytes .size 16, ?zone-id))
zone-id = text
port = 0..65535 port = 0..65535
discard = true / 0..127 discard = true / 0..127
path = [*text] path = [*text]
query = [*text] query = [*text]
fragment = text fragment = text
Appendix B. Change Log Appendix B. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
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 Changes from -04 to -05
* Simplify CBOR structure. * Simplify CBOR structure.
* Add implementation status section. * Add implementation status section.
Changes from -03 to -04: Changes from -03 to -04:
* Minor editorial improvements. * Minor editorial improvements.
 End of changes. 16 change blocks. 
36 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/