]> URI Path abbreviation in CoAP
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 using (relatively verbose) well-known URI paths. This document introduces the Uri-Path-Abbrev CoAP option that allows expressing well-known URI paths in as little as two bytes. Using this option revealed a subtle flaw in RFC7252 that severely limited the extension point of critical options. This document updates RFC7252 to rectify that. 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 size of the CoAP Uri-Path options easily longer than the rest of the CoAP message. This document establishes the CoAP Uri-Path-Abbrev option, which allows abbreviating the path component of the request URI by encoding the path component as a single number. A registry is established to maintain the mapping between numbers and URI paths.
Motivating example The design criteria for EDHOC described in give a frame fragmentation limit of 47 bytes for a CoAP message payload for 6TiSCH and 51 bytes for some parameters (and implementations) of LoRaWAN, and imply high performance penalties of a CoAP message not fitting in a single frame. An EDHOC message_1 on its own carries a minimum of 37 bytes. The 18 bytes of an encoded "/.well-known/edhoc" URI path push the CoAP message size over either limit, whereas an equivalent Uri-Path-Abbrev option lets the message stay well below these limits.
Update to RFC7252 The use of a critical CoAP option that is not understood by the server has a CoAP response error code (4.02 Bad Option) assigned, which generally enables clients to retry without using the critical option. This mechanism is useful for the abbreviation mechanism of this document. That mechanism got conflated with the mechanism of rejecting a request established in for handling unprocessable Non-confirmable messages, which makes detection of missing support for a critical option less reliable. of this document updates to repair the behavior of servers when they receive an unsupported critical option in a Non-confirmable message.
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 term "expand" is used to refer to the process of translating a Uri-Path-Abbrev option into an equivalent sequence of Uri-Path options. The term "abbreviate" is used to refer to the reverse process of translating a sequence of one or more Uri-Path options into a single Uri-Path-Abbrev option.
The Uri-Path-Abbrev option The Uri-Path-Abbrev option (short for "URI path, abbreviated") expresses a CoAP request's URI path in a more compact form. The Uri-Path-Abbrev value represents a particular URI 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 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. There is one occurrence of the value 13 encoded in a1270d, which, if the number were to change, would need updating. The option is critical, safe-to-forward, part of the Cache-Key, non-repeatable and used in CoAP requests. summarizes these properties, extending Table 4 of ). Its OSCORE treatment is as Class E (). The option has an unsigned integer value taken 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 its interactions with the Proxy-Uri option, but these consequences are generally desirable: It allows the option to be used with CoAP proxies that do not implement the option.
Server processing A CoAP server receiving this option processes it like the equivalent sequence of Uri-Path options. A server that supports a specific Uri-Path-Abbrev value MUST also support the sequence of Uri-Path options specifying the equivalent URI path. A server receiving the option with an unknown value MUST treat it as an unprocessable critical option, returning a 4.02 Bad Option response, and MUST NOT return a 4.04 Not Found response, because the equivalent path may be present on the server. Since CoAP clients that use the option are usually aware of the possibility of failure, there is no need to provide a diagnostic payload in the error response (as is generally recommended in and its updated version in ). A machine-readable (and, albeit beyond the scope of this document, actionable) response is described in : the server can set Content-Format 257 in the response and send the three-byte payload a1270d, which is the Concise Binary Object Representation (CBOR) encoding for the CoAP problem detail "Unprocessed CoAP option" with the option value CPA13.
Client processing A CoAP client can use the option instead of one or more Uri-Path option(s) if there is a suitable Uri-Path-Abbrev value that can express the requested URI path. The option SHOULD only be sent when it is known that the CoAP server has support for the concrete value. This knowledge is typically not learned/discovered, but follows from other specifications mandating support for it. A client can also send a value if it is merely likely that the server supports it. (The decision threshold varies by application, but generally it's closer to 95% than a mere more-likely-than-not.) This is called "tentative use" of the option. In that case, the client needs to reliably detect failure of the option processing, and needs to fall back to repeating the request with the URI path spelled out (using Uri-Path options), to operate reliably. The client can expect that a server that does not support the Uri-Path-Abbrev option or does not know the option value replies with a 4.02 Bad Option response. Diverging behavior of servers is allowed until the changes specified in have been made. To account for legacy servers, the full set of reactions a client can expect is:
  1. A 4.02 Bad Option response.
  2. A 5.02 Bad Gateway response caused by a proxy that received a RST (Reset) message from the server, or a lack of response.
  3. Having sent a Non-confirmable request message: A RST message.
  4. Having sent a Non-confirmable request message: Not receiving a response.
Some of the complexity of detecting lack of server-side support (items 3 and 4) can be avoided by not using the option with Non-confirmable requests in tentative use. Clients that know that the server supports any Uri-Path-Abbrev value can trust the server to reliably produce a 4.02 Bad Option response for unsupported Uri-Path-Abbrev values. As CoAP multicast requests generally do not result in error responses being returned (but rather, suppressed), tentative use is not available for multicast requests. A generic CoAP client implementation SHOULD NOT use this option without explicit instructions from a higher layer or the known specification that defined the Uri-Path-Abbrev value, because conditions for tentative use are generally not met in this case.
Proxy processing A proxy receiving a request MAY expand into Uri-Path options, or abbreviate to a Uri-Path-Abbrev option, 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 by the receiver. Like a generic client, it SHOULD NOT abbreviate without good reason; and if it does, it MUST be able to fall back to the expanded form upon failure, as to not introduce unexpected errors to the client. A proxy that knows the Uri-Path-Abbrev option but not the concrete value at hand SHOULD forward a request unmodified, which is the behavior it would apply if it did not know the option. A valid exception where the proxy can refuse the request instead is when the proxy is tasked with enforcing access control (see ). When cross-proxying to protocols that cannot transport this option (such as HTTP), the proxy needs to expand the path always.
Interaction with other options The option is mutually exclusive with the Uri-Path option. When receiving both options in a single request, a server MUST treat the Uri-Path-Abbrev option as a critical request option that could not be processed. The Uri-Path-Abbrev option MUST NOT be used in combination with the Proxy-Uri option (or the similar Proxy-Cri option ) by clients. When a request gets forwarded through multiple proxies, any of them might convert the Uri-* options (but, when unaware of its significance, not Uri-Path-Abbrev) into a single Proxy-Uri/-Cri option. This Proxy-Uri/-Cri conversion will get reverted to Uri-* options before or at the final hop where the final hop is not proxy forwarding. It is thus generally inconsequential to the client and the server that Proxy-Uri/-Cri and Uri-Path-Abbrev occur in the same message in such a case. Endpoints that process both the Proxy-Uri/-Cri and the Uri-Path-Abbrev option (that is, servers that are not forwarding like proxies, but are regarded as proxies by other proxies), MUST logically decompose the Proxy-Uri/-Cri options into Proxy-Scheme (or Proxy-Scheme-Number) and Uri-* options before processing the Uri-Path-Abbrev option, which entails an error response if both a path segment in a Proxy-Uri/-Cri option and Uri-Path-Abbrev option are present.
Choice of the option number RFC-Editor: Please remove this section during publication. It is valuable only to the working group and designated experts who manage the limited resource of option numbers, and stays available for future documents that may want to apply similar rationale throughout the draft versions. The option's desired properties (critical, safe-to-forward, part of the Cache-Key) limit the available number space to patterns ending with 0bXXX01 where XXX is not 111. All options encodable with a short (1+0-byte) delta, i.e. <= 12, are already assigned. Usually, we'd then look at other options this is typically combined with, and if there are none (as is the case here), go for a large value in the next more efficient (1+1-byte) space so that the small-but-quite-not-1+0-byte numbers stay usable as 1+0-byte options when combined in their "favorite pairings". (This was done with the EDHOC option which is usually paired with the OSCORE option ). However, in this case, there is an extra concern: The option number should also be smaller than Uri-Query, so that processing the options in a linear fashion can happen as it would happen with Uri-Path: the path gets processed first, setting up a state machine to process the query. As Uri-Query has option number 15, the value 13 for CPA13 is the only good choice for the Uri-Path-Abbrev option.
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 cBRSKI :
    • /.well-known/brski/es
    • /.well-known/brski/rv
    • /.well-known/brski/vs
Note that the well-known 'core' and 'rd' paths are commonly used together with Uri-Query options.
Implementation Status [ This section is to be removed by the RFC editor, which entails removing the reference to 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 . 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 systems, 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. The biggest trouble during implementation was that originally, it was attempted to give the server application access to information on whether or not Uri-Path-Abbrev was used. This was resolved by just not exposing the information -- after all, that is probably good layering practice anyway. Contact information: Christian Amsüss (author), updated 2025-09-26
  • libcoap (preliminary) A report on a yet unpublished implementation and related tests of ietf-core-uri-path-abbrev-01 in libcoap has been submitted at https://github.com/core-wg/uri-path-abbrev/issues/25 on 2025-10-01.
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 and the Proxy-Cri option have the same properties in that regard. The appropriate behavior is for policy enforcement points to refuse any request that contains critical options that are 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 one option into the CoAP Option Numbers registry in the CoRE Parameters registry 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 registry group. The value of the first Uri-Path-Abbrev option in a CoAP request corresponds to a URI path entry in 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 for the registry are given in . The required fields for each registration are:
  • Option value. A non-negative integer (uint) that can be expressed in 32 bits, unique within this registry. All positive values whose most significant bit of the most significant non-zero 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).
  • Expanded path. This text is the URI path (starting with /) that the option is expanded to.
  • Reference. A document that requested the allocation.
Reviewer instructions: The reviewer is instructed to be frugal with the 128 values that correspond to a single-byte option value, focusing on applications that are expected to be useful in different constrained ecosystems. The expanded path is expected to be a well-known path (), 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
Option value 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) 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. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Terminology for Constrained-Node Networks Universität Bremen TZI Ericsson Universitat Politecnica de Catalunya The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. Constrained RESTful Environments (CoRE) Link Format 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] Ephemeral Diffie-Hellman Over COSE (EDHOC) 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. EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol 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. URI Design and Ownership Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic. This document provides guidance on the specification of URI substructure in standards. This document obsoletes RFC 7320 and updates RFC 3986. Requirements for a Lightweight AKE for OSCORE 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. Well-Known Uniform Resource Identifiers (URIs) 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. Managing CBOR codepoints in Internet-Drafts 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 CDN prefix e (draft-ietf-cbor-edn-e-ref), a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. Object Security for Constrained RESTful Environments (OSCORE) 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. Concise Problem Details for Constrained Application Protocol (CoAP) APIs This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. Constrained Resource Identifiers Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) 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. Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing 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). Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) 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. Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Constrained RESTful Environments (CoRE) Resource Directory 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. Constrained Application Protocol (CoAP): Corrections and Clarifications Universität Bremen TZI RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. SCHC: Generic Framework for Static Context Header Compression and Fragmentation This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.
RFC7252-5.4.1: Critical Options and Error Messages This appendix is normative. introduces the concept of rejecting a message, by sending back a RST (Reset) message or by silently ignoring the rejected message. This can deal with messages for which a node does not have (e.g., no longer has) the necessary context to process it, such as a response to a message that a node sent immediately before it rebooted. The concept of rejecting a message is a quite powerful way to limit the complexity of dealing with a variety of error conditions. However, it seems overuses this instrument for the case of Non-confirmable messages. describes Critical Options, which, if not implemented/understood by a node, may require the return of server errors. For Confirmable messages containing requests, unrecognized critical options in requests are handled by a 4.02 (Bad Option) response, while those in Confirmable messages with responses and Acknowledgements are rejected.
  • Unrecognized options of class "critical" that occur in a Confirmable request MUST cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2).
  • Unrecognized options of class "critical" that occur in a Confirmable response, or piggybacked in an Acknowledgement, MUST cause the response to be rejected (Section 4.2).
