aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/doc/oidspecs/rfc/rfc4530.oidspec
diff options
context:
space:
mode:
Diffstat (limited to 'doc/oidspecs/rfc/rfc4530.oidspec')
-rw-r--r--doc/oidspecs/rfc/rfc4530.oidspec317
1 files changed, 317 insertions, 0 deletions
diff --git a/doc/oidspecs/rfc/rfc4530.oidspec b/doc/oidspecs/rfc/rfc4530.oidspec
new file mode 100644
index 0000000..6e88524
--- /dev/null
+++ b/doc/oidspecs/rfc/rfc4530.oidspec
@@ -0,0 +1,317 @@
1
2
3{
4 //
5 // RFC 4122 A UUID URN Namespace July 2005
6 //
7 // 3. Namespace Registration Template
8 //
9 // Namespace ID: UUID
10 // Registration Information:
11 // Registration date: 2003-10-01
12 //
13 // Declared registrant of the namespace:
14 // JTC 1/SC6 (ASN.1 Rapporteur Group)
15 //
16 // Declaration of syntactic structure:
17 // A UUID is an identifier that is unique across both space and time,
18 // with respect to the space of all UUIDs. Since a UUID is a fixed
19 // size and contains a time field, it is possible for values to
20 // rollover (around A.D. 3400, depending on the specific algorithm
21 // used). A UUID can be used for multiple purposes, from tagging
22 // objects with an extremely short lifetime, to reliably identifying
23 // very persistent objects across a network.
24 //
25 // The internal representation of a UUID is a specific sequence of
26 // bits in memory, as described in Section 4. To accurately
27 // represent a UUID as a URN, it is necessary to convert the bit
28 // sequence to a string representation.
29 //
30 // Each field is treated as an integer and has its value printed as a
31 // zero-filled hexadecimal digit string with the most significant
32 // digit first. The hexadecimal values "a" through "f" are output as
33 // lower case characters and are case insensitive on input.
34 //
35 // The formal definition of the UUID string representation is
36 // provided by the following ABNF [7]:
37 //
38 // UUID = time-low "-" time-mid "-"
39 // time-high-and-version "-"
40 // clock-seq-and-reserved
41 // clock-seq-low "-" node
42 // time-low = 4hexOctet
43 // time-mid = 2hexOctet
44 // time-high-and-version = 2hexOctet
45 // clock-seq-and-reserved = hexOctet
46 // clock-seq-low = hexOctet
47 // node = 6hexOctet
48 // hexOctet = hexDigit hexDigit
49 // hexDigit =
50 // "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
51 // "a" / "b" / "c" / "d" / "e" / "f" /
52 // "A" / "B" / "C" / "D" / "E" / "F"
53 //
54 // The following is an example of the string representation of a UUID as
55 // a URN:
56 //
57 // urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
58 //
59 // Relevant ancillary documentation:
60 // [1][2]
61 // Identifier uniqueness considerations:
62 // This document specifies three algorithms to generate UUIDs: the
63 // first leverages the unique values of 802 MAC addresses to
64 // guarantee uniqueness, the second uses pseudo-random number
65 // generators, and the third uses cryptographic hashing and
66 // application-provided text strings. As a result, the UUIDs
67 // generated according to the mechanisms here will be unique from all
68 // other UUIDs that have been or will be assigned.
69 //
70 // Identifier persistence considerations:
71 // UUIDs are inherently very difficult to resolve in a global sense.
72 // This, coupled with the fact that UUIDs are temporally unique
73 // within their spatial context, ensures that UUIDs will remain as
74 // persistent as possible.
75 //
76 // Process of identifier assignment:
77 // Generating a UUID does not require that a registration authority
78 // be contacted. One algorithm requires a unique value over space
79 // for each generator. This value is typically an IEEE 802 MAC
80 // address, usually already available on network-connected hosts.
81 // The address can be assigned from an address block obtained from
82 // the IEEE registration authority. If no such address is available,
83 // or privacy concerns make its use undesirable, Section 4.5
84 // specifies two alternatives. Another approach is to use version 3
85 // or version 4 UUIDs as defined below.
86 //
87 // Process for identifier resolution:
88 // Since UUIDs are not globally resolvable, this is not applicable.
89 //
90 // Rules for Lexical Equivalence:
91 // Consider each field of the UUID to be an unsigned integer as shown
92 // in the table in section Section 4.1.2. Then, to compare a pair of
93 // UUIDs, arithmetically compare the corresponding fields from each
94 // UUID in order of significance and according to their data type.
95 // Two UUIDs are equal if and only if all the corresponding fields
96 // are equal.
97 //
98 // As an implementation note, equality comparison can be performed on
99 // many systems by doing the appropriate byte-order canonicalization,
100 // and then treating the two UUIDs as 128-bit unsigned integers.
101 //
102 // UUIDs, as defined in this document, can also be ordered
103 // lexicographically. For a pair of UUIDs, the first one follows the
104 // second if the most significant field in which the UUIDs differ is
105 // greater for the first UUID. The second precedes the first if the
106 // most significant field in which the UUIDs differ is greater for
107 // the second UUID.
108 //
109 // Conformance with URN Syntax:
110 // The string representation of a UUID is fully compatible with the
111 // URN syntax. When converting from a bit-oriented, in-memory
112 // representation of a UUID into a URN, care must be taken to
113 // strictly adhere to the byte order issues mentioned in the string
114 // representation section.
115 //
116 // Validation mechanism:
117 // Apart from determining whether the timestamp portion of the UUID
118 // is in the future and therefore not yet assignable, there is no
119 // mechanism for determining whether a UUID is 'valid'.
120 //
121 // Scope:
122 // UUIDs are global in scope.
123 //
124 //
125 // RFC 4530 LDAP entryUUID June 2006
126 //
127 // 2.1. UUID Syntax
128 //
129 // A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
130 // bit) value that identifies an object. The ASN.1 [X.680] type UUID is
131 // defined to represent UUIDs as follows:
132 //
133 // UUID ::= OCTET STRING (SIZE(16))
134 // -- constrained to an UUID [RFC4122]
135 //
136 // In LDAP, UUID values are encoded using the [ASCII] character string
137 // representation described in [RFC4122]. For example,
138 // "597ae2f6-16a6-1027-98f4-d28b5365dc14".
139 //
140 // The following is an LDAP syntax description suitable for publication
141 // in subschema subentries.
142 //
143 // ( 1.3.6.1.1.16.1 DESC 'UUID' )
144 //
145 .oid = "1.3.6.1.1.16.1",
146 .name = "UUID",
147 .desc = "UUID",
148 .flags = LDAPSCHEMA_O_READABLE,
149 .type = LDAPSCHEMA_SYNTAX,
150 .class = LDAPSCHEMA_CLASS_ASCII,
151 .def = "( 1.3.6.1.1.16.1 DESC 'UUID' )",
152 .abnf = "UUID = time-low \"-\" time-mid \"-\"\n"
153 " time-high-and-version \"-\"\n"
154 " clock-seq-and-reserved\n"
155 " clock-seq-low \"-\" node\n"
156 "time-low = 4hexOctet\n"
157 "time-mid = 2hexOctet\n"
158 "time-high-and-version = 2hexOctet\n"
159 "clock-seq-and-reserved = hexOctet\n"
160 "clock-seq-low = hexOctet\n"
161 "node = 6hexOctet\n"
162 "hexOctet = hexDigit hexDigit\n"
163 "hexDigit =\n"
164 " \"0\" / \"1\" / \"2\" / \"3\" / \"4\" / \"5\" / \"6\" / \"7\" / \"8\" / \"9\" /\n"
165 " \"a\" / \"b\" / \"c\" / \"d\" / \"e\" / \"f\" /\n"
166 " \"A\" / \"B\" / \"C\" / \"D\" / \"E\" / \"F\"\n",
167 .re_posix = NULL,
168 .re_pcre = NULL,
169 .spec = "RFC 4530: LDAP entryUUID",
170 .spec_type = LDAPSCHEMA_SPEC_RFC,
171 .spec_name = "4530",
172 .spec_section = "2.1",
173 .spec_source = NULL,
174 .spec_vendor = "IETF",
175 .spec_text = NULL,
176 .notes = NULL,
177 .examples = (const char *[])
178 {
179 "597ae2f6-16a6-1027-98f4-d28b5365dc14",
180 NULL,
181 },
182};
183
184
185
186
187{
188 //
189 // RFC 4530 LDAP entryUUID June 2006
190 //
191 // 2.2. 'uuidMatch' Matching Rule
192 //
193 // The 'uuidMatch' matching rule compares an asserted UUID with a stored
194 // UUID for equality. Its semantics are the same as the
195 // 'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs
196 // from 'octetStringMatch' in that the assertion value is encoded using
197 // the UUID string representation instead of the normal OCTET STRING
198 // string representation.
199 //
200 // The following is an LDAP matching rule description suitable for
201 // publication in subschema subentries.
202 //
203 // ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
204 // SYNTAX 1.3.6.1.1.16.1 )
205 //
206 .oid = "1.3.6.1.1.16.2",
207 .name = "uuidMatch",
208 .desc = "'uuidMatch' Matching Rule",
209 .flags = 0,
210 .type = LDAPSCHEMA_MATCHINGRULE,
211 .def = "( 1.3.6.1.1.16.2 NAME 'uuidMatch' SYNTAX 1.3.6.1.1.16.1 )",
212 .spec = "RFC 4530: LDAP entryUUID",
213 .spec_type = LDAPSCHEMA_SPEC_RFC,
214 .spec_name = "4530",
215 .spec_section = "2.2",
216 .spec_source = NULL,
217 .spec_vendor = "IETF",
218 .spec_text = NULL,
219 .notes = NULL,
220 .examples = NULL,
221};
222
223
224
225{
226 //
227 // RFC 4530 LDAP entryUUID June 2006
228 //
229 // 2.3. 'uuidOrderingMatch' Matching Rule
230 //
231 // The 'uuidOrderingMatch' matching rule compares an asserted UUID with
232 // a stored UUID for ordering. Its semantics are the same as the
233 // 'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule
234 // differs from 'octetStringOrderingMatch' in that the assertion value
235 // is encoded using the UUID string representation instead of the normal
236 // OCTET STRING string representation.
237 //
238 // The following is an LDAP matching rule description suitable for
239 // publication in subschema subentries.
240 //
241 // ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
242 // SYNTAX 1.3.6.1.1.16.1 )
243 //
244 // Note that not all UUID variants have a defined ordering; and even
245 // where it does, servers are not obligated to assign UUIDs in any
246 // particular order. This matching rule is provided for completeness.
247 //
248 .oid = "1.3.6.1.1.16.3",
249 .name = "uuidOrderingMatch",
250 .desc = "'uuidOrderingMatch' Matching Rule",
251 .flags = 0,
252 .type = LDAPSCHEMA_MATCHINGRULE,
253 .def = "( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch' SYNTAX 1.3.6.1.1.16.1 )",
254 .spec = "RFC 4530: LDAP entryUUID",
255 .spec_type = LDAPSCHEMA_SPEC_RFC,
256 .spec_name = "4530",
257 .spec_section = "2.3",
258 .spec_source = NULL,
259 .spec_vendor = "IETF",
260 .spec_text = NULL,
261 .notes = NULL,
262 .examples = NULL,
263};
264
265
266
267{
268 //
269 // RFC 4530 LDAP entryUUID June 2006
270 //
271 // 2.4. 'entryUUID' Attribute
272 //
273 // The 'entryUUID' operational attribute provides the Universally Unique
274 // Identifier (UUID) assigned to the entry.
275 //
276 // The following is an LDAP attribute type description suitable for
277 // publication in subschema subentries.
278 //
279 // ( 1.3.6.1.1.16.4 NAME 'entryUUID'
280 // DESC 'UUID of the entry'
281 // EQUALITY uuidMatch
282 // ORDERING uuidOrderingMatch
283 // SYNTAX 1.3.6.1.1.16.1
284 // SINGLE-VALUE
285 // NO-USER-MODIFICATION
286 // USAGE directoryOperation )
287 //
288 // Servers SHALL generate and assign a new UUID to each entry upon its
289 // addition to the directory and provide that UUID as the value of the
290 // 'entryUUID' operational attribute. An entry's UUID is immutable.
291 //
292 // UUID are to be generated in accordance with Section 4 of [RFC4122].
293 // In particular, servers MUST ensure that each generated UUID is unique
294 // in space and time.
295 //
296 .oid = "1.3.6.1.1.16.4",
297 .name = "entryUUID",
298 .desc = "UUID of the entry",
299 .flags = LDAPSCHEMA_O_READABLE | LDAPSCHEMA_O_SINGLEVALUE | LDAPSCHEMA_O_NO_USER_MOD,
300 .type = LDAPSCHEMA_ATTRIBUTETYPE,
301 .def = "( 1.3.6.1.1.16.4 NAME 'entryUUID' DESC 'UUID of the entry' EQUALITY uuidMatch ORDERING uuidOrderingMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )",
302 .spec = "RFC 4530: LDAP entryUUID",
303 .spec_type = LDAPSCHEMA_SPEC_RFC,
304 .spec_name = "4530",
305 .spec_section = "2.4",
306 .spec_source = NULL,
307 .spec_vendor = "IETF",
308 .spec_text = NULL,
309 .notes = NULL,
310 .examples = NULL,
311};
312
313
314
315
316
317// end of OID spec file