CoRE Working Group B. Silverajan
Internet-Draft TUT
Intended status: Informational M. Ocak
Expires: May 3, 2018 Ericsson
October 30, 2017
CoAP Protocol Negotiation
draft-silverajan-core-coap-protocol-negotiation-07
Abstract
CoAP has been standardised as an application-level REST-based
protocol. When multiple transport protocols exist for exchanging
CoAP resource representations, this document introduces a way forward
for CoAP endpoints as well as intermediaries to agree upon alternate
transport and protocol configurations as well as URIs for CoAP
messaging. Several mechanisms are proposed: Extending the CoRE
Resource Directory with new parameter types, introducing a new CoAP
Option with which clients can interact directly with servers without
needing the Resource Directory, and finally a new CoRE Link Attribute
allowing exposing alternate locations on a per-resource basis.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
Silverajan & Ocak Expires May 3, 2018 [Page 1]
Internet-Draft CoAP Protocol Negotiation October 2017
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overcoming Middlebox Issues . . . . . . . . . . . . . . . 4
2.2. Better resource caching and serving in proxies . . . . . 5
3. Node Types based on Transport Availability . . . . . . . . . 6
4. New Resource Directory Parameters . . . . . . . . . . . . . . 7
4.1. The 'at' RD parameter . . . . . . . . . . . . . . . . . . 7
4.2. The 'tt' RD parameter . . . . . . . . . . . . . . . . . . 9
5. CoAP Alternative-Transport Option . . . . . . . . . . . . . . 9
6. The 'ol' CoRE Link Attribute . . . . . . . . . . . . . . . . 13
6.1. Using /.well-known/core . . . . . . . . . . . . . . . . . 13
6.2. Using CoRE Resource Directory . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15
A.1. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 15
A.2. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 16
A.3. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 16
A.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 16
A.5. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 16
A.6. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 16
A.7. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] allows clients,
origin servers and proxies, to exchange and manipulate resource
representations using REST-based methods over UDP or DTLS. CoAP
messaging is however being extended to use other alternative
underlying transports. These include reliable transports such as
TCP, WebSockets and TLS. In addition, the use of SMS as a CoAP
transport remains a possibility for simple communication in cellular
networks.
Silverajan & Ocak Expires May 3, 2018 [Page 2]
Internet-Draft CoAP Protocol Negotiation October 2017
When CoAP-based endpoints and proxies possess the ability to perform
CoAP messaging over multiple transports, significant benefits can be
obtained if communicating client endpoints can discover that multiple
transport bindings may exist on an origin server over which CoAP
resources can be retrieved. This allows a client to understand and
possibly substitute a different transport protocol configuration for
the same CoAP resources on the origin server, based on the
preferences of the communicating peers. Inevitably, if two CoAP
endpoints reside in distinctly separate networks with orthogonal
transports, a CoAP proxy node is needed between the two networks so
that CoAP Requests and Responses can be exchanged properly.
A URI in CoAP, however, serves two purposes simultaneously. It
firstly functions as a locator, by specifying the network location of
the endpoint hosting the resource, and the underlying transport used
by CoAP for accessing the resource representation. It secondly
identifies the name of the specific resource found at that endpoint
together with its namespace, or resource path. A single CoAP URI
cannot be used to express the identity of the resource independently
of alternate underlying transports or protocol configuration.
Multiple URIs can result for a single CoAP resource representations
if:
o the authority components of the URI differ, owing to the same
physical host exposing several network endpoints. For example,
"coap://example.org/sensors/temperature" and
"coap://example.net/sensors/temperature"
o the scheme components of the URI differ, owing to the origin
server exposing several underlying transport alternatives. For
example, "coap://example.org/sensors/temperature" and
"coap+tcp://example.org/sensors/temperature"
o the path components of the URI differ, should an origin server
also allow alternative transport endpoint such as the WebSocket
protocol, to be expressed using the path. For example,
"coap://example.org/sensors/temperature" and
"coap+ws://example.org/ws-endpoint/sensors/temperature"
Without a priori knowledge, clients would be unable to ascertain if
two or more URIs provided by an origin server are associated to the
same representation or not. Consequently, a communication mechanism
needs to be conceived to allow an origin server to properly capture
the relationship between these alternate representations or locations
and then subsequently supply this information to clients. This also
goes some way in limiting URI aliasing [WWWArchv1].
Silverajan & Ocak Expires May 3, 2018 [Page 3]
Internet-Draft CoAP Protocol Negotiation October 2017
In order to support CoAP clients, proxies and servers wishing to use
CoAP over multiple transports, this draft proposes the following:
o An ability for servers to register supported CoAP transports to a
CoRE Resource Directory [I-D.ietf-core-resource-directory] with
optional registration lifetime values
o A means for CoAP clients to interact with a CoRE resource
directory interface for requesting and discovering alternative
transports and locations of CoAP resources
o New Resource Directory parameter types enabling the above-
mentioned features.
o A new CoAP Option called Alternative-Transport that can be used by
CoAP clients to discover and retrieve the types of alternative
transports available at the origin server, as well as the links
describing the transport-specific endpoint address at which CoAP
resources are exposed from.
o A new CoRE Link attribute for exposing transports and endpoint
locations on an origin server on a per-resource basis.
2. Aim
The following simple scenarios aim to better portray how CoAP
protocol negotiation benefits communicating nodes
2.1. Overcoming Middlebox Issues
Discovering which transports are available is important for a client
to determine the optimal alternative to perform CoAP messaging
according to its needs, particularly when separated from a CoAP
server via a NAT. It is well-known that some firewalls as well as
many NATs, particularly home gateways, hinder the proper operation of
UDP traffic. NAT bindings for UDP-based traffic do not have as long
timeouts as TCP-based traffic.
Silverajan & Ocak Expires May 3, 2018 [Page 4]
Internet-Draft CoAP Protocol Negotiation October 2017
+-----------+
| Resource |
+--4-->| Directory |
| +-----------+
+---+ | ^
+----4--->| |<---+ +---1----+
+-------------+--V--+ | | +-V-----------------+
| | |--2-->| |--2-->| | |
| | UDP | | N | | UDP | |
| | |<--3--| |<--3--| | |
| CoAP Client +-----+ | A | +-----+ CoAP Server |
| | |--5-->| |--5-->| | |
| | TCP | | T | | TCP | |
| | |<--6--| |<--6--| | |
+-------------+-----+ +---+ +-----+-------------+
Figure 1: CoAP Client initially accesses CoAP Server over UDP and
then switching to TCP
Figure 1 depicts such a scenario. Step 1 depicts the CoAP Server
registering its transports to a Resource Directory. A CoAP client
uses UDP initially for accessing a CoAP Server in Step 2 and receives
a response in Step 3. Subsequently a CoAP client, residing behind a
NAT, performs a lookup on the Resource Directory in Step 4 to
discover alternative transports offered by the server. Steps 5 and 6
illustrate the client then deciding to use TCP for CoAP messaging
instead of UDP to set up an Observe relationship for a resource at
the CoAP Server, in order to avoid incoming packets containing
resource updates being discarded by the NAT.
2.2. Better resource caching and serving in proxies
Figure 2 outlines a more complex example of intermediate nodes such
as CoAP-based proxies to intelligently cache and respond to CoAP or
HTTP clients with the same resource representation requested over
alternative transports or server endpoints. As with the earlier
example, the CoAP Server registers its transports to a Resource
Directory (This is assumed to be performed beforehand and not
depicted in the figure, for brevity)
In this example, a CoAP over WebSockets client successfully obtains a
response from a CoAP forward proxy to retrieve a resource
representation from an origin server using UDP, by supplying the CoAP
server's endpoint address and resource in a Proxy-URI option. Arrow
1 represents a GET request to "coap+ws://proxy.example.com" which
Silverajan & Ocak Expires May 3, 2018 [Page 5]
Internet-Draft CoAP Protocol Negotiation October 2017
subsequently retrieves the resource from the CoAP server using the
URI "coap://example.org/sensors/temperature", shown as arrow 2.
+---------+
| CoAP+WS | +--------+-------+---+ +-----+---------+
| Client |<-1->| Web | | |<-2->| | |
+---------+ | Socket | CoAP | U | | UDP | CoAP |
+---------+ +--------+ Proxy | D | +-----+ Server |
| HTTP |<-3->| HTTP | | P | | TCP | |
| Client |<-4->| | | | | | |
+---------+ +--------+-------+---+ +-----+---------+
Figure 2: Proxying and returning a resource's alternate cached
representations to multiple clients
Subsequently, assume an HTTP client requests the same resource, but
instead specifies a CoAP over TCP alternative URI instead. Arrow 3
represents this event, where the HTTP client performs a GET request
to "http://proxy.example.com/coap+tcp://example.org/sensors/
temperature". When the proxy receives the request, instead of
immediately retrieving the temperature resource again over TCP, it
first verifies either from the Resource Directory or directly from
the server, whether the cached resource retrieved over UDP is a valid
equivalent representation of the resource requested by the HTTP
client over TCP. Upon confirmation, the proxy is able to supply the
same cached representation to the HTTP client as well (arrow 4).
3. Node Types based on Transport Availability
In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for
devices, in terms of their resource constraints, energy limitations
and communication power. For this document, in addition to these
capabilities, it seems useful to also identify devices based on their
transport capabilities.
Silverajan & Ocak Expires May 3, 2018 [Page 6]
Internet-Draft CoAP Protocol Negotiation October 2017
+-------+----------------------------+
| Name | Transport Availability |
+-------+----------------------------+
| T0 | Single transport |
| | |
| T1 | Multiple transports, with |
| | one or more active at any |
| | point in time |
| | |
| T2 | Multiple active and |
| | persistent transports |
| | at all times |
+-------+----------------------------+
Table 1: Classes of Available Transports
Type T0 nodes possess the capability of exactly 1 type of transport
channel for CoAP, at all times. These include both active and sleepy
nodes, which may choose to perform duty cycling for power saving.
Type T1 nodes possess multiple different transports, and can retrieve
or expose CoAP resources over any or all of these transports.
However, not all transports are constantly active and certain
transport channels and interfaces could be kept in a mostly-off state
for energy-efficiency, such as when using CoAP over SMS.
Type T2 nodes possess more than 1 transport, and multiple transports
are simultaneously active at all times in a persistent manner. CoAP
proxy nodes which allow CoAP endpoints from disparate transports to
communicate with each other, are a good example of this.
4. New Resource Directory Parameters
In order to allow resource interactions between clients and servers
with multiple locations or transports, the registration, update and
lookup interfaces of the CoRE Resource Directory need to be extended.
In this section two new RD parameters, "at" and "tt" are introduced.
Both are optional CoAP features. If supported, they occur at the
granularity level of an origin server, ie. they cannot be applied
selectively on some resources only. When absent, it is assumed that
the server does not support multiple transports or locations.
4.1. The 'at' RD parameter
A CoAP server wishing to advertise its resources over multiple
transports does so by using a new "at" parameter to register a list
of CoAP alternative transport URIs during registration with a
Silverajan & Ocak Expires May 3, 2018 [Page 7]
Internet-Draft CoAP Protocol Negotiation October 2017
Resource Directory. Such a URI would contain the schemes, addresses
as well as any ports or paths at which the server is available.
+-----------+-------+---------------+-------------------------------+
| Name | Query | Validity | Description |
+-----------+-------+---------------+-------------------------------+
| CoAP | at | URI | Comma separated list of URIs |
| Transport | | | (scheme, address, port, and |
| URI List | | | path) available at the server |
+-----------+-------+---------------+-------------------------------+
Table 2: The "at" RD parameter
The "at" parameter extends the Resource Directory's Registration and
Update interfaces.
The following example shows a type T1 endpoint registering its
resources and advertising its ability to use TCP as an alternative
transport:
Req: POST coap:/rd.example.com/rd
?ep=node1&at=coap+tcp://server.example.com,coap+ws://server.example.com:5683/ws/
Content-Format: 40
Payload:
</sensors/temp>;ct=41;rt="temperature-f";if="sensor",
</sensors/door>;ct=41;rt="door";if="sensor"
Res: 2.01 Created
Location: /rd/4521
The next example shows the same endpoint updating its registration
with a new lifetime and the availability of a single alternative
transport for CoAP (in this case WebSockets):
Req: POST /rd/4521?lt=600&at=coap+ws://server.example.com:5683/ws/
Content-Format: 40
Payload:
</sensors/temp>;ct=41;rt="temperature-f";if="sensor",
</sensors/door>;ct=41;rt="door";if="sensor"
Res: 2.04 Changed
Silverajan & Ocak Expires May 3, 2018 [Page 8]
Internet-Draft CoAP Protocol Negotiation October 2017
4.2. The 'tt' RD parameter
A CoAP client wishing to perform a look-up on the Resource Directory
for CoAP servers supporting multiple transports does so by using a
new "tt" parameter to query for CoAP alternative transport URIs.
+-----------+-------+---------------+-------------------------------+
| Name | Query | Validity | Description |
+-----------+-------+---------------+-------------------------------+
| CoAP | tt | | Transport type |
| Transport | | | requested by |
| Type | | | the client |
+-----------+-------+---------------+-------------------------------+
Table 3: The "tt" RD parameter
The "tt" parameter extends the Resource Directory's rd-lookup
interface.
The following example shows a client performing a lookup for
endpoints supporting TCP:
Req: GET /rd-lookup/ep?tt=tcp
Res: 2.05 Content
<coap+tcp://[FDFD::123]:61616>;ep="node5",
<coap+tcp://[FDFD::123]:61616>;ep="node7"
The next example shows a client performing a lookup for all
transports supported by a specific endpoint:
Req: GET /rd-lookup/ep?ep=node5&tt=*
Res: 2.05 Content
<coap+tcp://[FDFD::123]:61616>;ep="node5",
<coap+ws://[FDFD::123]:61616>;ep="node5"
5. CoAP Alternative-Transport Option
The CoAP Alternative-Transport Option can be used by CoAP clients and
CoAP servers in both Request and Response messages in constrained
environments where a CoRE Resource Directory is not present.
Silverajan & Ocak Expires May 3, 2018 [Page 9]
Internet-Draft CoAP Protocol Negotiation October 2017
Figure 3 depicts the properties of the Alternative-Transport Option.
+-----+---+---+---+---+------------------------+--------+--------+----------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+------------------------+--------+--------+----------+
| 66 | | x | - | x | Alternative-Transport | string | 0-1034 | (none) |
+-----+---+---+---+---+------------------------+--------+--------+----------+
C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable
Figure 3: The Alternative-Transport Option
When included in a Request message, this option is used by the client
in 2 possible ways. In the first case, a CoAP client can include the
Option with Length 0 to retrieve all alternative transports from a
CoAP server. In response to the client, the server includes base URI
for each transport in its own Option. In the second case, a CoAP
client can include the Option with a specific value in a CoAP
Request, and the CoAP server returns the base URI(s) for the
specified transport. If the specified transport by a CoAP client
returns multiple results on a CoAP server, the server returns all
base URIs of the transport in the response, each base URI in its own
Option.
A CoAP client can also use this Option to retrieve several transports
at once by including multiple Options in the request to a CoAP
server. If any of the specified transports is supported by the
server, the server returns all base URIs in its own option. There
can be more than 1 result for any of the transports so that each
transport base URI is still included in the response in its own
option.
Figure 4 describes a simple interaction between a client and a
server, in which the client uses an Alternative-Transports Option
with a null value to discover and retrieve all the available
transports from the server, as part of a GET operation to retrieve a
resource representation. The server responds with a CoAP Response
message which contains the resource representation as a payload. In
addition, the server also supplies multiple Alternative-Transport
Options in the message, with each Option containing the base URI for
an available transport. In this case the base URIs returned for TCP-
Silverajan & Ocak Expires May 3, 2018 [Page 10]
Internet-Draft CoAP Protocol Negotiation October 2017
based and WebSocket transports indicate their availability over a
non-standard port.
Client Server
+ |
| GET /temperature |
| Token: 0x64 |
| Alternative-Transport: (null) |
+-------------------------------------->|
| |
| 2.05 Content |
| Token: 0x64 |
| Payload: 21.0 Cel |
| Alternative-Transport: |
| coap+tcp://example.org:5555/ |
| Alternative-Transport: |
| coaps+tcp://example.org:6666/ |
| Alternative-Transport: |
| coap+sms://0015105550101/ |
| Alternative-Transport: |
| coap+ws://example.org:8080/ |
| |
|<--------------------------------------+
| |
Figure 4: Requesting all available alternative transports on the
server, and their locations
Alternatively, a client can also request for the availability of a
specific transport on the server, as shown in Figure 5. Here, the
CoAP Request contains an Alternative-Transport Option with the value
set to request the Base URIs for TCP-based endpoints.
Silverajan & Ocak Expires May 3, 2018 [Page 11]
Internet-Draft CoAP Protocol Negotiation October 2017
Client Server
+ |
| GET /temperature |
| Token: 0x64 |
| Alternative-Transport: tcp |
+-------------------------------------->|
| |
| 2.05 Content |
| Token: 0x64 |
| Payload: 21.0 Cel |
| Alternative-Transport: |
| coap+tcp://example.org:5555/ |
| Alternative-Transport: |
| coaps+tcp://example.org:6666/ |
| |
|<--------------------------------------+
| |
Figure 5: Requesting TCP-based alternative transports on the server,
and their locations
A client may also request a subset of available transports on the
server, by providing multiple Options, each having a single transport
identifier. The server likewise responds to the client request by
supplying the requested transport information. This is shown in
Figure 6.
Silverajan & Ocak Expires May 3, 2018 [Page 12]
Internet-Draft CoAP Protocol Negotiation October 2017
Client Server
+ |
| GET /temperature |
| Token: 0x64 |
| Alternative-Transport: ws |
| Alternative-Transport: sms |
+-------------------------------------->|
| |
| 2.05 Content |
| Token: 0x64 |
| Payload: 21.0 Cel |
| Alternative-Transport: |
| coap+sms://0015105550101/ |
| Alternative-Transport: |
| coap+ws://example.org:8080/ |
| |
|<--------------------------------------+
| |
Figure 6: Requesting WebSocket- and SMS-based alternative transports
on the server, and their locations
6. The 'ol' CoRE Link Attribute
In the majority of cases, it is expected that an origin server would
expose all its resources uniformly on its available transports or
endpoint addresses. Exceptions can exist however, where alternate
locations are made available on a per-resource basis. For such
cases, a new 'ol' ("other locations") attribute is provided. This
attribute is a string used to provide a list of base URIs from which
a specific resource can be reached. Allowing per-resource endpoint
or transport availabilty enables specific functions such as firmware
updates or hardware-specific operations. It also facilities mapping
to and from OCF-based resource-specific endpoint descriptions.
6.1. Using /.well-known/core
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;ct=41;rt="temperature-f";if="sensor",
</sensors/door>;ct=41;rt="door";if="sensor",
</sensors/light>;if="sensor"; ol="http://[FDFD::123]:61616,
coap://server2.example.com"
Silverajan & Ocak Expires May 3, 2018 [Page 13]
Internet-Draft CoAP Protocol Negotiation October 2017
6.2. Using CoRE Resource Directory
Req: POST coap:/rd.example.com/rd
?ep=node1&at=coap+tcp://server.example.com,coap+ws://server.example.com:5683/ws/
Content-Format: 40
Payload:
</sensors/temp>;ct=41;rt="temperature-f";if="sensor",
</sensors/door>;ct=41;rt="door";if="sensor",
</sensors/light>;if="sensor"; ol="http://[FDFD::123]:61616,
coap://server2.example.com"
Res: 2.01 Created
Location: /rd/4521
7. IANA Considerations
This document requests the registration of new RD parameter types
"at" and "tt".
The following entry needs to be added to the CoAP Option Numbers
Registry:
+--------+------------------------+------------------+
| Number | Name | Reference |
+--------+------------------------+------------------+
| 66 | Alternative-Transports | (this document) |
+--------+------------------------+------------------+
8. Security Considerations
When multiple transports, locations and representations are used,
some obvious risks are present both at the origin server as well as
by requesting clients.
When a client is presented with alternate URIs for retrieving
resources, it presents an opportunity for attackers to mount a series
of attacks, either by hijacking communication and masquerading as an
alternate location or by using a man-in-the-middle attack on TLS-
based communication to a server and redirecting traffic to an
alternate location. A malicious or compromised server could also be
used for reflective denial-of-service attacks on innocent third
Silverajan & Ocak Expires May 3, 2018 [Page 14]
Internet-Draft CoAP Protocol Negotiation October 2017
parties. Moreover, clients may obtain web links to alternate URIs
containing weaker security properties than the existing session.
9. Acknowledgements
Thanks to Klaus Hartke for comments and reviewing this draft, and
Teemu Savolainen for initial discussions about protocol negotations
and lifetime values. Zach Shelby provided significant suggestions on
how the Resource Directory can be employed and extended in place of
link attributes and relation types.
10. References
10.1. Normative References
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-11 (work in progress), July 2017.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[WWWArchv1]
http://www.w3.org/TR/webarch/#uri-aliases, "Architecture
of the World Wide Web, Volume One", December 2004.
Appendix A. Change Log
A.1. From -06 to -07
Added support for 'ol' Link attribute
Silverajan & Ocak Expires May 3, 2018 [Page 15]
Internet-Draft CoAP Protocol Negotiation October 2017
A.2. From -05 to -06
Added support for CoAP Alternative-Transports Option
A.3. From -04 to -05
Freshness update
A.4. From -03 to -04
Removed previously introduced link attribute and relation types
Initial foray with Resource Directory support
A.5. From -02 to -03
Added new author
Rewrite of "Introduction" section
Added new Aims Section
Added new Section on Node Types
Introduced "al" Active Lifetime link attribute
Added new Section on Observing transports and resources
Security and IANA considerations sections populated
A.6. From -01 to -02
Freshness update.
A.7. From -00 to -01
Reworked "Introduction" section, added "Rationale", and "Goals"
sections.
Authors' Addresses
Bilhanan Silverajan
Tampere University of Technology
Korkeakoulunkatu 10
FI-33720 Tampere
Finland
Email: bilhanan.silverajan@tut.fi
Silverajan & Ocak Expires May 3, 2018 [Page 16]
Internet-Draft CoAP Protocol Negotiation October 2017
Mert Ocak
Ericsson
Hirsalantie 11
02420 Jorvas
Finland
Email: mert.ocak@ericsson.com
Silverajan & Ocak Expires May 3, 2018 [Page 17]