]>

Austria christian@amsuess.com

Sandelman Software Works

mcr+ietf@sandelman.ca

CoRE coap Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus registering (relatively verbose) well-known URI paths. This document introduces an option that allows expressing well-known paths in as little as two bytes. About This Document Status information for this document may be found at . Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction When building application components on CoAP (), sending small messages is a general goal in the ecosystem (i.e., constrained environments, where data rates are limited and large packets can lead to packet loss, see ). While CoAP can operate with a wide range of URIs, short path names are therefore favored. Those short path names need to be discovered, and and provide mechanisms for that. Applications that can not discover such paths because they precede a discovery step, such as the discovery itself, setting up a security context () or establishing an initial identity () can not rely on discovered short paths, and need to use well-known paths. The best practice established in requires applications to use the prefix ".well-known" for their paths, making the combined paths easily longer than the rest of the CoAP message. This document establishes a CoAP option that allows abbreviating the path component of the request URI through a numeric registry.

Motivating example The design criteria for described in give a fragmentation limit of 47 bytes CoAP message payload for 6TiSCH and 51 bytes for some parameters (and implementations) of LoRaWAN, and high performance penalties of not fitting in those frames. An EDHOC message 1 on its own carries a minimum of 37 bytes. The 18 bytes of an encoded "/.well-known/edhoc" path push the size over either limit, whereas an equivalent Uri-Path-Abbrev stays well below the limit.

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 BCP 14 when, and only when, they appear in all capitals, as shown here. This document assumes basic familiarity with CoAP (), in particular its Uri-* options.

The Uri-Path-Abbrev option The Uri-Path-Abbrev option (short for "URI path, abbreviated") expresses a request's URI path in a more compact form. The Uri-Path-Abbrev value represents a particular path, and is thus equivalent to any number of Uri-Path options. Those paths are typically in a "/.well-known" location as described in . The numeric option values are coordinated by IANA in the Uri-Path-Abbrev registry established in this document in . Uri-Path-Abbrev Option Summary (C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable)

No.	C	U	N	R	Name	Format	Len.	Default
CPA13	x				Uri-Path-Abbrev	uint	0-4	(none)

RFC-Editor: This document uses the CPA (code point allocation) convention described in . For each usage of the term "CPA", please remove the prefix "CPA" from the indicated value and replace the residue with the value assigned by IANA; perform an analogous substitution for all other occurrences of the prefix "CPA" in the document. Finally, please remove this note. The option is a critical, safe-to-forward, and part of the cache key, and used in CoAP requests. summarizes these, extending Table 4 of ). Its OSCORE treatment is as Class E (). The option has an integer value from the registry established in . Apart from the format and repeatability, the option's properties only deviate from the Uri-Path (for which it stands in) in that this option is safe to forward. This has consequences for the interactions with the Proxy-URI option, but is generally desirable: It allows the option to be used with proxies that do not implement the option.

Server processing A server receiving this option process it like the equivalent sequence of Uri-Path options. A server that supports a Uri-Path-Abbrev value MUST also support the equivalent request composed of Uri-Path components. A server receiving the option with an unknown value MUST treat it as an unprocessable critical option, returning 4.02 Bad Option and MUST NOT return a 4.04 Not Found response, because the equivalent path may be present on the server.

Client processing A client may use the option instead of the Uri-Path option if there is a suitable value that can express the requested path. Unless the client can be assured that the server supports it (e.g. because the specification describing the interaction mandates support for the option in the server) it SHOULD fall back to sending the path explicitly if it receives an error indicating that the option was not understood (otherwise, it would have limited interoperability). A generic client implementation SHOULD NOT apply this optimization without explicit instructions from a higher layer or the known specification of the numeric value: In general, it is too unlikely that the Uri-Path-Abbrev value is understood by any server, and the message size savings in the successful case are dwarved by the almost doubling of resources needed to perform the fallback.

Proxy processing A proxy MAY expand or introduce a Uri-Path-Abbrev before consulting its cache. It MAY expand a Uri-Path-Abbrev option before forwarding, in particular if it has reason to assume that the option is not understood. Like a generic client, it SHOULD NOT introduce an abbreviation without good reason; and then, it MUST fall back to the expanded form, as to not introduce unexpected errors to the client. A proxy that knows Uri-Path-Abbrev but not the concrete value SHOULD forward it unmodified, which is the behavior it would apply if it did not know the option. A reason to reject the request instead is when the proxy is tasked with enforcing access control (see ). When cross-proxying to protocols that can not transport this option (such as HTTP), the proxy needs to expand the path.

