Skip to main content

CoAP over GATT (Bluetooth Low Energy Generic Attributes)
draft-amsuess-core-coap-over-gatt-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Christian Amsüss
Last updated 2023-03-13
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-amsuess-core-coap-over-gatt-03
CoRE                                                           C. Amsüss
Internet-Draft                                             14 March 2023
Intended status: Standards Track                                        
Expires: 15 September 2023

        CoAP over GATT (Bluetooth Low Energy Generic Attributes)
                  draft-amsuess-core-coap-over-gatt-03

Abstract

   Interaction from computers and cell phones to constrained devices is
   limited by the different network technologies used, and by the
   available APIs.  This document describes a transport for the
   Constrained Application Protocol (CoAP) that uses Bluetooth GATT
   (Generic Attribute Profile) and its use cases.

Note to Readers

   Discussion of this document takes place on the CORE Working Group
   mailing list (core@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/core/
   (https://mailarchive.ietf.org/arch/browse/core/).

   Source for this draft and an issue tracker can be found at
   https://gitlab.com/chrysn/coap-over-gatt/ (https://gitlab.com/chrysn/
   coap-over-gatt/-/tree/master).

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

   This Internet-Draft will expire on 15 September 2023.

Amsüss                  Expires 15 September 2023               [Page 1]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

Copyright Notice

   Copyright (c) 2023 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.  Application example . . . . . . . . . . . . . . . . . . .   3
     1.2.  Alternatives  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Protocol description  . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Boundary conditions: GATT properties  . . . . . . . . . .   5
     3.2.  Requests and responses  . . . . . . . . . . . . . . . . .   6
       3.2.1.  Message sub-layer . . . . . . . . . . . . . . . . . .   6
       3.2.2.  Using the message sub-layer . . . . . . . . . . . . .   7
       3.2.3.  Message deduplication . . . . . . . . . . . . . . . .   8
       3.2.4.  Requests and responses  . . . . . . . . . . . . . . .   8
       3.2.5.  Fragmentation . . . . . . . . . . . . . . . . . . . .   8
       3.2.6.  Multiple characteristics  . . . . . . . . . . . . . .   9
       3.2.7.  Development directions  . . . . . . . . . . . . . . .   9
     3.3.  Addresses . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.1.  Scheme-free alternative . . . . . . . . . . . . . . .  10
       3.3.2.  Use with persistent addresses . . . . . . . . . . . .  10
     3.4.  Compression and reinterpretation of non-CoAP
           characteristics . . . . . . . . . . . . . . . . . . . . .  11
     3.5.  Additional use of advertisements  . . . . . . . . . . . .  11
   4.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Uniform Resource Identifier (URI) Schemes . . . . . . . .  12
   5.  Security considerations . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .  14
   Appendix B.  Other ToDos  . . . . . . . . . . . . . . . . . . . .  15
   Appendix C.  -03 sketch . . . . . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

Amsüss                  Expires 15 September 2023               [Page 2]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] can be used
   with different network and transport technologies, for example UDP on
   6LoWPAN networks.

   Not all those network technologies are available at end user devices
   in the vicinity of the constrained devices, which inhibits direct
   communication and necessitates the use of gateway devices or cloud
   services.  In particular, 6LoWPAN is not available at all in typical
   end user devices, and while 6LoWPAN-over-BLE (IPSP, the Internet
   Protocol Support Profile of Bluetooth Low Energy (BLE), [RFC7668])
   might be compatible from a radio point of view, many operating
   systems or platforms lack support for it, especially in a user-
   accessible way.

   As a workaround to access constrained CoAP devices from end user
   devices, this document describes a way encapsulate generic CoAP
   exchanges in Bluetooth GATT (Generic Attribute Profile).  This is
   explicitly not designed as means of communication between two devices
   in full control of themselves -- those should rather build an IP
   based network and transport CoAP as originally specified.  It is
   intended as a means for an application to escape the limitations of
   its environment, with a special focus on web applications that use
   the Web Bluetooth [webbluetooth].  In that, it is similar to CoAP-
   over-WebSockets [RFC8323].  GATT, which has read and write semantics,
   is not a perfect match for CoAP's request/response semantics; this
   specification bridges the gap in order to make CoAP transportable
   over what is sometimes the only available protocol.

