Constrained RESTful Environments (core)

Constrained RESTful Environments (core)
Constrained RESTful Environments (core)
About
Documents
Meetings
History
Photos
Email expansions
List archive »
WG
Name
Constrained RESTful Environments
Acronym
core
Area
Web and Internet Transport
(wit)
State
Active
Charter
charter-ietf-core-02
Approved
Document dependencies
Document
dependencies
Loading...
Pan and zoom the dependency
graph after the layout settles.
Show legend
Loading...
Additional resources
CoRE landing page
GitHub Repository
Zulip stream
Personnel
Chairs
Carsten Bormann
Jaime Jimenez
Marco Tiloca
Area Director
Mike Bishop
Mailing list
Address
core@ietf.org
To subscribe
Archive
Chat
Room address
Charter for

Working Group
CoRE provides a framework for resource-oriented applications intended to
run on constrained IP networks. A constrained IP network has limited
packet sizes, may exhibit a high degree of packet loss, and may have a
substantial number of devices that may be powered off at any point in
time but periodically "wake up" for brief periods of time. These
networks and the nodes within them are characterized by severe limits on
throughput, available power, and particularly on the complexity that can
be supported with limited code size and limited RAM per node [
RFC 7228
].
More generally, we speak of constrained node networks whenever at least
some of the nodes and networks involved exhibit these characteristics.
Low-Power Wireless Personal Area Networks (LoWPANs) are an example of
this type of network. Constrained networks can occur as part of home and
building automation, energy management, and the Internet of Things.
The CoRE working group will define a framework for a limited class of
applications: those that deal with the manipulation of simple resources
on constrained networks. This includes applications to monitor simple
sensors (e.g. temperature sensors, light switches, and power meters), to
control actuators (e.g. light switches, heating controllers, and door
locks), and to manage devices.
The general architecture consists of nodes on the constrained network,
called Devices, that are responsible for one or more Resources that may
represent sensors, actuators, combinations of values, and/or other
information. Devices send messages to change and query resources on
other Devices. Devices can send notifications about changed resource
values to Devices that have expressed their interest to receive
notification about changes. A Device can also publish or be queried
about its resources. (Typically a single physical host on the network
would have just one Device but a host might represent multiple logical
Devices. The specific terminology to be used here is to be decided by
the working group.) As part of the framework for building these
applications, the working group has defined a Constrained Application
Protocol (CoAP) for the manipulation of Resources on a Device.
CoAP is designed for use between Devices on the same constrained
network, between Devices and general nodes on the Internet, and between
Devices on different constrained networks both joined by an internet.
(CoAP is also being used via other mechanisms, such as SMS on mobile
communication networks.) CoAP targets the type of operating
environments defined in the ROLL and 6Lo working groups which have
additional constraints compared to normal IP networks, but the CoAP
protocol also operates over traditional IP networks.
There also may be proxies that interconnect between other Internet
protocols and the Devices using the CoAP protocol. It is worth noting
that proxy does not have to occur at the boundary between the
constrained network and the more general network, but can be deployed at
various locations in the less-constrained network.
CoAP supports various forms of "caching". Beyond the benefits of
caching already well known from REST, caching can be used to increase
energy savings of low-power nodes by allowing them to be normally-off
RFC 7228
]. For example, a temperature sensor might wake up every five
minutes and send the current temperature to a proxy that has expressed
interest in notifications; when the proxy receives a request over CoAP
or HTTP for that temperature resource, it can respond with the last
notified value (instead of trying to query the Device which may not be
reachable at this time). The working group will continue to evolve this
model to increase its practical applicability.
The working group will perform maintenance on its first four
standards-track specifications:
RFC 6690
RFC 7252
RFC 7641
draft-ietf-core-block
and will continue to evolve the experimental group communications
support (
RFC 7390
). The working group will not develop a reliable
multicast solution.
CoAP today works over UDP and DTLS. The working group will define
transport mappings for alternative transports as required, both IP
(starting with TCP and a secure version over TLS) and non-IP (e.g., SMS,
working with the security area on potentially addressing the security gap); this
includes defining appropriate URI schemes. Continued compatibility with
CoAP over SMS as defined in OMA LWM2M will be considered.
CoRE will continue and complete its work on
draft-ietf-core-resource-directory
, as already partially adopted by OMA
LWM2M. Interoperability with DNS-SD (and the work of the dnssd working
group) will be a primary consideration. The working group will also
work on a specification enabling broker-based publish-subscribe-style
communication over CoAP.
CoRE will work on related data formats, such as alternative
representations of
RFC 6690
link format and
RFC 7390
group communication
information. The working group will complete the SenML specification,
again with consideration to its adoption in OMA LWM2M.
RFC 7252
defines a basic HTTP mapping for CoAP, with further discussion
in draft-ietf-core-http-mapping. This mapping will be evolved and
supported by further documents.
Besides continuing to examine operational and manageability aspects of
the CoAP protocol itself, CoRE will also develop a way to make
RESTCONF-style management functions available via CoAP that is
appropriate for constrained node networks. This will require very close
coordination with NETCONF and other operations and management working
groups. YANG data models will be used for manageability. Note that
the YANG modeling language is not a target for change in
this process, though additional mechanisms that support YANG
modules may be employed in specific cases where significant
performance gains are both attainable and required. The working
group will continue to consider the OMA LWM2M management functions
as a well-accepted alternative form of management and provide
support at the CoAP protocol level where required.
The working group has selected DTLS as the basis for the communications
security in CoAP. CoRE will work with the TLS working group on the
efficiency of this solution. The preferred cipher suites will evolve in
cooperation with the TLS working group and CFRG. The ACE working group
is expected to provide solutions to authorization that may need
complementary elements on the CoRE side. Object security as defined in
JOSE and being adapted to the constrained node network requirements in
COSE also may need additions on the CoRE side.
The working group will coordinate on requirements from many
organizations and SDO. The working group will closely coordinate with
other IETF working groups, particularly of the constrained node networks
cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate
groups in the IETF OPS and Security areas. Work on these subjects, as
well as on interaction models and design patterns (including follow-up
work around the CoRE Interfaces draft) may benefit from close
cooperation with the proposed Thing-to-Thing Research Group.
Milestones
Date
Milestone
Associated documents
2029-12-31
Dec 2029
Corrections and Clarifications for CoAP submitted to IESG for PS
draft-ietf-core-corr-clar
2026-12-31
Dec 2026
CoRE Interfaces submitted to IESG as Informational
draft-ietf-core-interfaces
2026-05-31
May 2026
Abbreviation of well-known URI paths in CoAP submitted to IESG for PS
draft-ietf-core-uri-path-abbrev
2026-03-31
Mar 2026
Constrained RESTful Application Language (CoRAL) submitted to IESG for PS
draft-ietf-core-coral
2025-11-30
Nov 2025
Dynamic Resource Linking for Constrained RESTful Environments submitted to IESG as Informational
draft-ietf-core-dynlink
2025-11-30
Nov 2025
Management over CoAP (YANG Library) submitted to IESG for PS
draft-ietf-core-yang-library
2025-03-31
Mar 2025
Publish-subscribe architecture for CoAP submitted to IESG for PS
draft-ietf-core-coap-pubsub
2025-03-31
Mar 2025
Management over CoAP (COMI) submitted to IESG for PS
draft-ietf-core-comi
2024-11-30
Nov 2024
Conditional Attributes for Constrained RESTful Environments submitted to IESG for PS
draft-ietf-core-conditional-attributes
Done milestones
Date
Milestone
Associated documents
Done
Allocation of SID ranges for PEN holders in YANG-CBOR submitted to IESG as Informational RFC
draft-ietf-core-yang-sid-pen
Done
Update to the IANA CoAP Content-Formats Registration Procedures submitted to IESG for PS
rfc9876 (was draft-ietf-core-cf-reg-update)
Done
DNS over CoAP (DoC) submitted to IESG for PS
rfc9953 (was draft-ietf-core-dns-over-coap)
Done
ALPN ID for CoAP over DTLS submitted to IESG as Informational RFC
rfc9952 (was draft-ietf-core-coap-dtls-alpn)
Done
Constrained Resource Identifiers submitted to IESG for PS
draft-ietf-core-href
Done
Secure group communication for CoAP submitted to IESG for PS
draft-ietf-core-oscore-groupcomm
Done
Group communication for CoAP bis submitted to IESG for PS
draft-ietf-core-groupcomm-bis
Done
Using EDHOC with CoAP and OSCORE submitted to IESG for PS
rfc9668 (was draft-ietf-core-oscore-edhoc)
Done
Creation of IANA registry for CoRE target attributes submitted to IESG as Informational RFC
rfc9423 (was draft-ietf-core-target-attr)
Done
Concise Problem Details For CoAP APIs submitted to IESG for PS
Done
CoRE Resource Directory submitted to IESG for PS
Done
Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS
Done
Object Security for Constrained RESTful Environments (OSCORE)
Done
CBOR Encoding of Data Modeled with YANG submitted to IESG for PS
Done
CoAP over TCP, TLS, and WebSockets submitted to IESG for PS
Done
Representing CoRE Link Collections in JSON submitted to IESG
Done
WG adoption for Management over CoAP
Done
Patch and Fetch Methods for CoAP submitted to IESG for PS
Done
Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG
Done
Blockwise transfers in CoAP submitted to IESG