Interaction with other options The option is mutually exclusive with the Uri-Path option. Receiving both options in a single request MUST be treated like the presence of a critical request option that could not be processed (that option being either the Uri-Path-Abbrev option or the conflicting option). The Uri-Path-Abbrev option MUST NOT be used in combination with the Proxy-Uri option (or the similar Proxy-CRI option (of )) by clients. Proxies that understand Uri-Path-Abbrev and convert Uri-* options into Proxy-Uri MUST expand any Uri-Path-Abbrev if they know the value. By the (de)composition rules around Proxy-Uri, and because Uri-Path-Abbrev is safe-to-forward, a proxy (being generally unaware of this specification) is allowed to combine the option with Proxy-Uri (or Proxy-CRI) when it combines the Uri-* options. In such a combined message, the Uri-Path segments to which the Uri-Path-Abbrev corresponds are appended to the path as if all components were present as individual options in the request without conflicting. Servers that support both Uri-Path-Abbrev and Proxy-URI/-CRI SHOULD process requests accordingly. (This is not a strict requirement, as there are no known implementations of proxies that actually compose a Proxy-URI/-CRI from individual options, nor is there a reason known why they should).

Future development Future updates to this document might extend the capabilities of the option to be repeated; that document will need to specify how later occurrences of the option extend the series of equivalent Uri-Path options from the first value. Server implementations that treat repeated Uri-Path-Abbrev options like any other critical unprocessable option (i.e., by responding with 4.02 Bad Option) support the transition to such an extension.

Choice of the option number TBD: Rephrase this to either be useful for readers of the final document who can thus learn how the option number namespace is managed, or remove before publication.

• It's already 1+1 -- we generally do try to keep even the 1+1 high so that later option typically paired with a low option (like EDHOC paired with OSCORE) can use the small delta. In this case, there's a good reason (being ordered before Uri-Query) though, and I don't expect that any other option would need this particular property (especially given that this option on its own has an extensible value range).

Initial Uri-Path-Abbrev values This document registers values for the following well-known URIs:

• /.well-known/core
• /.well-known/rd (see )
• /.well-known/edhoc (see )
• For EST ():
  • /.well-known/est/crts
  • /.well-known/est/sen
  • /.well-known/est/sren
  • /.well-known/est/skg
  • /.well-known/est/skc
  • /.well-known/est/att
  EST does allow using other paths, such as different root resources or arbitrary labels; for those, no abbreviations are supported in this document.
• For :
  • /.well-known/brski/es
  • /.well-known/brski/rv
  • /.well-known/brski/vs

For all those, later occurrences of Uri-Path-Abbrev are interpreted as additional Uri-Path values. While there are currently no resources under the CoRE and RD resource, this behavior is useful in BRSKI and EST. Note that the core and rd paths are commonly used with Uri-Query options.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

• aiocoap https://christian.amsuess.com/tools/aiocoap/ A general-purpose implementation of CoAP for unconstrained sytems, published under MIT License. In its current main branch, the implementation covers the server side of this specification, applying expansion automatically before looking up which resource to serve. For client, all it provides is the option field where to place a number if the application decides it is suitable, relying on the client application to perform the fallback. It implements version ietf-core-uri-path-abbrev-01. Implementation experience: Generally straightforward unless one tries to preserve the information whether Uri-Path-Abbrev was used for the server application (but that was probably just a bad idea in the first place). Contact information: Christian Amsüss (author), updated 2025-09-26

Security Considerations Having alternative expressions for information that is input to policy decisions can be problematic when the mechanism performing the check has a different interpretation of the presented data than the mechanism at time of use. That concern is not new to this document: Both the Proxy-Uri of and the Proxy-Cri option of have the same properties in that regard. The appropriate behavior is for policy checkers to reject any request that contains critical options that is not understood; the application protected by the checker may provide the checker with an allow-list of options that it will treat as unchecked input.

IANA Considerations

CoAP option: Uri-Path-Abbrev IANA is requested to enter an one option into the CoAP Option Numbers registry in the CoRE Parameters group:

• Number: CPA13
• Name: Uri-Path-Abbrev
• Reference: this document

Uri-Path-Abbrev registry IANA is requested to establish a new registry in the CoRE parameters group: Values of the first Uri-Path-Abbrev option in a CoAP request correspond to a URI path according to this registry. The policy for adding any value is IETF Review (as described in ). Change control for the registry follows this document's publication stream. Initial values are given in . Entry fields are:

• First option value. An non-negative integer that can be expressed in 32 bits, unique within this registry. All positive values whose most significant bit of the most significant byte is 1 are reserved. The Python invocation python3 -c 'print("reserved" if (250).bit_length() % 8 == 0 else "unreserved")' can be used to quickly test this property for any positive number (250 in this example).
• Simple expanded path. This text is the URI path (starting with /) that the option, when present only once in a request, is expanded to. This field may be empty if the document describes that the option needs to be repeated when using this first value.
• Reference. A document that requested the allocation, and describes whether the option may be repeated after this first value, and how later values are expanded

