< draft-ietf-core-coap-tcp-tls-01.txt   draft-ietf-core-coap-tcp-tls-02.txt >
CORE C. Bormann, Ed. CORE C. Bormann, Ed.
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track S. Lemay Intended status: Standards Track S. Lemay
Expires: May 22, 2016 V. Solorzano Barboza Expires: October 23, 2016 V. Solorzano Barboza
Zebra Technologies Zebra Technologies
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
November 19, 2015 April 21, 2016
A TCP and TLS Transport for the Constrained Application Protocol (CoAP) A TCP and TLS Transport for the Constrained Application Protocol (CoAP)
draft-ietf-core-coap-tcp-tls-01 draft-ietf-core-coap-tcp-tls-02
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) was designed with TCP as the The Hypertext Transfer Protocol (HTTP) was designed with TCP as the
underlying transport protocol. The Constrained Application Protocol underlying transport protocol. The Constrained Application Protocol
(CoAP), while inspired by HTTP, has been defined to make use of UDP (CoAP), while inspired by HTTP, has been defined to make use of UDP
instead of TCP. Therefore, reliable delivery and a simple congestion instead of TCP. Therefore, reliable delivery and a simple congestion
control and flow control mechanism are provided by the message layer control and flow control mechanism are provided by the message layer
of the CoAP protocol. of the CoAP protocol.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 22, 2016. This Internet-Draft will expire on October 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Constrained Application Protocol . . . . . . . . . . . . . . 3 3. Constrained Application Protocol . . . . . . . . . . . . . . 3
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
5. Message Transmission . . . . . . . . . . . . . . . . . . . . 7 5. Message Transmission . . . . . . . . . . . . . . . . . . . . 8
6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 7 6.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 9
6.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 8 6.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. Service Name and Port Number Registration . . . . . . . . 8 8.1. Service Name and Port Number Registration . . . . . . . . 10
8.2. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 11
8.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 10 8.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 can be for Internet of Things (IoT) deployments, assuming that UDP can be
used unimpeded -- UDP [RFC0768], or DTLS [RFC6347] over UDP; it is a used unimpeded -- UDP [RFC0768], or DTLS [RFC6347] over UDP; it is a
good choice for transferring small amounts of data across networks good choice for transferring small amounts of data across networks
that follow the IP architecture. Some CoAP deployments, however, may that follow the IP architecture. Some CoAP deployments, however, may
have to integrate well with existing enterprise infrastructure, where have to integrate well with existing enterprise infrastructure, where
the use of UDP-based protocols may not be well-received or may even the use of UDP-based protocols may not be well-received or may even
skipping to change at page 4, line 27 skipping to change at page 4, line 27
| TCP | | TCP |
+----------------------+ +----------------------+
Figure 1: The CoAP over TLS/TCP Protocol Stack Figure 1: The CoAP over TLS/TCP Protocol Stack
Since TCP offers reliable delivery, there is no need to offer a Since TCP offers reliable delivery, there is no need to offer a
redundant acknowledgement at the CoAP messaging layer. redundant acknowledgement at the CoAP messaging layer.
Since there is no need to carry around acknowledgement semantics, Since there is no need to carry around acknowledgement semantics,
messages do not require a message type; no message layer messages do not require a message type; no message layer
acknowledgement is expected or even possible. Because something acknowledgement is expected or even possible. By the nature of TCP,
needs to be put into the two bits indicating the message type, we put messages are always transmitted reliably over TCP. Figure 2 (derived
the bits for a Non-Confirmable message (NON) into the header. By the from [RFC7252], Figure 3) shows this message exchange graphically. A
nature of TCP, messages are always transmitted reliably over TCP. UDP-to-TCP gateway will therefore discard all empty messages, such as
Figure 2 (derived from [RFC7252], Figure 3) shows this message empty ACKs (after operating on them at the message layer), and re-
exchange graphically. A UDP-to-TCP gateway will therefore discard pack the contents of all non-empty CON, NON, or ACK messages (i.e.,
all empty messages, such as empty ACKs (after operating on them at those ACK messages that have a piggy-backed response) into untyped
the message layer), and re-pack the contents of all non-empty CON, messages.
NON, or ACK messages (i.e., those ACK messages that have a piggy-
backed response) into untyped messages (that happen to look like NON
messages).
Similarly, there is no need to detect duplicate delivery of a Similarly, there is no need to detect duplicate delivery of a
message. In UDP CoAP, the Message ID is used for relating message. In UDP CoAP, the Message ID is used for relating
acknowledgements to Confirmable messages as well as for duplicate acknowledgements to Confirmable messages as well as for duplicate
detection. Since the Message ID thus is not meaningful over TCP, it detection. Since the Message ID thus is not meaningful over TCP, it
is elided (as indicated by the dashes in Figure 2). is elided (as indicated by the dashes in Figure 2).
Client Server Client Server
| | | |
| (no type) [------] | | (no type) [------] |
skipping to change at page 5, line 30 skipping to change at page 5, line 27
| | | |
Figure 3 Figure 3
4. Message Format 4. Message Format
The CoAP message format defined in [RFC7252], as shown in Figure 4, The CoAP message format defined in [RFC7252], as shown in Figure 4,
relies on the datagram transport (UDP, or DTLS over UDP) for keeping relies on the datagram transport (UDP, or DTLS over UDP) for keeping
the individual messages separate. the individual messages separate.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID | |Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ... | Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ... | Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ... |1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RFC 7252 defined CoAP Message Format. Figure 4: RFC 7252 defined CoAP Message Format.
In a stream oriented transport protocol such as TCP, a form of In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed. For this purpose, CoAP over TCP message delimitation is needed. For this purpose, CoAP over TCP
introduces a length field. Figure 5 shows a 2-byte shim header introduces a length field with variable size. Figure 5 shows the
carrying length information prepended to the CoAP message header. adjusted CoAP header format with a modified structure for the fixed
header (first 4 bytes of the UDP CoAP header), which includes the
length information of variable size, shown here as an 8-bit length.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |Ver|0 1| TKL | Code | |Len=13 | TKL | Length (8-bit)| Code | TKL bytes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (TKL bytes) ... | Options (if any) ... | Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ... |1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: CoAP Header with prepended Shim Header. Figure 5: CoAP Header with 8-bit Length in Header.
The 'Message Length' field is a 16-bit unsigned integer in network The initial byte of the frame contains two nibbles, in a similar way
byte order. It provides the length of the subsequent CoAP message to the CoAP option encoding (see Section 3.1 of [RFC7252]).
(including the CoAP header but excluding this message length field)
in bytes (so its minimum value is 2). The Message ID and message Len: The first nibble, Len, is interpreted as a 4-bit unsigned
type are meaningless and thus elided (what would have been the integer. A value between 0 and 12 directly indicates the length
message type field is always filled with what would be the code for of message in bytes starting with the first bit of the Options
NON (01)). field. The other three values have a special meaning:
13: An 8-bit unsigned integer follows the initial byte and
indicates the length of options/payload minus 13.
14: A 16-bit unsigned integer in network byte order follows the
initial byte and indicates the length of options/payload minus
269.
15: A 32-bit unsigned integer in network byte order follows the
initial byte and indicates the length of options/payload minus
65805.
TKL: The second nibble of the initial byte indicates the token
length.
The following figures show the shim headers for the 0-bit, 16-bit,
and the 32-bit headers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len | TKL | Code | Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: CoAP Header with elided Length Header.
For example: A CoAP message just containing a 2.03 code with the
token 7f and no options or payload would be encoded as shown in
Figure 7.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x43 | 0x7f |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 0 ------> 0x01
TKL = 1 ___/
Code = 2.03 --> 0x43
Token = 0x7f
Figure 7: CoAP Header Example.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Len=14 | TKL | Length (16 bits) | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: CoAP Header with 16-bit Length in Header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Len=15 | TKL | Length (32 bits)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code | Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: CoAP Header with 32-bit Length in Header.
The semantics of the other CoAP header fields are left unchanged. The semantics of the other CoAP header fields are left unchanged.
4.1. Discussion 4.1. Discussion
One observation is that, over a reliable byte stream transport, the One observation is that, over a reliable byte stream transport, the
message size limitations defined in Section 4.6 of [RFC7252] are no message size limitations defined in Section 4.6 of [RFC7252] are no
longer strictly necessary. Consenting [[how: There is currently no longer strictly necessary. Consenting [[how: There is currently no
defined way to arrive at this consent. --cabo]] implementations may defined way to arrive at this consent. --cabo]] implementations may
want to interchange messages with payload sizes larger than 1024 want to interchange messages with payload sizes larger than 1024
skipping to change at page 6, line 47 skipping to change at page 8, line 25
o a UDP-to-TCP gateway may simply not have the context to convert a o a UDP-to-TCP gateway may simply not have the context to convert a
message with a Block option into the equivalent exchange without message with a Block option into the equivalent exchange without
any use of a Block option; any use of a Block option;
o large messages might also cause undesired head-of-line blocking; o large messages might also cause undesired head-of-line blocking;
o the 2-byte message length field causes another, larger upper bound o the 2-byte message length field causes another, larger upper bound
to the message length. to the message length.
[I-D.bormann-core-block-bert] proposes to extend the block-wise
transfer protocol to allow for larger block sizes as are possible
over TCP and TLS.
The general assumption is therefore that the block protocol will The general assumption is therefore that the block protocol will
continue to be used over TCP, even if TCP-based applications continue to be used over TCP, even if TCP-based applications
occasionally do exchange messages with payload sizes larger than occasionally do exchange messages with payload sizes larger than
desirable in UDP. desirable in UDP.
5. Message Transmission 5. Message Transmission
As CoAP exchanges messages asynchronously over the TCP connection, As CoAP exchanges messages asynchronously over the TCP connection,
the client can send multiple requests without waiting for responses. the client can send multiple requests without waiting for responses.
For this reason, and due to the nature of TCP, responses are returned For this reason, and due to the nature of TCP, responses are returned
skipping to change at page 10, line 40 skipping to change at page 12, line 26
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dice-profile] [I-D.ietf-dice-profile]
Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the
Internet of Things", draft-ietf-dice-profile-17 (work in Internet of Things", draft-ietf-dice-profile-17 (work in
progress), October 2015. progress), October 2015.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[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, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252,
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 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, RFC and Registration Procedures for URI Schemes", BCP 35,
7595, DOI 10.17487/RFC7595, June 2015, RFC 7595, DOI 10.17487/RFC7595, June 2015,
<http://www.rfc-editor.org/info/rfc7595>. <http://www.rfc-editor.org/info/rfc7595>.
10.2. Informative References 10.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.bormann-core-block-bert]
Bormann, C., "Block-wise transfers in CoAP: Extension for
Reliable Transport (BERT)", draft-bormann-core-block-
bert-00 (work in progress), November 2015.
[I-D.bormann-core-cocoa] [I-D.bormann-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-bormann- "CoAP Simple Congestion Control/Advanced", draft-bormann-
core-cocoa-03 (work in progress), October 2015. core-cocoa-03 (work in progress), October 2015.
[I-D.ietf-core-block] [I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
draft-ietf-core-block-18 (work in progress), September draft-ietf-core-block-19 (work in progress), March 2016.
2015.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
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>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
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, RFC Transport Protocol Port Number Registry", BCP 165,
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>.
Authors' Addresses Authors' Addresses
Carsten Bormann (editor) Carsten Bormann (editor)
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Simon Lemay Simon Lemay
 End of changes. 23 change blocks. 
78 lines changed or deleted 158 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/