CoRE Working Group                                             K. Hartke
Internet-Draft                                                  Ericsson
Intended status: Standards Track                        November 4, 2019                          8 January 2020
Expires: May 7, 11 July 2020

          The Constrained RESTful Application Language (CoRAL)
                        draft-ietf-core-coral-01
                        draft-ietf-core-coral-02

Abstract

   The Constrained RESTful Application Language (CoRAL) defines a data
   model and interaction model as well as two specialized serialization
   formats for the description of typed connections between resources on
   the Web ("links"), possible operations on such resources ("forms"),
   as well as
   and simple resource metadata.

Note to Readers

   This note is to be removed before publishing as an RFC.

   The issues list for this Internet-Draft can be found at
   <https://github.com/core-wg/coral/labels/coral>.

   Companion material for this Internet-Draft can be found at
   <https://github.com/core-wg/coral>.

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 7, 11 July 2020.

Copyright Notice

   Copyright (c) 2019 2020 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) (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Data and Interaction Model
     1.2.  Serialization Formats
     1.3.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
   2.  Data and Interaction Model  . . . . . . . . . . . . . . . . .   4
     2.1.  Browsing Context  . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Documents . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Links . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Forms . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.5.  Form Fields . . . . . . . . . . . . . . . . . . . . . . .   7
     2.6.  Embedded Representations  . . . . . . . . . . . . . . . .   7
     2.7.  Navigation  . . . . . . . . . . . . . . . . . . . . . . .   8
     2.8.
     2.7.  History Traversal . . . . . . . . . . . . . . . . . . . .   9
   3.  Binary Format . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  Data Structure  . . . . . . . . . . . . . . . . . . . . .  10
       3.1.1.  Documents . . . . . . . . . . . . . . . . . . . . . .  10
       3.1.2.  Links . . . . . . . . . . . . . . . . . . . . . . . .  10  Directives
       3.1.3.  Forms . . . . . . . . . . . . . . . . . . . . . . . .  11  IRIs
       3.1.4.  Embedded Representations  . . . . . . . . . . . . . .  12  Links
       3.1.5.  Directives  . . . . . . . . . . . . . . . . . . . . .  13  Forms
       3.1.6.  Form Fields
     3.2.  Dictionaries  . . . . . . . . . . . . . . . . . . . . . .  13  Dictionary Compression
       3.2.1.  Dictionary References . . . . . . . . . . . . . . . .  13
       3.2.2.  Media Type Parameter  . . . . . . . . . . . . . . . .  14
   4.  Textual Format  . . . . . . . . . . . . . . . . . . . . . . .  14
     4.1.  Lexical Structure . . . . . . . . . . . . . . . . . . . .  15
       4.1.1.  Line Terminators  . . . . . . . . . . . . . . . . . .  15
       4.1.2.  White Space . . . . . . . . . . . . . . . . . . . . .  15
       4.1.3.  Comments  . . . . . . . . . . . . . . . . . . . . . .  15
       4.1.4.  Identifiers . . . . . . . . . . . . . . . . . . . . .  16
       4.1.5.  IRIs and IRI References . . . . . . . . . . . . . . .  16
       4.1.6.  Literals  . . . . . . . . . . . . . . . . . . . . . .  16
       4.1.7.
       4.1.6.  Punctuators . . . . . . . . . . . . . . . . . . . . .  20
     4.2.  Syntactic Structure . . . . . . . . . . . . . . . . . . .  20
       4.2.1.  Documents . . . . . . . . . . . . . . . . . . . . . .  21
       4.2.2.  Links . . . . . . . . . . . . . . . . . . . . . . . .  21  Directives
       4.2.3.  Forms . . . . . . . . . . . . . . . . . . . . . . . .  22  IRIs
       4.2.4.  Embedded Representations  . . . . . . . . . . . . . .  23  Links
       4.2.5.  Directives  . . . . . . . . . . . . . . . . . . . . .  23  Forms
       4.2.6.  Form Fields
   5.  Document Semantics
     5.1.  Submitting Documents
       5.1.1.  PUT Requests
       5.1.2.  POST Requests
     5.2.  Returning Documents
       5.2.1.  Success Responses
       5.2.2.  Redirection Responses
       5.2.3.  Error Responses
   6.  Usage Considerations  . . . . . . . . . . . . . . . . . . . .  24
     5.1.
     6.1.  Specifying CoRAL-based Applications . . . . . . . . . . .  24
       5.1.1.
       6.1.1.  Application Interfaces  . . . . . . . . . . . . . . .  25
       5.1.2.
       6.1.2.  Resource Identifiers  . . . . . . . . . . . . . . . .  25
       5.1.3.
       6.1.3.  Implementation Limits . . . . . . . . . . . . . . . .  26
     5.2.
     6.2.  Minting Vocabulary  . . . . . . . . . . . . . . . . . . .  26
     5.3.
     6.3.  Expressing Registered Link Relation Types . . . . . . . .  27
     5.4.
     6.4.  Expressing Simple RDF Statements  . . . . . . . . . . . .  28
     5.5.
     6.5.  Expressing Natural Language Texts . . . . . . . . . . . .  28
     5.6.
     6.6.  Embedding CoRAL Representations in CBOR Data  . . . . . . . . . . . . . .  29
     5.7.  Submitting CoRAL Documents  . . . . . . . . . . . . . . .  29
       5.7.1.  PUT Requests  . . . . . . . . . . . . . . . . . . . .  29
       5.7.2.  POST Requests . . . . . . . . . . . . . . . . . . . .  29
     5.8.  Returning
     6.7.  Embedding CoRAL Documents . . . . . . . . . . . . . . . .  30
       5.8.1.  Success Responses . . . . . . . . . . . . . . . . . .  30
       5.8.2.  Error Responses . . . . . . . . . . . . . . . . . . .  30
   6. in CBOR Representations
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
   7.
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32
     7.1.
     8.1.  Media Type "application/coral+cbor" . . . . . . . . . . .  32
     7.2.
     8.2.  Media Type "text/coral" . . . . . . . . . . . . . . . . .  33
     7.3.
     8.3.  CoAP Content Formats  . . . . . . . . . . . . . . . . . .  34
     7.4.
     8.4.  CBOR Tag  . . . . . . . . . . . . . . . . . . . . . . . .  35
   8.
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     8.1.
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  35
     8.2.
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  37
   Appendix A.  Core Vocabulary  . . . . . . . . . . . . . . . . . .  39
     A.1.  Base  . . . . . . . . . . . . . . . . . . . . . . . . . .  40
     A.2.  Collections . . . . . . . . . . . . . . . . . . . . . . .  41
     A.3.  HTTP  . . . . . . . . . . . . . . . . . . . . . . . . . .  41
     A.4.  CoAP  . . . . . . . . . . . . . . . . . . . . . . . . . .  42
   Appendix B.  Default Dictionary . . . . . . . . . . . . . . . . .  43
   Appendix C.  Change Log
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  44
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  44

1.  Introduction

   The Constrained RESTful Application Language (CoRAL) is a language
   for the description of typed connections between resources on the Web
   ("links"), possible operations on such resources ("forms"), as well
   as and
   simple resource metadata.

   CoRAL is intended for driving automated software agents that navigate
   a Web application based on a standardized vocabulary of link relation
   types and operation types.  It is designed to be used in conjunction
   with a Web transfer protocol protocol, such as the Hypertext Transfer Protocol
   (HTTP) [RFC7230] or the Constrained Application Protocol (CoAP)
   [RFC7252].

   This document defines the CoRAL data model and interaction model, model as
   well as two specialized CoRAL serialization formats.

1.1.  Data and Interaction Model

   The CoRAL data and interaction model is a superset of derives from the Web Linking model of RFC 8288 [RFC8288].  The data model
   [RFC8288] and primarily consists of two primary elements: "links" that
   describe the relationship between two resources and the type of that relationship,
   relationship; and "forms" that describe a possible operation on a
   resource and the type of that operation.

   Additionally, the data model can describe simple resource metadata in a way similar
   similarly to statements in the Resource Description Framework (RDF)
   [W3C.REC-rdf11-concepts-20140225].  In contrast to RDF, the focus of
   CoRAL however
   CoRAL, however, is not on the interaction with resources, not just description of a resource graph, but on
   the
   relationships between them. discovery of possible future application states of a software
   agent.

   The interaction model derives from HTML
   5 [W3C.REC-html52-20171214] and
   specifies how an automated software agent can change the application
   state, i.e., navigate between resources by following links and
   perform operations on resources by submitting forms.

1.2.  Serialization Formats

   The primary CoRAL serialization format is a compact, binary encoding of
   links and forms in Concise Binary Object Representation (CBOR)
   [RFC7049].  It
   [I-D.ietf-cbor-7049bis].  The format is intended for environments
   with constraints on power, memory, and processing resources [RFC7228]
   and shares many similarities with the message format of the
   Constrained Application Protocol (CoAP) [RFC7252]: [RFC7252].  For example, it
   uses numeric identifiers instead of verbose strings for link relation
   types and operation types, and pre-parses Uniform Resource
   Identifiers (URIs) [RFC3986] into (what CoAP considers to be) their
   components, which considerably simplifies URI processing for
   constrained nodes a lot. that already implement CoAP.  As a result, link
   serializations in CoRAL are often much more compact and easier to
   process than equivalent serializations in CoRE Link Format [RFC6690].

   The secondary CoRAL serialization format is a lightweight, textual encoding
   of links and forms that is intended to be easy to read and to write
   for humans.  The format is loosely inspired by the syntax of Turtle
   [W3C.REC-turtle-20140225] and is mainly intended for giving
   examples.

1.1. examples
   with precise semantics.

1.3.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Terms defined in this document appear in _cursive_ where they are
   introduced.

2.  Data and Interaction Model

   The Constrained RESTful Application Language (CoRAL) is designed for
   building Web-based applications [W3C.REC-webarch-20041215] in which
   automated software agents navigate between resources by following
   links and perform operations on resources by submitting forms.

2.1.  Browsing Context

   Borrowing from HTML 5 [W3C.REC-html52-20171214], each such agent
   maintains a _browsing context_ in which the representations of Web
   resources are processed.  (In HTML 5, HTML, the browsing context typically
   corresponds to a tab or window in a Web browser.)

   At any time, one representation in each a browsing context is designated
   the _active_ representation.

2.2.  Documents

   A resource representation in one of the CoRAL serialization formats
   is called a CoRAL _document_.  The URI that was used to retrieve such
   a document is called the document's _retrieval context_.

   A CoRAL document consists of a list of zero or more links, forms, links and
   embedded resource representations, forms,
   collectively called _elements_.  CoRAL serialization formats may
   define additional types of elements for efficiency or convenience,
   such as a base for relative URI
   references [RFC3986]. references.

2.3.  Links

   A _link_ describes a relationship between two resources on the Web
   [RFC8288].  As defined in RFC 8288, it consists of a link in CoRAL has a _link context_, a
   _link relation type_, and a _link target_. In  However, in CoRAL, links
   do not have target attributes.  Instead, a link can
   additionally may have a nested list of
   zero or more elements, which take nested elements.  These enable both the place description of
   resource metadata (which is done in RFC 8288 with target attributes)
   and the chaining of links (which can be done in RFC 8288 by setting
   the anchor of one link to the target attributes. of another).

      A link can be viewed as a statement of the form "{link context}
      has a {link relation type} resource at {link target}" where the
      link target may be further described by nested elements.

   The link relation type identifies the semantics of a link.  In  While in
   HTML 5 and RFC 8288, link relation types 8288 these are typically denoted by an IANA-
   registered IANA-registered
   name, such as "stylesheet" or "type".  In CoRAL, they "type", link relation types in CoRAL
   are denoted by an Internationalized Resource Identifier (IRI) [RFC3987]
   [RFC3987], such as <http://www.iana.org/assignments/relation/stylesheet> <http://www.iana.org/assignments/relation/
   stylesheet> or <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>.
   This allows for the creation of new link relation types without the
   risk of collisions when from different organizations or domains of
   knowledge.
   An IRI also  IRIs can also lead to documentation, schema, and other
   information about the a link relation type.  These  In CoRAL documents, these
   IRIs are only used as identity tokens, though, and are compared using with
   Simple String Comparison
   (Section 5.1 as specified in Section 5.3.1 of RFC 3987). 3987.

   The link context and the link target are can be both denoted by either a URI
   reference or URI, a
   literal (similarly to RDF). value, or an anonymous resource.  If the URI scheme of a URI
   indicates a Web transfer protocol such as HTTP or CoAP, then an agent can
   dereference the URI and navigate the browsing context to the
   referenced resource; link
   target; this is called _following the link_.  A literal
   directly identifies a value: value can be
   either a Boolean value, an integer, a floating-
   point floating-point number, a date/time value, date/
   time instant, a byte string, or a text string.  An anonymous resource
   is a resource which is not identified by a URI and is not a literal.

   A link can occur as a top-level element in a document or as a nested
   element within a link.  When a link occurs as a top-level element,
   the link context implicitly is the document's retrieval context.
   When a link occurs nested within a link, the link context of the
   inner link is the same resource as the link target of the outer link.

   There are no restrictions on the cardinality of links; there can be
   multiple links to and from a particular target, and multiple links of
   the same or different types between a given link context and target.
   However, the nested data structure constrains the description of a
   resource graph to a tree: Links between linked resources can only be
   described by further nesting links.

2.4.  Forms

   A _form_ provides instructions to an agent for performing an
   operation on a Web resource.  It consists of  A form has a _form context_, an
   _operation type_, a _request method_, and a _submission target_.
   Additionally, a form may be accompanied by a list of zero or more
   _form fields_.

      A form can be viewed as an instruction of the form "To perform an
      {operation type} operation on {form context}, make a {request
      method} request to {submission target}" where the request may be
      further described by form fields.

   The operation type identifies the semantics of the operation.
   Operation types are denoted like (like link relation types types) by an IRI.

   Both the form context and the submission target are denoted by a URI.
   The form context is the resource on which an operation is ultimately
   performed.  To perform the operation, an agent needs to construct a
   request with the specified method and the specified submission target
   as the request URI.  Usually, the submission target is the same
   resource as the form context, but it may be a different resource.
   Constructing and sending the request is called _submitting the form_.

   Form fields, specified in the next section, can be used to provide
   more detailed instructions to the agent for constructing the request.
   For example, form fields can instruct the agent to include a payload
   or certain headers in the request that must match the specifications
   of the form fields.

   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,
   the form context implicitly is the document's retrieval context.
   When a form occurs nested within a link, the form context is the same
   resource as the link target of the enclosing link.

2.5.  Form Fields

   Form fields can be used to provide further more detailed instructions to
   agents for constructing the request when submitting a
   request. form.  For
   example, a form field could identify one or more data items that
   need to be included in fields can instruct the request agent to include a certain
   payload or reference another
   resource (such as a schema) that describes the structure of certain header fields in the
   payload.  A form field could also provide other kinds of information,
   such as request.  Form fields might
   describe a payload by identifying acceptable media types for the payload types, referencing
   a schema, or expected request
   headers. listing a number of data items that need to be included.
   Form fields may can be specific to the Web transfer protocol that is used
   for submitting the form.

   A form field is the a pair of a _form field type_ and a _form field
   value_.  Additionally, a form field may have a list of zero or more
   nested elements that further describe the form field value.

   The form field type identifies the semantics of the form field.  Form
   field types are denoted like (like link relation types and operation types
   types) by an IRI.

   The form field value can be either a URI reference, URI, a Boolean value, an
   integer, a floating-point number, a date/time value, instant, a byte string, or
   a text string.

2.6.  Embedded Representations

   When a document contains links to many resources and an agent needs a
   representation of each link target, it may be inefficient to retrieve
   each of these representations individually.  To alleviate this,
   documents can directly embed representations of resources.

   An _embedded representation_ consists of a sequence of bytes, labeled
   with _representation metadata_.

   An embedded representation may be a full, partial, or inconsistent
   version of the representation served from the URI of the resource.

   An embedded representation can occur as a top-level element in a
   document string, or as a nested element within a link.  When it occurs as a
   top-level element, it provides an alternate representation of null.  A null denotes the
   document's retrieval context.  When it occurs nested within a link,
   it provides a representation of link target intentional absence of the enclosing link.

2.7.
   any form field value.

2.6.  Navigation

   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
   an
   that the agent is expected to know before interacting with an the
   application.  From there, then on, the agent is expected to make all
   requests by following links and submitting forms that are provided by the server
   servers in responses.  The entry point URI can be obtained by manual configuration or through
   some discovery process. process or manual configuration.

   If dereferencing the entry point URI yields a CoRAL document (or any
   other representation that implements the CoRAL data and interaction
   model), then the agent makes this document the active representation
   in the browsing context and proceeds as follows:

   1.  The first step for the agent is to decide what to do next, i.e.,
       which type of link to follow or type of form to submit, based on
       the link relation types and operation types it understands. knows.

   2.  The agent then finds the link(s) or form(s) with the respective
       type in the active representation.  This may yield one or more
       candidates, from which the agent will have to select the most
       appropriate one.  The set of candidates may can be empty, for
       example, when a transition is not supported or not allowed.

   3.  The agent selects one of the candidates based on the order of
       appearance in the document and the resource metadata associated
       with each them in the form of these.  Metadata includes nested elements and form fields.
       Examples for resource metadata include the indication of a
       content type of for the target resource representation, the URI scheme, the
       request method, and other information that is provided as nested
       elements in
       scheme of a link target, or form fields in the request method of a form.

       If the selected candidate contains an embedded representation,
       the agent MAY skip the following steps and immediately proceed
       with step 8.

   4.  The agent obtains the _request URI_ from the link target or
       submission target.  Link targets and submission targets may be
       denoted by relative URI references, which need to be resolved to
       obtain the request URI.  Fragment identifiers are not part of the
       request URI and MUST be separated from the rest of the URI prior
       to a dereference. the next step.

   5.  The agent constructs a new request with the request URI.  If the
       agent is following a link, then the request method MUST be GET.
       If the agent is submitting a form, then the request method MUST
       be the one specified indicated by the form.  An IRI may need to be
       converted to a URI (Section 3.1 of RFC 3987) for protocols that
       do not support IRIs.

       The agent should set HTTP header fields and CoAP request options
       according to metadata associated with the nested elements of a link or form fields of a
       form (e.g., set the HTTP Accept header field or the CoAP Accept
       option when the a media type of for the target resource is provided).
       Depending on the operation type of a form, the agent may also need
       have to include a request payload that matches the specifications
       of one or more some form fields.

   6.  The agent sends the request and receives the response.

   7.  If a fragment identifier was separated from the request URI, the
       agent dereferences selects the fragment indicated by the fragment identifier
       within the received representation.

   8.  The agent _updates the browsing context_ by making the (embedded
       or received) (selected
       fragment of the) received representation the active
       representation.

   9.  Finally, the agent processes the representation according to the
       semantics of the its content type.  If the representation is a CoRAL
       document (or any other representation that implements the CoRAL
       data and interaction model), this means the agent has the choice of what to
       do next again -- and the cycle repeats.

2.8.

2.7.  History Traversal

   A

   Each browsing context MAY entail has a _session history_ that lists the resource
   representations that the agent has processed, is processing, or will
   process.  The maximum length of the session history is up for the
   agent to decide and may be zero.

   An entry in the session history consists of a resource representation
   and the request URI that was used to retrieve the representation.
   New entries are added to the session history as the agent navigates
   from resource to resource.

   An

   In addition to following links and submitting forms, an agent can
   decide tp navigate a browsing context by _traversing the session
   history_ in addition to following links and submitting forms.
   history_.  For example, if when an agent received receives a representation that doesn't
   does not contain any further links or forms, it can revert set the active
   representation back to one it has visited earlier.

   Traversing the history should take advantage of caches to avoid new
   requests.  An agent MAY reissue a safe request (e.g., a GET request)
   when it doesn't does not have a fresh representation in its cache.  An agent
   MUST NOT reissue an unsafe request (e.g., a PUT or a POST request)
   unless it intends to perform that operation again.

3.  Binary Format

   This section defines the encoding of documents in the CoRAL binary
   format.

   A document in the binary format is a data item encoded in Concise Binary Object
   Representation (CBOR) [RFC7049]. [I-D.ietf-cbor-7049bis].  The encoding MUST
   satisfy the Core Deterministic Encoding Requirements specified in
   Section XX of RFC XXXX [I-D.ietf-cbor-7049bis].

   The CBOR structure of this data
   item a document is presented in the Concise Data
   Definition Language (CDDL) [RFC8610].  All CDDL rules not defined in
   this document are defined in Appendix D of RFC 8610 [RFC8610].

   The media type is "application/coral+cbor".

   The following restrictions are placed on CBOR encoders: Byte strings
   and text strings MUST be encoded with definite length.  Integers and
   floating-point values MUST be encoded as such (e.g., a floating-point
   value of 0.0 must not be encoded as documents in the integer 0). binary format is "application/
   coral+cbor".

3.1.  Data Structure

   The data structure of a document in the binary format is made up of
   four
   three kinds of elements: links, forms, embedded representations, and (as an extension to the
   CoRAL data model) base directives.  Base
   directives  Directives provide a way to encode URI
   references with a common base more efficiently.

   Elements are processed in the

3.1.1.  Documents

   A document in the binary format is encoded as a CBOR array that
   contains zero or more elements.  An element is either a link, a form,
   or a directive.

      document = [*element]

      element = link / form / directive

   The elements are processed in the order they appear in the document.
   Document processors need to maintain an _environment_ while iterating
   an array of elements.  The environment consists of two variables: the
   _current context_ and the _current base_.  Both the current context
   and the current base are initially set to the document's retrieval
   context.

3.1.1.  Documents

   The body of

3.1.2.  Directives

   Directives provide the ability to manipulate the environment while
   processing elements.

   There is a document in single type of directives available: the binary format Base directive.

      directive = base-directive

3.1.2.1.  Base Directives

   A Base directive is encoded as an a CBOR array of
   zero or more links, forms, embedded representations, that contains the
   unsigned integer 1 and directives.

      document a base URI.

      base-directive = [1, baseURI]

   The base URI is denoted by a Constrained Resource Identifier (CoRI)
   reference [I-D.ietf-core-href].  The CoRI reference MUST be resolved
   against the current context (not the current base).

      baseURI = body

      body CoRI

      CoRI = [*(link / form / representation / directive)]

3.1.2. <Defined in Section XX of RFC XXXX>

   The directive is processed by resolving the CoRI reference against
   the current context and assigning the result to the current base.

3.1.3.  IRIs

   IRIs in links and forms are encoded as CoRI references.

      IRI = CoRI

   A CoRI reference is processed by resolving it to an IRI as specified
   in Section XX of RFC XXXX [I-D.ietf-core-href] using the current
   base.

3.1.4.  Links

   A link is encoded as an a CBOR array that consists of contains the unsigned integer
   2, followed by the link relation type and type, the link target, optionally
   followed by a link body that contains and, optionally, an array
   of zero or more nested elements.

      link = [2, relation-type, link-target, ?body] ?[*element]]

   The link relation type is encoded as a text string that conforms to
   the syntax of an IRI [RFC3987].

      relation-type = text

   The link target is denoted by either an IRI, a Constrained Resource Identifier
   (CoRI) reference [I-D.ietf-core-href] literal value, or represented by a null.

      link-target = IRI / literal
   value.  A CoRI reference MUST be resolved against the current base.
   The link target may be null, which indicates that the link target is
   an unidentified resource.

      link-target = CoRI / literal

      CoRI = <Defined in Section X of RFC XXXX> null

      literal = bool / int / float / time / bytes / text / null

   The array of elements in the link body, nested elements, if any, MUST be processed in a fresh
   environment.  Both the current context and the current base in the new this
   environment are initially set to the link target of the enclosing
   link.

