]>

douglas@crockford.com

Cisco Systems

kydavis@cisco.com kyzer.davis@outlook.com

Independent encoding base32 This document details the formal specification of Base32 for Humans; an alternate Base32 alphabet which extends the "Handled by Humans" text found in Section 3.4 of RFC 4648. This base features an alphabet curated for expressing numbers in a form that can be conveniently and accurately transmitted between humans and computer systems.

Introduction Douglas Crockford's Base32 has been published at since the early 2000s. This Base32 variant alphabet has been widely implemented and tested across the industry as an alternative Base32 () and Base32hex (); however it does not have a standards-based document published with any standards body. Since Base32 itself was published with the IETF; it is fitting to publish this Base32 variant with the IETF as well. This document serves to provide a standards-based reference for new libraries and for future RFCs to cite. One example is its use with Universally Unique IDentifiers (UUIDs) defined in , where Base32 for Humans is a recommended alternate encoding method via . Where possible, the content of this document mirrors the text of the original webpage, with expanded commentary and clarification where required, such as new encoding and decoding test vectors and comparisons to newer BaseXX alphabets.

Goals The goals of this Base32 alphabet are as follows: Be human readable and machine readable. Be compact: Humans have difficulty in manipulating long strings of arbitrary symbols. Be error resistant: Entering the symbols must not require keyboarding gymnastics. Be pronounceable: Humans should be able to accurately transmit the symbols to other humans using a telephone.

Comparing Existing Alphabets When examining other BaseXX alphabets against the goals defined in , the following observations are true: Base10 and Base16 () are well-known alphabets but tend to produce encoded outputs that are too long for human consumption. Base32 () and Base32hex () strike a balance between compactness and error resistance but include characters that are challenging for human use cases (see ). Base36 often uses the entire alphanumeric range and cannot easily substitute problematic characters. Base58 used in Bitcoin () removes similar problematic characters (0, Ii, Oo, Ll) but introduces both uppercase and lowercase letters, which can cause issues for case-sensitive inputs. Base62 () is a large alphabet with no symbols but, like Base36, uses uppercase and lowercase letters and therefore shares the same issues as Base36 and Base58. Base64 () and Base64url () provide compact encodings but require uppercase, lowercase, and special characters; removing any alphanumeric character typically forces a special character into the alphabet, which is undesirable for human-oriented use. The length of the Base32 alphabet (32 characters) allows selecting a subset of characters while omitting problematic ones. While this is not the most compact encoding available, avoiding symbols and treating alphabet characters as equivalent improves human readability and reduces transcription errors when reading aloud or typing. Compared to Z-Base-32 (), many design considerations overlap, but Z-Base-32 removes a different set of characters (0, 2, Ll, Vv). Z-Base-32 also reorders the alphabet in order to make certain characters appear more frequently for its target use cases. As a result, Z-Base-32 does not follow US-ASCII collation () and does not sort the same as its binary counterpart.

The Alphabet The Base32 for Humans alphabet, which can be referenced as "Base32plus", is a superset of the Base16 alphabet and an alternate version of the Base32hex alphabet; both featuring US-ASCII characters. The encoded data conveys each character as a 5-bit value. If necessary, values are zero-extended as described in so the input data length is a multiple of 5 bits. Base32plus excludes four letters: I, L, O, and U. I/i and l/L can be confused with the number 1, O/o can be confused with 0, and U can produce accidental obscenities or be confused with V/v. Note that 5/S/s and 2/Z/z are not modified in Base32plus, although these characters can look similar in handwriting (see ). details the alphabet characters along with their respective decoding and encoding values. When encoding, only uppercase letters are used. For more information on decoding, see . Value Decoding Encoding 00 0 O o 0 01 1 I i L l 1 02 2 2 03 3 3 04 4 4 05 5 5 06 6 6 07 7 7 08 8 8 09 9 9 10 A a A 11 B b B 12 C c C 13 D d D 14 E e E 15 F f F 16 G g G 17 H h H 18 J j J 19 K k K 20 M m M 21 N n N 22 P p P 23 Q q Q 24 R r R 25 S s S 26 T t T 27 V v V 28 W w W 30 X x X 31 Y y Y 32 Z z Z The Alphabet as a continuous text input can be found in .

Padding The Base32plus alphabet does not use a special padding character. If the bit length of the input is not a multiple of 5, zero-extend the number in the least-significant bit positions to make the length a multiple of 5. For example if the data is a 4-bit value 0b1111 the padded data would be a 5-bit value 0b11110.

Checksums An application MAY append a check symbol to a symbol string. This check symbol can detect symbol-substitution and symbol-transposition errors, allowing transmission and entry errors to be caught cheaply and early. The check symbol encodes the number modulo 37, the smallest prime greater than 32. Five additional symbols are defined for encoding or decoding the check symbol; these are shown in and extend . These additional symbols were chosen to avoid confusion with punctuation or URL formatting. Value Decoding Encoding 32 * * 33 ~ ~ 34 $ $ 35 = = 36 U u U The the checksums postfixed to the can be found in .

Where these symbols prove problematic for various application use cases, implementations MAY strip checksum values, utilize percent-encoding, or other application-specific methods to ensure proper handling and delivery of the checksum value.

Decoding When decoding, both uppercase and lowercase letters are accepted. I/i and L/l are treated as 1, and O/o is treated as 0. Hyphens (-) MAY be inserted into symbol strings to partition them into manageable pieces, improving readability and reducing confusion. Hyphens are ignored during decoding, although an application MAY check hyphen placement to help validate a symbol string.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Security Considerations Section addresses the primary security-related concern in this document: data integrity and validation of decoded data. No additional security considerations are identified.

IANA Considerations This document has no IANA actions.

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. IEEE Bitcoin

Changelog draft-00: Initial Release

Test Vectors The following text vectors start with a base of those found in and then add additional values that illustrate decoding of specific values and the usage of the checksum.

Encoding Input Encoded Data Checksum? Input Type f CR N Text fo CSQG N Text foo CSQPY N Text foob CSQPYRG N Text fooba CSQPYRK1 N Text foobar CSQPYRK1E8 N Text foobar CSQPYRK1E86 Y Text test EHJQ6X0 N Text test EHJQ6X0V Y Text 123456789 0XDWT58U Y Integer

Decoding Input Decoded Data Test Info CSQPYRK1E8 foobar Basic Input 1, decoded as text CSQPY-RK1E8 foobar Decode as text with dashes csqpyrkle8 foobar Decode l input as text csqpyrkie8 foobar Decode i input as text EHJQ6X0 test Base Input 2, decoded as text ehjq6xo test Decode o input as text CSQPYRK1E86 foobar Checksum 1, decoded as text EHJQ6X0V test Checksum 2, decoded as text 0XDWT58U 123456789 Checksum value of extended alphabet, decoded as integer