1.1.  Application example

   Consider a network of home automation light bulbs and switches, which
   internally uses CoAP on a 6LoWPAN network and whose basic pairing
   configuration can be done without additional electronic devices.

   Without CoAP-over-GATT, an application that offers advanced
   configuration requires the use of a dedicated gateway device or a
   router that is equipped and configured to forward between the 6LoWPAN
   and the local network.  In practice, this is often delivered as a
   wired gateway device and a custom app.

   With CoAP-over-GATT, the light bulbs can advertise themselves via
   BLE, and the configuration application can run as a web site.  The
   user navigates to that web site, and it asks permission to contact
   the light bulbs using Web Bluetooth.  The web application can then
   exchange CoAP messages directly with the light bulb, and have it
   proxy requests to other devices connected in the 6LoWPAN network.

Amsüss                  Expires 15 September 2023               [Page 3]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   For browsers that do not support Web Bluetooth, the same web
   application can be packaged into an native application consisting of
   a proxy process that forwards requests received via CoAP-over-
   WebSockets on the loopback interface to CoAP-over-GATT, and a browser
   view that runs the original web application in a configuration to use
   WebSockets rather than CoAP-over-GATT.

   That connection is no replacement when remote control of the system
   is desired (in which case, again, a router is required that
   translates 6LoWPAN to the rest of the network), but suffices for many
   commissioning tasks.

1.2.  Alternatives

   Several approaches were considered, but considered unsuitable for the
   intended use cases:

   *  CoAP over 6LoWPAN over BLE (BLE IPSP): While this is the natural
      choice for transporting CoAP over BLE, it is unavailable on
      typical end user devices.  There is no clear path toward how that
      would be integrated in platforms like Android or iOS, and even if
      it were, creating a network connection to a nearby device from
      within an application might not be possible (if how WLAN networks
      are managed is any indication).

   *  GoldenGate [goldengate]: This introduces significant network
      overhead, and burdens the end user device application with
      shipping a full network stack that is executed in a position where
      it can not integrate fully with the operating system's network
      stack.

      Moreover, this places a retransmission layer on top of a partially
      reliable transport (GATT), duplicating effort and possibly
      aggravating congestion situations.

   *  CoAP over UDP over SLIP over GATT UART [nefzger]: This is similar
      to the GoldenGate approach, but built on the GATT UART provided
      with Nordic Semiconductor's libraries.

      This shares the network stack duplication and retransmission
      concerns of GoldenGate.

   *  slipmux [I-D.bormann-t2trg-slipmux] over BLE GATT UART service:
      This is similar to the previous item; the stack duplication
      concern is addressed, but retransmissions are still active atop of
      a service that already provides some reliability.

Amsüss                  Expires 15 September 2023               [Page 4]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

2.  Terminology

3.  Protocol description