3.1.3.

3.1.5.  Forms

   A form is encoded as an a CBOR array that consists of contains the unsigned integer
   3, followed by the operation type and type, the submission target,
   optionally followed by a list and, optionally, an
   array of zero or more form fields.

      form = [3, operation-type, submission-target, ?form-fields] ?[*form-field]]

   The operation type is defined in the same way encoded as a link relation type
   (Section 3.1.2). text string that conforms to the
   syntax of an IRI [RFC3987].

      operation-type = text

   The submission target is an IRI.

      submission-target = IRI

   The request method is either implied by the operation type or encoded
   as a form field.  If there both are both, given, the form field takes precedence
   over the operation type.  Either way, the method MUST be defined for applicable
   to the Web transfer protocol identified by the scheme of the
   submission target.

   The submission target is denoted by a CoRI reference.  This CoRI
   reference MUST be resolved against the current base.

      submission-target = CoRI

3.1.3.1.  Form Fields

   A list of form fields is encoded as an array of zero or more type-
   value pairs.

      form-fields = [*(form-field-type, form-field-value)]

   The list, fields, if any, MUST be processed in a fresh environment.
   Both the current context and the current base in the new this environment are
   initially set to the submission target of the enclosing form.

3.1.6.  Form Fields

   A form field type is defined in the same way encoded as a link relation CBOR sequence that consists of a form
   field type, a form field value, and, optionally, an array of zero or
   more nested elements.

      form-field = (form-field-type, form-field-value, ?[*element])

   The form field type
   (Section 3.1.2). is encoded as a text string that conforms to the
   syntax of an IRI [RFC3987].

      form-field-type = text

   A

   The form field value can be a CoRI reference, a Boolean value, is either an
   integer, a floating-point number, IRI, a date/time literal value, a byte string, a
   text string, or null.  A CoRI reference MUST be resolved against the
   current base.

      form-field-value = CoRI IRI / literal

