]> Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Internet-Draft 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the cbor Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction (See abstract.) Additional EDN application extensions defined in this document

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
tbd b45	Create byte string from base45 representation

Discuss: We should also add application extensions for text generation from bytes, such as b64c and b64u, along the lines of .

Conventions and Terminology This specification uses terminology from . 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 and , i.e., ABNF defined in this document allows use of the case-sensitive extensions defined in . 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 () () when, and only when, they appear in all capitals, as shown here.

Application Extensions

same: multiple literals to be checked against each other 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: >" 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 ]]>

bytes: Reinterpret text string as byte string 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: >' 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 'ä/' ]]>

float: IEEE754-oriented literals for more floating point values 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: \ >" 37128.08203125 ]]>

tbd b32/h32/c32?: Create byte string from base32 representation TO BE DONE: define, possibly beyond the two variants defined in ; watch .

tbd b45: Create byte string from base45 representation TO BE DONE: define based on

Implementation Status 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 . 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 , "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".

Implementation 1 The "float" application extension is implemented in 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.

Implementation 2 The float application extension is implemented in the JavaScript tools that come with the CBOR test vectors project .

Security considerations The security considerations of apply. TO BE DONE: List any specific security considerations that apply to specific application extensions.

IANA considerations TO BE DONE:

References Normative References Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -22 is // intended to present a complete specification that can be used to // confirm the results of the 2026-04-01 CBOR interim. This includes // extending inline comments to encompass C-style comments, and end- // of-line comments to encompass C++-style comments. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. This document obsoletes RFC 4648 and changes the status to Internet Standard. This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. IEEE In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Acknowledgements