1
2
3
4
5
6
7Network Working Group                                        K. Zeilenga
8Request for Comments: 4521                           OpenLDAP Foundation
9BCP: 118                                                       June 2006
10Category: Best Current Practice
11
12
13                          Considerations for
14        Lightweight Directory Access Protocol (LDAP) Extensions
15
16Status of This Memo
17
18   This document specifies an Internet Best Current Practices for the
19   Internet Community, and requests discussion and suggestions for
20   improvements.  Distribution of this memo is unlimited.
21
22Copyright Notice
23
24   Copyright (C) The Internet Society (2006).
25
26Abstract
27
28   The Lightweight Directory Access Protocol (LDAP) is extensible.  It
29   provides mechanisms for adding new operations, extending existing
30   operations, and expanding user and system schemas.  This document
31   discusses considerations for designers of LDAP extensions.
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
58Zeilenga                 Best Current Practice                  [Page 1]
59
60RFC 4521                    LDAP Extensions                    June 2006
61
62
63Table of Contents
64
65   1. Introduction ....................................................3
66      1.1. Terminology ................................................3
67   2. General Considerations ..........................................4
68      2.1. Scope of Extension .........................................4
69      2.2. Interaction between extensions .............................4
70      2.3. Discovery Mechanism ........................................4
71      2.4. Internationalization Considerations ........................5
72      2.5. Use of the Basic Encoding Rules ............................5
73      2.6. Use of Formal Languages ....................................5
74      2.7. Examples ...................................................5
75      2.8. Registration of Protocol Values ............................5
76   3. LDAP Operation Extensions .......................................6
77      3.1. Controls ...................................................6
78           3.1.1. Extending Bind Operation with Controls ..............6
79           3.1.2. Extending the Start TLS Operation with Controls .....7
80           3.1.3. Extending the Search Operation with Controls ........7
81           3.1.4. Extending the Update Operations with Controls .......8
82           3.1.5. Extending the Responseless Operations with Controls..8
83      3.2. Extended Operations ........................................8
84      3.3. Intermediate Responses .....................................8
85      3.4. Unsolicited Notifications ..................................9
86   4. Extending the LDAP ASN.1 Definition .............................9
87      4.1. Result Codes ...............................................9
88      4.2. LDAP Message Types .........................................9
89      4.3. Authentication Methods ....................................10
90      4.4. General ASN.1 Extensibility ...............................10
91   5. Schema Extensions ..............................................10
92      5.1. LDAP Syntaxes .............................................11
93      5.2. Matching Rules ............................................11
94      5.3. Attribute Types ...........................................12
95      5.4. Object Classes ............................................12
96   6. Other Extension Mechanisms .....................................12
97      6.1. Attribute Description Options .............................12
98      6.2. Authorization Identities ..................................12
99      6.3. LDAP URL Extensions .......................................12
100   7. Security Considerations ........................................12
101   8. Acknowledgements ...............................................13
102   9. References .....................................................13
103      9.1. Normative References ......................................13
104      9.2. Informative References ....................................15
105
106
107
108
109
110
111
112
113
114Zeilenga                 Best Current Practice                  [Page 2]
115
116RFC 4521                    LDAP Extensions                    June 2006
117
118
1191.  Introduction
120
121   The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
122   extensible protocol.
123
124   LDAP allows for new operations to be added and for existing
125   operations to be enhanced [RFC4511].
126
127   LDAP allows additional schema to be defined [RFC4512][RFC4517].  This
128   can include additional object classes, attribute types, matching
129   rules, additional syntaxes, and other elements of schema.  LDAP
130   provides an ability to extend attribute types with options [RFC4512].
131
132   LDAP supports a Simple Authentication and Security Layer (SASL)
133   authentication method [RFC4511][RFC4513].  SASL [RFC4422] is
134   extensible.  LDAP may be extended to support additional
135   authentication methods [RFC4511].
136
137   LDAP supports establishment of Transport Layer Security (TLS)
138   [RFC4511][RFC4513].  TLS [RFC4346] is extensible.
139
140   LDAP has an extensible Uniform Resource Locator (URL) format
141   [RFC4516].
142
143   Lastly, LDAP allows for certain extensions to the protocol's Abstract
144   Syntax Notation - One (ASN.1) [X.680] definition to be made.  This
145   facilitates a wide range of protocol enhancements, for example, new
146   result codes needed to support extensions to be added through
147   extension of the protocol's ASN.1 definition.
148
149   This document describes practices that engineers should consider when
150   designing extensions to LDAP.
151
1521.1.  Terminology
153
154   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156   document are to be interpreted as described in BCP 14 [RFC2119].  In
157   this document, "the specification", as used by BCP 14, RFC 2119,
158   refers to the engineering of LDAP extensions.
159
160   The term "Request Control" refers to a control attached to a client-
161   generated message sent to a server.  The term "Response Control"
162   refers to a control attached to a server-generated message sent to a
163   client.
164
165
166
167
168
169
170Zeilenga                 Best Current Practice                  [Page 3]
171
172RFC 4521                    LDAP Extensions                    June 2006
173
174
175   DIT stands for Directory Information Tree.
176   DSA stands for Directory System Agent, a server.
177   DSE stands for DSA-Specific Entry.
178   DUA stands for Directory User Agent, a client.
179   DN stands for Distinguished Name.
180
1812.  General Considerations
182
1832.1.  Scope of Extension
184
185   Mutually agreeing peers may, within the confines of an extension,
186   agree to significant changes in protocol semantics.  However,
187   designers MUST consider the impact of an extension upon protocol
188   peers that have not agreed to implement or otherwise recognize and
189   support the extension.  Extensions MUST be "truly optional"
190   [RFC2119].
191
1922.2.  Interaction between extensions
193
194   Designers SHOULD consider how extensions they engineer interact with
195   other extensions.
196
197   Designers SHOULD consider the extensibility of extensions they
198   specify.  Extensions to LDAP SHOULD themselves be extensible.
199
200   Except where it is stated otherwise, extensibility is implied.
201
2022.3.  Discovery Mechanism
203
204   Extensions SHOULD provide adequate discovery mechanisms.
205
206   As LDAP design is based upon the client-request/server-response
207   paradigm, the general discovery approach is for the client to
208   discover the capabilities of the server before utilizing a particular
209   extension.  Commonly, this discovery involves querying the root DSE
210   and/or other DSEs for operational information associated with the
211   extension.  LDAP provides no mechanism for a server to discover the
212   capabilities of a client.
213
214   The 'supportedControl' attribute [RFC4512] is used to advertise
215   supported controls.  The 'supportedExtension' attribute [RFC4512] is
216   used to advertise supported extended operations.  The
217   'supportedFeatures' attribute [RFC4512] is used to advertise
218   features.  Other root DSE attributes MAY be defined to advertise
219   other capabilities.
220
221
222
223
224
225
226Zeilenga                 Best Current Practice                  [Page 4]
227
228RFC 4521                    LDAP Extensions                    June 2006
229
230
2312.4.  Internationalization Considerations
232
233   LDAP is designed to support the full Unicode [Unicode] repertory of
234   characters.  Extensions SHOULD avoid unnecessarily restricting
235   applications to subsets of Unicode (e.g., Basic Multilingual Plane,
236   ISO 8859-1, ASCII, Printable String).
237
238   LDAP Language Tag options [RFC3866] provide a mechanism for tagging
239   text (and other) values with language information.  Extensions that
240   define attribute types SHOULD allow use of language tags with these
241   attributes.
242
2432.5.  Use of the Basic Encoding Rules
244
245   Numerous elements of LDAP are described using ASN.1 [X.680] and are
246   encoded using a particular subset [Protocol, Section 5.2] of the
247   Basic Encoding Rules (BER) [X.690].  To allow reuse of
248   parsers/generators used in implementing the LDAP "core" technical
249   specification [RFC4510], it is RECOMMENDED that extension elements
250   (e.g., extension specific contents of controlValue, requestValue,
251   responseValue fields) described by ASN.1 and encoded using BER be
252   subjected to the restrictions of [Protocol, Section 5.2].
253
2542.6.  Use of Formal Languages
255
256   Formal languages SHOULD be used in specifications in accordance with
257   IESG guidelines [FORMAL].
258
2592.7.  Examples
260
261   Example DN strings SHOULD conform to the syntax defined in [RFC4518].
262   Example LDAP filter strings SHOULD conform to the syntax defined in
263   [RFC4515].  Example LDAP URLs SHOULD conform to the syntax defined in
264   [RFC4516].  Entries SHOULD be represented using LDIF [RFC2849].
265
2662.8.  Registration of Protocol Values
267
268   Designers SHALL register protocol values of their LDAP extensions in
269   accordance with BCP 64, RFC 4520 [RFC4520].  Specifications that
270   create new extensible protocol elements SHALL extend existing
271   registries or establish new registries for values of these elements
272   in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
273   [RFC2434].
274
275
276
277
278
279
280
281
282Zeilenga                 Best Current Practice                  [Page 5]
283
284RFC 4521                    LDAP Extensions                    June 2006
285
286
2873.  LDAP Operation Extensions
288
289   Extensions SHOULD use controls in defining extensions that complement
290   existing operations.  Where the extension to be defined does not
291   complement an existing operation, designers SHOULD consider defining
292   an extended operation instead.
293
294   For example, a subtree delete operation could be designed as either
295   an extension of the delete operation or as a new operation.  As the
296   feature complements the existing delete operation, use of the control
297   mechanism to extend the delete operation is likely more appropriate.
298
299   As a counter (and contrived) example, a locate services operation (an
300   operation that would return for a DN a set of LDAP URLs to services
301   that may hold the entry named by this DN) could be designed as either
302   a search operation or a new operation.  As the feature doesn't
303   complement the search operation (e.g., the operation is not contrived
304   to search for entries held in the Directory Information Tree), it is
305   likely more appropriate to define a new operation using the extended
306   operation mechanism.
307
3083.1.  Controls
309
310   Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
311   extending existing operations.  The existing operation can be a base
312   operation defined in [RFC4511] (e.g., search, modify) , an extended
313   operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or
314   an operation defined as an extension to a base or extended operation.
315
316   Extensions SHOULD NOT return Response controls unless the server has
317   specific knowledge that the client can make use of the control.
318   Generally, the client requests the return of a particular response
319   control by providing a related request control.
320
321   An existing operation MAY be extended to return IntermediateResponse
322   messages [Protocol, Section 4.13].
323
324   Specifications of controls SHALL NOT attach additional semantics to
325   the criticality of controls beyond those defined in [Protocol,
326   Section 4.1.11].  A specification MAY mandate the criticality take on
327   a particular value (e.g., TRUE or FALSE), where appropriate.
328
3293.1.1.  Extending Bind Operation with Controls
330
331   Controls attached to the request and response messages of a Bind
332   Operation [RFC4511] are not protected by any security layers
333   established by that Bind operation.
334
335
336
337
338Zeilenga                 Best Current Practice                  [Page 6]
339
340RFC 4521                    LDAP Extensions                    June 2006
341
342
343   Specifications detailing controls extending the Bind operation SHALL
344   detail that the Bind negotiated security layers do not protect the
345   information contained in these controls and SHALL detail how the
346   information in these controls is protected or why the information
347   does not need protection.
348
349   It is RECOMMENDED that designers consider alternative mechanisms for
350   providing the function.  For example, an extended operation issued
351   subsequent to the Bind operation (hence, protected by the security
352   layers negotiated by the Bind operation) might be used to provide the
353   desired function.
354
355   Additionally, designers of Bind control extensions MUST also consider
356   how the controls' semantics interact with individual steps of a
357   multi-step Bind operation.  Note that some steps are optional and
358   thus may require special attention in the design.
359
3603.1.2.  Extending the Start TLS Operation with Controls
361
362   Controls attached to the request and response messages of a Start TLS
363   Operation [RFC4511] are not protected by the security layers
364   established by the Start TLS operation.
365
366   Specifications detailing controls extending the Start TLS operation
367   SHALL detail that the Start TLS negotiated security layers do not
368   protect the information contained in these controls and SHALL detail
369   how the information in these controls is protected or why the
370   information does not need protection.
371
372   It is RECOMMENDED that designers consider alternative mechanisms for
373   providing the function.  For example, an extended operation issued
374   subsequent to the Start TLS operation (hence, protected by the
375   security layers negotiated by the Start TLS operation) might be used
376   to provided the desired function.
377
3783.1.3.  Extending the Search Operation with Controls
379
380   The Search operation processing has two distinct phases:
381
382      -  finding the base object; and
383
384      -  searching for objects at or under that base object.
385
386   Specifications of controls extending the Search Operation should
387   clearly state in which phase(s) the control's semantics apply.
388   Semantics of controls that are not specific to the Search Operation
389   SHOULD apply in the finding phase.
390
391
392
393
394Zeilenga                 Best Current Practice                  [Page 7]
395
396RFC 4521                    LDAP Extensions                    June 2006
397
398
3993.1.4.  Extending the Update Operations with Controls
400
401   Update operations have properties of atomicity, consistency,
402   isolation, and durability ([ACID]).
403
404      -  atomicity: All or none of the DIT changes requested are made.
405
406      -  consistency: The resulting DIT state must be conform to schema
407         and other constraints.
408
409      -  isolation: Intermediate states are not exposed.
410
411      -  durability: The resulting DIT state is preserved until
412         subsequently updated.
413
414   When defining a control that requests additional (or other) DIT
415   changes be made to the DIT, these additional changes SHOULD NOT be
416   treated as part of a separate transaction.  The specification MUST be
417   clear as to whether the additional DIT changes are part of the same
418   or a separate transaction as the DIT changes expressed in the request
419   of the base operation.
420
421   When defining a control that requests additional (or other) DIT
422   changes be made to the DIT, the specification MUST be clear as to the
423   order in which these and the base changes are to be applied to the
424   DIT.
425
4263.1.5.  Extending the Responseless Operations with Controls
427
428   The Abandon and Unbind operations do not include a response message.
429   For this reason, specifications for controls designed to be attached
430   to Abandon and Unbind requests SHOULD mandate that the control's
431   criticality be FALSE.
432
4333.2.  Extended Operations
434
435   Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
436   mechanism for defining new operations.  An extended operation
437   consists of an ExtendedRequest message, zero or more
438   IntermediateResponse messages, and an ExtendedResponse message.
439
4403.3.  Intermediate Responses
441
442   Extensions SHALL use IntermediateResponse messages instead of
443   ExtendedResponse messages to return intermediate results.
444
445
446
447
448
449
450Zeilenga                 Best Current Practice                  [Page 8]
451
452RFC 4521                    LDAP Extensions                    June 2006
453
454
4553.4.  Unsolicited Notifications
456
457   Unsolicited notifications [Protocol, Section 4.4] offer a capability
458   for the server to notify the client of events not associated with the
459   operation currently being processed.
460
461   Extensions SHOULD be designed such that unsolicited notifications are
462   not returned unless the server has specific knowledge that the client
463   can make use of the notification.  Generally, the client requests the
464   return of a particular unsolicited notification by performing a
465   related extended operation.
466
467   For example, a time hack extension could be designed to return
468   unsolicited notifications at regular intervals that were enabled by
469   an extended operation (which possibly specified the desired
470   interval).
471
4724.  Extending the LDAP ASN.1 Definition
473
474   LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
475   definition [Protocol, Appendix B] to be made.
476
4774.1.  Result Codes
478
479   Extensions that specify new operations or enhance existing operations
480   often need to define new result codes.  The extension SHOULD be
481   designed such that a client has a reasonably clear indication of the
482   nature of the successful or non-successful result.
483
484   Extensions SHOULD use existing result codes to indicate conditions
485   that are consistent with the intended meaning [RFC4511][X.511] of
486   these codes.  Extensions MAY introduce new result codes [RFC4520]
487   where no existing result code provides an adequate indication of the
488   nature of the result.
489
490   Extensions SHALL NOT disallow or otherwise restrict the return of
491   general service result codes, especially those reporting a protocol,
492   service, or security problem, or indicating that the server is unable
493   or unwilling to complete the operation.
494
4954.2.  LDAP Message Types
496
497   While extensions can specify new types of LDAP messages by extending
498   the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
499   unnecessary and inappropriate.  Existing operation extension
500   mechanisms (e.g., extended operations, unsolicited notifications, and
501   intermediate responses) SHOULD be used instead.  However, there may
502   be cases where an extension does not fit well into these mechanisms.
503
504
505
506Zeilenga                 Best Current Practice                  [Page 9]
507
508RFC 4521                    LDAP Extensions                    June 2006
509
510
511   In such cases, a new extension mechanism SHOULD be defined that can
512   be used by multiple extensions that have similar needs.
513
5144.3.  Authentication Methods
515
516   The Bind operation currently supports two authentication methods,
517   simple and SASL.  SASL [RFC4422] is an extensible authentication
518   framework used by multiple application-level protocols (e.g., BEEP,
519   IMAP, SMTP).  It is RECOMMENDED that new authentication processes be
520   defined as SASL mechanisms.  New LDAP authentication methods MAY be
521   added to support new authentication frameworks.
522
523   The Bind operation's primary function is to establish the LDAP
524   association [RFC4513].  No other operation SHALL be defined (or
525   extended) to establish the LDAP association.  However, other
526   operations MAY be defined to establish other security associations
527   (e.g., IPsec).
528
5294.4.  General ASN.1 Extensibility
530
531   Section 4 of [RFC4511] states the following:
532
533      In order to support future extensions to this protocol,
534      extensibility is implied where it is allowed per ASN.1 (i.e.,
535      sequence, set, choice, and enumerated types are extensible).  In
536      addition, ellipses (...)  have been supplied in ASN.1 types that
537      are explicitly extensible as discussed in [RFC4520].  Because of
538      the implied extensibility, clients and servers MUST (unless
539      otherwise specified) ignore trailing SEQUENCE components whose
540      tags they do not recognize.
541
542   Designers SHOULD avoid introducing extensions that rely on
543   unsuspecting implementations to ignore trailing components of
544   SEQUENCE whose tags they do not recognize.
545
5465.  Schema Extensions
547
548   Extensions defining LDAP schema elements SHALL provide schema
549   definitions conforming with syntaxes defined in [Models, Section
550   4.1].  While provided definitions MAY be reformatted (line wrapped)
551   for readability, this SHALL be noted in the specification.
552
553   For definitions that allow a NAME field, new schema elements SHOULD
554   provide one and only one name.  The name SHOULD be short.
555
556   Each schema definition allows a DESC field.  The DESC field, if
557   provided, SHOULD contain a short descriptive phrase.  The DESC field
558   MUST be regarded as informational.  That is, the specification MUST
559
560
561
562Zeilenga                 Best Current Practice                 [Page 10]
563
564RFC 4521                    LDAP Extensions                    June 2006
565
566
567   be written such that its interpretation is the same with and without
568   the provided DESC fields.
569
570   The extension SHALL NOT mandate that implementations provide the same
571   DESC field in the schema they publish.  Implementors MAY replace or
572   remove the DESC field.
573
574   Published schema elements SHALL NOT be redefined.  Replacement schema
575   elements (new OIDs, new NAMEs) SHOULD be defined as needed.
576
577   Schema designers SHOULD reuse existing schema elements, where
578   appropriate.  However, any reuse MUST not alter the semantics of the
579   element.
580
5815.1.  LDAP Syntaxes
582
583   Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680].
584   Each extension detailing an LDAP syntax MUST specify the ASN.1 data
585   definition associated with the syntax.  A distinct LDAP syntax SHOULD
586   be created for each distinct ASN.1 data definition (including
587   constraints).
588
589   Each LDAP syntax SHOULD have a string encoding defined for it.  It is
590   RECOMMENDED that this string encoding be restricted to UTF-8
591   [RFC3629] encoded Unicode [Unicode] characters.  Use of Generic
592   String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic
593   string encoding rules to provide string encodings for complex ASN.1
594   data definitions is RECOMMENDED.  Otherwise, it is RECOMMENDED that
595   the string encoding be described using a formal language (e.g., ABNF
596   [RFC4234]).  Formal languages SHOULD be used in specifications in
597   accordance with IESG guidelines [FORMAL].
598
599   If no string encoding is defined, the extension SHALL specify how the
600   transfer encoding is to be indicated.  Generally, the extension
601   SHOULD mandate use of binary or other transfer encoding option.
602
6035.2.  Matching Rules
604
605   Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
606   SUBSTRING) may be associated with an attribute type.  In addition,
607   LDAP provides an extensible matching rule mechanism.
608
609   The matching rule specification SHOULD detail which kind of matching
610   rule it is and SHOULD describe which kinds of values it can be used
611   with.
612
613   In addition to requirements stated in the LDAP technical
614   specification, equality matching rules SHOULD be commutative.
615
616
617
618Zeilenga                 Best Current Practice                 [Page 11]
619
620RFC 4521                    LDAP Extensions                    June 2006
621
622
6235.3.  Attribute Types
624
625   Designers SHOULD carefully consider how the structure of values is to
626   be restricted.  Designers SHOULD consider that servers will only
627   enforce constraints of the attribute's syntax.  That is, an attribute
628   intended to hold URIs, but that has directoryString syntax, is not
629   restricted to values that are URIs.
630
631   Designers SHOULD carefully consider which matching rules, if any, are
632   appropriate for the attribute type.  Matching rules specified for an
633   attribute type MUST be compatible with the attribute type's syntax.
634
635   Extensions specifying operational attributes MUST detail how servers
636   are to maintain and/or utilize values of each operational attribute.
637
6385.4.  Object Classes
639
640   Designers SHOULD carefully consider whether each attribute of an
641   object class is required ("MUST") or allowed ("MAY").
642
643   Extensions specifying object classes that allow (or require)
644   operational attributes MUST specify how servers are to maintain
645   and/or utilize entries belonging to these object classes.
646
6476.  Other Extension Mechanisms
648
6496.1.  Attribute Description Options
650
651   Each option is identified by a string of letters, numbers, and
652   hyphens.  This string SHOULD be short.
653
6546.2.  Authorization Identities
655
656   Extensions interacting with authorization identities SHALL support
657   the LDAP authzId format [RFC4513].  The authzId format is extensible.
658
6596.3.  LDAP URL Extensions
660
661   LDAP URL extensions are identified by a short string, a descriptor.
662   Like other descriptors, the string SHOULD be short.
663
6647.  Security Considerations
665
666   LDAP does not place undue restrictions on the kinds of extensions
667   that can be implemented.  While this document attempts to outline
668   some specific issues that designers need to consider, it is not (and
669
670
671
672
673
674Zeilenga                 Best Current Practice                 [Page 12]
675
676RFC 4521                    LDAP Extensions                    June 2006
677
678
679   cannot be) all encompassing.  Designers MUST do their own evaluations
680   of the security considerations applicable to their extensions.
681
682   Designers MUST NOT assume that the LDAP "core" technical
683   specification [RFC4510] adequately addresses the specific concerns
684   surrounding their extensions or assume that their extensions have no
685   specific concerns.
686
687   Extension specifications, however, SHOULD note whether security
688   considerations specific to the feature they are extending, as well as
689   general LDAP security considerations, apply to the extension.
690
6918.  Acknowledgements
692
693   The author thanks the IETF LDAP community for their thoughtful
694   comments.
695
696   This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
697   Greenblatt.
698
6999.  References
700
7019.1.  Normative References
702
703   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
704              Requirement Levels", BCP 14, RFC 2119, March 1997.
705
706   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
707              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
708              October 1998.
709
710   [RFC2849]  Good, G., "The LDAP Data Interchange Format (LDIF) -
711              Technical Specification", RFC 2849, June 2000.
712
713   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
714              10646", STD 63, RFC 3629, November 2003.
715
716   [RFC3641]  Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
717              Types", RFC 3641, October 2003.
718
719   [RFC3642]  Legg, S., "Common Elements of Generic String Encoding
720              Rules (GSER) Encodings", RFC 3642, October 2003.
721
722   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
723              (LDAP): Directory Information Models", RFC 4512, June
724              2006.
725
726
727
728
729
730Zeilenga                 Best Current Practice                 [Page 13]
731
732RFC 4521                    LDAP Extensions                    June 2006
733
734
735   [RFC3866]  Zeilenga, K., Ed., "Language Tags and Ranges in the
736              Lightweight Directory Access Protocol (LDAP)", RFC 3866,
737              July 2004.
738
739   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
740              Specifications: ABNF", RFC 4234, October 2005.
741
742   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
743              (LDAP): Technical Specification Road Map", RFC 4510, June
744              2006.
745
746   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
747              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
748
749   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
750              (LDAP): Directory Information Models", RFC 4512, June
751              2006.
752
753   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
754              (LDAP): Authentication Methods and Security Mechanisms",
755              RFC 4513, June 2006.
756
757   [RFC4515]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
758              Protocol (LDAP): String Representation of Search Filters",
759              RFC 4515, June 2006.
760
761   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
762              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
763              2006.
764
765   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
766              (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
767
768   [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
769              (LDAP): String Representation of Distinguished Names", RFC
770              4518, June 2006.
771
772   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
773              Considerations for the Lightweight Directory Access
774              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
775
776   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
777              Authentication and Security Layer (SASL)", RFC 4422, June
778              2006.
779
780
781
782
783
784
785
786Zeilenga                 Best Current Practice                 [Page 14]
787
788RFC 4521                    LDAP Extensions                    June 2006
789
790
791   [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
792              3.2.0" is defined by "The Unicode Standard, Version 3.0"
793              (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
794              as amended by the "Unicode Standard Annex #27: Unicode
795              3.1" (http://www.unicode.org/reports/tr27/) and by the
796              "Unicode Standard Annex #28: Unicode 3.2"
797              (http://www.unicode.org/reports/tr28/).
798
799   [FORMAL]   IESG, "Guidelines for the use of formal languages in IETF
800              specifications",
801              <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
802              specs.txt>, 2001.
803
804   [X.511]    International Telecommunication Union - Telecommunication
805              Standardization Sector, "The Directory: Abstract Service
806              Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
807
808   [X.680]    International Telecommunication Union - Telecommunication
809              Standardization Sector, "Abstract Syntax Notation One
810              (ASN.1) - Specification of Basic Notation", X.680(2002)
811              (also ISO/IEC 8824-1:2002).
812
813   [X.690]    International Telecommunication Union - Telecommunication
814              Standardization Sector, "Specification of ASN.1 encoding
815              rules: Basic Encoding Rules (BER), Canonical Encoding
816              Rules (CER), and Distinguished Encoding Rules (DER)",
817              X.690(2002) (also ISO/IEC 8825-1:2002).
818
8199.2.  Informative References
820
821   [ACID]     Section 4 of ISO/IEC 10026-1:1992.
822
823   [GUIDE]    Greenblatt, B., "LDAP Extension Style Guide", Work in
824              Progress.
825
826   [RFC3062]  Zeilenga, K., "LDAP Password Modify Extended Operation",
827              RFC 3062, February 2001.
828
829   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
830              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
831
832Author's Address
833
834   Kurt D. Zeilenga
835   OpenLDAP Foundation
836
837   EMail: Kurt@OpenLDAP.org
838
839
840
841
842Zeilenga                 Best Current Practice                 [Page 15]
843
844RFC 4521                    LDAP Extensions                    June 2006
845
846
847Full Copyright Statement
848
849   Copyright (C) The Internet Society (2006).
850
851   This document is subject to the rights, licenses and restrictions
852   contained in BCP 78, and except as set forth therein, the authors
853   retain all their rights.
854
855   This document and the information contained herein are provided on an
856   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
857   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
858   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
859   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
860   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
861   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
862
863Intellectual Property
864
865   The IETF takes no position regarding the validity or scope of any
866   Intellectual Property Rights or other rights that might be claimed to
867   pertain to the implementation or use of the technology described in
868   this document or the extent to which any license under such rights
869   might or might not be available; nor does it represent that it has
870   made any independent effort to identify any such rights.  Information
871   on the procedures with respect to rights in RFC documents can be
872   found in BCP 78 and BCP 79.
873
874   Copies of IPR disclosures made to the IETF Secretariat and any
875   assurances of licenses to be made available, or the result of an
876   attempt made to obtain a general license or permission for the use of
877   such proprietary rights by implementers or users of this
878   specification can be obtained from the IETF on-line IPR repository at
879   http://www.ietf.org/ipr.
880
881   The IETF invites any interested party to bring to its attention any
882   copyrights, patents or patent applications, or other proprietary
883   rights that may cover technology that may be required to implement
884   this standard.  Please address the information to the IETF at
885   ietf-ipr@ietf.org.
886
887Acknowledgement
888
889   Funding for the RFC Editor function is provided by the IETF
890   Administrative Support Activity (IASA).
891
892
893
894
895
896
897
898Zeilenga                 Best Current Practice                 [Page 16]
899
900