rfc9804v1.txt		rfc9804.txt
	skipping to change at line 115 ¶		skipping to change at line 115 ¶
	being used elsewhere. Uses of this representation herein are		being used elsewhere. Uses of this representation herein are
	referred to as "S-expressions".		referred to as "S-expressions".
	This memo makes precise the encodings of these SPKI S-expressions: It		This memo makes precise the encodings of these SPKI S-expressions: It
	gives a "canonical form" for them, describes two "transport"		gives a "canonical form" for them, describes two "transport"
	representations, and also describes an "advanced" format for display		representations, and also describes an "advanced" format for display
	to people. There are multiple implementations of S-expressions in a		to people. There are multiple implementations of S-expressions in a
	variety of programming languages including Python, Ruby, and C (see		variety of programming languages including Python, Ruby, and C (see
	Appendix A).		Appendix A).
	These S-expressions are either byte-strings ("octet-strings") or		These S-expressions are either octet-strings or lists of simpler
	lists of simpler S-expressions. Here is a sample S-expression:		S-expressions. Here is a sample S-expression:
	(snicker "abc" (#03# |YWJj|))		(snicker "abc" (#03# |YWJj|))
	It is a list of length three containing the following:		It is a list of length three containing the following:
	* the octet-string "snicker"		* the octet-string "snicker"
	* the octet-string "abc"		* the octet-string "abc"
	* a sub-list containing two elements: The hexadecimal constant #03#		* a sub-list containing two elements: The hexadecimal constant #03#
	skipping to change at line 169 ¶		skipping to change at line 169 ¶
	[RFC8949], and JSON [RFC8259].		[RFC8949], and JSON [RFC8259].
	1.1. Uses of S-Expressions		1.1. Uses of S-Expressions
	The S-expressions specified herein are in active use today between		The S-expressions specified herein are in active use today between
	GnuPG [GnuPG] and Ribose's RNP [Ribose]. Ribose has implemented C++		GnuPG [GnuPG] and Ribose's RNP [Ribose]. Ribose has implemented C++
	software to compose and parse these S-expressions [RNPGP_SEXPP]. The		software to compose and parse these S-expressions [RNPGP_SEXPP]. The
	GNU software is the Libgcrypt library [Libgcrypt], and there are		GNU software is the Libgcrypt library [Libgcrypt], and there are
	other implementations (see Appendix A).		other implementations (see Appendix A).
	They are used or referenced in the following RFCs:		S-expressions are also used or referenced in the following RFCs:
	* [RFC2693] for [SPKI]		* [RFC2693] for [SPKI]
	* [RFC3275] XML-Signature Syntax and Processing		* [RFC3275] XML-Signature Syntax and Processing
	In addition, S-expressions are the inspiration for the encodings in		In addition, S-expressions are the inspiration for the encodings in
	other protocols. For example, [RFC3259] or Section 6 of		other protocols. For example, [RFC3259] or Section 6 of
	[CDDL-freezer].		[CDDL-freezer].
	1.2. Formalization		1.2. Formalization
	skipping to change at line 224 ¶		skipping to change at line 224 ¶
	* a finite list of simpler S-expressions.		* a finite list of simpler S-expressions.
	An octet-string is a finite sequence of eight-bit octets. An octet-		An octet-string is a finite sequence of eight-bit octets. An octet-
	string may be zero length. There may be many different but		string may be zero length. There may be many different but
	equivalent ways of representing an octet-string		equivalent ways of representing an octet-string
	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"
	The above encodings are all equivalent in that they all denote the		The above encodings are all equivalent in that they all denote the
	same octet-string. Details of these encodings are given below, and		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		how to give a "display type" to a simple-string is also described in
	Section 4.6.		Section 4.6.
	A list is a finite sequence of zero or more simpler S-expressions. A		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		list is represented by using parentheses to surround the sequence of
	encodings of its elements, as in:		encodings of its elements, as in:
	skipping to change at line 349 ¶		skipping to change at line 348 ¶
	0:		0:
	4.2. Quoted-String Representation		4.2. Quoted-String Representation
	The quoted-string representation of an octet-string consists of:		The quoted-string representation of an octet-string consists of:
	* an optional decimal length field		* an optional decimal length field
	* an initial double-quote (")		* an initial double-quote (")
	* the octet-string with the C programming language [C] escape		* the octet-string with the C programming language [C88] escape
	conventions (\n, etc.)		conventions (\n, etc.)
	* a final double-quote (")		* a final double-quote (")
	The specified length is the length of the resulting string after any		The specified length is the length of the resulting string after any
	backslash escape sequences have been converted to the octet value		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
	[C] includes, and the length does not count such an octet.		[C88] includes, and the length does not count such an octet.
	The length is optional.		The length is optional.
	The escape conventions within the quoted string are as follows (these		The escape conventions within the quoted string are as follows (these
	follow the C programming language [C] conventions, with an extension		follow the C programming language [C88] conventions, with an
	for ignoring line terminators of just CR, LF, CRLF, or LFCR and more		extension for ignoring line terminators of just CR, LF, CRLF, or LFCR
	restrictive octal and hexadecimal value formats):		and more restrictive octal and hexadecimal value formats):
	\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
	skipping to change at line 468 ¶		skipping to change at line 467 ¶
	* an (optional) decimal length of the octet-string		* an (optional) decimal length of the octet-string
	* a vertical bar "|"		* a vertical bar "|"
	* the base-64 [RFC4648] encoding of the octet-string.		* the base-64 [RFC4648] encoding of the octet-string.
	* a final vertical bar "|"		* a final vertical bar "|"
	Base-64 encoding produces four characters of output for each three		Base-64 encoding produces four characters of output for each three
	octets of input. If the length of the input divided by three leaves		octets of input. When the length of the input is divided by three:
	a remainder of one or two, it produces an output block of length four
	ending in two or one equals signs, respectively. These equals signs		* if the remainder is one, it produces an output block of length
	MUST be included on output, but input routines MAY accept inputs		four ending in two equals signs.
	where one or two equals signs are dropped.		* if the remainder is two, it produces an output block of length
			four ending in one equals sign.
			These equals signs MUST be included on output, but input routines MAY
			accept inputs where one or two equals signs are dropped.
	Whitespace inserted in the midst of the base-64 encoding is ignored.		Whitespace inserted in the midst of the base-64 encoding is ignored.
	It is an error to have characters other than whitespace and base-64		It is an error to have characters other than whitespace and base-64
	characters.		characters.
	Here are some examples of base-64 encodings:		Here are some examples of base-64 encodings:
	|YWJj| -- represents "abc"		|YWJj| -- represents "abc"
	| Y W		| Y W
	J j | -- also represents "abc"		J j | -- also represents "abc"
	skipping to change at line 504 ¶		skipping to change at line 507 ¶
	An octet-string can contain any type of data representable by a		An octet-string can contain any type of data representable by a
	finite octet-string, e.g., text, a fixed or variable-length integer,		finite octet-string, e.g., text, a fixed or variable-length integer,
	or an image. Normally, the application producing and/or consuming		or an image. Normally, the application producing and/or consuming
	S-expressions will understand their structure, the data type, and the		S-expressions will understand their structure, the data type, and the
	encoding of the octet-strings within the S-expressions used by that		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 [RFC2130] [RFC3629].		encoding is RECOMMENDED [RFC2130] [RFC3629].
	The purpose of a display-hint is to provide information on how to		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		display an octet-string to a user. It has no other function. Many
	of the MIME [RFC2046] types work here.		of the media types [RFC2046] work here.
	A display-hint is an octet-string representation surrounded by square		A display-hint is an octet-string representation surrounded by square
	brackets. There may be whitespace separating the display hint octet-		brackets. There may be whitespace separating the display hint octet-
	string from the surrounding brackets. Any of the legal octet-string		string from the surrounding brackets. Any of the legal octet-string
	representations may be used for the display-hint string, but a		representations may be used for the display-hint string, but a
	display-hint may not be applied to a display-hint string -- that is,		display-hint may not be applied to a display-hint string -- that is,
	display-hints may not be nested.		display-hints may not be nested.
	A display-hint that can be used for UTF-8-encoded text is shown in		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"		the following example where the octet-string represents "böb☺", that
	with an umlaut over the "o", followed by WHITE SMILING FACE (U+263A).		is, "bob" with an umlaut over the "o", followed by the Unicode
			[Unicode] character WHITE SMILING FACE (U+263A).
	["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA"		["text/plain; charset=utf-8"]"b\xC3\xB7b\xE2\x98\xBA"
	Every octet-string representation is either preceded by a single		Every octet-string representation is or is not preceded by a single
	display-hint or not so preceded. There may be whitespace between the		display-hint. There may be whitespace between the close square
	close square bracket and the octet-string to which the hint applies.		bracket and the octet-string to which the hint applies.
	Here are some other examples of display-hints:		Here are some other examples of display-hints:
	[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"]
	An octet-string that has no display-hint may be considered to have a		An octet-string that has no display-hint may be considered to have a
	MIME [RFC2046] type specified by the application or use. In the		media type [RFC2046] specified by the application or use. In the
	absence of such a specification, the default is as follows:		absence of such a specification, the default is as follows:
	[application/octet-stream]		[application/octet-stream]
	When an S-expression is being encoded in one of the representations		When an S-expression is being encoded in one of the representations
	described in Section 6, any display-hint present is included. If a		described in Section 6, any display-hint present is included. If a
	display-hint is the default, it is not suppressed nor is the default		display-hint is the default, it is not suppressed nor is the default
	display-hint included in the representation for an octet-string		display-hint included in the representation for an octet-string
	without a display-hint.		without a display-hint.
	skipping to change at line 918 ¶		skipping to change at line 922 ¶
	a different display-hint.		a different display-hint.
	11. IANA Considerations		11. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[C] Kernighan, B. and D. Ritchie, "The C Programming		[C88] Kernighan, B. and D. Ritchie, "The C Programming
	Language", ISBN 0-13-110370-9, 1988.		Language", ISBN 0-13-110370-9, 1988.
	[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,		[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
	RFC 20, DOI 10.17487/RFC0020, October 1969,		RFC 20, DOI 10.17487/RFC0020, October 1969,
	<https://www.rfc-editor.org/info/rfc20>.		<https://www.rfc-editor.org/info/rfc20>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at line 986 ¶		skipping to change at line 990 ¶
	<https://man.cat-v.org/inferno/6/sexprs>.		<https://man.cat-v.org/inferno/6/sexprs>.
	[Libgcrypt]		[Libgcrypt]
	GnuPG, "The Libgcrypt Library", Libgcrypt version 1.10.2,		GnuPG, "The Libgcrypt Library", Libgcrypt version 1.10.2,
	6 April 2023,		6 April 2023,
	<https://www.gnupg.org/documentation/manuals/gcrypt/>.		<https://www.gnupg.org/documentation/manuals/gcrypt/>.
	[LISP] McCarthy, J., Abrahams, P. W., Edwards, D. J., Hart, T.		[LISP] McCarthy, J., Abrahams, P. W., Edwards, D. J., Hart, T.
	P., and M. Levin, "LISP 1.5 Programmer's Manual",		P., and M. Levin, "LISP 1.5 Programmer's Manual",
	ISBN-13 978-0-262-12011-0, ISBN-10 0262130114, 15 August		ISBN-13 978-0-262-12011-0, ISBN-10 0262130114, 15 August
	1962.		1962,
			<https://www.softwarepreservation.org/projects/LISP/book/
			LISP%201.5%20Programmers%20Manual.pdf>.
	[LISP2] McCarthy, J., "Recursive Functions of Symbolic Expressions		[LISP2] McCarthy, J., "Recursive Functions of Symbolic Expressions
	and Their Computation by Machine, Part I", April 1960,		and Their Computation by Machine, Part I", April 1960,
	<https://people.cs.umass.edu/~emery/classes/cmpsci691st/		<https://people.cs.umass.edu/~emery/classes/cmpsci691st/
	readings/PL/LISP.pdf>.		readings/PL/LISP.pdf>.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	DOI 10.17487/RFC2046, November 1996,		DOI 10.17487/RFC2046, November 1996,
	<https://www.rfc-editor.org/info/rfc2046>.		<https://www.rfc-editor.org/info/rfc2046>.
	skipping to change at line 1059 ¶		skipping to change at line 1065 ¶
	<https://github.com/seattlerb/sexp_processor>.		<https://github.com/seattlerb/sexp_processor>.
	[SFEXP] "Small Fast X-Expression Library", commit b7d3bea, 24		[SFEXP] "Small Fast X-Expression Library", commit b7d3bea, 24
	March 2023, <https://github.com/mjsottile/sfsexp>.		March 2023, <https://github.com/mjsottile/sfsexp>.
	[SPKI] Rivest, R., "SPKI/SDSI 2.0 A Simple Distributed Security		[SPKI] Rivest, R., "SPKI/SDSI 2.0 A Simple Distributed Security
	Infrastructure",		Infrastructure",
	<https://people.csail.mit.edu/rivest/pubs/RL96.slides-		<https://people.csail.mit.edu/rivest/pubs/RL96.slides-
	maryland.pdf>.		maryland.pdf>.
			[Unicode] The Unicode Consortium, "The Unicode Standard",
			<https://www.unicode.org/versions/latest/>.
	[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,		[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
	and F. Yergeau, "Extensible Markup Language (XML) 1.0",		and F. Yergeau, "Extensible Markup Language (XML) 1.0",
	W3C Recommendation, 26 November 2008,		W3C Recommendation, 26 November 2008,
	<https://www.w3.org/TR/2008/REC-xml-20081126/>. Latest		<https://www.w3.org/TR/2008/REC-xml-20081126/>. Latest
	version available at <https://www.w3.org/TR/REC-xml/>.		version available at <https://www.w3.org/TR/REC-xml/>.
	Appendix A. Implementations		Appendix A. Implementations
	At this time there are multiple implementations, many open source,		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
	skipping to change at line 1088 ¶		skipping to change at line 1097 ¶
	* The Inferno implementation [Inferno]		* The Inferno implementation [Inferno]
	* Small Fast X-Expression Library [SFEXP]		* Small Fast X-Expression Library [SFEXP]
	* S-expression Processor [SEXPP] in Ruby		* S-expression Processor [SEXPP] in Ruby
	* Canonical S-expressions [CANON2] (OCAML)		* Canonical S-expressions [CANON2] (OCAML)
	Acknowledgements		Acknowledgements
	Special thanks to Daniel K. Gillmore for his extensive comments.		Special thanks to Daniel K. Gillmor for his extensive comments.
	The comments and suggestions of the following are gratefully		The comments and suggestions of the following are gratefully
	acknowledged: John Klensin and Caleb Malchik.		acknowledged: John Klensin and Caleb Malchik.
	Contributors		Contributors
	Special thanks to Marc Petit-Huguenin, particularly for his extensive		Special thanks to Marc Petit-Huguenin, particularly for his extensive
	work and advice on the ABNF and on locating and fixing unclear parts		work and advice on the ABNF and on locating and fixing unclear parts
	of earlier draft versions of this document:		of earlier draft versions of this document:
End of changes. 15 change blocks.
	25 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48.