MIT CSAIL

32 Vassar Street, Room 32-G692 Cambridge Massachusetts 02139 United States of America rivest@mit.edu https://www.csail.mit.edu/person/ronald-l-rivest

Independent

2386 Panoramic Circle Apopka Florida 32703 United States of America +1-508-333-2270 d3e3e3@gmail.com

ART Sexp Sexpression S-expression This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI) certificates, as detailed in RFC 2692, with the intent that it be more widely applicable. It has been and is being used elsewhere. There are multiple implementations in a variety of programming languages. Uses of this representation are referred to in this document as "S-expressions". This memo makes precise the encodings of these SPKI S-expressions: It gives a "canonical form" for them, describes two "transport" representations, and also describes an "advanced" format for display to people.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 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 () 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.

Table of Contents

• .  Introduction
  • .  Uses of S-Expressions
  • .  Formalization
  • .  Historical Note
  • .  Conventions Used in This Document
• .  S-expressions -- Informal Introduction
• .  Character Set
• .  Octet-String Representation Types
  • .  Verbatim Representation
  • .  Quoted-String Representation
  • .  Token Representation
  • .  Hexadecimal Representation
  • .  Base-64 Representation of Octet-Strings
  • .  Display-Hints and Internationalization
  • .  Comparison of Octet-Strings
• .  Lists
• .  S-Expression Representation Types
  • .  Base-64 Representation of S-Expressions
  • .  Canonical Representation
  • .  Basic Transport Representation
  • .  Advanced Transport Representation
• .  ABNF of the Syntax
  • .  ABNF for Advanced Transport
  • .  ABNF for Canonical
  • .  ABNF for Basic Transport