Reviewer instructions: The reviewer is instructed to be frugal with the 128 values that correspond to a single-vbyte value, focusing on applications that are expected to be useful in different constrained ecosystems. The expanded path is expected to be well-known paths at the time of writing, but it is up to the reviewers to exceptionally also admit paths that are not well-known. Initial values for the Uri-Path-Abbrev registry

First option value	Simple expanded path	Reference
0	/.well-known/core	of this document
1	/.well-known/rd	of this document, and
2	/.well-known/edhoc	of this document, and
301	/.well-known/est/crts	of this document, and
302	/.well-known/est/sen	of this document, and
303	/.well-known/est/sren	of this document, and
304	/.well-known/est/skg	of this document, and
305	/.well-known/est/skc	of this document, and
306	/.well-known/est/att	of this document, and
401	/.well-known/brski/es	of this document, and
402	/.well-known/brski/rv	of this document, and
403	/.well-known/brski/vs	of this document, and

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. 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. Informative References The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic. This document provides guidance on the specification of URI substructure in standards. This document obsoletes RFC 7320 and updates RFC 3986. Inria Ericsson AB Ericsson AB Odin Solutions S.L. This document compiles the requirements for a lightweight authenticated key exchange protocol for OSCORE. This draft has completed a working group last call (WGLC) in the LAKE working group. Post-WGLC, the requirements are considered sufficiently stable for the working group to proceed with its work. It is not currently planned to publish this draft as an RFC. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Universität Bremen TZI CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. 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 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 –24 attempts to address follow-on AD review // comments as well as comments from the ARTART review. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol (CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model.

Further development Several possible further directions are anticipated in this document, but not specified at this point in time; they are left for further documents:

• The mechanism of expanding one option into another option might be expressed using the terminology of SCHC. Such a generalization is not aimed for in this document; authors of any future document providing such a framework are encouraged to provide an equivalent but machine-readable explanation of the mechanism specified here.
• The registry for Uri-Path-Abbrev values is set up such that first values can not have the most significant bit of the first byte set. This allows future documents to reuse the option for any CBOR expressions, e.g. the path component of a CRI . Note that those CBOR structures can only use the major types 4 to 7 for the top-level item, but that includes all containers (arrays, maps and tags). Senders and recipients of this option do not need to concern themselves with that extension mechanism unless they implement it: As the first value is compared to known registry entries, any CBOR item contained in it will simply not match any known value. Should the working group decide not to use that extension point, the registry's policy can be relaxed to also allow values with that leading bit set.
• A future document may update this document to allow registering values that are allowed to use together with Uri-Path values (but at the time of writing, no examples are known by which such a design could be properly vetted). In particular, that update weakens the "MUST" in .
• This option is designed to stand in for the Uri-Path option alone, not for any other option; this simplifies its interaction rules. In particular, application authors who seek to express Uri-Query options in a more concise or easier to process way are advised to avail themselves of the FETCH method introduced in .

Open questions This section will be gone by the time this document is published.

• Is the transformation of separate options to Proxy-URI even legal for proxies? If not, we can simplify the handling (and Uri-Path would really not have needed to be proxy-unsafe). Tracked at https://github.com/core-wg/corrclar/issues/51.
• This document might incentivise users to send more traffic through /.well-known/ paths, rather than go through discovery. It is up to WG discussion to decide whether this is desirable; to not make this document depend on that outcome, the registration policy is currently "IETF Review", which is extremely strict and can be relaxed in a later document if the WG decides so.

Change log Since ietf-core-uri-path-abbrev-00: Processing previous two interims.

• Rename option to Uri-Path-Abbrev.
• Allocate per-resource codes for EST and cBRSKI.
• Allocate code for EDHOC.
• Defer repeated use to future extensions.
• Rearrange content to have dedicated server, client and proxy subsections for option processing.
• Establish that generic clients SHOULD NOT use this without reason.
• More explicit language for proxies, including cross-proxies.
• Add introduction and motivating example.
• Add RFC7942 Implementation Status section.

Since draft-amsuess-core-shopinc-02: Adopted into WG unmodified as I-D.ietf-core-uri-path-abbrev Since draft-amsuess-core-shopinc-01: Processing 2025-08-27 interim.

• Document is standards track.
• Change name of the option from Short-Uri-Path to Uri-Path-Abbr.
• Close question of whether use of option 13 is justified (it is).
• Minor editorials.

Since draft-amsuess-core-shopinc-00:

• Switched option type from opaque to uint (retaining the lockout for values that look like CBOR arrays/maps).
• MCR joined as author.
• Added initial values for BRSKI and EST.
• Allow 4.04 responses.
• Add guidance for choosing prefixes and rules.
• Large editorial changes.

Acknowledgments This document was created out of discussion with Esko Dijk and Michael Richardson. Carsten Bormann provided useful input on shaping the registry.