



CoRE                                                           C. Amsüss
Internet-Draft                                                          
Intended status: Standards Track                           M. Richardson
Expires: 30 March 2026                          Sandelman Software Works
                                                       26 September 2025


                     URI-Path abbreviation in CoAP
                   draft-ietf-core-uri-path-abbrev-01

Abstract

   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

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-core-uri-path-abbrev/.

   Discussion of this document takes place on the Constrained RESTful
   Environments Working Group mailing list (mailto:core@ietf.org), which
   is archived at https://mailarchive.ietf.org/arch/browse/core/.
   Subscribe at https://www.ietf.org/mailman/listinfo/core/.

   Source for this draft and an issue tracker can be found at
   https://github.com/core-wg/uri-path-abbrev.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Amsüss & Richardson       Expires 30 March 2026                 [Page 1]

Internet-Draft               Uri-Path-Abbrev              September 2025


   This Internet-Draft will expire on 30 March 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivating example  . . . . . . . . . . . . . . . . . . .   3
     1.2.  Conventions and Definitions . . . . . . . . . . . . . . .   3
   2.  The Uri-Path-Abbrev option  . . . . . . . . . . . . . . . . .   3
     2.1.  Server processing . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Client processing . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Proxy processing  . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Interaction with other options  . . . . . . . . . . . . .   5
     2.5.  Future development  . . . . . . . . . . . . . . . . . . .   6
     2.6.  Choice of the option number . . . . . . . . . . . . . . .   6
   3.  Initial Uri-Path-Abbrev values  . . . . . . . . . . . . . . .   6
   4.  Implementation Status . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  CoAP option: Uri-Path-Abbrev  . . . . . . . . . . . . . .   9
     6.2.  Uri-Path-Abbrev registry  . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Further development  . . . . . . . . . . . . . . . .  13
   Appendix B.  Open questions . . . . . . . . . . . . . . . . . . .  14
   Appendix C.  Change log . . . . . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16









Amsüss & Richardson       Expires 30 March 2026                 [Page 2]

Internet-Draft               Uri-Path-Abbrev              September 2025


1.  Introduction

   When building application components on CoAP ([RFC7252]), 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 [RFC7228]).  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 [RFC7252] and
   [RFC6690] 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 ([RFC9528]) or
   establishing an initial identity ([RFC9148]) can not rely on
   discovered short paths, and need to use well-known paths.  The best
   practice established in [BCP190] 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.

1.1.  Motivating example

   The design criteria for [RFC9528] described in Section 2.11 of
   [I-D.ietf-lake-reqs-04] 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.

1.2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document assumes basic familiarity with CoAP ([RFC7252]), in
   particular its Uri-* options.

2.  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.




Amsüss & Richardson       Expires 30 March 2026                 [Page 3]

Internet-Draft               Uri-Path-Abbrev              September 2025


   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 [RFC8615].
   The numeric option values are coordinated by IANA in the Uri-Path-
   Abbrev registry established in this document in Section 6.2.

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

         Table 1: Uri-Path-Abbrev Option Summary (C = Critical, U =
                  Unsafe, N = NoCacheKey, R = Repeatable)


   // 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 option is a critical, safe-to-forward, and part of the cache key,
   and used in CoAP requests.  Table 1 summarizes these, extending
   Table 4 of [RFC7252]).  Its OSCORE treatment is as Class E
   ([RFC8613]).

   The option has an integer value from the registry established in
   Section 6.2.

   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.

2.1.  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.





Amsüss & Richardson       Expires 30 March 2026                 [Page 4]

Internet-Draft               Uri-Path-Abbrev              September 2025


   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.

2.2.  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.

2.3.  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 Section 5).

   When cross-proxying to protocols that can not transport this option
   (such as HTTP), the proxy needs to expand the path.

2.4.  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).



Amsüss & Richardson       Expires 30 March 2026                 [Page 5]

Internet-Draft               Uri-Path-Abbrev              September 2025


   The Uri-Path-Abbrev option MUST NOT be used in combination with the
   Proxy-Uri option (or the similar Proxy-CRI option (of
   [I-D.ietf-core-href])) 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).

