draft-ietf-core-coral-00.txt   draft-ietf-core-coral-01.txt 
Thing-to-Thing Research Group K. Hartke CoRE Working Group K. Hartke
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track August 29, 2019 Intended status: Standards Track November 4, 2019
Expires: March 1, 2020 Expires: May 7, 2020
The Constrained RESTful Application Language (CoRAL) The Constrained RESTful Application Language (CoRAL)
draft-ietf-core-coral-00 draft-ietf-core-coral-01
Abstract Abstract
The Constrained RESTful Application Language (CoRAL) defines a data The Constrained RESTful Application Language (CoRAL) defines a data
model and interaction model as well as two specialized serialization model and interaction model as well as two specialized serialization
formats for the description of typed connections between resources on formats for the description of typed connections between resources on
the Web ("links"), possible operations on such resources ("forms"), the Web ("links"), possible operations on such resources ("forms"),
as well as simple resource metadata. as well as simple resource metadata.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 1, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Data and Interaction Model . . . . . . . . . . . . . . . . . 4 2. Data and Interaction Model . . . . . . . . . . . . . . . . . 4
2.1. Browsing Context . . . . . . . . . . . . . . . . . . . . 4 2.1. Browsing Context . . . . . . . . . . . . . . . . . . . . 5
2.2. Documents . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Documents . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Form Fields . . . . . . . . . . . . . . . . . . . . . 7 2.5. Form Fields . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Embedded Representations . . . . . . . . . . . . . . . . 7 2.6. Embedded Representations . . . . . . . . . . . . . . . . 7
2.6. Navigation . . . . . . . . . . . . . . . . . . . . . . . 7 2.7. Navigation . . . . . . . . . . . . . . . . . . . . . . . 8
2.7. History Traversal . . . . . . . . . . . . . . . . . . . . 9 2.8. History Traversal . . . . . . . . . . . . . . . . . . . . 9
3. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 10 3.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Documents . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Documents . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4. Embedded Representations . . . . . . . . . . . . . . 12 3.1.4. Embedded Representations . . . . . . . . . . . . . . 12
3.1.5. Directives . . . . . . . . . . . . . . . . . . . . . 12 3.1.5. Directives . . . . . . . . . . . . . . . . . . . . . 13
3.2. Dictionaries . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Dictionaries . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Dictionary References . . . . . . . . . . . . . . . . 13 3.2.1. Dictionary References . . . . . . . . . . . . . . . . 13
3.2.2. Media Type Parameter . . . . . . . . . . . . . . . . 14 3.2.2. Media Type Parameter . . . . . . . . . . . . . . . . 14
4. Textual Format . . . . . . . . . . . . . . . . . . . . . . . 14 4. Textual Format . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Lexical Structure . . . . . . . . . . . . . . . . . . . . 15 4.1. Lexical Structure . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Line Terminators . . . . . . . . . . . . . . . . . . 15 4.1.1. Line Terminators . . . . . . . . . . . . . . . . . . 15
4.1.2. White Space . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. White Space . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. Comments . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3. Comments . . . . . . . . . . . . . . . . . . . . . . 15
4.1.4. Identifiers . . . . . . . . . . . . . . . . . . . . . 15 4.1.4. Identifiers . . . . . . . . . . . . . . . . . . . . . 16
4.1.5. IRIs and IRI References . . . . . . . . . . . . . . . 16 4.1.5. IRIs and IRI References . . . . . . . . . . . . . . . 16
4.1.6. Literals . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6. Literals . . . . . . . . . . . . . . . . . . . . . . 16
4.1.7. Punctuators . . . . . . . . . . . . . . . . . . . . . 20 4.1.7. Punctuators . . . . . . . . . . . . . . . . . . . . . 20
4.2. Syntactic Structure . . . . . . . . . . . . . . . . . . . 20 4.2. Syntactic Structure . . . . . . . . . . . . . . . . . . . 20
4.2.1. Documents . . . . . . . . . . . . . . . . . . . . . . 20 4.2.1. Documents . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.4. Embedded Representations . . . . . . . . . . . . . . 22 4.2.4. Embedded Representations . . . . . . . . . . . . . . 23
4.2.5. Directives . . . . . . . . . . . . . . . . . . . . . 23 4.2.5. Directives . . . . . . . . . . . . . . . . . . . . . 23
5. Usage Considerations . . . . . . . . . . . . . . . . . . . . 24 5. Usage Considerations . . . . . . . . . . . . . . . . . . . . 24
5.1. Specifying CoRAL-based Applications . . . . . . . . . . . 24 5.1. Specifying CoRAL-based Applications . . . . . . . . . . . 24
5.1.1. Application Interfaces . . . . . . . . . . . . . . . 24 5.1.1. Application Interfaces . . . . . . . . . . . . . . . 25
5.1.2. Resource Identifiers . . . . . . . . . . . . . . . . 25 5.1.2. Resource Identifiers . . . . . . . . . . . . . . . . 25
5.1.3. Implementation Limits . . . . . . . . . . . . . . . . 25 5.1.3. Implementation Limits . . . . . . . . . . . . . . . . 26
5.2. Minting Vocabulary . . . . . . . . . . . . . . . . . . . 26 5.2. Minting Vocabulary . . . . . . . . . . . . . . . . . . . 26
5.3. Expressing Registered Link Relation Types . . . . . . . . 27 5.3. Expressing Registered Link Relation Types . . . . . . . . 27
5.4. Expressing Simple RDF Statements . . . . . . . . . . . . 27 5.4. Expressing Simple RDF Statements . . . . . . . . . . . . 28
5.5. Expressing Natural Language Texts . . . . . . . . . . . . 27 5.5. Expressing Natural Language Texts . . . . . . . . . . . . 28
5.6. Embedding CoRAL in CBOR Data . . . . . . . . . . . . . . 28 5.6. Embedding CoRAL in CBOR Data . . . . . . . . . . . . . . 29
5.7. Submitting CoRAL Documents . . . . . . . . . . . . . . . 28 5.7. Submitting CoRAL Documents . . . . . . . . . . . . . . . 29
5.7.1. PUT Requests . . . . . . . . . . . . . . . . . . . . 28 5.7.1. PUT Requests . . . . . . . . . . . . . . . . . . . . 29
5.7.2. POST Requests . . . . . . . . . . . . . . . . . . . . 29 5.7.2. POST Requests . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 5.8. Returning CoRAL Documents . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5.8.1. Success Responses . . . . . . . . . . . . . . . . . . 30
7.1. Media Type "application/coral+cbor" . . . . . . . . . . . 31 5.8.2. Error Responses . . . . . . . . . . . . . . . . . . . 30
7.2. Media Type "text/coral" . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.3. CoAP Content Formats . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.4. CBOR Tag . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. Media Type "application/coral+cbor" . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.2. Media Type "text/coral" . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 34 7.3. CoAP Content Formats . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . 36 7.4. CBOR Tag . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Core Vocabulary . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 35
A.2. Collections . . . . . . . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . 37
A.3. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Core Vocabulary . . . . . . . . . . . . . . . . . . 39
A.4. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Default Dictionary . . . . . . . . . . . . . . . . . 42 A.2. Collections . . . . . . . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 A.3. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 A.4. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Default Dictionary . . . . . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The Constrained RESTful Application Language (CoRAL) is a language The Constrained RESTful Application Language (CoRAL) is a language
for the description of typed connections between resources on the Web for the description of typed connections between resources on the Web
("links"), possible operations on such resources ("forms"), as well ("links"), possible operations on such resources ("forms"), as well
as simple resource metadata. as simple resource metadata.
CoRAL is intended for driving automated software agents that navigate CoRAL is intended for driving automated software agents that navigate
a Web application based on a standardized vocabulary of link relation a Web application based on a standardized vocabulary of link relation
skipping to change at page 7, line 5 skipping to change at page 7, line 11
For example, form fields can instruct the agent to include a payload For example, form fields can instruct the agent to include a payload
or certain headers in the request that must match the specifications or certain headers in the request that must match the specifications
of the form fields. of the form fields.
A form can occur as a top-level element in a document or as a nested A form can occur as a top-level element in a document or as a nested
element within a link. When a form occurs as a top-level element, element within a link. When a form occurs as a top-level element,
the form context implicitly is the document's retrieval context. the form context implicitly is the document's retrieval context.
When a form occurs nested within a link, the form context is the link When a form occurs nested within a link, the form context is the link
target of the enclosing link. target of the enclosing link.
2.4.1. Form Fields 2.5. Form Fields
Form fields provide further instructions to agents for constructing a Form fields provide further instructions to agents for constructing a
request. request.
For example, a form field could identify one or more data items that For example, a form field could identify one or more data items that
need to be included in the request payload or reference another need to be included in the request payload or reference another
resource (such as a schema) that describes the structure of the resource (such as a schema) that describes the structure of the
payload. A form field could also provide other kinds of information, payload. A form field could also provide other kinds of information,
such as acceptable media types for the payload or expected request such as acceptable media types for the payload or expected request
headers. Form fields may be specific to the protocol used for headers. Form fields may be specific to the protocol used for
skipping to change at page 7, line 29 skipping to change at page 7, line 35
value_. value_.
The form field type identifies the semantics of the form field. Form The form field type identifies the semantics of the form field. Form
field types are denoted like link relation types and operation types field types are denoted like link relation types and operation types
by an IRI. by an IRI.
The form field value can be either a URI reference, a Boolean value, The form field value can be either a URI reference, a Boolean value,
an integer, a floating-point number, a date/time value, a byte an integer, a floating-point number, a date/time value, a byte
string, or a text string. string, or a text string.
2.5. Embedded Representations 2.6. Embedded Representations
When a document contains links to many resources and an agent needs a When a document contains links to many resources and an agent needs a
representation of each link target, it may be inefficient to retrieve representation of each link target, it may be inefficient to retrieve
each of these representations individually. To alleviate this, each of these representations individually. To alleviate this,
documents can directly embed representations of resources. documents can directly embed representations of resources.
An _embedded representation_ consists of a sequence of bytes, labeled An _embedded representation_ consists of a sequence of bytes, labeled
with _representation metadata_. with _representation metadata_.
An embedded representation may be a full, partial, or inconsistent An embedded representation may be a full, partial, or inconsistent
version of the representation served from the URI of the resource. version of the representation served from the URI of the resource.
An embedded representation can occur as a top-level element in a An embedded representation can occur as a top-level element in a
document or as a nested element within a link. When it occurs as a document or as a nested element within a link. When it occurs as a
top-level element, it provides an alternate representation of the top-level element, it provides an alternate representation of the
document's retrieval context. When it occurs nested within a link, document's retrieval context. When it occurs nested within a link,
it provides a representation of link target of the enclosing link. it provides a representation of link target of the enclosing link.
2.6. Navigation 2.7. Navigation
An agent begins interacting with an application by performing a GET An agent begins interacting with an application by performing a GET
request on an _entry point URI_. The entry point URI is the only URI request on an _entry point URI_. The entry point URI is the only URI
an agent is expected to know before interacting with an application. an agent is expected to know before interacting with an application.
From there, the agent is expected to make all requests by following From there, the agent is expected to make all requests by following
links and submitting forms provided by the server in responses. The links and submitting forms provided by the server in responses. The
entry point URI can be obtained by manual configuration or through entry point URI can be obtained by manual configuration or through
some discovery process. some discovery process.
If dereferencing the entry point URI yields a CoRAL document (or any If dereferencing the entry point URI yields a CoRAL document (or any
other representation that implements the CoRAL data and interaction other representation that implements the CoRAL data and interaction
model), then the agent makes this document the active representation model), then the agent makes this document the active representation
in the browsing context and proceeds as follows: in the browsing context and proceeds as follows:
skipping to change at page 9, line 22 skipping to change at page 9, line 28
8. The agent _updates the browsing context_ by making the (embedded 8. The agent _updates the browsing context_ by making the (embedded
or received) representation the active representation. or received) representation the active representation.
9. Finally, the agent processes the representation according to the 9. Finally, the agent processes the representation according to the
semantics of the content type. If the representation is a CoRAL semantics of the content type. If the representation is a CoRAL
document (or any other representation that implements the CoRAL document (or any other representation that implements the CoRAL
data and interaction model), this means the agent has the choice data and interaction model), this means the agent has the choice
of what to do next again -- and the cycle repeats. of what to do next again -- and the cycle repeats.
2.7. History Traversal 2.8. History Traversal
A browsing context MAY entail a _session history_ that lists the A browsing context MAY entail a _session history_ that lists the
resource representations that the agent has processed, is processing, resource representations that the agent has processed, is processing,
or will process. or will process.
An entry in the session history consists of a resource representation An entry in the session history consists of a resource representation
and the request URI that was used to retrieve the representation. and the request URI that was used to retrieve the representation.
New entries are added to the session history as the agent navigates New entries are added to the session history as the agent navigates
from resource to resource. from resource to resource.
skipping to change at page 27, line 30 skipping to change at page 28, line 9
lowercased, as per Section 3.3 of RFC 8288 [RFC8288]. lowercased, as per Section 3.3 of RFC 8288 [RFC8288].
(The convention of appending the link relation types to the prefix (The convention of appending the link relation types to the prefix
"http://www.iana.org/assignments/relation/" to form IRIs is adopted "http://www.iana.org/assignments/relation/" to form IRIs is adopted
from Atom [RFC4287]; see also Appendix A.2 of RFC 8288 [RFC8288].) from Atom [RFC4287]; see also Appendix A.2 of RFC 8288 [RFC8288].)
5.4. Expressing Simple RDF Statements 5.4. Expressing Simple RDF Statements
An RDF statement [W3C.REC-rdf11-concepts-20140225] says that some An RDF statement [W3C.REC-rdf11-concepts-20140225] says that some
relationship, indicated by a predicate, holds between two resources. relationship, indicated by a predicate, holds between two resources.
RDF predicates can therefore be good source for vocabulary to provide Existing RDF vocabularies can therefore be good source for link
resource metadata. For example, a CoRAL document could use the FOAF relation types that describe resource metadata. For example, a CoRAL
vocabulary [FOAF] to describe the person or software that made it: document could use the FOAF vocabulary [FOAF] to describe the person
or software that made it:
#using rdf = <http://www.w3.org/1999/02/22-rdf-syntax-ns#> #using rdf = <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
#using foaf = <http://xmlns.com/foaf/0.1/> #using foaf = <http://xmlns.com/foaf/0.1/>
foaf:maker null { foaf:maker null {
rdf:type <http://xmlns.com/foaf/0.1/Person> rdf:type <http://xmlns.com/foaf/0.1/Person>
foaf:familyName "Hartke" foaf:familyName "Hartke"
foaf:givenName "Klaus" foaf:givenName "Klaus"
foaf:mbox <mailto:klaus.hartke@ericsson.com> foaf:mbox <mailto:klaus.hartke@ericsson.com>
} }
skipping to change at page 29, line 13 skipping to change at page 29, line 45
a success response. a success response.
An origin server SHOULD verify that a submitted CoRAL document is An origin server SHOULD verify that a submitted CoRAL document is
consistent with any constraints the server has for the target consistent with any constraints the server has for the target
resource. When a document is inconsistent with the target resource, resource. When a document is inconsistent with the target resource,
the origin server SHOULD either make it consistent (e.g., by removing the origin server SHOULD either make it consistent (e.g., by removing
inconsistent elements) or respond with an appropriate error message inconsistent elements) or respond with an appropriate error message
containing sufficient information to explain why the document is containing sufficient information to explain why the document is
unsuitable. unsuitable.
The retrieval context of a CoRAL document in a PUT is the request URI The retrieval context and the base URI of a CoRAL document in a PUT
of the request. are the request URI of the request.
5.7.2. POST Requests 5.7.2. POST Requests
A POST request with a CoRAL document enclosed in the request payload A POST request with a CoRAL document enclosed in the request payload
requests that the target resource process the CoRAL document requests that the target resource process the CoRAL document
according to the resource's own specific semantics. according to the resource's own specific semantics.
The retrieval context of a CoRAL document in a POST is the request The retrieval context of a CoRAL document in a POST is an unspecified
URI of the request. URI. The base URI of the document is the request URI of the request.
5.8. Returning CoRAL Documents
In a response, the meaning of a CoRAL document changes depending on
the request method and the response status code. For example, a
CoRAL document in a successful response to a GET represents the
current state of the target resource, whereas a CoRAL document in a
successful response to a POST might represent either the processing
result or the new resource state. A CoRAL document in an error
response represents the error condition, usually describing the error
state and what next steps are suggested for resolving it.
5.8.1. Success Responses
Success responses have a response status code that indicates that the
client's request was successfully received, understood, and accepted.
When the representation in a success response does not describe the
state of the target resource, it describes result of processing the
request.
For example, when a request has been fulfilled and has resulted in
one or more new resources being created, a CoRAL document in the
response can link to and describe the resource(s) created.
The retrieval context of a CoRAL document representing a processing
result is an unspecified URI that refers to the processing result
itself. The base URI of the document is the request URI of the
request.
5.8.2. Error Responses
Error response have a response status code that indicates that either
the request cannot be fulfilled or the server failed to fulfill an
apparently valid request. A representation in an error response
describes the error condition.
The retrieval context of such a CoRAL document representing an error
condition is an unspecified URI that refers to the error condition
itself. The base URI of the document is the request URI of the
request.
6. Security Considerations 6. Security Considerations
Parsers of CoRAL documents must operate on input that is assumed to Parsers of CoRAL documents must operate on input that is assumed to
be untrusted. This means that parsers MUST fail gracefully in the be untrusted. This means that parsers MUST fail gracefully in the
face of malicious inputs (e.g., inputs not adhering to the data face of malicious inputs (e.g., inputs not adhering to the data
structure). Additionally, parsers MUST be prepared to deal with structure). Additionally, parsers MUST be prepared to deal with
resource exhaustion (e.g., resulting from the allocation of big data resource exhaustion (e.g., resulting from the allocation of big data
items) or exhaustion of the call stack (stack overflow). items) or exhaustion of the call stack (stack overflow).
CoRAL documents intentionally do not feature the equivalent of XML CoRAL serializations intentionally do not feature the equivalent of
entity references as to preclude the whole class of exponential XML XML entity references as to preclude the whole class of attacks
entity expansion ("billion laughs") [CAPEC-197] and improper XML relating to these, such as exponential XML entity expansion ("billion
external entity [CAPEC-201] attacks. laughs") [CAPEC-197] and malicious XML entity linking [CAPEC-201].
Implementers of the CoRAL binary format need to consider the security Implementers of the CoRAL binary format need to consider the security
aspects of processing CBOR with the restrictions described in aspects of processing CBOR with the restrictions described in
Section 3. Notably, different number representations for the same Section 3. Notably, different number representations for the same
numeric value are not equivalent in the CoRAL binary format. See numeric value are not equivalent in the CoRAL binary format. See
Section 8 of RFC 7049 [RFC7049] for security considerations relating Section 8 of RFC 7049 [RFC7049] for security considerations relating
to CBOR. to CBOR.
Implementers of the CoRAL textual format need to consider the Implementers of the CoRAL textual format need to consider the
security aspects of handling Unicode input. See the Unicode Standard security aspects of handling Unicode input. See the Unicode Standard
skipping to change at page 34, line 24 skipping to change at page 35, line 39
[[NOTE TO RFC EDITOR: Please replace all occurrences of "TBD6" in [[NOTE TO RFC EDITOR: Please replace all occurrences of "TBD6" in
this document with the code point assigned by IANA.]] this document with the code point assigned by IANA.]]
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-core-href] [I-D.ietf-core-href]
Hartke, K., "Constrained Resource Identifiers", draft- Hartke, K., "Constrained Resource Identifiers", draft-
ietf-core-href-00 (work in progress), August 2019. ietf-core-href-01 (work in progress), November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
skipping to change at page 36, line 23 skipping to change at page 37, line 37
<http://unicode.org/reports/tr31/>. <http://unicode.org/reports/tr31/>.
[UNICODE-UAX36] [UNICODE-UAX36]
The Unicode Consortium, "Unicode Standard Annex #36: The Unicode Consortium, "Unicode Standard Annex #36:
Unicode Security Considerations", Unicode Security Considerations",
<http://unicode.org/reports/tr36/>. <http://unicode.org/reports/tr36/>.
8.2. Informative References 8.2. Informative References
[CAPEC-197] [CAPEC-197]
MITRE, "CAPEC-197: XML Entity Expansion", July 2018, MITRE, "CAPEC-197: XML Entity Expansion", September 2019,
<https://capec.mitre.org/data/definitions/197.html>. <https://capec.mitre.org/data/definitions/197.html>.
[CAPEC-201] [CAPEC-201]
MITRE, "CAPEC-201: XML Entity Linking", July 2018, MITRE, "CAPEC-201: XML Entity Linking", September 2019,
<https://capec.mitre.org/data/definitions/201.html>. <https://capec.mitre.org/data/definitions/201.html>.
[FOAF] Brickley, D. and L. Miller, "FOAF Vocabulary Specification [FOAF] Brickley, D. and L. Miller, "FOAF Vocabulary Specification
0.99", January 2014, 0.99", January 2014,
<http://xmlns.com/foaf/spec/20140114.html>. <http://xmlns.com/foaf/spec/20140114.html>.
[HAL] Kelly, M., "JSON Hypertext Application Language", draft-
kelly-json-hal-08 (work in progress), May 2016.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <https://www.rfc-editor.org/info/rfc4287>. December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010, RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>. <https://www.rfc-editor.org/info/rfc5789>.
[RFC6573] Amundsen, M., "The Item and Collection Link Relations", [RFC6573] Amundsen, M., "The Item and Collection Link Relations",
RFC 6573, DOI 10.17487/RFC6573, April 2012, RFC 6573, DOI 10.17487/RFC6573, April 2012,
skipping to change at page 42, line 34 skipping to change at page 44, line 7
| 10 | <http://coreapps.org/coap#method> | | 10 | <http://coreapps.org/coap#method> |
| 11 | <http://coreapps.org/base#direction> | | 11 | <http://coreapps.org/base#direction> |
| 12 | "ltr" | | 12 | "ltr" |
| 13 | "rtl" | | 13 | "rtl" |
+-----+-------------------------------------------------------+ +-----+-------------------------------------------------------+
Table 2: Default Dictionary Table 2: Default Dictionary
Acknowledgements Acknowledgements
Thanks to Christian Amsuess, Carsten Bormann, Jaime Jimenez, CoRAL is heavily inspired by Mike Kelly's JSON Hypertext Application
Sebastian Kaebisch, Ari Keranen, Michael Koster, Matthias Kovatsch, Language [HAL].
Jim Schaad, and Niklas Widell for helpful comments and discussions
that have shaped the document. This document has benefited greatly from discussions and reviews of
the CoRAL design team:
Christian Amsuess
<christian@amsuess.com>
Carsten Bormann, Universitaet Bremen
<cabo@tzi.org>
Michael Koster, SmartThings
<michael.koster@smartthings.com>
Jim Schaad, August Cellars
<ietf@augustcellars.com>
Thanks to Thomas Fossati, Jaime Jimenez, Sebastian Kaebisch, Ari
Keranen, Matthias Kovatsch, and Niklas Widell for helpful comments
and discussions that have shaped the document.
Author's Address Author's Address
Klaus Hartke Klaus Hartke
Ericsson Ericsson
Torshamnsgatan 23 Torshamnsgatan 23
Stockholm SE-16483 Stockholm SE-16483
Sweden Sweden
Email: klaus.hartke@ericsson.com Email: klaus.hartke@ericsson.com
 End of changes. 27 change blocks. 
64 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/