< draft-richter-cbor-error-tag-00.txt   draft-richter-cbor-error-tag-01.txt >
Network Working Group J. Richter Network Working Group J. Richter
Internet-Draft pdv Financial Software GmbH Internet-Draft pdv Financial Software GmbH
Intended status: Informational C. Bormann Intended status: Informational C. Bormann
Expires: August 1, 2019 Universitaet Bremen TZI Expires: August 3, 2019 Universitaet Bremen TZI
January 28, 2019 January 30, 2019
Concise Binary Object Representation (CBOR) Tag for Error Indications Concise Binary Object Representation (CBOR) Tag for Error Indications
draft-richter-cbor-error-tag-00 draft-richter-cbor-error-tag-01
Abstract Abstract
The Concise Binary Object Representation (CBOR, RFC 7049) is a data The Concise Binary Object Representation (CBOR, RFC 7049) is a data
format whose design goals include the possibility of extremely small format whose design goals include the possibility of extremely small
code size, fairly small message size, and extensibility without the code size, fairly small message size, and extensibility without the
need for version negotiation. need for version negotiation.
In CBOR, one point of extensibility is the definition of CBOR tags. In CBOR, one point of extensibility is the definition of CBOR tags.
While CBOR defines representations for null values and for an While CBOR defines representations for null values and for an
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 1, 2019. This Internet-Draft will expire on August 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Error Format . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Error Format . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 3 3. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The Concise Binary Object Representation (CBOR, [RFC7049]) provides The Concise Binary Object Representation (CBOR, [RFC7049]) provides
for the interchange of structured data without a requirement for a for the interchange of structured data without a requirement for a
pre-agreed schema. RFC 7049 defines a basic set of data types, as pre-agreed schema. RFC 7049 defines a basic set of data types, as
well as a tagging mechanism that enables extending the set of data well as a tagging mechanism that enables extending the set of data
types supported via an IANA registry. types supported via an IANA registry.
In CBOR, one point of extensibility is the definition of CBOR tags. In CBOR, one point of extensibility is the definition of CBOR tags.
While CBOR defines representations for null values and for an While CBOR defines representations for null values and for an
undefine value, there is no convention for expressing errors or undefine value, there is no convention for expressing errors or
exceptions in data structures. The present specification defines a exceptions in data structures. The present specification defines a
tag for such error indications, enabling varying levels of detail. tag for such error indications, enabling varying levels of detail.
1.1. Terminology
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.
2. Error Format 2. Error Format
An error value is indicated by CBOR tag TBD101, which tags a data An error value is indicated by CBOR tag TBD101, which tags a data
item that may contain additional information about the error value: item that may contain additional information about the error value:
o If no further information is provided, the data item is the CBOR o If no further information is provided, the data item is the CBOR
value null. value null.
o If a diagnostic text string is provided, the data item is that o If a diagnostic text string is provided, the data item is that
text string. text string.
o If more detailed information is provided, the data item is a map o If more detailed information is provided, the data item is a map
(CBOR major type 5), with text string or integer keys and values (CBOR major type 5), with text string or integer keys and values
as defined by the application. as defined by the application.
This specification does not further define what keys and values
should be used in a map that is used as the tagged item for this tag.
However, to maximize interoperability, the following keys and values
are suggested for use whenever they are appropriate for an
application (the keys are text strings, suggested value types are
indicated in the table with CDDL names):
+---------+--------------------------------------------------+------+
| key | value | type |
+---------+--------------------------------------------------+------+
| name | a formal name for the kind of error amenable to | text |
| | program processing, maybe a class name or a URI | |
| code | a number assigned for the kind of error, e.g. an | int |
| | HTTP-style error code such as 404 | |
| message | human-readable description; what would be in the | text |
| | diagnostic text string if only that were | |
| | provided | |
| file | indicating location of error in program: file | text |
| | name | |
| line | indicating location of error in program: line | uint |
| | number | |
| column | indicating location of error in program: column | uint |
| | number | |
+---------+--------------------------------------------------+------+
Note that these suggestions have been somewhat inspired by the
JavaScript "Error" object (Section 19.5 of [ECMA262])), except that
two-word forms of keys have been shortened to single words. There is
no intention that the details of the JavaScript "Error" object are
normative for the present specification. More generally, there is no
intention to limit the use of the Tag defined here to those
applications that would employ the JavaScript "Error" object.
(Discussion: changing lineNumber into line sounds like a good idea.
Changing fileName into file is suboptimal, but reallu the problem is
that neither says "source file". I was thinking about using "source"
in place of "file".)
3. CDDL typenames 3. CDDL typenames
For the use with the CBOR Data Definition Language, CDDL For the use with the CBOR Data Definition Language, CDDL
[I-D.ietf-cbor-cddl], the type names defined in Figure 1 are [I-D.ietf-cbor-cddl], the type names defined in Figure 1 are
recommended: recommended:
error = error-of<(null / text / {* (int/tstr) => any})> error = error-of<(null / text / {* (int/text) => any})>
error-of<T> = #6.101(T) error-of<T> = #6.101(T)
Figure 1: Recommended type names for CDDL Figure 1: Recommended type names for CDDL
4. IANA Considerations 4. IANA Considerations
In the registry [IANA.cbor-tags], IANA is requested to allocate the In the registry [IANA.cbor-tags], IANA is requested to allocate the
tag in Table 1 from the FCFS space, with the present document as the tag in Table 1 from the FCFS space, with the present document as the
specification reference. specification reference.
+--------+-----------------+----------------------------+ +--------+-----------------+----------------------------+
| Tag | Data Item | Semantics | | Tag | Data Item | Semantics |
+--------+-----------------+----------------------------+ +--------+-----------------+----------------------------+
| TBD101 | null, text, map | [RFCthis] error indication | | TBD101 | null, text, map | [RFCthis] error indication |
+--------+-----------------+----------------------------+ +--------+-----------------+----------------------------+
Table 1: Values for Tags Table 1: Values for Tags
5. Security Considerations 5. Security Considerations
The security considerations of RFC 7049 apply; the tag introduced The security considerations of RFC 7049 apply.
here are not expected to raise security considerations beyond those.
6. Normative References Error/diagnostic information provided by a system can disclose
internals of that to an attacker; care should be taken with the tag
introduced here that its use does not facilitate attacks in this way.
6. References
6.1. Normative References
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-06 (work in progress), November 2018. cddl-06 (work in progress), November 2018.
[IANA.cbor-tags] [IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags>. <http://www.iana.org/assignments/cbor-tags>.
[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>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6.2. Informative References
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. [ECMA262] Ecma International, "ECMAScript 2018 Language
Specification", ECMA Standard ECMA-262, 9th Edition, June
2018, <https://www.ecma-
international.org/publications/files/ECMA-ST/
Ecma-262.pdf>.
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
Joerg Richter Joerg Richter
pdv Financial Software GmbH pdv Financial Software GmbH
Dorotheenstr. 64 Dorotheenstr. 64
Hamburg D-22301 Hamburg D-22301
Germany Germany
 End of changes. 12 change blocks. 
31 lines changed or deleted 66 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/