Internet Engineering Task Force (IETF) R. Rivest
Request for Comments: 9804 MIT CSAIL
Category: Informational D. Eastlake 3rd
ISSN: 2070-1721 Independent
June 2025
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.
このメモは、RFC 2692で詳述されているように、より広く適用可能であることを意図して、単純な公開キーインフラストラクチャ（SPKI）証明書をサポートするために考案されたデータ構造表現を指定します。それは他の場所で使用されており、使用されています。さまざまなプログラミング言語には複数の実装があります。この表現の使用は、このドキュメントでは「S-Expressions」と呼ばれます。このメモは、これらのSPKI S-Expressionsのエンコーディングを正確にします。それらに「標準的な形」を与え、2つの「輸送」表現を説明し、人々への表示の「高度な」形式についても説明します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9804.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9804で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Uses of S-Expressions
1.2. Formalization
1.3. Historical Note
1.4. Conventions Used in This Document
2. S-expressions -- Informal Introduction
3. Character Set
4. Octet-String Representation Types
4.1. Verbatim Representation
4.2. Quoted-String Representation
4.3. Token Representation
4.4. Hexadecimal Representation
4.5. Base-64 Representation of Octet-Strings
4.6. Display-Hints and Internationalization
4.7. Comparison of Octet-Strings
5. Lists
6. S-Expression Representation Types
6.1. Base-64 Representation of S-Expressions
6.2. Canonical Representation
6.3. Basic Transport Representation
6.4. Advanced Transport Representation
7. ABNF of the Syntax
7.1. ABNF for Advanced Transport
7.2. ABNF for Canonical
7.3. ABNF for Basic Transport
8. Restricted S-Expressions
9. In-Memory Representations
9.1. List-Structure Memory Representation
9.2. Array-Layout Memory Representation
9.2.1. Octet-String
9.2.2. Octet-String with Display-Hint
9.2.3. List
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Implementations
Acknowledgements
Contributors
Authors' Addresses
This memo specifies the data structure representation that was devised to support Simple Public Key Infrastructure (SPKI) certificates [RFC2692], with the intent that it be more widely applicable (see Section 1.3, "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".
このメモは、より広く適用可能であることを意図して、単純な公開キーインフラストラクチャ（SPKI）証明書[RFC2692]をサポートするために考案されたデータ構造表現を指定します（セクション1.3、「歴史ノート」を参照）。これは、任意の複雑なデータ構造を表すのに適しており、他の場所で使用されており、使用されています。本明細書のこの表現の使用は、「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 Appendix A).
このメモは、これらのSPKI S-Expressionsのエンコーディングを正確にします。それらに「標準的な形」を与え、2つの「輸送」表現を説明し、人々への表示の「高度な」形式についても説明します。Python、Ruby、Cを含むさまざまなプログラミング言語には、S-Expressionsの複数の実装があります（付録Aを参照）。
These S-expressions are either octet-strings or lists of simpler S-expressions. Here is a sample S-expression:
これらのs発現は、オクテットストリングまたはより単純なS発現のリストのいずれかです。これがサンプルS-Expressionです。
(snicker "abc" (#03# |YWJj|))
It is a list of length three containing the following:
これは、以下を含む長さ3のリストです。
* the octet-string "snicker"
* オクテットストリング「スニッカー」
* the octet-string "abc"
* オクテットストリング「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")
* 2つの要素を含むサブリスト：16進数定数＃03＃（そのオクテットに長いオクテットストリングを表し、そのオクテットの値は0x03です）とベース64定数| ywjj |（これは「ABC」と同じオクテットストリングを表します）
This document specifies how to construct and use these S-expressions.
このドキュメントは、これらのS発現を構築および使用する方法を指定します。
The design goals for S-expressions were as follows:
S-Expressionsの設計目標は次のとおりでした。
* Generality: S-expressions should be good at representing arbitrary data.
* 一般性：S-Expressionsは、任意のデータを表すのに適している必要があります。
* Readability: It should be easy for someone to examine and understand the structure of an S-expression.
* 読みやすさ：誰かがS-Expressionの構造を調べて理解するのは簡単なはずです。
* Economy: S-expressions should represent data compactly.
* 経済：S-Expressionsはデータをコンパクトに表す必要があります。
* Transportability: S-expressions should be easy to transport over communication media (such as email) that are known to be less than perfect.
* 輸送可能性：S-Expressionsは、完全ではないことが知られている通信メディア（電子メールなど）を介して簡単に輸送できる必要があります。
* Flexibility: S-expressions should make it relatively simple to modify and extend data structures.
* 柔軟性：S-Expressionsは、データ構造を変更および拡張することを比較的簡単にする必要があります。
* Canonicalization: It should be easy to produce a unique "canonical" form of an S-expression, for digital signature purposes.
* 標準化：デジタル署名のために、S-Expressionのユニークな「標準的な」形式を簡単に作成できるはずです。
* Efficiency: S-expressions should admit in-memory representations that allow efficient processing.
* 効率：S-Expressionsは、効率的な処理を可能にするメモリ内表現を認める必要があります。
For implementors of new applications and protocols other technologies also worthy of consideration include the following: XML [XML], CBOR [RFC8949], and JSON [RFC8259].
新しいアプリケーションとプロトコルの実装者の場合、その他の検討に値する他のテクノロジーには、XML [XML]、CBOR [RFC8949]、およびJSON [RFC8259]が含まれます。
The S-expressions specified herein are in active use today between GnuPG [GnuPG] and Ribose's RNP [Ribose]. Ribose has implemented C++ software to compose and parse these S-expressions [RNPGP_SEXPP]. The GNU software is the Libgcrypt library [Libgcrypt], and there are other implementations (see Appendix A).
本明細書で指定されているs発現は、今日GNUPG [GNUPG]とリボースのRNP [リボース]の間で積極的に使用されています。リボースは、これらのS発現[RNPGP_SEXPP]を構成および解析するためにC ++ソフトウェアを実装しています。GNUソフトウェアはlibgcryptライブラリ[libgcrypt]であり、他の実装があります（付録Aを参照）。
S-expressions are also used or referenced in the following RFCs:
S-Expressionsは、次のRFCで使用または参照されます。
* [RFC2693] for [SPKI]
* [rfc2693] for [spki]
* [RFC3275] XML-Signature Syntax and Processing
* [RFC3275] XML-Signature構文と処理
In addition, S-expressions are the inspiration for the encodings in other protocols. For example, [RFC3259] or Section 6 of [CDDL-freezer].
さらに、S-Expressionsは、他のプロトコルのエンコーディングのインスピレーションです。たとえば、[rfc3259]または[cddl-freezer]のセクション6。
[Formal] 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.
[Formal]は、SPKI S-Expressionsの正式なモデルを示すインターネットドラフトであり、このドキュメントの例とABNFが正しいことを正式に実証しています。
The S-expressions described here were originally developed for "SDSI" (the Simple Distributed Security Infrastructure by Lampson and Rivest [SDSI]) in 1996, although their origins date back to McCarthy's [LISP] programming language. They were further refined and improved during the merger of SDSI and SPKI [SPKI] [RFC2692] [RFC2693] during the first half of 1997. S-expressions are more readable and flexible than Bernstein's "netstrings" [BERN], which were developed contemporaneously.
ここで説明されているS発現は、1996年に「SDSI」（LampsonとRivest [SDSI]による単純な分散セキュリティインフラストラクチャ）用に開発されましたが、その起源はMcCarthyの[LISP]プログラミング言語にまでさかのぼります。彼らは、1997年上半期にSDSIとSPKI [SPKI] [RFC2692] [RFC2693]の合併中にさらに洗練され、改善されました。S発明は、Bernsteinの「ネットストリングス」[ベルン]よりも読みやすく柔軟です。
Although a specification was made publicly available as a file named draft-rivest-sexp-00.txt on 4 May 1997, that file was never actually submitted to the IETF. This document is a clarified and modernized version of that document.
1997年5月4日に仕様がDraft-rivest-sexp-00.txtという名前のファイルとして公開されましたが、そのファイルは実際にIETFに提出されることはありませんでした。このドキュメントは、そのドキュメントの明確で近代化されたバージョンです。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Informally, an S-expression is either:
非公式には、S-Expressionは次のとおりです。
* an octet-string, or
* オクテット弦、または
* a finite list of simpler S-expressions.
* より単純なS発現の有限リスト。
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
オクテット弦は、8ビットのオクテットの有限シーケンスです。オクテット弦はゼロの長さである可能性があります。オクテット弦を表現する多くの異なるが同等の方法があるかもしれません
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 Section 4.6.
上記のエンコーディングはすべて、すべて同じオクテット弦を示しているという点で同等です。これらのエンコーディングの詳細を以下に示します。また、単純な弦に「ディスプレイタイプ」を与える方法については、セクション4.6にも説明します。
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:
リストは、ゼロ以下のS-Expressionsの有限シーケンスです。リストは、括弧を使用して、次のような要素のエンコーディングのシーケンスを囲むことによって表されます。
(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:
ご覧のとおり、S-Expressionのエンコードには変動が可能です。一部のアプリケーションでは、エンコーディングを標準化または制限することが望ましいです。他の場合には、制限がないことが望ましいです。以下は、これらのS発現を目的としたターゲットケースです。
* a "transport" or "basic" encoding for transporting the S-expression between computers
* コンピューター間のS-発現を輸送するための「トランスポート」または「基本」エンコード
* a "canonical" encoding, used when signing the S-expression
* S-Expressionに署名するときに使用される「正規」エンコーディング
* an "advanced" encoding used for input/output to people
* 人々への入出力/出力に使用される「高度な」エンコード
* an "in-memory" encoding used for processing the S-expression in the computer
* コンピューター内のS-Expressionの処理に使用される「インメモリ」エンコード
In this document, related encoding techniques for each of these uses are provided.
このドキュメントでは、これらの各用途に関連するエンコーディング手法が提供されます。
This document specifies encodings of S-expressions. Except when giving "verbatim" encodings, the character set used is limited to the following characters in ASCII [RFC0020]:
このドキュメントは、S-Expressionsのエンコーディングを指定します。「逐語的」エンコーディングを与える場合を除き、使用される文字セットは、ASCII [RFC0020]の次の文字に限定されます。
Alphabetic:
アルファベット系：
A B ... Z a b ... z
Numeric:
数値：
0 1 ... 9
Whitespace:
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
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.
オクテットストリングはオクテットの有限シーケンスであり、オクテット弦の長さはゼロである可能性があることを思い出してください。
A verbatim encoding of an octet-string consists of three parts:
オクテット弦の逐語的エンコードは、3つの部分で構成されています。
* the length (number of octets) of the octet-string, given in decimal, most significant digit first, with no leading zeros
* 10進数で与えられたオクテット弦の長さ（オクテットの数）、最初は最も重要な数字で、主要なゼロはありません
* 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:
The quoted-string representation of an octet-string consists of:
Octet-stringの引用されたストリング表現は次のとおりです。
* an optional decimal length field
* オプションの小数点付けフィールド
* an initial double-quote (")
* 最初のダブルクォート（ "）
* the octet-string with the C programming language [C88] escape conventions (\n, etc.)
* Cプログラミング言語を使用したオクテットストリング[C88]は慣習を逃がします（\ nなど）
* 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 [C88] includes, and the length does not count such an octet.
指定された長さは、バックスラッシュエスケープシーケンスが示すオクテット値に変換された後、結果の文字列の長さです。文字列には[C88]が含まれる「終端ヌル」はなく、長さはそのようなオクテットをカウントしません。
The length is optional.
長さはオプションです。
The escape conventions within the quoted string are as follows (these follow the C programming language [C88] conventions, with an extension for ignoring line terminators of just CR, LF, CRLF, or LFCR and more restrictive octal and hexadecimal value formats):
引用された文字列内の脱出規則は次のとおりです（これらはCプログラミング言語[C88]規則に続き、CR、LF、CRLF、またはLFCRのみのラインターミネーターを無視するための拡張機能、およびより制限的なOctalおよび六分法値形式）：
\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."
""
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:
* アルファベット（高度または小文字）、数値、または次の8つの「擬似アルファベット」句読点のいずれかである文字のみが含まれています。
- . / _ : * + =
* it is length 1 or greater.
* 長さ1以上です。
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
*
An octet-string may be represented with a hexadecimal encoding consisting of:
オクテット弦は、以下で構成される16進コードで表される場合があります。
* an (optional) decimal length of the octet-string
* オクテット弦の（オプションの）10進数
* 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.
* オクテット弦の16進コード化。各オクテットは2匹の16進数桁で表され、最も重要な数字が最初に表されます。そのような数字の偶数がある必要があります。
* 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.
六十葉エンコードの真ん中に任意に挿入される可能性があります。それは無視されます。白面および16進数桁以外の文字を持つことはエラーです。
Here are some examples of hexadecimal encodings:
ここに16進エンコーディングの例があります：
#616263# -- represents "abc"
3#616263# -- also represents "abc"
# 616
263 # -- also represents "abc"
## -- represents the zero-length string
An octet-string may be represented in a base-64 encoding [RFC4648] consisting of:
オクテット弦は、以下で構成されるベース64エンコーディング[RFC4648]で表される場合があります。
* an (optional) decimal length of the octet-string
* オクテット弦の（オプションの）10進数
* a vertical bar "|"
* 垂直バー「|」
* the base-64 [RFC4648] encoding of the octet-string.
* octet-stringのベース64 [RFC4648]エンコード。
* 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:
Base-64エンコーディングは、入力3オクテットごとに4文字の出力を生成します。入力の長さが3で割られている場合：
* if the remainder is one, it produces an output block of length four ending in two equals signs.
* 残りが1つの場合、2つの標識に等しい長さ4の出力ブロックを生成します。
* if the remainder is two, it produces an output block of length four ending in one equals sign.
* 残りが2の場合、長さ4の出力ブロックが1つの等しい符号で終了します。
These equals signs MUST be included on output, but input routines MAY accept inputs where one or two equals signs are dropped.
これらの等しいサインは出力に含める必要がありますが、入力ルーチンは、1つまたは2つの等しい標識がドロップされる入力を受け入れる場合があります。
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.
ベース64エンコーディングの真っin中に挿入されたホワイトスペースは無視されます。WhitespaceとBase-64文字以外の文字を持つことはエラーです。
Here are some examples of base-64 encodings:
ベース64エンコーディングの例をいくつか紹介します。
|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 Section 6.1.
垂直バー（ "| |"）を使用したオクテット弦のこのベース64エンコードと、セクション6.1のcurly装具（ "{{}"）を使用したS-expressionのベース64エンコードの違いに注意してください。
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 [RFC2130] [RFC3629].
オクテット弦には、有限のオクテットストリング、たとえばテキスト、固定または可変整形の整数、または画像によって表されるあらゆるタイプのデータを含めることができます。通常、S-Expressionsを生成および/または消費するアプリケーションは、そのアプリケーションで使用されているS発現内のOctetストリングの構造、データ型、およびエンコードを理解します。オクテット弦がテキストで構成されている場合、UTF-8エンコードの使用が推奨されます[RFC2130] [RFC3629]。
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 [RFC2046] work here.
ディスプレイヒントの目的は、ユーザーにオクテットストリングを表示する方法に関する情報を提供することです。他の機能はありません。メディアタイプの多く[RFC2046]はここで動作します。
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 [Unicode] character WHITE SMILING FACE (U+263A).
UTF-8エンコードされたテキストに使用できるディスプレイヒントは、Octet-Stringが「böb☺」を表す次の例で示されています。つまり、「o」の上にUmlautを持つ「ボブ」、続いてUnicode [unicode]キャラクター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 [RFC2046] specified by the application or use. In the absence of such a specification, the default is as follows:
ディスプレイヒントのないオクテットストリングは、アプリケーションまたは使用によって指定されたメディアタイプ[RFC2046]を持つと見なされる場合があります。このような仕様がない場合、デフォルトは次のとおりです。
[application/octet-stream]
When an S-expression is being encoded in one of the representations described in Section 6, 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.
セクション6で説明されている表現の1つでS-Expressionがエンコードされている場合、表示ヒントの表示が含まれています。ディスプレイヒントがデフォルトである場合、それは抑制されていません。また、デフォルトのディスプレイヒントは、ディスプレイヒントなしでオクテットストリングの表現に含まれていません。
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.
同じディスプレイヒントと同じデータオクテットストリングを持っている場合にのみ、ほとんどの計算およびアルゴリズムの目的で2つのオクテットストリングを同等と見なすことをお勧めします。ただし、特定のアプリケーションには別の基準が必要になる場合があります。たとえば、比較に関するディスプレイのヒントを無視する場合があります。
Note that octet-strings are "case-sensitive"; the octet-string "abc" is not equal to the octet-string "ABC".
オクテットストリングは「ケースに敏感」であることに注意してください。オクテットストリングの「ABC」は、オクテットストリング「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 Section 4.6 .
ディスプレイヒントのないオクテットストリングは、アプリケーション用に指定されたデフォルトのディスプレイヒントを備えたオクテットストリングと見なすことにより、またはそのような仕様がない場合、セクション4.6で指定された一般的なデフォルトのディスプレイヒントと見なすことにより、別のオクテットストリング（ディスプレイのヒントを持つ）と比較できます。
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 (Section 4.3) 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.
Octet stringsと同様に、リストを表す際にバリエーションがあります。Whitespaceはリスト要素を分離するために使用される場合がありますが、1つのトークンが別のトークンに従うときのように、2つのオクテットストリングが1つとして解釈される場合は、2つのオクテットストリングを分離するためにのみ必要です。正確には、トークンとして表されるオクテット弦（セクション4.3）は、次のトークン、逐語的表現、または長さが付けられている場合は次のいずれかから、ホワイトスペースによって分離する必要があります。また、Whitespaceは、最初の左括弧に従うか、リストの最終的な右括弧の前にあります。
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+)
()
There are three "types" of representation:
表現には3つの「タイプ」があります。
* 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 [RFC4648] representation of an S-expression may be used as described in Section 6.1.
最初の2つは、実装によってサポートされる必要があります。最後はオプションです。基本表現の一部として、S-Expressionの基本64 [RFC4648]表現は、セクション6.1で説明されているように使用できます。
An S-expression may be represented in a base-64 encoding [RFC4648] consisting of:
S-Expressionは、以下で構成されるベース64エンコード[RFC4648]で表される場合があります。
* an opening curly brace "{"
* オープニングカーリーブレース "{"
* the base-64 [RFC4648] encoding of the S-expression
* S-Expressionのベース64 [RFC4648]エンコード
* 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.
Base-64エンコーディングは、入力3オクテットごとに4文字の出力を生成します。入力の長さを3つの葉で分割すると、残りの1つまたは2つの葉がある場合、それぞれ2つまたは1つの標識で終了する長さ4の出力ブロックが生成されます。これらの等しいサインは出力に含める必要がありますが、入力ルーチンは、1つまたは2つの等しい標識がドロップされる入力を受け入れる場合があります。
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.
開口部の巻き毛のブレースの後、または閉じた巻き毛のブレースが無視される前に、ベース64エンコードの真っin中に挿入されました。WhitespaceとBase-64文字以外の文字を持つことはエラーです。
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 Section 4.5.
セクション4.5の垂直バー（ "| |"）を使用したオクテットストリングのベース64エンコード（ "{{}"）を使用したS-expressionのこのベース64エンコードの違いに注意してください。
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 [CANON1] and [CANON2].
この標準表現は、特定のオクテット値に敏感ではないチャネル上のデジタル署名の目的と輸送に使用されます。それは、各S-Expressionに対して一意に定義されています。それは特に読みやすいわけではありませんが、それはポイントではありません。解析が非常に簡単で、合理的に経済的で、S-Expressionのためにユニークであることを意図しています。[Canon1]および[Canon2]を参照してください。
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 Section 7.2.
S-expressionの「標準的な」形式は、逐語的なモードの各オクテット弦を表し、各リストを表し、互いに互いまたは周囲の括弧から要素を分離するブランクがありません。セクション7.2も参照してください。
Here are some examples of canonical representations of S-expressions:
S-発現の標準表現の例をいくつか紹介します。
(6:issuer3:bob)
(4:icon[12:image/bitmap]9:xxxxxxxxx)
(7:subject(3:ref5:alice6:mother))
10:foo)]}>bar
0:
There are two forms of the "basic transport" representation:
「基本的な輸送」表現には2つの形式があります。
1. The canonical representation
1. 標準表現
2. A base-64 [RFC4648] representation of the canonical representation, surrounded by braces (see Section 6.1)
2. ブレースに囲まれた標準表現のベース64 [RFC4648]表現（セクション6.1を参照）
The basic transport representations (see Section 7.3) 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.
基本的な輸送表現（セクション7.3を参照）は、ある機械から別の機械への輸送のS発現を表す普遍的な手段を提供することを目的としています。S-Expressionが送信されているチャネルが、すべてのゼロビット（null）のオクテット（すべてのビット）のオクテット（del）など、いくつかの特別な値のオクテットに敏感である場合、またはチャネルが時折ライン終了ホワイトスペースが必要であるような「ラインの長さ」に敏感である場合、いくつかの特別な値のオクテットに敏感である場合、ベース64エンコードが適切です。
Here are two examples of an S-expression represented in basic transport mode:
基本的な輸送モードで表されるS-Expressionの2つの例を次に示します。
(1:a1:b1:c)
{KDE6YTE6YjE
6Yyk= }
The second example above is the same S-expression as the first encoded in base-64.
上記の2番目の例は、ベース64で最初にエンコードされたS-Expressionと同じS-Expressionです。
The "advanced transport" representation is intended to provide more flexible and readable notations for documentation, design, debugging, and (in some cases) user interface.
「Advanced Transport」表現は、ドキュメント、設計、デバッグ、および（場合によっては）ユーザーインターフェイスのために、より柔軟で読み取り可能な表記を提供することを目的としています。
The advanced transport representation allows all of the octet-string representation forms described above in Section 4: quoted strings, base-64, hexadecimal, tokens, representations of strings with omitted lengths, and so on. See Section 7.1.
高度な輸送表現により、上記のすべてのオクテット弦表現形式は、セクション4：引用文字列、ベース64、ヘキサデシマル、トークン、省略された文字列の表現などを可能にします。セクション7.1を参照してください。
ABNF is the Augmented Backus-Naur Form for syntax specifications as defined in [RFC5234]. 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 Appendix B.1 of [RFC5234].
ABNFは、[RFC5234]で定義されている構文仕様のための強化されたバックナウル形式です。S-Expressionsの高度な表現のためのABNFが最初に与えられ、基本的な形式と標準形式がそこから導き出されます。すべての大文字の以下のルール名は、[RFC5234]の付録B.1に定義されています。
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)
c-sexp = c-string / ("(" *c-sexp ")")
c-string = [ "[" verbatim "]" ] verbatim
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
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:
このドキュメントでは、一般的な形式のS発現について説明しています。アプリケーションは、S-Expressionsの使用をさまざまな方法で制限し、異なるデフォルトの表示ヒントを指定することをお勧めします。考慮される可能性のある制限は次のとおりです。
* no advanced representations (only canonical and basic)
* 高度な表現はありません（標準的で基本的なみ）
* no display-hints
* ディスプレイヒントはありません
* no lengths on hexadecimal, quoted-strings, or base-64 encodings
* 16進数、引用されたストリング、またはベース64エンコーディングに長さはありません
* no empty lists
* 空のリストはありません
* no empty octet-strings
* 空のオクテットストリングはありません
* no lists having another list as its first element
* 最初の要素として別のリストを持つリストはありません
* no base-64 or hexadecimal encodings
* ベース64またはヘキサデシマルエンコーディングはありません
* fixed limits on the size of octet-strings
* オクテットストリングのサイズの固定制限
As provided in Section 6, 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.
セクション6で規定されているように、コンフォーマントの実装は標準的および基本的な表現をサポートしますが、一般的には高度な表現のサポートは必要ありません。したがって、高度な表現は、そのサポートを義務付けるアプリケーション、または能力発見メカニズムがサポートを示す場所でのみ使用できます。
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:
処理のために、S-Expressionは通常、効率的な処理を受けやすい方法でメモリ内で解析され、表現されます。このドキュメントは、2つの選択肢を提案しています。
* "list-structure"
* 「リスト構造」
* "array-layout"
* 「array-layout」
These are only sketched here, as they are only suggestive. The code in [SexpCode] illustrates these styles in more detail.
これらはここでのみスケッチされています。[sexpcode]のコードは、これらのスタイルをより詳細に示しています。
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 [LISP2].
ここには、シンプルストリング、文字列、リストまたはリストノードの個別のレコードがあります。フォームのs発現（ "abc" "de"）は、シンプルストリングの2つのレコード、文字列の2つ、およびレコードが比較的小さなメモリブロックであり、単純なストリングを除いて他のレコードにポインターを持つ可能性があるリスト要素の2つのレコードとしてエンコードできます。これは、[lisp2]のセクション4で説明したかなり一般的な表現です。
Here each S-expression is represented as a contiguous array of octets. The first octet codes the "type" of the S-expression:
ここでは、各S-Expressionは、オクテットの連続的な配列として表されます。最初のオクテットは、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.
3つのタイプのそれぞれは、すぐに次の表現のサイズ（オクテット）を示すK-OCTET整数が続きます。ここで、Kは実装に依存する整数です。それは2〜8のどこにでもあるかもしれませんが、特定の実装のために修正されます。処理できるオブジェクトのサイズを決定します。輸送表現と標準表現は、実装によって作成されたKの選択とは無関係です。
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.
リストの長さは通常のS発現表記には与えられませんが、解析時にそれらを入力するのは簡単です。右の括弧に到達すると、リスト表現がどれくらいの期間であり、どこに戻って行方不明の長さを埋めるかがわかります。
This is represented as follows:
これは次のように表されます。
01 <length> <octet-string>
For example (here, k = 2):
たとえば、（ここ、k = 2）：
01 0003 a b c
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:
たとえば、S-Expression：
[gif] #61626364#
would be represented as (with k = 2):
（k = 2で）として表されます。
02 000d
01 0003 g i f
01 0004 61 62 63 64
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):
たとえば、リスト（ABC [D] EF（g））は、（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
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 Section 6.2.
純粋なデータ表現形式として、S-Expressionsに対するセキュリティ上の考慮事項はほとんどありません。デジタル署名の一貫した作成と検証には、標準的な形式が必要です。これはセクション6.2に記載されています。
The default display-hint (see Section 4.6) 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.
デフォルトの表示ヒント（セクション4.6を参照）は、アプリケーションに指定できます。そのアプリケーションに表されている未ティップのオクテットストリングを含むS-発明が異なるアプリケーションによって処理される場合、それらの未ティップのオクテットストリングは、異なるディスプレイヒントがあるかのように扱われる可能性があることに注意してください。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[C88] Kernighan, B. and D. Ritchie, "The C Programming
Language", ISBN 0-13-110370-9, 1988.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[BERN] Bernstein, D. J., "Netstrings", Work in Progress,
Internet-Draft, draft-bernstein-netstrings-02, 1 January
1997, <https://datatracker.ietf.org/doc/html/draft-
bernstein-netstrings-02>.
[CANON1] Wikipedia, "Canonical S-expressions",
<https://en.wikipedia.org/wiki/Canonical_S-expressions>.
[CANON2] Grinberg, R., "Csexp - Canonical S-expressions", 24 March
2023, <https://github.com/ocaml-dune/csexp>.
[CDDL-freezer]
Bormann, C., "A feature freezer for the Concise Data
Definition Language (CDDL)", Work in Progress, Internet-
Draft, draft-bormann-cbor-cddl-freezer-15, 28 February
2025, <https://datatracker.ietf.org/doc/html/draft-
bormann-cbor-cddl-freezer-15>.
[Formal] Petit-Huguenin, M., "A Formalization of Symbolic
Expressions", Work in Progress, Internet-Draft, draft-
petithuguenin-ufmrg-formal-sexpr-06, 4 May 2025,
<https://datatracker.ietf.org/doc/html/draft-
petithuguenin-ufmrg-formal-sexpr-06>.
[GnuPG] GnuPG, "The GNU Privacy Guard", <https://www.gnupg.org/>.
[Inferno] "Inferno S-expressions", Inferno Manual Page,
<https://man.cat-v.org/inferno/6/sexprs>.
[Libgcrypt]
GnuPG, "The Libgcrypt Library", Libgcrypt version 1.10.2,
6 April 2023,
<https://www.gnupg.org/documentation/manuals/gcrypt/>.
[LISP] McCarthy, J., Abrahams, P. W., Edwards, D. J., Hart, T.
P., and M. Levin, "LISP 1.5 Programmer's Manual",
ISBN-13 978-0-262-12011-0, ISBN-10 0262130114, 15 August
1962,
<https://www.softwarepreservation.org/projects/LISP/book/
LISP%201.5%20Programmers%20Manual.pdf>.
[LISP2] McCarthy, J., "Recursive Functions of Symbolic Expressions
and Their Computation by Machine, Part I", April 1960,
<https://people.cs.umass.edu/~emery/classes/cmpsci691st/
readings/PL/LISP.pdf>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
Atkinson, R., Crispin, M., and P. Svanberg, "The Report of
the IAB Character Set Workshop held 29 February - 1 March,
1996", RFC 2130, DOI 10.17487/RFC2130, April 1997,
<https://www.rfc-editor.org/info/rfc2130>.
[RFC2692] Ellison, C., "SPKI Requirements", RFC 2692,
DOI 10.17487/RFC2692, September 1999,
<https://www.rfc-editor.org/info/rfc2692>.
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
DOI 10.17487/RFC2693, September 1999,
<https://www.rfc-editor.org/info/rfc2693>.
[RFC3259] Ott, J., Perkins, C., and D. Kutscher, "A Message Bus for
Local Coordination", RFC 3259, DOI 10.17487/RFC3259, April
2002, <https://www.rfc-editor.org/info/rfc3259>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, DOI 10.17487/RFC3275, March 2002,
<https://www.rfc-editor.org/info/rfc3275>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[Ribose] Ribose Group Inc., "Open-source projects for developers
and designers", <https://open.ribose.com/>.
[RNPGP_SEXPP]
"S-Expressions parser and generator library in C++ (SEXP
in C++)", Version 0.9.2, commit 249c6e3, 22 March 2025,
<https://github.com/rnpgp/sexpp>.
[SDSI] Rivest, R. and B. Lampson, "A Simple Distributed Security
Architecture", Working document for SDSI version 1.1, 2
October 1996, <https://people.csail.mit.edu/rivest/pubs/
RL96.ver-1.1.html>.
[SexpCode] "SEXP---(S-expressions)", commit 4aa7c36, 10 June 2015,
<https://github.com/jpmalkiewicz/rivest-sexp>.
[SEXPP] "SexpProcessor", commit a90f90f, 11 April 2025,
<https://github.com/seattlerb/sexp_processor>.
[SFEXP] "Small Fast X-Expression Library", commit b7d3bea, 24
March 2023, <https://github.com/mjsottile/sfsexp>.
[SPKI] Rivest, R., "SPKI/SDSI 2.0 A Simple Distributed Security
Infrastructure",
<https://people.csail.mit.edu/rivest/pubs/RL96.slides-
maryland.pdf>.
[Unicode] The Unicode Consortium, "The Unicode Standard",
<https://www.unicode.org/versions/latest/>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0",
W3C Recommendation, 26 November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>. Latest
version available at <https://www.w3.org/TR/REC-xml/>.
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:
現時点では、ここで指定されているさまざまなS-Expression形式の一部またはすべてを読み取り、解析することを目的とした複数のオープンソースがあります。特に、以下を参照してください - 不完全な可能性があります - リスト：
* Project GNU's [Libgcrypt]
* プロジェクトGNUの[libgcrypt]
* Ribose's RNP [RNPGP_SEXPP] in C++
* C ++のリボースのRNP [RNPGP_SEXPP]
* Github project of J. P. Malkiewicz [SexpCode] in C
* c
* The Inferno implementation [Inferno]
* インフェルノの実装[Inferno]
* Small Fast X-Expression Library [SFEXP]
* 小さな高速X-発現ライブラリ[SFEXP]
* S-expression Processor [SEXPP] in Ruby
* RubyのS-Expression Processor [sexpp]
* Canonical S-expressions [CANON2] (OCAML)
* 標準的なS-発明[Canon2]（OCAML）
Special thanks to Daniel K. Gillmor for his extensive comments.
彼の広範なコメントをしてくれたダニエル・K・ギルモアに感謝します。
The comments and suggestions of the following are gratefully acknowledged: John Klensin and Caleb Malchik.
以下のコメントと提案は、ジョン・クレンシンとカレブ・マルチクのコメントに感謝しています。
Special thanks to Marc Petit-Huguenin, particularly for his extensive work and advice on the ABNF and on locating and fixing unclear parts of earlier draft versions of this document:
Marc Petit-Hugueninに感謝します。特に、ABNFに関する彼の広範な作業とアドバイス、およびこのドキュメントの以前のドラフトバージョンの不明確な部分を見つけて修正したことに感謝します。
Marc Petit-Huguenin
Impedance Mismatch LLC
Email: marc@petit-huguenin.org
Ronald L. Rivest
MIT CSAIL
32 Vassar Street, Room 32-G692
Cambridge, Massachusetts 02139
United States of America
Email: rivest@mit.edu
URI: https://www.csail.mit.edu/person/ronald-l-rivest
Donald E. Eastlake 3rd
Independent
2386 Panoramic Circle
Apopka, Florida 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com