3.1.  Boundary conditions: GATT properties

   [ This section may be shortened in later iterations, but is kept
   around while the protocol is being developed to easily fix mistakes
   made from wrong assumptions. ]

   CoAP-over-GATT has different properties than UDP transported over the
   Internet:

   *  Messages sent by one party are received by the other party in the
      order in which they are sent.  There is no re-ordering.

      (There is also a total order on messages sent by any party, but
      that property is not useful because it's often not accessible
      through the Bluetooth stacks.)

   *  There is limited reliabiliy built into the protocol.

      Data transmissions initiated by the data source can be unreliable
      ("write without response", "notify") or reliable ("write with
      response", "indicate").

      The caveat with their relability is that acknowledgements are sent
      by the BLE stack, without consulting with the application.  (This
      is not only done for simplicity but also for power efficiency:
      There is only a short time window in which the data source is
      listening for confirmations).  Thus, these confirmations can not
      serve to acknowledge that the a CoAP request contained in the
      event was read, understood and is being processed.

      The reliability mechanisms are still useful, though: Both "write"
      and "notify"/"indicate" update the GATT characteristic's state,
      and while a slow application may miss data when sent in fast
      succession, it is reasonable to expect from the BLE stack to
      deliver the last data to the application when no more data is
      sent.

   *  Reads and writes may be subtly confused: When a characteristic is
      written to, and it is read before the BLE server application has
      had time to interact with its BLE stack, the written value may be
      echoed back at read time.

Amsüss                  Expires 15 September 2023               [Page 5]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

      This is likely not problematic when "notify"/"indicate" is used
      instead of polling reads, but it seems prudent to take
      precautions.

3.2.  Requests and responses

   CoAP-over-GATT uses a GATT Characteristics to transport requst and
   response messages.  Similar CoAP-over-UDP it offers both reliable and
   unreliable transfer and message deduplication, but as GATT's
   properties (see Section 3.1) differ from UDP's, it uses a different
   serialization and a different kind of message IDs.

   Tokens are used like with other CoAP transports, and allow keeping
   multiple requests active at the same time.

   A GATT server announces service of UUID 8df804b7-3300-496d-9dfa-
   f8fb40a236bc (abbreviated US in this document), with one or more
   characteristics of UUID 3d4190a8-f322-4ff8-93fa-8d7bed520333
   (abbreviated UC) through BLE advertisements from a BLE peripheral
   (typically a constrained device), which are discovered by a BLE
   central (typically an end user device).  The server and client roles
   of CoAP and GATT are independent of each other: either BLE
   participant can send requests in a CoAP client role.

3.2.1.  Message sub-layer

   At its CoAP-over-GATT characteristic, each party maintains a single
   bit Message ID (initialized at 1 when a connection is created), and
   the last Message ID sent by the peer (initialized at 0 when a
   connection is created).

   Messages are serialized as GATT values.  The GATT client sends a
   message by writing it to the characteristic (reliably using the
   "write with response" or unreliably using "write without response"
   operation); the GATT server sends them reliably using an "indicate"
   or unreliably "notify" event.  The serialization format is the same
   for all, and illustrated in Figure 1:

   0   1   2   3   4       8       16      varying
   +---+---+---+---+-------+-------+-------+---------+----+---------+
   | R | M | C | A |  TKL  |  Code | Token | Options | ff | Payload |
   +---+---+---+---+-------+-------+-------+---------+----+---------+

                     Figure 1: Components of a message

   *  a single message description byte, compose of 4 bits R (Role), M
      (Message ID), C (Confirm) and A (Acknowledge ID), followed by 4
      bits of token length (TKL).

Amsüss                  Expires 15 September 2023               [Page 6]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   *  Code, token, options, payload marker and payload as in [RFC7252].

      Unlike there, there is no 16-bit Message ID field (a similar role
      is taken by bits M and A), and in empty messages, the code is not
      sent.

   The bits are set as follows:

   *  The R bit is always set to 0 by the GATT server, and to 1 by the
      GATT client.

   *  The Message ID bit is always set to the current Message ID of the
      sender.

   *  The Confirm bit is set if the sender asks the peer to acknowledge
      that the message has been noted.

   *  The Acknowledge ID is always set to the peer's last sent Message
      ID that had the Confirm bit set.

   When receiving a message with the C bit set, the recipient MUST
   eventually send a response message with radio reliability.

3.2.2.  Using the message sub-layer

   [ This section reflects ongoing experimentation with the above
   serialization format and rules.  Senders may use other patterns as
   long as they do not stall their peer by not sending any messages
   after the Confirm bit was set. ]

   To send a message unreliably in terms of CoAP transmission, a sender
   sets its latest Message ID in the M bit, sets C to 0, and populates
   the remaining bits per the rules above.  It then sends the message
   unreliably on the radio (it may be sent reliably, especially when the
   peer set the C bit before).  After a CoAP-unreliable message, the
   sender may send more CoAP-unreliable messages.  It should avoid
   sending multiple messages in the same connection event.

   To send a message reliably in terms of CoAP transmission, a sender
   sets its latest Message ID in the M bit, sets C to 1, and populates
   the remaining bits per the rules above.  It thens ends the message
   reliably on the radio (it may send unreliably if a message is
   expected from the peer soon, but then needs to be prepared to send
   the same message again).  After sending that message, the sender does
   not send any other message until a message is received with A equal
   to the sent message's M bit.  The sender may need to send the very
   same message again if no earlier transmission of the message happened
   reliably. [ Do we need to give timing guidance here?  Probably not,

Amsüss                  Expires 15 September 2023               [Page 7]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   because it only happens if there is some expectation in the first
   place. ] The sender may cancel the transmission by sending an empty
   message with the same M and C bits, or by sending different message
   with these bits (which are then all unreliable transmissions).

   When receiving a message with the C bit set, it is up to the
   recipient when to send the radio-reliable message.  If it is expected
   that a radio-reliable message will be sent soon, it is permissible
   and useful to send unrelated unreliable messages that already account
   for the set C bit in their A bit.

3.2.3.  Message deduplication

   CoAP-over-GATT participants MUST ignore a message arriving at a
   characteristic if it is identical to the one received previously in
   the same connection.  (The first message is never ignored).

   Note that it is not possible to send two identical consecutive
   messages unreliably.  When sending identical requests, the sender may
   vary the token.  Sending identical responses generally is rarely
   significant, even with the generalized [I-D.bormann-core-responses],
   because the mechanism to make responses "non-matching" in that
   document's terminology typically incurs variation.  When it does not,
   but the repetition is still significant, sending the messages
   reliably becomes necessary.

3.2.4.  Requests and responses

   CoAP requests and responses are built on the message sub-layer as
   they are in [RFC7252]: requests are sent with a token chosen by the
   CoAP client, and the CoAP server sends a response with the same
   token.

   Responses and message-layer acknowledgments can happen in the same
   message.  Unlike in [RFC7252], there is no association between a
   request and its message ID: Any message may serve as an
   acknowledgement; it is always only the token that matches requests to
   responses.

3.2.5.  Fragmentation

   Attribute values are limited to 512 Bytes ([bluetooth52] Part F
   Section 3.2.9), practically limiting blockwise operation ([RFC7959])
   to size exponents to 4 (resulting in a block size of 256 byte).  Even
   smaller messages might enhance the transfer efficiency when they
   avoid fragmentation at the L2CAP level. [ TBD: Verify: ]

Amsüss                  Expires 15 September 2023               [Page 8]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

3.2.6.  Multiple characteristics

   If a server provides multiple OC typed characteristics, multiple
   messages can be sent without waiting for individual confirmation.
   This is similar to using RFC7252 with NSTART > 1, and may be used by
   the GATT client if the GATT server lists multiple UC characteristics.
   The GATT server can send messages only through characteristics on
   which the GATT client enabled "indicate" or "notify"; if the GATT
   client does not support multiple characteristics, it will just pick
   any and only enable them on that one.

   Each characteristic has its independent message ID bits.  All
   characteristics of a service share a single token space, and
   responses need not necessarily be sent on the characteristic the
   request was sent on.

   The use of muliple characteristics is primarily practical when large
   amounts of data are to be transferred.  These transfers can utilize
   much of BLE's bandwidth because they make it easy to send much data
   within a single BLE connection event.

3.2.7.  Development directions

   *  Is there any good reason to allow read operations?

      A GATT client that is waiting for a Confirm bit to be acknowledged
      might attempt a Read (for the case that the confirmation arrived
      in an unreliable message), but might just as well perform the last
      write again.

      Reading would be more efficient (because it can happen without
      application intervention, and no data is sent), but the added
      complexity might not be worth the enhancements.

   *  Fragmentation.  If the current approach of requiring devices to
      support large MTU sizes turns out to be impractical, or if GATT
      level fragmentation vastly outperforms CoAP fragmentation, it may
      be necessary to use composite reads and writes on GATT.

      Care has to be taken to use only operations supported by
      [webbluetooth]: that API does not expose reads with offsets.

      Offset based fragmentation may also be incompatible with the
      write-with-response approach suggested for reliability.

Amsüss                  Expires 15 September 2023               [Page 9]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

3.3.  Addresses

   The URI scheme associated with CoAP over GATT is "coap+gatt".  The
   default value of Uri-Host is the MAC address of the CoAP server, in
   hexadecimal encoding, with the dash character ("-") separating the
   bytes. [ Some bikeshedding is expected on these details. ]

   User information and port are always absent with this scheme.

   Assembling the URI of a request for the discovery resource of a BLE
   device with the MAC address 00:11:22:33:44:55 would thus be
   assembled, under the rules of Section 6.4 of [RFC7252], to
   coap+gatt://00-11-22-33-44-55/.well-known/core.

   Locally defined host or service name registries may be used to create
   names that are more suitable for human interaction.  For DNS, which
   is widely used for this purpose, no record types are registered that
   map to Bluetooth MAC addresses at the time of writing.

   Note that on some platforms (e.g.  Web Bluetooth [webbluetooth]), the
   peer's or the own address may not be known application.  They may
   come up with an application-internal registered name component (e. g.
   coap+gatt://id-SomeInternalIdentifier/.well-known/core), but must be
   aware that those can not be expressed towards anything outside the
   local stack -- the same way they would avoid using IPv6 zone
   identifiers or URIs whose host name is localhost.

3.3.1.  Scheme-free alternative

   As an alternative to the abovementioned scheme, a zone in .arpa could
   be registered to use addresses like

   coap://001122334455.ble.arpa/.well-known/core

   where the .ble.arpa address do not resolve to any IP addresses.

   [ Accepting this will require a .arpa registering IANA consideration
   to replace the URI one. ]

3.3.2.  Use with persistent addresses

   When services are meant to provide long-lived and universally usable
   URIs, addresses based on MAC addresses can be impractical, because
   they fluctuate on hardware changes.  (Moreover, privacy mechanisms on
   the device or the platform can render them unusable even before
   hardware changes).

Amsüss                  Expires 15 September 2023              [Page 10]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   In the absence of a usable host or service name registry,
   implementers may opt for non-GATT addresses right away.
   [I-D.ietf-core-transport-indication] provides the means to advertise
   a different canonical address, and to announce availability of that
   advertised service on the present transport, CoAP-over-GATT.  If the
   device is not generally reachable, the canonical address might also
   be unreachable (see [I-D.ietf-core-transport-indication] section
   "Unreachable canonical origin address").

   When long-lived addresses circumvent privacy preserving measures,
   considerations concering the tracking of devices [ are TBD along the
   lines of "don't make it discoverable to unauthorized sources, and in
   case of doubt let the peer show its credentials first" ].

3.4.  Compression and reinterpretation of non-CoAP characteristics

   The use of SCHC is being evaluated in combination with CoAP-over-
   GATT; the device can use the characteristic UUID to announce the
   static context used.

   Together with non-traditional response forms
   ([I-D.bormann-core-responses] and contexts that expand, say, a
   numeric value 0x1234 to a message like

   2.05 Content Response-For: GET /temperature Content-Format:
   application/senml+cbor Payload (in JSON-ish equivalent): [ {1 /* unit
   */: "K", 2 /* value */: 0x1234} ]

   This enables a different use case than dealing with limited
   environments: Accessing BLE devices via CoAP without application
   specific gateways.  Any required information about the application
   can be expressed in the SCHC context.

3.5.  Additional use of advertisements

   In the current specification, advertisements are used to indicate
   that CoAP-over-GATT is being used.

   Two more uses of them are being considered:

   *  Some resource metadata might already be transported in
      advertisements.

      These would need to be compact (in the order of magnitude of 10
      bytes or less), and could contain data otherwise only discovered
      by querying the .well-known/core resource, or (hashes of) AS and
      audience values for ACE to facilitate connection creation with a
      device known by its managed identity.

Amsüss                  Expires 15 September 2023              [Page 11]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   *  Advertisements could contain broadcast CoAP messages.

      Given that these non-traditional responses can not have embedded
      requests (as defined in [I-D.bormann-core-responses]) due to size
      contraints, a mechanism such as
      [I-D.ietf-core-observe-multicast-notifications] could be used to
      distribute some consensus request.

4.  IANA considerations

4.1.  Uniform Resource Identifier (URI) Schemes

   IANA is asked to enter a new scheme into the "Uniform Resource
   Identifier (URI) Schemes" registry set up in [RFC7595]:

   *  URI Scheme: "coap+gatt"

   *  Description: CoAP over Bluetooth GATT (sharing the footnote of
      coap+tcp)

   *  Well-Known URI Support: yes, analogous to [RFC7252]

5.  Security considerations

   All data received over GATT is considered untrusted; secure
   communication can be achieved using OSCORE [RFC8613].

   Physical proximity can not be inferred from this means of
   communication.

6.  Acknowledgements

   TBD

   in particular Hauke / and process his input

7.  References

7.1.  Normative References

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

Amsüss                  Expires 15 September 2023              [Page 12]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7595>.

7.2.  Informative References

   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
              <https://www.rfc-editor.org/rfc/rfc7668>.

   [webbluetooth]
              Grant, R. and O. Ruiz-Henríquez, "Web Bluetooth", 24
              February 2020,
              <https://webbluetoothcg.github.io/web-bluetooth/>.

   [goldengate]
              Fitbit, Inc, "Golden Gate", 2020,
              <https://fitbit.github.io/golden-gate/>.

   [nefzger]  Matthias Nefzger, "Talk CoAP to me – IoT over Bluetooth
              Low Energy", 1 March 2021,
              <https://www.maibornwolff.de/en/blog/talk-coap-me-iot-
              over-bluetooth-low-energy>.

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8323>.

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

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7959>.

   [bluetooth52]
              "Bluetooth Core Specification v5.2", 31 December 2019,
              <https://www.bluetooth.org/docman/handlers/
              downloaddoc.ashx?doc_id=478726>.

Amsüss                  Expires 15 September 2023              [Page 13]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   [I-D.bormann-t2trg-slipmux]
              Bormann, C. and T. Kaupat, "Slipmux: Using an UART
              interface for diagnostics, configuration, and packet
              transfer", Work in Progress, Internet-Draft, draft-
              bormann-t2trg-slipmux-03, 4 November 2019,
              <https://datatracker.ietf.org/doc/html/draft-bormann-
              t2trg-slipmux-03>.

   [I-D.bormann-core-responses]
              Bormann, C. and C. Amsüss, "CoAP: Non-traditional response
              forms", Work in Progress, Internet-Draft, draft-bormann-
              core-responses-01, 3 February 2022,
              <https://datatracker.ietf.org/doc/html/draft-bormann-core-
              responses-01>.

   [I-D.ietf-core-transport-indication]
              Amsüss, C., "CoAP Protocol Indication", Work in Progress,
              Internet-Draft, draft-ietf-core-transport-indication-02,
              13 March 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-core-transport-indication-02>.

   [I-D.ietf-core-observe-multicast-notifications]
              Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini,
              "Observe Notifications as CoAP Multicast Responses", Work
              in Progress, Internet-Draft, draft-ietf-core-observe-
              multicast-notifications-05, 24 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              observe-multicast-notifications-05>.

Appendix A.  Change log

   Since -02:

   *  Message format extended by a leading byte, the option to have a
      token.  This enables role reversal and concurrent requests.

   *  The UC identifier was changed to reflect the incompatible change
      in protocol.

   *  A section on used BLE properties was added.

   *  A section providing outlook on other data for advertisements was
      added.

   Since -01:

   *  Point out (possibly conflicting) development directions.

Amsüss                  Expires 15 September 2023              [Page 14]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

   *  Describe URI scheme more completely, including persistent
      addresses.

   *  Aim for standards track.

   *  Describe rejeced alternative approaches.

   Since -00:

   *  Add note on SCHC possibilities.

Appendix B.  Other ToDos

   *  Future proofness?

      -  https://www.ti.com/lit/ml/slyp707/slyp707.pdf mentiones EATT
         for interleaving ATT -- looks like it's just for multiple
         applications, can we be one application?

      -  Same source: MTU can change over time.  (Hopefully issue
         https://gitlab.com/chrysn/coap-over-
         gatt/-/issues/1#note_518745553 (https://gitlab.com/chrysn/coap-
         over-gatt/-/issues/1#note_518745553) handles that
         transparently) -- queued writes? long writes?

      -  GATT caching seems not to be harmful.

Appendix C.  -03 sketch

   *  single prefix byte

      -  "reliable" is always only radio-reliable, doesn't mean ready-
         to-process

      -  unprocessed: assume (demand) latest msg is reliably processed

      -  tkl nibble

      -  1-bit msgid

         o  NONish msgs don't change msgid

            both radio-reliable and radio-unreliable msgs can be NONish

         o  CONish msgs do change msgid, and block characteristic in
            that direction until ACKed

Amsüss                  Expires 15 September 2023              [Page 15]
Internet-Draft  CoAP over GATT (Bluetooth Low Energy Gen      March 2023

            CONish are best sent radio-reliably, and that reliability
            plus guaranteed processing of latest state means that no
            GATT level retransmissions need to be done (no timer mgmt:
            it'll work eventually, although timer would detect broken /
            thread-crashed peer)

      -  1-bit "please ACK" (aka "ready for changing MID?"), which
         places onus on peer to send a radio-reliable msg back

         ACKs can end cycle of tell-me-its-done b/c they're radio-
         reliable, eventually processed, and if the ACKer later sends
         more (esp. non-empty) msgs, they'd still ACK

      -  bits "is-ack, ack-what"? that'd fill up the initial byte.

         o  can do with single-ack bit? it wouldn't flip until ACK
            requested...

      -  need bit for who-sent to recognize own state? (that'd only be
         needed if read is done) and would excede init'l byte

      -  ~NSTART > 1 (precisely: >1 un-acked CON in flight, indep of
         reqs): "trunking" via multiple chars

      -  ACKs as write or notify: these may stall if got lost; party may
         do them if it knows it'll send radio-relible msg anyway. (then,
         may be elided altogether, but sending them allows the original
         sender to send more if we're lucky and it gets through)

      -  minimal subset: echo this-or-that-bit, always send new msgid
         and ask for next OK and block

   bits:

   Party YourMID PleaseAck MyMid | 4 TKL | token* | msg

Author's Address

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

Amsüss                  Expires 15 September 2023              [Page 16]