• .  Restricted S-Expressions
• .  In-Memory Representations
  • .  List-Structure Memory Representation
  • .  Array-Layout Memory Representation
    • .  Octet-String
    • .  Octet-String with Display-Hint
    • .  List
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• .  Implementations
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI) certificates , with the intent that it be more widely applicable (see , "Historical Note"). It is suitable for representing arbitrary, complex data structures and has been and is being used elsewhere. Uses of this representation herein are referred to as "S-expressions". This memo makes precise the encodings of these SPKI S-expressions: It gives a "canonical form" for them, describes two "transport" representations, and also describes an "advanced" format for display to people. There are multiple implementations of S-expressions in a variety of programming languages including Python, Ruby, and C (see ). These S-expressions are either octet-strings or lists of simpler S-expressions. Here is a sample S-expression: (snicker "abc" (#03# |YWJj|)) It is a list of length three containing the following:

• the octet-string "snicker"
• the octet-string "abc"
• a sub-list containing two elements: The hexadecimal constant #03# (which represents a one-octet-long octet-string with the value of that octet being 0x03) and the base-64 constant |YWJj| (which represents the same octet-string as "abc")

This document specifies how to construct and use these S-expressions. The design goals for S-expressions were as follows:

• Generality: S-expressions should be good at representing arbitrary data.
• Readability: It should be easy for someone to examine and understand the structure of an S-expression.
• Economy: S-expressions should represent data compactly.
• Transportability: S-expressions should be easy to transport over communication media (such as email) that are known to be less than perfect.
• Flexibility: S-expressions should make it relatively simple to modify and extend data structures.
• Canonicalization: It should be easy to produce a unique "canonical" form of an S-expression, for digital signature purposes.
• Efficiency: S-expressions should admit in-memory representations that allow efficient processing.

For implementors of new applications and protocols other technologies also worthy of consideration include the following: XML , CBOR , and JSON .

Uses of S-Expressions The S-expressions specified herein are in active use today between GnuPG and Ribose's RNP . Ribose has implemented C++ software to compose and parse these S-expressions . The GNU software is the Libgcrypt library , and there are other implementations (see ). S-expressions are also used or referenced in the following RFCs:

• for
• XML-Signature Syntax and Processing

In addition, S-expressions are the inspiration for the encodings in other protocols. For example, or .

Formalization is an Internet-Draft that shows a formal model of SPKI S-expressions and formally demonstrates that the examples and ABNF in this document are correct.

Historical Note The S-expressions described here were originally developed for "SDSI" (the Simple Distributed Security Infrastructure by Lampson and Rivest ) in 1996, although their origins date back to McCarthy's programming language. They were further refined and improved during the merger of SDSI and SPKI during the first half of 1997. S-expressions are more readable and flexible than Bernstein's "netstrings" , which were developed contemporaneously.

Conventions Used in This Document 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 when, and only when, they appear in all capitals, as shown here.

S-expressions -- Informal Introduction Informally, an S-expression is either:

• an octet-string, or
• a finite list of simpler S-expressions.

An octet-string is a finite sequence of eight-bit octets. An octet-string may be zero length. There may be many different but equivalent ways of representing an octet-string abc -- as a token "abc" -- as a quoted string #616263# -- as a hexadecimal string 3:abc -- as a length-prefixed "verbatim" encoding |YWJj| -- as a base-64 encoding of the octet-string "abc" The above encodings are all equivalent in that they all denote the same octet-string. Details of these encodings are given below, and how to give a "display type" to a simple-string is also described in . A list is a finite sequence of zero or more simpler S-expressions. A list is represented by using parentheses to surround the sequence of encodings of its elements, as in: (abc (de #6667#) "ghi jkl") As can be seen, there is variability possible in the encoding of an S-expression. In some applications, it is desirable to standardize or restrict the encodings; in other cases, it is desirable to have no restrictions. The following are the target cases these S-expressions aim to handle:

• a "transport" or "basic" encoding for transporting the S-expression between computers
• a "canonical" encoding, used when signing the S-expression
• an "advanced" encoding used for input/output to people
• an "in-memory" encoding used for processing the S-expression in the computer

In this document, related encoding techniques for each of these uses are provided.

Character Set This document specifies encodings of S-expressions. Except when giving "verbatim" encodings, the character set used is limited to the following characters in ASCII : Alphabetic: A B ... Z a b ... z Numeric: 0 1 ... 9 Whitespace: space, horizontal tab, vertical tab, form-feed carriage-return, line-feed The following graphics characters, which are called "pseudo-alphabetic" in this document: - hyphen or minus . period / slash _ underscore : colon * asterisk + plus = equal The following graphics characters, which are "reserved punctuation": ( left parenthesis ) right parenthesis [ left bracket ] right bracket { left brace } right brace | vertical bar # number sign " double quote & ampersand \ backslash The following characters are unused and unavailable, except in "verbatim" and "quoted string" encodings: ! exclamation point % percent ^ circumflex ~ tilde ; semicolon ' single-quote (apostrophe) , comma < less than > greater than ? question mark

Octet-String Representation Types This section describes in detail the ways in which an octet-string may be represented. Recall that an octet-string is any finite sequence of octets and that an octet-string may have length zero.

Verbatim Representation A verbatim encoding of an octet-string consists of three parts:

• the length (number of octets) of the octet-string, given in decimal, most significant digit first, with no leading zeros
• a colon ":"
• the octet-string itself, verbatim

There are no blanks or whitespace separating the parts. No "escape sequences" are interpreted in the octet-string. This encoding is also called a "binary" or "raw" encoding. Here are some sample verbatim encodings: 3:abc 7:subject 4:::": 12:hello world! 10:abcdefghij 0:

Quoted-String Representation The quoted-string representation of an octet-string consists of:

• an optional decimal length field
• an initial double-quote (")
• the octet-string with the C programming language escape conventions (\n, etc.)
• a final double-quote (")

The specified length is the length of the resulting string after any backslash escape sequences have been converted to the octet value they denote. The string does not have any "terminating NULL" that includes, and the length does not count such an octet. The length is optional. The escape conventions within the quoted string are as follows (these follow the C programming language conventions, with an extension for ignoring line terminators of just CR, LF, CRLF, or LFCR and more restrictive octal and hexadecimal value formats): \a -- audible alert (bell) \b -- backspace \t -- horizontal tab \v -- vertical tab \n -- new-line \f -- form-feed \r -- carriage-return \" -- double-quote \' -- single-quote \? -- question mark \\ -- back-slash \ooo -- character with octal value ooo (all three digits MUST be present) \xhh -- character with hexadecimal value hh (both digits MUST be present) \<carriage-return> -- causes carriage-return to be ignored. \<line-feed> -- causes line-feed to be ignored. \<carriage-return><line-feed> -- causes CRLF to be ignored. \<line-feed><carriage-return> -- causes LFCR to be ignored. Here are some examples of quoted-string encodings: "subject" "hi there" 7"subject" "\xFE is the same octet as \376" 3"\n\n\n" "This has\n two lines." "This has \ one line." ""

Token Representation An octet-string that meets the following conditions may be given directly as a "token":

• it does not begin with a digit;
• it contains only characters that are: alphabetic (upper or lower case), numeric, or one of the following eight "pseudo-alphabetic" punctuation marks: - . / _ : * + =
• it is length 1 or greater.

Note: Upper and lower case are not equivalent. A token may begin with punctuation, including ":". Here are some examples of token representations: subject not-before :=.. class-of-1997 //example.net/names/smith *

Hexadecimal Representation An octet-string may be represented with a hexadecimal encoding consisting of:

• an (optional) decimal length of the octet-string
• a sharp-sign "#"
• a hexadecimal encoding of the octet-string, with each octet represented with two hexadecimal digits, most significant digit first. There MUST be an even number of such digits.
• a final sharp-sign "#"

There may be whitespace inserted in the midst of the hexadecimal encoding arbitrarily; it is ignored. It is an error to have characters other than whitespace and hexadecimal digits. Here are some examples of hexadecimal encodings: #616263# -- represents "abc" 3#616263# -- also represents "abc" # 616 263 # -- also represents "abc" ## -- represents the zero-length string

Base-64 Representation of Octet-Strings An octet-string may be represented in a base-64 encoding consisting of:

• an (optional) decimal length of the octet-string
• a vertical bar "|"
• the base-64 encoding of the octet-string.
• a final vertical bar "|"

Base-64 encoding produces four characters of output for each three octets of input. When the length of the input is divided by three:

• if the remainder is one, it produces an output block of length four ending in two equals signs.
• if the remainder is two, it produces an output block of length four ending in one equals sign.

These equals signs MUST be included on output, but input routines MAY accept inputs where one or two equals signs are dropped. Whitespace inserted in the midst of the base-64 encoding is ignored. It is an error to have characters other than whitespace and base-64 characters. Here are some examples of base-64 encodings: |YWJj| -- represents "abc" | Y W J j | -- also represents "abc" 3|YWJj| -- also represents "abc" |YWJjZA==| -- represents "abcd" |YWJjZA| -- also represents "abcd" || -- represents the zero-length string Note the difference between this base-64 encoding of an octet-string using vertical bars ("| |") and the base-64 encoding of an S-expression using curly braces ("{ }") in .

Display-Hints and Internationalization An octet-string can contain any type of data representable by a finite octet-string, e.g., text, a fixed or variable-length integer, or an image. Normally, the application producing and/or consuming S-expressions will understand their structure, the data type, and the encoding of the octet-strings within the S-expressions used by that application. If the octet-string consists of text, use of UTF-8 encoding is RECOMMENDED . The purpose of a display-hint is to provide information on how to display an octet-string to a user. It has no other function. Many of the media types work here. A display-hint is an octet-string representation surrounded by square brackets. There may be whitespace separating the display hint octet-string from the surrounding brackets. Any of the legal octet-string representations may be used for the display-hint string, but a display-hint may not be applied to a display-hint string -- that is, display-hints may not be nested. A display-hint that can be used for UTF-8-encoded text is shown in the following example where the octet-string represents "böb☺", that is, "bob" with an umlaut over the "o", followed by the Unicode character WHITE SMILING FACE (U+263A). ["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA" Every octet-string representation is or is not preceded by a single display-hint. There may be whitespace between the close square bracket and the octet-string to which the hint applies. Here are some other examples of display-hints: [image/gif] [charset=unicode-1-1] [ text/richtext ] ["text/plain; charset=iso-8859-1"] [application/postscript] [audio/basic] ["http://example.com/display-types/funky.html"] An octet-string that has no display-hint may be considered to have a media type specified by the application or use. In the absence of such a specification, the default is as follows: [application/octet-stream] When an S-expression is being encoded in one of the representations described in , any display-hint present is included. If a display-hint is the default, it is not suppressed nor is the default display-hint included in the representation for an octet-string without a display-hint.

Comparison of Octet-Strings It is RECOMMENDED that two octet-strings be considered equivalent for most computational and algorithmic purposes if and only if they have the same display-hint and the same data octet-strings. However, a particular application might need a different criterion. For example, it might ignore the display hint on comparisons. Note that octet-strings are "case-sensitive"; the octet-string "abc" is not equal to the octet-string "ABC". An octet-string without a display-hint may be compared to another octet-string (with or without a display hint) by considering it as an octet-string with the default display-hint specified for the applications or, in the absence of such specification, the general default display-hint specified in .

Lists Just as with octet-strings, there are variations in representing a list. Whitespace may be used to separate list elements, but they are only required to separate two octet-strings when otherwise the two octet-strings might be interpreted as one, as when one token follows another. To be precise, an octet-string represented as a token () MUST be separated by whitespace from a following token, verbatim representation, or any of the following if they are prefixed with a length: quoted-string, hexadecimal, or base-64 representation. Also, whitespace may follow the initial left parenthesis or precede the final right parenthesis of a list. Here are some examples of encodings of lists: (a bob c) ( a ( bob c ) ( ( d e ) ( e f ) ) ) (11:certificate(6:issuer3:bob)(7:subject5:alice)) (|ODpFeGFtcGxlIQ==| "1997" murphy 3:XC+) ()

S-Expression Representation Types There are three "types" of representation:

• canonical
• basic transport
• advanced transport

The first two MUST be supported by any implementation; the last is OPTIONAL. As part of basic representation, the base-64 representation of an S-expression may be used as described in .

Base-64 Representation of S-Expressions An S-expression may be represented in a base-64 encoding consisting of:

• an opening curly brace "{"
• the base-64 encoding of the S-expression
• a final closing curly brace "}"

Base-64 encoding produces four characters of output for each three octets of input. If the length of the input divided by three leaves a remainder of one or two, it produces an output block of length four ending in two or one equals signs, respectively. These equals signs MUST be included on output, but input routines MAY accept inputs where one or two equals signs are dropped. Whitespace inserted in the midst of the base-64 encoding, after the opening curly brace, or before the closing curly brace is ignored. It is an error to have characters other than whitespace and base-64 characters. Note the difference between this base-64 encoding of an S-expression using curly braces ("{ }") and the base-64 encoding of an octet-string using vertical bars ("| |") in .

Canonical Representation This canonical representation is used for digital signature purposes and transport over channels not sensitive to specific octet values. It is uniquely defined for each S-expression. It is not particularly readable, but that is not the point. It is intended to be very easy to parse, reasonably economical, and unique for any S-expression. See and . The "canonical" form of an S-expression represents each octet-string in verbatim mode, and represents each list with no blanks separating elements from each other or from the surrounding parentheses. See also . Here are some examples of canonical representations of S-expressions: (6:issuer3:bob) (4:icon[12:image/bitmap]9:xxxxxxxxx) (7:subject(3:ref5:alice6:mother)) 10:foo)]}>bar 0:

Basic Transport Representation There are two forms of the "basic transport" representation:

1. The canonical representation
2. A base-64 representation of the canonical representation, surrounded by braces (see )

The basic transport representations (see ) are intended to provide a universal means of representing S-expressions for transport from one machine to another. The base-64 encoding would be appropriate if the channel over which the S-expression is being sent might be sensitive to octets of some special values, such as an octet of all zero bits (NULL) or an octet of all one bits (DEL), or if the channel is sensitive to "line length" such that occasional line terminating whitespace is needed. Here are two examples of an S-expression represented in basic transport mode: (1:a1:b1:c) {KDE6YTE6YjE 6Yyk= } The second example above is the same S-expression as the first encoded in base-64.

Advanced Transport Representation The "advanced transport" representation is intended to provide more flexible and readable notations for documentation, design, debugging, and (in some cases) user interface. The advanced transport representation allows all of the octet-string representation forms described above in : quoted strings, base-64, hexadecimal, tokens, representations of strings with omitted lengths, and so on. See .

ABNF of the Syntax ABNF is the Augmented Backus-Naur Form for syntax specifications as defined in . The ABNF for advanced representation of S-expressions is given first, and the basic and canonical forms are derived therefrom. The rule names below in all capital letters are defined in .

ABNF for Advanced Transport sexp = *whitespace value *whitespace whitespace = SP / HTAB / vtab / CR / LF / ff vtab = %x0B ; vertical tab ff = %x0C ; form feed value = string / ("(" *(value / whitespace) ")") string = [display] simple-string display = "[" *whitespace simple-string *whitespace "]" *whitespace simple-string = verbatim / quoted-string / token / hexadecimal / base-64 verbatim = decimal ":" *OCTET ; the length followed by a colon and the exact ; number of OCTETs indicated by the length decimal = %x30 / (%x31-39 *DIGIT) quoted-string = [decimal] DQUOTE *(printable / escaped) DQUOTE printable = %x20-21 / %x23-5B / %x5D-7E ; All US-ASCII printable but double-quote and ; backslash escaped = backslash (%x3F / %x61 / %x62 / %x66 / %x6E / %x72 / %x74 / %x76 / DQUOTE / quote / backslash / 3(%x30-37) / (%x78 2HEXDIG) / CR / LF / (CR LF) / (LF CR)) backslash = %x5C quote = %x27 ; single quote token = (ALPHA / simple-punc) *(ALPHA / DIGIT / simple-punc) simple-punc = "-" / "." / "/" / "_" / ":" / "*" / "+" / "=" hexadecimal = [decimal] "#" *whitespace *hexadecimals "#" hexadecimals = 2(HEXDIG *whitespace) base-64 = [decimal] "|" *whitespace *base-64-chars [base-64-end] "|" base-64-chars = 4(base-64-char *whitespace) base-64-char = ALPHA / DIGIT / "+" / "/" base-64-end = base-64-chars / 3(base-64-char *whitespace) ["=" *whitespace] / 2(base-64-char *whitespace) *2("=" *whitespace)

ABNF for Canonical c-sexp = c-string / ("(" *c-sexp ")") c-string = [ "[" verbatim "]" ] verbatim

ABNF for Basic Transport b-sexp = c-sexp / b-base-64 b-base-64 = "{" *whitespace *base-64-chars base-64-end "}" ; encodes a c-sexp, which has a minimum ; length of 2

Restricted S-Expressions This document has described S-expressions in general form. Applications may wish to restrict their use of S-expressions in various ways as well as to specify a different default display-hint. Here are some possible restrictions that might be considered:

• no advanced representations (only canonical and basic)
• no display-hints
• no lengths on hexadecimal, quoted-strings, or base-64 encodings
• no empty lists
• no empty octet-strings
• no lists having another list as its first element
• no base-64 or hexadecimal encodings
• fixed limits on the size of octet-strings

As provided in , conformant implementations will support canonical and basic representation, but support for advanced representation is not generally required. Thus, advanced representation can only be used in applications that mandate its support or where a capability discovery mechanism indicates support.

In-Memory Representations For processing, the S-expression would typically be parsed and represented in memory in a way that is more amenable to efficient processing. This document suggests two alternatives:

• "list-structure"
• "array-layout"

These are only sketched here, as they are only suggestive. The code in illustrates these styles in more detail.

List-Structure Memory Representation Here there are separate records for simple-strings, strings, and lists or list nodes. An S-expression of the form ("abc" "de") could be encoded as two records for the simple-strings, two for the strings, and two for the list elements where a record is a relatively small block of memory and, except for simple-string, might have pointers in it to other records. This is a fairly conventional representation as discussed in Section 4 of .

Array-Layout Memory Representation Here each S-expression is represented as a contiguous array of octets. The first octet codes the "type" of the S-expression: 01 octet-string 02 octet-string with display-hint 03 beginning of list (and 00 is used for "end of list") Each of the three types is immediately followed by a k-octet integer indicating the size (in octets) of the following representation. Here, k is an integer that depends on the implementation. It might be anywhere from 2 to 8, but it would be fixed for a given implementation; it determines the size of the objects that can be handled. The transport and canonical representations are independent of the choice of k made by the implementation. Although the lengths of lists are not given in the usual S-expression notations, it is easy to fill them in when parsing; when you reach a right parenthesis, you know how long the list representation was and where to go back to fill in the missing length.

Octet-String This is represented as follows: 01 <length> <octet-string> For example (here, k = 2): 01 0003 a b c

Octet-String with Display-Hint This is represented as follows: 02 <length> 01 <length> <octet-string> /* for display-type */ 01 <length> <octet-string> /* for octet-string */ For example, the S-expression: [gif] #61626364# would be represented as (with k = 2): 02 000d 01 0003 g i f 01 0004 61 62 63 64

List This is represented as: 03 <length> <item1> <item2> <item3> ... <item> 00 For example, the list (abc [d]ef (g)) is represented in memory as (with k = 2): 03 001b 01 0003 a b c 02 0009 01 0001 d 01 0002 e f 03 0005 01 0001 g 00 00

Security Considerations As a pure data representation format, there are few security considerations to S-expressions. A canonical form is required for the consistent creation and verification of digital signatures. This is provided in . The default display-hint (see ) can be specified for an application. Note that if S-expressions containing untyped octet-strings represented for that application are processed by a different application, those untyped octet-string may be treated as if they had a different display-hint.

IANA Considerations This document has no IANA actions.

References Normative References 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. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. 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] 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] 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 Work in Progress Universität Bremen TZI In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. Work in Progress Impedance Mismatch LLC The goal of this document is to show and explain the formal model developed to guarantee that the examples and ABNF in the "SPKI Symbolic Expressions" Internet-Draft are correct. Work in Progress GnuPG Inferno Manual Page GnuPG Libgcrypt version 1.10.2 The Computer Center and Research Laboratory of Electronics, Massachusetts Institute of Technology Massachusetts Institute of Technology This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. This memo defines an Experimental Protocol for the Internet community. This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community. The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community. This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Ribose Group Inc. Version 0.9.2, commit 249c6e3 Working document for SDSI version 1.1 commit 4aa7c36 commit a90f90f commit b7d3bea MIT Lab for Computer Science The Unicode Consortium

Textuality and Netscape Microsoft W3C Sun Microsystems W3C Recommendation Latest version available at .

Implementations At this time there are multiple implementations, many open source, available that are intended to read and parse some or all of the various S-expression formats specified here. In particular, see the following -- likely incomplete -- list:

• Project GNU's
• Ribose's RNP in C++
• Github project of J. P. Malkiewicz in C
• The Inferno implementation
• Small Fast X-Expression Library
• S-expression Processor in Ruby
• Canonical S-expressions (OCAML)

Acknowledgements Special thanks to for his extensive comments. The comments and suggestions of the following are gratefully acknowledged: and .

Contributors Special thanks to , particularly for his extensive work and advice on the ABNF and on locating and fixing unclear parts of earlier draft versions of this document: Impedance Mismatch LLC

marc@petit-huguenin.org

Authors' Addresses MIT CSAIL

32 Vassar Street, Room 32-G692 Cambridge Massachusetts 02139 United States of America rivest@mit.edu https://www.csail.mit.edu/person/ronald-l-rivest

Independent

2386 Panoramic Circle Apopka Florida 32703 United States of America +1-508-333-2270 d3e3e3@gmail.com