@techreport{ietf-cbor-edn-literals-26,
    number =    {draft-ietf-cbor-edn-literals-26},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/26/},
    author =    {Carsten Bormann},
    title =     {{Concise Diagnostic Notation (CDN)}},
    pagetotal = 73,
    year =      2026,
    month =     jun,
    day =       15,
    abstract =  {This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN'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:) -26 is intended to // address the May/June 2026 Working Group Last Call comments on -25 // and the ensuing WG discussions. Specifically, this update: • is // going further with the idea to entirely replace the non- backwards // compatible update considered for the RFC 8610/G.4 concatenation by // two new application extensions (temporarily named b1/t1), and to // add related application-oriented extensions that deprecate the // original streamstring syntax. • includes the float'' application- // extension so that the entire CBOR format can be covered. • now // uses rules closer to those of markdown for handling data // transparency in raw strings, simplifying their implementation. • // adds security considerations. • proactively reserves the // application-extension identifier "pragma" for potential future // standardization. • This update does not address certain comments // that propose some editorial restructuring requiring moving text // around; this is best done in a next revision after the technical // comments are addressed.},
}