draft-ietf-core-coap-tcp-tls-10.txt   draft-ietf-core-coap-tcp-tls-11.txt 
CORE C. Bormann CORE C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Updates: 7641, 7959 (if approved) S. Lemay Updates: 7641, 7959 (if approved) S. Lemay
Intended status: Standards Track Zebra Technologies Intended status: Standards Track Zebra Technologies
Expires: May 3, 2018 H. Tschofenig Expires: June 21, 2018 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 December 18, 2017
October 30, 2017
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
draft-ietf-core-coap-tcp-tls-10 draft-ietf-core-coap-tcp-tls-11
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 49 skipping to change at page 1, line 48
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 3, 2018. This Internet-Draft will expire on June 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 7 3. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 7 3.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 7
3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 8 3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 8
3.3. Message Transmission . . . . . . . . . . . . . . . . . . 10 3.3. Message Transmission . . . . . . . . . . . . . . . . . . 10
3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 11 3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 11
4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 11 4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 12
4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 13 4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 13
4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 14 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 14
4.3. Message Transmission . . . . . . . . . . . . . . . . . . 15 4.3. Message Transmission . . . . . . . . . . . . . . . . . . 15
4.4. Connection Health . . . . . . . . . . . . . . . . . . . . 15 4.4. Connection Health . . . . . . . . . . . . . . . . . . . . 15
5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 16 5.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 16
5.2. Signaling Option Numbers . . . . . . . . . . . . . . . . 16 5.2. Signaling Option Numbers . . . . . . . . . . . . . . . . 16
5.3. Capabilities and Settings Messages (CSM) . . . . . . . . 16 5.3. Capabilities and Settings Messages (CSM) . . . . . . . . 16
5.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 18 5.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 19
5.5. Release Messages . . . . . . . . . . . . . . . . . . . . 20 5.5. Release Messages . . . . . . . . . . . . . . . . . . . . 20
5.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 21 5.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 21
5.7. Signaling examples . . . . . . . . . . . . . . . . . . . 22 5.7. Signaling examples . . . . . . . . . . . . . . . . . . . 22
6. Block-wise Transfer and Reliable Transports . . . . . . . . . 22 6. Block-wise Transfer and Reliable Transports . . . . . . . . . 23
6.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 24 6.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 24
6.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 24 6.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 25
7. Observing Resources over Reliable Transports . . . . . . . . 25 7. Observing Resources over Reliable Transports . . . . . . . . 25
7.1. Notifications and Reordering . . . . . . . . . . . . . . 25 7.1. Notifications and Reordering . . . . . . . . . . . . . . 26
7.2. Transmission and Acknowledgements . . . . . . . . . . . . 25 7.2. Transmission and Acknowledgements . . . . . . . . . . . . 26
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 26
7.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 26 7.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 27
8. CoAP over Reliable Transport URIs . . . . . . . . . . . . . . 26 8. CoAP over Reliable Transport URIs . . . . . . . . . . . . . . 27
8.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 27 8.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 28
8.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 27 8.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 28
8.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 28 8.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 29
8.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 29 8.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 30
8.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 30 8.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 31
8.6. Decomposing URIs into Options . . . . . . . . . . . . . . 30 8.6. Decomposing URIs into Options . . . . . . . . . . . . . . 31
8.7. Composing URIs from Options . . . . . . . . . . . . . . . 31 8.7. Composing URIs from Options . . . . . . . . . . . . . . . 32
9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. TLS binding for CoAP over TCP . . . . . . . . . . . . . . 32 9.1. TLS binding for CoAP over TCP . . . . . . . . . . . . . . 33
9.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 33 9.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 34
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 34 10.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 34 11.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 34
11.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 34 11.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 35
11.3. Service Name and Port Number Registration . . . . . . . 36 11.3. Service Name and Port Number Registration . . . . . . . 36
11.4. Secure Service Name and Port Number Registration . . . . 36 11.4. Secure Service Name and Port Number Registration . . . . 37
11.5. URI Scheme Registration . . . . . . . . . . . . . . . . 37 11.5. URI Scheme Registration . . . . . . . . . . . . . . . . 38
11.6. Well-Known URI Suffix Registration . . . . . . . . . . . 39 11.6. Well-Known URI Suffix Registration . . . . . . . . . . . 40
11.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 39 11.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 40
11.8. WebSocket Subprotocol Registration . . . . . . . . . . . 40 11.8. WebSocket Subprotocol Registration . . . . . . . . . . . 40
11.9. CoAP Option Numbers Registry . . . . . . . . . . . . . . 40 11.9. CoAP Option Numbers Registry . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . 40 12.1. Normative References . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . 42 12.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. CoAP over WebSocket Examples . . . . . . . . . . . . 44 Appendix A. CoAP over WebSocket Examples . . . . . . . . . . . . 45
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 48
B.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 47 B.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 48
B.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 47 B.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 48
B.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 47 B.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 48
B.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 47 B.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 48
B.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 48 B.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 49
B.6. Since draft-ietf-core-coap-tcp-tls-07 . . . . . . . . . . 48 B.6. Since draft-ietf-core-coap-tcp-tls-07 . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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]
can be used unimpeded, as can the Datagram Transport Layer Security can be used unimpeded, as can the Datagram Transport Layer Security
protocol (DTLS [RFC6347]) over UDP. The use of CoAP over UDP is protocol (DTLS [RFC6347]) over UDP. The use of CoAP over UDP is
focused on simplicity, has a low code footprint, and a small over- focused on simplicity, has a low code footprint, and a small over-
the-wire message size. the-wire message size.
skipping to change at page 6, line 41 skipping to change at page 6, line 41
BERT extends [RFC7959] to enable the use of larger messages over a BERT extends [RFC7959] to enable the use of larger messages over a
reliable transport. reliable transport.
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 (see Section 2.1 of [RFC7959]). descriptive usage (see Section 2.1 of [RFC7959]).
Transport Connection:
Underlying reliable byte stream connection, as directly provided
by TCP, or indirectly via TLS or WebSockets.
Connection:
Transport Connection, unless explicitly qualified otherwise.
Connection Initiator: Connection Initiator:
The peer that opens a reliable byte stream connection, i.e., the The peer that opens a Transport Connection, i.e., the TCP active
TCP active opener, TLS client, or WebSocket client. opener, TLS client, or WebSocket client.
Connection Acceptor: Connection Acceptor:
The peer that accepts the reliable byte stream connection opened The peer that accepts the Transport Connection opened by the other
by the other peer, i.e., the TCP passive opener, TLS server, or peer, i.e., the TCP passive opener, TLS server, or WebSocket
WebSocket server. server.
3. CoAP over TCP 3. 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.
The message layer of CoAP over UDP supports optional reliability by The message layer of CoAP over UDP supports optional reliability by
defining four types of messages: Confirmable, Non-confirmable, defining four types of messages: Confirmable, Non-confirmable,
Acknowledgement, and Reset. In addition, messages include a Message Acknowledgement, and Reset. In addition, messages include a Message
ID to relate Acknowledgments to Confirmable messages and to detect ID to relate Acknowledgments to Confirmable messages and to detect
duplicate messages. duplicate messages.
The management of the connections is left to the application, i.e., The management of the transport connections is left to the
the present specification does not describe how an application application, i.e., the present specification does not describe how an
decides to open a connection or to re-open another one in the application decides to open a connection or to re-open another one in
presence of failures (or what it would deem to be a failure, see also the presence of failures (or what it would deem to be a failure, see
Section 5.4). In particular, the Connection Initiator need not be also Section 5.4). In particular, the Connection Initiator need not
the client of the first request placed on the connection. be the client of the first request placed on the connection. Some
implementations will want to implement a dynamic connection
management similar to the one described in Section 6 of [RFC7230] for
HTTP, opening a connection when the first client request is ready to
be sent and reusing that for further messages for a while, until no
message is sent for a certain time and no requests are outstanding
(possibly with a configurable idle time) and a release process is
started (Section 5.5). In implementations of this kind, connection
releases or aborts may not be indicated as errors to the application
but may simply be handled by automatic reconnection once the need
arises again. Other implementations may be based on configured
connections that are kept open continuously and lead to management
system notifications on release or abort. The protocol defined in
the present specification is intended to work with either model (or
other, application-specific connection management models).
3.1. Messaging Model 3.1. Messaging Model
Conceptually, CoAP over TCP replaces most of the message layer of Conceptually, CoAP over TCP replaces most of the message layer of
CoAP over UDP with a framing mechanism on top of the byte-stream CoAP over UDP with a framing mechanism on top of the byte-stream
provided by TCP/TLS, conveying the length information for each provided by TCP/TLS, conveying the length information for each
message that on datagram transports is provided by the UDP/DTLS message that on datagram transports is provided by the UDP/DTLS
datagram layer. datagram layer.
TCP ensures reliable message transmission, so the message layer of TCP ensures reliable message transmission, so the message layer of
skipping to change at page 10, line 35 skipping to change at page 10, line 43
TKL = 1 ___/ TKL = 1 ___/
Code = 2.03 --> 0x43 Code = 2.03 --> 0x43
Token = 0x7f Token = 0x7f
Figure 5: CoAP message with no options or payload Figure 5: CoAP message with no options or payload
The semantics of the other CoAP header fields are left unchanged. The semantics of the other CoAP header fields are left unchanged.
3.3. Message Transmission 3.3. Message Transmission
Once a connection is established, each endpoint MUST send a Once a transport connection is established, each endpoint MUST send a
Capabilities and Settings message (CSM see Section 5.3) as their Capabilities and Settings message (CSM, see Section 5.3) as their
first message on the connection. This message establishes the first message on the connection. This message establishes the
initial settings and capabilities for the endpoint, such as maximum initial settings and capabilities for the endpoint, such as maximum
message size or support for block-wise transfers. The absence of message size or support for block-wise transfers. The absence of
options in the CSM indicates that base values are assumed. options in the CSM indicates that base values are assumed.
To avoid a deadlock, the Connection Initiator MUST NOT wait for the To avoid a deadlock, the Connection Initiator MUST NOT wait for the
Connection Acceptor to send its initial CSM message before sending Connection Acceptor to send its initial CSM message before sending
its own initial CSM message. Conversely, the Connection Acceptor MAY its own initial CSM message. Conversely, the Connection Acceptor MAY
wait for the Connection Initiator to send its initial CSM message wait for the Connection Initiator to send its initial CSM message
before sending its own initial CSM message. before sending its own initial CSM message.
skipping to change at page 11, line 12 skipping to change at page 11, line 20
the Connection Acceptor's CSM might indicate capabilities that impact the Connection Acceptor's CSM might indicate capabilities that impact
how the initiator is expected to communicate with the acceptor. For how the initiator is expected to communicate with the acceptor. For
example, the acceptor CSM could indicate a Max-Message-Size option example, the acceptor CSM could indicate a Max-Message-Size option
(see Section 5.3.1) that is smaller than the base value (1152) in (see Section 5.3.1) that is smaller than the base value (1152) in
order to limit both buffering requirements and head-of-line blocking. order to limit both buffering requirements and head-of-line blocking.
Endpoints MUST treat a missing or invalid CSM as a connection error Endpoints MUST treat a missing or invalid CSM as a connection error
and abort the connection (see Section 5.6). and abort the connection (see Section 5.6).
CoAP requests and responses are exchanged asynchronously over the CoAP requests and responses are exchanged asynchronously over the
TCP/TLS connection. A CoAP client can send multiple requests without transport connection. A CoAP client can send multiple requests
waiting for a response and the CoAP server can return responses in without waiting for a response and the CoAP server can return
any order. Responses MUST be returned over the same connection as responses in any order. Responses MUST be returned over the same
the originating request. Concurrent requests are differentiated by connection as the originating request. Concurrent requests are
their Token, which is scoped locally to the connection. differentiated by their Token, which is scoped locally to the
connection.
The connection is bi-directional, so requests can be sent both by the The transport connection is bi-directional, so requests can be sent
entity that established the connection (Connection Initiator) and the both by the entity that established the connection (Connection
remote host (Connection Acceptor). If one side does not implement a Initiator) and the remote host (Connection Acceptor). If one side
CoAP server, an error response MUST be returned for all CoAP requests does not implement a CoAP server, an error response MUST be returned
from the other side. The simplest approach is to always return 5.01 for all CoAP requests from the other side. The simplest approach is
(Not Implemented). A more elaborate mock server could also return to always return 5.01 (Not Implemented). A more elaborate mock
4.xx responses such as 4.04 (Not Found) or 4.02 (Bad Option) where server could also return 4.xx responses such as 4.04 (Not Found) or
appropriate. 4.02 (Bad Option) where appropriate.
Retransmission and deduplication of messages is provided by the TCP Retransmission and deduplication of messages is provided by the TCP
protocol. protocol.
3.4. Connection Health 3.4. Connection Health
Empty messages (Code 0.00) can always be sent and MUST be ignored by Empty messages (Code 0.00) can always be sent and MUST be ignored by
the recipient. This provides a basic keep-alive function that can the recipient. This provides a basic keep-alive function that can
refresh NAT bindings. refresh NAT bindings.
If a CoAP client does not receive any response for some time after If a CoAP 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), it resource and it does not receive any notification for some time), it
can send a CoAP Ping Signaling message (see Section 5.4) to test the can send a CoAP Ping Signaling message (see Section 5.4) to test the
connection and verify that the CoAP server is responsive. transport connection and verify that the CoAP server is responsive.
When the underlying TCP connection is closed or reset, the signaling When the underlying transport connection is closed or reset, the
state and any observation state (see Section 7.4) associated with the signaling state and any observation state (see Section 7.4)
reliable connection are removed. In flight messages may or may not associated with the connection are removed. In flight messages may
be lost. or may not be lost.
4. CoAP over WebSockets 4. CoAP over WebSockets
CoAP over WebSockets is intentionally similar to CoAP over TCP; CoAP over WebSockets is intentionally similar to CoAP over TCP;
therefore, this section only specifies the differences between the therefore, this section only specifies the differences between the
transports. transports.
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 on a CoAP server that exposes a WebSocket CoAP resource located on a CoAP server that exposes a WebSocket
skipping to change at page 17, line 5 skipping to change at page 17, line 5
5.3. Capabilities and Settings Messages (CSM) 5.3. Capabilities and Settings Messages (CSM)
Capabilities and Settings messages (CSM) are used for two purposes: Capabilities and Settings messages (CSM) are used for two purposes:
o Each capability option indicates one capability of the sender to o Each capability option indicates one capability of the sender to
the recipient. the recipient.
o Each setting option indicates a setting that will be applied by o Each setting option indicates a setting that will be applied by
the sender. the sender.
One CSM MUST be sent by each endpoint at the start of the connection. One CSM MUST be sent by each endpoint at the start of the transport
Further CSM MAY be sent at any other time by either endpoint over the connection. Further CSM MAY be sent at any other time by either
lifetime of the connection. endpoint over the lifetime of the connection.
Both capability and setting options are cumulative. A CSM does not Both capability and setting options are cumulative. A CSM does not
invalidate a previously sent capability indication or setting even if invalidate a previously sent capability indication or setting even if
it is not repeated. A capability message without any option is a no- it is not repeated. A capability message without any option is a no-
operation (and can be used as such). An option that is sent might operation (and can be used as such). An option that is sent might
override a previous value for the same option. The option defines override a previous value for the same option. The option defines
how to handle this case if needed. how to handle this case if needed.
Base values are listed below for CSM Options. These are the values Base values are listed below for CSM Options. These are the values
for the capability and setting before any Capabilities and Settings for the capability and setting before any Capabilities and Settings
skipping to change at page 17, line 34 skipping to change at page 17, line 34
Capabilities and Settings messages are indicated by the 7.01 code Capabilities and Settings messages are indicated by the 7.01 code
(CSM). (CSM).
5.3.1. Max-Message-Size Capability Option 5.3.1. Max-Message-Size Capability Option
The sender can use the elective Max-Message-Size Option to indicate The sender can use the elective Max-Message-Size Option to indicate
the maximum size of a message in bytes that it can receive. The the maximum size of a message in bytes that it can receive. The
message size indicated includes the entire message, starting from the message size indicated includes the entire message, starting from the
first byte of the message header and ending at the end of the message first byte of the message header and ending at the end of the message
payload (there is no relationship of the message size to the overall payload.
request or response body size that may be achievable in block-wise
transfer.) (Note that there is no relationship of the message size to the
overall request or response body size that may be achievable in
block-wise transfer. For example, the exchange depicted further down
in Figure 13 can be performed if the CoAP client indicates a value of
around 6000 bytes for the Max-Message-Size option, even though the
total body size transferred to the client is 3072 + 5120 + 4711 =
12903 bytes.)
+---+---+---+---------+------------------+--------+--------+--------+ +---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base | | # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value | | | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+ +---+---+---+---------+------------------+--------+--------+--------+
| 2 | | | CSM | Max-Message-Size | uint | 0-4 | 1152 | | 2 | | | CSM | Max-Message-Size | uint | 0-4 | 1152 |
+---+---+---+---------+------------------+--------+--------+--------+ +---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable C=Critical, R=Repeatable
As per Section 4.6 of [RFC7252], the base value (and the value used As per Section 4.6 of [RFC7252], the base value (and the value used
when this option is not implemented) is 1152. when this option is not implemented) is 1152.
The active value of the Max-Message-Size Option is replaced each time The active value of the Max-Message-Size Option is replaced each time
the option is sent with a modified value. Its starting value is its the option is sent with a modified value. Its starting value is its
base value. base value.
5.3.2. Block-wise Transfer Capability Option 5.3.2. Block-Wise-Transfer Capability Option
+---+---+---+---------+-----------------+--------+--------+---------+ +---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base | | # | C | R | 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 | | | |
+---+---+---+---------+-----------------+--------+--------+---------+ +---+---+---+---------+------------------+--------+--------+--------+
C=Critical, R=Repeatable C=Critical, R=Repeatable
A sender can use the elective Block-wise Transfer Option to indicate A sender can use the elective Block-Wise-Transfer Option to indicate
that it supports the block-wise transfer protocol [RFC7959]. that it supports the block-wise transfer protocol [RFC7959].
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 wishing to offer block-wise transfers to its peer implementation wishing to offer block-wise transfers to its peer
therefore needs to indicate the Block-wise Transfer Option. therefore needs to indicate the Block-Wise-Transfer Option.
If a Max-Message-Size Option is indicated with a value that is If a Max-Message-Size Option is indicated with a value that is
greater than 1152 (in the same or a different CSM message), the greater than 1152 (in the same or a different CSM message), the
Block-wise Transfer Option also indicates support for BERT (see Block-Wise-Transfer Option also indicates support for BERT (see
Section 6). Subsequently, if the Max-Message-Size Option is Section 6). Subsequently, if the Max-Message-Size Option is
indicated with a value equal to or less than 1152, BERT support is no indicated with a value equal to or less than 1152, BERT support is no
longer indicated. (Note that indication of BERT support obliges longer indicated. (Note that indication of BERT support obliges
neither peer to actually choose to make use of BERT.) neither peer to actually choose to make use of BERT.)
Implementation note: When indicating a value of the Max-Message-Size Implementation note: When indicating a value of the Max-Message-Size
option with an intention to enable BERT, the indicating option with an intention to enable BERT, the indicating
implementation may want to choose a BERT size message it wants to implementation may want to choose a BERT size message it wants to
encourage and add a delta for the header and any options that also encourage and add a delta for the header and any options that also
need to be included in the message. Section 4.6 of [RFC7252] adds need to be included in the message. Section 4.6 of [RFC7252] adds
skipping to change at page 20, line 8 skipping to change at page 20, line 11
A sender can also include an elective Custody Option in a Ping A sender can also include an elective Custody Option in a Ping
message to explicitly request the inclusion of an elective Custody message to explicitly request the inclusion of an elective Custody
Option in the corresponding Pong message. In that case, the receiver Option in the corresponding Pong message. In that case, the receiver
SHOULD delay its Pong message until it finishes processing all the SHOULD delay its Pong message until it finishes processing all the
request/response messages received prior to the Ping message on the request/response messages received prior to the Ping message on the
current connection. current connection.
5.5. Release Messages 5.5. Release Messages
A Release message indicates that the sender does not want to continue A Release message indicates that the sender does not want to continue
maintaining the connection and opts for an orderly shutdown. The maintaining the transport connection and opts for an orderly
details are in the options. A diagnostic payload (see Section 5.5.2 shutdown, but wants to leave it to the peer to actually start closing
of [RFC7252]) MAY be included. A peer will normally respond to a the connection. The details are in the options. A diagnostic
Release message by closing the TCP/TLS connection. Messages may be payload (see Section 5.5.2 of [RFC7252]) MAY be included.
in flight or responses outstanding when the sender decides to send a
Release message. The peer responding to the Release message SHOULD A peer will normally respond to a Release message by closing the
delay the closing of the connection until it has responded to all transport connection. (In case that does not happen, the sender of
requests received by it before the Release message. It also MAY wait the release may want to implement a timeout mechanism if getting rid
for the responses to its own requests. of the connection is actually important to it.)
Messages may be in flight or responses outstanding when the sender
decides to send a Release message (which is one reason the sender had
decided to wait with closing the connection). The peer responding to
the Release message SHOULD delay the closing of the connection until
it has responded to all requests received by it before the Release
message. It also MAY wait for the responses to its own requests.
It is NOT RECOMMENDED for the sender of a Release message to continue
sending requests on the connection it already indicated to be
released: the peer might close the connection at any time and miss
those requests. There is no obligation for the peer to check for
this condition, though.
Release messages are indicated by the 7.04 code (Release). Release messages are indicated by the 7.04 code (Release).
Release messages can indicate one or more reasons using elective Release messages can indicate one or more reasons using elective
options. The following options are defined: options. The following options are defined:
+---+---+---+---------+------------------+--------+--------+--------+ +---+---+---+---------+------------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base | | # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value | | | | | to | | | | Value |
+---+---+---+---------+------------------+--------+--------+--------+ +---+---+---+---------+------------------+--------+--------+--------+
skipping to change at page 21, line 12 skipping to change at page 21, line 29
C=Critical, R=Repeatable C=Critical, R=Repeatable
The elective Hold-Off Option indicates that the server is requesting The elective Hold-Off Option indicates that the server is requesting
that the peer not reconnect to it for the number of seconds given in that the peer not reconnect to it for the number of seconds given in
the value. the value.
5.6. Abort Messages 5.6. Abort Messages
An Abort message indicates that the sender is unable to continue An Abort message indicates that the sender is unable to continue
maintaining the connection and cannot even wait for an orderly maintaining the transport connection and cannot even wait for an
release. The sender shuts down the connection immediately after the orderly release. The sender shuts down the connection immediately
abort (and may or may not wait for a Release or Abort message or after the abort (and may or may not wait for a Release or Abort
connection shutdown in the inverse direction). A diagnostic payload message or connection shutdown in the inverse direction). A
(see Section 5.5.2 of [RFC7252]) SHOULD be included in the Abort diagnostic payload (see Section 5.5.2 of [RFC7252]) SHOULD be
message. Messages may be in flight or responses outstanding when the included in the Abort message. Messages may be in flight or
sender decides to send an Abort message. The general expectation is responses outstanding when the sender decides to send an Abort
that these will NOT be processed. message. The general expectation is that these will NOT be
processed.
Abort messages are indicated by the 7.05 code (Abort). Abort messages are indicated by the 7.05 code (Abort).
Abort messages can indicate one or more reasons using elective Abort messages can indicate one or more reasons using elective
options. The following option is defined: options. The following option is defined:
+---+---+---+---------+-----------------+--------+--------+---------+ +---+---+---+---------+-----------------+--------+--------+---------+
| # | C | R | Applies | Name | Format | Length | Base | | # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value | | | | | to | | | | Value |
+---+---+---+---------+-----------------+--------+--------+---------+ +---+---+---+---------+-----------------+--------+--------+---------+
skipping to change at page 22, line 48 skipping to change at page 23, line 27
6. Block-wise Transfer and Reliable Transports 6. 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 transport. While this suggests that the Block- used over a reliable transport. While this suggests that the Block-
wise transfer protocol [RFC7959] is also no longer needed, it remains wise transfer protocol [RFC7959] is also no longer needed, it remains
applicable for a number of cases: 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 transport 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.
skipping to change at page 35, line 17 skipping to change at page 36, line 10
the name of the option, and a reference to the option's the name of the option, and a reference to the option's
documentation. documentation.
Initial entries in this sub-registry are as follows: Initial entries in this sub-registry are as follows:
+------------+--------+---------------------+-----------+ +------------+--------+---------------------+-----------+
| Applies to | Number | Name | Reference | | Applies to | Number | Name | Reference |
+------------+--------+---------------------+-----------+ +------------+--------+---------------------+-----------+
| 7.01 | 2 | Max-Message-Size | [RFCthis] | | 7.01 | 2 | Max-Message-Size | [RFCthis] |
| | | | | | | | | |
| 7.01 | 4 | Block-wise-Transfer | [RFCthis] | | 7.01 | 4 | Block-Wise-Transfer | [RFCthis] |
| | | | | | | | | |
| 7.02, 7.03 | 2 | Custody | [RFCthis] | | 7.02, 7.03 | 2 | Custody | [RFCthis] |
| | | | | | | | | |
| 7.04 | 2 | Alternative-Address | [RFCthis] | | 7.04 | 2 | Alternative-Address | [RFCthis] |
| | | | | | | | | |
| 7.04 | 4 | Hold-Off | [RFCthis] | | 7.04 | 4 | Hold-Off | [RFCthis] |
| | | | | | | | | |
| 7.05 | 2 | Bad-CSM-Option | [RFCthis] | | 7.05 | 2 | Bad-CSM-Option | [RFCthis] |
+------------+--------+---------------------+-----------+ +------------+--------+---------------------+-----------+
skipping to change at page 41, line 45 skipping to change at page 42, line 35
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015, RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>. <https://www.rfc-editor.org/info/rfc7595>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
skipping to change at page 43, line 8 skipping to change at page 43, line 39
[I-D.gomez-lwig-tcp-constrained-node-networks] [I-D.gomez-lwig-tcp-constrained-node-networks]
Gomez, C., Crowcroft, J., and M. Scharf, "TCP over Gomez, C., Crowcroft, J., and M. Scharf, "TCP over
Constrained-Node Networks", draft-gomez-lwig-tcp- Constrained-Node Networks", draft-gomez-lwig-tcp-
constrained-node-networks-03 (work in progress), June constrained-node-networks-03 (work in progress), June
2017. 2017.
[I-D.ietf-core-cocoa] [I-D.ietf-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-ietf- "CoAP Simple Congestion Control/Advanced", draft-ietf-
core-cocoa-01 (work in progress), March 2017. core-cocoa-02 (work in progress), October 2017.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-06 (work in (OSCORE)", draft-ietf-core-object-security-07 (work in
progress), October 2017. progress), November 2017.
[IANA.uri-schemes] [IANA.uri-schemes]
IANA, "Uniform Resource Identifier (URI) Schemes", IANA, "Uniform Resource Identifier (URI) Schemes",
<http://www.iana.org/assignments/uri-schemes>. <http://www.iana.org/assignments/uri-schemes>.
[LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine [LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine
Technical Specification Version 1.0", February 2017, Technical Specification Version 1.0", February 2017,
<http://www.openmobilealliance.org/release/LightweightM2M/ <http://www.openmobilealliance.org/release/LightweightM2M/
V1_0-20170208-A/ V1_0-20170208-A/
OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>. OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>.
skipping to change at page 43, line 46 skipping to change at page 44, line 31
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[SecurityChallenges] [SecurityChallenges]
Polk, T. and S. Turner, "Security Challenges for the Polk, T. and S. Turner, "Security Challenges for the
Internet of Things", Interconnecting Smart Objects with Internet of Things", Interconnecting Smart Objects with
the Internet / IAB Workshop , February 2011, the Internet / IAB Workshop , February 2011,
<http://www.iab.org/wp-content/IAB-uploads/2011/03/ <http://www.iab.org/wp-content/IAB-uploads/2011/03/
Turner.pdf>. Turner.pdf>.
[SW2016] Swett, I., "QUIC Deployment Experience @Google", [SW2016] Swett, I., "QUIC Deployment Experience @Google",
Proceedings Proceedings
https://www.ietf.org/proceedings/96/slides/slides-96-quic- https://www.ietf.org/proceedings/96/slides/slides-96-quic-
skipping to change at page 44, line 28 skipping to change at page 45, line 23
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/
temperature?u=Cel>, for example, from a resource representation temperature?u=Cel>, for example, from a resource representation
that it retrieved previously. that it retrieved previously.
2. It establishes a WebSocket connection to the endpoint URI 2. It establishes a WebSocket connection to the endpoint URI
composed of the authority "example.org" and the well-known path composed of the authority "example.org" and the well-known path
"/.well-known/coap", <ws://example.org/.well-known/coap>. "/.well-known/coap", <ws://example.org/.well-known/coap>.
3. It sends a single-frame, masked, binary message containing a CoAP 3. CSM messages (Section 5.3) are exchanged (not shown for lack of
space).
4. It sends a single-frame, masked, binary message containing a CoAP
request. The request indicates the target resource with the Uri- request. The request indicates the target resource with the Uri-
Path ("sensors", "temperature") and Uri-Query ("u=Cel") options. Path ("sensors", "temperature") and Uri-Query ("u=Cel") options.
4. It waits for the server to return a response. 5. It waits for the server to return a response.
5. The CoAP client uses the connection for further requests, or the 6. The CoAP client uses the connection for further requests, or the
connection is closed. connection is closed.
CoAP CoAP CoAP CoAP
Client Server Client Server
(WebSocket (WebSocket (WebSocket (WebSocket
Client) Server) Client) Server)
| | | |
| | | |
+=========>| GET /.well-known/coap HTTP/1.1 +=========>| GET /.well-known/coap HTTP/1.1
skipping to change at page 45, line 25 skipping to change at page 46, line 25
| | Connection: Upgrade | | Connection: Upgrade
| | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== | | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
| | Sec-WebSocket-Protocol: coap | | Sec-WebSocket-Protocol: coap
| | Sec-WebSocket-Version: 13 | | Sec-WebSocket-Version: 13
| | | |
|<=========+ HTTP/1.1 101 Switching Protocols |<=========+ HTTP/1.1 101 Switching Protocols
| | Upgrade: websocket | | Upgrade: websocket
| | Connection: Upgrade | | Connection: Upgrade
| | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= | | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
| | Sec-WebSocket-Protocol: coap | | Sec-WebSocket-Protocol: coap
| | : :
:<-------->: Exchange of CSM messages (not shown)
| | | |
+--------->| Binary frame (opcode=%x2, FIN=1, MASK=1) +--------->| Binary frame (opcode=%x2, FIN=1, MASK=1)
| | +-------------------------+ | | +-------------------------+
| | | GET | | | | GET |
| | | Token: 0x53 | | | | Token: 0x53 |
| | | Uri-Path: "sensors" | | | | Uri-Path: "sensors" |
| | | Uri-Path: "temperature" | | | | Uri-Path: "temperature" |
| | | Uri-Query: "u=Cel" | | | | Uri-Query: "u=Cel" |
| | +-------------------------+ | | +-------------------------+
| | | |
|<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0) |<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0)
| | +-------------------------+ | | +-------------------------+
| | | 2.05 Content | | | | 2.05 Content |
| | | Token: 0x53 | | | | Token: 0x53 |
| | | Payload: "22.3 Cel" | | | | Payload: "22.3 Cel" |
| | +-------------------------+ | | +-------------------------+
: : : :
: : : :
| |
+--------->| Close frame (opcode=%x8, FIN=1, MASK=1) +--------->| Close frame (opcode=%x8, FIN=1, MASK=1)
| | | |
|<---------+ Close frame (opcode=%x8, FIN=1, MASK=0) |<---------+ Close frame (opcode=%x8, FIN=1, MASK=0)
| | | |
Figure 17: A CoAP client retrieves the representation of a resource Figure 17: A CoAP client retrieves the representation of a resource
identified by a "coap+ws" URI identified by a "coap+ws" URI
Figure 18 shows how a CoAP client uses a CoAP forward proxy with a Figure 18 shows how a CoAP client uses a CoAP forward proxy with a
WebSocket endpoint to retrieve the representation of the resource WebSocket endpoint to retrieve the representation of the resource
skipping to change at page 50, line 31 skipping to change at page 51, line 31
Bilhanan Silverajan Bilhanan Silverajan
Tampere University of Technology Tampere University of Technology
Korkeakoulunkatu 10 Korkeakoulunkatu 10
Tampere FI-33720 Tampere FI-33720
Finland Finland
Email: bilhanan.silverajan@tut.fi Email: bilhanan.silverajan@tut.fi
Brian Raymor (editor) Brian Raymor (editor)
Microsoft
One Microsoft Way
Redmond 98052
United States of America
Email: brian.raymor@microsoft.com Email: brianraymor@hotmail.com
 End of changes. 44 change blocks. 
128 lines changed or deleted 173 lines changed or added

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