hn-classics/_stories/1997/16310017.md

[Source](https://people.csail.mit.edu/rivest/Sexp.txt "Permalink to ")

Network Working Group R. Rivest Internet Draft May 4, 1997 Expires November 4, 1997 S-Expressions draft-rivest-sexp-00.txt Status of this Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa), nic.nordu.net (Europe), ds.internic.net (US East Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim) Abstract This memo describes a data structure called "S-expressions" that are suitable for representing arbitrary complex data structures. We make precise the encodings of S-expressions: we give a "canonical form" for S-expressions, described two "transport" representations, and also describe an "advanced" format for display to people. 1\. Introduction S-expressions are data structures for representing complex data. They are either byte-strings ("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: \-- the octet-string "snicker" \-- the octet-string "abc" \-- a sub-list containing two elements: \- the hexadecimal constant #03# \- the base-64 constant |YWJj| (which is the same as "abc") This note gives a specific proposal for constructing and utilizing S-expressions. The proposal is independent of any particular application. Here are the design goals for S-expressions: \-- 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. \-- tranportability: 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. Section 2 gives an introduction to S-expressions. Section 3 discusses the character sets used. Section 4 presents the various representations of octet-strings. Section 5 describes how to represent lists. Section 6 discusses how S-expressions are represented for various uses. Section 7 gives a BNF syntax for S-expressions. Section 8 talks about how S-expressions might be represented in memory. Section 9 briefly describes implementations for handling S-expressions. Section 10 discusses how applications might utilize S-expressions. Section 11 gives historical notes on S-expressions. Section 12 gives references. 2\. 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. 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 {MzphYmM=} -- as a base-64 encoding of the verbatim encoding (that is, an encoding of "3:abc") |YWJj| -- as a base-64 encoding of the octet-string "abc" These encodings are all equivalent; they all denote the same octet string. We will give details of these encodings later on, and also describe how to give a "display type" to a byte string. A list is a finite seq

[1]: http://www.clark.net/pub/cme/html/spki.html
Initial commit 2018-02-23 18:19:40 +00:00			`[Source](https://people.csail.mit.edu/rivest/Sexp.txt "Permalink to ")`

			Network Working Group R. Rivest Internet Draft May 4, 1997 Expires November 4, 1997 S-Expressions draft-rivest-sexp-00.txt Status of this Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa), nic.nordu.net (Europe), ds.internic.net (US East Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim) Abstract This memo describes a data structure called "S-expressions" that are suitable for representing arbitrary complex data structures. We make precise the encodings of S-expressions: we give a "canonical form" for S-expressions, described two "transport" representations, and also describe an "advanced" format for display to people. 1\. Introduction S-expressions are data structures for representing complex data. They are either byte-strings ("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: \-- the octet-string "snicker" \-- the octet-string "abc" \-- a sub-list containing two elements: \- the hexadecimal constant #03# \- the base-64 constant \|YWJj\| (which is the same as "abc") This note gives a specific proposal for constructing and utilizing S-expressions. The proposal is independent of any particular application. Here are the design goals for S-expressions: \-- 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. \-- tranportability: 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. Section 2 gives an introduction to S-expressions. Section 3 discusses the character sets used. Section 4 presents the various representations of octet-strings. Section 5 describes how to represent lists. Section 6 discusses how S-expressions are represented for various uses. Section 7 gives a BNF syntax for S-expressions. Section 8 talks about how S-expressions might be represented in memory. Section 9 briefly describes implementations for handling S-expressions. Section 10 discusses how applications might utilize S-expressions. Section 11 gives historical notes on S-expressions. Section 12 gives references. 2\. 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. 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 {MzphYmM=} -- as a base-64 encoding of the verbatim encoding (that is, an encoding of "3:abc") \|YWJj\| -- as a base-64 encoding of the octet-string "abc" These encodings are all equivalent; they all denote the same octet string. We will give details of these encodings later on, and also describe how to give a "display type" to a byte string. A list is a finite seq

			`[1]: http://www.clark.net/pub/cme/html/spki.html`