rfc9285.original		rfc9285.txt
	Network Working Group P. Faltstrom		Internet Engineering Task Force (IETF) P. Fältström
	Internet-Draft Netnod		Request for Comments: 9285 Netnod
	Intended status: Informational F. Ljunggren		Category: Informational F. Ljunggren
	Expires: December 18, 2022 Kirei		ISSN: 2070-1721 Kirei
	D. van Gulik		D.W. van Gulik
	Webweaving		Webweaving
	June 16, 2022		August 2022
	The Base45 Data Encoding		The Base45 Data Encoding
	draft-faltstrom-base45-12
	Abstract		Abstract
	This document describes the Base45 encoding scheme which is built		This document describes the Base45 encoding scheme, which is built
	upon the Base64, Base32 and Base16 encoding schemes.		upon the Base64, Base32, and Base16 encoding schemes.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are candidates for any level of Internet
			Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on December 18, 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9285.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Revised BSD License text as described in Section 4.e of the
	the Trust Legal Provisions and are provided without warranty as		Trust Legal Provisions and are provided without warranty as described
	described in the Simplified BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Conventions Used in This Document . . . . . . . . . . . . . . 2		2. Conventions Used in This Document
	3. Interpretation of Encoded Data . . . . . . . . . . . . . . . 2		3. Interpretation of Encoded Data
	4. The Base45 Encoding . . . . . . . . . . . . . . . . . . . . . 3		4. The Base45 Encoding
	4.1. When to, and not to, use Base45 . . . . . . . . . . . . . 4		4.1. When to Use and Not Use Base45
	4.2. The alphabet used in Base45 . . . . . . . . . . . . . . . 4		4.2. The Alphabet Used in Base45
	4.3. Encoding examples . . . . . . . . . . . . . . . . . . . . 4		4.3. Encoding Examples
	4.4. Decoding examples . . . . . . . . . . . . . . . . . . . . 5		4.4. Decoding Example
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Normative References
	8. Normative References . . . . . . . . . . . . . . . . . . . . 6		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses
	1. Introduction		1. Introduction
	A QR-code is used to encode text as a graphical image. Depending on		A QR code is used to encode text as a graphical image. Depending on
	the characters used in the text various encoding options for a QR-		the characters used in the text, various encoding options for a QR
	code exist, e.g. Numeric, Alphanumeric and Byte mode. Even in Byte		code exist, e.g., Numeric, Alphanumeric, and Byte mode. Even in Byte
	mode a typical QR-code reader tries to interpret a byte sequence as a		mode, a typical QR code reader tries to interpret a byte sequence as
	UTF-8 or ISO/IEC 8859-1 encoded text. Thus, QR-codes cannot be used		text encoded in UTF-8 or ISO/IEC 8859-1. Thus, QR codes cannot be
	to encode arbitrary binary data directly. Such data has to be		used to encode arbitrary binary data directly. Such data has to be
	converted into an appropriate text before that text could be encoded		converted into an appropriate text before that text could be encoded
	as a QR-code. Compared to already established Base64, Base32 and		as a QR code. Compared to already established Base64, Base32, and
	Base16 encoding schemes, that are described in RFC 4648 [RFC4648],		Base16 encoding schemes that are described in [RFC4648], the Base45
	the Base45 scheme described in this document offer a more compact QR-		scheme described in this document offers a more compact QR code
	code encoding.		encoding.
	One important difference from those others and Base45 is the key		One important difference from those others and Base45 is the key
	table and that the padding with '=' is not required.		table and that the padding with '=' is not required.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Interpretation of Encoded Data		3. Interpretation of Encoded Data
	Encoded data is to be interpreted as described in RFC 4648 [RFC4648]		Encoded data is to be interpreted as described in [RFC4648] with the
	with the exception that a different alphabet is selected.		exception that a different alphabet is selected.
	4. The Base45 Encoding		4. The Base45 Encoding
	QR codes have a limited ability to store binary data. In practice		QR codes have a limited ability to store binary data. In practice,
	binary data have to be encoded in characters according to one of the		binary data have to be encoded in characters according to one of the
	modes already defined in the standard for QR codes. The easiest mode		modes already defined in the standard for QR codes. The easiest mode
	to use in called Alphanumeric mode (see section 7.3.4 and Table 2 of		to use in called Alphanumeric mode (see Section 7.3.4 and Table 2 of
	ISO/IEC 18004:2015 [ISO18004]). Unfortunately Alphanumeric mode uses		[ISO18004]. Unfortunately Alphanumeric mode uses 45 different
	45 different characters which implies neither Base32 nor Base64 are		characters which implies neither Base32 nor Base64 are very effective
	very effective encodings.		encodings.
	A 45-character subset of US-ASCII is used; the 45 characters usable		A 45-character subset of US-ASCII is used; the 45 characters usable
	in a QR code in Alphanumeric mode (see section 7.3.4 and Table 2 of		in a QR code in Alphanumeric mode (see Section 7.3.4 and Table 2 of
	ISO/IEC 18004:2015 [ISO18004]). Base45 encodes 2 bytes in 3		[ISO18004]). Base45 encodes 2 bytes in 3 characters, compared to
	characters, compared to Base64, which encodes 3 bytes in 4		Base64, which encodes 3 bytes in 4 characters.
	characters.
	For encoding, two bytes [a, b] MUST be interpreted as a number n in		For encoding, two bytes [a, b] MUST be interpreted as a number n in
	base 256, i.e. as an unsigned integer over 16 bits so that the number		base 256, i.e. as an unsigned integer over 16 bits so that the number
	n = (a*256) + b.		n = (a * 256) + b.
	This number n is converted to base 45 [c, d, e] so that n = c +		This number n is converted to base 45 [c, d, e] so that n = c + (d *
	(d*45) + (e*45*45). Note the order of c, d and e which are chosen so		45) + (e * 45 * 45). Note the order of c, d and e which are chosen
	that the left-most [c] is the least significant.		so that the left-most [c] is the least significant.
	The values c, d and e are then looked up in Table 1 to produce a		The values c, d and e are then looked up in Table 1 to produce a
	three character string. The process is reversed when decoding.		three character string. The process is reversed when decoding.
	For encoding a single byte [a], it MUST be interpreted as a base 256		For encoding a single byte [a], it MUST be interpreted as a base 256
	number, i.e. as an unsigned integer over 8 bits. That integer MUST		number, i.e. as an unsigned integer over 8 bits. That integer MUST
	be converted to base 45 [c d] so that a = c + (45*d). The values c		be converted to base 45 [c d] so that a = c + (45 * d). The values c
	and d are then looked up in Table 1 to produce a two character		and d are then looked up in Table 1 to produce a two-character
	string.		string.
	A byte string [a b c d ... x y z] with arbitrary content and		A byte string [a b c d ... x y z] with arbitrary content and
	arbitrary length MUST be encoded as follows: From left to right pairs		arbitrary length MUST be encoded as follows: From left to right pairs
	of bytes MUST be encoded as described above. If the number of bytes		of bytes MUST be encoded as described above. If the number of bytes
	is even, then the encoded form is a string with a length which is		is even, then the encoded form is a string with a length that is
	evenly divisible by 3. If the number of bytes is odd, then the last		evenly divisible by 3. If the number of bytes is odd, then the last
	(rightmost) byte MUST be encoded on two characters as described		(rightmost) byte MUST be encoded on two characters as described
	above.		above.
	For decoding a Base45 encoded string the inverse operations are		For decoding a Base45 encoded string the inverse operations are
	performed.		performed.
	4.1. When to, and not to, use Base45		4.1. When to Use and Not Use Base45
	If binary data is to be stored in a QR-Code, the suggested mechanism		If binary data is to be stored in a QR code, the suggested mechanism
	is to use the Alphanumeric mode that uses 11 bits for 2 characters as		is to use the Alphanumeric mode that uses 11 bits for 2 characters as
	defined in section 7.3.4 in ISO/IEC 18004:2015 [ISO18004]. The ECI		defined in Section 7.3.4 of [ISO18004]. The Extended Channel
	mode indicator for this encoding is 0010.		Interpretation (ECI) mode indicator for this encoding is 0010.
	On the other hand if the data is to be sent via some other transport,		On the other hand if the data is to be sent via some other transport,
	a transport encoding suitable for that transport should be used		a transport encoding suitable for that transport should be used
	instead of Base45. For example, it is not recommended to first		instead of Base45. For example, it is not recommended to first
	encode data in Base45 and then encode the resulting string in Base64		encode data in Base45 and then encode the resulting string in Base64
	if the data is to be sent via email. Instead, the Base45 encoding		if the data is to be sent via email. Instead, the Base45 encoding
	should be removed, and the data itself should be encoded in Base64.		should be removed, and the data itself should be encoded in Base64.
	4.2. The alphabet used in Base45		4.2. The Alphabet Used in Base45
	The Alphanumeric mode is defined to use 45 characters as specified in		The Alphanumeric mode is defined to use 45 characters as specified in
	this alphabet.		this alphabet.
	Table 1: The Base45 Alphabet		+=====+==========+=====+==========+=====+==========+=====+==========+
			|Value| Encoding |Value| Encoding |Value| Encoding |Value| Encoding |
			+=====+==========+=====+==========+=====+==========+=====+==========+
			| 00| 0 | 12| C | 24| O | 36| Space |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 01| 1 | 13| D | 25| P | 37| $ |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 02| 2 | 14| E | 26| Q | 38| % |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 03| 3 | 15| F | 27| R | 39| * |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 04| 4 | 16| G | 28| S | 40| + |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 05| 5 | 17| H | 29| T | 41| - |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 06| 6 | 18| I | 30| U | 42| . |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 07| 7 | 19| J | 31| V | 43| / |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 08| 8 | 20| K | 32| W | 44| : |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 09| 9 | 21| L | 33| X | | |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 10| A | 22| M | 34| Y | | |
			+-----+----------+-----+----------+-----+----------+-----+----------+
			| 11| B | 23| N | 35| Z | | |
			+-----+----------+-----+----------+-----+----------+-----+----------+
	Value Encoding Value Encoding Value Encoding Value Encoding		Table 1: The Base45 Alphabet
	00 0 12 C 24 O 36 Space
	01 1 13 D 25 P 37 $
	02 2 14 E 26 Q 38 %
	03 3 15 F 27 R 39 *
	04 4 16 G 28 S 40 +
	05 5 17 H 29 T 41 -
	06 6 18 I 30 U 42 .
	07 7 19 J 31 V 43 /
	08 8 20 K 32 W 44 :
	09 9 21 L 33 X
	10 A 22 M 34 Y
	11 B 23 N 35 Z
	4.3. Encoding examples		4.3. Encoding Examples
	It should be noted that although the examples are all text, Base45 is		It should be noted that although the examples are all text, Base45 is
	an encoding for binary data where each octet can have any value		an encoding for binary data where each octet can have any value
	0-255.		0-255.
	Encoding example 1: The string "AB" is the byte sequence [65 66].		Encoding example 1:
	The 16 bit value is 65 * 256 + 66 = 16706. 16706 equals 11 + 45 * 11
	+ 45 * 45 * 8, so the sequence in base 45 is [11 11 8]. By looking
	up these values in the Table 1 we get the encoded string "BB8".
	Encoding example 2: The string "Hello!!" as ASCII is the byte		The string "AB" is the byte sequence [[65 66]]. If we look at all
	sequence [72 101 108 108 111 33 33]. If we look at each 16 bit		16 bits, we get 65 * 256 + 66 = 16706. 16706 equals 11 + (11 *
	value, it is [18533 27756 28449 33]. Note the 33 for the last byte.		45) + (8 * 45 * 45), so the sequence in base 45 is [11 11 8].
	When looking at the values in base 45, we get [[38 6 9] [36 31 13] [9		Referring to Table 1, we get the encoded string "BB8".
	2 14] [33 0]] where the last byte is represented by two. The
	resulting string "%69 VD92EX0" is created by looking up these values
	in Table 1. It should be noted it includes a space.
	Encoding example 3: The string "base-45" as ASCII is the byte		+-----------+------------------+
	sequence [98 97 115 101 45 52 53]. If we look at each 16 bit value,		| AB | Initial string |
	it is [25185 29541 11572 53]. Note the 53 for the last byte. When		+-----------+------------------+
	looking at the values in base 45, we get [[30 19 12] [21 26 14] [7 32		| [[65 66]] | Decimal value |
	5] [8 1]] where the last byte is represented by two. By looking up		+-----------+------------------+
	these values in the Table 1 we get the encoded string "UJCLQE7W581".		| [16706] | Value in base 16 |
			+-----------+------------------+
			| [11 11 8] | Value in base 45 |
			+-----------+------------------+
			| BB8 | Encoded string |
			+-----------+------------------+
	4.4. Decoding examples		Table 2: Example 1 in Detail
	Decoding example 1: The string "QED8WEX0" represents, when looked up		Encoding example 2:
	in Table 1, the values [26 14 13 8 32 14 33 0]. We arrange the
	numbers in chunks of three, except for the last one which can be two,		The string "Hello!!" as ASCII is the byte sequence [[72 101] [108
	and get [[26 14 13] [8 32 14] [33 0]]. In base 45 we get [26981		108] [111 33] [33]]. If we look at this 16 bits at a time, we get
	29798 33] where the bytes are [[105 101] [116 102] [33]]. If we look		[18533 27756 28449 33]. Note the 33 for the last byte. When
	at the ASCII values we get the string "ietf!".		looking at the values in base 45, we get [[38 6 9] [36 31 13] [9 2
			14] [33 0]], where the last byte is represented by two values.
			The resulting string "%69 VD92EX0" is created by looking up these
			values in Table 1. It should be noted it includes a space.
			+---------------------------------------+------------------+
			| Hello!! | Initial string |
			+---------------------------------------+------------------+
			| [[72 101] [108 108] [111 33] [33]] | Decimal value |
			+---------------------------------------+------------------+
			| [18533 27756 28449 33] | Value in base 16 |
			+---------------------------------------+------------------+
			| [[38 6 9] [36 31 13] [9 2 14] [33 0]] | Value in base 45 |
			+---------------------------------------+------------------+
			| %69 VD92EX0 | Encoded string |
			+---------------------------------------+------------------+
			Table 3: Example 2 in Detail
			Encoding example 3:
			The string "base-45" as ASCII is the byte sequence [[98 97] [115
			101] [45 52] [53]]. If we look at this two bytes at a time, we
			get [25185 29541 11572 53]. Note the 53 for the last byte. When
			looking at the values in base 45, we get [[30 19 12] [21 26 14] [7
			32 5] [8 1]] where the last byte is represented by two values.
			Referring to Table 1, we get the encoded string "UJCLQE7W581".
			+----------------------------------------+------------------+
			| base-45 | Initial string |
			+----------------------------------------+------------------+
			| [[98 97] [115 101] [45 52] [53]] | Decimal value |
			+----------------------------------------+------------------+
			| [25185 29541 11572 53] | Value in base 16 |
			+----------------------------------------+------------------+
			| [[30 19 12] [21 26 14] [7 32 5] [8 1]] | Value in base 45 |
			+----------------------------------------+------------------+
			| UJCLQE7W581 | Encoded string |
			+----------------------------------------+------------------+
			Table 4: Example 3 in Detail
			4.4. Decoding Example
			Decoding example 1:
			The string "QED8WEX0" represents, when looked up in Table 1, the
			values [26 14 13 8 32 14 33 0]. We arrange the numbers in chunks
			of three, except for the last one which can be two numbers, and
			get [[26 14 13] [8 32 14] [33 0]]. In base 45, we get [26981
			29798 33] where the bytes are [[105 101] [116 102] [33]]. If we
			look at the ASCII values, we get the string "ietf!".
			+-------------------------------+------------------------+
			| QED8WEX0 | Initial string |
			+-------------------------------+------------------------+
			| [26 14 13 8 32 14 33 0] | Looked up values |
			+-------------------------------+------------------------+
			| [[26 14 13] [8 32 14] [33 0]] | Groups of three |
			+-------------------------------+------------------------+
			| [26981 29798 33] | Interpreted as base 45 |
			+-------------------------------+------------------------+
			| [[105 101] [116 102] [33]] | Values in base 8 |
			+-------------------------------+------------------------+
			| ietf! | Decoded string |
			+-------------------------------+------------------------+
			Table 5: Example 4 in Detail
	5. IANA Considerations		5. IANA Considerations
	There are no considerations for IANA in this document.		This document has no IANA actions.
	6. Security Considerations		6. Security Considerations
	When implementing encoding and decoding it is important to be very		When implementing encoding and decoding it is important to be very
	careful so that buffer overflow or similar does not occur. This of		careful so that buffer overflow or similar issues do not occur. This
	course includes the calculations in base 45 and lookup in the table		of course includes the calculations in base 45 and lookup in the
	of characters (Table 1). A decoder must also be robust regarding		table of characters (Table 1). A decoder must also be robust
	input, including proper handling of any octet value 0-255, including		regarding input, including proper handling of any octet value 0-255,
	the NUL character (ASCII 0).		including the NUL character (ASCII 0).
	It should be noted that Base64 and some other encodings pad the		It should be noted that Base64 and some other encodings pad the
	string so that the encoding starts with an aligned number of		string so that the encoding starts with an aligned number of
	characters while Base45 specifically avoids padding. Because of		characters while Base45 specifically avoids padding. Because of
	this, special care has to be taken when odd number of octets are to		this, special care has to be taken when an odd number of octets is to
	be encoded. Similarly, care must be taken if the number of		be encoded. Similarly, care must be taken if the number of
	characters to decode are not evenly divisible by 3.		characters to decode are not evenly divisible by 3.
	Base encodings use a specific, reduced alphabet to encode binary		Base encodings use a specific, reduced alphabet to encode binary
	data. Non-alphabet characters could exist within base-encoded data,		data. Non-alphabet characters could exist within base-encoded data,
	caused by data corruption or by design. Non-alphabet characters may		caused by data corruption or by design. Non-alphabet characters may
	be exploited as a "covert channel", where non-protocol data can be		be exploited as a "covert channel", where non-protocol data can be
	sent for nefarious purposes. Non-alphabet characters might also be		sent for nefarious purposes. Non-alphabet characters might also be
	sent in order to exploit implementation errors leading to, e.g.,		sent in order to exploit implementation errors leading to, for
	buffer overflow attacks.		example, buffer overflow attacks.
	Implementations MUST reject any input that is not a valid encoding.		Implementations MUST reject any input that is not a valid encoding.
	For example, it MUST reject the input (encoded data) if it contains		For example, it MUST reject the input (encoded data) if it contains
	characters outside the base alphabet (in Table 1) when interpreting		characters outside the base alphabet (in Table 1) when interpreting
	base-encoded data.		base-encoded data.
	Even though a Base45 encoded string contains only characters from the		Even though a Base45-encoded string contains only characters from the
	alphabet in Table 1, cases like the following has to be considered:		alphabet in Table 1, cases like the following have to be considered:
	The string "FGW" represents 65535 (FFFF in base 16), which is a valid		The string "FGW" represents 65535 (FFFF in base 16), which is a valid
	encoding of 16 bits. A slightly different encoded string of the same		encoding of 16 bits. A slightly different encoded string of the same
	length, "GGW", would represent 65536 (10000 in base 16), which is		length, "GGW", would represent 65536 (10000 in base 16), which is
	represented by more than 16 bits. Implementations MUST also reject		represented by more than 16 bits. Implementations MUST also reject
	the encoded data if it contains a triplet of characters which, when		the encoded data if it contains a triplet of characters that, when
	decoded, results in an unsigned integer which is greater than 65535		decoded, results in an unsigned integer that is greater than 65535
	(ffff in base 16).		(FFFF in base 16).
	It should be noted that the resulting string after encoding to Base45		It should be noted that the resulting string after encoding to Base45
	might include non-URL-safe characters so if the URL including the		might include non-URL-safe characters so if the URL including the
	Base45 encoded data has to be URL safe, one has to use %-encoding.		Base45 encoded data has to be URL-safe, one has to use percent-
			encoding.
	7. Acknowledgements
	The authors thank Mark Adler, Anders Ahl, Alan Barrett, Sam Spens
	Clason, Alfred Fiedler, Tomas Harreveld, Erik Hellman, Joakim
	Jardenberg, Michael Joost, Erik Kline, Christian Landgren, Anders
	Lowinger, Mans Nilsson, Jakob Schlyter, Peter Teufl and Gaby
	Whitehead for the feedback. Also, everyone that have been working
	with Base64 over a long period of years and have proven the
	implementations are stable.
	8. Normative References		7. Normative References
	[ISO18004]		[ISO18004] ISO/IEC, "Information technology - Automatic
	ISO/IEC JTC 1/SC 31, "ISO/IEC 18004:2015 Information		identification and data capture techniques - QR Code bar
	technology - Automatic identification and data capture		code symbology specification", ISO/IEC 18004:2015,
	techniques - QR Code bar code symbology specification",		February 2015, <https://www.iso.org/standard/62021.html>.
	ISO/IEC
	18004:2015 https://www.iso.org/standard/62021.html,
	February 2015.
	[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>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			Acknowledgements
			The authors thank Mark Adler, Anders Ahl, Alan Barrett, Sam Spens
			Clason, Alfred Fiedler, Tomas Harreveld, Erik Hellman, Joakim
			Jardenberg, Michael Joost, Erik Kline, Christian Landgren, Anders
			Lowinger, Mans Nilsson, Jakob Schlyter, Peter Teufl, and Gaby
			Whitehead for the feedback. Also, everyone who has been working with
			Base64 over a long period of years and has proven the implementations
			are stable.
	Authors' Addresses		Authors' Addresses
	Patrik Faltstrom		Patrik Fältström
	Netnod		Netnod
	Email: paf@netnod.se		Email: paf@netnod.se
	Fredrik Ljunggren		Fredrik Ljunggren
	Kirei		Kirei
	Email: fredrik@kirei.se		Email: fredrik@kirei.se
	Dirk-Willem van Gulik		Dirk-Willem van Gulik
	Webweaving		Webweaving
	Email: dirkx@webweaving.org		Email: dirkx@webweaving.org
End of changes. 46 change blocks.
	148 lines changed or deleted		220 lines changed or added
This html diff was produced by rfcdiff 1.48.