< draft-ietf-core-coap-tcp-tls-07.txt		draft-ietf-core-coap-tcp-tls-08.txt >
	CORE C. Bormann		CORE C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Updates: 7641 (if approved) S. Lemay		Updates: 6455, 7641, 7959 (if approved) S. Lemay
	Intended status: Standards Track Zebra Technologies		Intended status: Standards Track Zebra Technologies
	Expires: September 7, 2017 H. Tschofenig		Expires: October 23, 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
	March 06, 2017		April 21, 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-07		draft-ietf-core-coap-tcp-tls-08
	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
	changes required to use CoAP over TCP, TLS, and WebSockets		changes required to use CoAP over TCP, TLS, and WebSockets
	transports. It also formally updates [RFC7641] for use with these		transports. It also formally updates RFC 7641 for use with these
	transports.		transports, RFC 7959 to enable the use of larger messages over a
			reliable transport, and RFC 6455 to extend the well-known URI
			mechanism (RFC 5785) to the ws and wss URI schemes.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 October 23, 2017.
	This Internet-Draft will expire on September 7, 2017.
	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
	(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 27 ¶		skipping to change at page 2, line 28 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
	3. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 6		3. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 6		3.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 7		3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Message Transmission . . . . . . . . . . . . . . . . . . 10		3.3. Message Transmission . . . . . . . . . . . . . . . . . . 11
	3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 11		3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 12
	4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 11		4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 12
	4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 13		4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 14
	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 . . . . . . . . . . . . . . . . . . . . 16
	5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	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) . . . . . . . . 17
	5.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 18		5.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 18
	5.5. Release Messages . . . . . . . . . . . . . . . . . . . . 19		5.5. Release Messages . . . . . . . . . . . . . . . . . . . . 19
	5.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 20		5.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 20
	5.7. Signaling examples . . . . . . . . . . . . . . . . . . . 21		5.7. Signaling examples . . . . . . . . . . . . . . . . . . . 21
	6. Block-wise Transfer and Reliable Transports . . . . . . . . . 22		6. Block-wise Transfer and Reliable Transports . . . . . . . . . 22
	6.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 23		6.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 23
	6.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 24		6.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 24
	7. CoAP over Reliable Transport URIs . . . . . . . . . . . . . . 24		7. CoAP over Reliable Transport URIs . . . . . . . . . . . . . . 24
	7.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 25		7.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 25
	7.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 25		7.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 26
	7.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 26		7.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 27
	7.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 27		7.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 27
	7.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 28		7.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 28
	7.6. Decomposing URIs into Options . . . . . . . . . . . . . . 28		7.6. Decomposing URIs into Options . . . . . . . . . . . . . . 29
	7.7. Composing URIs from Options . . . . . . . . . . . . . . . 29		7.7. Composing URIs from Options . . . . . . . . . . . . . . . 29
			8. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 30
	8. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 29
	8.1. TLS binding for CoAP over TCP . . . . . . . . . . . . . . 30		8.1. TLS binding for CoAP over TCP . . . . . . . . . . . . . . 30
	8.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 30		8.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 31
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 31		9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	9.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 31		9.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 31
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	10.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 31		10.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 32
	10.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 32		10.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 32
	10.3. Service Name and Port Number Registration . . . . . . . 33		10.3. Service Name and Port Number Registration . . . . . . . 33
	10.4. Secure Service Name and Port Number Registration . . . . 34		10.4. Secure Service Name and Port Number Registration . . . . 34
	10.5. URI Scheme Registration . . . . . . . . . . . . . . . . 34		10.5. URI Scheme Registration . . . . . . . . . . . . . . . . 34
	10.6. Well-Known URI Suffix Registration . . . . . . . . . . . 37		10.6. Well-Known URI Suffix Registration . . . . . . . . . . . 37
	10.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 37		10.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 37
	10.8. WebSocket Subprotocol Registration . . . . . . . . . . . 37		10.8. WebSocket Subprotocol Registration . . . . . . . . . . . 37
			10.9. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	11.1. Normative References . . . . . . . . . . . . . . . . . . 38		11.1. Normative References . . . . . . . . . . . . . . . . . . 38
	11.2. Informative References . . . . . . . . . . . . . . . . . 39		11.2. Informative References . . . . . . . . . . . . . . . . . 40
	Appendix A. Updates to RFC 7641 Observing Resources in the		Appendix A. Updates to RFC 7641 Observing Resources in the
	Constrained Application Protocol (CoAP) . . . . . . 40		Constrained Application Protocol (CoAP) . . . . . . 41
	A.1. Notifications and Reordering . . . . . . . . . . . . . . 40		A.1. Notifications and Reordering . . . . . . . . . . . . . . 41
	A.2. Transmission and Acknowledgements . . . . . . . . . . . . 41		A.2. Transmission and Acknowledgements . . . . . . . . . . . . 41
	A.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 41		A.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 41
	A.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 41		A.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 42
	Appendix B. CoAP over WebSocket Examples . . . . . . . . . . . . 42		Appendix B. CoAP over WebSocket Examples . . . . . . . . . . . . 42
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 45		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 46
	C.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 45		C.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 46
	C.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 45		C.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 46
	C.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 45		C.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 46
	C.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 45		C.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 46
	C.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 46		C.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 47
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46		C.6. Since draft-ietf-core-coap-tcp-tls-07 . . . . . . . . . . 47
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 46		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
	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 Datagram Transport Layer Security (DTLS) [RFC6347] over UDP can be
	choice for transferring small amounts of data across networks that		used unimpeded. UDP is a good choice for transferring small amounts
	follow the IP architecture.		of data across networks that follow the IP architecture.
	Some CoAP deployments need to integrate well with existing enterprise		Some CoAP deployments need to integrate well with existing enterprise
	infrastructures, where UDP-based protocols may not be well-received		infrastructures, where UDP-based protocols may not be well-received
	or may even be blocked by firewalls. Middleboxes that are unaware of		or may even be blocked by firewalls. Middleboxes that are unaware of
	CoAP usage for IoT can make the use of UDP brittle, resulting in lost		CoAP usage for IoT can make the use of UDP brittle, resulting in lost
	or malformed packets.		or malformed packets.
	Emerging standards such as Lightweight Machine to Machine [LWM2M]		Emerging standards such as Lightweight Machine to Machine [LWM2M]
	currently use CoAP over UDP as a transport and require support for		currently use CoAP over UDP as a transport and require support for
	CoAP over TCP to address the issues above and to protect investments		CoAP over TCP to address the issues above and to protect investments
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 12 ¶
	CoAP may be integrated into a Web environment where the front-end		CoAP may be integrated into a Web environment where the front-end
	uses CoAP over UDP from IoT devices to a cloud infrastructure and		uses CoAP over UDP from IoT devices to a cloud infrastructure and
	then CoAP over TCP between the back-end services. A TCP-to-UDP		then CoAP over TCP between the back-end services. A TCP-to-UDP
	gateway can be used at the cloud boundary to communicate with the		gateway can be used at the cloud boundary to communicate with the
	UDP-based IoT device.		UDP-based IoT device.
	To allow IoT devices to better communicate in these demanding		To allow IoT devices to better communicate in these demanding
	environments, CoAP needs to support different transport protocols,		environments, CoAP needs to support different transport protocols,
	namely TCP [RFC0793], in some situations secured by TLS [RFC5246].		namely TCP [RFC0793], in some situations secured by TLS [RFC5246].
	In addition, some corporate networks only allow Internet access via a		CoAP applications running inside a web browser without access to
	HTTP proxy. In this case, the best transport for CoAP might be the		connectivity other than HTTP and the WebSocket protocol [RFC6455] may
	WebSocket protocol [RFC6455]. The WebSocket protocol provides two-		cross-proxy their CoAP requests via HTTP to a HTTP-to-CoAP cross-
	way communication between a WebSocket client and a WebSocket server		proxy or transport them via the the WebSocket protocol, which
	after upgrading an HTTP/1.1 [RFC7230] connection and may be available		provides two-way communication between a WebSocket client and a
	in an environment that blocks CoAP over UDP. Another scenario for		WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.
	CoAP over WebSockets is a CoAP application running inside a web
	browser without access to connectivity other than HTTP and
	WebSockets.
	This document specifies how to access resources using CoAP requests		This document specifies how to access resources using CoAP requests
	and responses over the TCP, TLS and WebSocket protocols. This allows		and responses over the TCP, TLS and WebSocket protocols. This allows
	connectivity-limited applications to obtain end-to-end CoAP		connectivity-limited applications to obtain end-to-end CoAP
	connectivity either by communicating CoAP directly with a CoAP server		connectivity either by communicating CoAP directly with a CoAP server
	accessible over a TCP, TLS or WebSocket connection or via a CoAP		accessible over a TCP, TLS or WebSocket connection or via a CoAP
	intermediary that proxies CoAP requests and responses between		intermediary that proxies CoAP requests and responses between
	different transports, such as between WebSockets and UDP.		different transports, such as between WebSockets and UDP.
	Appendix A updates the "Observing Resources in the Constrained		Appendix A updates the "Observing Resources in the Constrained
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 50 ¶
	[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], [RFC7252], [RFC7641], and		concepts that are used in [RFC6455], [RFC7252], [RFC7641], and
	[RFC7959].		[RFC7959].
	The term "reliable transport" is used only to refer to transport		The term "reliable transport" is used only to refer to transport
	protocols, such as TCP, which provide reliable and ordered delivery		protocols, such as TCP, which provide reliable and ordered delivery
	of a byte-stream.		of a byte-stream.
			Block-wise Extension for Reliable Transport (BERT):
			BERT extends [RFC7959] to enable the use of larger messages over a
			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]).
	Connection Initiator:		Connection Initiator:
	The peer that opens a reliable byte stream connection, i.e., the		The peer that opens a reliable byte stream connection, i.e., the
	TCP active opener, TLS client, or WebSocket client.		TCP active opener, TLS client, or WebSocket client.
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 41 ¶
	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		TCP/TLS connection. A CoAP client can send multiple requests without
	waiting for a response and the CoAP server can return responses in		waiting for a response and the CoAP server can return responses in
	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 (Connection Initiator) and the		entity that established the connection (Connection Initiator) and the
	remote host (Connection Acceptor). If one side does not implement a		remote host (Connection Acceptor). If one side does not implement a
	CoAP server, an appropriate error response such as 4.04 (Not Found)		CoAP server, an error response MUST be returned for all CoAP requests
	or 5.01 (Not Implemented) MUST be returned for all CoAP requests from		from the other side. The simplest approach is to always return 5.01
	the other side.		(Not Implemented). A more elaborate mock server could also return
			4.xx responses such as 4.04 (Not Found) or 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.		connection and verify that the CoAP server is responsive.
			When the underlying TCP connection is closed or reset, the signaling
			state and any observation state (see Appendix A.4) associated with
			the reliable connection are removed. In flight messages may 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
	endpoint (see Figure 9). The CoAP client acts as the WebSocket		endpoint (see Figure 9). The CoAP client acts as the WebSocket
	skipping to change at page 24, line 49 ¶		skipping to change at page 25, line 4 ¶
	Figure 17: PUT with BERT blocks		Figure 17: PUT with BERT blocks
	7. CoAP over Reliable Transport URIs		7. CoAP over Reliable Transport URIs
	CoAP over UDP [RFC7252] defines the "coap" and "coaps" URI schemes.		CoAP over UDP [RFC7252] defines the "coap" and "coaps" URI schemes.
	This document introduces four additional URI schemes for identifying		This document introduces four additional URI schemes for identifying
	CoAP resources and providing a means of locating the resource:		CoAP resources and providing a means of locating the resource:
	o the "coap+tcp" URI scheme for CoAP over TCP		o the "coap+tcp" URI scheme for CoAP over TCP
	o the "coaps+tcp" URI scheme for CoAP over TCP secured by TLS		o the "coaps+tcp" URI scheme for CoAP over TCP secured by TLS
	o the "coap+ws" URI scheme for CoAP over WebSockets		o the "coap+ws" URI scheme for CoAP over WebSockets
	o the "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS		o the "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS
	Resources made available via these schemes have no shared identity		Resources made available via these schemes have no shared identity
	even if their resource identifiers indicate the same authority (the		even if their resource identifiers indicate the same authority (the
	same host listening to the same TCP port). They are hosted in		same host listening to the same TCP port). They are hosted in
	distinct namespaces because each URI scheme implies a distinct origin		distinct namespaces because each URI scheme implies a distinct origin
	server.		server.
	The syntax for the URI schemes in this section are specified using		The syntax for the URI schemes in this section are specified using
	Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of		Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of
	"host", "port", "path-abempty", and "query" are adopted from		"host", "port", "path-abempty", "query", and "fragment" are adopted
	[RFC3986].		from [RFC3986].
	Section 8 (Multicast CoAP) in [RFC7252] is not applicable to these		Section 8 (Multicast CoAP) in [RFC7252] is not applicable to these
	schemes.		schemes.
			As with the "coap" and "coaps" schemes defined in [RFC7252], all URI
			schemes defined in this section also support the path prefix "/.well-
			known/" defined by [RFC5785] for "well-known locations" in the
			namespace of a host. This enables discovery as per Section 7 of
			[RFC7252].
	7.1. coap+tcp URI scheme		7.1. coap+tcp URI scheme
	The "coap+tcp" URI scheme identifies CoAP resources that are intended		The "coap+tcp" URI scheme identifies CoAP resources that are intended
	to be accessible using CoAP over TCP.		to be accessible using CoAP over TCP.
	coap+tcp-URI =		coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ]
	"coap+tcp:" "//" host [ ":" port ] path-abempty [ "?" query ]		path-abempty [ "?" query ] [ "#" fragment ]
	The syntax defined in Section 6.1 of [RFC7252] applies to this URI		The syntax defined in Section 6.1 of [RFC7252] applies to this URI
	scheme with the following changes:		scheme with the following changes:
	o The port subcomponent indicates the TCP port at which the CoAP		o The port subcomponent indicates the TCP port at which the CoAP
	server is located. (If it is empty or not given, then the default		server is located. (If it is empty or not given, then the default
	port 5683 is assumed, as with UDP.)		port 5683 is assumed, as with UDP.)
	Encoding considerations: The scheme encoding conforms to the		Encoding considerations: The scheme encoding conforms to the
	encoding rules established for URIs in [RFC3986].		encoding rules established for URIs in [RFC3986].
	Interoperability considerations: None.		Interoperability considerations: None.
	Security considerations: See Section 11.1 of [RFC7252].		Security considerations: See Section 11.1 of [RFC7252].
	7.2. coaps+tcp URI scheme		7.2. coaps+tcp URI scheme
	The "coaps+tcp" URI scheme identifies CoAP resources that are		The "coaps+tcp" URI scheme identifies CoAP resources that are
	intended to be accessible using CoAP over TCP secured with TLS.		intended to be accessible using CoAP over TCP secured with TLS.
	coaps+tcp-URI =		coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ]
	"coaps+tcp:" "//" host [ ":" port ] path-abempty [ "?" query ]		path-abempty [ "?" query ] [ "#" fragment ]
	The syntax defined in Section 6.2 of [RFC7252] applies to this URI		The syntax defined in Section 6.2 of [RFC7252] applies to this URI
	scheme, with the following changes:		scheme, with the following changes:
	o The port subcomponent indicates the TCP port at which the TLS		o The port subcomponent indicates the TCP port at which the TLS
	server for the CoAP server is located. If it is empty or not		server for the CoAP server is located. If it is empty or not
	given, then the default port 443 is assumed (this is different		given, then the default port 443 is assumed (this is different
	from the default port for "coaps", i.e., CoAP over DTLS over UDP).		from the default port for "coaps", i.e., CoAP over DTLS over UDP).
	o If a TLS server does not support the Application-Layer Protocol		o If a TLS server does not support the Application-Layer Protocol
	skipping to change at page 26, line 51 ¶		skipping to change at page 27, line 14 ¶
	Interoperability considerations: None.		Interoperability considerations: None.
	Security considerations: See Section 11.1 of [RFC7252].		Security considerations: See Section 11.1 of [RFC7252].
	7.3. coap+ws URI scheme		7.3. coap+ws URI scheme
	The "coap+ws" URI scheme identifies CoAP resources that are intended		The "coap+ws" URI scheme identifies CoAP resources that are intended
	to be accessible using CoAP over WebSockets.		to be accessible using CoAP over WebSockets.
	coap-ws-URI =		coap-ws-URI = "coap+ws:" "//" host [ ":" port ]
	"coap+ws:" "//" host [ ":" port ] path-abempty [ "?" query ]		path-abempty [ "?" query ] [ "#" fragment ]
	The port subcomponent is OPTIONAL. The default is port 80.		The port subcomponent is OPTIONAL. The default is port 80.
	The WebSocket endpoint is identified by a "ws" URI that is composed		The WebSocket endpoint is identified by a "ws" URI that is composed
	of the authority part of the "coap+ws" URI and the well-known path		of the authority part of the "coap+ws" URI and the well-known path
	"/.well-known/coap" [RFC5785]. The path and query parts of a		"/.well-known/coap" [RFC5785]. The present specification formally
	"coap+ws" URI identify a resource within the specified endpoint which		updates [RFC6455], extending the well-known URI mechanism defined in
	can be operated on by the methods defined by CoAP:		[RFC5785] to also cover the "ws" URI scheme defined in that document.
			The path and query parts of a "coap+ws" URI identify a resource
			within the specified endpoint which can be operated on by the methods
			defined by CoAP:
	coap+ws://example.org/sensors/temperature?u=Cel		coap+ws://example.org/sensors/temperature?u=Cel
	\______ ______/\___________ ___________/		\______ ______/\___________ ___________/
	\/ \/		\/ \/
	Uri-Path: "sensors"		Uri-Path: "sensors"
	ws://example.org/.well-known/coap Uri-Path: "temperature"		ws://example.org/.well-known/coap Uri-Path: "temperature"
	Uri-Query: "u=Cel"		Uri-Query: "u=Cel"
	Figure 18: The "coap+ws" URI Scheme		Figure 18: The "coap+ws" URI Scheme
	skipping to change at page 27, line 34 ¶		skipping to change at page 27, line 49 ¶
	Interoperability considerations: None.		Interoperability considerations: None.
	Security considerations: See Section 11.1 of [RFC7252].		Security considerations: See Section 11.1 of [RFC7252].
	7.4. coaps+ws URI scheme		7.4. coaps+ws URI scheme
	The "coaps+ws" URI scheme identifies CoAP resources that are intended		The "coaps+ws" URI scheme identifies CoAP resources that are intended
	to be accessible using CoAP over WebSockets secured by TLS.		to be accessible using CoAP over WebSockets secured by TLS.
	coaps-ws-URI =		coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ]
	"coaps+ws:" "//" host [ ":" port ] path-abempty [ "?" query ]		path-abempty [ "?" query ] [ "#" fragment ]
	The port subcomponent is OPTIONAL. The default is port 443.		The port subcomponent is OPTIONAL. The default is port 443.
	The WebSocket endpoint is identified by a "wss" URI that is composed		The WebSocket endpoint is identified by a "wss" URI that is composed
	of the authority part of the "coaps+ws" URI and the well-known path		of the authority part of the "coaps+ws" URI and the well-known path
	"/.well-known/coap" [RFC5785]. The path and query parts of a		"/.well-known/coap" [RFC5785]. The present specification formally
	"coaps+ws" URI identify a resource within the specified endpoint		updates [RFC6455], extending the well-known URI mechanism defined in
	which can be operated on by the methods defined by CoAP.		[RFC5785] to also cover the "wss" URI scheme defined in that
			document. The path and query parts of a "coaps+ws" URI identify a
			resource within the specified endpoint which can be operated on by
			the methods defined by CoAP.
	coaps+ws://example.org/sensors/temperature?u=Cel		coaps+ws://example.org/sensors/temperature?u=Cel
	\______ ______/\___________ ___________/		\______ ______/\___________ ___________/
	\/ \/		\/ \/
	Uri-Path: "sensors"		Uri-Path: "sensors"
	wss://example.org/.well-known/coap Uri-Path: "temperature"		wss://example.org/.well-known/coap Uri-Path: "temperature"
	Uri-Query: "u=Cel"		Uri-Query: "u=Cel"
	Figure 19: The "coaps+ws" URI Scheme		Figure 19: The "coaps+ws" URI Scheme
	skipping to change at page 30, line 35 ¶		skipping to change at page 31, line 8 ¶
	PreSharedKey: TLS is enabled. The guidance in Section 4.2 of		PreSharedKey: TLS is enabled. The guidance in Section 4.2 of
	[RFC7925] applies.		[RFC7925] applies.
	RawPublicKey: TLS is enabled. The guidance in Section 4.3 of		RawPublicKey: TLS is enabled. The guidance in Section 4.3 of
	[RFC7925] applies.		[RFC7925] applies.
	Certificate: TLS is enabled. The guidance in Section 4.4 of		Certificate: TLS is enabled. The guidance in Section 4.4 of
	[RFC7925] applies.		[RFC7925] applies.
	The "NoSec" mode is mandatory-to-implement. The system simply sends		The "NoSec" mode is optional-to-implement. The system simply sends
	the packets over normal TCP which is indicated by the "coap+tcp"		the packets over normal TCP which is indicated by the "coap+tcp"
	scheme and the TCP CoAP default port. The system is secured only by		scheme and the TCP CoAP default port. The system is secured only by
	keeping attackers from being able to send or receive packets from the		keeping attackers from being able to send or receive packets from the
	network with the CoAP nodes.		network with the CoAP nodes.
	"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-		"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-
	implement for the TLS binding depending on the credential type used		implement for the TLS binding depending on the credential type used
	with the device. These security modes are achieved using TLS and are		with the device. These security modes are achieved using TLS and are
	indicated by the "coaps+tcp" scheme and TLS-secured CoAP default		indicated by the "coaps+tcp" scheme and TLS-secured CoAP default
	port.		port.
	skipping to change at page 38, line 7 ¶		skipping to change at page 38, line 7 ¶
	Subprotocol Identifier.		Subprotocol Identifier.
	coap		coap
	Subprotocol Common Name.		Subprotocol Common Name.
	Constrained Application Protocol (CoAP)		Constrained Application Protocol (CoAP)
	Subprotocol Definition.		Subprotocol Definition.
	[RFCthis]		[RFCthis]
			10.9. CoAP Option Numbers Registry
			IANA is requested to add [RFCthis] to the references for the
			following entries registered by [RFC7959] in the "CoAP Option
			Numbers" sub-registry defined by [RFC7252]:
			+--------+--------+---------------------+
			| Number | Name | Reference |
			+--------+--------+---------------------+
			| 23 | Block2 | RFC 7959, [RFCthis] |
			| | | |
			| 27 | Block1 | RFC 7959, [RFCthis] |
			+--------+--------+---------------------+
			Table 3: CoAP Option Numbers
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<http://www.rfc-editor.org/info/rfc793>.		<http://www.rfc-editor.org/info/rfc793>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 39, line 26 ¶		skipping to change at page 39, line 45 ¶
	Application Protocol (CoAP)", RFC 7641,		Application Protocol (CoAP)", RFC 7641,
	DOI 10.17487/RFC7641, September 2015,		DOI 10.17487/RFC7641, September 2015,
	<http://www.rfc-editor.org/info/rfc7641>.		<http://www.rfc-editor.org/info/rfc7641>.
	[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer		[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
	Security (TLS) / Datagram Transport Layer Security (DTLS)		Security (TLS) / Datagram Transport Layer Security (DTLS)
	Profiles for the Internet of Things", RFC 7925,		Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,		DOI 10.17487/RFC7925, July 2016,
	<http://www.rfc-editor.org/info/rfc7925>.		<http://www.rfc-editor.org/info/rfc7925>.
			[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>.
	11.2. Informative References		11.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.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-00 (work in progress), October 2016.		core-cocoa-01 (work in progress), March 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 of CoAP (OSCOAP)", draft-ietf-core-		"Object Security of CoAP (OSCOAP)", draft-ietf-core-
	object-security-01 (work in progress), December 2016.		object-security-02 (work in progress), March 2017.
	[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>.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980,
	<http://www.rfc-editor.org/info/rfc768>.		<http://www.rfc-editor.org/info/rfc768>.
	skipping to change at page 40, line 26 ¶		skipping to change at page 41, line 5 ¶
	[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, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <http://www.rfc-editor.org/info/rfc6347>.
	[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",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
	[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>.
	[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>.
	Appendix A. Updates to RFC 7641 Observing Resources in the Constrained		Appendix A. Updates to RFC 7641 Observing Resources in the Constrained
	Application Protocol (CoAP)		Application Protocol (CoAP)
	skipping to change at page 46, line 10 ¶		skipping to change at page 47, line 10 ¶
	Updated Pong response requirements		Updated Pong response requirements
	Added Connection Initiator and Connection Acceptor terminology where		Added Connection Initiator and Connection Acceptor terminology where
	appropriate		appropriate
	Updated LWM2M 1.0 informative reference		Updated LWM2M 1.0 informative reference
	C.5. Since draft-ietf-core-coap-tcp-tls-06		C.5. Since draft-ietf-core-coap-tcp-tls-06
	Addressed feedback from second Working Group Last Call		Addressed feedback from second Working Group Last Call
			C.6. Since draft-ietf-core-coap-tcp-tls-07
			Addressed feedback from IETF Last Call
			Addressed feedback from ARTART review
			Addressed feedback from GENART review
			Addressed feedback from TSVART review
			Added fragment identifiers to URI schemes
			Added "Updates RFC7959" for BERT
			Added "Updates RFC6455" to extend well-known URI mechanism to ws and
			wss
			Clarified well-known URI mechanism use for all URI schemes
			Changed NoSec to optional-to-implement
	Acknowledgements		Acknowledgements
	We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier		We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier
	Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster,		Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster,
	Matthias Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Goran		Matthias Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Goran
	Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu		Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu
	Wei for their feedback.		Wei for their feedback.
	Contributors		Contributors
	Matthias Kovatsch		Matthias Kovatsch
	Siemens AG		Siemens AG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich D-81739		Munich D-81739
	Phone: +49-173-5288856		Phone: +49-173-5288856
	EMail: matthias.kovatsch@siemens.com		EMail: matthias.kovatsch@siemens.com
	Teemu Savolainen		Teemu Savolainen
	Nokia Technologies		Nokia Technologies
End of changes. 42 change blocks.
	76 lines changed or deleted		135 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/