3.1.4.  Embedded Representations

   An embedded representation is encoded as an array that consists of
   the unsigned integer 0, followed by a byte string containing the
   representation data, optionally followed by representation metadata.

      representation = [0, bytes, ?representation-metadata]

   Representation metadata is encoded as an array of zero or more name-
   value pairs.

      representation-metadata = [*(metadata-name, metadata-value)] / null

   The metadata, nested elements, if any, MUST be processed in a fresh
   environment.  All
   variables in  Both the new current context and current base in this
   environment are initially set to a copy of the
   variables in the current environment.

   The metadata name is defined in the same way as a link relation type
   (Section 3.1.2).

      metadata-name = text

   A metadata form field value can be a CoRI reference, a Boolean value, an
   integer, a floating-point number, a date/time value, a byte string, a
   text string, or null.  A CoRI reference MUST be resolved against the
   current base.

      metadata-value = CoRI / literal

3.1.5.  Directives

   Directives provide the ability to manipulate the environment when
   processing a list of elements.  There is one type of directives
   available: the Base directive.

      directive = base-directive

3.1.5.1.  Base Directives
   enclosing form field.

3.2.  Dictionary Compression

   A Base directive is encoded as an array that consists of the unsigned
   integer 1, followed by a base.

      base-directive = [1, base]

   The base is denoted by a CoRI reference.  This CoRI reference MUST be
   resolved against the current context (not the current base).

      base = CoRI

   The directive is processed by resolving the CoRI reference against
   the current context and assigning the result to document in the current base.

3.2.  Dictionaries

   The binary format can reference values from a an external
   dictionary to reduce representation size and processing cost.
   Dictionary references can be used in place of link relation types,
   link targets, operation types, submission targets, form field types,
   and form field values,
   representation metadata names, and representation metadata values.

3.2.1.  Dictionary References

   A dictionary reference is encoded as an unsigned integer.  Where a
   dictionary reference cannot be expressed unambiguously, the unsigned
   integer is tagged with CBOR tag TBD6. TBD6, as follows:

      relation-type /= uint

      link-target /= #6.TBD6(uint)

      operation-type /= uint

      submission-target /= #6.TBD6(uint)

      form-field-type /= uint

      form-field-value /= #6.TBD6(uint)

      metadata-name /= uint

      metadata-value /= #6.TBD6(uint)

3.2.2.  Media Type Parameter

   The "application/coral+cbor" media type is defined

   A dictionary reference MUST NOT refer to have a
   "dictionary" parameter that specifies the dictionary in use.  The dictionary value that is identified by a URI [RFC3986].
   otherwise not allowed.  For example, a dictionary reference that is
   used in place of a link relation type is not allowed to refer to a
   Boolean value.

3.2.2.  Media Type Parameter

   The "application/coral+cbor" media type for documents in the binary
   format is defined to have a "dictionary" parameter that specifies the
   dictionary in use.  The dictionary is identified by a URI [RFC3986].
   For example, a CoRAL document that uses the dictionary identified by
   the URI <http://example.com/dictionary> can use the following content
   type:

      application/coral+cbor;dictionary="http://example.com/dictionary"

   The URI serves only as an identifier; it does not necessarily have to
   be dereferencable (or even use a dereferencable URI scheme).  It is
   permissible, though, to use a dereferencable URI and to serve a
   representation that provides information about the dictionary in a
   human-
   machine- or machine-readable human-readable way.  (The representation format and
   security considerations of such a representation
   is are outside the
   scope of this document.)

   For simplicity, a CoRAL document can reference values only from one
   dictionary; the value of the "dictionary" parameter MUST be a single
   URI.  If the  The "dictionary" parameter is OPTIONAL.  If it is absent, the
   default dictionary specified in Appendix B of this document is
   assumed.

   Once a dictionary has made an assignment, the assignment MUST NOT be
   changed or removed.  A dictionary, however, may contain additional
   information about an assignment, which may change over time.

   In CoAP [RFC7252], media types (including specific values for media
   type their
   parameters) are encoded as an unsigned integer called the "content
   format".
   format" of a representation.  For use with CoAP, each new CoRAL
   dictionary MUST register therefore needs to have a new content format registered
   with IANA in the IANA CoAP Content-Formats Registry.

4.  Textual Format

   This section defines the syntax of documents in the CoRAL textual
   format using two grammars: The lexical grammar defines how Unicode
   characters are combined to form line terminators, white space,
   comments, and tokens.  The syntactic grammar defines how tokens are
   combined to form documents.  Both grammars are presented in Augmented
   Backus-Naur Form (ABNF) [RFC5234].

   A document in the textual format is a Unicode string in a Unicode
   encoding form [UNICODE].  The media type for such documents is "text/
   coral".  The "charset" parameter of textual media types [RFC6657] is
   not used; instead, charset information is transported inside the
   document in the form of an OPTIONAL Byte Order Mark (BOM).  The use
   of the UTF-8 encoding scheme [RFC3629], [RFC3629] without a BOM, BOM is RECOMMENDED.

4.1.  Lexical Structure

   The lexical structure of a document in the textual format is made up
   of four basic elements: line terminators, white space, comments, and
   tokens.  Of these, only tokens are significant in the syntactic
   grammar.  There are five three kinds of tokens: identifiers, IRIs, IRI
   references, literals, identifier tokens, literal
   tokens, and punctuators. punctuator tokens.

      token = identifier / iri IRIref / iriref boolean / literal integer / float

      token =/ datetime / bytes / text / null / punctuator

   When several lexical grammar rules match a sequence of characters in
   a document, the longest match takes priority.

4.1.1.  Line Terminators

   Line terminators divide text into lines.  A line terminator is any
   Unicode character with Line_Break class BK, CR, LF, or NL.  However,
   any CR character that immediately precedes a LF character is ignored.
   (This affects only the numbering of lines in error messages.)

4.1.2.  White Space

   White space is a sequence of one or more white space characters.  A
   white space character is any Unicode character with the White_Space
   property.

4.1.3.  Comments

   Comments are sequences of characters that are ignored when parsing
   text into tokens.  Single-line comments begin with the characters
   "//" and extend to the end of the line.  Delimited comments begin
   with the characters "/*" and end with the characters "*/".  Delimited
   comments can occupy a portion of a line, a single line, or multiple
   lines.

   Comments do not nest.  The character sequences "/*" and "*/" have no
   special meaning within a single-line comment; the character sequences
   "//" and "/*" have no special meaning within a delimited comment.

4.1.4.  Identifiers

   An identifier token is a user-defined symbolic name.  The rules for
   identifiers correspond to those recommended by the Unicode Standard
   Annex #31 [UNICODE-UAX31] using [UAX31] with the following profile:

      identifier = START *CONTINUE *(MEDIAL 1*CONTINUE)

      START = <Any character with the XID_Start property>

      CONTINUE = <Any character with the XID_Continue property>

      MEDIAL = "-" / "." / "~" / %x58A / %xF0B

      MEDIAL =/ %x2010 / %x2027 / %x30A0 / %x30FB

   All identifiers MUST be converted into Unicode Normalization Form C
   (NFC), as which is defined by the in Unicode Standard Annex #15 [UNICODE-UAX15]. [UAX15].
   Comparison of identifiers is based on NFC and is case-sensitive (unless
   otherwise noted).

4.1.5.  IRIs and  Literals

   A literal token is a textual representation of a value.

4.1.5.1.  IRI References

   IRIs and Reference Literals

   IRI reference tokens denote references are to resources on the Web.

   An IRI reference literal consists of a Unicode strings string that conform conforms
   to the syntax defined in RFC 3987 [RFC3987].  An IRI reference can be is
   either an IRI or a relative reference.  Both IRIs and  IRI references are enclosed
   in angle brackets ("<" and ">").

      iri = "<" IRI ">"

      iriref

      IRIref = "<" IRI-reference ">"

      IRI = <Defined in Section 2.2 of RFC 3987>

      IRI-reference = <Defined in Section 2.2 of RFC 3987>

4.1.6.  Literals

   A literal is a textual representation of a value.  There are seven
   types of literals: Boolean, integer, floating-point, date/time, byte
   string, text string, and null.

      literal = boolean / integer / float / datetime / bytes / text

      literal =/ null

4.1.6.1.

4.1.5.2.  Boolean Literals

   The case-insensitive tokens "true" and "false" denote the Boolean
   values true and false, respectively.

      boolean = "true" / "false"

4.1.6.2.

4.1.5.3.  Integer Literals

   Integer literals literal tokens denote an integer value of unspecified
   precision.  By default, integer literals are expressed in decimal,
   but they can also be specified in an alternate base using a prefix:
   Binary literals begin with "0b", octal literals begin with "0o", and
   hexadecimal literals begin with "0x".

   Decimal literals contain the digits "0" through "9".  Binary literals
   contain "0" and "1", octal literals contain "0" through "7", and
   hexadecimal literals contain "0" through "9" as well as "A" through
   "F" in upper- or lowercase.

   Negative integers are expressed by prepending a minus sign ("-").

      integer = ["+" / "-"] (decimal / binary / octal / hexadecimal)

      decimal = 1*DIGIT

      binary = %x30 (%x42 / %x62) 1*BINDIG

      octal = %x30 (%x4F / %x6F) 1*OCTDIG

      hexadecimal = %x30 (%x58 / %x78) 1*HEXDIG

      DIGIT = %x30-39

      BINDIG = %x30-31

      OCTDIG = %x30-37

      HEXDIG = %x30-39 / %x41-46 / %x61-66

4.1.6.3.

