Diff: rfc9804.original.xml

	rfc9804.original.xml	rfc9804.xml

	<?XML333 version="1.0" encoding="utf-8"?>	<?xml version='1.0' encoding='UTF-8'?>
	<?xml-model href="rfc7991bis.rnc"?> <!-- Required for schema
	validation and schema-aware editing -->

	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY filename "draft-rivest-sexp-13">	<!ENTITY nbsp " ">
	<!ENTITY nbsp " ">	<!ENTITY zwsp "">
	<!ENTITY zwsp "">	<!ENTITY nbhy "‑">
	<!ENTITY nbhy "‑">	<!ENTITY wj "⁠">
	<!ENTITY wj "⁠">
	]>	]>

	<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
	<!-- This third-party XSLT can be enabled for direct transformations
	in XML processors, including most browsers -->
	<!-- If further character entities are required then they should be
	added to the DOCTYPE above. Use of an external entity file is not
	recommended. -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>


	<rfc	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft
	xmlns:xi="http://www.w3.org/2001/XInclude"	-rivest-sexp-13" number="9804" ipr="trust200902" obsoletes="" submissionType="
	category="info"	IETF" xml:lang="en" version="3" updates="" consensus="true" tocInclude="true"
	docName="&filename;"	symRefs="true" sortRefs="true">
	ipr="trust200902"
	obsoletes=""
	submissionType="IETF"
	xml:lang="en"
	version="3">
	<!--
	* docName should be the name of your draft * category should be
	one of std, bcp, info, exp, historic * ipr should be one of
	trust200902, noModificationTrust200902, noDerivativesTrust200902,
	pre5378Trust200902 * updates can be an RFC number as NNNN *
	obsoletes can be an RFC number as NNNN


	<!-- ____________________FRONT_MATTER____________________ -->
	<front>	<front>
	<title abbrev="SPKI S-Expressions">Simple Public Key Infrastructure	<title abbrev="SPKI S-Expressions">Simple Public Key Infrastructure
	(SPKI) S-Expressions</title>	(SPKI) S-Expressions</title>

	<!-- The abbreviated title is required if the full title is	<seriesInfo name="RFC" value="9804"/>
	longer than 39 characters -->

	<seriesInfo name="Internet-Draft"
	value="&filename;"/>


	<author fullname="Ronald L. Rivest" initials="R."	<author fullname="Ronald L. Rivest" initials="R." surname="Rivest">
	surname="Rivest">
	<organization>MIT CSAIL</organization>	<organization>MIT CSAIL</organization>
	<address>	<address>
	<postal>	<postal>
	<street>32 Vassar Street, Room 32-G692</street>	<street>32 Vassar Street, Room 32-G692</street>
	<city>Cambridge</city>	<city>Cambridge</city>
	<region>Massachusetts</region>	<region>Massachusetts</region>
	<code>02139</code>	<code>02139</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>rivest@mit.edu</email>	<email>rivest@mit.edu</email>
	<uri>https://www.csail.mit.edu/person/ronald-l-rivest</uri>	<uri>https://www.csail.mit.edu/person/ronald-l-rivest</uri>
	</address>	</address>
	</author>	</author>


	<author fullname="Donald E. Eastlake 3rd" initials="D."	<author fullname="Donald E. Eastlake 3rd" initials="D." surname="Eastlake">
	surname="Eastlake">
	<organization>Independent</organization>	<organization>Independent</organization>
	<address>	<address>
	<postal>	<postal>
	<street>2386 Panoramic Circle</street>	<street>2386 Panoramic Circle</street>
	<city>Apopka</city>	<city>Apopka</city>
	<region>Florida</region>	<region>Florida</region>
	<code>32703</code>	<code>32703</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone>+1-508-333-2270</phone>	<phone>+1-508-333-2270</phone>
	<email>d3e3e3@gmail.com</email>	<email>d3e3e3@gmail.com</email>
	</address>	</address>
	</author>	</author>


	<date year="2025" month="1" day="9"/>	<date year="2025" month="June"/>


	<area>Applications and Real Time</area>	<area>ART</area>


	<workgroup>Network Working Group</workgroup>	<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->


	<keyword>Sexp</keyword>	<keyword>example</keyword>
	<!-- Multiple keywords are allowed. Keywords are incorporated
	into HTML output files for use by search engines. -->


		<!--[rfced] FYI, we updated this sentence to remove "and",
		as the phrasing "[A] specifies [B] and with the intent" reads oddly.
		The first sentence of the introduction has been updated as well.
		Please let us know if you prefer otherwise.

		Original:
		This memo specifies the data structure representation that was
		devised to support Simple Public Key Infrastructure (SPKI, RFC 2692)
		certificates and with the intent that it be more widely applicable.

		Current:
		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 it be
		more widely applicable.

		Original:

		Current:
		-->
	<abstract>	<abstract>
	<t>This memo specifies the data structure representation that was	<t>This memo specifies the data structure representation that was

	devised to support Simple Public Key Infrastructure (SPKI, RFC 2692)	devised to support Simple Public Key Infrastructure (SPKI)
	certificates and with the intent that it be more widely	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	applicable. It has been and is being used elsewhere. There are
	multiple implementations in a variety of programming languages. Uses	multiple implementations in a variety of programming languages. Uses
	of this representation are referred to in this document as	of this representation are referred to in this document as
	"S-expressions". This memo makes precise the encodings of these	"S-expressions". This memo makes precise the encodings of these

	SPKI S-expressions: it gives a "canonical form" for them, describes	SPKI S-expressions: It gives a "canonical form" for them, describes
	two "transport" representations, and also describes an "advanced"	two "transport" representations, and also describes an "advanced"
	format for display to people.</t>	format for display to people.</t>
	</abstract>	</abstract>

	</front>	</front>


	<!-- ____________________MIDDLE_MATTER____________________ -->
	<middle>	<middle>


	<section> <!-- 1. -->	<section>
	<name>Introduction</name>	<name>Introduction</name>

	<t>This memo specifies the data structure representation that was	<t>This memo specifies the data structure representation that was

	devised to support Simple Public Key Infrastructure (SPKI) <xref	devised to support Simple Public Key Infrastructure (SPKI) certificates <xref
	target="RFC2692"/> certificates and with the intent that it be more	target="RFC2692"/>, with the intent that it be more
	widely applicable (see <xref target="history"/>, History). It is	widely applicable (see <xref target="history"/>, "Historical Note"). It is
	suitable for representing arbitrary, complex data structures and has	suitable for representing arbitrary, complex data structures and has
	been and is being used elsewhere. Uses of this representation herein	been and is being used elsewhere. Uses of this representation herein
	are referred to as "S-expressions".</t>	are referred to as "S-expressions".</t>

	<t>This memo makes precise the encodings of these SPKI	<t>This memo makes precise the encodings of these SPKI

	S-expressions: it gives a "canonical form" for them, describes two	S-expressions: It gives a "canonical form" for them, describes two
	"transport" representations, and also describe an "advanced" format	"transport" representations, and also describes an "advanced" format
	for display to people. There are multiple implementations of	for display to people. There are multiple implementations of
	S-expressions in a variety of programming languages including Python,	S-expressions in a variety of programming languages including Python,
	Ruby, and C (see <xref target="Code"/>).</t>	Ruby, and C (see <xref target="Code"/>).</t>

	<t>These S-expressions are either byte-strings ("octet-strings") or	<t>These S-expressions are either byte-strings ("octet-strings") or
	lists of simpler S-expressions. Here is a sample S-expression:</t>	lists of simpler S-expressions. Here is a sample S-expression:</t>


	<sourcecode>	<sourcecode><![CDATA[
	(snicker "abc" (#03# \|YWJj\|))	(snicker "abc" (#03# \|YWJj\|))

	</sourcecode>	]]></sourcecode>

	<t>It is a list of length three containing the following:</t>	<t>It is a list of length three containing the following:</t>

	<ul>	<ul>
	<li>the octet-string "snicker"</li>	<li>the octet-string "snicker"</li>

	<li>the octet-string "abc"</li>	<li>the octet-string "abc"</li>


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

	<t>This document specifies how to construct and use these	<t>This document specifies how to construct and use these
	S-expressions.</t>	S-expressions.</t>

	<t>The design goals for S-expressions were as follows:</t>	<t>The design goals for S-expressions were as follows:</t>


	<dl>	<ul spacing="normal">


	<dt>generality:</dt><dd>S-expressions should be good at representing	<li>Generality: S-expressions should be good at representing
	arbitrary data.</dd>	arbitrary data.</li>


	<dt>readability:</dt><dd>It should be easy for someone to examine and	<li>Readability: It should be easy for someone to examine and
	understand the structure of an S-expression.</dd>	understand the structure of an S-expression.</li>


	<dt>economy:</dt><dd>S-expressions should represent data	<li>Economy: S-expressions should represent data
	compactly.</dd>	compactly.</li>


	<dt>transportability:</dt><dd>S-expressions should be easy to transport	<li>Transportability: S-expressions should be easy to transport
	over communication media (such as email) that are known to be less	over communication media (such as email) that are known to be less

	than perfect.</dd>	than perfect.</li>


	<dt>flexibility:</dt><dd>S-expressions should make it relatively	<li>Flexibility: S-expressions should make it relatively
	simple to modify and extend data structures.</dd>	simple to modify and extend data structures.</li>


	<dt>canonicalization:</dt><dd>It should be easy to produce a unique	<li>Canonicalization: It should be easy to produce a unique
	"canonical" form of an S-expression, for digital signature	"canonical" form of an S-expression, for digital signature

	purposes.</dd>	purposes.</li>


	<dt>efficiency:</dt><dd>S-expressions should admit in-memory	<li>Efficiency: S-expressions should admit in-memory
	representations that allow efficient processing.</dd>	representations that allow efficient processing.</li>


	</dl>	</ul>

	<t>For implementors of new applications and protocols other	<t>For implementors of new applications and protocols other

	technologies also worthy of consideration include the following: <xref	technologies also worthy of consideration include the following: XML <xref
	target="XML"/>, CBOR <xref target="RFC8949"/>, and JSON <xref	target="XML"/>, CBOR <xref target="RFC8949"/>, and JSON <xref

	target="RFC7159"/>.</t>	target="RFC8259"/>.</t>


	<section> <!-- 1.1 -->	<section>
	<name>Uses of S-Expressions</name>	<name>Uses of S-Expressions</name>

	<t>The S-expressions specified herein are in active use today between	<t>The S-expressions specified herein are in active use today between
	GnuPG <xref target="GnuPG"/> and Ribose's RNP <xref target="Ribose"/>.	GnuPG <xref target="GnuPG"/> and Ribose's RNP <xref target="Ribose"/>.
	Ribose has implemented C++ software to compose and parse these	Ribose has implemented C++ software to compose and parse these

	S-expressions <xref target="RNPGP_SEXPP"/>. The GNU software is here	S-expressions <xref target="RNPGP_SEXPP"/>. The GNU software is the Libgcrypt l
	<xref target="Libgcrypt"/> and there are other implementations (see	ibrary <xref target="Libgcrypt"/>, and there are other implementations (see
	<xref target="Code"/>).</t>	<xref target="Code"/>).</t>


		<!-- [rfced] For clarity, what does "They" refer to?
		Perhaps "S-expressions"? (Preceding paragraph included for context)

		Original:
		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 here [Libgcrypt] and there are other implementations
		(see Appendix A).

		They are used or referenced in the following RFCs:

		Perhaps:
		S-expressions are also used or referenced in the following RFCs:
		-->

	<t>They are used or referenced in the following RFCs:</t>	<t>They are used or referenced in the following RFCs:</t>

	<ul>	<ul>
	<li><xref target="RFC2693"/> for <xref target="SPKI"/></li>	<li><xref target="RFC2693"/> for <xref target="SPKI"/></li>
	<li><xref target="RFC3275"/> XML-Signature Syntax and	<li><xref target="RFC3275"/> XML-Signature Syntax and
	Processing</li>	Processing</li>
	</ul>	</ul>


	<t>In addition, S-Expressions are the inspiration for the encodings in	<t>In addition, S-expressions are the inspiration for the encodings in
	other protocols. For example, <xref target="RFC3259"/> or Section 6 of	other protocols. For example, <xref target="RFC3259"/> or <xref section="6" targ
	<xref target="CDDLfreezer"/>.</t>	et="I-D.bormann-cbor-cddl-freezer"/>.</t>

	</section>	</section>

	<section>	<section>
	<name>Formalization</name>	<name>Formalization</name>


	<t>An Internet Draft <xref target="formal"/> has been posted showing	<t><xref target="I-D.petithuguenin-ufmrg-formal-sexpr"/> is an Internet-Draft
	a formal model of SPKI S-Expressions and which formally demonstrates	that shows
		a formal model of SPKI S-expressions and formally demonstrates
	that the examples and ABNF in this document are correct.</t>	that the examples and ABNF in this document are correct.</t>

	</section>	</section>


	<section anchor="history"> <!-- 1.3 -->	<section anchor="history">
	<name>Historical Note</name>	<name>Historical Note</name>

	<t>The S-expressions described here were originally developed for	<t>The S-expressions described here were originally developed for
	"SDSI" (the Simple Distributed Security Infrastructure by Lampson and	"SDSI" (the Simple Distributed Security Infrastructure by Lampson and
	Rivest <xref target="SDSI"/>) in 1996, although their origins date	Rivest <xref target="SDSI"/>) in 1996, although their origins date
	back to McCarthy's <xref target="LISP"/> programming language. They	back to McCarthy's <xref target="LISP"/> programming language. They
	were further refined and improved during the merger of SDSI and SPKI	were further refined and improved during the merger of SDSI and SPKI
	<xref target="SPKI"/> <xref target="RFC2692"/> <xref	<xref target="SPKI"/> <xref target="RFC2692"/> <xref
	target="RFC2693"/> during the first half of 1997. S-expressions are	target="RFC2693"/> during the first half of 1997. S-expressions are

	more readable and flexible than, Bernstein's "net-strings" <xref	more readable and flexible than Bernstein's "netstrings" <xref
	target="BERN"/>, which were developed contemporaneously.</t>	target="BERN"/>, which were developed contemporaneously.</t>

	<aside>	<aside>
	<t>Although a specification was made publicly available as a file	<t>Although a specification was made publicly available as a file
	named draft-rivest-sexp-00.txt on 4 May 1997, that file was never	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	actually submitted to the IETF. This document is a clarified and
	modernized version of that document.</t>	modernized version of that document.</t>
	</aside>	</aside>


	</section> <!-- 1.3 -->	</section>


	<section> <!-- 1.4 -->	<section>
	<name>Conventions Used in This Document</name>	<name>Conventions Used in This Document</name>

		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		</section>


	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	</section>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	when, they appear in all capitals, as shown here.</t>

	</section> <!-- 1.4 -->

	</section> <!-- end 1. Introduction -->


	<section anchor="Sec2"> <!-- 2. -->	<section anchor="Sec2">
	<name>S-expressions -- informal introduction</name>	<name>S-expressions -- Informal Introduction</name>

	<t>Informally, an S-expression is either:</t>	<t>Informally, an S-expression is either:</t>

	<ul spacing="compact">	<ul spacing="compact">
	<li>an octet-string, or</li>	<li>an octet-string, or</li>
	<li>a finite list of simpler S-expressions.</li>	<li>a finite list of simpler S-expressions.</li>
	</ul>	</ul>

	<t>An octet-string is a finite sequence of eight-bit octets. An	<t>An octet-string is a finite sequence of eight-bit octets. An
	octet-string may be zero length. There may be many different but	octet-string may be zero length. There may be many different but
	equivalent ways of representing an octet-string</t>	equivalent ways of representing an octet-string</t>


	<sourcecode>	<!-- [rfced] Regarding the sourcecode elements in Sections 2, 3, 4.2, 4.4,
		and 4.5, should any of these be formatted as lists? We ask because these
		elements appear to be lists rather than formal language or pseudocode.
		(See https://authors.ietf.org/rfcxml-vocabulary#sourcecode for more details
		on this element.)

		Current (Section 2):
		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"

		Perhaps:
		* 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"
		-->

		<sourcecode><![CDATA[
	abc -- as a token	abc -- as a token
	"abc" -- as a quoted string	"abc" -- as a quoted string
	#616263# -- as a hexadecimal string	#616263# -- as a hexadecimal string
	3:abc -- as a length-prefixed "verbatim" encoding	3:abc -- as a length-prefixed "verbatim" encoding
	\|YWJj\| -- as a base-64 encoding of the octet-string	\|YWJj\| -- as a base-64 encoding of the octet-string
	"abc"	"abc"

	</sourcecode>	]]></sourcecode>

	<t>The above encodings are all equivalent in that they all denote the	<t>The above encodings are all equivalent in that they all denote the
	same octet-string. Details of these encodings are given below, and how	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 <xref	to give a "display type" to a simple-string is also described in <xref
	target="DisplayHint"/>.</t>	target="DisplayHint"/>.</t>

	<t>A list is a finite sequence of zero or more simpler S-expressions.	<t>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	A list is represented by using parentheses to surround the sequence of
	encodings of its elements, as in:</t>	encodings of its elements, as in:</t>


	<sourcecode>	<sourcecode><![CDATA[
	(abc (de #6667#) "ghi jkl")	(abc (de #6667#) "ghi jkl")

	</sourcecode>	]]></sourcecode>

	<t>As can be seen, there is variability possible in the encoding of an	<t>As can be seen, there is variability possible in the encoding of an
	S-expression. In some applications, it is desirable to standardize or	S-expression. In some applications, it is desirable to standardize or
	restrict the encodings; in other cases, it is desirable to have no	restrict the encodings; in other cases, it is desirable to have no
	restrictions. The following are the target cases these S-expressions	restrictions. The following are the target cases these S-expressions
	aim to handle:</t>	aim to handle:</t>

	<ul>	<ul>

	<li>a "transport" or "basic" encoding for transporting the	<li>a "transport" or "basic" encoding for transporting the

	S-expression between computers.</li>	S-expression between computers</li>

	<li>a "canonical" encoding, used when signing the	<li>a "canonical" encoding, used when signing the

	S-expression.</li>	S-expression</li>


	<li>an "advanced" encoding used for input/output to people.</li>	<li>an "advanced" encoding used for input/output to people</li>

	<li>an "in-memory" encoding used for processing the S-expression	<li>an "in-memory" encoding used for processing the S-expression

	in the computer.</li>	in the computer</li>

	</ul>	</ul>

	<t>In this document, related encoding techniques for each of these	<t>In this document, related encoding techniques for each of these
	uses are provided.</t>	uses are provided.</t>

	</section>	</section>


	<section anchor="Sec3"> <!-- 3. -->	<section anchor="Sec3">
	<name>Character set</name>	<name>Character Set</name>

	<t>This document specifies encodings of S-expressions. Except when	<t>This document specifies encodings of S-expressions. Except when
	giving "verbatim" encodings, the character set used is limited to the	giving "verbatim" encodings, the character set used is limited to the
	following characters in ASCII <xref target="RFC0020"/>:</t>	following characters in ASCII <xref target="RFC0020"/>:</t>

	<dl spacing="compact">	<dl spacing="compact">

	<dt>Alphabetic:</dt><dd>	<dt>Alphabetic:</dt><dd>

	<sourcecode>	<sourcecode><![CDATA[
	A B ... Z a b ... z	A B ... Z a b ... z

	</sourcecode></dd>	]]></sourcecode></dd>

	<dt>Numeric:</dt><dd>	<dt>Numeric:</dt><dd>

	<sourcecode>	<sourcecode><![CDATA[
	0 1 ... 9	0 1 ... 9

	</sourcecode></dd>	]]></sourcecode></dd>

	<dt>Whitespace:</dt><dd>	<dt>Whitespace:</dt><dd>

	<sourcecode>	<sourcecode><![CDATA[
	space, horizontal tab, vertical tab, form-feed	space, horizontal tab, vertical tab, form-feed
	carriage-return, line-feed	carriage-return, line-feed

	</sourcecode></dd>	]]></sourcecode></dd>

	<dt>The following graphics characters, which are called	<dt>The following graphics characters, which are called
	"pseudo-alphabetic" in this document:</dt><dd/>	"pseudo-alphabetic" in this document:</dt><dd/>
	<dt></dt><dd>	<dt></dt><dd>

	<sourcecode>	<sourcecode><![CDATA[
	- hyphen or minus	- hyphen or minus
	. period	. period
	/ slash	/ slash
	_ underscore	_ underscore
	: colon	: colon
	* asterisk	* asterisk
	+ plus	+ plus
	= equal	= equal

	</sourcecode>	]]></sourcecode>
	</dd>	</dd>

	<dt>The following graphics characters, which are "reserved	<dt>The following graphics characters, which are "reserved
	punctuation":</dt><dd/>	punctuation":</dt><dd/>
	<dt></dt><dd>	<dt></dt><dd>

	<sourcecode> <![CDATA[	<sourcecode><![CDATA[
	( left parenthesis	( left parenthesis
	) right parenthesis	) right parenthesis
	[ left bracket	[ left bracket
	] right bracket	] right bracket
	{ left brace	{ left brace
	} right brace	} right brace
	\| vertical bar	\| vertical bar
	# number sign	# number sign
	" double quote	" double quote
	& ampersand	& ampersand
	\ backslash	\ backslash

	]]> </sourcecode>	]]></sourcecode>
	</dd>	</dd>

	<dt>The following characters are unused and unavailable, except in	<dt>The following characters are unused and unavailable, except in
	"verbatim" and "quoted string" encodings:</dt><dd/>	"verbatim" and "quoted string" encodings:</dt><dd/>
	<dt></dt><dd>	<dt></dt><dd>

	<sourcecode> <![CDATA[	<sourcecode><![CDATA[
	! exclamation point	! exclamation point
	% percent	% percent
	^ circumflex	^ circumflex
	~ tilde	~ tilde
	; semicolon	; semicolon
	' single-quote (apostrophe)	' single-quote (apostrophe)
	, comma	, comma
	< less than	< less than
	> greater than	> greater than
	? question mark	? question mark

	]]> </sourcecode>	]]></sourcecode>
	</dd>	</dd>

	</dl>	</dl>


	</section> <!-- 3 -->	</section>


	<section anchor="Sec4"> <!-- 4. -->	<section anchor="Sec4">
	<name>Octet-string representation types</name>	<name>Octet-String Representation Types</name>

	<t>This section describes in detail the ways in which an octet-string may	<t>This section describes in detail the ways in which an octet-string may
	be represented.</t>	be represented.</t>


	<t>Recall that an octet-string is any finite sequence of octets, and	<t>Recall that an octet-string is any finite sequence of octets and
	that an octet-string may have length zero.</t>	that an octet-string may have length zero.</t>


	<section> <!-- 4.1 -->	<section>
	<name>Verbatim representation</name>	<name>Verbatim Representation</name>

	<t>A verbatim encoding of an octet-string consists of three parts:</t>	<t>A verbatim encoding of an octet-string consists of three parts:</t>

	<ul>	<ul>

	<li>the length (number of octets) of the octet-string, given in	<li>the length (number of octets) of the octet-string, given in

	decimal, most significant digit first, with no leading zeros.</li>	decimal, most significant digit first, with no leading zeros</li>

	<li>a colon ":"</li>	<li>a colon ":"</li>


	<li>the octet-string itself, verbatim.</li>	<li>the octet-string itself, verbatim</li>

	</ul>	</ul>

	<t>There are no blanks or whitespace separating the parts. No "escape	<t>There are no blanks or whitespace separating the parts. No "escape
	sequences" are interpreted in the octet-string. This encoding is also	sequences" are interpreted in the octet-string. This encoding is also
	called a "binary" or "raw" encoding.</t>	called a "binary" or "raw" encoding.</t>

	<t>Here are some sample verbatim encodings:</t>	<t>Here are some sample verbatim encodings:</t>


	<sourcecode>	<sourcecode><![CDATA[
	3:abc	3:abc
	7:subject	7:subject
	4:::":	4:::":
	12:hello world!	12:hello world!
	10:abcdefghij	10:abcdefghij
	0:	0:

	</sourcecode>	]]></sourcecode>


	</section> <!-- 4.1 -->	</section>


	<section> <!-- 4.2 -->	<section>
	<name>Quoted-string representation</name>	<name>Quoted-String Representation</name>

	<t>The quoted-string representation of an octet-string consists of:</t>	<t>The quoted-string representation of an octet-string consists of:</t>

	<ul>	<ul>

	<li>an optional decimal length field</li>	<li>an optional decimal length field</li>

	<li>an initial double-quote (")</li>	<li>an initial double-quote (")</li>


	<li>the octet-string with the "C" programming language <xref	<li>the octet-string with the C programming language <xref
	target="C"/> escape conventions (\n, etc.)</li>	target="C"/> escape conventions (\n, etc.)</li>

	<li>a final double-quote (")</li>	<li>a final double-quote (")</li>

	</ul>	</ul>

	<t>The specified length is the length of the resulting string after	<t>The specified length is the length of the resulting string after
	any backslash escape sequences have been converted to the octet value	any backslash escape sequences have been converted to the octet value
	they denote. The string does not have any "terminating NULL" that	they denote. The string does not have any "terminating NULL" that
	<xref target="C"/> includes, and the length does not count such an	<xref target="C"/> includes, and the length does not count such an
	octet.</t>	octet.</t>

	<t>The length is optional.</t>	<t>The length is optional.</t>

	<t>The escape conventions within the quoted string are as follows	<t>The escape conventions within the quoted string are as follows

	(these follow the "C" <xref target="C"/> programming language	(these follow the C programming language <xref target="C"/>
	conventions, with an extension for ignoring line terminators of just	conventions, with an extension for ignoring line terminators of just
	CR, LF, CRLF, or LFCR and more restrictive octal and hexadecimal value	CR, LF, CRLF, or LFCR and more restrictive octal and hexadecimal value
	formats):</t>	formats):</t>


	<sourcecode>	<sourcecode><![CDATA[
	\a -- audible alert (bell)	\a -- audible alert (bell)
	\b -- backspace	\b -- backspace
	\t -- horizontal tab	\t -- horizontal tab
	\v -- vertical tab	\v -- vertical tab
	\n -- new-line	\n -- new-line
	\f -- form-feed	\f -- form-feed
	\r -- carriage-return	\r -- carriage-return
	\" -- double-quote	\" -- double-quote
	\' -- single-quote	\' -- single-quote
	\? -- question mark	\? -- question mark
	\\ -- back-slash	\\ -- back-slash
	\ooo -- character with octal value ooo (all three	\ooo -- character with octal value ooo (all three
	digits MUST be present)	digits MUST be present)
	\xhh -- character with hexadecimal value hh (both	\xhh -- character with hexadecimal value hh (both
	digits MUST be present)	digits MUST be present)

	\<carriage-return> -- causes carriage-return	\<carriage-return> -- causes carriage-return to be ignored.
	to be ignored.	\<line-feed> -- causes line-feed to be ignored.
	\<line-feed> -- causes linefeed to be	\<carriage-return><line-feed> -- causes
	ignored.
	\<carriage-return><line-feed> -- causes
	CRLF to be ignored.	CRLF to be ignored.

	\<line-feed><carriage-return> -- causes	\<line-feed><carriage-return> -- causes
	LFCR to be ignored.	LFCR to be ignored.

	</sourcecode>	]]></sourcecode>

	<t>Here are some examples of quoted-string encodings:</t>	<t>Here are some examples of quoted-string encodings:</t>


	<sourcecode>	<sourcecode><![CDATA[
	"subject"	"subject"
	"hi there"	"hi there"
	7"subject"	7"subject"
	"\xFE is the same octet as \376"	"\xFE is the same octet as \376"
	3"\n\n\n"	3"\n\n\n"
	"This has\n two lines."	"This has\n two lines."
	"This has \	"This has \
	one line."	one line."
	""	""

	</sourcecode>	]]></sourcecode>


	</section> <!-- 4.2 -->	</section>


	<section anchor="token"> <!-- 4.3 -->	<section anchor="token">
	<name>Token representation</name>	<name>Token Representation</name>

	<t>An octet-string that meets the following conditions may be given	<t>An octet-string that meets the following conditions may be given
	directly as a "token":</t>	directly as a "token":</t>

	<ul>	<ul>
	<li>it does not begin with a digit;</li>	<li>it does not begin with a digit;</li>


	<li>it contains only characters that are: alphabetic (upper or lower	<li><t>it contains only characters that are: alphabetic (upper or lower
	case), numeric, or one of the following eight "pseudo-alphabetic" punctuation	case), numeric, or one of the following eight "pseudo-alphabetic" punctuation

	marks:  -  .  /  _  :  *  +  =</li>	marks:</t>
		<artwork>
		- . / _ : * + =
		</artwork>
		</li>
	<li>it is length 1 or greater.</li>	<li>it is length 1 or greater.</li>
	</ul>	</ul>

	<t>Note: Upper and lower case are not equivalent.	<t>Note: Upper and lower case are not equivalent.
	A token may begin with punctuation, including ":".</t>	A token may begin with punctuation, including ":".</t>

	<t>Here are some examples of token representations:</t>	<t>Here are some examples of token representations:</t>


	<sourcecode>	<sourcecode><![CDATA[
	subject	subject
	not-before	not-before
	:=..	:=..
	class-of-1997	class-of-1997
	//example.net/names/smith	//example.net/names/smith
	*	*

	</sourcecode>	]]></sourcecode>


	</section> <!-- 4.3 -->	</section>


	<section> <!-- 4.4 -->	<section>
	<name>Hexadecimal representation</name>	<name>Hexadecimal Representation</name>

	<t>An octet-string may be represented with a hexadecimal encoding	<t>An octet-string may be represented with a hexadecimal encoding
	consisting of:</t>	consisting of:</t>

	<ul>	<ul>

	<li>an (optional) decimal length of the octet-string</li>	<li>an (optional) decimal length of the octet-string</li>

	<li>a sharp-sign "#"</li>	<li>a sharp-sign "#"</li>

	<li>a hexadecimal encoding of the octet-string, with each octet	<li>a hexadecimal encoding of the octet-string, with each octet
	represented with two hexadecimal digits, most significant digit	represented with two hexadecimal digits, most significant digit

	first. There MUST be an even number of such digits.</li>	first. There <bcp14>MUST</bcp14> be an even number of such digits.</li>

	<li>a final sharp-sign "#"</li>	<li>a final sharp-sign "#"</li>

	</ul>	</ul>

	<t>There may be whitespace inserted in the midst of the hexadecimal	<t>There may be whitespace inserted in the midst of the hexadecimal
	encoding arbitrarily; it is ignored. It is an error to have	encoding arbitrarily; it is ignored. It is an error to have
	characters other than whitespace and hexadecimal digits.</t>	characters other than whitespace and hexadecimal digits.</t>

	<t>Here are some examples of hexadecimal encodings:</t>	<t>Here are some examples of hexadecimal encodings:</t>


	<sourcecode>	<sourcecode><![CDATA[
	#616263# -- represents "abc"	#616263# -- represents "abc"
	3#616263# -- also represents "abc"	3#616263# -- also represents "abc"
	# 616	# 616
	263 # -- also represents "abc"	263 # -- also represents "abc"
	## -- represents the zero-length string	## -- represents the zero-length string

	</sourcecode>	]]></sourcecode>


	</section> <!-- 4.4 -->	</section>


	<section anchor="base64string"> <!-- 4.5 -->	<section anchor="base64string">
	<name>Base-64 representation of octet-strings</name>	<name>Base-64 Representation of Octet-Strings</name>

	<t>An octet-string may be represented in a base-64 encoding <xref	<t>An octet-string may be represented in a base-64 encoding <xref
	target="RFC4648"/> consisting of:</t>	target="RFC4648"/> consisting of:</t>

	<ul>	<ul>
	<li>an (optional) decimal length of the octet-string</li>	<li>an (optional) decimal length of the octet-string</li>

	<li>a vertical bar "\|"</li>	<li>a vertical bar "\|"</li>

	<li>the base-64 <xref target="RFC4648"/> encoding of the	<li>the base-64 <xref target="RFC4648"/> encoding of the
	octet-string.</li>	octet-string.</li>

	<li>a final vertical bar "\|"</li>	<li>a final vertical bar "\|"</li>
	</ul>	</ul>


		<!-- [rfced] In Section 4.5, regarding this text:

		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.

		Is the following accurate?
		* If the remainder is one, then it produces a block length of four
		with two equals signs.
		* If the remainder is two, then it produces a block length of four
		with one equals sign.
		We ask in order to verify the use of "respectively".

		Perhaps it would also be helpful to include an example of each
		instance? Please let us know if/how we may update.
		-->

	<t>Base-64 encoding produces four characters of output for each three	<t>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	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	remainder of one or two, it produces an output block of length four
	ending in two or one equals signs, respectively. These equals signs	ending in two or one equals signs, respectively. These equals signs

	MUST be included on output but input routines MAY accept inputs where	<bcp14>MUST</bcp14> be included on output, but input routines <bcp14>MAY</bcp14> accept inputs where
	one or two equals signs are dropped.</t>	one or two equals signs are dropped.</t>

	<t>Whitespace inserted in the midst of the base-64 encoding is	<t>Whitespace inserted in the midst of the base-64 encoding is
	ignored. It is an error to have characters other than whitespace and	ignored. It is an error to have characters other than whitespace and
	base-64 characters.</t>	base-64 characters.</t>

	<t>Here are some examples of base-64 encodings:</t>	<t>Here are some examples of base-64 encodings:</t>


	<sourcecode>	<sourcecode><![CDATA[
	\|YWJj\| -- represents "abc"	\|YWJj\| -- represents "abc"
	\| Y W	\| Y W
	J j \| -- also represents "abc"	J j \| -- also represents "abc"
	3\|YWJj\| -- also represents "abc"	3\|YWJj\| -- also represents "abc"
	\|YWJjZA==\| -- represents "abcd"	\|YWJjZA==\| -- represents "abcd"
	\|YWJjZA\| -- also represents "abcd"	\|YWJjZA\| -- also represents "abcd"
	\|\| -- represents the zero-length string	\|\| -- represents the zero-length string

	</sourcecode>	]]></sourcecode>

	<t>Note the difference between this base-64 encoding of an	<t>Note the difference between this base-64 encoding of an
	octet-string using vertical bars ("\| \|") and the base-64 encoding of	octet-string using vertical bars ("\| \|") and the base-64 encoding of
	an S-expression using curly braces ("{ }") in <xref	an S-expression using curly braces ("{ }") in <xref
	target="base64sexp"/>.</t>	target="base64sexp"/>.</t>


	</section> <!-- 4.5 -->	</section>


	<section anchor="DisplayHint"> <!-- 4.6 -->	<section anchor="DisplayHint">
	<name>Display-Hints and Internationalization</name>	<name>Display-Hints and Internationalization</name>

	<t>An octet-string can contain any type of data representable by a	<t>An octet-string can contain any type of data representable by a

	finite octet-string, for example text, a fixed or variable length	finite octet-string, e.g., text, a fixed or variable-length
	integer, or an image. Normally the application producing / consuming	integer, or an image. Normally, the application producing and/or consuming
	S-expressions will understand their structure and the data type and	S-expressions will understand their structure, the data type, and
	encoding of the octet-strings within the S-expressions used by that	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	application. If the octet-string consists of text, use of UTF-8

	encoding is RECOMMENDED <xref target="RFC2130"/> <xref	encoding is <bcp14>RECOMMENDED</bcp14> <xref target="RFC2130"/> <xref
	target="RFC3629"/>.</t>	target="RFC3629"/>.</t>


	<t>The purposes of a display-hint is to provide information on how to	<!--[rfced] We received guidance that, in general, "MIME types" should
		be referred to as "media types". May we update the text as follows?

		Original:
		Many of the MIME [RFC2046] types work here.

		Perhaps:
		Many of the media types [RFC2046] work here.
		-->
		<t>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	display an octet-string to a user. It has no other function. Many of
	the MIME <xref target="RFC2046"/> types work here.</t>	the MIME <xref target="RFC2046"/> types work here.</t>

	<t>A display-hint is an octet-string representation surrounded by	<t>A display-hint is an octet-string representation surrounded by
	square brackets. There may be whitespace separating the display hint	square brackets. There may be whitespace separating the display hint
	octet-string from the surrounding brackets. Any of the legal	octet-string from the surrounding brackets. Any of the legal

	octet-string representations may be used for the display-hint string	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	but a display-hint may not be applied to a display-hint string -- that
	is, display-hints may not be nested.</t>	is, display-hints may not be nested.</t>


	<t>A display-hint that can be used for UTF-8 encoded text is shown in	<!--[rfced] Section 4.6: We updated the text because non-ASCII
	the following example where the octet-string is text saying "bob", with an	characters can appear in RFCs. Please review and let us know if you
	umlaut over the central "o", followed by a smilie emoji.</t>	prefer otherwise.


	<sourcecode>	Original:
		A display-hint that can be used for UTF-8 encoded text is shown in
		the following example where the octet-string is text saying "bob",
		with an umlaut over the central "o", followed by a smilie emoji.

		["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA"

		Current:
		A display-hint that can be used for UTF-8-encoded text is shown in
		the following example where the octet-string is "böb☺", i.e., "bob"
		with an umlaut over the "o", followed by WHITE SMILING FACE (U+263A).

		["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA"
		-->

		<t>A display-hint that can be used for UTF-8-encoded text is shown in
		the following example where the octet-string is "böb☺", i.e., "bob" with an umla
		ut over the "o", followed by WHITE SMILING FACE (U+263A).</t>

		<sourcecode><![CDATA[
	["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA"	["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA"

	</sourcecode>	]]></sourcecode>

		<!-- [rfced] May this be rephrased as follows for clarity?

		Current:
		Every octet-string representation is either preceded by a single
		display-hint or not so preceded.

		Perhaps:
		Every octet-string representation may or may not be preceded by a
		single display-hint.
		-->

	<t>Every octet-string representation is either preceded by a single	<t>Every octet-string representation is either preceded by a single
	display-hint or not so preceded. There may be whitespace between	display-hint or not so preceded. There may be whitespace between
	the close square bracket and the octet-string to which the hint	the close square bracket and the octet-string to which the hint
	applies.</t>	applies.</t>

	<t>Here are some other examples of display-hints:</t>	<t>Here are some other examples of display-hints:</t>


	<sourcecode>	<sourcecode><![CDATA[
	[image/gif]	[image/gif]
	[charset=unicode-1-1]	[charset=unicode-1-1]
	[ text/richtext ]	[ text/richtext ]
	["text/plain; charset=iso-8859-1"]	["text/plain; charset=iso-8859-1"]
	[application/postscript]	[application/postscript]
	[audio/basic]	[audio/basic]
	["http://example.com/display-types/funky.html"]	["http://example.com/display-types/funky.html"]

	</sourcecode>	]]></sourcecode>

	<t>An octet-string that has no display-hint may be considered to have	<t>An octet-string that has no display-hint may be considered to have
	a MIME <xref target="RFC2046"/> type specified by the application or	a MIME <xref target="RFC2046"/> type specified by the application or
	use. In the absence of such a specification, the default is as	use. In the absence of such a specification, the default is as
	follows:</t>	follows:</t>


	<sourcecode>	<sourcecode><![CDATA[
	[application/octet-stream]	[application/octet-stream]

	</sourcecode>	]]></sourcecode>


	<t>When an S-Expression is being encoded in one of the representations	<t>When an S-expression is being encoded in one of the representations
	described in <xref target="Represent"/>, any display-hint present is	described in <xref target="Represent"/>, any display-hint present is
	included. If a display-hint is the default, it is not suppressed nor	included. If a display-hint is the default, it is not suppressed nor
	is the default display-hint included in the representation for an	is the default display-hint included in the representation for an
	octet-string without a display-hint.</t>	octet-string without a display-hint.</t>


	</section> <!-- 4.6 -->	</section>


	<section> <!-- 4.7 -->	<section>
	<name>Comparison of octet-strings</name>	<name>Comparison of Octet-Strings</name>


	<t>It is RECOMMENDED that two octet-strings be considered equivalent	<t>It is <bcp14>RECOMMENDED</bcp14> that two octet-strings be considered equival ent
	for most computational and algorithmic purposes if and only if they	for most computational and algorithmic purposes if and only if they
	have the same display-hint and the same data octet-strings. However, a	have the same display-hint and the same data octet-strings. However, a
	particular application might need a different criterion. For example,	particular application might need a different criterion. For example,
	it might ignore the display hint on comparisons.</t>	it might ignore the display hint on comparisons.</t>

	<t>Note that octet-strings are "case-sensitive"; the octet-string	<t>Note that octet-strings are "case-sensitive"; the octet-string
	"abc" is not equal to the octet-string "ABC".</t>	"abc" is not equal to the octet-string "ABC".</t>

	<t>An octet-string without a display-hint may be compared to another	<t>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 or without a display hint) by considering it as an
	octet-string with the default display-hint specified for the	octet-string with the default display-hint specified for the
	applications or, in the absence of such specification, the general	applications or, in the absence of such specification, the general
	default display-hint specified in <xref target="DisplayHint"/> .</t>	default display-hint specified in <xref target="DisplayHint"/> .</t>


	</section> <!-- 4.7 -->	</section>


	</section> <!-- 4. -->	</section>


	<section anchor="Sec5"> <!-- 5. -->	<section anchor="Sec5">
	<name>Lists</name>	<name>Lists</name>

	<t>Just as with octet-strings, there are variations in representing a	<t>Just as with octet-strings, there are variations in representing a
	list. Whitespace may be used to separate list elements, but they are	list. Whitespace may be used to separate list elements, but they are
	only required to separate two octet-strings when otherwise the two	only required to separate two octet-strings when otherwise the two
	octet-strings might be interpreted as one, as when one token follows	octet-strings might be interpreted as one, as when one token follows
	another. To be precise, an octet-string represented as a token (<xref	another. To be precise, an octet-string represented as a token (<xref

	target="token"/>) MUST be separated by whitespace from a following	target="token"/>) <bcp14>MUST</bcp14> be separated by whitespace from a followin g
	token, verbatim representation, or any of the following if they are	token, verbatim representation, or any of the following if they are
	prefixed with a length: quoted-string, hexadecimal, or base-64	prefixed with a length: quoted-string, hexadecimal, or base-64
	representation. Also, whitespace may follow the initial left	representation. Also, whitespace may follow the initial left

	parenthesis, or precede the final right parenthesis of a list.</t>	parenthesis or precede the final right parenthesis of a list.</t>

	<t>Here are some examples of encodings of lists:</t>	<t>Here are some examples of encodings of lists:</t>


	<sourcecode>	<sourcecode><![CDATA[
	(a bob c)	(a bob c)

	( a ( bob c ) ( ( d e ) ( e f ) ) )	( a ( bob c ) ( ( d e ) ( e f ) ) )

	(11:certificate(6:issuer3:bob)(7:subject5:alice))	(11:certificate(6:issuer3:bob)(7:subject5:alice))

	(\|ODpFeGFtcGxlIQ==\| "1997" murphy 3:XC+)	(\|ODpFeGFtcGxlIQ==\| "1997" murphy 3:XC+)

	()	()

	</sourcecode>	]]></sourcecode>

	</section>	</section>


	<section anchor="Represent"> <!-- 6. -->	<section anchor="Represent">
	<name>S-expression representation types</name>	<name>S-Expression Representation Types</name>

	<t>There are three "types" of representation: </t>	<t>There are three "types" of representation: </t>

	<ul>	<ul>
	<li>canonical</li>	<li>canonical</li>

	<li>basic transport</li>	<li>basic transport</li>

	<li>advanced transport</li>	<li>advanced transport</li>
	</ul>	</ul>


	<t>The first two MUST be supported by any implementation; the last is	<t>The first two <bcp14>MUST</bcp14> be supported by any implementation; the las
	OPTIONAL. As part of basic representation, the base-64 <xref	t is
		<bcp14>OPTIONAL</bcp14>. As part of basic representation, the base-64 <xref
	target="RFC4648"/> representation of an S-expression may be used as	target="RFC4648"/> representation of an S-expression may be used as
	described in <xref target="base64sexp"/>.</t>	described in <xref target="base64sexp"/>.</t>

	<section anchor="base64sexp">	<section anchor="base64sexp">

	<name>Base-64 representation of S-expressions</name>	<name>Base-64 Representation of S-Expressions</name>

	<t>An S-expression may be represented in a base-64 encoding <xref	<t>An S-expression may be represented in a base-64 encoding <xref
	target="RFC4648"/> consisting of:</t>	target="RFC4648"/> consisting of:</t>

	<ul>	<ul>
	<li>an opening curly brace "{"</li>	<li>an opening curly brace "{"</li>

	<li>the base-64 <xref target="RFC4648"/> encoding of the	<li>the base-64 <xref target="RFC4648"/> encoding of the

	S-expression.</li>	S-expression</li>

	<li>a final closing curly brace "}"</li>	<li>a final closing curly brace "}"</li>
	</ul>	</ul>

	<t>Base-64 encoding produces four characters of output for each three	<t>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	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	remainder of one or two, it produces an output block of length four
	ending in two or one equals signs, respectively. These equals signs	ending in two or one equals signs, respectively. These equals signs

	MUST be included on output but input routines MAY accept inputs where	<bcp14>MUST</bcp14> be included on output, but input routines <bcp14>MAY</bcp14> accept inputs where
	one or two equals signs are dropped.</t>	one or two equals signs are dropped.</t>

	<t>Whitespace inserted in the midst of the base-64 encoding, after the	<t>Whitespace inserted in the midst of the base-64 encoding, after the
	opening curly brace, or before the closing curly brace is ignored. It	opening curly brace, or before the closing curly brace is ignored. It
	is an error to have characters other than whitespace and base-64	is an error to have characters other than whitespace and base-64
	characters.</t>	characters.</t>

	<t>Note the difference between this base-64 encoding of an	<t>Note the difference between this base-64 encoding of an
	S-expression using curly braces ("{ }") and the base-64 encoding of an	S-expression using curly braces ("{ }") and the base-64 encoding of an
	octet-string using vertical bars ("\| \|") in <xref	octet-string using vertical bars ("\| \|") in <xref
	target="base64string"/>.</t>	target="base64string"/>.</t>

	</section>	</section>

	<section anchor="canonical">	<section anchor="canonical">

	<name>Canonical representation</name>	<name>Canonical Representation</name>

	<t>This canonical representation is used for digital signature	<t>This canonical representation is used for digital signature
	purposes and transport over channels not sensitive to specific octet	purposes and transport over channels not sensitive to specific octet
	values. It is uniquely defined for each S-expression. It is not	values. It is uniquely defined for each S-expression. It is not
	particularly readable, but that is not the point. It is intended to	particularly readable, but that is not the point. It is intended to

	be very easy to parse, to be reasonably economical, and to be unique	be very easy to parse, reasonably economical, and unique
	for any S-expression. (See <xref target="CANON"/>.)</t>	for any S-expression. See <xref target="CANON1"/> and <xref target="CANON2"/>.</
		t>

	<t>The "canonical" form of an S-expression represents each	<t>The "canonical" form of an S-expression represents each
	octet-string in verbatim mode, and represents each list with no blanks	octet-string in verbatim mode, and represents each list with no blanks
	separating elements from each other or from the surrounding	separating elements from each other or from the surrounding

	parentheses (see also <xref target="ABNFc"/>).</t>	parentheses. See also <xref target="ABNFc"/>.</t>

	<t>Here are some examples of canonical representations of	<t>Here are some examples of canonical representations of
	S-expressions:</t>	S-expressions:</t>


	<sourcecode>	<sourcecode><![CDATA[
	(6:issuer3:bob)	(6:issuer3:bob)
	(4:icon[12:image/bitmap]9:xxxxxxxxx)	(4:icon[12:image/bitmap]9:xxxxxxxxx)
	(7:subject(3:ref5:alice6:mother))	(7:subject(3:ref5:alice6:mother))
	10:foo)]}>bar	10:foo)]}>bar
	0:	0:

	</sourcecode>	]]></sourcecode>

	</section>	</section>

	<section>	<section>

	<name>Basic transport representation</name>	<name>Basic Transport Representation</name>

	<t>There are two forms of the "basic transport" representation:</t>	<t>There are two forms of the "basic transport" representation:</t>


	<ul>	<ol>
	<li>the canonical representation</li>	<li>The canonical representation</li>


	<li>an <xref target="RFC4648"/> base-64 representation of the	<li>A base-64 <xref target="RFC4648"/> representation of the
	canonical representation, surrounded by braces (see <xref	canonical representation, surrounded by braces (see <xref

	target="base64sexp"/>).</li>	target="base64sexp"/>)</li>
	</ul>	</ol>

	<t>The basic transport representations (see <xref target="ABNFb"/>)	<t>The basic transport representations (see <xref target="ABNFb"/>)
	are intended to provide a universal means of representing	are intended to provide a universal means of representing
	S-expressions for transport from one machine to another. The base-64	S-expressions for transport from one machine to another. The base-64
	encoding would be appropriate if the channel over which the	encoding would be appropriate if the channel over which the
	S-expression is being sent might be sensitive to octets of some	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	special values, such as an octet of all zero bits (NULL) or an octet

	of all one bits (DEL), or the channel is sensitive to "line length"	of all one bits (DEL), or if the channel is sensitive to "line length"
	such that occasional line terminating whitespace is needed.</t>	such that occasional line terminating whitespace is needed.</t>

	<t>Here are two examples of an S-expression represented in basic	<t>Here are two examples of an S-expression represented in basic
	transport mode:</t>	transport mode:</t>


	<sourcecode>	<sourcecode><![CDATA[
	(1:a1:b1:c)	(1:a1:b1:c)

	{KDE6YTE6YjE	{KDE6YTE6YjE
	6Yyk= }	6Yyk= }

	</sourcecode>	]]></sourcecode>

	<t>The second example above is the same S-expression as the first	<t>The second example above is the same S-expression as the first
	encoded in base-64.</t>	encoded in base-64.</t>

	</section>	</section>

	<section>	<section>

	<name>Advanced transport representation</name>	<name>Advanced Transport Representation</name>

	<t>The "advanced transport" representation is intended to provide more	<t>The "advanced transport" representation is intended to provide more
	flexible and readable notations for documentation, design, debugging,	flexible and readable notations for documentation, design, debugging,
	and (in some cases) user interface.</t>	and (in some cases) user interface.</t>

	<t>The advanced transport representation allows all of the	<t>The advanced transport representation allows all of the

	octet-string representation forms described above in Section 4: quoted	octet-string representation forms described above in <xref target="Sec4"/>: quot ed
	strings, base-64, hexadecimal, tokens, representations of strings with	strings, base-64, hexadecimal, tokens, representations of strings with

	omitted lengths, and so on. (See <xref target="ABNFa"/>).</t>	omitted lengths, and so on. See <xref target="ABNFa"/>.</t>

	</section>	</section>


	</section> <!-- 6. -->	</section>


	<section anchor="ABNF"> <!-- 7. -->	<section anchor="ABNF">
	<name>ABNF of the syntax</name>	<name>ABNF of the Syntax</name>

	<t>ABNF is the Augmented Backus-Naur Form for syntax specifications as	<t>ABNF is the Augmented Backus-Naur Form for syntax specifications as
	defined in <xref target="RFC5234"/>. The ABNF for advanced	defined in <xref target="RFC5234"/>. The ABNF for advanced

	representation of S-expressions is given first and the basic and	representation of S-expressions is given first, and the basic and
	canonical forms derived therefrom. The rule names below in all	canonical forms are derived therefrom. The rule names below in all
	capital letters are defined in Appendix B.1 of <xref	capital letters are defined in <xref section="B.1"
	target="RFC5234"/>.</t>	target="RFC5234"/>.</t>

	<section anchor="ABNFa">	<section anchor="ABNFa">

	<name>ABNF for advanced transport</name>	<name>ABNF for Advanced Transport</name>


	<sourcecode type="ABNF"> <![CDATA[	<sourcecode type="abnf"> <![CDATA[
	sexp = whitespace value whitespace	sexp = whitespace value whitespace

	whitespace = SP / HTAB / vtab / CR / LF / ff	whitespace = SP / HTAB / vtab / CR / LF / ff

	vtab = %x0B ; vertical tab	vtab = %x0B ; vertical tab

	ff = %x0C ; form feed	ff = %x0C ; form feed

	value = string / ("(" *(value / whitespace) ")")	value = string / ("(" *(value / whitespace) ")")


	skipping to change at line 952 ¶	skipping to change at line 1028 ¶
	base-64-char = ALPHA / DIGIT / "+" / "/"	base-64-char = ALPHA / DIGIT / "+" / "/"

	base-64-end = base-64-chars /	base-64-end = base-64-chars /
	3(base-64-char whitespace) ["=" whitespace] /	3(base-64-char whitespace) ["=" whitespace] /
	2(base-64-char whitespace) 2("=" *whitespace)	2(base-64-char whitespace) 2("=" *whitespace)
	]]> </sourcecode>	]]> </sourcecode>

	</section>	</section>

	<section anchor="ABNFc">	<section anchor="ABNFc">

	<name>ABNF for canonical</name>	<name>ABNF for Canonical</name>


	<sourcecode type="ABNF"> <![CDATA[	<sourcecode type="abnf"> <![CDATA[
	c-sexp = c-string / ("(" *c-sexp ")")	c-sexp = c-string / ("(" *c-sexp ")")

	c-string = [ "[" verbatim "]" ] verbatim	c-string = [ "[" verbatim "]" ] verbatim
	]]> </sourcecode>	]]> </sourcecode>

	</section>	</section>
	<section anchor="ABNFb">	<section anchor="ABNFb">

	<name>ABNF for basic transport</name>	<name>ABNF for Basic Transport</name>


	<sourcecode type="ABNF"> <![CDATA[	<sourcecode type="abnf"> <![CDATA[
	b-sexp = c-sexp / b-base-64	b-sexp = c-sexp / b-base-64

	b-base-64 = "{" whitespace base-64-chars base-64-end "}"	b-base-64 = "{" whitespace base-64-chars base-64-end "}"
	; encodes a c-sexp, which has a minimum	; encodes a c-sexp, which has a minimum
	; length of 2	; length of 2
	]]> </sourcecode>	]]> </sourcecode>

	</section>	</section>


	</section> <!-- 7. -->	</section>


	<section> <!-- 8. -->	<section>
	<name>Restricted S-expressions</name>	<name>Restricted S-Expressions</name>

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

	<ul>	<ul>

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

	<t>As provided in <xref target="Represent"/>, conformant	<t>As provided in <xref target="Represent"/>, conformant

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

	</section>	</section>


	<section anchor="Sec8"> <!-- 9. -->	<section anchor="Sec8">
	<name>In-memory representations</name>	<name>In-Memory Representations</name>

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

	<ul>	<ul>
	<li>"list-structure"</li>	<li>"list-structure"</li>

	<li>"array-layout"</li>	<li>"array-layout"</li>
	</ul>	</ul>

	<t>These are only sketched here, as they are only suggestive. The	<t>These are only sketched here, as they are only suggestive. The

	<xref target="SexpCode"/> code illustrates these styles in more	code in <xref target="SexpCode"/> illustrates these styles in more
	detail.</t>	detail.</t>


	<section> <!-- 9.1 -->	<section>
	<name>List-structure memory representation</name>	<name>List-Structure Memory Representation</name>

	<t>Here there are separate records for simple-strings, strings, and	<t>Here there are separate records for simple-strings, strings, and
	lists or list nodes. An S-expression of the form ("abc" "de") could	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,	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	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	block of memory and, except for simple-string, might have pointers in
	it to other records. This is a fairly conventional representation as	it to other records. This is a fairly conventional representation as
	discussed in Section 4 of <xref target="LISP2"/>.</t>	discussed in Section 4 of <xref target="LISP2"/>.</t>

	</section>	</section>


	<section> <!-- 9.2 -->	<section>
	<name>Array-layout memory representation</name>	<name>Array-Layout Memory Representation</name>

	<t>Here each S-expression is represented as a contiguous array of octets.	<t>Here each S-expression is represented as a contiguous array of octets.
	The first octet codes the "type" of the S-expression:</t>	The first octet codes the "type" of the S-expression:</t>


	<sourcecode>	<sourcecode><![CDATA[01 octet-string]]></sourcecode>
	01 octet-string


	02 octet-string with display-hint	<sourcecode><![CDATA[02 octet-string with display-hint]]></sourcecode>


	03 beginning of list (and 00 is used for "end of list")	<sourcecode><![CDATA[03 beginning of list (and 00 is used for "end of list")]]
	</sourcecode>	></sourcecode>

	<t>Each of the three types is immediately followed by a k-octet integer	<t>Each of the three types is immediately followed by a k-octet integer

	indicating the size (in octets) of the following representation. Here	indicating the size (in octets) of the following representation. Here,
	k is an integer that depends on the implementation, it might be	k is an integer that depends on the implementation. It might be
	anywhere from 2 to 8, but would be fixed for a given implementation;	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	it determines the size of the objects that can be handled. The
	transport and canonical representations are independent of the choice	transport and canonical representations are independent of the choice
	of k made by the implementation.</t>	of k made by the implementation.</t>

	<t>Although the lengths of lists are not given in the usual	<t>Although the lengths of lists are not given in the usual
	S-expression notations, it is easy to fill them in when parsing; when	S-expression notations, it is easy to fill them in when parsing; when

	you reach a right-parenthesis you know how long the list	you reach a right parenthesis, you know how long the list
	representation was, and where to go back to fill in the missing	representation was and where to go back to fill in the missing
	length.</t>	length.</t>


	<section> <!-- 9.2.1 -->	<section>
	<name>Octet-string</name>	<name>Octet-String</name>

	<t>This is represented as follows:</t>	<t>This is represented as follows:</t>

	<sourcecode> <![CDATA[	<sourcecode> <![CDATA[
	01 <length> <octet-string>	01 <length> <octet-string>
	]]> </sourcecode>	]]> </sourcecode>


	<t>For example (here k = 2)</t>	<t>For example (here, k = 2):</t>


	<sourcecode>	<sourcecode><![CDATA[
	01 0003 a b c	01 0003 a b c

	</sourcecode>	]]></sourcecode>

	</section>	</section>


	<section> <!-- 9.2.2 -->	<section>
	<name>Octet-string with display-hint</name>	<name>Octet-String with Display-Hint</name>

	<t>This is represented as follows:</t>	<t>This is represented as follows:</t>

	<sourcecode> <![CDATA[	<sourcecode> <![CDATA[
	02 <length>	02 <length>
	01 <length> <octet-string> /* for display-type */	01 <length> <octet-string> /* for display-type */
	01 <length> <octet-string> /* for octet-string */	01 <length> <octet-string> /* for octet-string */
	]]> </sourcecode>	]]> </sourcecode>


	<t>For example, the S-expression </t>	<t>For example, the S-expression: </t>


	<sourcecode>	<sourcecode><![CDATA[
	[gif] #61626364#	[gif] #61626364#

	</sourcecode>	]]></sourcecode>


	<t>would be represented as (with k = 2)</t>	<t>would be represented as (with k = 2):</t>


	<sourcecode>	<sourcecode><![CDATA[
	02 000d	02 000d
	01 0003 g i f	01 0003 g i f
	01 0004 61 62 63 64	01 0004 61 62 63 64

	</sourcecode>	]]></sourcecode>

	</section>	</section>


	<section> <!-- 9.2.3 -->	<section>
	<name>List</name>	<name>List</name>


	<t>This is represented as</t>	<t>This is represented as:</t>

	<sourcecode> <![CDATA[	<sourcecode> <![CDATA[
	03 <length> <item1> <item2> <item3> ... <item> 00	03 <length> <item1> <item2> <item3> ... <item> 00
	]]> </sourcecode>	]]> </sourcecode>

	<t>For example, the list (abc [d]ef (g)) is represented in memory as	<t>For example, the list (abc [d]ef (g)) is represented in memory as

	(with k = 2)</t>	(with k = 2):</t>


	<sourcecode>	<sourcecode><![CDATA[
	03 001b	03 001b
	01 0003 a b c	01 0003 a b c
	02 0009	02 0009
	01 0001 d	01 0001 d
	01 0002 e f	01 0002 e f
	03 0005	03 0005
	01 0001 g	01 0001 g
	00	00
	00	00

	</sourcecode>	]]></sourcecode>

	</section>	</section>

	</section> <!-- 9.2 -->	</section>
	</section> <!-- 9. -->	</section>


	<section anchor="Sec10"> <!-- 10. -->	<section anchor="Sec10">
	<name>Security Considerations</name>	<name>Security Considerations</name>

	<t>As a pure data representation format, there are few security	<t>As a pure data representation format, there are few security
	considerations to S-expressions. A canonical form is required for the	considerations to S-expressions. A canonical form is required for the
	consistent creation and verification of digital signatures. This is	consistent creation and verification of digital signatures. This is
	provided in <xref target="canonical"/>.</t>	provided in <xref target="canonical"/>.</t>

	<t>The default display-hint (see <xref target="DisplayHint"/>) can be	<t>The default display-hint (see <xref target="DisplayHint"/>) can be
	specified for an application. Note that if S-expressions containing	specified for an application. Note that if S-expressions containing
	untyped octet-strings represented for that application are processed	untyped octet-strings represented for that application are processed
	by a different application, those untyped octet-string may be treated	by a different application, those untyped octet-string may be treated
	as if they had a different display-hint.</t>	as if they had a different display-hint.</t>


	</section> <!-- 10. -->	</section>


	<section anchor="Sec12"> <!-- 11. -->	<section anchor="Sec12">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>


	<t>This document requires no IANA actions.</t>	<t>This document has no IANA actions.</t>


	</section> <!-- 11. -->	</section>

	</middle>	</middle>


	<!-- ____________________BACK_MATTER____________________ -->
	<back>	<back>


		<displayreference target="I-D.petithuguenin-ufmrg-formal-sexpr" to="Formal"/>
		<displayreference target="I-D.bormann-cbor-cddl-freezer" to="CDDL-freezer"/>

		<references>
		<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>


		<!-- [rfced] Regarding this reference, the C programming language standard
		is now an ISO/IEC standard: ISO/IEC 9899:2024
		(https://www.iso.org/standard/82075.html).

		A technically equivalent specification is available from the C Programming
		Language working group (JTC1/SC22/WG14):
		https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf.

		May we update this reference as shown below or otherwise?

		Original:
		[C] Kernighan, B. and D. Ritchie, "The C Programming
		Language", ISBN 0-13-110370-9, 1988.

		Perhaps:
		[C] ISO/IEC, "Information technology — Programming languages —
		C", ISO/IEC 9899:2024, 2024,
		<https://www.iso.org/standard/82075.html>. Technically
		equivalent specification available here:
		<https://www.open-std.org/jtc1/sc22/wg14/www/docs/
		n3220.pdf>.
		-->

		<!-- Note: Here's the XML for the ISO/IEC Standard if the authors choose it.
		<reference anchor="C" target="https://www.iso.org/standard/82075.html">
		<front>
		<title>Information technology — Programming languages — C</title>
		<author>
		<organization>ISO/IEC</organization>
		</author>
		<date year="2024"/>
		</front>
		<seriesInfo name="ISO/IEC" value="9899:2024"/>
		<annotation>Technically equivalent specification available here: <eref target=
		"https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf" brackets="angle"/>.
		</annotation>
		</reference>
		-->

	<reference anchor="C">	<reference anchor="C">
	<front>	<front>
	<title>The C Programming Language</title>	<title>The C Programming Language</title>
	<author surname="Kernighan" initials="B."	<author surname="Kernighan" initials="B."
	fullname="Brian W. Kernighan"/>	fullname="Brian W. Kernighan"/>
	<author surname="Ritchie" initials="D."	<author surname="Ritchie" initials="D."
	fullname="Dennis M. Ritchie"/>	fullname="Dennis M. Ritchie"/>
	<date year="1988"/>	<date year="1988"/>
	</front>	</front>
	<seriesInfo name="ISBN" value="0-13-110370-9"/>	<seriesInfo name="ISBN" value="0-13-110370-9"/>
	</reference>	</reference>

	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.0020.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3629.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4648.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5234.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

	</references>	</references>

	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>


	<reference anchor="BERN"	<reference anchor="BERN" target="https://datatracker.ietf.org/doc/html/draft-ber
	target="https://www.ietf.org/archive/id/draft-bernstein-netstrings-02.txt">	nstein-netstrings-02">
	<front>	<front>
	<title>Netstrings</title>	<title>Netstrings</title>
	<author surname="Bernstein" initials="D."	<author initials="D. J." surname="Bernstein" fullname="D. J. Bernstein">
	fullname="Daniel J. Bernstein"/>	</author>
	<date year="1997" month="2" day="1"/>	<date month="January" day="1" year="1997" />
	</front>	</front>
	<seriesInfo name="Work in" value="progress"/>	<seriesInfo name="Internet-Draft" value="draft-bernstein-netstrings-02" />
	</reference>	</reference>


	<referencegroup anchor="CANON">	<!-- [rfced] Regarding the [CANON] reference, we split it into
	<reference anchor="CANON2"	two entries, as one is a Wikipedia article and the other is a
		GitHub repository. Please let us know if you prefer different
		symbolic names.

		Original:
		[CANON] Wikipedia, "Canonical S-expressions",
		<https://en.wikipedia.org/wiki/Canonical_S-expressions>.

		Grinberg, R., "Csexp - Canonical S-expressions", 24 March
		2023, <https://github.com/ocaml-dune/csexp>.

		Current:
		[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>.

		Please review the two instances where [CANON] was cited in the original
		and let us know if any updates are needed. FYI, we updated the second one
		to cite only [CANON2], as the former does not mention OCAML.

		Original:
		* Canonical S-expressions [CANON] (OCAML)

		Current:
		* Canonical S-expressions [CANON2] (OCAML)
		-->

		<reference anchor="CANON1"
	target="https://en.wikipedia.org/wiki/Canonical_S-expressions">	target="https://en.wikipedia.org/wiki/Canonical_S-expressions">
	<front>	<front>
	<title>Canonical S-expressions</title>	<title>Canonical S-expressions</title>
	<author surname="Wikipedia" fullname="Wikipedia"/>	<author surname="Wikipedia" fullname="Wikipedia"/>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="CANON3"	<reference anchor="CANON2"
	target="https://github.com/ocaml-dune/csexp">	target="https://github.com/ocaml-dune/csexp">
	<front>	<front>
	<title>Csexp - Canonical S-expressions</title>	<title>Csexp - Canonical S-expressions</title>
	<author surname="Grinberg" initials="R."	<author surname="Grinberg" initials="R."
	fullname="Rudi Grinberg"/>	fullname="Rudi Grinberg"/>
	<date year="2023" month="3" day="24"/>	<date year="2023" month="3" day="24"/>
	</front>	</front>
	</reference>	</reference>

	</referencegroup>


	<reference anchor="CDDLfreezer"	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bormann-
	target="https://datatracker.ietf.org/doc/draft-bormann-cbor-cddl-freezer/">	cbor-cddl-freezer.xml"/>
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.petithug
	<title>A feature freezer for the Concise Data Definition Language	uenin-ufmrg-formal-sexpr.xml"/>
	(CDDL)</title>
	<author surname="Bormann" initials="C."
	fullname="Carsten Bormann">
	<organization>Universität Bremen TZI</organization>
	</author>
	<date year="2023" month="9" day="12"/>
	</front>
	<seriesInfo name="work" value="in progress"/>
	</reference>

	<reference anchor="formal"
	target="https://datatracker.ietf.org/doc/html/draft-petithuguenin-ufmr
	g-formal-sexpr-04">
	<front>
	<title>A Formalization of Symbolic Expressions</title>
	<author fullname="Marc Petit-Huguenin"
	surname="Petit-Huguenin" initials="M.">
	<organization>Impedance Mismatch LLC</organization>
	</author>
	<date year="2024" month="05" day="24"/>
	</front>
	<seriesInfo name="work" value="in progress"/>
	</reference>

	<reference anchor="GnuPG"	<reference anchor="GnuPG"
	target="https://www.gnupg.org/">	target="https://www.gnupg.org/">
	<front>	<front>
	<title>The GNU Privacy Guard</title>	<title>The GNU Privacy Guard</title>
	<author>	<author>

	<organization>Free Software Foundation, Inc.</organization>	<organization>GnuPG</organization>
	</author>	</author>
	</front>	</front>
	</reference>	</reference>


		<!-- [Inferno] Note to PE: I couldn't confirm the original
		author information, so I removed it. -->
	<reference anchor="Inferno"	<reference anchor="Inferno"

	target="http://man.cat-v.org/inferno/6/sexprs">	target="https://man.cat-v.org/inferno/6/sexprs">
	<front>	<front>
	<title>Inferno S-expressions</title>	<title>Inferno S-expressions</title>

	<author surname="Uriel" fullname="Uriel">	<author/>
	<organization>Random Contrarian Insurgent
	Organization</organization>
	</author>
	</front>	</front>

		<refcontent>Inferno Manual Page</refcontent>
	</reference>	</reference>

	<reference anchor="Libgcrypt"	<reference anchor="Libgcrypt"
	target="https://www.gnupg.org/documentation/manuals/gcrypt/">	target="https://www.gnupg.org/documentation/manuals/gcrypt/">
	<front>	<front>
	<title>The Libgcrypt Library</title>	<title>The Libgcrypt Library</title>
	<author>	<author>
	<organization>GnuPG</organization>	<organization>GnuPG</organization>
	</author>	</author>
	<date year="2023" month="4" day="6"/>	<date year="2023" month="4" day="6"/>
	</front>	</front>

	<seriesInfo name="Libgcrypt version" value="1.10.2"/>	<refcontent>Libgcrypt version 1.10.2</refcontent>
	</reference>	</reference>


		<!-- [rfced] Regarding [LISP], we found the following URL from the Software
		Preservation Group of the Computer History Museum that provides an
		open-access to this reference:
		https://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers
		%20Manual.pdf.

		Would you like to include this URL with the reference?

		Original:
		[LISP] Levin, M. and J. McCarthy, "LISP 1.5 Programmer's Manual",
		ISBN-13 978-0-262-12011-0, ISBN-10 0262130114, 15 August
		1962.
		-->

	<reference anchor="LISP">	<reference anchor="LISP">
	<front>	<front>
	<title>LISP 1.5 Programmer's Manual</title>	<title>LISP 1.5 Programmer's Manual</title>

		<author surname="McCarthy" initials="J."
		fullname="John McCarthy"/>
		<author fullname="Paul W. Abrahams"/>
		<author fullname="Daniel J. Edwards"/>
		<author fullname="Timothy P. Hart"/>
	<author surname="Levin" initials="M."	<author surname="Levin" initials="M."
	fullname="Michael I. Levin">	fullname="Michael I. Levin">
	<organization>The Computer Center and Research Laboratory of	<organization>The Computer Center and Research Laboratory of
	Electronics, Massachusetts Institute of	Electronics, Massachusetts Institute of
	Technology</organization>	Technology</organization>
	</author>	</author>

	<author surname="McCarthy" initials="J."
	fullname="John McCarthy"/>
	<date year="1962" month="August" day="15"/>	<date year="1962" month="August" day="15"/>
	</front>	</front>
	<seriesInfo name="ISBN-13" value="978-0-262-12011-0"/>	<seriesInfo name="ISBN-13" value="978-0-262-12011-0"/>
	<seriesInfo name="ISBN-10" value="0262130114"/>	<seriesInfo name="ISBN-10" value="0262130114"/>
	</reference>	</reference>

	<reference anchor="LISP2"	<reference anchor="LISP2"
	target="https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/PL/LISP. pdf">	target="https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/PL/LISP. pdf">
	<front>	<front>
	<title>Recursive Functions of Symbolic Expressions and Their	<title>Recursive Functions of Symbolic Expressions and Their

	skipping to change at line 1318 ¶	skipping to change at line 1452 ¶
	<author surname="McCarthy" initials="J."	<author surname="McCarthy" initials="J."
	fullname="John McCarthy">	fullname="John McCarthy">
	<organization>Massachusetts Institute of	<organization>Massachusetts Institute of
	Technology</organization>	Technology</organization>
	</author>	</author>
	<date year="1960" month="April"/>	<date year="1960" month="April"/>
	</front>	</front>
	</reference>	</reference>

	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2046.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2130.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2130.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2692.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2692.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2693.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2693.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3259.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3259.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3275.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3275.xml"/>

		<!-- [rfced] FYI, RFC 7259 (which was cited once in the original) has been
		obsoleted by RFC 8259, so we updated the informative reference accordingly.
		Please let us know if you prefer otherwise.

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

		Current:
		For implementors of new applications and protocols other technologies
		also worthy of consideration include the following: XML [XML], CBOR
		[RFC8949], and JSON [RFC8259].
		-->

	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7159.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
	<xi:include	<xi:include

	href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8949.xml"/>	href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>

	<reference anchor="Ribose"	<reference anchor="Ribose"
	target="https://open.ribose.com/">	target="https://open.ribose.com/">
	<front>	<front>
	<title>Open-source projects for developers and designers</title>	<title>Open-source projects for developers and designers</title>
	<author>	<author>
	<organization>Ribose Group Inc.</organization>	<organization>Ribose Group Inc.</organization>
	</author>	</author>

	<date year="2023" month="April" day="13"/>
	</front>	</front>
	</reference>	</reference>


		<!-- [rfced] FYI, for these 2 references, we were unable to confirm
		the dates provided in the original I-D, so we have updated to the
		dates as follows. Please let us know if you prefer otherwise.

		[RNPGP_SEXPP] updated to the most recent commit. (Note that
		the version has been updated from Version 0.8.7 to Version 0.9.2.)

		[SEXPP] updated to the most recent commit.

		Current:
		[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>.

		[SEXPP] "SexpProcessor", commit a90f90f, 11 April 2025,
		<https://github.com/seattlerb/sexp_processor>.
		-->

	<reference anchor="RNPGP_SEXPP"	<reference anchor="RNPGP_SEXPP"
	target="https://github.com/rnpgp/sexpp">	target="https://github.com/rnpgp/sexpp">
	<front>	<front>
	<title>S-Expressions parser and generator library in C++ (SEXP in	<title>S-Expressions parser and generator library in C++ (SEXP in
	C++)</title>	C++)</title>

	<author surname="Ribose"	<author/>
	fullname="Ribose RNP"/>	<date year="2025" month="March" day="22"/>
	<date year="2023" month="6" day="28"/>
	</front>	</front>

	<seriesInfo name="version" value="0.8.7"/>	<refcontent>Version 0.9.2, commit 249c6e3</refcontent>
	</reference>	</reference>

	<reference anchor="SDSI"	<reference anchor="SDSI"
	target="https://people.csail.mit.edu/rivest/pubs/RL96.ver-1.1.html">	target="https://people.csail.mit.edu/rivest/pubs/RL96.ver-1.1.html">
	<front>	<front>
	<title>A Simple Distributed Security Architecture</title>	<title>A Simple Distributed Security Architecture</title>
	<author surname="Rivest" initials="R."	<author surname="Rivest" initials="R."
	fullname="Ronald L. Rivest"/>	fullname="Ronald L. Rivest"/>
	<author surname="Lampson" initials="B."	<author surname="Lampson" initials="B."
	fullname="Butler Lampson"/>	fullname="Butler Lampson"/>
	<date year="1996" month="October" day="2"/>	<date year="1996" month="October" day="2"/>
	</front>	</front>

	<seriesInfo name="working" value="document"/>	<refcontent>Working document for SDSI version 1.1</refcontent>
	<seriesInfo name="SDSI version" value="1.1"/>
	</reference>	</reference>

	<reference anchor="SexpCode"	<reference anchor="SexpCode"
	target="https://github.com/jpmalkiewicz/rivest-sexp">	target="https://github.com/jpmalkiewicz/rivest-sexp">
	<front>	<front>
	<title>SEXP---(S-expressions)</title>	<title>SEXP---(S-expressions)</title>

	<author surname="Malkiewicz" initials="J."	<author/>
	fullname="J. P. Malkiewicz"/>
	<date year="2015" month="6" day="10"/>	<date year="2015" month="6" day="10"/>
	</front>	</front>

		<refcontent>commit 4aa7c36</refcontent>
	</reference>	</reference>

	<reference anchor="SEXPP"	<reference anchor="SEXPP"
	target="https://github.com/seattlerb/sexp_processor">	target="https://github.com/seattlerb/sexp_processor">
	<front>	<front>
	<title>SexpProcessor</title>	<title>SexpProcessor</title>

	<author surname="Davis" initials="R."	<author/>
	fullname="Ryan "zenspider" Davis"/>	<date year="2025" month="April" day="11"/>
	<date year="2015" month="6" day="10"/>
	</front>	</front>

		<refcontent>commit a90f90f</refcontent>
	</reference>	</reference>

	<reference anchor="SFEXP"	<reference anchor="SFEXP"
	target="https://github.com/mjsottile/sfsexp">	target="https://github.com/mjsottile/sfsexp">
	<front>	<front>
	<title>Small Fast X-Expression Library</title>	<title>Small Fast X-Expression Library</title>

	<author surname="Sottile" initials="M."	<author/>
	fullname="Matthew Sottile"/>
	<date year="2023" month="3" day="24"/>	<date year="2023" month="3" day="24"/>
	</front>	</front>

		<refcontent>commit b7d3bea</refcontent>
	</reference>	</reference>

	<reference anchor="SPKI"	<reference anchor="SPKI"
	target="https://people.csail.mit.edu/rivest/pubs/RL96.slides-maryland.pdf">	target="https://people.csail.mit.edu/rivest/pubs/RL96.slides-maryland.pdf">
	<front>	<front>
	<title>SPKI/SDSI 2.0 A Simple Distributed Security	<title>SPKI/SDSI 2.0 A Simple Distributed Security
	Infrastructure</title>	Infrastructure</title>
	<author surname="Rivest" initials="R."	<author surname="Rivest" initials="R."
	fullname="Ronald L. Rivest">	fullname="Ronald L. Rivest">
	<organization>MIT Lab for Computer Science</organization>	<organization>MIT Lab for Computer Science</organization>
	</author>	</author>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="XML"	<reference anchor="XML"

	target="https://www.w3.org/TR/REC-xml/">	target="https://www.w3.org/TR/2008/REC-xml-20081126/">
	<front>	<front>
	<title>Extensible Markup Language (XML) 1.0</title>	<title>Extensible Markup Language (XML) 1.0</title>
	<author surname="Bray" initials="T."	<author surname="Bray" initials="T."
	fullname="Tim Bray">	fullname="Tim Bray">
	<organization>Textuality and Netscape</organization>	<organization>Textuality and Netscape</organization>
	</author>	</author>
	<author surname="Paoli" initials="J."	<author surname="Paoli" initials="J."
	fullname="Jean Paoli">	fullname="Jean Paoli">
	<organization>Microsoft</organization>	<organization>Microsoft</organization>
	</author>	</author>

	skipping to change at line 1437 ¶	skipping to change at line 1603 ¶
	<organization>W3C</organization>	<organization>W3C</organization>
	</author>	</author>
	<author surname="Maler" initials="E."	<author surname="Maler" initials="E."
	fullname="Eve Maler">	fullname="Eve Maler">
	<organization>Sun Microsystems</organization>	<organization>Sun Microsystems</organization>
	</author>	</author>
	<author surname="Yergeau" initials="F."	<author surname="Yergeau" initials="F."
	fullname="François Yergeau"/>	fullname="François Yergeau"/>
	<date year="2008" month="11" day="26"/>	<date year="2008" month="11" day="26"/>
	</front>	</front>

		<refcontent>W3C Recommendation</refcontent>
		<annotation>Latest version available at <eref target="https://www.w3.org/TR/RE
		C-xml/" brackets="angle"/>.</annotation>
	</reference>	</reference>

	</references>	</references>

		</references>


	<section anchor="Code"> <!-- Appendix A -->	<section anchor="Code">
	<name>Implementations</name>	<name>Implementations</name>

	<t>At this time there are multiple implementations, many open source,	<t>At this time there are multiple implementations, many open source,
	available that are intended to read and parse some or all of the	available that are intended to read and parse some or all of the
	various S-expression formats specified here. In particular, see the	various S-expression formats specified here. In particular, see the

	following likely incomplete list:</t>	following -- likely incomplete -- list:</t>

	<ul>	<ul>

	<li>Project GNU's <xref target="Libgcrypt"/>.</li>	<li>Project GNU's <xref target="Libgcrypt"/></li>
	<li>Ribose's RNP <xref target="RNPGP_SEXPP"/> in C++.</li>	<li>Ribose's RNP <xref target="RNPGP_SEXPP"/> in C++</li>
	<li>Github project of J. P. Malkiewicz <xref	<li>Github project of J. P. Malkiewicz <xref

	target="SexpCode"/> in C.</li>	target="SexpCode"/> in C</li>
	<li>The Inferno implementation <xref target="Inferno"/>.</li>	<li>The Inferno implementation <xref target="Inferno"/></li>
	<li>Small Fast X-Expression Library <xref target="SFEXP"/>.</li>	<li>Small Fast X-Expression Library <xref target="SFEXP"/></li>
	<li>S-expression Processor <xref target="SEXPP"/> in Ruby.</li>	<li>S-expression Processor <xref target="SEXPP"/> in Ruby</li>
	<li>Canonical S-expressions <xref target="CANON"/> (OCAML).</li>	<li>Canonical S-expressions <xref target="CANON2"/> (OCAML)</li>
	</ul>	</ul>


	</section> <!-- Appendix A -->	</section>

	<section> <!-- Appendix B -->
	<name>Change History</name>

	<t>RFC Editor Note: Please delete this section before publication.</t>

	<section>
	<name>-00 Changes</name>

	<t>This sub-section summarizes significant changes between the
	original 1997 -00 version of this document and the 2023 -00 version
	submitted to the IETF.</t>

	<ol>
	<li>Convert to XML v3.</li>

	<li>Update Ron Rivest author information and, with his permission,
	add Donald Eastlake as an author.</li>

	<li>Add minimal "IANA Considerations" and "Security
	Considerations" sections.</li>

	<li>Since implementation requirements terminology is used, add the
	usual paragraph about it as a sub-section of Section 1 and add
	references to <xref target="RFC2119"/> and <xref
	target="RFC8174"/>.</li>

	<li>Divide references into Normative and Informational and update
	base-64 reference to be to <xref target="RFC4648"/>.</li>

	<li>Add a couple of sentences to the "Historical note" section about
	the history of -00 versions of the draft.</li>
	</ol>

	</section> <!-- -00 -->

	<section>
	<name>Changes from -00 to -01</name>

	<ol>
	<li>Fix glitches and errors in the BNF.</li>

	<li>Add Acknowledgements section to list Marc Petit-Huguenin (who
	provided BNF improvements) and John Klensin.</li>

	<li>Update code references in <xref target="Code"/> and add to
	Informative References section. Note: The code
	in the Malkiewicz github repository may be the code that was
	originally at http://theory.lcs.mit.edu/~rivest/sexp.html </li>

	<li>Add this Change History Appendix.</li>

	<li>Move "Historical Notes" which were formerly a separate section
	at the end of the document up to be a sub-section of Section 1.</li>

	<li>Add references to <xref target="LISP"/>, <xref
	target="RFC2692"/>, and <xref target="RFC2693"/>.</li>

	<li>Add simple security considerations.</li>

	<li>Minor editorial fixes/improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -01 to -02</name>

	<ol>
	<li>Change default MIME Type in <xref target="DisplayHint"/> to have
	charset=utf-8 <xref target="RFC4648"/>.</li>
	<li>Change BNF to ABNF and add reference to <xref
	target="RFC5234"/>.</li>
	<li>Move Marc Petit-Huguenin to a Contributors section for his work
	on the ABNF.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -02 to -03</name>

	<ol>
	<li>Add current S-expression usage Section 1.2.</li>
	<li>Add the white book <xref target="C"/> as a reference.</li>
	<li>Add reference to the Ribose RNP code <xref
	target="RNPGP_SEXPP"/>.</li>
	<li>Minor editorial improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -03 to -04</name>

	<t>Trivial keep-alive update.</t>

	</section>

	<section>
	<name>Changes from -04 to -05</name>

	<ol>
	<li>Add reference to <xref target="Inferno"/> implementation.</li>
	<li>Eliminate remaining references to being a "proposal".</li>
	<li>Emphasize that a particular application can specify a different
	default display-hint.</li>
	<li>Add reference to <xref target="RFC0020"/> for ASCII.</li>
	<li>Minor editorial improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -05 to -06</name>

	<ol>
	<li>Move implementations list to Appendix A. Add numerous
	implementations.</li>
	<li>Change default display-hint to "application/octet-stream".</li>
	<li>Expand Abstract and include most of Abstract in the
	Introduction.</li>
	<li>Use different tokens for the top-level rule in the three ABNF
	encodings so that the rules would not collide if all were used. Fix
	ABNF for "printable".</li>
	<li>Add an illustration of list-structure memory
	representation.</li>
	<li>Editorial improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -06 to -07</name>

	<ol>
	<li>Re-order some top-level sections.</li>
	<li>Replace "list-structure" memory figure with explanation and
	<xref target="LISP2"/> reference.</li>
	<li>Re-organize ABNF to give full ABNF for advanced transport first
	and then mostly derive canonical and basic from advanced.</li>
	<li>Correct reference to <xref target="RFC5234"/> to be to Appendix
	B.1, not Appendix A.</li>
	<li>Attempt to clarify the difference between canonicalization and
	equality.</li>
	<li>Add the explicit <xref target="base64sexp"/> on base-64
	representation of S-expressions.</li>
	<li>Globally hyphenate "octet-string" and "display-hint", generally
	replace "byte" with "octet".</li>
	<li>Add some more examples here and there.</li>
	<li>Fix typos. Other editorial improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -07 to -08</name>

	<ol>
	<li>A variety of minor fixes and more precise wording.</li>
	<li>Give exact circumstances under which a space is needed to
	separate successive octet-string representations in a list.</li>
	<li>Additional editorial improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -08 to -09</name>

	<ol>
	<li>Add mention of and reference to <xref target="formal"/>.</li>
	<li>Add mention in the text that whitespace can appear just after
	the opening curly brace and before just before the closing curly
	brace of base-64 encoding (the ABNF was correct).</li>
	<li>Minor editorial improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -09 to -10</name>

	<ol>
	<li>Revert default display hint to more closely follow the original
	SPKI S-expressions.</li>
	<li>Editorial improvements.</li>
	</ol>

	</section>

	<section>
	<name>Changes from -10 to -12</name>

	<t>Minor ABNF fixes and editorial changes.</t>

	</section>

	<section>
	<name>Changes from -12 to -13</name>

	<t>Added recommendation and references for using UTF-8 to support
	Interntionalization for text octet-strings. Minor other updates
	based on IESG reviews.</t>

	</section>

	</section> <!-- Appendix B -->

	<section anchor="Acknowledgements" numbered="false">	<section anchor="Acknowledgements" numbered="false">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>


	<t>Special thanks to Daniel K. Gillmore for his extensive	<t>Special thanks to <contact fullname="Daniel K. Gillmore"/> for his extensiv e
	comments.</t>	comments.</t>

	<t>The comments and suggestions of the following are gratefully	<t>The comments and suggestions of the following are gratefully

	acknowledged: John Klensin and Caleb Malchik.</t>	acknowledged: <contact fullname="John Klensin"/> and <contact fullname="Caleb Malchik"/>.</t>

	</section>	</section>

	<section anchor="Contributors" numbered="false">	<section anchor="Contributors" numbered="false">
	<name>Contributors</name>	<name>Contributors</name>


	<t>Special thanks to Marc Petit-Huguenin, particularly for his	<t>Special thanks to <contact fullname="Marc Petit-Huguenin"/>, particularly f or his
	extensive work and advice on the ABNF and on locating and fixing	extensive work and advice on the ABNF and on locating and fixing

	unclear parts of earlier versions of this document:</t>	unclear parts of earlier draft versions of this document:</t>

	<contact fullname="Marc Petit-Huguenin" initials="M."	<contact fullname="Marc Petit-Huguenin" initials="M."
	surname="Petit-Huguenin">	surname="Petit-Huguenin">
	<organization>Impedance Mismatch LLC</organization>	<organization>Impedance Mismatch LLC</organization>
	<address>	<address>
	<email>marc@petit-huguenin.org</email>	<email>marc@petit-huguenin.org</email>
	</address>	</address>
	</contact>	</contact>
	</section>	</section>

	</back>	</back>


		<!-- [rfced] FYI, this term was capitalized inconsistently. We changed
		the 3 instances of "S-Expressions" (in running text in Sections
		1.1, 1.2, and 4.6) to the lowercased form, based on usage in the rest
		of the document. Please let us know if you prefer otherwise.

		S-expressions vs. S-Expressions
		-->

		<!-- [rfced] The following terms appear to be consistently hyphenated in
		this document, but in most RFCs, they are not hyphenated. Would you like to
		add a note to the beginning of the document about the reasoning as to why
		the hyphen is used in this document? Or would you like to update to no hyphen
		throughout? Please let us know any updates.

		byte-strings
		display-hint
		octet-strings
		simple-string

		Re: capitalization, should these terms always be lowercase?
		If so, we will lowercase them in the section titles, even
		when they appear at the start of the section title. Two examples:

		Original:
		4. Octet-string representation types

		Current [title case]:
		4. Octet-String Representation Types

		Perhaps:
		4. octet-string Representation Types

		Original: 9.2.2. Octet-string with display-hint
		Current: 9.2.2. Octet-String with Display-Hint
		Perhaps: 9.2.2. octet-string with display-hint
		-->

		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.

		Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice.
		-->

	</rfc>	</rfc>

End of changes. 248 change blocks.
	592 lines changed or deleted	619 lines changed or added
This html diff was produced by rfcdiff 1.48.