< draft-ietf-core-coap-tcp-tls-08.txt		draft-ietf-core-coap-tcp-tls-09.txt >
	CORE C. Bormann		CORE C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Updates: 6455, 7641, 7959 (if approved) S. Lemay		Updates: 7252, 7641, 7959 (if approved) S. Lemay
	Intended status: Standards Track Zebra Technologies		Intended status: Standards Track Zebra Technologies
	Expires: October 23, 2017 H. Tschofenig		Expires: November 17, 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
	April 21, 2017		May 16, 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-08		draft-ietf-core-coap-tcp-tls-09
	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 RFC 7641 for use with these		transports. It also formally updates RFC 7252 fixing an erratum in
	transports, RFC 7959 to enable the use of larger messages over a		the URI syntax, RFC 7641 for use with the new transports, and RFC
	reliable transport, and RFC 6455 to extend the well-known URI		7959 to enable the use of larger messages over a reliable transport.
	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 November 17, 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 26 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 7		3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Message Transmission . . . . . . . . . . . . . . . . . . 11		3.3. Message Transmission . . . . . . . . . . . . . . . . . . 11
	3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 12		3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 12
	4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 12		4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 12
	4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 14		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 . . . . . . . . . . . . . . . . . . . . 16		4.4. Connection Health . . . . . . . . . . . . . . . . . . . . 16
	5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 16		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) . . . . . . . . 17		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. Use of the "coap" URI scheme with TCP . . . . . . . . . . 25
	7.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 26		7.2. Use of the "coaps" URI scheme with TLS over TCP . . . . . 25
	7.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 27		7.3. Use of the "coap" URI scheme with WebSockets . . . . . . 26
	7.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 27		7.4. Use of the "coaps" URI scheme with WebSockets . . . . . . 27
	7.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 28		7.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 27
	7.6. Decomposing URIs into Options . . . . . . . . . . . . . . 29		7.6. Decomposing URIs into Options . . . . . . . . . . . . . . 28
	7.7. Composing URIs from Options . . . . . . . . . . . . . . . 29		7.7. Composing URIs from Options . . . . . . . . . . . . . . . 28
	8. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 30		7.8. Trying out multiple transports at once . . . . . . . . . 29
			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 . . . . . . . . . . . 31		8.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 30
	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 . . . . . . . . . . . . . . . . . . . . 32		10.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 31
	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. Well-Known URI Suffix Registration . . . . . . . . . . . 34
	10.6. Well-Known URI Suffix Registration . . . . . . . . . . . 37		10.6. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 35
	10.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 37		10.7. WebSocket Subprotocol Registration . . . . . . . . . . . 35
	10.8. WebSocket Subprotocol Registration . . . . . . . . . . . 37		10.8. CoAP Option Numbers Registry . . . . . . . . . . . . . . 35
	10.9. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		11.1. Normative References . . . . . . . . . . . . . . . . . . 36
	11.1. Normative References . . . . . . . . . . . . . . . . . . 38		11.2. Informative References . . . . . . . . . . . . . . . . . 37
	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) . . . . . . 41		Constrained Application Protocol (CoAP) . . . . . . 39
	A.1. Notifications and Reordering . . . . . . . . . . . . . . 41		A.1. Notifications and Reordering . . . . . . . . . . . . . . 39
	A.2. Transmission and Acknowledgements . . . . . . . . . . . . 41		A.2. Transmission and Acknowledgements . . . . . . . . . . . . 39
	A.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 41		A.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 40
	A.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 42		A.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 40
	Appendix B. CoAP over WebSocket Examples . . . . . . . . . . . . 42		Appendix B. CoAP over WebSocket Examples . . . . . . . . . . . . 40
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 46		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 44
	C.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 46		C.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 44
	C.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 46		C.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 44
	C.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 46		C.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 44
	C.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 46		C.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 44
	C.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 47		C.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 45
	C.6. Since draft-ietf-core-coap-tcp-tls-07 . . . . . . . . . . 47		C.6. Since draft-ietf-core-coap-tcp-tls-07 . . . . . . . . . . 45
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47		C.7. Since draft-ietf-core-coap-tcp-tls-08 . . . . . . . . . . 45
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 46
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
	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 Datagram Transport Layer Security (DTLS) [RFC6347] over UDP can be		or Datagram Transport Layer Security (DTLS) [RFC6347] over UDP can be
	used unimpeded. UDP is a good choice for transferring small amounts		used unimpeded. UDP is a good choice for transferring small amounts
	of data across networks that 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
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 17 ¶
	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
	in existing CoAP implementations and deployments. Although HTTP/2		in existing CoAP implementations and deployments. Although HTTP/2
	could also potentially address these requirements, there would be		could also potentially address these requirements, there would be
	additional costs and delays introduced by such a transition.		additional costs and delays introduced by such a transition.
	Currently, there are also fewer HTTP/2 implementations available for		Currently, there are also fewer HTTP/2 implementations available for
	constrained devices in comparison to CoAP.		constrained devices in comparison to CoAP.
	To address these requirements, this document defines how to transport		To address these requirements, this document defines how to transport
	CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. Figure 1		CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. For these
			cases, the reliability offered by the transport protocol subsumes the
			reliability functions of the message layer used for CoAP over UDP.
			(Note that both for a reliable transport and the CoAP over UDP
			message layer, the reliability offered is per transport hop: where
			proxies -- see Sections 5.7 and 10 of [RFC7252] -- are involved, that
			layer's reliability function does not extend end-to-end.) Figure 1
	illustrates the layering:		illustrates the layering:
	+--------------------------------+		+--------------------------------+
	| Application |		| Application |
	+--------------------------------+		+--------------------------------+
	+--------------------------------+		+--------------------------------+
	| Requests/Responses/Signaling | CoAP (RFC 7252) / This Document		| Requests/Responses/Signaling | CoAP (RFC 7252) / This Document
	|--------------------------------|		|--------------------------------|
	| Message Framing | This Document		| Message Framing | This Document
	+--------------------------------+		+--------------------------------+
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 41 ¶
	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
	Application Protocol" [RFC7641] specification for use with CoAP over		Application Protocol" [RFC7641] specification for use with CoAP over
	reliable transports. [RFC7641] is an extension to the CoAP protocol		reliable transports. [RFC7641] is an extension to the CoAP protocol
	that enables CoAP clients to "observe" a resource on a CoAP server.		that enables CoAP clients to "observe" a resource on a CoAP server.
	(The CoAP client retrieves a representation of a resource and		(The CoAP client retrieves a representation of a resource and
	registers to be notified by the CoAP server when the representation		registers to be notified by the CoAP server when the representation
	is updated.)		is updated.)
			Section 7 fixes an erratum on the URI scheme syntax in [RFC7252].
			Section 6 defines semantics for a value 7 for the field "SZX" in a
			Block1 or Block2 option, updating [RFC7959].
	2. Conventions and Terminology		2. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	This document assumes that readers are familiar with the terms and		This document assumes that readers are familiar with the terms and
	concepts that are used in [RFC6455], [RFC7252], [RFC7641], and		concepts that are used in [RFC6455], [RFC7252], [RFC7641], and
	[RFC7959].		[RFC7959].
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 4 ¶
	WebSocket =============> WebSocket		WebSocket =============> WebSocket
	Client Connection Server		Client Connection Server
	Figure 9: CoAP Client (WebSocket client) accesses CoAP Server		Figure 9: CoAP Client (WebSocket client) accesses CoAP Server
	(WebSocket server)		(WebSocket server)
	The challenge with this configuration is how to identify a resource		The challenge with this configuration is how to identify a resource
	in the namespace of the CoAP server. When the WebSocket protocol is		in the namespace of the CoAP server. When the WebSocket protocol is
	used by a dedicated client directly (i.e., not from a web page		used by a dedicated client directly (i.e., not from a web page
	through a web browser), the client can connect to any WebSocket		through a web browser), the client can connect to any WebSocket
	endpoint. Section 7.3 and Section 7.4 define new URI schemes that		endpoint. Section 7.3 and Section 7.4 define how the "coap" and
	enable the client to identify both a WebSocket endpoint and the path		"coaps" URI schemes can be used to enable the client to identify both
	and query of the CoAP resource within that endpoint.		a WebSocket endpoint and the path and query of the CoAP resource
			within that endpoint.
	Another possible configuration is to set up a CoAP forward proxy at		Another possible configuration is to set up a CoAP forward proxy at
	the WebSocket endpoint. Depending on what transports are available		the WebSocket endpoint. Depending on what transports are available
	to the proxy, it could forward the request to a CoAP server with a		to the proxy, it could forward the request to a CoAP server with a
	CoAP UDP endpoint (Figure 10), an SMS endpoint (a.k.a. mobile phone),		CoAP UDP endpoint (Figure 10), an SMS endpoint (a.k.a. mobile phone),
	or even another WebSocket endpoint. The CoAP client specifies the		or even another WebSocket endpoint. The CoAP client specifies the
	resource to be updated or retrieved in the Proxy-Uri Option.		resource to be updated or retrieved in the Proxy-Uri Option.
	___________ ___________ ___________		___________ ___________ ___________
	| | | | | |		| | | | | |
	skipping to change at page 24, line 47 ¶		skipping to change at page 24, line 47 ¶
	| PUT, /options, 1:24/0/BERT(5683) ------> |		| PUT, /options, 1:24/0/BERT(5683) ------> |
	| |		| |
	| <------ 2.04 Changed, 1:24/0/BERT |		| <------ 2.04 Changed, 1:24/0/BERT |
	| |		| |
	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 corrects an erratum in Sections 6.1 and 6.2 of
	CoAP resources and providing a means of locating the resource:		[RFC7252] and defines how to use the schemes with the new transports.
			Section 8 (Multicast CoAP) in [RFC7252] is not applicable to these
	o the "coap+tcp" URI scheme for CoAP over TCP		new transports.
	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 "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS
	Resources made available via these schemes have no shared identity
	even if their resource identifiers indicate the same authority (the
	same host listening to the same TCP port). They are hosted in
	distinct namespaces because each URI scheme implies a distinct origin
	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", "query", and "fragment" are adopted		"host", "port", "path-abempty", "query", and "fragment" are adopted
	from [RFC3986].		from [RFC3986].
	Section 8 (Multicast CoAP) in [RFC7252] is not applicable to these		The ABNF syntax defined in Sections 6.1 and 6.2 of [RFC7252] for
	schemes.		"coap" and "coaps" schemes lacks the fragment identifer. This
			specification updates the two rules in those sections as follows:
	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		coap-URI = "coap:" "//" host [ ":" port ]
			path-abempty [ "?" query ] [ "#" fragment ]
			coaps-URI = "coaps:" "//" host [ ":" port ]
			path-abempty [ "?" query ] [ "#" fragment ]
	The "coap+tcp" URI scheme identifies CoAP resources that are intended		7.1. Use of the "coap" URI scheme with TCP
	to be accessible using CoAP over TCP.
	coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ]		The "coap" URI scheme defined in Section 6.1 of [RFC7252] can also be
	path-abempty [ "?" query ] [ "#" fragment ]		used to identify CoAP resources that are intended to be accessible
			using CoAP over TCP.
	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
	scheme with the following changes:		transport, with the following change:
	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		7.2. Use of the "coaps" URI scheme with TLS over TCP
	encoding rules established for URIs in [RFC3986].
	Interoperability considerations: None.
	Security considerations: See Section 11.1 of [RFC7252].
	7.2. coaps+tcp URI scheme
	The "coaps+tcp" URI scheme identifies CoAP resources that are
	intended to be accessible using CoAP over TCP secured with TLS.
	coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ]		The "coaps" URI scheme defined in Section 6.2 of [RFC7252] can also
	path-abempty [ "?" query ] [ "#" fragment ]		be used to identify CoAP resources that are intended to be accessible
			using CoAP over TCP secured with TLS.
	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
	scheme, with the following changes:		transport, 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 Connection Acceptor is located. If it is
	given, then the default port 443 is assumed (this is different		empty or not given, then the default port 5684 is assumed.
	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
	Negotiation Extension (ALPN) [RFC7301] or wishes to accommodate		Negotiation Extension (ALPN) [RFC7301] or wishes to accommodate
	TLS clients that do not support ALPN, it MAY offer a coaps+tcp		TLS clients that do not support ALPN, it MAY offer a coaps
	endpoint on TCP port 5684. This endpoint MAY also be ALPN		endpoint on the default TCP port 5684. This endpoint MAY also be
	enabled. A TLS server MAY offer coaps+tcp endpoints on ports		ALPN enabled. A TLS server MAY offer coaps endpoints on TCP ports
	other than TCP port 5684, which MUST be ALPN enabled.		other than 5684; these then MUST be ALPN enabled.
	o For TCP ports other than port 5684, the TLS client MUST use the		o For TCP ports other than port 5684, the TLS client MUST use the
	ALPN extension to advertise the "coap" protocol identifier (see		ALPN extension to advertise the "coap" protocol identifier (see
	Section 10.7) in the list of protocols in its ClientHello. If the		Section 10.6) in the list of protocols in its ClientHello. If the
	TCP server selects and returns the "coap" protocol identifier		TCP server selects and returns the "coap" protocol identifier
	using the ALPN extension in its ServerHello, then the connection		using the ALPN extension in its ServerHello, then the connection
	succeeds. If the TLS server either does not negotiate the ALPN		succeeds. If the TLS server either does not negotiate the ALPN
	extension or returns a no_application_protocol alert, the TLS		extension or returns a no_application_protocol alert, the TLS
	client MUST close the connection.		client MUST close the connection.
	o For TCP port 5684, a TLS client MAY use the ALPN extension to		o For TCP port 5684, a TLS client MAY use the ALPN extension to
	advertise the "coap" protocol identifier in the list of protocols		advertise the "coap" protocol identifier in the list of protocols
	in its ClientHello. If the TLS server selects and returns the		in its ClientHello. If the TLS server selects and returns the
	"coap" protocol identifier using the ALPN extension in its		"coap" protocol identifier using the ALPN extension in its
	ServerHello, then the connection succeeds. If the TLS server		ServerHello, then the connection succeeds. If the TLS server
	returns a no_application_protocol alert, then the TLS client MUST		returns a no_application_protocol alert, then the TLS client MUST
	close the connection. If the TLS server does not negotiate the		close the connection. If the TLS server does not negotiate the
	ALPN extension, then coaps+tcp is implicitly selected.		ALPN extension, then coaps over TCP is implicitly selected.
	o For TCP port 5684, if the TLS client does not use the ALPN		o For TCP port 5684, if the TLS client does not use the ALPN
	extension to negotiate the protocol, then coaps+tcp is implicitly		extension to negotiate the protocol, then coaps over TCP is
	selected.		implicitly selected.
	Encoding considerations: The scheme encoding conforms to the
	encoding rules established for URIs in [RFC3986].
	Interoperability considerations: None.
	Security considerations: See Section 11.1 of [RFC7252].
	7.3. coap+ws URI scheme
	The "coap+ws" URI scheme identifies CoAP resources that are intended
	to be accessible using CoAP over WebSockets.
	coap-ws-URI = "coap+ws:" "//" host [ ":" port ]		7.3. Use of the "coap" URI scheme with WebSockets
	path-abempty [ "?" query ] [ "#" fragment ]
	The port subcomponent is OPTIONAL. The default is port 80.		The "coap" URI scheme defined in Section 6.1 of [RFC7252] can also be
			used to identify CoAP resources that are intended to be accessible
			using CoAP over WebSockets.
	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" URI and the well-known path
	"/.well-known/coap" [RFC5785]. The present specification formally		"/.well-known/coap" [RFC5785] [I-D.bormann-hybi-ws-wk]. The path and
	updates [RFC6455], extending the well-known URI mechanism defined in		query parts of the "coap" URI identify a resource within the
	[RFC5785] to also cover the "ws" URI scheme defined in that document.		specified endpoint which can be operated on by the methods defined by
	The path and query parts of a "coap+ws" URI identify a resource		CoAP:
	within the specified endpoint which can be operated on by the methods
	defined by CoAP:
	coap+ws://example.org/sensors/temperature?u=Cel		coap://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: Building ws URIs and Uri options from coap URIs
	Encoding considerations: The scheme encoding conforms to the
	encoding rules established for URIs in [RFC3986].
	Interoperability considerations: None.
	Security considerations: See Section 11.1 of [RFC7252].
	7.4. coaps+ws URI scheme
	The "coaps+ws" URI scheme identifies CoAP resources that are intended		Note that the default port for "coap" is 5683, while the default port
	to be accessible using CoAP over WebSockets secured by TLS.		for "ws" is 80. Therefore, if the port given for "coap" is 80, the
			default port for "ws" can be used. If the port is not given for
			"coap", then an explicit port number of 5683 needs to be given for
			"ws".
	coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ]		7.4. Use of the "coaps" URI scheme with WebSockets
	path-abempty [ "?" query ] [ "#" fragment ]
	The port subcomponent is OPTIONAL. The default is port 443.		The "coaps" URI scheme defined in Section 6.2 of [RFC7252] can also
			be used to identify CoAP resources that are intended to be accessible
			using CoAP over WebSockets secured by TLS.
	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" URI and the well-known path
	"/.well-known/coap" [RFC5785]. The present specification formally		"/.well-known/coap" [RFC5785] [I-D.bormann-hybi-ws-wk]. The path and
	updates [RFC6455], extending the well-known URI mechanism defined in		query parts of the "coaps" URI identify a resource within the
	[RFC5785] to also cover the "wss" URI scheme defined in that		specified endpoint which can be operated on by the methods defined by
	document. The path and query parts of a "coaps+ws" URI identify a		CoAP.
	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://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: Building wss URIs and Uri options from coaps URIs
	Encoding considerations: The scheme encoding conforms to the
	encoding rules established for URIs in [RFC3986].
	Interoperability considerations: None.
	Security considerations: See Section 11.1 of [RFC7252].		Note that the default port for "coaps" is 5684, while the default
			port for "wss" is 443. If the port given for "coap" is 443, the
			default port for "wss" can be used. If the port is not given for
			"coaps", then an explicit port number of 5684 needs to be given for
			"wss".
	7.5. Uri-Host and Uri-Port Options		7.5. Uri-Host and Uri-Port Options
	CoAP over reliable transports maintains the property from		Except for the transports over WebSockets, CoAP over reliable
	Section 5.10.1 of [RFC7252]:		transports maintains the property from Section 5.10.1 of [RFC7252]:
	The default values for the Uri-Host and Uri-Port Options are		The default values for the Uri-Host and Uri-Port Options are
	sufficient for requests to most servers.		sufficient for requests to most servers.
	Unless otherwise noted, the default value of the Uri-Host Option is		Unless otherwise noted, the default value of the Uri-Host Option is
	the IP literal representing the destination IP address of the request		the IP literal representing the destination IP address of the request
	message. The default value of the Uri-Port Option is the destination		message. The default value of the Uri-Port Option is the destination
	TCP port.		TCP port.
	For CoAP over TLS, these default values are the same unless Server		For CoAP over TLS, these default values are the same unless Server
	skipping to change at page 29, line 12 ¶		skipping to change at page 28, line 16 ¶
	requests from the WebSocket client to the WebSocket server is		requests from the WebSocket client to the WebSocket server is
	indicated by the Host header field from the WebSocket handshake.		indicated by the Host header field from the WebSocket handshake.
	7.6. Decomposing URIs into Options		7.6. Decomposing URIs into Options
	The steps are the same as specified in Section 6.4 of [RFC7252] with		The steps are the same as specified in Section 6.4 of [RFC7252] with
	minor changes.		minor changes.
	This step from [RFC7252]:		This step from [RFC7252]:
	3. If |url| does not have a <scheme> component whose value, when
	converted to ASCII lowercase, is "coap" or "coaps", then fail
	this algorithm.
	is updated to:
	3. If |url| does not have a <scheme> component whose value, when
	converted to ASCII lowercase, is "coap+tcp", "coaps+tcp",
	"coap+ws", or "coaps+ws", then fail this algorithm.
	This step from [RFC7252]:
	7. If |port| does not equal the request's destination UDP port,		7. If |port| does not equal the request's destination UDP port,
	include a Uri-Port Option and let that option's value be |port|.		include a Uri-Port Option and let that option's value be |port|.
	is updated to:		is updated to:
	7. If |port| does not equal the request's destination TCP port,		7. If |port| does not equal the request's destination UDP port or
	include a Uri-Port Option and let that option's value be |port|.		TCP port, include a Uri-Port Option and let that option's value
			be |port|.
	7.7. Composing URIs from Options		7.7. Composing URIs from Options
	The steps are the same as specified in Section 6.5 of [RFC7252] with		The steps are the same as specified in Section 6.5 of [RFC7252] with
	minor changes.		minor changes.
	This step from [RFC7252]:		This step from [RFC7252]:
	1. If the request is secured using DTLS, let |url| be the string		1. If the request is secured using DTLS, let |url| be the string
	"coaps://". Otherwise, let |url| be the string "coap://".		"coaps://". Otherwise, let |url| be the string "coap://".
	is updated to:		is updated to:
	1. For CoAP over TCP, if the request is secured using TLS, let |url|		1. If the request is secured using DTLS or TLS, let |url| be
	be the string "coaps+tcp://". Otherwise, let |url| be the string		the string "coaps://". Otherwise, let |url| be the string
	"coap+tcp://". For CoAP over WebSockets, if the request is		"coap://".
	secured using TLS, let |url| be the string "coaps+ws://".
	Otherwise, let |url| be the string "coap+ws://".
	This step from [RFC7252]:		This step from [RFC7252]:
	4. If the request includes a Uri-Port Option, let |port| be that		4. If the request includes a Uri-Port Option, let |port| be that
	option's value. Otherwise, let |port| be the request's		option's value. Otherwise, let |port| be the request's
	destination UDP port.		destination UDP port.
	is updated to:		is updated to:
	4. If the request includes a Uri-Port Option, let |port| be that		4. If the request includes a Uri-Port Option, let |port| be that
	option's value. Otherwise, let |port| be the request's		option's value. Otherwise, let |port| be the request's
	destination TCP port.		destination UDP port or TCP port.
			7.8. Trying out multiple transports at once
			As in the "Happy Eyeballs" approach to using IPv6 and IPv4 [RFC6555],
			an application may want to try out multiple transports for a given
			URI at the same time, e.g., DTLS over UDP and TLS over TCP. However,
			two important caveats need to be considered:
			o Initiating multiple instances of the same exchange with the
			intention of using only one of the successful results is only safe
			for idempotent exchanges (see Section 5.1 of [RFC7252]).
			o An important setback in using the UDP or DTLS over UDP transport
			through NATs and other middleboxes can be the quick loss of NAT
			bindings during idling periods [HomeGateway]. This will not be
			evident right on the initial exchange.
			After the initial exchange, or whenever important information is
			learned about which selection to prefer, an endpoint may want to
			cache this information; however, the information may become stale
			after the endpoint moves or the network changes. A cache timeout
			(possibly enhanced by movement detection) is advisable.
			Alternatively, or additionally, the choice of transport may be aided
			by configuration and resource directory information; the self-
			description of a node may also include target attributes for links
			given to resources there. Details of such attributes are out of
			scope for the present document; see for instance
			[I-D.ietf-core-resource-directory].
	8. Securing CoAP		8. Securing CoAP
	Security Challenges for the Internet of Things [SecurityChallenges]		Security Challenges for the Internet of Things [SecurityChallenges]
	recommends:		recommends:
	... it is essential that IoT protocol suites specify a mandatory		... it is essential that IoT protocol suites specify a mandatory
	to implement but optional to use security solution. This will		to implement but optional to use security solution. This will
	ensure security is available in all implementations, but		ensure security is available in all implementations, but
	configurable to use when not necessary (e.g., in closed		configurable to use when not necessary (e.g., in closed
	skipping to change at page 30, line 37 ¶		skipping to change at page 30, line 7 ¶
	A security solution MUST be implemented to protect CoAP over reliable		A security solution MUST be implemented to protect CoAP over reliable
	transports and MUST be enabled by default. This document defines the		transports and MUST be enabled by default. This document defines the
	TLS binding, but alternative solutions at different layers in the		TLS binding, but alternative solutions at different layers in the
	protocol stack MAY be used to protect CoAP over reliable transports		protocol stack MAY be used to protect CoAP over reliable transports
	when appropriate. Note that there is ongoing work to support a data		when appropriate. Note that there is ongoing work to support a data
	object-based security model for CoAP that is independent of transport		object-based security model for CoAP that is independent of transport
	(see [I-D.ietf-core-object-security]).		(see [I-D.ietf-core-object-security]).
	8.1. TLS binding for CoAP over TCP		8.1. TLS binding for CoAP over TCP
	The TLS usage guidance in [RFC7925] applies.		The TLS usage guidance in [RFC7925] applies, including the guidance
			about cipher suites in that document that are derived from the
			mandatory to implement (MTI) cipher suites defined in [RFC7252].
			(Note that this selection caters for the device-to-cloud use case of
			CoAP over TLS more than for any use within a back-end environment,
			where the standard TLS 1.2 cipher suites or the more recent ones
			defined in [RFC7525] are more appropriate.)
	During the provisioning phase, a CoAP device is provided with the		During the provisioning phase, a CoAP device is provided with the
	security information that it needs, including keying materials,		security information that it needs, including keying materials,
	access control lists, and authorization servers. At the end of the		access control lists, and authorization servers. At the end of the
	provisioning phase, the device will be in one of four security modes:		provisioning phase, the device will be in one of four security modes:
	NoSec: TLS is disabled.		NoSec: TLS is disabled.
	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 optional-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" scheme
	scheme and the TCP CoAP default port. The system is secured only by		and the TCP CoAP default port. The system is secured only by keeping
	keeping attackers from being able to send or receive packets from the		attackers from being able to send or receive packets from the network
	network with the CoAP nodes.		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" scheme and TLS-secured CoAP default port.
	port.
	8.2. TLS usage for CoAP over WebSockets		8.2. TLS usage for CoAP over WebSockets
	A CoAP client requesting a resource identified by a "coaps+ws" URI		A CoAP client requesting a resource identified by a "coaps" URI
	negotiates a secure WebSocket connection to a WebSocket server		negotiates a secure WebSocket connection to a WebSocket server
	endpoint with a "wss" URI. This is described in Section 7.4.		endpoint with a "wss" URI. This is described in Section 7.4.
	The client MUST perform a TLS handshake after opening the connection		The client MUST perform a TLS handshake after opening the connection
	to the server. The guidance in Section 4.1 of [RFC6455] applies.		to the server. The guidance in Section 4.1 of [RFC6455] applies.
	When a CoAP server exposes resources identified by a "coaps+ws" URI,		When a CoAP server exposes resources identified by a "coaps" URI, the
	the guidance in Section 4.4 of [RFC7925] applies towards mandatory-		guidance in Section 4.4 of [RFC7925] applies towards mandatory-to-
	to-implement TLS functionality for certificates. For the server-side		implement TLS functionality for certificates. For the server-side
	requirements in accepting incoming connections over a HTTPS (HTTP-		requirements in accepting incoming connections over a HTTPS (HTTP-
	over-TLS) port, the guidance in Section 4.2 of [RFC6455] applies.		over-TLS) port, the guidance in Section 4.2 of [RFC6455] applies.
			Note that this formally inherits the mandatory to implement cipher
			suites defined in [RFC5246]. However, modern usually browsers
			implement more recent cipher suites that then are automatically
			picked up via the JavaScript WebSocket API. WebSocket Servers that
			provide Secure CoAP over WebSockets for the browser use case will
			need to follow the browser preferences and MUST follow [RFC7525].
	9. Security Considerations		9. Security Considerations
	The security considerations of [RFC7252] apply. For CoAP over		The security considerations of [RFC7252] apply. For CoAP over
	WebSockets and CoAP over TLS-secured WebSockets, the security		WebSockets and CoAP over TLS-secured WebSockets, the security
	considerations of [RFC6455] also apply.		considerations of [RFC6455] also apply.
	9.1. Signaling Messages		9.1. Signaling Messages
	The guidance given by an Alternative-Address Option cannot be		The guidance given by an Alternative-Address Option cannot be
	followed blindly. In particular, a peer MUST NOT assume that a		followed blindly. In particular, a peer MUST NOT assume that a
	skipping to change at page 33, line 43 ¶		skipping to change at page 33, line 43 ¶
	o Whether the option is repeatable.		o Whether the option is repeatable.
	o The format and length of the option's value.		o The format and length of the option's value.
	o The base value for the option, if any.		o The base value for the option, if any.
	10.3. Service Name and Port Number Registration		10.3. Service Name and Port Number Registration
	IANA is requested to assign the port number 5683 and the service name		IANA is requested to assign the port number 5683 and the service name
	"coap+tcp", in accordance with [RFC6335].		"coap", in accordance with [RFC6335].
	Service Name.		Service Name.
	coap+tcp		coap
	Transport Protocol.		Transport Protocol.
	tcp		tcp
	Assignee.		Assignee.
	IESG <iesg@ietf.org>		IESG <iesg@ietf.org>
	Contact.		Contact.
	IETF Chair <chair@ietf.org>		IETF Chair <chair@ietf.org>
	skipping to change at page 34, line 21 ¶		skipping to change at page 34, line 21 ¶
	Reference.		Reference.
	[RFCthis]		[RFCthis]
	Port Number.		Port Number.
	5683		5683
	10.4. Secure Service Name and Port Number Registration		10.4. Secure Service Name and Port Number Registration
	IANA is requested to assign the port number 5684 and the service name		IANA is requested to assign the port number 5684 and the service name
	"coaps+tcp", in accordance with [RFC6335]. The port number is		"coaps+tcp", in accordance with [RFC6335]. The port number is
	requested to address the exceptional case of TLS implementations that		requested also to address the exceptional case of TLS implementations
	do not support the "Application-Layer Protocol Negotiation Extension"		that do not support the "Application-Layer Protocol Negotiation
	[RFC7301].		Extension" [RFC7301].
	Service Name.		Service Name.
	coaps+tcp		coaps
	Transport Protocol.		Transport Protocol.
	tcp		tcp
	Assignee.		Assignee.
	IESG <iesg@ietf.org>		IESG <iesg@ietf.org>
	Contact.		Contact.
	IETF Chair <chair@ietf.org>		IETF Chair <chair@ietf.org>
	Description.		Description.
	Constrained Application Protocol (CoAP)		Constrained Application Protocol (CoAP)
	Reference.		Reference.
	[RFC7301], [RFCthis]		[RFC7301], [RFCthis]
	Port Number.		Port Number.
	5684		5684
	10.5. URI Scheme Registration		10.5. Well-Known URI Suffix Registration
	URI schemes are registered within the "Uniform Resource Identifier
	(URI) Schemes" registry maintained at
	http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml .
	10.5.1. coap+tcp
	IANA is requested to register the Uniform Resource Identifier (URI)
	scheme "coap+tcp". This registration request complies with
	[RFC7595].
	Scheme name:
	coap+tcp
	Status:
	Permanent
	Applications/protocols that use this scheme name:
	The scheme is used by CoAP endpoints to access CoAP resources
	using TCP.
	Contact:
	IETF chair <chair@ietf.org>
	Change controller:
	IESG <iesg@ietf.org>
	Reference:
	Section 7.1 in [RFCthis]
	10.5.2. coaps+tcp
	IANA is requested to register the Uniform Resource Identifier (URI)
	scheme "coaps+tcp". This registration request complies with
	[RFC7595].
	Scheme name:
	coaps+tcp
	Status:
	Permanent
	Applications/protocols that use this scheme name:
	The scheme is used by CoAP endpoints to access CoAP resources
	using TLS.
	Contact:
	IETF chair <chair@ietf.org>
	Change controller:
	IESG <iesg@ietf.org>
	Reference:
	Section 7.2 in [RFCthis]
	10.5.3. coap+ws
	IANA is requested to register the Uniform Resource Identifier (URI)
	scheme "coap+ws". This registration request complies with [RFC7595].
	Scheme name:
	coap+ws
	Status:
	Permanent
	Applications/protocols that use this scheme name:
	The scheme is used by CoAP endpoints to access CoAP resources
	using the WebSocket protocol.
	Contact:
	IETF chair <chair@ietf.org>
	Change controller:
	IESG <iesg@ietf.org>
	Reference:
	Section 7.3 in [RFCthis]
	10.5.4. coaps+ws
	IANA is requested to register the Uniform Resource Identifier (URI)
	scheme "coaps+ws". This registration request complies with
	[RFC7595].
	Scheme name:
	coaps+ws
	Status:
	Permanent
	Applications/protocols that use this scheme name:
	The scheme is used by CoAP endpoints to access CoAP resources
	using the WebSocket protocol secured with TLS.
	Contact:
	IETF chair <chair@ietf.org>
	Change controller:
	IESG <iesg@ietf.org>
	References:
	Section 7.4 in [RFCthis]
	10.6. Well-Known URI Suffix Registration
	IANA is requested to register the 'coap' well-known URI in the "Well-		IANA is requested to register the 'coap' well-known URI in the "Well-
	Known URIs" registry. This registration request complies with		Known URIs" registry. This registration request complies with
	[RFC5785]:		[RFC5785]:
	URI Suffix.		URI Suffix.
	coap		coap
	Change controller.		Change controller.
	IETF		IETF
	Specification document(s).		Specification document(s).
	[RFCthis]		[RFCthis]
	Related information.		Related information.
	None.		None.
	10.7. ALPN Protocol Identifier		10.6. ALPN Protocol Identifier
	IANA is requested to assign the following value in the registry		IANA is requested to assign the following value in the registry
	"Application Layer Protocol Negotiation (ALPN) Protocol IDs" created		"Application Layer Protocol Negotiation (ALPN) Protocol IDs" created
	by [RFC7301]. The "coap" string identifies CoAP when used over TLS.		by [RFC7301]. The "coap" string identifies CoAP when used over TLS.
	Protocol.		Protocol.
	CoAP		CoAP
	Identification Sequence.		Identification Sequence.
	0x63 0x6f 0x61 0x70 ("coap")		0x63 0x6f 0x61 0x70 ("coap")
	Reference.		Reference.
	[RFCthis]		[RFCthis]
	10.8. WebSocket Subprotocol Registration		10.7. WebSocket Subprotocol Registration
	IANA is requested to register the WebSocket CoAP subprotocol under		IANA is requested to register the WebSocket CoAP subprotocol under
	the "WebSocket Subprotocol Name Registry":		the "WebSocket Subprotocol Name Registry":
	Subprotocol Identifier.		Subprotocol Identifier.
	coap		coap
	Subprotocol Common Name.		Subprotocol Common Name.
	Constrained Application Protocol (CoAP)		Constrained Application Protocol (CoAP)
	skipping to change at page 38, line 4 ¶		skipping to change at page 35, line 43 ¶
	IANA is requested to register the WebSocket CoAP subprotocol under		IANA is requested to register the WebSocket CoAP subprotocol under
	the "WebSocket Subprotocol Name Registry":		the "WebSocket Subprotocol Name Registry":
	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		10.8. CoAP Option Numbers Registry
	IANA is requested to add [RFCthis] to the references for the		IANA is requested to add [RFCthis] to the references for the
	following entries registered by [RFC7959] in the "CoAP Option		following entries registered by [RFC7959] in the "CoAP Option
	Numbers" sub-registry defined by [RFC7252]:		Numbers" sub-registry defined by [RFC7252]:
	+--------+--------+---------------------+		+--------+--------+---------------------+
	| Number | Name | Reference |		| Number | Name | Reference |
	+--------+--------+---------------------+		+--------+--------+---------------------+
	| 23 | Block2 | RFC 7959, [RFCthis] |		| 23 | Block2 | RFC 7959, [RFCthis] |
	| | | |		| | | |
	| 27 | Block1 | RFC 7959, [RFCthis] |		| 27 | Block1 | RFC 7959, [RFCthis] |
	+--------+--------+---------------------+		+--------+--------+---------------------+
	Table 3: CoAP Option Numbers		Table 3: CoAP Option Numbers
	11. References		11. References
	11.1. Normative References		11.1. Normative References
			[I-D.bormann-hybi-ws-wk]
			Bormann, C., "Well-known URIs for the WebSocket Protocol",
			draft-bormann-hybi-ws-wk-00 (work in progress), May 2017.
	[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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	skipping to change at page 39, line 29 ¶		skipping to change at page 37, line 24 ¶
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<http://www.rfc-editor.org/info/rfc7252>.		<http://www.rfc-editor.org/info/rfc7252>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"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, <http://www.rfc-editor.org/info/rfc7301>.		July 2014, <http://www.rfc-editor.org/info/rfc7301>.
	[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines		[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	and Registration Procedures for URI Schemes", BCP 35,		"Recommendations for Secure Use of Transport Layer
	RFC 7595, DOI 10.17487/RFC7595, June 2015,		Security (TLS) and Datagram Transport Layer Security
	<http://www.rfc-editor.org/info/rfc7595>.		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
			2015, <http://www.rfc-editor.org/info/rfc7525>.
	[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,
	<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,
	skipping to change at page 40, line 20 ¶		skipping to change at page 38, line 13 ¶
	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-01 (work in progress), March 2017.		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-02 (work in progress), March 2017.		object-security-03 (work in progress), May 2017.
			[I-D.ietf-core-resource-directory]
			Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
			Resource Directory", draft-ietf-core-resource-directory-10
			(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 48 ¶		skipping to change at page 38, line 46 ¶
	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,
	<http://www.rfc-editor.org/info/rfc6335>.		<http://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, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <http://www.rfc-editor.org/info/rfc6347>.
			[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
			Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
			2012, <http://www.rfc-editor.org/info/rfc6555>.
	[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>.
	[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/
	skipping to change at page 42, line 33 ¶		skipping to change at page 40, line 40 ¶
	CoAP server) MUST remove all entries associated with the client		CoAP server) MUST remove all entries associated with the client
	endpoint from the lists of observers when the connection is either		endpoint from the lists of observers when the connection is either
	closed or times out.		closed or times out.
	Appendix B. CoAP over WebSocket Examples		Appendix B. CoAP over WebSocket Examples
	This section gives examples for the first two configurations		This section gives examples for the first two configurations
	discussed in Section 4.		discussed in Section 4.
	An example of the process followed by a CoAP client to retrieve the		An example of the process followed by a CoAP client to retrieve the
	representation of a resource identified by a "coap+ws" URI might be		representation of a resource identified by a "coap" URI might be as
	as follows. Figure 20 below illustrates the WebSocket and CoAP		follows. Figure 20 below illustrates the WebSocket and CoAP messages
	messages exchanged in detail.		exchanged in detail.
	1. The CoAP client obtains the URI <coap+ws://example.org/sensors/		1. The CoAP client obtains the URI <coap://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. 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.
	skipping to change at page 44, line 51 ¶		skipping to change at page 42, line 51 ¶
	| | +-------------------------+		| | +-------------------------+
	: :		: :
	: :		: :
	| |		| |
	+--------->| 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 20: A CoAP client retrieves the representation of a resource		Figure 20: A CoAP client retrieves the representation of a resource
	identified by a "coap+ws" URI		identified by a "coap" URI over the WebSocket protocol
	Figure 21 shows how a CoAP client uses a CoAP forward proxy with a		Figure 21 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
	"coap://[2001:db8::1]/". The use of the forward proxy and the		"coap://[2001:db8::1]/". The use of the forward proxy and the
	address of the WebSocket endpoint are determined by the client from		address of the WebSocket endpoint are determined by the client from
	local configuration rules. The request URI is specified in the		local configuration rules. The request URI is specified in the
	Proxy-Uri Option. Since the request URI uses the "coap" URI scheme,		Proxy-Uri Option. Since the request URI uses the "coap" URI scheme,
	the proxy fulfills the request by issuing a Confirmable GET request		the proxy fulfills the request by issuing a Confirmable GET request
	over UDP to the CoAP server and returning the response over the		over UDP to the CoAP server and returning the response over the
	WebSocket connection to the client.		WebSocket connection to the client.
	skipping to change at page 45, line 50 ¶		skipping to change at page 43, line 50 ¶
	| | |		| | |
	|<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0)		|<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0)
	| | | +------------------------------------+		| | | +------------------------------------+
	| | | | 2.05 Content |		| | | | 2.05 Content |
	| | | | Token: 0x7d |		| | | | Token: 0x7d |
	| | | | Payload: "ready" |		| | | | Payload: "ready" |
	| | | +------------------------------------+		| | | +------------------------------------+
	| | |		| | |
	Figure 21: A CoAP client retrieves the representation of a resource		Figure 21: A CoAP client retrieves the representation of a resource
	identified by a "coap" URI via a WebSockets-enabled CoAP proxy		identified by a "coap" URI via a WebSocket-enabled CoAP proxy
	Appendix C. Change Log		Appendix C. Change Log
	The RFC Editor is requested to remove this section at publication.		The RFC Editor is requested to remove this section at publication.
	C.1. Since draft-ietf-core-coap-tcp-tls-02		C.1. Since draft-ietf-core-coap-tcp-tls-02
	Merged draft-savolainen-core-coap-websockets-07 Merged draft-bormann-		Merged draft-savolainen-core-coap-websockets-07 Merged draft-bormann-
	core-block-bert-01 Merged draft-bormann-core-coap-sig-02		core-block-bert-01 Merged draft-bormann-core-coap-sig-02
	skipping to change at page 47, line 31 ¶		skipping to change at page 45, line 31 ¶
	Added "Updates RFC7959" for BERT		Added "Updates RFC7959" for BERT
	Added "Updates RFC6455" to extend well-known URI mechanism to ws and		Added "Updates RFC6455" to extend well-known URI mechanism to ws and
	wss		wss
	Clarified well-known URI mechanism use for all URI schemes		Clarified well-known URI mechanism use for all URI schemes
	Changed NoSec to optional-to-implement		Changed NoSec to optional-to-implement
			C.7. Since draft-ietf-core-coap-tcp-tls-08
			Reverted "Updates RFC6455" to extend well-known URI mechanism to ws
			and wss; point to [I-D.bormann-hybi-ws-wk] instead
			Don't use port 443 as the default port for coaps+tcp
			Remove coap+tt and coaps+tt URI schemes (where tt is tcp or ws); map
			everything to coap/coaps
	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. Last-call reviews from Mark Nottingham and
			Yoshifumi Nishida as well as several IESG reviewers provided
			extensive comments; from the IESG, we would like to specifically call
			out Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kuehlewind, and
			the responsible AD Alexey Melnikov.
	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. 73 change blocks.
	323 lines changed or deleted		242 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/