4.1.5.4.  Floating-point Literals

   Floating-point literals literal tokens denote a floating-point number of
   unspecified precision.

   Floating-point literals consist of a sequence of decimal digits
   followed by a fraction, an exponent, or both.  The fraction consists
   of a decimal point (".") followed by a sequence of decimal digits.
   The exponent consists of the letter "e" in upper- or lowercase,
   followed by an optional sign and a sequence of decimal digits that
   indicate a power of 10 by which the value preceding the "e" is
   multiplied.

   Negative floating-point values are expressed by prepending a minus
   sign ("-").

      float = ["+" / "-"] 1*DIGIT [fraction] [exponent]

      fraction = "." 1*DIGIT

      exponent = (%x45 / %x65) ["+" / "-"] 1*DIGIT

   A floating-point literal can additionally denote either the special
   "Not-a-Number" (NaN) value, positive infinity, or negative infinity.
   The NaN value is produced by the case-insensitive token "NaN".  The
   two infinite values are produced by the case-insensitive tokens
   "+Infinity" (or simply "Infinity") and "-Infinity".

      float =/ "NaN"

      float =/ ["+" / "-"] "Infinity"

4.1.6.4.

4.1.5.5.  Date/Time Literals

   Date/time literals literal tokens denote an instant in time.

   A date/time literal consists of the prefix "dt" and a sequence of
   Unicode characters in Internet Date/Time Format [RFC3339], enclosed
   in single quotes.

      datetime = %x64.74 SQUOTE date-time SQUOTE

      date-time = <Defined in Section 5.6 of RFC 3339>

      SQUOTE = %x27

4.1.6.5.

4.1.5.6.  Byte String Literals

   Byte string literals literal tokens denote an ordered sequence of bytes.

   A byte string literal consists of a prefix and zero or more bytes
   encoded in Base16, Base32, or Base64 [RFC4648], enclosed in single
   quotes.  Byte string literals encoded in Base16 begin with "h" or
   "b16", byte string literals encoded in Base32 begin with "b32", and
   byte string literals encoded in Base64 begin with "b64".

      bytes = base16 / base32 / base64

      base16 = (%x68 / %x62.31.36) SQUOTE <Base16 encoded data> SQUOTE

      base32 = %x62.33.32 SQUOTE <Base32 encoded data> SQUOTE

      base64 = %x62.36.34 SQUOTE <Base64 encoded data> SQUOTE

4.1.6.6.

4.1.5.7.  Text String Literals

   Text string literals literal tokens denote a Unicode string.

   A text string literal consists of zero or more Unicode characters
   enclosed in double quotes.  It can include simple escape sequences
   (such as \t for the tab character) as well as hexadecimal and Unicode
   escape sequences.

      text = DQUOTE *(char / %x5C escape) DQUOTE

      char = <Any character except %x22, DQUOTE, %x5C, and line terminators>

      escape = simple-escape / hexadecimal-escape / unicode-escape

      simple-escape = %x30 / %x62 / %x74 / %x6E / %x76

      simple-escape =/ %x66 / %x72 / %x22 / %x27 / %x5C

      hexadecimal-escape = (%x78 / %x58) 2HEXDIG

      unicode-escape = %x75 4HEXDIG / %x55 8HEXDIG

      DQUOTE = %x22

   An escape sequence denotes a single Unicode code point.  For
   hexadecimal and Unicode escape sequences, the code point is expressed
   by the hexadecimal number following the "\x", "\X", "\u", or "\U"
   prefix.  Simple escape sequences indicate the code points listed in
   Table 1.

          +-----------------+------------+----------------------+
          | Escape Sequence | Code Point | Character Name       |
          +-----------------+------------+----------------------+
          +=================+============+======================+
          |        \0       |   U+0000   | Null                 |
          +-----------------+------------+----------------------+
          |        \b       |   U+0008   | Backspace            |
          +-----------------+------------+----------------------+
          |        \t       |   U+0009   | Character Tabulation |
          +-----------------+------------+----------------------+
          |        \n       |   U+000A   | Line Feed            |
          +-----------------+------------+----------------------+
          |        \v       |   U+000B   | Line Tabulation      |
          +-----------------+------------+----------------------+
          |        \f       |   U+000C   | Form Feed            |
          +-----------------+------------+----------------------+
          |        \r       |   U+000D   | Carriage Return      |
          +-----------------+------------+----------------------+
          |        \"       |   U+0022   | Quotation Mark       |
          +-----------------+------------+----------------------+
          |        \'       |   U+0027   | Apostrophe           |
          +-----------------+------------+----------------------+
          |        \\       |   U+005C   | Reverse Solidus      |
          +-----------------+------------+----------------------+

                      Table 1: Simple Escape Sequences

4.1.6.7.

4.1.5.8.  Null Literal

   The case-insensitive tokens "null" and "_" denote the intentional
   absence of any value.

      null = "null" / "_"

4.1.7.

4.1.6.  Punctuators

   Punctuator tokens are used for grouping and separating.

      punctuator = "#" / ":" / "*" "=" / "@" / "[" / "]" / "{" / "}" / "=" / "->"

4.2.  Syntactic Structure

   The syntactic structure of a document in the textual format is made
   up of four three kinds of elements: links, forms, embedded representations, and (as an extension to
   the CoRAL data model) directives.  Directives provide a way to make
   documents easier to read and write by setting a base for relative IRI
   references and introducing shorthands for IRIs.

   Elements are processed in

4.2.1.  Documents

   A document in the textual format consists of a sequence of zero or
   more elements.  An element is either a link, a form, or a directive.

      document = *element

      element = link / form / directive

   The elements are processed in the order they appear in the document.
   Document processors need to maintain an _environment_ while iterating
   a list sequence of elements.  The environment consists of three variables:
   the _current context_, the _current base_, and the _current mapping
   from identifiers to IRIs_.  Both the current context and the current
   base are initially set to the document's retrieval context.  The
   current mapping from identifiers to IRIs is initially empty.

4.2.1.  Documents

   The body of

4.2.2.  Directives

   Directives provide the ability to manipulate the environment while
   processing elements.

   All directives start with a document number sign ("#") followed by an
   identifier.  The identifier is case-insensitive and restricted to
   Unicode characters in the textual format consists Basic Latin block.

   The following two types of zero or more
   links, forms, embedded representations, directives are available: the Base
   directive and directives.

      document = body

      body the Using directive.

      directive = *(link / form / representation base-directive / directive)

4.2.2.  Links using-directive

4.2.2.1.  Base Directives

   A link Base directive consists of the link relation type, a number sign ("#"), followed by the link
   target, optionally
   case-insensitive token "base", followed by a link body enclosed in curly brackets
   ("{" and "}").

      link base IRI.

      base-directive = relation-type link-target ["{" body "}"] "#" "base" baseIRI

   The link relation type base IRI is denoted by either an IRI, a simple name, or
   a qualified name.

      relation-type IRI reference.  The IRI reference MUST
   be resolved against the current context (not the current base).

      baseIRI = iri / simple-name / qualified-name

   A simple name consists of an identifier.  It IRIref

   The directive is resolved to an IRI processed by
   looking up resolving the empty string in IRI reference against the
   current mapping from identifiers
   to IRIs context and appending assigning the specified identifier result to the result.  It is
   an error if the empty string is not present in the current mapping.

      simple-name = identifier base.

4.2.2.2.  Using Directives

   A qualified name Using directive consists of two identifiers separated by a colon
   (":").  It is resolved to number sign ("#"), followed by the
   case-insensitive token "using", optionally followed by an IRI identifier
   and an equals sign ("="), finally followed by looking up an IRI.  If the
   identifier on is not specified, it is assumed to be the
   left hand side in empty string.

      using-directive = "#" "using" [identifier "="] IRIref

   The directive is processed by adding the specified identifier and IRI
   to the current mapping from identifiers to IRIs and
   appending the identifier on the right hand side to the result. IRIs.  It is an error if
   the identifier on the left hand side is not already present in the current mapping.

      qualified-name = identifier ":" identifier

   The link target mapping or if the IRI is not
   an IRI but a relative reference.

4.2.3.  IRIs

   IRIs in links and forms can be either denoted by an IRI reference or represented by
   looked up from a
   value literal. mapping from identifiers to IRIs using names.  There
   are three kinds of names: simple names, qualified names, and
   predefined names.

      IRI = IRIref / simple-name / qualified-name / predefined-name

   Both IRI references and names are processed by resolving them to an
   IRI, as described in the following sub-sections.

4.2.3.1.  IRI References

   An IRI reference MUST be is resolved against to an IRI as specified in Section 6.5 of
   RFC 3987 [RFC3987] using the current base.  If the link target is null, the link target is

4.2.3.2.  Simple Names

   A simple name consists of an unidentified
   resource.

      link-target identifier.

      simple-name = iriref / literal

   The list of elements in identifier

   A simple name is resolved to an IRI by looking up the link body, if any, MUST be processed empty string in a
   fresh environment.  Both
   the current context and current base in this
   environment are initially set to the link target of the enclosing
   link.  The mapping from identifiers to IRIs is initially set and appending the given
   identifier to a
   copy the result.  It is an error if the empty string is not
   present in the mapping.

4.2.3.3.  Qualified Names

   A qualified name consists of two identifiers separated by a colon
   (":").

      qualified-name = identifier ":" identifier

   A qualified name is resolved to an IRI by looking up the identifier
   given on the left hand side in the current mapping from identifiers
   to IRIs IRIs.  The identifier given on the right hand side is appended to
   the result.  It is an error if the identifier on the left hand side
   is not present in the current
   environment.

4.2.3.  Forms mapping.

4.2.3.4.  Predefined Names

   A form predefined name consists of a commercial at sign ("@") followed by
   an identifier.  The identifier is case-insensitive and restricted to
   Unicode characters in the operation Basic Latin block.

      predefined-name = "@" identifier

   A predefined name is resolved to an IRI by looking up the identifier
   in Table 2.  It is an error if the identifier is not present in the
   table.

           +------------+--------------------------------------+
           | Identifier | IRI                                  |
           +============+======================================+
           | direction  | <http://coreapps.org/base#direction> |
           +------------+--------------------------------------+
           | language   | <http://coreapps.org/base#language>  |
           +------------+--------------------------------------+

                         Table 2: Predefined Names

4.2.4.  Links

   A link consists of the link relation type, followed by a "->" token and the submission link
   target, optionally followed by a list sequence of form fields zero or more nested
   elements enclosed in square curly brackets ("[" ("{" and "]").

      form "}").

      link = operation-type "->" submission-target ["[" form-fields "]"] relation-type link-target ["{" *element "}"]

   The operation type is defined in the same way as a link relation type
   (Section 4.2.2).

      operation-type is an IRI.

      relation-type = iri / simple-name / qualified-name IRI

   The request method link target is either implied by the operation type or encoded
   as an IRI, a form field.  If there are both, the form field takes precedence
   over the operation type.  Either way, the method MUST be defined for
   the Web transfer protocol identified by the scheme of the submission
   target.

   The submission target is denoted by an IRI reference.  This IRI
   reference MUST be resolved against the current base.

      submission-target = iriref

4.2.3.1.  Form Fields

   A list of form fields consists of zero literal value, or more type-value pairs.

      form-fields null.

      link-target = IRI / literal / null

      literal = *(form-field-type form-field-value) boolean / integer / float / datetime / bytes / text

   The list, nested elements, if any, MUST be processed in a fresh
   environment.  Both the current context and the current base in this
   environment are initially set to the submission link target of the enclosing form.
   link.  The mapping from identifiers to IRIs is initially set to a
   copy of the mapping from identifiers to IRIs in the current
   environment.

   The form field type is defined in the same way as a link relation
   type (Section 4.2.2).

      form-field-type = iri / simple-name / qualified-name

   The

