draft-ietf-cbor-cddl-02.txt   draft-ietf-cbor-cddl-03.txt 
Network Working Group H. Birkholz Network Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Standards Track C. Vigano Intended status: Standards Track C. Vigano
Expires: August 30, 2018 Universitaet Bremen Expires: January 3, 2019 Universitaet Bremen
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
February 26, 2018 July 02, 2018
Concise data definition language (CDDL): a notational convention to Concise data definition language (CDDL): a notational convention to
express CBOR data structures express CBOR data structures
draft-ietf-cbor-cddl-02 draft-ietf-cbor-cddl-03
Abstract Abstract
This document proposes a notational convention to express CBOR data This document proposes a notational convention to express CBOR data
structures (RFC 7049). Its main goal is to provide an easy and structures (RFC 7049). Its main goal is to provide an easy and
unambiguous way to express structures for protocol messages and data unambiguous way to express structures for protocol messages and data
formats that use CBOR. formats that use CBOR.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
3.8.6. Control operators .lt, .le, .gt, .ge, .eq, .ne, and 3.8.6. Control operators .lt, .le, .gt, .ge, .eq, .ne, and
.default . . . . . . . . . . . . . . . . . . . . . . 26 .default . . . . . . . . . . . . . . . . . . . . . . 26
3.9. Socket/Plug . . . . . . . . . . . . . . . . . . . . . . . 27 3.9. Socket/Plug . . . . . . . . . . . . . . . . . . . . . . . 27
3.10. Generics . . . . . . . . . . . . . . . . . . . . . . . . 28 3.10. Generics . . . . . . . . . . . . . . . . . . . . . . . . 28
3.11. Operator Precedence . . . . . . . . . . . . . . . . . . . 28 3.11. Operator Precedence . . . . . . . . . . . . . . . . . . . 28
4. Making Use of CDDL . . . . . . . . . . . . . . . . . . . . . 30 4. Making Use of CDDL . . . . . . . . . . . . . . . . . . . . . 30
4.1. As a guide to a human user . . . . . . . . . . . . . . . 30 4.1. As a guide to a human user . . . . . . . . . . . . . . . 30
4.2. For automated checking of CBOR data structure . . . . . . 30 4.2. For automated checking of CBOR data structure . . . . . . 30
4.3. For data analysis tools . . . . . . . . . . . . . . . . . 31 4.3. For data analysis tools . . . . . . . . . . . . . . . . . 31
5. Security considerations . . . . . . . . . . . . . . . . . . . 31 5. Security considerations . . . . . . . . . . . . . . . . . . . 31
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
6.1. CDDL control operator registry . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32 7.1. Normative References . . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . 32 7.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. (Not used.) . . . . . . . . . . . . . . . . . . . . 33 Appendix A. (Not used.) . . . . . . . . . . . . . . . . . . . . 34
Appendix B. ABNF grammar . . . . . . . . . . . . . . . . . . . . 33 Appendix B. ABNF grammar . . . . . . . . . . . . . . . . . . . . 34
Appendix C. Matching rules . . . . . . . . . . . . . . . . . . . 36 Appendix C. Matching rules . . . . . . . . . . . . . . . . . . . 36
Appendix D. (Not used.) . . . . . . . . . . . . . . . . . . . . 40 Appendix D. (Not used.) . . . . . . . . . . . . . . . . . . . . 40
Appendix E. Standard Prelude . . . . . . . . . . . . . . . . . . 40 Appendix E. Standard Prelude . . . . . . . . . . . . . . . . . . 40
E.1. Use with JSON . . . . . . . . . . . . . . . . . . . . . . 42 E.1. Use with JSON . . . . . . . . . . . . . . . . . . . . . . 42
Appendix F. The CDDL tool . . . . . . . . . . . . . . . . . . . 44 Appendix F. The CDDL tool . . . . . . . . . . . . . . . . . . . 44
Appendix G. Extended Diagnostic Notation . . . . . . . . . . . . 44 Appendix G. Extended Diagnostic Notation . . . . . . . . . . . . 44
G.1. White space in byte string notation . . . . . . . . . . . 45 G.1. White space in byte string notation . . . . . . . . . . . 45
G.2. Text in byte string notation . . . . . . . . . . . . . . 45 G.2. Text in byte string notation . . . . . . . . . . . . . . 45
G.3. Embedded CBOR and CBOR sequences in byte strings . . . . 45 G.3. Embedded CBOR and CBOR sequences in byte strings . . . . 45
G.4. Concatenated Strings . . . . . . . . . . . . . . . . . . 46 G.4. Concatenated Strings . . . . . . . . . . . . . . . . . . 46
skipping to change at page 4, line 20 skipping to change at page 4, line 20
the fact that CDDL can also be used for describing JSON data the fact that CDDL can also be used for describing JSON data
structures (see Appendix E.1). structures (see Appendix E.1).
This document has the following structure: This document has the following structure:
The syntax of CDDL is defined in Section 3. Examples of CDDL and The syntax of CDDL is defined in Section 3. Examples of CDDL and
related CBOR data items ("instances") are defined in Appendix H. related CBOR data items ("instances") are defined in Appendix H.
Section 4 discusses usage of CDDL. Examples are provided early in Section 4 discusses usage of CDDL. Examples are provided early in
the text to better illustrate concept definitions. A formal the text to better illustrate concept definitions. A formal
definition of CDDL using ABNF grammar is provided in Appendix B. definition of CDDL using ABNF grammar is provided in Appendix B.
Finally, a prelude of standard CDDL definitions available in every Finally, a _prelude_ of standard CDDL definitions that is
CBOR specification is listed in Appendix E. automatically prepended to and thus available in every CBOR
specification is listed in Appendix E.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119, BCP 14 [RFC2119]. 2119, BCP 14 [RFC2119].
1.2. Terminology 1.2. Terminology
skipping to change at page 5, line 23 skipping to change at page 5, line 23
example of a record, as is the pair of exponent (first) and example of a record, as is the pair of exponent (first) and
mantissa (second) in a CBOR decimal fraction. mantissa (second) in a CBOR decimal fraction.
o A _table_, a map from a domain of map keys to a domain of map o A _table_, a map from a domain of map keys to a domain of map
values, that are mostly of the same semantics. A set of language values, that are mostly of the same semantics. A set of language
tags, each mapped to a text string translated to that specific tags, each mapped to a text string translated to that specific
language, is an example of a table. The key domain is usually not language, is an example of a table. The key domain is usually not
limited to a specific set by the specification, but open for the limited to a specific set by the specification, but open for the
application, e.g., in a table mapping IP addresses to MAC application, e.g., in a table mapping IP addresses to MAC
addresses, the specification does not attempt to foresee all addresses, the specification does not attempt to foresee all
possible IP addresses. possible IP addresses. In a language such as JavaScript, a "Map"
(as opposed to a plain "Object") would often be employed to
achieve the generality of the key domain.
o A _struct_, a map from a domain of map keys as defined by the o A _struct_, a map from a domain of map keys as defined by the
specification to a domain of map values the semantics of each of specification to a domain of map values the semantics of each of
which is bound to a specific map key. This is what many people which is bound to a specific map key. This is what many people
have in mind when they think about JSON objects; CBOR adds the have in mind when they think about JSON objects; CBOR adds the
ability to use map keys that are not just text strings. Structs ability to use map keys that are not just text strings. Structs
can be used to solve similar problems as records; the use of can be used to solve similar problems as records; the use of
explicit map keys facilitates optionality and extensibility. explicit map keys facilitates optionality and extensibility.
Two important concepts provide the foundation for CDDL: Two important concepts provide the foundation for CDDL:
skipping to change at page 6, line 11 skipping to change at page 6, line 11
e.g. "1". A type can be built as a _choice_ of other types, e.g. "1". A type can be built as a _choice_ of other types,
e.g., an "int" is either a "uint" or a "nint" (negative integer). e.g., an "int" is either a "uint" or a "nint" (negative integer).
Finally, a type can be built as an array or a map from a group. Finally, a type can be built as an array or a map from a group.
The rest of this section introduces a number of basic concepts of The rest of this section introduces a number of basic concepts of
CDDL, and section Section 3 defines additional syntax. Appendix C CDDL, and section Section 3 defines additional syntax. Appendix C
gives a concise summary of the semantics of CDDL. gives a concise summary of the semantics of CDDL.
2.1. Groups and Composition in CDDL 2.1. Groups and Composition in CDDL
CDDL Groups are lists of name/value pairs (group _entries_). CDDL Groups are lists of group _entries_, each of which can be a
name/value pair or a more complex group expression composed of name/
value pairs.
In an array context, only the value of the entry is represented; the In an array context, only the value of the entry is represented; the
name is annotation only (and can be left off if not needed). In a name is annotation only (and can be left off if not needed). In a
map context, the names become the map keys ("member keys"). map context, the names become the map keys ("member keys").
In an array context, the sequence of elements in the group is In an array context, the sequence of elements in the group is
important, as it is the information that allows associating actual important, as it is the information that allows associating actual
array elements with entries in the group. In a map context, the array elements with entries in the group. In a map context, the
sequence of entries in a group is not relevant (but there is still a sequence of entries in a group is not relevant (but there is still a
need to write down group entries in a sequence). need to write down group entries in a sequence).
skipping to change at page 9, line 5 skipping to change at page 9, line 5
o The end of a group can be marked by ')' o The end of a group can be marked by ')'
o Definitions of entries inside of a group are noted as follows: o Definitions of entries inside of a group are noted as follows:
_keytype => valuetype,_ (read "keytype maps to valuetype"). The _keytype => valuetype,_ (read "keytype maps to valuetype"). The
comma is actually optional (not just in the final entry), but it comma is actually optional (not just in the final entry), but it
is considered good style to set it. The double arrow can be is considered good style to set it. The double arrow can be
replaced by a colon in the common case of directly using a text replaced by a colon in the common case of directly using a text
string or integer literal as a key (see Section 3.5.1). string or integer literal as a key (see Section 3.5.1).
An entry consists of a _keytype_ and a _valuetype_: A basic entry consists of a _keytype_ and a _valuetype_, both of
which are types (Section 2.2).
o _keytype_ is either an atom used as the actual key or a type in
general. The latter case may be needed when using groups in a
table context, where the actual keys are of lesser importance than
the key types, e.g in contexts verifying incoming data.
o _valuetype_ is a type, which could be derived from the major types
defined in [RFC7049], could be a convenience valuetype defined in
this document (Appendix E) or the name of a type defined in the
specification.
A group definition can also contain choices between groups, see A group definition can also contain choices between groups, see
Section 2.2.2. Section 2.2.2.
2.2. Types 2.2. Types
2.2.1. Values 2.2.1. Values
Values such as numbers and strings can be used in place of a type. Values such as numbers and strings can be used in place of a type.
(For instance, this is a very common thing to do for a keytype, (For instance, this is a very common thing to do for a keytype,
common enough that CDDL provides additional convenience syntax for common enough that CDDL provides additional convenience syntax for
this.) this.)
The value notation is based on the C language, but does not offer all
the syntactic variations Appendix B. The value notation for numbers
inherits from C the distinction between integer values (no fractional
part or exponent given -- NR1 [ISO6093]) and floating point values
(where a fractional part and/or an exponent is present -- NR2 or
NR3), so the type "1" does not include any floating point numbers
while the types "1e3" and "1.5" are both floating point Numbers and
do not include any integer numbers.
2.2.2. Choices 2.2.2. Choices
Many places that allow a type also allow a choice between types, Many places that allow a type also allow a choice between types,
delimited by a "/" (slash). The entire choice construct can be put delimited by a "/" (slash). The entire choice construct can be put
into parentheses if this is required to make the construction into parentheses if this is required to make the construction
unambiguous (please see Appendix B for the details). unambiguous (please see Appendix B for the details).
Choices of values can be used to express enumerations: Choices of values can be used to express enumerations:
attire = "bow tie" / "necktie" / "Internet attire" attire = "bow tie" / "necktie" / "Internet attire"
skipping to change at page 17, line 19 skipping to change at page 17, line 19
(we speak of a "bareword" member key), as can a double-quoted string (we speak of a "bareword" member key), as can a double-quoted string
or a number. (When other types, in particular multi-valued ones, are or a number. (When other types, in particular multi-valued ones, are
used as keytypes, they are followed by a double arrow, see below.) used as keytypes, they are followed by a double arrow, see below.)
If a text string key does not match the syntax for an identifier (or If a text string key does not match the syntax for an identifier (or
if the specifier just happens to prefer using double quotes), the if the specifier just happens to prefer using double quotes), the
text string syntax can also be used in the member key position, text string syntax can also be used in the member key position,
followed by a colon. The above example could therefore have been followed by a colon. The above example could therefore have been
written with quoted strings in the member key positions. More written with quoted strings in the member key positions. More
generally, all the types defined can be used in a keytype position by generally, all the types defined can be used in a keytype position by
following them with a double arrow. A string also is a (single- following them with a double arrow -- in particular, the double arrow
is necessary if a type is named by an identifier (which would be
interpreted as a string before a colon). A string also is a (single-
valued) type, so another form for this example is: valued) type, so another form for this example is:
located-samples = { located-samples = {
"sample-point" => int, "sample-point" => int,
"samples" => [+ float], "samples" => [+ float],
} }
See Section 3.5.3 below for how the colon shortcut described here See Section 3.5.3 below for how the colon shortcut described here
also adds some implied semantics. also adds some implied semantics.
skipping to change at page 21, line 29 skipping to change at page 21, line 29
type (for tags). type (for tags).
For example, an application might want to define a basic and an For example, an application might want to define a basic and an
advanced header. Without unwrapping, this might be done as follows: advanced header. Without unwrapping, this might be done as follows:
basic-header-group = ( basic-header-group = (
field1: int, field1: int,
field2: text, field2: text,
) )
basic-header = { basic-header-group } basic-header = [ basic-header-group ]
advanced-header = { advanced-header = [
basic-header-group, basic-header-group,
field3: bytes, field3: bytes,
field4: number, ; as in the tagged type "time" field4: number, ; as in the tagged type "time"
} ]
Unwrapping simplifies this to: Unwrapping simplifies this to:
basic-header = { basic-header = [
field1: int, field1: int,
field2: text, field2: text,
} ]
advanced-header = { advanced-header = [
~basic-header, ~basic-header,
field3: bytes, field3: bytes,
field4: ~time, field4: ~time,
} ]
(Note that leaving out the first unwrap operator in the latter (Note that leaving out the first unwrap operator in the latter
example would lead to nesting the basic-header in its own map inside example would lead to nesting the basic-header in its own array
the advanced-header, while, with the unwrapped basic-header, the inside the advanced-header, while, with the unwrapped basic-header,
definition of the group inside basic-header is essentially repeated the definition of the group inside basic-header is essentially
inside advanced-header, leading to a single map. This can be used repeated inside advanced-header, leading to a single array. This can
for various applications often solved by inheritance in programming be used for various applications often solved by inheritance in
languages. The effect of unwrapping can also be described as programming languages. The effect of unwrapping can also be
"threading in" the group or type inside the referenced type, which described as "threading in" the group or type inside the referenced
suggested the thread-like "~" character.) type, which suggested the thread-like "~" character.)
3.8. Controls 3.8. Controls
A _control_ allows to relate a _target_ type with a _controller_ type A _control_ allows to relate a _target_ type with a _controller_ type
via a _control operator_. via a _control operator_.
The syntax for a control type is "target .control-operator The syntax for a control type is "target .control-operator
controller", where control operators are special identifiers prefixed controller", where control operators are special identifiers prefixed
by a dot. (Note that _target_ or _controller_ might need to be by a dot. (Note that _target_ or _controller_ might need to be
parenthesized.) parenthesized.)
skipping to change at page 26, line 28 skipping to change at page 26, line 28
$message /= [4, noodles: text, sauce: text, parmesan: bool] $message /= [4, noodles: text, sauce: text, parmesan: bool]
For ".within", a tool might flag an error if type1 allows data items For ".within", a tool might flag an error if type1 allows data items
that are not allowed by type2. In contrast, for ".and", there is no that are not allowed by type2. In contrast, for ".and", there is no
expectation that type1 already is a subset of type2. expectation that type1 already is a subset of type2.
3.8.6. Control operators .lt, .le, .gt, .ge, .eq, .ne, and .default 3.8.6. Control operators .lt, .le, .gt, .ge, .eq, .ne, and .default
The controls .lt, .le, .gt, .ge, .eq, .ne specify a constraint on the The controls .lt, .le, .gt, .ge, .eq, .ne specify a constraint on the
left hand side type to be a value less than, less than or equal, left hand side type to be a value less than, less than or equal,
equal to, not equal to, greather than, or greater than or equal to a equal to, not equal to, greater than, or greater than or equal to a
value given as a (single-valued) right hand side type. In the value given as a (single-valued) right hand side type. In the
present specification, the first four controls (.lt, .le, .gt, .ge) present specification, the first four controls (.lt, .le, .gt, .ge)
are defined only for numeric types, as these have a natural ordering are defined only for numeric types, as these have a natural ordering
relationship. relationship.
speed = number .ge 0 ; unit: m/s speed = number .ge 0 ; unit: m/s
A variant of the ".ne" control is the ".default" control, which A variant of the ".ne" control is the ".default" control, which
expresses an additional intent: the value specified by the right- expresses an additional intent: the value specified by the right-
hand-side type is intended as a default value for the left hand side hand-side type is intended as a default value for the left hand side
type given, and the implied .ne control is there to prevent this type given, and the implied .ne control is there to prevent this
value from being sent over the wire. This control is only meaningful value from being sent over the wire. This control is only meaningful
when the controld type is used in an optional context; otherwise when the control type is used in an optional context; otherwise there
there would be no way to express the default value. would be no way to express the default value.
timer = { timer = {
time: uint, time: uint,
? displayed-step: (number .gt 0) .default 1 ? displayed-step: (number .gt 0) .default 1
} }
3.9. Socket/Plug 3.9. Socket/Plug
Both for type choices and group choices, a mechanism is defined that Both for type choices and group choices, a mechanism is defined that
facilitates starting out with empty choices and assembling them facilitates starting out with empty choices and assembling them
skipping to change at page 31, line 48 skipping to change at page 31, line 48
data structures. As such, it does not bring any security issues on data structures. As such, it does not bring any security issues on
itself, although specification of protocols that use CBOR naturally itself, although specification of protocols that use CBOR naturally
need security analysis when defined. need security analysis when defined.
Topics that could be considered in a security considerations section Topics that could be considered in a security considerations section
that uses CDDL to define CBOR structures include the following: that uses CDDL to define CBOR structures include the following:
o Where could the language maybe cause confusion in a way that will o Where could the language maybe cause confusion in a way that will
enable security issues? enable security issues?
o Where a CDDL matcher is part of the implementation of a system,
the security of the system ought not depend on the correctness of
the CDDL specification or CDDL implementation without any further
defenses in place.
Writers of CDDL specifications are strongly encouraged to value
simplicity and transparency of the specification over its elegance.
Keep it as simple as possible while still expressing the needed data
model.
A related observation about formal description techniques in general
that is strongly recommended to be kept in mind by writers of CDDL
specifications: Just because CDDL makes it easier to handle
complexity in a specification, that does not make that complexity
somehow less bad (except maybe on the level of the humans having to
grasp the complex structure while reading the spec).
6. IANA considerations 6. IANA considerations
This document does not require any IANA registrations. 6.1. CDDL control operator registry
IANA is requested ...
(TBD: define a registry of control operators. Policy to be defined,
definitely at least specification required. Designated expert should
be instructed to require a workable specification that enables
interoperability of implementations of CDDL specifications making use
of the control operator. Define initial table from the present
document.)
7. References 7. References
7.1. Normative References 7.1. Normative References
[ISO6093] ISO, "Information processing -- Representation of
numerical values in character strings for information
interchange", ISO 6093, 1985.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 33, line 7 skipping to change at page 33, line 38
Definition Language (CDDL)", draft-bormann-cbor-cddl- Definition Language (CDDL)", draft-bormann-cbor-cddl-
freezer-00 (work in progress), January 2018. freezer-00 (work in progress), January 2018.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-core-senml] [I-D.ietf-core-senml]
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Media Types for Sensor Measurement Lists Bormann, "Sensor Measurement Lists (SenML)", draft-ietf-
(SenML)", draft-ietf-core-senml-12 (work in progress), core-senml-16 (work in progress), May 2018.
December 2017.
[I-D.newton-json-content-rules] [I-D.newton-json-content-rules]
Newton, A. and P. Cordell, "A Language for Rules Newton, A. and P. Cordell, "A Language for Rules
Describing JSON Content", draft-newton-json-content- Describing JSON Content", draft-newton-json-content-
rules-09 (work in progress), September 2017. rules-09 (work in progress), September 2017.
[RELAXNG] ISO/IEC, "Information technology -- Document Schema [RELAXNG] ISO/IEC, "Information technology -- Document Schema
Definition Language (DSDL) -- Part 2: Regular-grammar- Definition Language (DSDL) -- Part 2: Regular-grammar-
based validation -- RELAX NG", ISO/IEC 19757-2, December based validation -- RELAX NG", ISO/IEC 19757-2, December
2008. 2008.
skipping to change at page 39, line 28 skipping to change at page 40, line 13
/ [occur S] "(" S group S ")" optcom / [occur S] "(" S group S ")" optcom
from a parenthesized group, again with a possible occurrence from a parenthesized group, again with a possible occurrence
indicator. indicator.
memberkey = type1 S ["^" S] "=>" memberkey = type1 S ["^" S] "=>"
/ bareword S ":" / bareword S ":"
/ value S ":" / value S ":"
Key types can be given by a type expression, a bareword (which stands Key types can be given by a type expression, a bareword (which stands
for string value created from this bareword), or a value (which for a type that just contains a string value created from this
stands for a type that just contains this value). A key value bareword), or a value (which stands for a type that just contains
matches its key type if the key value is a member of the key type, this value). A key value matches its key type if the key value is a
unless a cut preceding it in the group applies (see Section 3.5.3 how member of the key type, unless a cut preceding it in the group
map matching is infuenced by the presence of the cuts denoted by "^" applies (see Section 3.5.3 how map matching is infuenced by the
or ":" in previous entries). presence of the cuts denoted by "^" or ":" in previous entries).
bareword = id bareword = id
A bareword is an alternative way to write a type with a single text A bareword is an alternative way to write a type with a single text
string value; it can only be used in the syntactic context given string value; it can only be used in the syntactic context given
above. above.
optcom = S ["," S] optcom = S ["," S]
(Optional commas do not influence the matching.) (Optional commas do not influence the matching.)
 End of changes. 27 change blocks. 
52 lines changed or deleted 89 lines changed or added

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