The 4.02 error response enables clients to perform discovery of whether a critical option is recognized by a server, but surprisingly this works only for Confirmable messages. For unknown reasons, then goes on to handle all Non-confirmable messages with unrecognized critical options by rejecting them:
  • Unrecognized options of class "critical" that occur in a Non-confirmable message MUST cause the message to be rejected (Section 4.3).
This deprives the sender of a Non-confirmable request of the information about what caused the rejection. However, using Non-confirmable messages does not automatically mean that the recipient does not have the context needed to process the message. This unexplained inconsistency has been present in since its initial publication, apparently without causing much trouble. Section of this document describes a situation where discovery of option support is more central to at least one use case; not being able to properly perform this discovery for Non-confirmable messages now emerges as an actual defect. This defect is remedied by applying this change:
INCORRECT:
  • Unrecognized options of class "critical" that occur in a Non-confirmable message MUST cause the message to be rejected (Section 4.3).
CORRECTED:
  • Unrecognized options of class "critical" that occur in a Non-confirmable request SHOULD cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2).
  • Unrecognized options of class "critical" that occur in a Non-confirmable response, or piggybacked in an Acknowledgement, MUST cause the response to be rejected (Section 4.3).
Of course, existing implementations will not immediately change their behavior, so an implementation of a discovery process per this document will still need to deal with uncertainty for the foreseeable future, but the likelihood will reduce over time. Client implementations that are not updated and actually rely on not receiving an error response in this case will simply reject the response message, which has no real disadvantages. Note that the SHOULD about diagnostic payloads is repeated in the corrected text; such a mandate usually needs to provide more information about when this interoperability requirement does not need to be met. While now in many cases provides a better way to respond than a CoAP diagnostic payload; for conciseness, this observation is not included in the normative replacement text proposed above. [ The following section and this sentence to be removed by the RFC editor. ] This technical change was originally developed as , and moved into this document for publication, so that it can be used for simplifications in describing tentative use, where the text would otherwise have had to reaffirm the original behavior.
Further development This appendix is for information only. Several possible further directions are anticipated in this document but not specified here; these are left for further documents that update and thus compatibly extend this document. In any case, server implementations that treat unknown option values or 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.
  • Some values of the option might admit repetition of the option. A document that updates this document and the Uri-Path-Abbrev registry will need to specify how later occurrences of the option extend the series of equivalent Uri-Path options from the first value, or defer some of that decision to that first value's entry.
  • 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 cannot have the most significant bit of the first byte set. This allows future documents to reuse the option for CBOR data items, e.g., the path component of a CRI . Note that those CBOR data items 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 use the FETCH method introduced in .