4.2.5.  Forms

   A form field value can be an IRI reference, Boolean literal,
   integer literal, floating-point literal, byte string literal, text
   string literal, or null.  An IRI reference MUST be resolved against
   the current base.

      form-field-value = iriref / literal

4.2.4.  Embedded Representations

   An embedded representation consists of a "*" token, the operation type, followed by a "->" token and
   the
   representation data, submission target, optionally followed by representation metadata a sequence of zero or
   more form fields enclosed in square brackets ("[" and "]").

      representation

      form = "*" bytes operation-type "->" submission-target ["[" representation-metadata *form-field "]"]

   Representation metadata consists of zero or more name-value pairs.

      representation-metadata

   The operation type is an IRI.

      operation-type = IRI

   The submission target is an IRI.

      submission-target = *(metadata-name metadata-value) IRI

   The request method is either implied by the operation type or encoded
   as a form field.  If both are given, the form field takes precedence
   over the operation type.  Either way, the method MUST be applicable
   to the Web transfer protocol identified by the scheme of the
   submission target.

   The metadata, form fields, if any, MUST be processed in a fresh environment.  All
   variables in
   Both the new current context and the current base in this environment are
   initially set to a copy of the
   variables in submission target of the current environment. enclosing form.  The metadata name
   mapping from identifiers to IRIs is defined in the same way as a link relation type
   (Section 4.2.2).

      metadata-name = iri / simple-name / qualified-name

   The metadata value can be an IRI reference, Boolean literal, integer
   literal, floating-point literal, byte string literal, text string
   literal, or null.  An IRI reference MUST be resolved against the
   current base.

      metadata-value = iriref / literal

4.2.5.  Directives

   Directives provide the ability initially set to manipulate the environment when
   processing a list copy of elements.  All directives start with a number
   sign ("#") followed by a directive identifier.  Directive the
   mapping from identifiers
   are case-insensitive and constrained to Unicode characters IRIs in the
   Basic Latin block.

   The following two types of directives are available: the Base
   directive and the Using directive.

      directive = base-directive / using-directive

4.2.5.1.  Base Directives current environment.

4.2.6.  Form Fields

   A Base directive form field consists of a number sign ("#"), form field type, followed by the
   case-insensitive identifier "base", a form field
   value, optionally followed by a base.

      base-directive sequence of zero or more nested
   elements enclosed in curly brackets ("{" and "}").

      form-field = "#" "base" base form-field-type form-field-value ["{" *element "}"]

   The base form field type is denoted by an IRI.

      form-field-type = IRI reference.

   The form field value is either an IRI, a literal value, or null.

      form-field-value = IRI reference / literal / null

   The nested elements, if any, MUST be
   resolved against the current context (not the current base).

      base = iriref

   The directive is processed by resolving the IRI reference against in a fresh
   environment.  Both the current context and assigning the result current base in this
   environment are initially set to the current base.

4.2.5.2.  Using Directives

   A Using directive consists form field value of a number sign ("#"), followed by the
   case-insensitive identifier "using", optionally followed by an
   identifier and an equals sign ("="), finally followed by an IRI.  If
   the identifier is not specified, it is assumed to be the empty
   string.

      using-directive = "#" "using" [identifier "="] iri
   enclosing form field.  The directive mapping from identifiers to IRIs is processed by adding the specified identifier and IRI
   initially set to a copy of the current mapping from identifiers to IRIs.  It is an error if
   the identifier is already present IRIs in
   the mapping. current environment.

5.  Usage Considerations

   This section discusses some considerations in creating CoRAL-based
   applications and vocabularies.  Document Semantics

5.1.  Specifying CoRAL-based Applications

   CoRAL-based applications naturally implement the Web architecture
   [W3C.REC-webarch-20041215] and thus are centered around orthogonal
   specifications for identification, interaction, and representation:

   o  Resources are identified by IRIs or represented by value literals.

   o  Interactions are based on  Submitting Documents

   By default, a CoRAL document is a representation that captures the hypermedia interaction model
   current state of the
      Web and the methods provided by the Web transfer protocol. a resource.  The
      semantics meaning of possible interactions are identified by link relation
      types and operation types.

   o  Representations are a CoRAL documents encoded in the binary format
      defined in Section 3 or the textual format defined document changes
   when it is submitted in Section 4. a request.  Depending on the application, additional representation formats
      may request method,
   the CoRAL document can capture the intended state of a resource (PUT)
   or be used.

5.1.1.  Application Interfaces

   Specifications for CoRAL-based applications need subject to list the specific
   components used application-specific processing (POST).

5.1.1.  PUT Requests

   A PUT request with a CoRAL document enclosed in the application interface and their identifiers.
   This should include the following items:

   o  URI schemes that identify the Web transfer protocol(s) used in the
      application.

   o  Internet media types request payload
   requests that identify the representation format(s)
      used in state of the application, including target resource be created or replaced
   with the media type(s) of state described by the CoRAL
      serialization format(s).

   o  Link relation types that identify the semantics document.  A successful PUT of links.

   o  Operation types
   a CoRAL document generally means that identify the semantics of forms.
      Additionally, for each operation type, the permissible request
      method(s).

   o  Form field types a subsequent GET on that identify the semantics of form fields.
      Additionally, for each form field type, the permissible form field
      values.

   o  Metadata names same
   target resource would result in an equivalent document being sent in
   a success response.

   An origin server SHOULD verify that identify a submitted CoRAL document is
   consistent with any constraints the semantics of representation
      metadata.  Additionally, server has for each metadata name, the permissible
      metadata values.

5.1.2.  Resource Identifiers

   URIs [RFC3986] are a cornerstone of Web-based applications.  They
   enable the uniform identification of resources and are used every
   time target
   resource.  When a client interacts document is inconsistent with a the target resource,
   the origin server SHOULD either make it consistent (e.g., by removing
   inconsistent elements) or a resource representation
   needs to refer respond with an appropriate error message
   containing sufficient information to another resource.

   URIs often include structured application data in explain why the path document is
   unsuitable.

   The retrieval context and query
   components, such as paths in the base URI of a filesystem or keys CoRAL document in a database.  It
   is a common practice in many HTTP-based application programming
   interfaces (APIs) to make this part of PUT
   are the application specification,
   i.e., to prescribe fixed request URI templates that are hard-coded in
   implementations.  There are a number of problems the request.

5.1.2.  POST Requests

   A POST request with this practice
   [RFC7320], though.

   In CoRAL-based applications, a CoRAL document enclosed in the request payload
   requests that the target resource names are therefore not part process the CoRAL document
   according to the resource's own specific semantics.

   The retrieval context of a CoRAL document in a POST is defined by the application specification -- they are
   target resource's processing semantics; it can be an implementation detail. unspecified URI.
   The specification base URI of a CoRAL-based application MUST NOT mandate any
   particular form the document is the request URI of resource name structure.  BCP 190 [RFC7320]
   describes the problematic practice request.

5.2.  Returning Documents

   In a response, the meaning of fixed URI structures in more
   detail and provides some acceptable alternatives.

5.1.3.  Implementation Limits

   This a CoRAL document places no restrictions changes depending on
   the number of elements in request method and the response status code.  For example, a
   CoRAL document or in a successful response to a GET represents the depth
   current state of nested elements.  Applications using the target resource, whereas a CoRAL (in particular those running document in constrained environments) may
   wish to limit these numbers and specify implementation limits that an
   application implementation must at least support a
   successful response to be interoperable.

   Applications may also mandate the following and other restrictions:

   o  use of only a POST might represent either the binary format processing
   result or the text format;

   o  use of only either HTTP or CoAP as supported Web transfer
      protocol;

   o  use of only dictionary references new resource state.  A CoRAL document in an error
   response represents the binary format for certain
      vocabulary;

   o  use error condition, usually describing the error
   state and what next steps are suggested for resolving it.

5.2.1.  Success Responses

   Success responses have a response status code that indicates that the
   client's request was successfully received, understood, and accepted
   (2xx in HTTP, 2.xx in CoAP).  When the representation in a success
   response does not describe the state of only either content type strings or content format IDs;

   o  use the target resource, it
   describes result of CoRI references only up to processing the request.  For example, when a specific length;

   o  use of CBOR
   request has been fulfilled and has resulted in one or more new
   resources being created, a canonical format (see Section 3.9 of RFC 7049).

5.2.  Minting Vocabulary

   New CoRAL document in the response can link relation types, operation types, form field types, to
   and
   metadata names can be minted by defining an IRI [RFC3987] that
   uniquely identifies describe the item.  Although resource(s) created.

   The retrieval context and the IRI can point to base URI of a
   resource that contains CoRAL document
   representing the current state of a definition resource are the request URI of
   the semantics, clients SHOULD
   NOT automatically access request.

   The retrieval context of a CoRAL document representing a processing
   result is an unspecified URI that resource refers to avoid overburdening its
   server.  The IRI SHOULD be under the control processing result
   itself.  The base URI of the person or party
   defining it, or be delegated to them.

   To avoid interoperability problems, it document is RECOMMENDED the request URI of the
   request.

