]> Universität Bremen TZI

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

Web and Internet Transport Constrained RESTful Environments URI CRI Constrained Devices URI Scheme For the Concise Binary Object Representation (CBOR), a Concise Diagnostic Notation (CDN) has been defined in draft-ietf-cbor-edn-literals. This provides an extension point for "App-Extension Identifiers" registry in the "Concise Diagnostic Notation" registry group, supporting text representations of CBOR tags and other structures to enhance usability. The present document specifies an app-extension and registers an app-extension identifier for CBOR tag 99, Constrained Resource Identifiers (CRI), as defined in RFC-to-be 9988. (This cref will be removed by the RFC editor:)
This document carries the specification of the cri'' application-oriented prefix for CBOR diagnostic notation. This specification used to be in the CoRE WG document for CRIs, became part of the CBOR WG document for CBOR diagnostic notation when the CBOR WG document was delayed, and was then deleted from that document as it is outside the scope of the CBOR WG. So this document now goes back to the CoRE WG, as a "new" individual submission. About This Document Status information for this document may be found at . Discussion of this document takes place on the core Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction (To be derived from abstract, q.v.)

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in () () when, and only when, they appear in all capitals, as shown here.

Concise Resource Identifiers: The "cri" Extension The app-extension identifier "cri" is used to notate a CDN literal for a CRI reference as defined in . The input of the literal is a URI Reference as per or an IRI Reference as per . The value of the literal is a CRI reference that can be converted to the text of the literal using the procedure of . Note that there may be more than one CRI reference that can be converted to the URI/IRI reference given; implementations are expected to favor the simplest variant available and make non-surprising choices otherwise. In the all-uppercase variant of the app-prefix, the value is enclosed in a tag number 99. As an example, the CDN is equivalent to See for an ABNF definition for the content of cri literals.

cri: ABNF Definition of URI Representation of a CRI It can be expected that implementations of the app-extension identifier "cri" will make use of platform-provided URI implementations, which will include a URI parser. In case such a URI parser is not available or inconvenient to integrate, a grammar of the content of cri literals is provided by the ABNF for URI-reference in Section of RFC 3986 with certain re-arrangements taken from ; these are reproduced in . If the content is not ASCII only (i.e., for IRIs), first apply and apply this grammar to the result.

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

Security Considerations TODO Security

IANA Considerations RFC Editor: please replace RFC-XXXX with the RFC number of this RFC, [IANA.concise-diagnostic-notation] with a reference to the new registry group, and remove this note.

Concise Diagnostic Notation App-extension Identifiers Registry IANA is requested to register the "cri" app-extension identifier as per in the "App-Extension Identifiers" registry in the "Concise Diagnostic Notation" registry group [IANA.concise-diagnostic-notation], with the Change Controller "IETF". app-extension Identifier "cri"

app-extension identifier	Description	Reference
cri	Constrained Resource Identifier	RFC-XXXX,

Normative References The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) 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 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. Universität Bremen TZI This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) This revision -29 // attempts to implement various change requests not covered in -28 // that have been discussed in the 2026-08-19 and 2026-09-30 WG // interim meetings, but does not attempt to reflect the outcome of // those discussions. The text also does not have WG input yet on // any renaming decisions (CDN name, b1/t1 name). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.