CoRE Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track October 22, 2012
Expires: April 25, 2013
CoRE Roadmap and Implementation Guide
draft-bormann-core-roadmap-03
Abstract
The CoRE set of protocols, in particular the CoAP protocol, is
defined in draft-ietf-core-coap in conjunction with a number of
specifications that are currently nearing completion. There are also
several dozen more individual Internet-Drafts in various states of
development, with various levels of WG review and interest.
Today, this is simply a bewildering array of documents. Beyond the
main four documents, it is hard to find relevant information and
assess the status of proposals. At the level of Internet-Drafts, the
IETF has only adoption as a WG document to assign status - too crude
an instrument to assess the level of development and standing for
anyone who does not follow the daily proceedings of the WG.
With a more long-term perspective, as additional drafts mature and
existing specifications enter various levels of spec maintenance, the
entirety of these specifications may become harder to understand,
pose specific implementation problems, or be simply inconsistent.
The present guide aims to provide a roadmap to these documents as
well as provide specific advice how to use these specifications in
combination. In certain cases, it may provide clarifications or even
corrections to the specifications referenced.
This guide is intended as a continued work-in-progress, i.e. a long-
lived Internet-Draft, to be updated whenever new information becomes
available and new consensus on how to handle issues is formed.
Similar to the ROHC implementation guide, RFC 4815, it might be
published as an RFC at some future time later in the acceptance curve
of the specifications.
This document does not describe a new protocol or attempt to set a
new standard of any kind - it mostly describes good practice in using
the existing specifications, but it may also document emerging
consensus where a correction needs to be made.
Status of this Memo
Bormann Expires April 25, 2013 [Page 1]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
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 http://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 April 25, 2013.
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
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.
Bormann Expires April 25, 2013 [Page 2]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Main Four . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The CoAP protocol . . . . . . . . . . . . . . . . . . . . 5
2.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Further reading . . . . . . . . . . . . . . . . . . . . . 7
3. Informational Drafts . . . . . . . . . . . . . . . . . . . . . 8
3.1. Implementation . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Multicast and Group Communication . . . . . . . . . . . . 8
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Congestion Control . . . . . . . . . . . . . . . . . . . . 10
4. CoAP over X . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Optional components of CoRE . . . . . . . . . . . . . . . . . 12
5.1. CoAP-misc . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Generalizing Media Types . . . . . . . . . . . . . . . . . 12
5.3. Patience, Leisure, Pledge, or: Timing extensions . . . . . 13
5.4. Extending Observe . . . . . . . . . . . . . . . . . . . . 13
5.5. Service discovery . . . . . . . . . . . . . . . . . . . . 13
5.6. Server discovery, Naming, etc. . . . . . . . . . . . . . . 14
5.7. More support for sleepy nodes . . . . . . . . . . . . . . 14
6. Replaced drafts . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Bormann Expires April 25, 2013 [Page 3]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
1. Introduction
(To be written - for now please see the Abstract.)
1.1. Terminology
This document is a guide. However, it might evolve to make specific
recommendations on how to use standards-track specifications.
Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119. They indicate requirement levels for compliant CoRE
implementations [RFC2119]. Note that these keywords are not only
used where a correction or clarification is intended; the latter are
explicitly identified as such.
The term "byte" is used in its now customary sense as a synonym for
"octet".
Bormann Expires April 25, 2013 [Page 4]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
2. The Main Four
The main component of the CoRE architecture is the Constrained
Application Protocol (CoAP). It aims to provide a RESTful transfer
service, not unlike HTTP, but radically simplified for the use on
constrained devices on constrained networks. REST is the
architectural style that informed the design of HTTP [REST]. The
terms "constrained device" and "constrained network" refer to
limited-capability devices such as sensors operating on networks such
as the IEEE 802.15.4 based 6LoWPAN [RFC4919].
[I-D.ietf-lwig-guidance] provides a more detailed discussion of what
we mean by these terms.
2.1. The CoAP protocol
The CoAP protocol is defined in three specifications:
o [I-D.ietf-core-coap]
o [I-D.ietf-core-block]
o [I-D.ietf-core-observe]
The first specification, [I-D.ietf-core-coap], provides the core
transfer protocol, including the means to provide communication
security using the DTLS protocol [RFC6347] (compare this to the way
[RFC2616] and [RFC2818] define HTTP and HTTPS). The protocol is
structured into a message layer, which provides duplicate detection
and optional message reliability on top of UDP, and a request/
response layer, which provides the usual REST operations GET, PUT,
POST, and DELETE. A highly efficient protocol encoding carries the
4-byte base header, a sequence of _Options_, and the payload (body)
of a message. The main extension points of CoAP are its Options,
similar to the way new header fields are used to extend HTTP.
Since CoAP is a very simple protocol based on UDP, it is limited in
its transfer size by the datagram sizes provided by UDP. As a
further constraint, many constrained networks do not provide good
reliability of delivery once their small frame sizes are exceeded and
the adaptation layer is forced to fragment [WEI]. This may lead to a
practical limitation to payload sizes as small as 64 bytes.
[I-D.ietf-core-block] extends the base CoAP protocol with three
options that enable _blockwise_ transfer, i.e., splitting up a larger
transfer into a sequence of smaller transactions, as well as the
early determination of the overall size of the resource
representation.
In HTTP, transactions are always client initiated, and it is the
Bormann Expires April 25, 2013 [Page 5]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
responsibility of the client to perform GET operations again and
again (polling) if it wants to stay up to date about the status of a
resource. This "pull model" becomes expensive in an environment with
limited power, limited network resources, and nodes that sleep most
of the time. Some more or less savory workarounds have been
developed for HTTP [RFC6202], but, as a new protocol, CoAP can do
better. [I-D.ietf-core-observe] extends the base CoAP protocol with
an option that a client can use to indicate its interest in further
updates from a resource. If the server accepts this option, the
client becomes an _Observer_ of this resource and receives an
asynchronous notification message each time it changes. Each such
notification message is identical in structure to the response to the
initial GET request.
While the "Block" and "Observe" specifications are optional additions
to the CoAP protocol (just as the core specification already defines
14 options most of which will not need to be used in every message),
they together form what is now generally considered to be the CoAP
protocol. All three CoAP specifications are, at the time of this
writing, in the process of being updated based on the comments to the
first Working-Group Last-Call [RFC2418], a prerequisite to submitting
them to the IESG for publication as a Standards-Track RFC. The
specifications, together with link-format (below), have been widely
implemented in highly interoperable implementations: an ETSI
"plugtest" event in March 2012 was attended by 15 organizations with
20 implementations; in over 3000 tests performed only about 6 %
failed.
2.2. Discovery
The fourth specification in the main set now nearing completion does
not extend the CoAP protocol but addresses a different problem.
In the Web, a number of methods for discovery of resources are
common. Initially, Web discovery was just performed by humans based
on an entry resource to a server (e.g., "/index.html"). This
resource then includes links that directly or indirectly allow a
human to reach the other Web resources that make up the Web site.
Web discovery can be performed by machines if standardized interfaces
and resource descriptions are available. Among the component
mechanisms for Web discovery that are standardized in the IETF are
the well-known resource path "/.well-known/..." [RFC5785] and the
HTTP link header [RFC5988]. Several related techniques are in common
use today.
Clearly, in the machine-to-machine environments that will be typical
of CoAP applications, it is important to enable devices to discover
Bormann Expires April 25, 2013 [Page 6]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
each other and their resources. Autonomous devices and embedded
systems necessitate uniform, interoperable resource discovery.
A basic component for this is provided by a standardized description
format for the resources a server provides, the _link-format_.
Unless other methods of discovery are available, CoAP servers should
provide such a description via the well-known URI
"/.well-known/core", available for access via a GET request on that
URI. (More advanced resource discovery schemes might make the same
description available by other means, e.g. by posting it to a
resource directory.)
The description format has been adapted from the format used in the
HTTP link header [RFC5988], which is simple and easy to parse. In
contrast to the HTTP specification, link-format is specified as an
Internet media type (what used to be called "MIME type") and intended
to be carried around in the payload [RFC6690].
[RFC6690] is the first RFC of the CoRE working group.
2.3. Further reading
A recent article provides a more detailed overview over the CoRE
documents nearing completion [SB].
While the specification documents themselves have to go into
meticulous details on every aspect of their protocols, they are the
ultimate reference source and are the recommended reading if this
basic overview is not sufficient.
Bormann Expires April 25, 2013 [Page 7]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
3. Informational Drafts
3.1. Implementation
In the IETF, a separate working group is working on informational
documents concerning guidance in lightweight implementation of
protocols, the LWIG working group. LWIG has several drafts pertinent
here:
[I-D.ietf-lwig-guidance] is the main working document of the WG. It
contains some discussion about CoAP implementation in its section
3.4.2, including the efficient representation of managing duplicate
detection state. [I-D.kovatsch-lwig-class1-coap] contains additional
considerations that, over time, might move into
[I-D.ietf-lwig-guidance].
[I-D.castellani-lwig-coap-separate-responses] contains some examples
for message exchanges, focusing on elaborating exchanges involving
separate responses.
Two drafts show how to build minimal implementations of security
protocols relevant for CoAP: [I-D.tschofenig-lwig-tls-minimal] for
TLS, which is relevant for CoAP's use of DTLS; and
[I-D.kivinen-ipsecme-ikev2-minimal] for IKEv2, the protocol for
setting up IPsec security associations. See also the discussion of
[I-D.hartke-core-codtls] in Section 3.3.
3.2. Multicast and Group Communication
As it is based on UDP, CoAP easily supports the use of IP multicast
to confer messages. However, there are difficult issues around
making the desirable multicast applications actually work well.
This led to an additional milestone on the CoRE charter:
Nov 2012: Using CoAP for group communications to IESG as
Informational
The informational WG draft [I-D.ietf-core-groupcomm] discusses
fundamentals and use cases for group communication with CoAP. In
parts, it is still in an explorative mode and will require additional
investigation before conclusive results become available.
[I-D.dijk-core-groupcomm-misc] gives some additional considerations,
listing requirements, providing some taxonomy, proposing deployment
guidelines, and discussing approaches that are not (yet?) in the
focus of the WG. Its section 5 can serve as an overview over the
status of multicast in constrained node/networks.
Bormann Expires April 25, 2013 [Page 8]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
3.3. Security
Several individual drafts analyze the issues around the security of
constrained devices in constrained networks.
| draft-garcia-core-security | | 2012-03-26 |
| draft-sarikaya-core-sbootstrapping | -05 | 2012-07-10 |
| draft-jennings-core-transitive-trust-enrollment | -01 | 2012-10-13 |
Figure 1
[I-D.garcia-core-security] in particular describes the "Thing
Lifecycle" and discusses resulting architectural considerations.
[I-D.jennings-core-transitive-trust-enrollment] demonstrates a
specific approach to securing the Thing Lifecycle based on defined
roles of security players, including a Manufacturer, an Introducer,
and a Transfer Agent.
Further work around Thing Lifecycles is also expected to occur in the
SOLACE initiative (Smart Object Lifecycle Architecture for
Constrained Environments), with its early mailing list at
solace@ietf.org -- developed after the model of the COMAN initiative
(Management for Constrained Management Networks and Devices,
coman@ietf.org, [I-D.ersue-constrained-mgmt]).
[I-D.hartke-core-codtls] looks specifically into the use of DTLS in
constrained networks. It raises issues that pertain both to the LWIG
and CoRE working groups of the IETF.
Other drafts in this space:
| draft-wang-core-profile-secflag-options | -02 | 2012-10-12 |
Figure 2
3.4. Intermediaries
[I-D.castellani-core-http-mapping] discusses some ideas about what
HTTP/CoAP intermediaries could do beyond the basic mapping defined in
[I-D.ietf-core-coap]. In the IETF83 WG meeting, it was discussed to
evolve this draft into one document describing best practices for
mapping between HTTP and CoAP (beyond what is already described in
[I-D.ietf-core-coap]), and one document that describes usages that
serve as additional useful examples for more advanced forms of
mapping, a first draft is available in
[I-D.castellani-core-advanced-http-mapping].
Bormann Expires April 25, 2013 [Page 9]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
3.5. Congestion Control
[I-D.ietf-core-coap] only defines a very basic congestion control
scheme that is focused on being safe in a wide variety of
applications. Additional documents will define more advanced
congestion control schemes that can provide more optimized
performance in exchange for more implementation complexity and/or a
narrower field of application.
Several drafts are contributing to this active subject of discussion
in the WG:
| draft-bormann-core-congestion-control | -02 | 2012-08-01 |
| draft-bormann-core-cocoa | -00 | 2012-08-13 |
Figure 3
[I-D.greevenbosch-core-minimum-request-interval] proposes adding an
option that allows a server to indicate its desire for some pacing of
the requests sent to it by one client; enabling a form of server load
control.
Bormann Expires April 25, 2013 [Page 10]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
4. CoAP over X
[I-D.becker-core-coap-sms-gprs] shows how to run CoAP over cellular
SMS and in mixed SMS/GPRS environments. This draft optionally makes
use of an SMS-oriented encoding for CoAP that is described in
[I-D.bormann-coap-misc].
[I-D.li-core-coap-payload-length-option] defines a way to indicate
the length of the payload in case the underlying transport does not
provide a suitable definite length indication.
Bormann Expires April 25, 2013 [Page 11]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
5. Optional components of CoRE
Additional sub-protocols are being discussed in the IETF that may
become optional protocols in CoREs.
The present document will track these sub-protocols and be amended
once the sub-protocols reach formal status in the IETF.
Since the WG is cautious in adopting additional work while the main
specifications near completion, none of the additional protocols
proposed have become WG documents yet.
5.1. CoAP-misc
One draft is a little different from the other drafts in this
category: [I-D.bormann-coap-misc] is a running document capturing
CoAP extensions that are in various states of being cooked.
Some of these extensions may finally be adopted for the WG documents
and then vanish from CoAP-misc. For other extensions, we may decide
that they are not very good ideas. Instead of deleting them from
CoAP-misc, they are moved to an appendix. This documents the
approach, the best implementation of that approach that was reached,
and the reasons why it was not adopted. This documentation should
spare the WG and its contributors from the continuous reinvention of
bad ideas.
As of the time of writing, the main body of CoAP-misc is almost
empty, as most urgent developments have found their way into the WG
documents, and many other ideas wait in the "nursery" section of the
document.
5.2. Generalizing Media Types
CoAP defines a registry for combinations of an Internet Media Type
("MIME type") and a Content Encoding (e.g. some form of compression),
enabling its compact encoding of this information in one or two
bytes. Each entry in the registry defines a single, fixed set of
media type parameters (as in ";charset=utf-8"), if any. This does
not work well with media types that rely on more complex combinations
of parameter settings. [I-D.doi-core-parameter-option] proposes to
add an option to carry parameters for media types.
[I-D.fossati-core-multipart-ct] defines a new media type that can
carry multiple embedded representations employing different media
types using a binary type-length-value format.
Bormann Expires April 25, 2013 [Page 12]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
5.3. Patience, Leisure, Pledge, or: Timing extensions
Several proposals intend to extend the amount of information
available during an exchange about the timing requirements of the
participants.
| draft-li-core-coap-patience-option | -01 | 2012-10-22 |
Figure 4
Another discussion is in Appendix B.4 of [I-D.bormann-coap-misc].
The question of whether some of this functionality should be
introduced into the main WG documents now is currently also the
subject of an active issue tracker ticket [CoRE204].
5.4. Extending Observe
5.5. Service discovery
Basic service discovery is defined in [RFC6690]. A JSON
representation of the same information is defined in
[I-D.bormann-core-links-json]. The intention is to make this
information available in an equivalent format that is more accessible
to classic Web servers, both as a file format (Internet media type)
and as a format that can be used in e.g. a JavaScript API.
[I-D.arkko-core-dev-urn] defines a new Uniform Resource Name (URN)
namespace that can be used to provide hardware device identifiers in
resource descriptions.
[I-D.shelby-core-interfaces] provides additional semantics that can
be used to make resource descriptions more directly machine-
interpretable. This ties in to a more general discussion about CoRE
profiles that has only just begun.
[I-D.greevenbosch-core-profile-description] ties into this and
defines a basic JSON format for indicating what CoAP Options and what
Content-Formats (still called media-types there) are available for a
resource.
[I-D.fossati-core-fp-link-format-attribute] defines a link-format
attribute that indicates a certain resource is best reached via a
specific proxy.
Other drafts in this space:
Bormann Expires April 25, 2013 [Page 13]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
| draft-wang-core-profile-secflag-options | -01 | 2012-07-16 |
Figure 5
5.6. Server discovery, Naming, etc.
On the boundary between service and server discovery, resource
directory servers provide a way to collect resource descriptions from
multiple servers into one accessible location.
[I-D.bormann-core-simple-server-discovery] provided a basic way to
discover such servers in a constrained node/network without
necessarily having to resort to multicast. It has been merged into
[I-D.shelby-core-resource-directory], which defines protocol elements
that can be used for setting up such a resource directory.
Additional drafts include:
| draft-he-core-energy-aware-pd | -01 | 2012-07-16 |
| draft-cao-core-pd | -02 | 2012-07-16 |
Figure 6
An attempt to merge mDNS/DNS-SD-based discovery (colloquially known
as zeroconf or Bonjour), including recent approaches to extend these
for constrained networks, into the picture is documented in
[I-D.vanderstok-core-dna].
5.7. More support for sleepy nodes
The basic communication model of CoAP was imported from the Web. This
applies well to some communication requirements in constrained node/
networks, but leaves some other requirements open.
The assumption underlying the current set of WG documents is that the
communication layers below the application provide support functions
for sleeping nodes. Adding support at the application layer might be
able to further reduce the power requirements of "sleepy nodes" that
can sleep most of the time.
[I-D.rahman-core-sleepy-problem-statement] summarizes the overall
problem statement for sleepy nodes without getting into any specific
solution.
A number of drafts aim to extend the CoAP communication model towards
more support for sleepy nodes.
The base CoAP spec [I-D.ietf-core-coap] already provides some
Bormann Expires April 25, 2013 [Page 14]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
rudimentary support of sleepy nodes by supporting caching in
intermediaries: resources from a sleepy node may be available from a
caching proxy (if previously retrieved) even though the node is
asleep. [I-D.ietf-core-observe] enhances this support by enabling
sleepy nodes to update caching intermediaries on their own schedule.
A number of drafts more extensively extend the concept of an
intermediary by introducing an additional kind of server that is
hosting the resources of the sleepy node:
The approach of [I-D.vial-core-mirror-server] is to store the actual
resource representations in a special type of Resource Directory
called the Mirror Server. Communicating devices can then fetch the
resource from the Mirror Server regardless of the state of the sleepy
server. ([I-D.vial-core-mirror-proxy] simply appears to be a
previous version of this draft.)
Similar to the above, the approach of
[I-D.fossati-core-publish-option] is to temporarily delegate
authority of its resources (when it is sleeping) to a proxy server
that is always on.
Also, the approach of [I-D.giacomin-core-sleepy-option] is to define
a proxy that acts as a store-and-forward agent for a sleepy node.
Other drafts introduce a variety of signaling based approaches to
facilitate communicating with sleepy nodes: The approach of
[I-D.castellani-core-alive] is to define a new CoAP message type
(called "Alive") which the sleepy node multicasts to all interested
devices when it wakes up. The approach of [I-D.rahman-core-sleepy]
is to introduce storing of sleep characteristics in the Resource
Directory. Communicating devices can then query the RD to learn the
sleep status of the sleepy node before attempting communications.
Finally, some drafts build on the concept of the Observe mechanism to
help keep track of the sleepy node information. The approach of
[I-D.fossati-core-monitor-option] is to extend the Observe pattern to
handle the scenario when both server and clients are sleepy nodes.
Note that some of the other drafts (e.g.,
[I-D.vial-core-mirror-server], [I-D.rahman-core-sleepy]) include
using/extending the Observe mechanism as part of their overall
approach.
Support for sleepy nodes is currently a very active subject of
discussion in the WG; it is clear that there is a high level of
interest in the WG in addressing application-level support for sleepy
nodes in future specifications.
Bormann Expires April 25, 2013 [Page 15]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
[I-D.arkko-core-cellular] provides a well-founded discussion of
methods for power conservation in CoAP nodes connected via cellular
networks.
Bormann Expires April 25, 2013 [Page 16]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
6. Replaced drafts
Internet-Drafts often get replaced by merged drafts or get promoted
to WG drafts. As the relationships between drafts are not always
accurately captured by the secretariat tools, this table provides a
mapping from current drafts to any previous drafts they are
replacing:
+-----------------------------------+-------------------------------+
| current draft | replaced draft |
+-----------------------------------+-------------------------------+
| [I-D.ietf-core-coap] | draft-shelby-core-coap |
| | |
| [I-D.ietf-core-block] | draft-bormann-core-coap-block |
| | |
| | draft-li-core-coap-size-optio |
| | n |
| | |
| [I-D.ietf-core-observe] | draft-hartke-coap-observe |
| | |
| [RFC6690] | draft-shelby-core-link-format |
| | |
| [I-D.ietf-core-groupcomm] | draft-rahman-core-groupcomm |
| | |
| [I-D.becker-core-coap-sms-gprs] | draft-li-core-coap-over-sms |
| | |
| [I-D.vanderstok-core-dna] | draft-vanderstok-core-bc |
| | |
| [I-D.shelby-core-resource-directo | draft-bormann-core-simple-ser |
| ry] | ver-discovery |
| | |
| [I-D.greevenbosch-core-minimum-re | draft-greevenbosch-core-block |
| quest-interval] | -minimum-time |
+-----------------------------------+-------------------------------+
Note that draft-scim-core-schema is just named against the naming
conventions and actually unrelated to the CoRE working group.
Bormann Expires April 25, 2013 [Page 17]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
7. IANA Considerations
This document has no actions for IANA.
Bormann Expires April 25, 2013 [Page 18]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
8. Security Considerations
(None so far; this section will certainly grow as additional security
considerations beyond those listed in the base specifications become
known.)
Bormann Expires April 25, 2013 [Page 19]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
9. Acknowledgements
(The concept for this document is borrowed from [RFC4815], which was
invented by Lars-Erik Jonsson. Thanks!)
Akbar Rahman contributed text to this roadmap.
Bormann Expires April 25, 2013 [Page 20]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
10. References
10.1. Normative References
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-10 (work in progress), October 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-12 (work in progress), October 2012.
[I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP",
draft-ietf-core-observe-06 (work in progress),
September 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
10.2. Informative References
[CoRE204] "Introduce a minimal version of Pledge", CoRE ticket #204,
<http://trac.tools.ietf.org/wg/core/trac/ticket/204>.
[I-D.arkko-core-cellular]
Arkko, J., Eriksson, A., and A. Keranen, "Building Power-
Efficient CoAP Devices for Cellular Networks",
draft-arkko-core-cellular-00 (work in progress),
July 2012.
[I-D.arkko-core-dev-urn]
Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
Names for Device Identifiers", draft-arkko-core-dev-urn-03
(work in progress), July 2012.
[I-D.becker-core-coap-sms-gprs]
Bormann Expires April 25, 2013 [Page 21]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
Becker, M., Li, K., Kuladinithi, K., and T. Poetsch,
"Transport of CoAP over SMS, USSD and GPRS",
draft-becker-core-coap-sms-gprs-02 (work in progress),
July 2012.
[I-D.bormann-coap-misc]
Bormann, C. and K. Hartke, "Miscellaneous additions to
CoAP", draft-bormann-coap-misc-21 (work in progress),
October 2012.
[I-D.bormann-core-links-json]
Bormann, C., "Representing CoRE Link Collections in JSON",
draft-bormann-core-links-json-01 (work in progress),
July 2012.
[I-D.bormann-core-simple-server-discovery]
Bormann, C., "CoRE Simple Server Discovery",
draft-bormann-core-simple-server-discovery-01 (work in
progress), March 2012.
[I-D.castellani-core-advanced-http-mapping]
Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Best Practices for HTTP-CoAP Mapping
Implementation",
draft-castellani-core-advanced-http-mapping-00 (work in
progress), July 2012.
[I-D.castellani-core-alive]
Castellani, A. and S. Loreto, "CoAP Alive Message",
draft-castellani-core-alive-00 (work in progress),
March 2012.
[I-D.castellani-core-http-mapping]
Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Best Practices for HTTP-CoAP Mapping
Implementation", draft-castellani-core-http-mapping-05
(work in progress), July 2012.
[I-D.castellani-lwig-coap-separate-responses]
Castellani, A., "Learning CoAP separate responses by
examples",
draft-castellani-lwig-coap-separate-responses-00 (work in
progress), March 2012.
[I-D.dijk-core-groupcomm-misc]
Dijk, E. and A. Rahman, "Miscellaneous CoAP Group
Communication Topics", draft-dijk-core-groupcomm-misc-02
(work in progress), October 2012.
Bormann Expires April 25, 2013 [Page 22]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
[I-D.doi-core-parameter-option]
Doi, Y. and K. Lynn, "CoAP Content-Type Parameter Option",
draft-doi-core-parameter-option-01 (work in progress),
October 2012.
[I-D.ersue-constrained-mgmt]
Ersue, M., Romascanu, D., and J. Schoenwaelder,
"Management of Networks with Constrained Devices: Use
Cases and Requirements", draft-ersue-constrained-mgmt-02
(work in progress), October 2012.
[I-D.fossati-core-fp-link-format-attribute]
Fossati, T. and S. Loreto, "Resource Discovery through
Proxies", draft-fossati-core-fp-link-format-attribute-00
(work in progress), July 2012.
[I-D.fossati-core-monitor-option]
Fossati, T., Giacomin, P., and S. Loreto, "Monitor Option
for CoAP", draft-fossati-core-monitor-option-00 (work in
progress), July 2012.
[I-D.fossati-core-multipart-ct]
Fossati, T., "Multipart Content Format Encoding for CoAP",
draft-fossati-core-multipart-ct-01 (work in progress),
October 2012.
[I-D.fossati-core-publish-option]
Fossati, T., Giacomin, P., and S. Loreto, "Publish Option
for CoAP", draft-fossati-core-publish-option-00 (work in
progress), July 2012.
[I-D.garcia-core-security]
Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-04 (work
in progress), March 2012.
[I-D.giacomin-core-sleepy-option]
Fossati, T., Giacomin, P., Loreto, S., and M. Rossini,
"Sleepy Option for CoAP",
draft-giacomin-core-sleepy-option-00 (work in progress),
February 2012.
[I-D.greevenbosch-core-minimum-request-interval]
Greevenbosch, B., "CoAP Minimum Request Interval",
draft-greevenbosch-core-minimum-request-interval-00 (work
in progress), September 2012.
Bormann Expires April 25, 2013 [Page 23]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
[I-D.greevenbosch-core-profile-description]
Greevenbosch, B., Hoebeke, J., and I. Ishaq, "CoAP Profile
Description Format",
draft-greevenbosch-core-profile-description-01 (work in
progress), October 2012.
[I-D.hartke-core-codtls]
Hartke, K. and O. Bergmann, "Datagram Transport Layer
Security in Constrained Environments",
draft-hartke-core-codtls-02 (work in progress), July 2012.
[I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-03 (work in progress),
October 2012.
[I-D.ietf-lwig-guidance]
Bormann, C., "Guidance for Light-Weight Implementations of
the Internet Protocol Suite", draft-ietf-lwig-guidance-02
(work in progress), August 2012.
[I-D.jennings-core-transitive-trust-enrollment]
Jennings, C., "Transitive Trust Enrollment for Constrained
Devices",
draft-jennings-core-transitive-trust-enrollment-01 (work
in progress), October 2012.
[I-D.kivinen-ipsecme-ikev2-minimal]
Kivinen, T., "Minimal IKEv2",
draft-kivinen-ipsecme-ikev2-minimal-01 (work in progress),
October 2012.
[I-D.kovatsch-lwig-class1-coap]
Kovatsch, M., "Implementing CoAP for Class 1 Devices",
draft-kovatsch-lwig-class1-coap-00 (work in progress),
October 2012.
[I-D.li-core-coap-payload-length-option]
Li, K. and X. Sun, "CoAP Payload-Length Option Extension",
draft-li-core-coap-payload-length-option-00 (work in
progress), May 2012.
[I-D.rahman-core-sleepy]
Rahman, A., "Enhanced Sleepy Node Support for CoAP",
draft-rahman-core-sleepy-01 (work in progress),
October 2012.
[I-D.rahman-core-sleepy-problem-statement]
Bormann Expires April 25, 2013 [Page 24]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
Rahman, A., Fossati, T., Loreto, S., and M. Vial, "Sleepy
Devices in CoAP - Problem Statement",
draft-rahman-core-sleepy-problem-statement-01 (work in
progress), October 2012.
[I-D.shelby-core-interfaces]
Shelby, Z. and M. Vial, "CoRE Interfaces",
draft-shelby-core-interfaces-03 (work in progress),
July 2012.
[I-D.shelby-core-resource-directory]
Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource
Directory", draft-shelby-core-resource-directory-04 (work
in progress), July 2012.
[I-D.tschofenig-lwig-tls-minimal]
Tschofenig, H. and J. Gilger, "A Minimal (Datagram)
Transport Layer Security Implementation",
draft-tschofenig-lwig-tls-minimal-01 (work in progress),
October 2012.
[I-D.vanderstok-core-dna]
Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery,
Naming, and Addressing", draft-vanderstok-core-dna-02
(work in progress), July 2012.
[I-D.vial-core-mirror-proxy]
Vial, M., "CoRE Mirror Server",
draft-vial-core-mirror-proxy-01 (work in progress),
July 2012.
[I-D.vial-core-mirror-server]
Vial, M., "CoRE Mirror Server",
draft-vial-core-mirror-server-00 (work in progress),
October 2012.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine, 2000, <http://
www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Bormann Expires April 25, 2013 [Page 25]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer,
"RObust Header Compression (ROHC): Corrections and
Clarifications to RFC 3095", RFC 4815, February 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202,
April 2011.
[SB] Bormann, C., Castellani, A., and Z. Shelby, "CoAP: An
Application Protocol for Billions of Tiny Internet Nodes",
DOI 10.1109/MIC.2012.29, 2012.
[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
Internet", ISBN 9780470747995, 2009.
Bormann Expires April 25, 2013 [Page 26]
Internet-Draft CoRE Roadmap and Implementation Guide October 2012
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Bormann Expires April 25, 2013 [Page 27]