5.2.2.  Redirection Responses

   Redirection responses have a response status code that only IRIs
   are minted indicates that are normalized according
   further action needs to Section 5.3 of RFC 3987.
   Non-normalized forms that are best avoided include:

   o  Uppercase characters in scheme names and domain names
   o  Percent-encoding of characters where it is not required be taken by the IRI
      syntax

   o  Explicitly stated HTTP default port (e.g., <http://example.com/>
      is preferable over <http://example.com:80/>)

   o  Completely empty path agent (3xx in HTTP IRIs (e.g., <http://example.com/> HTTP).  A
   redirection response, for example, might indicate that the target
   resource is
      preferable over <http://example.com>)

   o  Dot segments ("/./" available at a different URI or "/../") the server offers a
   choice of multiple matching resources, each with its own specific
   URI.

   In the latter case, the representation in the path component response might contain
   a list of an IRI

   o  Lowercase hexadecimal letters within percent-encoding triplets
      (e.g., "%3F" is preferable over "%3f")

   o  Punycode-encoding resource metadata and URI references (i.e., links) from
   which the agent can choose the most preferred one.

   The retrieval context of Internationalized Domain Names in IRIs

   o  IRIs that are not a CoRAL document representing such multiple
   choices in Unicode Normalization Form C [UNICODE-UAX15]

   IRIs a redirection response is an unspecified URI that identify vocabulary do not need refers
   to be registered. the redirection itself.  The
   inclusion base URI of domain names in IRIs allows for the decentralized
   creation of new IRIs without document is the risk
   request URI of collisions.

   However, IRIs can be relatively verbose and impose a high overhead on the request.

5.2.3.  Error Responses

   Error response have a representation.  This can response status code that indicates that either
   the request cannot be a problem in constrained environments
   [RFC7228].  Therefore, CoRAL alternatively allows fulfilled or the use of unsigned
   integers server failed to reference CBOR data items from a dictionary, as specified fulfill an
   apparently valid request (4xx or 5xx in HTTP, 4.xx or 5.xx in CoAP).
   A representation in Section 3.2.  These impose a much smaller overhead but instead
   need to be assigned by an authority to avoid collisions.

5.3.  Expressing Registered Link Relation Types

   Link relation types registered in error response describes the IANA Link Relations Registry,
   such as "collection" [RFC6573] or "icon" [W3C.REC-html52-20171214],
   can be used in error condition.

   The retrieval context of a CoRAL by appending the registered name to the IRI
   <http://www.iana.org/assignments/relation/>:

      #using iana = <http://www.iana.org/assignments/relation/>

      iana:collection </items>
      iana:icon       </favicon.png>

   Note document representing such an error
   condition is an unspecified URI that registered link relation types are required refers to be
   lowercased, as per Section 3.3 of RFC 8288 [RFC8288].

   (The convention of appending the link relation types to error condition
   itself.  The base URI of the prefix
   "http://www.iana.org/assignments/relation/" to form IRIs document is adopted
   from Atom [RFC4287]; see also Appendix A.2 the request URI of RFC 8288 [RFC8288].)

5.4.  Expressing Simple RDF Statements

   An RDF statement [W3C.REC-rdf11-concepts-20140225] says that some
   relationship, indicated by a predicate, holds between two resources.
   Existing RDF vocabularies can therefore be good source for link
   relation types that describe resource metadata.  For example, a CoRAL
   document could use the FOAF vocabulary [FOAF] to describe
   request.

6.  Usage Considerations

   This section discusses some considerations in creating CoRAL-based
   applications and vocabularies.

6.1.  Specifying CoRAL-based Applications

   CoRAL-based applications naturally implement the person
   or software that made it:

      #using rdf = <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
      #using foaf = <http://xmlns.com/foaf/0.1/>

      foaf:maker null {
         rdf:type        <http://xmlns.com/foaf/0.1/Person>
         foaf:familyName "Hartke"
         foaf:givenName  "Klaus"
         foaf:mbox       <mailto:klaus.hartke@ericsson.com>
      }

5.5.  Expressing Natural Language Texts

   Text strings that Web architecture
   [W3C.REC-webarch-20041215] and thus are the target of a link can be associated with a
   language tag [RFC5646] centered around orthogonal
   specifications for identification, interaction, and a base text direction (i.e., right-to-left representation:

   *  Resources are identified by IRIs or left-to-right) represented by nesting links literal values.

   *  Interactions are based on the hypermedia interaction model of type <http://coreapps.org/
   base#language> the
      Web and <http://coreapps.org/base#direction> under that
   link, respectively:

      #using <http://coreapps.org/base#>
      #using iana = <http://www.iana.org/assignments/relation/>

      iana:terms-of-service </tos> {
         title "Nutzungsbedingungen" {
            language "de"
            direction "ltr"
         }
         title "Terms of use" {
            language "en-US"
            direction "ltr"
         }
      } the methods provided by the Web transfer protocol.  The
      semantics of possible interactions are identified by link relation
      types <http://coreapps.org/base#language> and
   <http://coreapps.org/base#direction> operation types.

   *  Representations are defined in Appendix A.

5.6.  Embedding CoRAL in CBOR Data

   Data items documents encoded in the CoRAL binary format (Section 3)
      defined in Section 3 or the textual format defined in Section 4.
      Depending on the application, additional representation formats
      may be embedded in
   other CBOR data [RFC7049] data. used.

6.1.1.  Application Interfaces

   Specifications using CDDL [RFC8610]
   SHOULD reference for CoRAL-based applications need to list the specific
   components used in the application interface and their identifiers.
   This should include the following CDDL definitions for this purpose:

      CoRAL-Document = document

      CoRAL-Link = items:

   *  The Web transfer protocols supported.

   *  The representation formats used, identified by their Internet
      media types, including the CoRAL serialization formats.

   *  The link

      CoRAL-Form = relation types used.

   *  The operation types used.  Additionally, for each operation type,
      the permissible request methods.

   *  The form

   For field types used.  Additionally, for each embedded document, link, and form, form field
      type, the retrieval context,
   link context, and permissible form context needs to be specified, respectively.

5.7.  Submitting CoRAL Documents

   By default, a CoRAL document is field values.

6.1.2.  Resource Identifiers

   URIs [RFC3986] are a representation that captures the
   current state cornerstone of a resource.  The meaning Web-based applications.  They
   enable the uniform identification of resources and are used every
   time a CoRAL document changes
   when it is submitted in client interacts with a request.  Depending on the request method,
   the CoRAL document can capture the intended state of server or a resource (PUT)
   or be subject representation
   needs to application-specific processing (POST).

5.7.1.  PUT Requests

   A PUT request with refer to another resource.

   URIs often include structured application data in the path and query
   components, such as paths in a CoRAL document enclosed filesystem or keys in a database.  It
   is a common practice in HTTP-based application programming interfaces
   (APIs) to make this part of the request payload
   requests application specification, i.e., to
   prescribe fixed URI templates that the state are hard-coded in implementations.
   However, there are a number of the target resource be created or replaced problems with this practice
   [I-D.nottingham-rfc7320bis].

   In CoRAL-based applications, resource names are therefore not part of
   the state described by the CoRAL document.  A successful PUT application specification -- they are an implementation detail.
   The specification of a CoRAL document generally means that a subsequent GET on that same
   target CoRAL-based application MUST NOT mandate any
   particular form of resource would result name structure.

   BCP 190 [I-D.nottingham-rfc7320bis] describes the problematic
   practice of fixed URI structures in an equivalent more detail and provides some
   acceptable alternatives.

6.1.3.  Implementation Limits

   This document being sent places no restrictions on the number of elements in a success response.

   An origin server SHOULD verify that a submitted
   CoRAL document is
   consistent with any constraints the server has for the target
   resource.  When a document is inconsistent with the target resource,
   the origin server SHOULD either make it consistent (e.g., by removing
   inconsistent elements) or respond with the depth of nested elements.  Applications using
   CoRAL (in particular those running in constrained environments) may
   limit these numbers and give specific implementation limits that an appropriate error message
   containing sufficient information
   application implementation must at least support to explain why be interoperable.

   Applications may also mandate the document is
   unsuitable.

   The retrieval context following and other restrictions:

   *  Use of only either the binary format or the text format.

   *  Use of only either HTTP or CoAP as the base URI supported Web transfer
      protocol.

   *  Use of a CoRAL document only dictionary references in a PUT
   are the request URI binary format for certain
      vocabulary.

   *  Use of the request.

5.7.2.  POST Requests

   A POST request with URI references and CoRI references only up to a CoRAL document enclosed in specific
      length.

6.2.  Minting Vocabulary

   New link relation types, operation types, and form field types can be
   minted by defining an IRI [RFC3987] that uniquely identifies the request payload
   requests
   item.  Although the IRI can point to a resource that contains a
   definition of the target semantics, clients SHOULD NOT automatically access
   that resource process to avoid overburdening its server.  The IRI SHOULD be
   under the CoRAL document control of the person or party defining it, or be delegated
   to them.

   To avoid interoperability problems, it is RECOMMENDED that only IRIs
   are minted that are normalized according to the resource's own specific semantics.

   The retrieval context Section 5.3 of a CoRAL document RFC 3987.
   Non-normalized forms that are best avoided include:

   *  Uppercase characters in a POST scheme names and domain names

   *  Percent-encoding of characters where it is not required by the IRI
      syntax

   *  Explicitly stated HTTP default port (e.g., <http://example.com/>
      is preferable over <http://example.com:80/>)

   *  Completely empty path in HTTP IRIs (e.g., <http://example.com/> is
      preferable over <http://example.com>)

   *  Dot segments ("/./" or "/../") in the path component of an unspecified
   URI. IRI

   *  Lowercase hexadecimal letters within percent-encoding triplets
      (e.g., "%3F" is preferable over "%3f")

   *  Punycode-encoding of Internationalized Domain Names in IRIs

   *  IRIs that are not in Unicode Normalization Form C [UAX15]

   IRIs that identify vocabulary do not need to be registered.  The base URI
   inclusion of domain names in IRIs allows for the document is the request URI decentralized
   creation of new IRIs without the request.

5.8.  Returning CoRAL Documents

   In a response, the meaning risk of a CoRAL document changes depending on
   the request method collisions.

   However, IRIs can be relatively verbose and the response status code.  For example, impose a
   CoRAL document in high overhead on
   a successful response to representation.  This can be a GET represents problem in constrained environments
   [RFC7228].  Therefore, CoRAL alternatively allows the
   current state use of the target resource, whereas unsigned
   integers to reference CBOR data items from a CoRAL document dictionary, as specified
   in Section 3.2.  These impose a
   successful response much smaller overhead but instead
   need to a POST might represent either be assigned by an authority to avoid collisions.

6.3.  Expressing Registered Link Relation Types

   Link relation types registered in the processing
   result IANA Link Relations Registry,
   such as "collection" [RFC6573] or the new resource state.  A CoRAL document "icon" [W3C.REC-html52-20171214],
   can be used in an error
   response represents CoRAL by appending the error condition, usually describing registered name to 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 IRI
   <http://www.iana.org/assignments/relation/>:

      #using iana = <http://www.iana.org/assignments/relation/>

      iana:collection </items>
      iana:icon       </favicon.png>

   The convention of appending the
   client's request was successfully received, understood, and accepted.
   When relation type name to the representation in prefix
   "http://www.iana.org/assignments/relation/" to form IRIs is adopted
   from Atom [RFC4287]; see also Appendix A.2 of RFC 8288 [RFC8288].

   Note that registered relation type names are required to be lowercase
   ASCII letters (Section 3.3 of RFC 8288).

6.4.  Expressing Simple RDF Statements

   An RDF statement [W3C.REC-rdf11-concepts-20140225] says that some
   relationship, indicated by a success response does not predicate, holds between two resources.
   Existing RDF vocabularies can therefore be good source for link
   relation types that describe the
   state of the target resource, it describes result of processing the
   request. resource metadata.  For example, when a request has been fulfilled and has resulted in
   one or more new resources being created, a CoRAL
   document in could use the
   response can link FOAF vocabulary [FOAF] to and describe the resource(s) created.

   The retrieval context person
   or software that made it:

      #using rdf = <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
      #using foaf = <http://xmlns.com/foaf/0.1/>

      foaf:maker null {
         rdf:type        <http://xmlns.com/foaf/0.1/Person>
         foaf:familyName "Hartke"
         foaf:givenName  "Klaus"
         foaf:mbox       <mailto:klaus.hartke@ericsson.com>
      }

6.5.  Expressing Natural Language Texts

   Text strings that are the target of a link can be associated with a
   language tag [RFC5646] and a base text direction (i.e., right-to-left
   or left-to-right) by nesting links of type <http://coreapps.org/
   base#language> and <http://coreapps.org/base#direction> under that
   link, respectively:

      #using <http://coreapps.org/base#>
      #using iana = <http://www.iana.org/assignments/relation/>

      iana:terms-of-service </tos> {
         title "Nutzungsbedingungen" {
            language "de"
            direction "ltr"
         }
         title "Terms of use" {
            language "en-US"
            direction "ltr"
         }
      }

   The link relation types <http://coreapps.org/base#language> and
   <http://coreapps.org/base#direction> are defined in Appendix A.

6.6.  Embedding Representations in CoRAL document representing

   When a processing
   result is document links to many Web resources and an unspecified URI that refers agent needs a
   representation of each of them, it can be inefficient to the processing result
   itself.  The base URI retrieve
   each representations individually.  To minimize round-trips,
   documents can embed representations of the resources.

   A representation can be embedded in a document is the request URI of the
   request.

5.8.2.  Error Responses

   Error response by including a link of
   type <http://coreapps.org/base#representation>:

      #using <http://coreapps.org/base#>
      #using http = <http://coreapps.org/http#>
      #using iana = <http://www.iana.org/assignments/relation/>

      iana:icon </favicon.gif> {
         representation
            b64'R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAIAOw==' {
            http:type "image/gif"
         }
      }

   An embedded representation should have a response status code nested link of type
   <http://coreapps.org/http#type> or <http://coreapps.org/coap#type>
   that indicates that either the request cannot be fulfilled or content type of the server failed to fulfill an
   apparently valid request.  A representation representation.

   The link relation types <http://coreapps.org/base#representation>,
   <http://coreapps.org/http#type>, and <http://coreapps.org/coap#type>
   are defined in Appendix A.

6.7.  Embedding CoRAL in CBOR Representations

   Data items in an error response
   describes the error condition.

   The retrieval context of such a CoRAL binary format (Section 3) may be embedded in
   other CBOR structures [I-D.ietf-cbor-7049bis].  Specifications using
   CDDL [RFC8610] can reference the following CDDL definitions for this
   purpose:

      CoRAL-Document = document representing an error
   condition is an unspecified URI that refers to

      CoRAL-Link = link

      CoRAL-Form = form

   For each embedded document, link, and form, the error condition
   itself.  The base URI of specification for the
   embedding CBOR structure needs to specify the document is retrieval
   context, the request URI of link context, and the
   request.

6. form context, respectively.

7.  Security Considerations

   Parsers of

   CoRAL documents must operate on input that is assumed document processors need to be untrusted.  This means that parsers MUST fail gracefully in the
   face fully prepared for all types of malicious inputs (e.g., inputs not adhering
   hostile input that may be designed to corrupt, overrun, or achieve
   control of the data
   structure).  Additionally, parsers MUST agent processing the document.  For example, hostile
   input may be prepared constructed to deal with
   resource exhaustion (e.g., resulting from the allocation of overrun buffers, allocate very big data
   items)
   structures, or exhaustion of exhaust the call stack (stack overflow). depth by setting up deeply nested
   elements.  Processors need to have appropriate resource management to
   mitigate these attacks.

   CoRAL serializations serialization formats intentionally do not feature the
   equivalent of XML entity references so as to preclude the whole entire
   class of attacks relating to these, them, such as exponential XML entity
   expansion ("billion laughs") [CAPEC-197] and malicious XML entity
   linking [CAPEC-201].

   Implementers of the CoRAL binary format need to consider the security
   aspects of processing CBOR with the restrictions described in decoding CBOR.  See Section 3.  Notably, XX of RFC XXXX
   [I-D.ietf-cbor-7049bis] for security considerations relating to CBOR.
   In particular, different number representations encodings for the same numeric value
   are not equivalent in the CoRAL binary format.  See
   Section 8 (e.g., a floating-point value of RFC 7049 [RFC7049] for security considerations relating
   to CBOR. 0.0 is
   not the same as the integer 0).

   Implementers of the CoRAL textual format need to consider the
   security aspects of handling Unicode input.  See the Unicode Standard
   Annex Technical
   Report #36 [UNICODE-UAX36] [UTR36] for security considerations relating to visual
   spoofing and misuse of character encodings.  See Section 10 of RFC
   3629 [RFC3629] for security considerations relating to UTF-8.  See
   Unicode Technical Standard #39 [UTS39] for security mechanisms that
   can be used to detect possible security problems relating to Unicode.

   CoRAL makes extensive use of resource identifiers.  See Section 7 of
   RFC 3986 [RFC3986] for security considerations relating to URIs.  See
   Section 8 of RFC 3987 [RFC3987] for security considerations relating
   to IRIs.  See Section X XX of RFC XXXX [I-D.ietf-core-href] for
   security considerations relating to CoRIs.

   The security of applications using CoRAL can depend on the proper
   preparation and comparison of internationalized strings.  For
   example, such strings can be used to make authentication and
   authorization decisions, and the security of an application could be
   compromised if an entity providing a given string is connected to the
   wrong account or online resource based on different interpretations
   of the string.  See RFC 6943 [RFC6943] for security considerations
   relating to identifiers in IRIs and other places. strings.

   CoRAL is intended to be used in conjunction with a Web transfer
   protocol like HTTP or CoAP.  See Section 9 of RFC 7230 [RFC7230],
   Section 9 of RFC 7231 [RFC7231], etc., for security considerations
   relating to HTTP.  See Section 11 of RFC 7252 [RFC7252] for security
   considerations relating to CoAP.

   CoRAL does not define any specific mechanisms for protecting the
   confidentiality and integrity of CoRAL documents.  It relies on
   security mechanisms on the application layer or transport layer mechanisms for
   this, such as Transport Layer Security (TLS) [RFC8446].

   CoRAL documents and the structure of a web of resources revealed from
   automatically following links can disclose personal information and
   other sensitive information.  Implementations need to prevent the
   unintentional disclosure of such information.  See Section of 9 of RFC
   7231 [RFC7231] for additional considerations.

   Applications using CoRAL ought to consider the attack vectors opened
   by automatically following, trusting, or otherwise using links and
   forms in CoRAL documents.  Notably,  See Section 5 of RFC 8288 [RFC8288] for
   related considerations.

   In particular, when a server that CoRAL document is authoritative
   for the CoRAL representation of a
   resource, the server that is authoritative for that resource may not
   necessarily be authoritative for nested elements in the document.  See Section 5 of
   RFC 8288 [RFC8288] for related considerations.

   Unless  In
   this case, unless an application mitigates this risk by specifying more defines specific rules, any link or
   form in a document where the link or form link/form context and the document's retrieval context don't
   do not share the same Web origin [RFC6454] MUST should be discarded
   ("same-origin policy").

7.

8.  IANA Considerations

7.1.

8.1.  Media Type "application/coral+cbor"

   This document registers the media type "application/coral+cbor"
   according to the procedures of BCP 13 [RFC6838].

   Type name:
      application

   Subtype name:
      coral+cbor

   Required parameters:
      N/A

   Optional parameters:
      dictionary - See Section 3.2 of [I-D.ietf-core-coral].

   Encoding considerations:
      binary - See Section 3 of [I-D.ietf-core-coral].

   Security considerations:
      See Section 6 7 of [I-D.ietf-core-coral].

   Interoperability considerations:
      N/A

   Published specification:
      [I-D.ietf-core-coral]

   Applications that use this media type:
      See Section 1 of [I-D.ietf-core-coral].

   Fragment identifier considerations:
      As specified for "application/cbor".

   Additional information:
      Deprecated alias names for this type: N/A

      Magic number(s): N/A

      File extension(s): .coral.cbor

      Macintosh file type code(s): N/A

   Person & email address to contact for further information:
      See the Author's Address section of [I-D.ietf-core-coral].

   Intended usage:
      COMMON

   Restrictions on usage:
      N/A

   Author:
      See the Author's Address section of [I-D.ietf-core-coral].

   Change controller:
      IESG

   Provisional registration?
      No

7.2.

8.2.  Media Type "text/coral"

   This document registers the media type "text/coral" according to the
   procedures of BCP 13 [RFC6838] and guidelines in of RFC 6657 [RFC6657].

   Type name:
      text

   Subtype name:
      coral

   Required parameters:
      N/A

   Optional parameters:
      N/A

   Encoding considerations:
      binary - See Section 4 of [I-D.ietf-core-coral].

   Security considerations:
      See Section 6 7 of [I-D.ietf-core-coral].

   Interoperability considerations:
      N/A

   Published specification:
      [I-D.ietf-core-coral]

   Applications that use this media type:
      See Section 1 of [I-D.ietf-core-coral].

   Fragment identifier considerations:
      N/A

   Additional information:
      Deprecated alias names for this type: N/A

      Magic number(s): N/A

      File extension(s): .coral

      Macintosh file type code(s): N/A

   Person & email address to contact for further information:
      See the Author's Address section of [I-D.ietf-core-coral].

   Intended usage:
      COMMON

   Restrictions on usage:
      N/A

   Author:
      See the Author's Address section of [I-D.ietf-core-coral].

   Change controller:
      IESG

   Provisional registration?
      No

7.3.

8.3.  CoAP Content Formats

   This document registers CoAP content formats for the content types
   "application/coral+cbor" and "text/coral" according to the procedures
   of RFC 7252 [RFC7252].

   o

   *  Content Type:  application/coral+cbor
      Content Coding:  identity
      ID:  TBD3
      Reference:  [I-D.ietf-core-coral]

   o

   *  Content Type:  text/coral
      Content Coding:  identity
      ID:  TBD4
      Reference:  [I-D.ietf-core-coral]

   [[NOTE TO RFC EDITOR: Please replace all occurrences of "TBD3" and
   "TBD4" in this document with the code points assigned by IANA.]]

   [[NOTE TO IMPLEMENTERS: Experimental implementations can use content
   format ID 65087 for "application/coral+cbor" and content format ID
   65343 for "text/coral" until IANA has assigned code points.]]

7.4.

8.4.  CBOR Tag

   This document registers a CBOR tag for dictionary references
   according to the procedures of RFC 7049 [RFC7049].

   o XXXX [I-D.ietf-cbor-7049bis].

   *  Tag:  TBD6
      Data Item:  unsigned integer
      Semantics:  Dictionary reference
      Reference:  [I-D.ietf-core-coral]

   [[NOTE TO RFC EDITOR: Please replace all occurrences of "TBD6" in
   this document with the code point assigned by IANA.]]

8.

9.  References

8.1.

9.1.  Normative References

   [I-D.ietf-cbor-7049bis]
              Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", Work in Progress, Internet-Draft,
              draft-ietf-cbor-7049bis-12, 18 December 2019,
              <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-12>.

   [I-D.ietf-core-href]
              Hartke, K., "Constrained Resource Identifiers", draft-
              ietf-core-href-01 (work Work in progress), November 2019.
              Progress, Internet-Draft, draft-ietf-core-href-02, 8
              January 2020,
              <https://tools.ietf.org/html/draft-ietf-core-href-02>.

   [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>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
              January 2005, <https://www.rfc-editor.org/info/rfc3987>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/info/rfc6454>.

   [RFC6657]  Melnikov, A. and J. Reschke, "Update to MIME regarding
              "charset" Parameter Handling in Textual Media Types",
              RFC 6657, DOI 10.17487/RFC6657, July 2012,
              <https://www.rfc-editor.org/info/rfc6657>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [UAX15]    The Unicode Consortium, "Unicode Standard Annex #15:
              Unicode Normalization Forms",
              <http://unicode.org/reports/tr15/>.

   [UAX31]    The Unicode Consortium, "Unicode Standard Annex #31:
              Unicode Identifier and Pattern Syntax",
              <http://unicode.org/reports/tr31/>.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
              <http://www.unicode.org/versions/latest/>.  Note that this
              reference is to the latest version of Unicode, rather than
              to a specific release.  It is not expected that future
              changes in the Unicode specification will have any impact
              on this document.

   [UNICODE-UAX15]
              The Unicode Consortium, "Unicode Standard Annex #15:
              Unicode Normalization Forms",
              <http://unicode.org/reports/tr15/>.

   [UNICODE-UAX31]
              The Unicode Consortium, "Unicode Standard Annex #31:
              Unicode Identifier and Pattern Syntax",
              <http://unicode.org/reports/tr31/>.

   [UNICODE-UAX36]
              The Unicode Consortium, "Unicode Standard Annex #36:
              Unicode Security Considerations",
              <http://unicode.org/reports/tr36/>.

8.2.

9.2.  Informative References

   [CAPEC-197]
              MITRE, "CAPEC-197: XML Entity Expansion", 30 September
              2019, <https://capec.mitre.org/data/definitions/197.html>.

   [CAPEC-201]
              MITRE, "CAPEC-201: XML Entity Linking", 30 September 2019,
              <https://capec.mitre.org/data/definitions/201.html>.

   [FOAF]     Brickley, D. and L. Miller, "FOAF Vocabulary Specification
              0.99", 14 January 2014,
              <http://xmlns.com/foaf/spec/20140114.html>.

   [HAL]      Kelly, M., "JSON Hypertext Application Language", draft-
              kelly-json-hal-08 (work Work in progress),
              Progress, Internet-Draft, draft-kelly-json-hal-08, 12 May 2016.
              2016,
              <https://tools.ietf.org/html/draft-kelly-json-hal-08>.

   [I-D.nottingham-rfc7320bis]
              Nottingham, M., "URI Design and Ownership", Work in
              Progress, Internet-Draft, draft-nottingham-rfc7320bis-03,
              5 January 2020, <https://tools.ietf.org/html/draft-
              nottingham-rfc7320bis-03>.

   [RFC4287]  Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
              Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
              December 2005, <https://www.rfc-editor.org/info/rfc4287>.

   [RFC5789]  Dusseault, L. and J. Snell, "PATCH Method for HTTP",
              RFC 5789, DOI 10.17487/RFC5789, March 2010,
              <https://www.rfc-editor.org/info/rfc5789>.

   [RFC6573]  Amundsen, M., "The Item and Collection Link Relations",
              RFC 6573, DOI 10.17487/RFC6573, April 2012,
              <https://www.rfc-editor.org/info/rfc6573>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/info/rfc6690>.

   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
              2013, <https://www.rfc-editor.org/info/rfc6943>.

   [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>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [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>.

   [RFC7320]  Nottingham, M., "URI Design and Ownership", BCP 190,
              RFC 7320, DOI 10.17487/RFC7320, July 2014,
              <https://www.rfc-editor.org/info/rfc7320>.

   [RFC8132]  van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
              FETCH Methods for the Constrained Application Protocol
              (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
              <https://www.rfc-editor.org/info/rfc8132>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/info/rfc8288>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [UTR36]    The Unicode Consortium, "Unicode Technical Report #36:
              Unicode Security Considerations",
              <http://unicode.org/reports/tr36/>.

   [UTS39]    The Unicode Consortium, "Unicode Technical Standard #39:
              Unicode Security Mechanisms",
              <http://unicode.org/reports/tr39/>.

   [W3C.REC-html52-20171214]
              Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and
              S. Moon, "HTML 5.2", World Wide Web Consortium
              Recommendation REC-html52-20171214, 14 December 2017,
              <https://www.w3.org/TR/2017/REC-html52-20171214>.

   [W3C.REC-rdf-schema-20140225]
              Brickley, D. and R. Guha, "RDF Schema 1.1", World Wide Web
              Consortium Recommendation REC-rdf-schema-20140225, 25
              February 2014,
              <http://www.w3.org/TR/2014/REC-rdf-schema-20140225>.

   [W3C.REC-rdf11-concepts-20140225]
              Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1
              Concepts and Abstract Syntax", World Wide Web Consortium
              Recommendation REC-rdf11-concepts-20140225, 25 February
              2014,
              <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225>.

   [W3C.REC-turtle-20140225]
              Prud&#039;hommeaux, E. and G. Carothers, "RDF 1.1 Turtle",
              World Wide Web Consortium Recommendation REC-turtle-
              20140225, 25 February 2014,
              <http://www.w3.org/TR/2014/REC-turtle-20140225>.

   [W3C.REC-webarch-20041215]
              Jacobs, I. and N. Walsh, "Architecture of the World Wide
              Web, Volume One", World Wide Web Consortium
              Recommendation REC-webarch-20041215, 15 December 2004,
              <http://www.w3.org/TR/2004/REC-webarch-20041215>.

Appendix A.  Core Vocabulary

   This section defines the core vocabulary for CoRAL: a set of link
   relation types, operation types, form field types, and metadata
   names. and form field types.

A.1.  Base

   Link Relation Types:

   <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
      Indicates that the link's context is an instance of the class
      specified as the link's target, as defined by RDF Schema
      [W3C.REC-rdf-schema-20140225].

   <http://coreapps.org/base#title>
      Indicates that the link target is a human-readable label (e.g., a
      menu entry).

      The link target MUST be a text string.  The text string SHOULD be
      annotated with a language and text direction using nested links of
      type <http://coreapps.org/base#language> and <http://coreapps.org/
      base#direction>, respectively.

   <http://coreapps.org/base#language>
      Indicates that the link target is a language tag [RFC5646] that
      specifies the language of the link context.

      The link target MUST be a text string in the format specified in
      Section 2.1 of RFC 5646 [RFC5646].

   <http://coreapps.org/base#direction>
      Indicates that the link target is a base text direction (right-to-
      left or left-to-right) that specifies the text directionality of
      the link context.

      The link target MUST be either the text string "rtl" or the text
      string "ltr".

   <http://coreapps.org/base#representation>
      Indicates that the link target is a representation of the link
      context.

      The link target MUST be a byte string.

      The representation may be a full, partial, or inconsistent version
      of the representation served from the URI of the resource.

      A link with link relation type can occur as a top-level element in
      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 document's retrieval context.  When it occurs nested within a
      link, it provides a representation of link target of the enclosing
      link.

   Operation Types:

   <http://coreapps.org/base#update>
      Indicates that the state of the form's context can be replaced
      with the state described by a representation submitted to the
      server.

      This operation type defaults to the PUT method [RFC7231] [RFC7252]
      for both HTTP and CoAP.  Typical overrides by a form field include
      the PATCH method [RFC5789] [RFC8132] for HTTP and CoAP and the
      iPATCH method [RFC8132] for CoAP.

   <http://coreapps.org/base#search>
      Indicates that the form's context can be searched by submitting a
      search query.

      This operation type defaults to the POST method [RFC7231] for HTTP
      and the FETCH method [RFC8132] for CoAP.  Typical overrides by a
      form field include the POST method [RFC7252] for CoAP.

A.2.  Collections

   Link Relation Types:

   <http://www.iana.org/assignments/relation/item>
      Indicates that the link's context is a collection and that the
      link's target is a member of that collection, as defined in
      Section 2.1 of RFC 6573 [RFC6573].

   <http://www.iana.org/assignments/relation/collection>
      Indicates that the link's target is a collection and that the
      link's context is a member of that collection, as defined in
      Section 2.2 of RFC 6573 [RFC6573].

   Operation Types:

   <http://coreapps.org/collections#create>
      Indicates that the form's context is a collection and that a new
      item can be created in that collection with the state defined by a
      representation submitted to the server.

      This operation type defaults to the POST method [RFC7231]
      [RFC7252] for both HTTP and CoAP.

   <http://coreapps.org/collections#delete>
      Indicates that the form's context is a member of a collection and
      that the form's context can be removed from that collection.

      This operation type defaults to the DELETE method [RFC7231]
      [RFC7252] for both HTTP and CoAP.

A.3.  HTTP

   Form Field Types:

   <http://coreapps.org/http#method>
      Specifies the HTTP method for the request.

      The form field value MUST be a text string in the format defined
      in Section 4.1 of RFC 7231 [RFC7231].  The set of possible values
      is maintained in the IANA HTTP Method Registry.

      A form field of this type MUST NOT occur more than once in a form.
      If absent, it defaults to the request method implied by the form's
      operation type.

   <http://coreapps.org/http#accept>
      Specifies an acceptable HTTP content type for the request payload.
      There may be multiple form fields of this type.  If a form does
      not include a form field of this type, the server accepts any or
      no request payload, depending on the operation type.

      The form field value MUST be a text string in the format defined
      in Section 3.1.1.1 of RFC 7231 [RFC7231].  The possible set of
      media types and their parameters are maintained in the IANA Media
      Types Registry.

   Representation Metadata:

   Link Relation Types:

   <http://coreapps.org/http#type>
      Specifies the HTTP content type of the representation. link context.

      The metadata value link target MUST be specified as a text string in the format defined in
      Section 3.1.1.1 of RFC 7231 [RFC7231].  The possible set of media
      types and their parameters are maintained in the IANA Media Types
      Registry.

      Metadata

      A link of this type MUST NOT occur more than once for a
      representation. the link
      context.  If absent, its value defaults to the content type
      "application/octet-stream".

A.4.  CoAP

   Form Field Types:

   <http://coreapps.org/coap#method>
      Specifies the CoAP method for the request.

      The form field value MUST be an integer identifying one of the
      CoAP request methods maintained in the IANA CoAP Method Codes
      Registry (e.g., the integer 2 for the POST method).

      A form field of this type MUST NOT occur more than once in a form.
      If absent, it defaults to the request method implied by the form's
      operation type.

   <http://coreapps.org/coap#accept>
      Specifies an acceptable CoAP content format for the request
      payload.  There may be multiple form fields of this type.  If a
      form does not include a form field of this type, the server
      accepts any or no request payload, depending on the operation
      type.

      The form field value MUST be an integer identifying one of the
      content formats maintained in the IANA CoAP Content-Formats
      Registry.

   Representation Metadata:

   Link Relation Types:

   <http://coreapps.org/coap#type>
      Specifies the CoAP content format of the representation. link context.

      The metadata value link target MUST be an integer identifying one of the content
      formats maintained in the IANA CoAP Content-Formats Registry.

      Metadata

      A link of this type MUST NOT occur more than once for a
      representation. the link
      context.  If absent, it defaults to content format 42 (i.e., the
      content type "application/octet-stream" without a content coding).

Appendix B.  Default Dictionary

   This section defines a default dictionary that is assumed when the
   "application/coral+cbor" media type is used without a "dictionary"
   parameter.

      +-----+-------------------------------------------------------+
      | Key | Value                                                 |
      +-----+-------------------------------------------------------+
      +=====+=======================================================+
      |   0 | <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>     |
      +-----+-------------------------------------------------------+
      |   1 | <http://www.iana.org/assignments/relation/item>       |
      +-----+-------------------------------------------------------+
      |   2 | <http://www.iana.org/assignments/relation/collection> |
      +-----+-------------------------------------------------------+
      |   3 | <http://coreapps.org/collections#create>              |
      +-----+-------------------------------------------------------+
      |   4 | <http://coreapps.org/base#update>                     |
      +-----+-------------------------------------------------------+
      |   5 | <http://coreapps.org/collections#delete>              |
      +-----+-------------------------------------------------------+
      |   6 | <http://coreapps.org/base#search>                     |
      +-----+-------------------------------------------------------+
      |   7 | <http://coreapps.org/coap#accept>                     |
      +-----+-------------------------------------------------------+
      |   8 | <http://coreapps.org/coap#type>                       |
      +-----+-------------------------------------------------------+
      |   9 | <http://coreapps.org/base#language>                   |
      +-----+-------------------------------------------------------+
      |  10 | <http://coreapps.org/coap#method>                     |
      +-----+-------------------------------------------------------+
      |  11 | <http://coreapps.org/base#direction>                  |
      +-----+-------------------------------------------------------+
      |  12 | "ltr"                                                 |
      +-----+-------------------------------------------------------+
      |  13 | "rtl"                                                 |
      +-----+-------------------------------------------------------+
      |  14 | <http://coreapps.org/base#representation>             |
      +-----+-------------------------------------------------------+

                        Table 2: 3: Default Dictionary

Appendix C.  Change Log

   This section is to be removed before publishing as an RFC.

   Changes from -01 to -02:

   *  Added nested elements to form fields.

   *  Replaced the special construct for embedded representations with
      links.

   *  Changed the textual format to allow simple/qualified names
      wherever IRI references are allowed.

   *  Introduced predefined names in the textual format (#39).

   *  Minor editorial improvements and bug fixes.

   Changes from -00 to -01:

   *  Added a section on the semantics of CoRAL documents in responses.

   *  Minor editorial improvements.

Acknowledgements

   CoRAL is heavily inspired by Mike Kelly's JSON Hypertext Application
   Language [HAL].

   This document has benefited greatly

   The recommendations for minting IRIs have been adopted from discussions RDF 1.1
   Concepts and reviews of Abstract Syntax [W3C.REC-rdf11-concepts-20140225] to
   ease the CoRAL design team: interoperability between RDF predicates and link relation
   types.

   Thanks to Christian Amsuess
      <christian@amsuess.com> Amsuess, 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, Jim Schaad, Sebastian Kaebisch, Ari Keranen, Michael Koster,
   Matthias Kovatsch, and Niklas Widell for helpful comments and
   discussions that have shaped the document.

Author's Address

   Klaus Hartke
   Ericsson
   Torshamnsgatan 23
   Stockholm
   SE-16483 Stockholm
   Sweden

   Email: klaus.hartke@ericsson.com