]>

Austria christian@amsuess.com

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 [ This is a -00, please read the abstract. ]

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 Short-Uri-Path option The Short-Uri-Path option expresses a request's URI path in a more compact form. The Short-Uri-Path option 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 option values are coordinated by IANA in the Short-Uri-Path registry established in this document. A client may use the option instead of the Uri-Host 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 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. A server that supports a Short-Uri-Path value MUST also support the equivalent request composed of Uri-Path components.

Short-Uri-Path Option Summary

RFC-Editor: This document uses the CPA (code point allocation) convention described in [I-D.bormann-cbor-draft-numbers]. 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 Short-Uri-Path option has an opaque value. It is a critical and safe-to-forward option that is part of the cache key, used in CoAP requests. summarizes these, extending Table 4 of ). Its OSCORE treatment is as Class E (). These properties only deviate from the Uri-Path (for which it stands in) in that this option is safe to forward. This has unfortunate 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. A proxy MAY expand or introduce a Short-Uri-Path when forwarding a request, in particular for serving cached responses, as long as this introduces no new errors to the client.

Interaction with other options The option is mutually exclusive with the Uri-Path option. Receiving both options in a single request MUST treated like the presence of a critical request option that could not be processed (that option being either the Short-Uri-Path option or the conflicting option). The Short-Uri-Path option MUST NOT be used in combination with the Proxy-Uri option (or the similar Proxy-CRI option (of )) by clients, and proxies that convert Uri-* options into Proxy-Path MUST expand any Short-Uri-Path if they know the value. By the (de)composition rules of Proxy-Uri and Short-Uri-Path being safe-to-forward, a proxy 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 Short-Uri-Path corresponds are appended to the path as if all components were present as individual options in the request without conflicting. Servers that support both Short-Uri-Path and Proxy-URI/-CRI SHOULD process requests accordingly. (This is not a strict requirement, as there are no known implementations of proxies that actually ).

Repeated use If the document defining the registered value of the first Short-Uri-Path option allows it, further Short-Uri-Path options may be added after that. Their value is not expanded through the Short-Uri-Path IANA registry, but according to rules set up in that particular registration. To be implementable on a wide variety of platforms, those rules should allow expansion into Uri-Path options in an iterative way (i.e., any added Short-Uri-Path option corresponds only to appended Uri-Path options, or cause a 4.02 Bad Option error). Examples of rules are:

• Options after the first are treated exactly like Uri-Path options.
• There can be only one added Short-Uri-Path option, and its opaque value is looked up in a table shaped like the Short-Uri-Path IANA registry.

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 Short-Uri-Path values This document registers values for the following well-known URIs:

• /.well-known/core
• /.well-known/rd (see )

TBD: Ask BRSKI for a description For none of these, the repeated use of the option is specified; note that both are commonly used with Uri-Query options.

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: Short-Uri-Path IANA is requested to enter an one option into the CoAP Option Numbers registry in the CoRE Parameters group:

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

Short-Uri-Path registry IANA is requested to establish a new registry in the CoRE parameters group: Values of the first Short-Uri-Path 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. Entry fields are:

• First option value. An arbitrary length byte sequence given in hexadecimal format; this value needs to be unique within this registry. The most significant bit of the first byte can not be 1.
• 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 single-byte values, focusing on applications that are expected to be useful in different constrained ecosystems. The expanded path (or paths) are 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. If the registration foresees updates, those should always just allow previously unacceptable values into new path segments, and not alter the semantics of previously valid expansions.

Initial values

First option value | Simple expanded path | Reference (empty) | /.well-known/core | of this document 00 | /.well-known/rd | of this document, and

References Normative References 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. 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. Informative References 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. 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 –23 attempts to address the AD review comments; // it is submitted right before the I-D deadline in order to serve as // discussion input to IETF 123 even though not all discussions have // completed. In particular, the updated handling of zone // identifiers requires some additional scrutiny. 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). 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 Short-Uri-Path 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 strucutres 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 an opaque value 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 exension 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.

• Do we want to enable the use of Uri-Query with this option? If so, we need option number 13, or put what the author regards as unreasonable requirements on recipients. In particular, the .well-known/core resource that is attractive for compression is commonly used with Uri-Query options, and it also works well for /.well-known/rd. The alternative is to use a higher number (still 1+1 but less precious), eg. 267.
• Is the transformation of separate options to Proxy-URI even legal for proxies? If not, we can simplify the handling (and Uri-Path would reall not have needed to be proxy-unsafe).
• 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.
• Do we want to add /.well-known/edhoc here, or rather fix it by updating the EDHOC option to also work without an OSCORE option? (The author prefers the latter).

Acknowledgments This document was created out of discussion with Esko Dijk and Michael Richardson. Care to become authors?