2.5.  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.

2.6.  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).

3.  Initial Uri-Path-Abbrev values

   This document registers values for the following well-known URIs:




Amsüss & Richardson       Expires 30 March 2026                 [Page 6]

Internet-Draft               Uri-Path-Abbrev              September 2025


   *  /.well-known/core

   *  /.well-known/rd (see [RFC9175])

   *  /.well-known/edhoc (see [RFC9528])

   *  For EST ([RFC9148]):

      -  /.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 [I-D.ietf-anima-constrained-voucher]:

      -  /.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.

4.  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 [RFC7942].
   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



Amsüss & Richardson       Expires 30 March 2026                 [Page 7]

Internet-Draft               Uri-Path-Abbrev              September 2025


   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 [RFC7942], "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/
      (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

5.  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 [RFC7252] and the Proxy-Cri option of
   [I-D.ietf-core-href] 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.




Amsüss & Richardson       Expires 30 March 2026                 [Page 8]

Internet-Draft               Uri-Path-Abbrev              September 2025


6.  IANA Considerations

6.1.  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

6.2.  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
   [RFC8126]).  Change control for the registry follows this document's
   publication stream.  Initial values are given in Table 2.

   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.




Amsüss & Richardson       Expires 30 March 2026                 [Page 9]

Internet-Draft               Uri-Path-Abbrev              September 2025


      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.

     +========+==============+======================================+
     | First  | Simple       | Reference                            |
     | option | expanded     |                                      |
     | value  | path         |                                      |
     +========+==============+======================================+
     | 0      | /.well-      | Section 3 of this document           |
     |        | known/core   |                                      |
     +--------+--------------+--------------------------------------+
     | 1      | /.well-      | Section 3 of this document, and      |
     |        | known/rd     | [RFC9176]                            |
     +--------+--------------+--------------------------------------+
     | 2      | /.well-      | Section 3 of this document, and      |
     |        | known/edhoc  | [RFC9528]                            |
     +--------+--------------+--------------------------------------+
     | 301    | /.well-      | Section 3 of this document, and      |
     |        | known/est/   | [RFC9148]                            |
     |        | crts         |                                      |
     +--------+--------------+--------------------------------------+
     | 302    | /.well-      | Section 3 of this document, and      |
     |        | known/est/   | [RFC9148]                            |
     |        | sen          |                                      |
     +--------+--------------+--------------------------------------+
     | 303    | /.well-      | Section 3 of this document, and      |
     |        | known/est/   | [RFC9148]                            |
     |        | sren         |                                      |
     +--------+--------------+--------------------------------------+
     | 304    | /.well-      | Section 3 of this document, and      |
     |        | known/est/   | [RFC9148]                            |
     |        | skg          |                                      |
     +--------+--------------+--------------------------------------+
     | 305    | /.well-      | Section 3 of this document, and      |
     |        | known/est/   | [RFC9148]                            |
     |        | skc          |                                      |
     +--------+--------------+--------------------------------------+



Amsüss & Richardson       Expires 30 March 2026                [Page 10]

Internet-Draft               Uri-Path-Abbrev              September 2025


     | 306    | /.well-      | Section 3 of this document, and      |
     |        | known/est/   | [RFC9148]                            |
     |        | att          |                                      |
     +--------+--------------+--------------------------------------+
     | 401    | /.well-      | Section 3 of this document, and      |
     |        | known/brski/ | [I-D.ietf-anima-constrained-voucher] |
     |        | es           |                                      |
     +--------+--------------+--------------------------------------+
     | 402    | /.well-      | Section 3 of this document, and      |
     |        | known/brski/ | [I-D.ietf-anima-constrained-voucher] |
     |        | rv           |                                      |
     +--------+--------------+--------------------------------------+
     | 403    | /.well-      | Section 3 of this document, and      |
     |        | known/brski/ | [I-D.ietf-anima-constrained-voucher] |
     |        | vs           |                                      |
     +--------+--------------+--------------------------------------+

         Table 2: Initial values for the Uri-Path-Abbrev registry

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7252>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [BCP190]   Best Current Practice 190,
              <https://www.rfc-editor.org/info/bcp190>.
              At the time of writing, this BCP comprises the following:

              Nottingham, M., "URI Design and Ownership", BCP 190,
              RFC 8820, DOI 10.17487/RFC8820, June 2020,
              <https://www.rfc-editor.org/info/rfc8820>.





