]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4521.txt
Remove many (but not all) references to slurpd(8).
[openldap] / doc / rfc / rfc4521.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 4521                           OpenLDAP Foundation
9 BCP: 118                                                       June 2006
10 Category: Best Current Practice
11
12
13                           Considerations for
14         Lightweight Directory Access Protocol (LDAP) Extensions
15
16 Status 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
22 Copyright Notice
23
24    Copyright (C) The Internet Society (2006).
25
26 Abstract
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
58 Zeilenga                 Best Current Practice                  [Page 1]
59 \f
60 RFC 4521                    LDAP Extensions                    June 2006
61
62
63 Table 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
114 Zeilenga                 Best Current Practice                  [Page 2]
115 \f
116 RFC 4521                    LDAP Extensions                    June 2006
117
118
119 1.  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
152 1.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
170 Zeilenga                 Best Current Practice                  [Page 3]
171 \f
172 RFC 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
181 2.  General Considerations
182
183 2.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
192 2.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
202 2.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
226 Zeilenga                 Best Current Practice                  [Page 4]
227 \f
228 RFC 4521                    LDAP Extensions                    June 2006
229
230
231 2.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
243 2.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
254 2.6.  Use of Formal Languages
255
256    Formal languages SHOULD be used in specifications in accordance with
257    IESG guidelines [FORMAL].
258
259 2.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
266 2.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
282 Zeilenga                 Best Current Practice                  [Page 5]
283 \f
284 RFC 4521                    LDAP Extensions                    June 2006
285
286
287 3.  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
308 3.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
329 3.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
338 Zeilenga                 Best Current Practice                  [Page 6]
339 \f
340 RFC 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
360 3.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
378 3.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
394 Zeilenga                 Best Current Practice                  [Page 7]
395 \f
396 RFC 4521                    LDAP Extensions                    June 2006
397
398
399 3.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
426 3.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
433 3.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
440 3.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
450 Zeilenga                 Best Current Practice                  [Page 8]
451 \f
452 RFC 4521                    LDAP Extensions                    June 2006
453
454
455 3.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
472 4.  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
477 4.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
495 4.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
506 Zeilenga                 Best Current Practice                  [Page 9]
507 \f
508 RFC 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
514 4.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
529 4.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
546 5.  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
562 Zeilenga                 Best Current Practice                 [Page 10]
563 \f
564 RFC 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
581 5.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
603 5.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
618 Zeilenga                 Best Current Practice                 [Page 11]
619 \f
620 RFC 4521                    LDAP Extensions                    June 2006
621
622
623 5.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
638 5.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
647 6.  Other Extension Mechanisms
648
649 6.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
654 6.2.  Authorization Identities
655
656    Extensions interacting with authorization identities SHALL support
657    the LDAP authzId format [RFC4513].  The authzId format is extensible.
658
659 6.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
664 7.  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
674 Zeilenga                 Best Current Practice                 [Page 12]
675 \f
676 RFC 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
691 8.  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
699 9.  References
700
701 9.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
730 Zeilenga                 Best Current Practice                 [Page 13]
731 \f
732 RFC 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
786 Zeilenga                 Best Current Practice                 [Page 14]
787 \f
788 RFC 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
819 9.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
832 Author's Address
833
834    Kurt D. Zeilenga
835    OpenLDAP Foundation
836
837    EMail: Kurt@OpenLDAP.org
838
839
840
841
842 Zeilenga                 Best Current Practice                 [Page 15]
843 \f
844 RFC 4521                    LDAP Extensions                    June 2006
845
846
847 Full 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
863 Intellectual 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
887 Acknowledgement
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
898 Zeilenga                 Best Current Practice                 [Page 16]
899 \f