draft-ietf-core-coap-tcp-tls-04.txt   draft-ietf-core-coap-tcp-tls-05.txt 
CORE C. Bormann CORE C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track S. Lemay Updates: 7641 (if approved) S. Lemay
Expires: February 25, 2017 Zebra Technologies Intended status: Standards Track Zebra Technologies
H. Tschofenig Expires: April 14, 2017 H. Tschofenig
ARM Ltd. ARM Ltd.
K. Hartke K. Hartke
Universitaet Bremen TZI Universitaet Bremen TZI
B. Silverajan B. Silverajan
Tampere University of Technology Tampere University of Technology
B. Raymor, Ed. B. Raymor, Ed.
Microsoft Microsoft
August 24, 2016 October 11, 2016
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
draft-ietf-core-coap-tcp-tls-04 draft-ietf-core-coap-tcp-tls-05
Abstract Abstract
The Constrained Application Protocol (CoAP), although inspired by The Constrained Application Protocol (CoAP), although inspired by
HTTP, was designed to use UDP instead of TCP. The message layer of HTTP, was designed to use UDP instead of TCP. The message layer of
the CoAP over UDP protocol includes support for reliable delivery, the CoAP over UDP protocol includes support for reliable delivery,
simple congestion control, and flow control. simple congestion control, and flow control.
Some environments benefit from the availability of CoAP carried over Some environments benefit from the availability of CoAP carried over
reliable transports such as TCP or TLS. This document outlines the reliable transports such as TCP or TLS. This document outlines the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2017. This Internet-Draft will expire on April 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 5 2. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 5 2.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 5
2.2. UDP-to-TCP gateways . . . . . . . . . . . . . . . . . . . 6 2.2. UDP-to-TCP gateways . . . . . . . . . . . . . . . . . . . 6
2.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 6 2.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 6
2.4. Message Format . . . . . . . . . . . . . . . . . . . . . 6 2.4. Message Format . . . . . . . . . . . . . . . . . . . . . 7
2.5. Message Transmission . . . . . . . . . . . . . . . . . . 10 2.5. Message Transmission . . . . . . . . . . . . . . . . . . 10
3. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 10 3. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 10
3.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 12 3.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 12
3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 13 3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 13
3.3. Message Transmission . . . . . . . . . . . . . . . . . . 14 3.3. Message Transmission . . . . . . . . . . . . . . . . . . 14
3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 14 3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 15
3.5. Closing the Connection . . . . . . . . . . . . . . . . . 15 3.5. Closing the Connection . . . . . . . . . . . . . . . . . 15
4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 15 4.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 16
4.2. Signaling Option Numbers . . . . . . . . . . . . . . . . 16 4.2. Signaling Option Numbers . . . . . . . . . . . . . . . . 16
4.3. Capability and Settings Messages (CSM) . . . . . . . . . 16 4.3. Capability and Settings Messages (CSM) . . . . . . . . . 16
4.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 18 4.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 18
4.5. Release Messages . . . . . . . . . . . . . . . . . . . . 19 4.5. Release Messages . . . . . . . . . . . . . . . . . . . . 19
4.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 20 4.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 20
4.7. Capability and Settings examples . . . . . . . . . . . . 21 4.7. Capability and Settings examples . . . . . . . . . . . . 21
5. Block-wise Transfer and Reliable Transports . . . . . . . . . 21 5. Block-wise Transfer and Reliable Transports . . . . . . . . . 21
5.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 23 5.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 23
5.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 23 5.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 23
6. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. CoAP over TCP and TLS URIs . . . . . . . . . . . . . . . 24 6.1. CoAP over TCP and TLS URIs . . . . . . . . . . . . . . . 24
6.2. CoAP over WebSockets URIs . . . . . . . . . . . . . . . . 25 6.2. CoAP over WebSockets URIs . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 27 7.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 27 8.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 28
8.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 28 8.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 28
8.3. Service Name and Port Number Registration . . . . . . . . 29 8.3. Service Name and Port Number Registration . . . . . . . . 29
8.4. Secure Service Name and Port Number Registration . . . . 30 8.4. Secure Service Name and Port Number Registration . . . . 30
8.5. URI Scheme Registration . . . . . . . . . . . . . . . . . 30 8.5. URI Scheme Registration . . . . . . . . . . . . . . . . . 30
8.6. Well-Known URI Suffix Registration . . . . . . . . . . . 33 8.6. Well-Known URI Suffix Registration . . . . . . . . . . . 33
8.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 33 8.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 33
8.8. WebSocket Subprotocol Registration . . . . . . . . . . . 33 8.8. WebSocket Subprotocol Registration . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Negotiating Protocol Versions . . . . . . . . . . . 36 Appendix A. Updates to RFC7641 Observing Resources in the
Appendix B. CoAP over WebSocket Examples . . . . . . . . . . . . 36 Constrained Application Protocol (CoAP) . . . . . . 36
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40 A.1. Notifications and Reordering . . . . . . . . . . . . . . 36
C.1. Since draft-core-coap-tcp-tls-02 . . . . . . . . . . . . 40 A.2. Transmission and Acknowledgements . . . . . . . . . . . . 36
C.2. Since draft-core-coap-tcp-tls-03 . . . . . . . . . . . . 40 A.3. Cancellation . . . . . . . . . . . . . . . . . . . . . . 37
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Negotiating Protocol Versions . . . . . . . . . . . 37
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix C. CoAP over WebSocket Examples . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 41
D.1. Since draft-core-coap-tcp-tls-02 . . . . . . . . . . . . 41
D.2. Since draft-core-coap-tcp-tls-03 . . . . . . . . . . . . 41
D.3. Since draft-core-coap-tcp-tls-04 . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] was designed The Constrained Application Protocol (CoAP) [RFC7252] was designed
for Internet of Things (IoT) deployments, assuming that UDP [RFC0768] for Internet of Things (IoT) deployments, assuming that UDP [RFC0768]
or DTLS [RFC6347] over UDP can be used unimpeded. UDP is a good or DTLS [RFC6347] over UDP can be used unimpeded. UDP is a good
choice for transferring small amounts of data across networks that choice for transferring small amounts of data across networks that
follow the IP architecture. follow the IP architecture.
Some CoAP deployments need to integrate well with existing enterprise Some CoAP deployments need to integrate well with existing enterprise
skipping to change at page 5, line 18 skipping to change at page 5, line 23
different transports, such as between WebSockets and UDP. different transports, such as between WebSockets and UDP.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document assumes that readers are familiar with the terms and This document assumes that readers are familiar with the terms and
concepts that are used in [RFC6455] and [RFC7252]. concepts that are used in [RFC6455], [RFC7252], and [RFC7641].
The term "reliable transport" only refers to stream-based transport The term "reliable transport" only refers to stream-based transport
protocols such as TCP. protocols such as TCP.
BERT Option: BERT Option:
A Block1 or Block2 option that includes an SZX value of 7. A Block1 or Block2 option that includes an SZX value of 7.
BERT Block: BERT Block:
The payload of a CoAP message that is affected by a BERT Option in The payload of a CoAP message that is affected by a BERT Option in
descriptive usage (Section 2.1 of [I-D.ietf-core-block]). descriptive usage (Section 2.1 of [RFC7959]).
2. CoAP over TCP 2. CoAP over TCP
The request/response interaction model of CoAP over TCP is the same The request/response interaction model of CoAP over TCP is the same
as CoAP over UDP. The primary differences are in the message layer. as CoAP over UDP. The primary differences are in the message layer.
CoAP over UDP supports optional reliability by defining four types of CoAP over UDP supports optional reliability by defining four types of
messages: Confirmable, Non-confirmable, Acknowledgement, and Reset. messages: Confirmable, Non-confirmable, Acknowledgement, and Reset.
TCP eliminates the need for the message layer to support reliability. TCP eliminates the need for the message layer to support reliability.
As a result, message types are not defined in CoAP over TCP. As a result, message types are not defined in CoAP over TCP.
skipping to change at page 6, line 45 skipping to change at page 6, line 51
2.3. Opening Handshake 2.3. Opening Handshake
Both the client and the server MUST send a Capability and Settings Both the client and the server MUST send a Capability and Settings
message (CSM see Section 4.3) as its first message on the connection. message (CSM see Section 4.3) as its first message on the connection.
This message establishes the initial settings and capabilities for This message establishes the initial settings and capabilities for
the endpoint such as maximum message size or support for block-wise the endpoint such as maximum message size or support for block-wise
transfers. The absence of options in the CSM indicates that base transfers. The absence of options in the CSM indicates that base
values are assumed. values are assumed.
To avoid unnecessary latency, a client MAY send additional messages
without waiting to receive the server CSM; however, it is important
to note that the server CSM might advertise capabilities that impact
how a client is expected to communicate with the server. For
example, the server CSM could advertise a Max-Message-Size option
(See Section 4.3.2) that is smaller than the base value (1152).
Clients and servers MUST treat a missing or invalid CSM as a Clients and servers MUST treat a missing or invalid CSM as a
connection error and abort the connection (see Section 4.6). connection error and abort the connection (see Section 4.6).
2.4. Message Format 2.4. Message Format
The CoAP message format defined in [RFC7252], as shown in Figure 3, The CoAP message format defined in [RFC7252], as shown in Figure 3,
relies on the datagram transport (UDP, or DTLS over UDP) for keeping relies on the datagram transport (UDP, or DTLS over UDP) for keeping
the individual messages separate and for providing length the individual messages separate and for providing length
information. information.
skipping to change at page 7, line 32 skipping to change at page 7, line 44
specified for CoAP over UDP. The differences are as follows: specified for CoAP over UDP. The differences are as follows:
o Since the underlying TCP connection provides retransmissions and o Since the underlying TCP connection provides retransmissions and
deduplication, there is no need for the reliability mechanisms deduplication, there is no need for the reliability mechanisms
provided by CoAP over UDP. The "T" and "Message ID" fields in the provided by CoAP over UDP. The "T" and "Message ID" fields in the
CoAP message header are elided. CoAP message header are elided.
o The "Ver" field is elided as well. In constrast to the UDP o The "Ver" field is elided as well. In constrast to the UDP
message layer for UDP and DTLS, the CoAP over TCP message layer message layer for UDP and DTLS, the CoAP over TCP message layer
does not send a version number in each message. If required in does not send a version number in each message. If required in
the future, a new Capability and Settings Option (See Appendix A) the future, a new Capability and Settings Option (See Appendix B)
could be defined to support version negotiation. could be defined to support version negotiation.
o In a stream oriented transport protocol such as TCP, a form of o In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed. For this purpose, CoAP over TCP message delimitation is needed. For this purpose, CoAP over TCP
introduces a length field with variable size. Figure 4 shows the introduces a length field with variable size. Figure 4 shows the
adjusted CoAP message format with a modified structure for the adjusted CoAP message format with a modified structure for the
fixed header (first 4 bytes of the CoAP over UDP header), which fixed header (first 4 bytes of the CoAP over UDP header), which
includes the length information of variable size, shown here as an includes the length information of variable size, shown here as an
8-bit length. 8-bit length.
skipping to change at page 10, line 20 skipping to change at page 10, line 36
any order. Responses MUST be returned over the same connection as any order. Responses MUST be returned over the same connection as
the originating request. Concurrent requests are differentiated by the originating request. Concurrent requests are differentiated by
their Token, which is scoped locally to the connection. their Token, which is scoped locally to the connection.
The connection is bi-directional, so requests can be sent both by the The connection is bi-directional, so requests can be sent both by the
entity that established the connection and the remote host. entity that established the connection and the remote host.
Retransmission and deduplication of messages is provided by the TCP/ Retransmission and deduplication of messages is provided by the TCP/
TLS protocol. TLS protocol.
Since the TCP protocol provides ordered delivery of messages, the
mechanism for reordering detection when observing resources [RFC7641]
is not needed. The value of the Observe Option in notifications MAY
be empty on transmission and MUST be ignored on reception.
3. CoAP over WebSockets 3. CoAP over WebSockets
CoAP over WebSockets can be used in a number of configurations. The CoAP over WebSockets can be used in a number of configurations. The
most basic configuration is a CoAP client retrieving or updating a most basic configuration is a CoAP client retrieving or updating a
CoAP resource located at a CoAP server that exposes a WebSocket CoAP resource located at a CoAP server that exposes a WebSocket
endpoint (Figure 9). The CoAP client acts as the WebSocket client, endpoint (Figure 9). The CoAP client acts as the WebSocket client,
establishes a WebSocket connection, and sends a CoAP request, to establishes a WebSocket connection, and sends a CoAP request, to
which the CoAP server returns a CoAP response. The WebSocket which the CoAP server returns a CoAP response. The WebSocket
connection can be used for any number of requests. connection can be used for any number of requests.
skipping to change at page 14, line 8 skipping to change at page 14, line 29
future, CoAP over WebSockets can address the requirement by the future, CoAP over WebSockets can address the requirement by the
definition of a new subprotocol identifier that is negotiated during definition of a new subprotocol identifier that is negotiated during
the opening handshake. the opening handshake.
Requests and response messages can be fragmented as specified in Requests and response messages can be fragmented as specified in
Section 5.4 of [RFC6455], though typically they are sent unfragmented Section 5.4 of [RFC6455], though typically they are sent unfragmented
as they tend to be small and fully buffered before transmission. The as they tend to be small and fully buffered before transmission. The
WebSocket protocol does not provide means for multiplexing. If it is WebSocket protocol does not provide means for multiplexing. If it is
not desirable for a large message to monopolize the connection, not desirable for a large message to monopolize the connection,
requests and responses can be transferred in a block-wise fashion as requests and responses can be transferred in a block-wise fashion as
defined in [I-D.ietf-core-block]. defined in [RFC7959].
Empty messages (Code 0.00) MUST be ignored by the recipient (see also Empty messages (Code 0.00) MUST be ignored by the recipient (see also
Section 4.4). Section 4.4).
3.3. Message Transmission 3.3. Message Transmission
CoAP requests and responses are exchanged asynchronously over the CoAP requests and responses are exchanged asynchronously over the
WebSocket connection. A CoAP client can send multiple requests WebSocket connection. A CoAP client can send multiple requests
without waiting for a response and the CoAP server can return without waiting for a response and the CoAP server can return
responses in any order. Responses MUST be returned over the same responses in any order. Responses MUST be returned over the same
skipping to change at page 14, line 31 skipping to change at page 15, line 5
connection. connection.
The connection is bi-directional, so requests can be sent both by the The connection is bi-directional, so requests can be sent both by the
entity that established the connection and the remote host. entity that established the connection and the remote host.
Retransmission and deduplication of messages is provided by the Retransmission and deduplication of messages is provided by the
WebSocket protocol. CoAP over WebSockets therefore does not make a WebSocket protocol. CoAP over WebSockets therefore does not make a
distinction between Confirmable or Non-Confirmable messages, and does distinction between Confirmable or Non-Confirmable messages, and does
not provide Acknowledgement or Reset messages. not provide Acknowledgement or Reset messages.
Since the WebSocket protocol provides ordered delivery of messages,
the mechanism for reordering detection when observing resources
[RFC7641] is not needed. The value of the Observe Option in
notifications MAY be empty on transmission and MUST be ignored on
reception.
3.4. Connection Health 3.4. Connection Health
When a client does not receive any response for some time after When a client does not receive any response for some time after
sending a CoAP request (or, similarly, when a client observes a sending a CoAP request (or, similarly, when a client observes a
resource and it does not receive any notification for some time), the resource and it does not receive any notification for some time), the
connection between the WebSocket client and the WebSocket server may connection between the WebSocket client and the WebSocket server may
be lost or temporarily disrupted without the client being aware of be lost or temporarily disrupted without the client being aware of
it. it.
To check the health of the WebSocket connection (and thereby of all To check the health of the WebSocket connection (and thereby of all
skipping to change at page 15, line 15 skipping to change at page 15, line 30
There is no way to retransmit a request without creating a new one. There is no way to retransmit a request without creating a new one.
Re-registering interest in a resource is permitted, but entirely Re-registering interest in a resource is permitted, but entirely
unnecessary. unnecessary.
3.5. Closing the Connection 3.5. Closing the Connection
The WebSocket connection is closed as specified in Section 7 of The WebSocket connection is closed as specified in Section 7 of
[RFC6455]. [RFC6455].
All requests for which the CoAP client has not received a response All requests for which the CoAP client has not received a response
yet are cancelled when the connection is closed. If the client yet are cancelled when the connection is closed.
observes one or more resources over the WebSocket connection, then
the CoAP server (or intermediary in the role of the CoAP server) MUST
remove all entries associated with the client from the lists of
observers when the connection is closed.
4. Signaling 4. Signaling
Signaling messages are introduced to allow peers to: Signaling messages are introduced to allow peers to:
o Share characteristics such as maximum message size for the o Share characteristics such as maximum message size for the
connection connection
o Shutdown the connection in an ordered fashion o Shutdown the connection in an ordered fashion
skipping to change at page 18, line 4 skipping to change at page 18, line 16
4.3.3. Block-wise Transfer Capability Option 4.3.3. Block-wise Transfer Capability Option
+--------+-----------+----------------+--------+--------+-----------+ +--------+-----------+----------------+--------+--------+-----------+
| Number | Applies | Name | Format | Length | Base | | Number | Applies | Name | Format | Length | Base |
| | to | | | | Value | | | to | | | | Value |
+--------+-----------+----------------+--------+--------+-----------+ +--------+-----------+----------------+--------+--------+-----------+
| 4 | CSM | Block-wise | empty | 0 | (none) | | 4 | CSM | Block-wise | empty | 0 | (none) |
| | | Transfer | | | | | | | Transfer | | | |
+--------+-----------+----------------+--------+--------+-----------+ +--------+-----------+----------------+--------+--------+-----------+
A sender can use the Block-wise Transfer elective Option to indicate A sender can use the Block-wise Transfer elective Option to indicate
that it supports the block-wise transfer protocol that it supports the block-wise transfer protocol [RFC7959].
[I-D.ietf-core-block].
If the option is not given, the peer has no information about whether If the option is not given, the peer has no information about whether
block-wise transfers are supported by the sender or not. An block-wise transfers are supported by the sender or not. An
implementation that supports block-wise transfers SHOULD indicate the implementation that supports block-wise transfers SHOULD indicate the
Block-wise Transfer Option. If a Max-Message-Size Option is Block-wise Transfer Option. If a Max-Message-Size Option is
indicated with a value that is greater than 1152 (in the same or a indicated with a value that is greater than 1152 (in the same or a
different CSM message), the Block-wise Transfer Option also indicates different CSM message), the Block-wise Transfer Option also indicates
support for BERT (see Section 5). support for BERT (see Section 5).
4.4. Ping and Pong Messages 4.4. Ping and Pong Messages
skipping to change at page 19, line 44 skipping to change at page 20, line 13
this server. this server.
+--------+----------+-------------------+--------+--------+---------+ +--------+----------+-------------------+--------+--------+---------+
| Number | Applies | Name | Format | Length | Base | | Number | Applies | Name | Format | Length | Base |
| | to | | | | Value | | | to | | | | Value |
+--------+----------+-------------------+--------+--------+---------+ +--------+----------+-------------------+--------+--------+---------+
| 4 | Release | Alternate-Address | string | 1-255 | (none) | | 4 | Release | Alternate-Address | string | 1-255 | (none) |
+--------+----------+-------------------+--------+--------+---------+ +--------+----------+-------------------+--------+--------+---------+
The Alternative-Address elective option requests the peer to instead The Alternative-Address elective option requests the peer to instead
open a connection of the same kind as the present connection to the open a connection of the same scheme as the present connection to the
alternative transport address given. Its value is in the form alternative transport address given. Its value is in the form
"authority" as defined in Section 3.2 of [RFC3986]. "authority" as defined in Section 3.2 of [RFC3986].
+--------+------------+----------+--------+--------+------------+ +--------+------------+----------+--------+--------+------------+
| Number | Applies to | Name | Format | Length | Base Value | | Number | Applies to | Name | Format | Length | Base Value |
+--------+------------+----------+--------+--------+------------+ +--------+------------+----------+--------+--------+------------+
| 6 | Release | Hold-Off | uint | 0-3 | (none) | | 6 | Release | Hold-Off | uint | 0-3 | (none) |
+--------+------------+----------+--------+--------+------------+ +--------+------------+----------+--------+--------+------------+
The Hold-Off elective option indicates that the server is requesting The Hold-Off elective option indicates that the server is requesting
skipping to change at page 21, line 44 skipping to change at page 22, line 4
Code = 7.03 Pong --> 0xe3 Code = 7.03 Pong --> 0xe3
Token = 0x42 Token = 0x42
Figure 16: Pong Message Example Figure 16: Pong Message Example
5. Block-wise Transfer and Reliable Transports 5. Block-wise Transfer and Reliable Transports
The message size restrictions defined in Section 4.6 of CoAP The message size restrictions defined in Section 4.6 of CoAP
[RFC7252] to avoid IP fragmentation are not necessary when CoAP is [RFC7252] to avoid IP fragmentation are not necessary when CoAP is
used over a reliable byte stream transport. While this suggests that used over a reliable byte stream transport. While this suggests that
the Block-wise transfer protocol [I-D.ietf-core-block] is also no the Block-wise transfer protocol [RFC7959] is also no longer needed,
longer needed, it remains applicable for a number of cases: it remains applicable for a number of cases:
o large messages, such as firmware downloads, may cause undesired o large messages, such as firmware downloads, may cause undesired
head-of-line blocking when a single TCP connection is used head-of-line blocking when a single TCP connection is used
o a UDP-to-TCP gateway may simply not have the context to convert a o a UDP-to-TCP gateway may simply not have the context to convert a
message with a Block Option into the equivalent exchange without message with a Block Option into the equivalent exchange without
any use of a Block Option (it would need to convert the entire any use of a Block Option (it would need to convert the entire
blockwise exchange from start to end into a single exchange) blockwise exchange from start to end into a single exchange)
The 'Block-wise Extension for Reliable Transport (BERT)' extends the The 'Block-wise Extension for Reliable Transport (BERT)' extends the
Block protocol to enable the use of larger messages over a reliable Block protocol to enable the use of larger messages over a reliable
transport. transport.
The use of this new extension is signaled by sending Block1 or Block2 The use of this new extension is signaled by sending Block1 or Block2
Options with SZX == 7 (a "BERT option"). SZX == 7 is a reserved Options with SZX == 7 (a "BERT option"). SZX == 7 is a reserved
value in [I-D.ietf-core-block]. value in [RFC7959].
In control usage, a BERT option is interpreted in the same way as the In control usage, a BERT option is interpreted in the same way as the
equivalent Option with SZX == 6, except that it also indicates the equivalent Option with SZX == 6, except that it also indicates the
capability to process BERT blocks. As with the basic Block protocol, capability to process BERT blocks. As with the basic Block protocol,
the recipient of a CoAP request with a BERT option in control usage the recipient of a CoAP request with a BERT option in control usage
is allowed to respond with a different SZX value, e.g. to send a non- is allowed to respond with a different SZX value, e.g. to send a non-
BERT block instead. BERT block instead.
In descriptive usage, a BERT Option is interpreted in the same way as In descriptive usage, a BERT Option is interpreted in the same way as
the equivalent Option with SZX == 6, except that the payload is the equivalent Option with SZX == 6, except that the payload is
skipping to change at page 35, line 33 skipping to change at page 35, line 33
10.17487/RFC7925, July 2016, 10.17487/RFC7925, July 2016,
<http://www.rfc-editor.org/info/rfc7925>. <http://www.rfc-editor.org/info/rfc7925>.
9.2. Informative References 9.2. Informative References
[HomeGateway] [HomeGateway]
Eggert, L., "An experimental study of home gateway Eggert, L., "An experimental study of home gateway
characteristics", Proceedings of the 10th annual characteristics", Proceedings of the 10th annual
conference on Internet measurement, 2010. conference on Internet measurement, 2010.
[I-D.becker-core-coap-sms-gprs]
Becker, M., Li, K., Kuladinithi, K., and T. Poetsch,
"Transport of CoAP over SMS", draft-becker-core-coap-sms-
gprs-05 (work in progress), August 2014.
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
draft-ietf-core-block-21 (work in progress), July 2016.
[LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine [LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine
Technical Specification Candidate Version 1.0", April Technical Specification Candidate Version 1.0", April
2016, <http://technical.openmobilealliance.org/Technical/R 2016, <http://technical.openmobilealliance.org/Technical/R
elease_Program/docs/LightweightM2M/V1_0-20160407-C/ elease_Program/docs/LightweightM2M/V1_0-20160407-C/
OMA-TS-LightweightM2M-V1_0-20160407-C.pdf>. OMA-TS-LightweightM2M-V1_0-20160407-C.pdf>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
10.17487/RFC0768, August 1980, 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
skipping to change at page 36, line 30 skipping to change at page 36, line 25
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI
10.17487/RFC6454, December 2011, 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>. <http://www.rfc-editor.org/info/rfc6454>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC Protocol (HTTP/1.1): Message Syntax and Routing", RFC
7230, DOI 10.17487/RFC7230, June 2014, 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
Appendix A. Negotiating Protocol Versions [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<http://www.rfc-editor.org/info/rfc7959>.
Appendix A. Updates to RFC7641 Observing Resources in the Constrained
Application Protocol (CoAP)
A.1. Notifications and Reordering
When using the Observe Option with CoAP over UDP, notifications from
the server set the option value to an increasing sequence number for
reordering detection on the client since messages can arrive in a
different order than they were sent. This sequence number is not
required for CoAP over reliable transports since the TCP protocol
ensures reliable and ordered delivery of messages. The value of the
Observe Option in 2.xx notifications MAY be empty on transmission and
MUST be ignored on reception.
A.2. Transmission and Acknowledgements
For CoAP over UDP, server notifications to the client can be
confirmable or non-confirmable. A confirmable message requires the
client to either respond with an acknowledgement message or a reset
message. An acknowledgement message indicates that the client is
alive and wishes to receive further notifications. A reset message
indicates that the client does not recognize the token which causes
the server to remove the associated entry from the list of observers.
Since TCP eliminates the need for the message layer to support
reliability, CoAP over reliable transports does not support
confirmable or non-confirmable message types. All notifications are
delivered reliably to the client with positive acknowledgement of
receipt occurring at the TCP level. If the client does not recognize
the token in a notification, it MAY immediately abort the connection
(see Section 4.6) and SHOULD include a diagnostic payload.
A.3. Cancellation
For CoAP over UDP, a client that is no longer interested in receiving
notifications can "forget" the observation and respond to the next
notification from the server with a reset message to cancel the
observation.
For CoAP over reliable transports, a client MUST explicitly
deregister by issuing a GET request that has the Token field set to
the token of the observation to be cancelled and includes an Observe
Option with the value set to 1 (deregister).
If the client observes one or more resources over a reliable
connection, then the CoAP server (or intermediary in the role of the
CoAP server) MUST remove all entries associated with the client
endpoint from the lists of observers when the connection is either
closed or times out.
Appendix B. Negotiating Protocol Versions
CoAP is defined in [RFC7252] with a version number of 1. At this CoAP is defined in [RFC7252] with a version number of 1. At this
time, there is no known reason to support version numbers different time, there is no known reason to support version numbers different
from 1. from 1.
In contrast to the message layer for UDP and DTLS, the CoAP over TCP In contrast to the message layer for UDP and DTLS, the CoAP over TCP
message format does not include a version number. If version message format does not include a version number. If version
negotiation needs to be addressed in the future, then Capability and negotiation needs to be addressed in the future, then Capability and
Settings have been specifically designed to enable such a potential Settings have been specifically designed to enable such a potential
feature. feature.
Appendix B. CoAP over WebSocket Examples Appendix C. CoAP over WebSocket Examples
This section gives examples for the first two configurations This section gives examples for the first two configurations
discussed in Section 3. discussed in Section 3.
An example of the process followed by a CoAP client to retrieve the An example of the process followed by a CoAP client to retrieve the
representation of a resource identified by a "coap+ws" URI might be representation of a resource identified by a "coap+ws" URI might be
as follows. Figure 19 below illustrates the WebSocket and CoAP as follows. Figure 19 below illustrates the WebSocket and CoAP
messages exchanged in detail. messages exchanged in detail.
1. The CoAP client obtains the URI <coap+ws://example.org/sensors/ 1. The CoAP client obtains the URI <coap+ws://example.org/sensors/
skipping to change at page 40, line 5 skipping to change at page 41, line 5
| | | +------------------------------------+ | | | +------------------------------------+
| | | | 2.05 Content | | | | | 2.05 Content |
| | | | Token: 0x7d | | | | | Token: 0x7d |
| | | | Payload: "ready" | | | | | Payload: "ready" |
| | | +------------------------------------+ | | | +------------------------------------+
| | | | | |
Figure 20: A CoAP client retrieves the representation of a resource Figure 20: A CoAP client retrieves the representation of a resource
identified by a "coap" URI via a WebSockets-enabled CoAP proxy identified by a "coap" URI via a WebSockets-enabled CoAP proxy
Appendix C. Change Log Appendix D. Change Log
The RFC Editor is requested to remove this section at publication. The RFC Editor is requested to remove this section at publication.
C.1. Since draft-core-coap-tcp-tls-02 D.1. Since draft-core-coap-tcp-tls-02
Merged draft-savolainen-core-coap-websockets-07 Merged draft-bormann- Merged draft-savolainen-core-coap-websockets-07 Merged draft-bormann-
core-block-bert-01 Merged draft-bormann-core-coap-sig-02 core-block-bert-01 Merged draft-bormann-core-coap-sig-02
C.2. Since draft-core-coap-tcp-tls-03 D.2. Since draft-core-coap-tcp-tls-03
Editorial updates Editorial updates
Added mandatory exchange of Capabilities and Settings messages after Added mandatory exchange of Capabilities and Settings messages after
connecting connecting
Added support for coaps+tcp port 5684 and more details on Added support for coaps+tcp port 5684 and more details on
Application-Layer Protocol Negotiation (ALPN) Application-Layer Protocol Negotiation (ALPN)
Added guidance on CoAP Signaling Ping-Pong versus WebSocket Ping-Pong Added guidance on CoAP Signaling Ping-Pong versus WebSocket Ping-Pong
Updated references and requirements for TLS security considerations Updated references and requirements for TLS security considerations
D.3. Since draft-core-coap-tcp-tls-04
Updated references
Added Appendix: Updates to RFC7641 Observing Resources in the
Constrained Application Protocol (CoAP)
Updated Capability and Settings Message (CSM) exchange in the Opening
Handshake to allow client to send messages before receiving server
CSM
Acknowledgements Acknowledgements
We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier
Delaby, Christian Groves, Nadir Javed, Michael Koster, Matthias Delaby, Christian Groves, Nadir Javed, Michael Koster, Matthias
Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Zach Shelby, Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Zach Shelby,
Andrew Summers, Julien Vermillard, and Gengyu Wei for their feedback. Andrew Summers, Julien Vermillard, and Gengyu Wei for their feedback.
Contributors Contributors
Valik Solorzano Barboza Valik Solorzano Barboza
Zebra Technologies Zebra Technologies
820 W. Jackson Blvd. Suite 700 820 W. Jackson Blvd. Suite 700
Chicago 60607 Chicago 60607
United States of America United States of America
Phone: +1-847-634-6700 Phone: +1-847-634-6700
Email: vsolorzanobarboza@zebra.com Email: vsolorzanobarboza@zebra.com
Teemu Savolainen Teemu Savolainen
 End of changes. 31 change blocks. 
62 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/