| Internet-Draft | EDN Application Extensions | April 2026 |
| Bormann | Expires 12 October 2026 | [Page] |
The CBOR Extended Diagnostic Notation (EDN), to be standardized in draft-ietf-cbor-edn-literals, provides "application extensions" as its main language extension point.¶
A number of application extensions are already defined in draft-ietf-cbor-edn-literals itself and in draft-ietf-cbor-edn-e-ref. The present document defines a number of additional application extensions that have been batched up as a next step after completing these specifications. (Chore: Briefly List extensions.)¶
This -00 of an individual submission shows the approximate shape the first "batch" of application extensions could have, plus a number of registrations that could go into this batch. The latter provides a basis for a technical discussion of those registrations.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://cabo.github.io/edn-app-ext/draft-bormann-cbor-edn-app-ext.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bormann-cbor-edn-app-ext/.¶
Discussion of this document takes place on the cbor Working Group mailing list (mailto:cbor@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cbor/. Subscribe at https://www.ietf.org/mailman/listinfo/cbor/.¶
Source for this draft and an issue tracker can be found at https://github.com/cabo/edn-app-ext.¶
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 12 October 2026.¶
Copyright (c) 2026 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) 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
(See abstract.)¶
| Name | Purpose |
|---|---|
| same | Multiple literals for the same item, to be checked against each other |
| bytes | Reinterpret text string as byte string |
| float | Provide IEEE754-oriented literals for more floating point values |
| tbd b32/h32/c32? | Create byte string from base32 representation, possibly beyond the two variants defined in [RFC4648] |
| tbd b45 | Create byte string from base45 representation [RFC9285] |
Discuss: We should also add application extensions for text generation from bytes, such as b64c and b64u, along the lines of [RFC9741].¶
This specification uses terminology from [I-D.ietf-cbor-edn-literals]. In particular, with respect to control operators, "target" refers to the left-hand side operand, and "controller" to the right-hand side operand. "Tool" refers to tools that produce, consume, or otherwise process EDN. Note also that the data model underlying CBOR provides for text strings as well as byte strings as two separate types, which are then collectively referred to as "strings".¶
The term ABNF in this specification stands for the combination of [STD68] and [RFC7405], i.e., ABNF defined in this document allows use of the case-sensitive extensions defined in [RFC7405].¶
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 [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here.¶
The "same" application extension receives a sequence of one or more
data items and throws an error if these data items are not the same.¶
Example:¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
$ edn-abnf -afloat,same -e "same<< float'47110815', 37128.08203125, \
0x1.22102ap+15 >>"
37128.08203125
$ edn-abnf -afloat,same -e "same<< float'47110815', 37128.08203126 >\
>"
** cbor-diagnostic: same<<>>: 37128.08203125 not same as 37128.\
08203126: Argument Error
$ edn-abnf -asame -e "same<< h'a10101', <<{/alg/ 1: 1 /AES-GCM 128 /\
}>> >>"
h'A10101'
$ edn-abnf -asame -e "same<<1>>" # trivially true
1
¶
The "bytes" application extension receives a sequence of zero or more
strings (throwing an error if any of these data items are not text or
byte strings), concatenates their byte content and yields the
concatenation as a byte string.¶
Examples:¶
$ edn-abnf -abytes -e 'bytes<<>>' h'' $ edn-abnf -abytes -e 'bytes`text1`' h'7465787431' $ edn-abnf -abytes -e 'bytes<<"1", "2">>' h'3132' $ edn-abnf -abytes -e 'bytes<<"ä", h'"'2f'"'>>' h'C3A42F' $ edn-abnf -abytes -e 'bytes<<"ä", h'"'2f'"'>>' | diag2diag.rb -tu 'ä/'¶
The "float" application extension enables the notation of 2-byte,
4-byte, and 8-byte byte strings as hex literals (like the h
application prefix).
The application-oriented literal is interpreted as an encoded data item
prefixing the byte string by a single byte 0xF9 (binary16), 0xFA
(binary32), and 0xFB (binary64), respectively, would be.¶
Example:¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
$ edn-abnf -afloat -e "[float'fe00', float'47110815']" -tpretty
82 # array(2)
F9 FE00 # primitive(65024)
FA 47110815 # primitive(1192298517)
$ edn-abnf -afloat,same -e "same<< float'47110815', 37128.08203125 >\
>"
37128.08203125
¶
TO BE DONE: define, possibly beyond the two variants defined in [RFC4648]; watch [I-D.josefsson-rfc4648bis].¶
This section is to be removed before publishing as an RFC.¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
The "float" application extension is implemented in
https://cbor.me and can be enabled (–afloat) in the cbor
diagnostic tools (cbor-diag gem) and the edn-abnf gem.
At the time of writing, the "same" and "bytes" application
extensions (–asame, –abytes) are only available in the gems.¶
The float application extension is implemented in the JavaScript
tools that come with the CBOR test vectors project https://github.com/cbor-wg/cbor-test-vectors/blob/main/check/files.test.js.¶
The security considerations of [I-D.ietf-cbor-edn-literals] apply.¶
TO BE DONE: List any specific security considerations that apply to specific application extensions.¶
TO BE DONE:¶