6 Internet-Draft Kurt D. Zeilenga
7 Intended Category: Standard Track OpenLDAP Foundation
8 Expires in six months 9 February 2005
12 LDAP: Internationalized String Preparation
13 <draft-ietf-ldapbis-strprep-05.txt>
19 This document is intended to be published as a Standard Track RFC.
20 Distribution of this memo is unlimited. Technical discussion of this
21 document will take place on the IETF LDAP Revision Working Group
22 mailing list <ietf-ldapbis@openldap.org>. Please send editorial
23 comments directly to the editor <Kurt@OpenLDAP.org>.
25 By submitting this Internet-Draft, I accept the provisions of Section
26 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
27 applicable patent or other IPR claims of which I am aware have been
28 disclosed, or will be disclosed, and any of which I become aware will
29 be disclosed, in accordance with RFC 3668.
31 Internet-Drafts are working documents of the Internet Engineering Task
32 Force (IETF), its areas, and its working groups. Note that other
33 groups may also distribute working documents as Internet-Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference material
38 or to cite them other than as "work in progress."
40 The list of current Internet-Drafts can be accessed at
41 http://www.ietf.org/1id-abstracts.html
43 The list of Internet-Draft Shadow Directories can be accessed at
44 http://www.ietf.org/shadow.html
47 Copyright (C) The Internet Society (2005). All Rights Reserved.
49 Please see the Full Copyright section near the end of this document
57 Zeilenga LDAPprep [Page 1]
59 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
64 The previous Lightweight Directory Access Protocol (LDAP) technical
65 specifications did not precisely define how character string matching
66 is to be performed. This led to a number of usability and
67 interoperability problems. This document defines string preparation
68 algorithms for character-based matching rules defined for use in LDAP.
73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
75 document are to be interpreted as described in BCP 14 [RFC2119].
77 Character names in this document use the notation for code points and
78 names from the Unicode Standard [Unicode]. For example, the letter
79 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
80 In the lists of mappings and the prohibited characters, the "U+" is
81 left off to make the lists easier to read. The comments for character
82 ranges are shown in square brackets (such as "[CONTROL CHARACTERS]")
83 and do not come from the standard.
85 Note: a glossary of terms used in Unicode can be found in [Glossary].
86 Information on the Unicode character encoding model can be found in
89 The term "combining mark", as used in this specification, refers to
90 any Unicode [Unicode] code point which has a mark property (Mn, Mc,
91 Me). Appendix A provides a complete list of combining marks.
98 A Lightweight Directory Access Protocol (LDAP) [Roadmap] matching rule
99 [Syntaxes] defines an algorithm for determining whether a presented
100 value matches an attribute value in accordance with the criteria
101 defined for the rule. The proposition may be evaluated to True,
104 True - the attribute contains a matching value,
106 False - the attribute contains no matching value,
108 Undefined - it cannot be determined whether the attribute contains
109 a matching value or not.
113 Zeilenga LDAPprep [Page 2]
115 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
118 For instance, the caseIgnoreMatch matching rule may be used to compare
119 whether the commonName attribute contains a particular value without
120 regard for case and insignificant spaces.
123 1.2. X.500 String Matching Rules
125 "X.520: Selected attribute types" [X.520] provides (amongst other
126 things) value syntaxes and matching rules for comparing values
127 commonly used in the Directory. These specifications are inadequate
128 for strings composed of Unicode [Unicode] characters.
130 The caseIgnoreMatch matching rule [X.520], for example, is simply
131 defined as being a case insensitive comparison where insignificant
132 spaces are ignored. For printableString, there is only one space
133 character and case mapping is bijective, hence this definition is
134 sufficient. However, for Unicode string types such as
135 universalString, this is not sufficient. For example, a case
136 insensitive matching implementation which folded lower case characters
137 to upper case would yield different different results than an
138 implementation which used upper case to lower case folding. Or one
139 implementation may view space as referring to only SPACE (U+0020), a
140 second implementation may view any character with the space separator
141 (Zs) property as a space, and another implementation may view any
142 character with the whitespace (WS) category as a space.
144 The lack of precise specification for character string matching has
145 led to significant interoperability problems. When used in
146 certificate chain validation, security vulnerabilities can arise. To
147 address these problems, this document defines precise algorithms for
148 preparing character strings for matching.
151 1.3. Relationship to "stringprep"
153 The character string preparation algorithms described in this document
154 are based upon the "stringprep" approach [StringPrep]. In
155 "stringprep", presented and stored values are first prepared for
156 comparison and so that a character-by-character comparison yields the
159 The approach used here is a refinement of the "stringprep"
160 [StringPrep] approach. Each algorithm involves two additional
163 a) prior to applying the Unicode string preparation steps outlined in
164 "stringprep", the string is transcoded to Unicode;
169 Zeilenga LDAPprep [Page 3]
171 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
174 b) after applying the Unicode string preparation steps outlined in
175 "stringprep", the string is modified to appropriately handle
176 characters insignificant to the matching rule.
178 Hence, preparation of character strings for X.500 matching involves
185 5) Check Bidi (Bidirectional)
186 6) Insignificant Character Handling
188 These steps are described in Section 2.
191 1.4. Relationship to the LDAP Technical Specification
193 This document is a integral part of the LDAP technical specification
194 [Roadmap] which obsoletes the previously defined LDAP technical
195 specification [RFC3377] in its entirety.
197 This document details new LDAP internationalized character string
198 preparation algorithms used by [Syntaxes] and possible other technical
199 specifications defining LDAP syntaxes and/or matching rules.
202 1.5. Relationship to X.500
204 LDAP is defined [Roadmap] in X.500 terms as an X.500 access mechanism.
205 As such, there is a strong desire for alignment between LDAP and X.500
206 syntax and semantics. The character string preparation algorithms
207 described in this document are based upon "Internationalized String
208 Matching Rules for X.500" [XMATCH] proposal to ITU/ISO Joint Study
212 2. String Preparation
214 The following six-step process SHALL be applied to each presented and
215 attribute value in preparation for character string matching rule
225 Zeilenga LDAPprep [Page 4]
227 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
231 6) Insignificant Character Handling
233 Failure in any step causes the assertion to evaluate to Undefined.
235 The character repertoire of this process is Unicode 3.2 [Unicode].
240 Each non-Unicode string value is transcoded to Unicode.
242 PrintableString [X.680] value are transcoded directly to Unicode.
244 UniversalString, UTF8String, and bmpString [X.680] values need not be
245 transcoded as they are Unicode-based strings (in the case of
246 bmpString, a subset of Unicode).
248 TeletexString [X.680] values are transcoded to Unicode. As there is
249 no standard for mapping TelexString values to Unicode, the mapping is
252 For these and other reasons, use of TeletexString is NOT RECOMMENDED.
254 The output is the transcoded string.
259 SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
260 points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
261 VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
262 mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
265 CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
266 TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
267 (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
269 All other control code (e.g., Cc) points or code points with a control
270 function (e.g., Cf) are mapped to nothing. The following is a
271 complete list of these code points: U+0000-0008, 000E-001F, 007F-0084,
272 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
273 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
275 ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points
276 with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
277 Zp) are mapped to SPACE (U+0020). The following is a complete list of
281 Zeilenga LDAPprep [Page 5]
283 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
286 these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F,
289 For case ignore, numeric, and stored prefix string matching rules,
290 characters are case folded per B.2 of [StringPrep].
292 The output is the mapped string.
297 The input string is be normalized to Unicode Form KC (compatibility
298 composed) as described in [UAX15]. The output is the normalized
304 All Unassigned code points are prohibited. Unassigned code points are
305 listed in Table A.1 of [StringPrep].
307 Characters which, per Section 5.8 of [Stringprep], change display
308 properties or are deprecated are prohibited. These characters are are
309 listed in Table C.8 of [StringPrep].
311 Private Use code points are prohibited. These characters are listed
312 in Table C.3 of [StringPrep].
314 All non-character code points are prohibited. These code points are
315 listed in Table C.4 of [StringPrep].
317 Surrogate codes are prohibited. These characters are listed in Table
320 The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
322 The step fails if the input string contains any prohibited code point.
323 Otherwise, the output is the input string.
328 Bidirectional characters are ignored.
331 2.6. Insignificant Character Handling
333 In this step, the string is modified to ensure proper handling of
337 Zeilenga LDAPprep [Page 6]
339 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
342 characters insignificant to the matching rule. This modification
343 differs from matching rule to matching rule.
345 Section 2.6.1 applies to case ignore and exact string matching.
346 Section 2.6.2 applies to numericString matching.
347 Section 2.6.3 applies to telephoneNumber matching.
350 2.6.1. Insignificant Space Handling
352 For the purposes of this section, a space is defined to be the SPACE
353 (U+0020) code point followed by no combining marks.
355 NOTE - The previous steps ensure that the string cannot contain any
356 code points in the separator class, other than SPACE (U+0020).
358 If the input string contains at least one non-space character, then
359 the string is modified such that the string starts with exactly one
360 space character, ends with exactly one SPACE character, and that any
361 inner (non-empty) sequence of space characters is replaced with
362 exactly two SPACE characters. For instance, the input strings
363 "foo<SPACE>bar<SPACE><SPACE>", results in the output
364 "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
366 Otherwise, if the string being prepared is an initial, any, or final
367 substring, then the output string is exactly one SPACE character, else
368 the output string is exactly two SPACEs.
370 Appendix B discusses the rationale for the behavior.
373 2.6.2. numericString Insignificant Character Handling
375 For the purposes of this section, a space is defined to be the SPACE
376 (U+0020) code point followed by no combining marks.
378 All spaces are regarded as insignificant and are to be removed.
380 For example, removal of spaces from the Form KC string:
381 "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
382 would result in the output string:
384 and the Form KC string:
385 "<SPACE><SPACE><SPACE>"
386 would result in the output string:
387 "" (an empty string).
393 Zeilenga LDAPprep [Page 7]
395 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
398 2.6.3. telephoneNumber Insignificant Character Handling
400 For the purposes of this section, a hyphen is defined to be
401 HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
402 NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
403 (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no
404 combining marks and a space is defined to be the SPACE (U+0020) code
405 point followed by no combining marks.
407 All hyphens and spaces are considered insignificant and are to be
410 For example, removal of hyphens and spaces from the Form KC string:
411 "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
412 would result in the output string:
414 and the Form KC string:
415 "<HYPHEN><HYPHEN><HYPHEN>"
416 would result in the (empty) output string:
420 3. Security Considerations
422 "Preparation for International Strings ('stringprep')" [StringPrep]
423 security considerations generally apply to the algorithms described
429 The approach used in this document is based upon design principles and
430 algorithms described in "Preparation of Internationalized Strings
431 ('stringprep')" [StringPrep] by Paul Hoffman and Marc Blanchet. Some
432 additional guidance was drawn from Unicode Technical Standards,
433 Technical Reports, and Notes.
435 This document is a product of the IETF LDAP Revision (LDAPBIS) Working
444 Email: Kurt@OpenLDAP.org
449 Zeilenga LDAPprep [Page 8]
451 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
456 [[Note to the RFC Editor: please replace the citation tags used in
457 referencing Internet-Drafts with tags of the form RFCnnnn where
461 6.1. Normative References
463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
464 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
466 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
467 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
470 [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
471 Internationalized Strings ('stringprep')",
472 draft-hoffman-rfc3454bis-xx.txt, a work in progress.
474 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
475 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
477 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
478 3.2.0" is defined by "The Unicode Standard, Version 3.0"
479 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
480 as amended by the "Unicode Standard Annex #27: Unicode
481 3.1" (http://www.unicode.org/reports/tr27/) and by the
482 "Unicode Standard Annex #28: Unicode 3.2"
483 (http://www.unicode.org/reports/tr28/).
485 [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
486 Unicode Normalization Forms, Version 3.2.0".
487 <http://www.unicode.org/unicode/reports/tr15/tr15-22.html>,
490 [X.680] International Telecommunication Union -
491 Telecommunication Standardization Sector, "Abstract
492 Syntax Notation One (ASN.1) - Specification of Basic
493 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
496 6.2. Informative References
498 [X.500] International Telecommunication Union -
499 Telecommunication Standardization Sector, "The Directory
500 -- Overview of concepts, models and services,"
501 X.500(1993) (also ISO/IEC 9594-1:1994).
505 Zeilenga LDAPprep [Page 9]
507 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
510 [X.501] International Telecommunication Union -
511 Telecommunication Standardization Sector, "The Directory
512 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
514 [X.520] International Telecommunication Union -
515 Telecommunication Standardization Sector, "The
516 Directory: Selected Attribute Types", X.520(1993) (also
517 ISO/IEC 9594-6:1994).
519 [Glossary] The Unicode Consortium, "Unicode Glossary",
520 <http://www.unicode.org/glossary/>.
522 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
523 #17, Character Encoding Model", UTR17,
524 <http://www.unicode.org/unicode/reports/tr17/>, August
527 [XMATCH] Zeilenga, K., "Internationalized String Matching Rules
528 for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
531 [RFC1345] Simonsen, K., "Character Mnemonics & Character Sets",
535 Appendix A. Combining Marks
537 This appendix is normative.
539 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1 05A3-05B9 05BB-05BC
540 05BF 05C1-05C2 05C4 064B-0655 0670 06D6-06DC 06DE-06E4 06E7-06E8
541 06EA-06ED 0711 0730-074A 07A6-07B0 0901-0903 093C 093E-094F 0951-0954
542 0962-0963 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7 09E2-09E3
543 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D 0A70-0A71 0A81-0A83 0ABC
544 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48
545 0B4B-0B4D 0B56-0B57 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
546 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83 0CBE-0CC4 0CC6-0CC8
547 0CCA-0CCD 0CD5-0CD6 0D02-0D03 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57
548 0D82-0D83 0DCA 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
549 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19 0F35 0F37 0F39
550 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97 0F99-0FBC 0FC6 102C-1032
551 1036-1039 1056-1059 1712-1714 1732-1734 1752-1753 1772-1773 17B4-17D3
552 180B-180D 18A9 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
553 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B 1D1AA-1D1AD
557 Appendix B. Substrings Matching
561 Zeilenga LDAPprep [Page 10]
563 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
566 In absence of substrings matching, the insignificant space handling
567 for case ignore/exact matching could be simplified. Specifically,
568 the handling could be as require all sequences of one or more spaces
569 be replaced with one space and, if string contains non-space
570 characters, removal of all all leading spaces and trailing spaces.
572 In the presence of substrings matching, this simplified space handling
573 this simplified space handling would lead to unexpected and
574 undesirable matching behavior. For instance:
575 1) (CN=foo\20*\20bar) would match the CN value "foobar" but not
576 "foo<SPACE>bar" nor "foo<SPACE><SPACE>bar";
577 2) (CN=*\20foobar\20*) would match "foobar", but (CN=*\20*foobar*\20*)
579 3) (CN=foo\20*\20bar) would match "foo<SPACE>X<SPACE>bar" but not
580 "foo<SPACE><SPACE>bar".
582 The first case illustrates that this simplified space handling would
583 cause leading and trailing spaces in substrings of the string to be
584 regarded as insignificant. However, only leading and trailing (as
585 well as multiple consecutive spaces) of the string (as a whole) are
588 The second case illustrates that this simplified space handling would
589 cause sub-partitioning failures. That is, if a prepared any substring
590 matches a partition of the attribute value, then an assertion
591 constructed by subdividing that substring into multiple substrings
594 The third case illustrates that this simplified space handling causes
595 another partitioning failure. Though both the initial or final
596 strings match different portions of "foo<SPACE>X<SPACE>bar" with
597 neither matching the X portion, they don't match a string consisting
598 of the two matched portions less the unmatched X portion.
600 In designing an appropriate approach for space handling for substrings
601 matching, one must study key aspects of X.500 case exact/ignore
602 matching. X.520 [X.520] says:
603 The [substrings] rule returns TRUE if there is a partitioning of
604 the attribute value (into portions) such that:
605 - the specified substrings (initial, any, final) match different
606 portions of the value in the order of the strings sequence;
607 - initial, if present, matches the first portion of the value;
608 - final, if present, matches the last portion of the value;
609 - any, if present, matches some arbitrary portion of the value.
611 That is, the substrings assertion (CN=foo\20*\20bar) matches the
612 attribute value "foo<SPACE><SPACE>bar" as the value can be partitioned
613 into the portions "foo<SPACE>" and "<SPACE>bar" meeting the above
617 Zeilenga LDAPprep [Page 11]
619 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
625 [T]he following spaces are regarded as not significant:
626 - leading spaces (i.e. those preceding the first character that is
628 - trailing spaces (i.e. those following the last character that is
630 - multiple consecutive spaces (these are taken as equivalent to a
631 single space character).
633 This statement applies to the assertion values and attribute values
634 as whole strings, and not individually to substrings of an assertion
635 value. In particular, the statements should be taken to mean that
636 if an assertion value and attribute value match without any
637 consideration to insignificant characters, then that assertion value
638 should also match any attribute value which differs only by inclusion
639 or removal of insignificant characters.
641 Hence, the assertion (CN=foo\20*\20bar) matches
642 "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
643 only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
644 of insignificant spaces.
646 Astute readers of this text will also note that there are special
647 cases where the specified space handling does not ignore spaces
648 which could be considered insignificant. For instance, the assertion
649 (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
650 (insignificant spaces present in value) nor " " (insignificant
651 spaces not present in value). However, as these cases have no
652 practical application that cannot be met by simple assertions, e.g.
653 (cn=\20), and this minor anomaly can only be fully addressed by a
654 preparation algorithm to be used in conjunction with
655 character-by-character partitioning and matching, the anomaly is
656 considered acceptable.
660 Intellectual Property Rights
662 The IETF takes no position regarding the validity or scope of any
663 Intellectual Property Rights or other rights that might be claimed
664 to pertain to the implementation or use of the technology described
665 in this document or the extent to which any license under such
666 rights might or might not be available; nor does it represent that
667 it has made any independent effort to identify any such rights.
668 Information on the procedures with respect to rights in RFC documents
669 can be found in BCP 78 and BCP 79.
673 Zeilenga LDAPprep [Page 12]
675 Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
678 Copies of IPR disclosures made to the IETF Secretariat and any
679 assurances of licenses to be made available, or the result of an
680 attempt made to obtain a general license or permission for the use
681 of such proprietary rights by implementers or users of this
682 specification can be obtained from the IETF on-line IPR repository
683 at http://www.ietf.org/ipr.
685 The IETF invites any interested party to bring to its attention any
686 copyrights, patents or patent applications, or other proprietary
687 rights that may cover technology that may be required to implement
688 this standard. Please address the information to the IETF at
695 Copyright (C) The Internet Society (2005). This document is subject
696 to the rights, licenses and restrictions contained in BCP 78, and
697 except as set forth therein, the authors retain all their rights.
699 This document and the information contained herein are provided on an
700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
701 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
702 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
703 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
704 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
729 Zeilenga LDAPprep [Page 13]