-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-taylor-uuid-ncname.xml
402 lines (392 loc) · 28 KB
/
draft-taylor-uuid-ncname.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
<?xml version="1.0" encoding="utf-8"?>
<rfc version="3" category="info" submissionType="independent" ipr="trust200902" updates="4122" docName="draft-taylor-uuid-ncname-03">
<front>
<title>Compact UUIDs for Constrained Grammars</title>
<seriesInfo name="Internet-Draft" status="informational" value="draft-taylor-uuid-ncname-03"/>
<author initials="D" surname="Taylor" fullname="Dorian Taylor">
<organization>Independent</organization>
<address>
<email>ietf@doriantaylor.com</email>
<uri>https://doriantaylor.com/</uri>
</address>
</author>
<date year="2023" month="1" day="10"/>
<abstract>
<t>The Universally Unique Identifier is a suitable standard for, as the name suggests, uniquely identifying entities in a symbol space large enough that the identifiers do not collide. Many formal grammars, however, are too restrictive to permit the use of UUIDs in their canonical representation (described in RFC 4122 and elsewhere), despite it being useful to do so. This document specifies an alternative compact representation for UUIDs that preserves some properties of the canonical form, with three encoding varietals, to fit these more restrictive contexts.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>The formal grammar production "one or more letters or underscores followed by zero or more letters, digits, or underscores" (denoted by the regular expression <tt>/^[A-Za-z_][0-9A-Za-z_]*$/</tt>) is ubiquitous in computing. It is often used for identifiers, and for good reasons. We may encounter some variations on this theme, like admitting hyphens, dots, or Unicode alphanumerics. Some systems may impose additional constraints, like case-sensitivity (or the lack of it), explicit upper- or lower-case letters, or limits on identifier length.</t>
<t>UUIDs are standardized 128-bit identifiers with many useful properties, and there are many places where it would make sense to use them, but their canonical representation, either with or without <xref target="RFC4122">the URN prefix</xref>, does not conform to the constraint described above:</t>
<ul>
<li>UUIDs contain hyphens (and colons, in UUID URNs),</li>
<li>UUIDs potentially start with a digit,</li>
<li>UUIDs are potentially too long for a given slot.</li>
</ul>
<t>This leads to developers creating ad-hoc, overlapping, and generally mutually incompatible solutions. The goal of this specification is to address an ostensible need for a UUID representation that is fewer characters in length than the canonical form, and that always starts with a letter.</t>
<t>This document specifies a strategy for a compact representation of UUIDs, with three encoding variants, as well as the related transformations to and from the familiar UUID format. The proposed name for the general strategy is <em>UUID-NCName</em>, after the <xref target="XML-NAMES">NCName grammar production</xref>, which is pervasive in XML and RDF applications. The encodings are thus styled as <em>UUID-NCName-32</em>, <em>UUID-NCName-58</em>, and <em>UUID-NCName-64</em>, referring to the numerical base of their respective encodings. Each encoding presents tradeoffs in alphabet, symbol length, and case sensitivity.</t>
<section title="Requirements" anchor="requirements">
<t>The aim of this specification is to eliminate work on the part of developers who find themselves in the position of needing to squeeze UUIDs into the aforementioned grammars, by defining alternative representations that are:</t>
<ul>
<li>Significantly shorter lexically than the canonical UUID representation (even after removing the hyphens),</li>
<li>Guaranteed to begin with with a letter (<tt>/^[A-Za-z]/</tt>),</li>
<li>Deployable (through different encodings) in case-sensitive and case-insensitive contexts,</li>
<li>Devoid of non-payload characters (i.e., every character in the representation is part of the UUID; except for any padding to a prescribed length; see <xref target="strategy"/>),</li>
<li>Fully isomorphic to the canonical UUID representation (i.e., accommodates all possible future UUID versions and variants that <xref target="RFC4122"/> does),</li>
<li>Amenable to <xref target="detection">detection and identification by heuristic</xref> (in a manner analogous to the canonical UUID representation).</li>
</ul>
</section>
<section title="Motivation & Applications" anchor="applications">
<t>The purpose of an identifier in general is to pick out some information resource or other, such that it can be referred to, ideally unambiguously. The purpose of a large, generated identifier like the UUID, is to satisfy the uniqueness criterion while also specifying a datatype and normal form for said identifiers, and ultimately alleviate the need to set time aside to think up names for things. Why one would want to go inserting UUIDs in places they wouldn't otherwise fit, is so these UUIDs can be cross-referenced in some other database where they <em>do</em> fit. Consider:</t>
<ul>
<li>A programming environment that separates the task of writing logic from naming things, stores identifiers internally as UUID-NCName-32 prior to transforming them on display or export, thus preserving the correctness of the syntax.</li>
<li>A component content management system that uses UUIDs to identify elementary content components, uses the UUID-NCName-64 (or UUID-NCName-58, but in this case Base64 works too and is one byte shorter) representations of the same UUIDs as fragment identifiers for when those components are transcluded.</li>
</ul>
</section>
</section>
<section title="Terminology" anchor="terminology">
<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section title="Strategy" anchor="strategy">
<t>Not all 128 bits of a UUID are data; rather, several bits are masked. The top four bits of the third segment, known as <tt>time_hi_and_version</tt>, specify the UUID's version, which is fixed. Up to three high bits in the following segment, called <tt>clock_seq_hi_and_reserved</tt>, specify the variant: how the UUID — if applicable — is meant to be read. We remove these masked quartets (we round up to four bits for the variant) and use them as "bookends" for the rest of the identifier, mapping them to the first sixteen symbols of the Base32 table <xref target="RFC4648"/>, which are all letters. These "bookend" characters provide an analogous hint to a developer of the nature of the UUID, just as one can by looking at the third and fourth segments of a canonical hexadecimal UUID representation.</t>
<t>The remaining 120 bits, which we bit-shift to close the gaps of the two masked quartets we removed, now divide evenly by both 5 and 6, the number of bits per character in Base32 and Base64, respectively. <xref target="Base58">Base58</xref> encoding cannot map to an even number of bits, but we don't have the same concerns with regard to padding as we do with Base32 and Base64. Indeed with Base58 we have a different padding issue: some inputs yield shorter outputs than others, so we pad the Base58 representation with underscore characters (<tt>_</tt>, a character <em>not</em> in the Base58 alphabet) to get a consistent length. The details are laid out in the <xref target="encoding">encoding algorithm</xref> below.</t>
<t>The transformation takes a UUID such as <tt>068d0f22-7ce5-4fe2-9f81-3a09af4ed880</tt>, and returns the results:</t>
<ul>
<li><tt>ea2gq6it44x7c7aj2bgxu5weaj</tt> for Base32,</li>
<li><tt>EBdYYqP7vH96E8SLjJaTH_J</tt> for Base58, and</li>
<li><tt>EBo0PInzl_i-BOgmvTtiAJ</tt> for Base64.</li>
</ul>
<t>These symbols will always start and end with case-insensitive letters (<tt>/^[A-Za-z]/</tt>), and the entire Base32 symbol is case-insensitive.</t>
</section>
<section title="Syntax" anchor="syntax">
<t>Here is the ABNF grammar for the productions <tt>uuid-ncname-32</tt>, <tt>uuid-ncname-58</tt>, and <tt>uuid-ncname-64</tt>:</t>
<sourcecode type="abnf"><![CDATA[uuid-ncname-32 = bookend 24base32 bookend
uuid-ncname-58 = bookend base58 bookend
uuid-ncname-64 = bookend 20base64url bookend
bookend = %x41-50 / %x61-70 ; [A-Pa-p]
base32 = %x32-37 / %x41-5a / %x61-7a ; [2-7A-Za-z]
b58char = %x31-39 / %x41-48 / %x4a-4e / %x50-5a /
%x61-6c / %x6d-7a ; [1-9A-HJ-NP-Za-km-z]
base58 = 15b58char 6"_" / 16b58char 5"_" /
17b58char 4"_" / 18b58char 3"_" /
19b58char 2"_" / 20b58char "_" / 21b58char
; (symbol sequence plus appropriate padding)
base64url = %x2d / %x30-39 / %x41-5a / %x5f / %x61-7a
; [-0-9A-Z_a-z]]]></sourcecode>
<t>"Bookends" are 4-bit sequences (nybbles, quartets, etc.) which we map directly onto the Base32 table from <xref target="RFC4648"/>. Indeed the this portion of the Base64 table is identical, though we say Base32 to underscore the fact that bookend characters are case-insensitive. Certain environments encode meaning into the case of the first character of a symbol, so it is important that its literal representation be flexible. There is likewise little value in arbitrarily constraining the last character. Nevertheless, UUID-NCName-32 symbols <bcp14>SHOULD</bcp14> be generated entirely lower-case, while UUID-NCName-58 and UUID-NCName-64 symbols <bcp14>SHOULD</bcp14> be generated with the bookend characters in upper-case.</t>
<section title="Detection Heuristic" anchor="detection">
<t>All encodings of UUID-NCName are a fixed length:</t>
<ul>
<li>UUID-NCName-32 is always 26 bytes.</li>
<li>UUID-NCName-58 is always 23 bytes.</li>
<li>UUID-NCName-64 is always 22 bytes.</li>
</ul>
<t>All encodings likewise use the same "bookend" mechanism which always correspond to the first 16 symbols of Base32 (A to P, with the side effect that they are effectively case-insensitive). The first and last character in all three representations will therefore always be the same, modulo case, for a given UUID. Furthermore, since these "bookend" characters represent the version and variant bits, they will correspond to predictable values. Version 4 (random) UUIDs, for instance, will always begin with <tt>E</tt>, and any UUID with its variant bits set as defined in <xref target="RFC4122">RFC 4122</xref> will always terminate (again, modulo case) with <tt>I</tt>, <tt>J</tt>, <tt>K</tt>, or <tt>L</tt>.</t>
<t>Given these facts, any UUID-NCName representation <bcp14>MAY</bcp14> be captured (and its "bookends" separated) using the following regular expression:</t>
<sourcecode type="perl"><![CDATA[/\b([A-Pa-p]) # zero-width boundary and version bookend
([2-7A-Za-z]{24}|[-0-9A-Z_a-z]{20}| # base32 and 64
(?:[1-9A-HJ-NP-Za-km-z]{15}_{6}|[1-9A-HJ-NP-Za-km-z]{16}_{5}|
[1-9A-HJ-NP-Za-km-z]{17}_{4}|[1-9A-HJ-NP-Za-km-z]{18}___|
[1-9A-HJ-NP-Za-km-z]{19}__|[1-9A-HJ-NP-Za-km-z]{20}_|
[1-9A-HJ-NP-Za-km-z]{21})) # base58 with underscore pad
([A-Pa-p])\b/x # variant bookend and zero-width boundary]]></sourcecode>
<t>The scrupulous may also wish to examine the bookend characters, for which the first should only correspond to the numbers 1 through 5 (plus zero for the nil UUID) for UUID versions known at the time of this writing, and the other should have the same bits set as expected in <relref section="4.1.1" target="RFC4122">RFC 4122</relref>. Note however that there is room in the spec for another ten UUID versions (up to a hypothetical version 15), and another variant bit that is currently unused.</t>
<t>This detection method is considered a heuristic because it is possible to identify false-positive matches in random strings of text, just as it would be with a canonical UUID representation. It is assumed that there would be sufficient enough context to positively identify these alternative UUID representations in the wild.</t>
</section>
<section title="Equivalency" anchor="equivalency">
<t>Two UUID-NCName symbols are necessarily identical if they convert to the same (canonical) UUID. Two UUID-NCName-32 symbols are identical if their string values match when normalized to all upper- or lower-case letters. Two UUID-NCName-58 or UUID-NCName-64 symbols are identical if their string values match when the "bookend" characters are normalized to either upper- or lower-case.</t>
</section>
</section>
<section title="Algorithms" anchor="algorithms">
<t>These are candidate algorithms for encoding and decoding the symbols, transforming them to and from the canonical UUID representation. Equivalent algorithms no doubt exist, but these are the ones used in the <xref target="implementations">reference implementations</xref>.</t>
<section title="Encoding Algorithm" anchor="encoding">
<t>First we apply the shifting algorithm:</t>
<ol>
<li>Convert the UUID to a binary string <tt>bin</tt>.</li>
<li>Convert <tt>bin</tt> to an array of four 32-bit unsigned network-endian integers <tt>ints</tt>.</li>
<li>Extract <tt>version</tt> as <tt>(ints[1] & 0x0000f000) >> 12</tt>.</li>
<li>Extract <tt>variant</tt> as <tt>(ints[2] & 0xf0000000) >> 24</tt>.</li>
<li>Assign <tt>ints[1] = (ints[1] & 0xffff0000) | ((ints[1] & 0x00000fff) << 4) | ((ints[2] & 0x0fffffff) >> 24)</tt>.</li>
<li>Assign <tt>ints[2] = (ints[2] & 0x00ffffff) << 8 | (ints[3] >> 24)</tt>.</li>
<li>Assign <tt>ints[3] = (ints[3] << 8) | variant</tt>.</li>
<li>Convert <tt>ints</tt> back into a binary string and return it along with the <tt>version</tt>.</li>
</ol>
<t>Then apply one of the formatting algorithms; here is Base32:</t>
<ol>
<li>Take the binary string <tt>bin</tt> and shift the last octet to the right by one bit.</li>
<li>Encode <tt>bin</tt> with the Base32 algorithm to get the string <tt>b32</tt>.</li>
<li>Truncate <tt>b32</tt> to 25 characters, removing any padding.</li>
<li>Convert <tt>version</tt> to its value in the Base32 table.</li>
<li>Return <tt>version</tt> concatenated to <tt>b32</tt>, optionally in either upper or lower case.</li>
</ol>
<t>And Base58:</t>
<ol>
<li>Remove the last octet from the binary string <tt>bin</tt>, convert it to an integer and assign it to <tt>variant</tt>.</li>
<li>Shift <tt>variant</tt> to the right by 4 bits, and convert it to its value in the Base32 table.</li>
<li>Encode the remaining <tt>bin</tt> with the Base58 algorithm to get the string <tt>b58</tt>.</li>
<li>If <tt>b58</tt> is less than 21 characters long, append underscores (<tt>_</tt>) until it is.</li>
<li>Convert <tt>version</tt> to its value in the Base32 table.</li>
<li>Return the concatenation of <tt>version</tt>, <tt>b58</tt>, and <tt>variant</tt>.</li>
</ol>
<t>And finally, Base64:</t>
<ol>
<li>Take the binary string <tt>bin</tt> and shift the last octet to the right by two bits.</li>
<li>Encode <tt>bin</tt> with the base64url algorithm to get the string <tt>b64</tt>.</li>
<li>Truncate <tt>b64</tt> to 21 characters, removing any padding.</li>
<li>Convert <tt>version</tt> to its value in the Base32 table.</li>
<li>return <tt>version</tt> concatenated to <tt>b64</tt>.</li>
</ol>
</section>
<section title="Decoding Algorithm" anchor="decoding">
<ol>
<li>First use the <xref target="detection">detection heuristic</xref> to determine whether the symbol <tt>ncname</tt> is Base32, Base58, or Base64.</li>
<li>Remove the first character of the symbol <tt>ncname</tt> and convert it into an integer according to the Base32 spec; call that integer <tt>version</tt>.</li>
<li>
<t>If <tt>ncname</tt> is Base58:</t>
<ol type="a">
<li>Remove the last character and decode it to an integer according to the Base32 spec; call that integer <tt>variant</tt>.</li>
<li>Shift <tt>variant</tt> four bits to the left.</li>
<li>Remove all trailing underscores from the remainder of <tt>ncname</tt>.</li>
<li>Decode the remainder of <tt>ncname</tt> with the Base58 algorithm as <tt>bin</tt>.</li>
<li>Append the octet corresponding to the value of <tt>variant</tt> to <tt>bin</tt>.</li>
</ol>
</li>
<li>
<t>Otherwise:</t>
<ol type="a">
<li>If <tt>ncname</tt> is Base64, and the last character is lowercase, set it to uppercase.</li>
<li>Append padding if necessary to satisfy the decoder, <tt>A======</tt> for Base32 and <tt>A==</tt> for Base64.</li>
<li>Decode the remainder of <tt>ncname</tt> by either the <tt>base32</tt> or <tt>base64url</tt> decoding algorithm into binary string <tt>bin</tt>.</li>
<li>If <tt>ncname</tt> is Base32, shift the last octet of <tt>bin</tt> one bit to the left; if Base64 shift it two bits.</li>
</ol>
</li>
</ol>
<t>Now we apply the shifting algorithm in reverse:</t>
<ol>
<li>Ensure <tt>version &= 0xf</tt> so it is in the range of 0-15.</li>
<li>Convert the binary string <tt>bin</tt> into an array of four 32-bit unsigned network-endian integers <tt>ints</tt>.</li>
<li>Assign <tt>variant = (ints[3] & 0xf0) << 24</tt>.</li>
<li>Shift and assign <tt>ints[3] >>= 8</tt>.</li>
<li>Union and assign <tt>ints[3] |= ((ints[2] & 0xff) << 24)</tt>.</li>
<li>Shift and assign <tt>ints[2] >>= 8</tt>.</li>
<li>Union and assign <tt>ints[2] |= ((ints[1] & 0xf) << 24) | variant</tt>.</li>
<li>Assign <tt>ints[1] = (ints[1] & 0xffff0000) | (version << 12) | ((ints[1] >> 4) & 0xfff)</tt>.</li>
<li>Convert <tt>ints</tt> back into the new binary string <tt>bin</tt>.</li>
<li>Format <tt>bin</tt> as a canonical UUID.</li>
</ol>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t>There are no discernible IANA considerations associated with this specification.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>As UUID-NCName symbols are isomorphic to their canonical UUID representations, the security considerations for these symbols also the same as <xref target="RFC4122"/>, though we repeat here the admonition not to assume that UUIDs are hard to guess.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="Base58" target="https://tools.ietf.org/html/draft-msporny-base58-02">
<front>
<title>The Base58 Encoding Scheme</title>
<author initials="S." surname="Nakamoto" fullname="S. Nakamoto"/>
<author initials="M." surname="Sporny" fullname="M. Sporny"/>
<date year="2020" month="October" day="31"/>
<abstract>
<t>This document specifies the base 58 encoding scheme, including an introduction to the benefits of the approach, the encoding and decoding algorithm, alternative alphabets, and security considerations.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"/>
<date year="1997" month="March"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC4122" target="https://www.rfc-editor.org/info/rfc4122">
<front>
<title>A Universally Unique IDentifier (UUID) URN Namespace</title>
<author initials="P." surname="Leach" fullname="P. Leach"/>
<author initials="M." surname="Mealling" fullname="M. Mealling"/>
<author initials="R." surname="Salz" fullname="R. Salz"/>
<date year="2005" month="July"/>
<abstract>
<t>This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4122"/>
<seriesInfo name="DOI" value="10.17487/RFC4122"/>
</reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson"/>
<date year="2006" month="October"/>
<abstract>
<t>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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"/>
<date year="2017" month="May"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="XML-NAMES" target="https://www.w3.org/TR/2009/REC-xml-names-20091208/">
<front>
<title>Namespaces in XML 1.0 (Third Edition)</title>
<author initials="T" surname="Bray" fullname="Tim Bray"/>
<author initials="D" surname="Hollander" fullname="Dave Hollander"/>
<author initials="A" surname="Layman" fullname="Andrew Layman"/>
<author initials="R" surname="Tobin" fullname="Richard Tobin"/>
<author initials="H S" surname="Thompson" fullname="Henry S. Thompson"/>
<date year="2009" month="December" day="08"/>
<abstract>
<t>XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references.</t>
</abstract>
</front>
</reference>
</references>
<section title="Samples" anchor="samples">
<table>
<name>Samples of canonical UUID representations</name>
<thead>
<tr>
<th>Version</th>
<th>Canonical UUID Representation</th>
</tr>
</thead>
<tbody>
<tr>
<th>0, Nil</th>
<td><tt>00000000-0000-0000-0000-000000000000</tt></td>
</tr>
<tr>
<th>1, Timestamp</th>
<td><tt>ca6be4c8-cbaf-11ea-b2ab-00045a86c8a1</tt></td>
</tr>
<tr>
<th>2, DCE "Security"</th>
<td><tt>000003e8-cbb9-21ea-b201-00045a86c8a1</tt></td>
</tr>
<tr>
<th>3, MD5</th>
<td><tt>3d813cbb-47fb-32ba-91df-831e1593ac29</tt></td>
</tr>
<tr>
<th>4, Random</th>
<td><tt>01867b2c-a0dd-459c-98d7-89e545538d6c</tt></td>
</tr>
<tr>
<th>5, SHA-1</th>
<td><tt>21f7f8de-8051-5b89-8680-0195ef798b6a</tt></td>
</tr>
</tbody>
</table>
<table>
<name>Samples of UUID-NCName-32 and UUID-NCName-64 representations</name>
<thead>
<tr>
<th>Version</th>
<th>Base32</th>
<th>Base64</th>
</tr>
</thead>
<tbody>
<tr>
<th>0, Nil</th>
<td><tt>aaaaaaaaaaaaaaaaaaaaaaaaaa</tt></td>
<td><tt>AAAAAAAAAAAAAAAAAAAAAA</tt></td>
</tr>
<tr>
<th>1, Timestamp</th>
<td><tt>bzjv6jsglv4pkfkyaarninsfbl</tt></td>
<td><tt>BymvkyMuvHqKrAARahsihL</tt></td>
</tr>
<tr>
<th>2, DCE "Security"</th>
<td><tt>caaaah2glxepkeaiaarninsfbl</tt></td>
<td><tt>CAAAD6Mu5HqIBAARahsihL</tt></td>
</tr>
<tr>
<th>3, MD5</th>
<td><tt>dhwatzo2h7mv2dx4ddykzhlbjj</tt></td>
<td><tt>DPYE8u0f7K6Hfgx4Vk6wpJ</tt></td>
</tr>
<tr>
<th>4, Random</th>
<td><tt>eagdhwlfa3vm4rv4j4vcvhdlmj</tt></td>
<td><tt>EAYZ7LKDdWcjXieVFU41sJ</tt></td>
</tr>
<tr>
<th>5, SHA-1</th>
<td><tt>feh37rxuakg4jnaabsxxxtc3ki</tt></td>
<td><tt>FIff43oBRuJaAAZXveYtqI</tt></td>
</tr>
</tbody>
</table>
<table>
<name>Samples of UUID-NCName-58 representations</name>
<thead>
<tr>
<th>Version</th>
<th>Base58</th>
</tr>
</thead>
<tbody>
<tr>
<th>0, Nil</th>
<td><tt>A111111111111111______A</tt></td>
</tr>
<tr>
<th>1, Timestamp</th>
<td><tt>B6fTkmTD22KpWbDq1LuiszL</tt></td>
</tr>
<tr>
<th>2, DCE "Security"</th>
<td><tt>C11KtP6Y9P3rRkvh2N1e__L</tt></td>
</tr>
<tr>
<th>3, MD5</th>
<td><tt>D2ioV6oTr9yq6dMojd469nJ</tt></td>
</tr>
<tr>
<th>4, Random</th>
<td><tt>E3UZ99RxxUJC1v4dWsYtb_J</tt></td>
</tr>
<tr>
<th>5, SHA-1</th>
<td><tt>Fx7wEJfz9eb1TYzsrT7Zs_I</tt></td>
</tr>
</tbody>
</table>
</section>
<section title="Implementations" anchor="implementations">
<t>As of this writing, there are two implementations of UUID-NCName:</t>
<ul>
<li>Perl, <eref target="https://metacpan.org/pod/Data::UUID::NCName"/></li>
<li>Ruby, <eref target="https://rubygems.org/gems/uuid-ncname"/></li>
</ul>
</section>
</back>
</rfc>