Change log Since ietf-core-uri-path-abbrev-04: Addressing WGLC comments.
  • Updated references.
  • Use "refuse" rather than "reject" around policy rules, as "reject" has defined CoAP terminology, which even gets used in this document.
  • Editorial changes, including in abstract.
    • Implementation Status section now to be removed by RFC editor.
Since ietf-core-uri-path-abbrev-03:
  • Applied simplifications in handling of Proxy-Uri in combination of -03 more consistently:
    • Removed mandate that proxies that recognize Uri-Path-Abbrev perform conversion to Proxy-Uri expand it if known (they may still do that per more generic rules, but given that a later proxy would undo the Proxy-Uri packing, there's no strong reason to, and it might hinder performance at a constrained server).
    • Limited requirements of processing a Proxy-Uri together with Uri-Path-Abbrev to those endpoints that are actually in a position where they need to do it: those that process both options. That requirement was previously a SHOULD (made sense in -02 when it'd have been done by any server just to cater for the odd proxy) and became a MUST (now that it's only actionable for implementations that actually it).
  • Editorial fixes
Since ietf-core-uri-path-abbrev-02:
  • Added normative appendix fixing an oversight in RFC7252 (moving in from corr-clar). This allows limiting the handling of exotic cases in tentative use.
  • Named Uri-Path-Abbrev as the unprocessed option when it occurs together with Uri-Path.
  • Processing a mixed Proxy-Uri / Uri-Path-Abbrev is now an error if a path component is present in the former. Text was changed to indicate more strongly that seeing a Proxy-Uri and Uri-Path-Abbrev together is an exotic case even when there is no conflict.
  • Formal definitions of abbreviate/expand.
  • Editorial enhancements.
Since ietf-core-uri-path-abbrev-01: Processing WGA review input and cleanup.
  • Using Uri-Path-Abbrev without knowing it will be supported now has a term ("tentative use") and was reworded.
  • The "SHOULD" to support fallback mode was lifted to "SHOULD only be [used when the server is known to support it]", with the recovery being a factual necessity for reliability in tentative use.
  • The fallback detection was extended to account for possible reactions to NONs (namely, RST, not replying at all, and 5.02).
  • Use with multicast was limited to non-tentative use.
  • Added reference to libcoap work.
  • Added pointer to RFC9290 (Problem Details) error messages, discouraging diagnostic payloads.
  • Sections on future work were unified in the appendix.
  • Appendix on open questions was moved into the issue tracker at https://github.com/core-wg/uri-path-abbrev/issues/.
  • Cleanup of IANA considerations where -01 previous changes were not accounted for.
  • "Choice of option number" spelled out and set up for removal before publication.
  • Editorial changes.
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 Discussion with Esko Dijk led to the creation of the document, he questioned choices until the design was simple enough, and also provided editorial input. Carsten Bormann provided , as well as useful input on shaping the registry. Jon Shallow provided much input, in particular around gaps in the fallback process. Marco Tiloca helped bring the document into a consistent shape.
Contributors Universität Bremen TZI
Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org