Amsüss & Richardson       Expires 30 March 2026                [Page 11]

Internet-Draft               Uri-Path-Abbrev              September 2025


   [I-D.bormann-cbor-draft-numbers]
              Bormann, C., "Managing CBOR codepoints in Internet-
              Drafts", Work in Progress, Internet-Draft, draft-bormann-
              cbor-draft-numbers-06, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-bormann-cbor-
              draft-numbers-06>.

   [I-D.ietf-anima-constrained-voucher]
              Richardson, M., Van der Stok, P., Kampanakis, P., and E.
              Dijk, "Constrained Bootstrapping Remote Secure Key
              Infrastructure (cBRSKI)", Work in Progress, Internet-
              Draft, draft-ietf-anima-constrained-voucher-28, 6 July
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              anima-constrained-voucher-28>.

   [I-D.ietf-core-href]
              Bormann, C. and H. Birkholz, "Constrained Resource
              Identifiers", Work in Progress, Internet-Draft, draft-
              ietf-core-href-24, 30 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              href-24>.

   [I-D.ietf-lake-reqs-04]
              Vučinić, M., Selander, G., Mattsson, J. P., and D. Garcia-
              Carillo, "Requirements for a Lightweight AKE for OSCORE",
              Work in Progress, Internet-Draft, draft-ietf-lake-reqs-04,
              8 June 2020, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lake-reqs-04>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/rfc/rfc6690>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/rfc/rfc7228>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/rfc/rfc7942>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.




Amsüss & Richardson       Expires 30 March 2026                [Page 12]

Internet-Draft               Uri-Path-Abbrev              September 2025


   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8613>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

   [RFC8790]  Keränen, A. and M. Mohajer, "FETCH and PATCH with Sensor
              Measurement Lists (SenML)", RFC 8790,
              DOI 10.17487/RFC8790, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8790>.

   [RFC9148]  van der Stok, P., Kampanakis, P., Richardson, M., and S.
              Raza, "EST-coaps: Enrollment over Secure Transport with
              the Secure Constrained Application Protocol", RFC 9148,
              DOI 10.17487/RFC9148, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9148>.

   [RFC9175]  Amsüss, C., Preuß Mattsson, J., and G. Selander,
              "Constrained Application Protocol (CoAP): Echo, Request-
              Tag, and Token Processing", RFC 9175,
              DOI 10.17487/RFC9175, February 2022,
              <https://www.rfc-editor.org/rfc/rfc9175>.

   [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
              P. van der Stok, "Constrained RESTful Environments (CoRE)
              Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
              2022, <https://www.rfc-editor.org/rfc/rfc9176>.

   [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
              "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
              DOI 10.17487/RFC9528, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9528>.

Appendix A.  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.







Amsüss & Richardson       Expires 30 March 2026                [Page 13]

Internet-Draft               Uri-Path-Abbrev              September 2025


      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
      [I-D.ietf-core-href].  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 Section 2.4.

   *  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 [RFC8790].

Appendix B.  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
      (https://github.com/core-wg/corrclar/issues/51).



Amsüss & Richardson       Expires 30 March 2026                [Page 14]

Internet-Draft               Uri-Path-Abbrev              September 2025


   *  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.

Appendix C.  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).



Amsüss & Richardson       Expires 30 March 2026                [Page 15]

Internet-Draft               Uri-Path-Abbrev              September 2025


   *  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.

Authors' Addresses

   Christian Amsüss
   Austria
   Email: christian@amsuess.com


   Michael Richardson
   Sandelman Software Works
   Email: mcr+ietf@sandelman.ca

























Amsüss & Richardson       Expires 30 March 2026                [Page 16]
