7 INTERNET-DRAFT Kurt D. Zeilenga
8 Intended Category: Standard Track OpenLDAP Foundation
9 Expires in six months 3 May 2003
13 LDAP: Grouping of Related Operations
14 <draft-zeilenga-ldap-grouping-06.txt>
19 This document is an Internet-Draft and is in full conformance with all
20 provisions of Section 10 of RFC2026.
22 This document is intended to be, after appropriate review and
23 revision, submitted to the RFC Editor as a Standard Track document.
24 Distribution of this memo is unlimited. Technical discussion of this
25 document will take place on the IETF LDAP Extension Working Group
26 mailing list <ldapext@ietf.org>. Please send editorial comments
27 directly to the author <Kurt@OpenLDAP.org>.
29 Internet-Drafts are working documents of the Internet Engineering Task
30 Force (IETF), its areas, and its working groups. Note that other
31 groups may also distribute working documents as Internet-Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as ``work in progress.''
37 The list of current Internet-Drafts can be accessed at
38 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
39 Internet-Draft Shadow Directories can be accessed at
40 <http://www.ietf.org/shadow.html>.
42 Copyright 2003, The Internet Society. All Rights Reserved.
44 Please see the Copyright section near the end of this document for
50 This document provides a general mechanism for grouping related
51 Lightweight Directory Access Protocol (LDAP) operations. Grouping of
52 operations can be used to support replication, proxies, and
58 Zeilenga LDAP Grouping [Page 1]
60 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
65 Schema definitions are provided using LDAP description formats
66 [RFC2252]. Definitions provided here are formatted (line wrapped) for
69 Protocol elements are described using ASN.1 [X.680]. The term
70 "BER-encoded" means the element is to be encoded using the Basic
71 Encoding Rules [X.690] under the restrictions detailed in Section 5.1
74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
76 document are to be interpreted as described in BCP 14 [RFC2119].
81 This document provides a general mechanism for grouping related
82 Lightweight Directory Access Protocol (LDAP) [RFC3377] operations.
83 Grouping of operations can be used to support replication, proxies,
84 and high level operations such as transactions [TXNGRP].
86 This document describes a set of LDAP extended operations [RFC2251]
87 and other protocol and schema elements to support grouping of related
88 operations. Uses of this grouping mechanism will be detailed in
91 A group of operations is defined as a set of operations within a
92 common session identified by a unique cookie. All requests which are
93 initiated with the same cookie belong to the same grouping. The
94 cookie is obtained using the create group operation and is normally
95 valid until the end group operation is completed. A group can end
96 prematurely as described below.
98 Operations can be intermixed regardless of their grouping (or lack of
99 grouping). Groups can be nested.
101 Each group is of a particular type specified when the group is
102 created. This type defines the semantics of the group.
107 This document describes three extended operations, two unsolicited
108 notification, and one control. Extended operations and controls are
109 described by LDAP [RFC2251] and provide here for convenience:
114 Zeilenga LDAP Grouping [Page 2]
116 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
119 ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
120 requestName [0] LDAPOID,
121 requestValue [1] OCTET STRING OPTIONAL
124 ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
125 COMPONENTS of LDAPResult,
126 responseName [10] LDAPOID OPTIONAL,
127 response [11] OCTET STRING OPTIONAL
130 Control ::= SEQUENCE {
132 criticality BOOLEAN DEFAULT FALSE,
133 controlValue OCTET STRING OPTIONAL
137 2.1 Common Protocol Elements
139 groupCookie ::= OCTET STRING
141 A groupCookie is an octet string used to uniquely identify a grouping
142 of related operations within the session. A groupCookie is a
143 notational convenience.
146 2.2 Create Grouping Operation
148 The Create Grouping extended operation is used to create or start a
149 grouping of related operations. The operation consists of the
150 createGroupingRequest and the createGroupingResponse. The object
151 identifier createGroupingOID identifies this operation and SHOULD be
152 listed as a value of supportedExtension in the root DSE of servers
153 which support this operation.
155 createGroupingOID ::= "IANA-ASSIGNED-OID.1"
158 2.2.1 createGroupingRequest
160 The client initiates this operation by sending a
161 createGroupingRequest. This request is an ExtendedRequest where the
162 requestName is the object identifier createGroupOID and requestValue
163 is BER-encoded createGroupingRequestValue:
165 createGroupingRequestValue ::= SEQUENCE {
166 createGroupType [0] LDAPOID,
170 Zeilenga LDAP Grouping [Page 3]
172 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
175 createGroupValue [1] OCTET STRING OPTIONAL
178 where createGroupType is an object identifier that describes the
179 specific type of grouping and createGroupValue contains a type
183 2.2.2 createGroupingResponse
185 The createGroupingResponse is sent in response to a
186 createGroupingRequest. This response is an ExtendedResponse where the
187 responseName MUST be the value of the requestName provided in the
188 request and the response is a BER-encoded createGroupingResponseValue:
190 createGroupingResponseValue ::= SEQUENCE {
191 createGroupCookie [0] groupCookie OPTIONAL,
192 createGroupValue [1] OCTET STRING OPTIONAL
195 where createGroupCookie, if present, is a cookie uniquely identifying
196 the new grouping and createGroupValue is a type specific payload. The
197 createGroupCookie only when the operation results in the creation of a
198 group. Otherwise, it is absent.
201 2.3 End Grouping Operation
203 The End Grouping extended operation is used to end or stop a grouping
204 of related operations. The operation consists of the
205 endGroupingRequest and the endGroupingResponse. The object identifier
206 endGroupingOID identifies this operation and SHOULD be listed as a
207 value of supportedExtension in the root DSE of servers which support
210 endGroupingOID ::= "IANA-ASSIGNED-OID.2"
213 2.3.1 endGroupingRequest
215 The client initiates this operation by sending an endGroupingRequest.
216 This request is an ExtendedRequest where the requestName is the object
217 identifier endGroupOID and requestValue is BER-encoded
218 endGroupingRequestValue:
220 endGroupingRequestValue ::= SEQUENCE {
221 endGroupCookie [0] groupCookie,
222 endGroupValue [1] OCTET STRING OPTIONAL
226 Zeilenga LDAP Grouping [Page 4]
228 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
233 where endGroupCookie is a cookie identifying the grouping and
234 endGroupValue contains a type specific payload.
237 2.3.2 endGroupingResponse
239 The endGroupingResponse is sent in response to a endGroupingRequest.
240 This response is an ExtendedResponse where the responseName MUST be
241 the value of the requestName provided in request and the response is a
242 BER-encoded endGroupingResponseValue:
244 endGroupingResponseValue ::= SEQUENCE {
245 endGroupValue [1] OCTET STRING OPTIONAL
248 where endGroupValue is a type specific payload.
251 2.4 endGroupingNotice
253 The endGroupingNotice is an LDAP unsolicited notification. The
254 notification may be sent to the client to end a grouping which the
255 server is unable or unwilling to continue to process. The notice is
256 an extendedResponse where the responseName is the object identifier
257 endGroupingNoticeOID and the response is a BER-encoded
258 endGroupingNoticeValue:
260 endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3"
262 endGroupingNoticeValue ::= SEQUENCE {
263 endGroupingCookie [0] groupCookie,
264 endGroupValue [1] OCTET STRING OPTIONAL
267 where endGroupingCookie is a cookie uniquely identifying the grouping
268 and endGroupValue contains a type specific payload.
271 2.5 Action Grouping Operation
273 The Action Grouping extended operation is used to take an action
274 affecting a grouping of related operations. The operation consists of
275 the actionGroupingRequest and the actionGroupingResponse. The object
276 identifier actionGroupingOID identifies this operation and SHOULD be
277 listed as a value of supportedExtension in the root DSE of servers
278 which support this operation.
282 Zeilenga LDAP Grouping [Page 5]
284 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
287 actionGroupingOID ::= "IANA-ASSIGNED-OID.4"
290 2.5.1 actionGroupingRequest
292 The client initiates this operation by sending an
293 actionGroupingRequest. This request is an ExtendedRequest where the
294 requestName is the object identifier actionGroupOID and requestValue
295 is BER-encoded actionGroupingRequestValue:
297 actionGroupingRequestValue ::= SEQUENCE {
298 actionGroupCookie [0] groupCookie,
299 actionGroupValue [1] OCTET STRING OPTIONAL
302 where actionGroupCookie is a cookie identifying the grouping and
303 actionGroupValue contains a type specific payload.
306 2.5.2 actionGroupingResponse
308 The actionGroupingResponse is sent in response to a
309 actionGroupingRequest. This response is an ExtendedResponse where the
310 responseName MUST be the value of the requestName provided in request
311 and the response is a BER-encoded actionGroupingResponseValue:
313 actionGroupingResponseValue ::= SEQUENCE {
314 actionGroupValue [1] OCTET STRING OPTIONAL
317 where actionGroupValue is a type specific payload.
320 2.6 infoGroupingNotice
322 The infoGroupingNotice is an LDAP unsolicited notification. The
323 notice may be sent to the client to provide additional grouping type
324 specific information. The notice is an extendedResponse where the
325 responseName is the object identifier infoGroupingNoticeOID and the
326 response is a BER-encoded infoGroupingNoticeValue:
328 infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5"
330 infoGroupingNoticeValue ::= SEQUENCE {
331 infoGroupingCookie [0] groupCookie,
332 infoGroupValue [1] OCTET STRING OPTIONAL
338 Zeilenga LDAP Grouping [Page 6]
340 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
343 where infoGroupingCookie is a cookie uniquely identifying the grouping
344 and infoGroupValue contains a type specific payload.
349 The groupingControl is used to identify requests and responses as
350 belonging to a grouping of operations. The groupingControl is a
351 Control where the controlType is the object identifier
352 groupingControlOID, the criticality is TRUE, and the controlValue is a
353 BER-encoded groupingControlValue:
355 groupingControlOID ::= "IANA-ASSIGNED-OID.6"
357 groupingControlValue ::= SEQUENCE {
358 groupingCookie [0] groupCookie,
359 groupValue [1] OCTET STRING OPTIONAL
362 where groupingCookie is a cookie uniquely identifying the grouping and
363 groupingValue contains a type specific payload.
365 The value groupingControlOID SHOULD be listed as a value of
366 supportedControl in the root DSE by servers which support this
369 The control SHALL NOT appear multiple times in the same LDAP PDU. If
370 multiple occurrences of the control are detected, the PDU SHALL be
371 treated as a protocol error.
376 The document describes one attribute type.
379 3.1. supportedGroupingTypes
381 Servers SHOULD publish grouping types they support listing group type
382 object identifiers as values of the supportedGroupingTypes attribute
383 type in the root DSE. The supportedGroupingTypes attribute type is
386 ( IANA-ASSIGNED-OID.7 NAME 'supportedGroupingTypes'
387 DESC 'supported types of groupings of operations'
388 EQUALITY objectIdentifierMatch
389 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
394 Zeilenga LDAP Grouping [Page 7]
396 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
399 The objectIdentifierMatch and OBJECT IDENTIFIER
400 (1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252].
402 Servers MUST be capable of recognizing this attribute type by the name
403 'supportedGroupingTypes'. Servers MAY recognize the attribute type by
407 4. Operational Semantics
409 This section details the common semantics of groups of related
410 operations. Additional semantics may be associated with each
411 grouping type as described by other documents.
414 4.1 Grouping Semantics
416 This subsection details semantics of the protocol elements introduced
420 4.1.1 Create Grouping
422 To group related operations, the client MUST request a groupCookie
423 from the server by sending a createGroupingRequest as described in
424 Section 2.2.1. The client SHALL provide type specific payload in
425 createGroupValue if so required by the grouping type.
427 The server SHALL respond with a createGroupingResponse as described in
428 Section 2.2.2. If the server is willing and able to create the
429 grouping as requested (and per type requirements), it SHALL respond
430 with success, provide a session-unique groupCookie and, if
431 appropriate, a type specific payload. Otherwise the server SHALL
432 respond with a non-successful response containing no groupCookie, but
433 MAY, if appropriate, provide a type specific payload.
438 When the client wishes to end the grouping, the client SHALL send a
439 endGroupingRequest as described in Section 2.3.1. The client SHALL
440 provide the groupCookie of the grouping to end and MAY provided a type
441 specific payload. If the grouping to end contains active nested
442 groupings, these are implicitly ended as well without notice. The
443 server SHALL respond with an endGroupingResponse as described in
450 Zeilenga LDAP Grouping [Page 8]
452 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
455 4.1.3 End Group Notice
457 The server MAY end a group without solicitation for any reason. The
458 server SHALL notify the client of this action by sending a endGrouping
459 Notice, as described in Section 2.4. The server SHALL provide the
460 groupCookie of the group it terminated and MAY provide a type specific
461 payload. The notice SHALL have a non-success resultCode.
463 If the group contains nested groups, the nested groups are implicitly
464 ended as well without additional notice.
467 4.1.4 Action Grouping
469 To perform an action within a group of related operations, the client
470 sends to the server actionGroupingRequest as described in Section
471 2.5.1. The client SHALL provide the groupCookie of the group the
472 operation is requested upon and, if required by the grouping type, a
473 type specific payload.
475 The server SHALL respond with a actionGroupingResponse as described in
476 Section 2.5.2. The server SHALL, if required by the grouping type,
477 provide type specific payload.
480 4.1.5 Info Grouping Notice
482 As allowed by the grouping type, the server MAY provide to the client
483 a notice regarding the grouping of related operations in an
484 infoGroupingNotice as described in Section 2.6. The server SHALL, if
485 required by the grouping type, provide type specific payload.
490 Groups of the same or different types MAY be nested. A nested group
491 is instantiated by providing a groupingControl containing the parent
492 group's cookie with the createGroupingRequest.
494 Group type specifications MAY restrict the types of groupings which
495 may be nested. Servers MAY also place additional restrictions upon
496 nesting. Clients SHOULD NOT assume support for arbitrary nesting.
499 4.3 Intermixing of unrelated operations
501 LDAP is designed to allow clients to perform unrelated tasks
502 concurrently. In keeping with this design, operations which unrelated
506 Zeilenga LDAP Grouping [Page 9]
508 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
511 to the grouping are generally allowed be intermixed with grouped
512 operations. (See Section 4.5 for specific exceptions to this general
513 rule.) It is noted that undue restrictions often unrelated operation
514 cause unnecessary serialization of independent tasks, place
515 unnecessary burden upon implementors, and can limit extensibility.
517 Group type specifications SHOULD NOT disallow unrelated operations
518 from being intermixed with grouped operations.
520 Note: a grouping which disallows unrelated operatoins from being
521 intermixed with grouped operations can be viewed as providing
525 4.4 Grouped operations
527 Interrogation (compare, search) and update (add, delete, modify,
528 rename) MAY be grouped. Certain extended operations MAY also be
529 grouped, but those which affect the session as a whole, such as Start
530 TLS, MUST NOT be grouped.
532 Requests and Responses associated with grouped operations contain a
533 groupingControl control as described in Section 2.7.
535 Group type specifications MAY restrict the kind and/or number of
536 operations which may be related. Servers MAY place additional
537 restrictions upon groupings. Clients SHOULD NOT assume support for
543 Upon issuing any grouping operation, the semantics of following
544 operations listed is modified as described below.
549 The abandon operation SHOULD NOT be used to cancel grouped operations.
550 The Cancel operation is to be used instead (as discussed in 4.5.3).
555 The client SHOULD end all outstanding groupings before issuing a bind
556 request. The server SHALL, in addition to the behavior described in
557 [RFC2251] and [RFC2829], abandon all outstanding groups. No
558 endGroupingNotice notification is sent upon such abandonment.
562 Zeilenga LDAP Grouping [Page 10]
564 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
567 A Bind operation cannot be related to other operations using this
568 grouping mechanism. The bind messages SHOULD NOT contain
569 groupingControl controls and, if present, SHALL be treated as a a
575 The cancel operation [CANCEL] MAY be used to cancel grouped operations
576 but SHOULD NOT contain a groupingControl control unless the group type
577 calls for a type specific payload to be provided. The groupingCookie
578 in the provided groupingControl control MUST be the same associated
579 with the operation to be canceled, otherwise the cancel request SHALL
580 be treated as an error.
585 The client SHOULD end all outstanding groupings before issuing a Start
586 TLS [RFC2930] request. If there are any outstanding groupings, the
587 server MUST return operationsError in response to a StartTLS request.
588 Start TLS operation cannot be related to other operations using this
589 grouping mechanism and the Start TLS request and response PDUs SHALL
590 NOT contain a groupingControl control.
595 The server SHALL, in addition to the behavior described in [RFC2251],
596 abandon all outstanding groups. No endGroupingNotice is sent upon
597 such abandonment. An unbind operation cannot be related to other
598 operations using this grouping mechanism. The unbind request SHOULD
599 NOT contain a groupingControl control and, if present, SHALL be
603 5. Profiling Requirements
605 Documents detailing extensions using the grouping mechanism MUST
606 provide a profile of its use of the mechanism.
608 The profile SHALL specify the object identifier to be used to uniquely
609 identify each grouping type it defines. Object identifiers used to
610 identity group types, like other protocol elements, SHALL be delegated
611 in accordance with BCP 64 [RFC3383] and registered as LDAP Protocol
612 Mechanisms [RFC3383] as detailed in Section 7.1 of this document.
614 The profile SHALL state which protocol elements of the mechanism it
618 Zeilenga LDAP Grouping [Page 11]
620 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
625 Each of the grouping protocol elements defined in this document allow
626 transfer of type specific payloads. For each protocol element used,
627 the profile SHALL state whether the element is to carry a type
628 specific payload or not and SHALL fully describe the syntax and
629 semantics associated with each type specific payload.
631 The profile MAY define grouping type specific semantics which place
632 further restrictions upon the grouping related operations.
635 6. Security Considerations
637 This mechanism can be used to support complex groupings of related
638 operations. With such complexity comes inherit risk. Specifications
639 of uses of this mechanism should take special care to address security
640 issues. In particular, denial of service and authentication,
641 authorization, and access-control issues should be addressed in
642 documents detailing uses of this grouping mechanism.
645 7. IANA Considerations
647 7.1. Future Registration of Grouping Types
649 Future specifications which detail LDAP grouping types are to register
650 each grouping type as a LDAP Protocol Mechanism per guidance given in
651 BCP 64 [RFC3383]. A usage of "Grouping Type" in a Protocol Mechanism
652 registration template indicates that the value to be registered is
653 associated with an LDAP Grouping Type.
656 7.2. Object Identifier Registration
658 It is requested that IANA register upon Standards Action an LDAP
659 Object Identifier to identify protocol elements defined in this
660 technical specification. The following registration template is
663 Subject: Request for LDAP OID Registration
664 Person & email address to contact for further information:
665 Kurt Zeilenga <kurt@OpenLDAP.org>
666 Specification: RFCXXXX
667 Author/Change Controller: IESG
669 Identifies elements of the LDAP Grouping Operation
674 Zeilenga LDAP Grouping [Page 12]
676 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
679 7.3. LDAP Protocol Mechanism
681 It is requested that IANA register upon Standards Action the LDAP
682 protocol mechanism described in this document. The following
683 registration template is suggested:
685 Subject: Request for LDAP Protocol Mechansism Registration
686 Object Identifier: IANA-ASSIGNED-OID
687 Description: See comments
688 Person & email address to contact for further information:
689 Kurt Zeilenga <kurt@openldap.org>
690 Usage: Extended Operation
691 Specification: RFCXXXX
692 Author/Change Controller: IESG
695 Object Identifier Type Description
696 ------------------- ---- -------------------------
697 IANA-ASSIGNED-OID.1 E Create Grouping Operation
698 IANA-ASSIGNED-OID.2 E End Grouping Operation
699 IANA-ASSIGNED-OID.4 E Action Grouping Operation
704 7.4. supportedGroupingTypes Registration
706 It is requested that IANA register upon Standards Action the LDAP
707 'supportedGroupingTypes' descriptor. The following registration
708 template is suggested:
710 Subject: Request for LDAP Descriptor Registration
711 Descriptor (short name): supportedGroupingTypes
712 Object Identifier: IANA-ASSIGNED-OID.7
713 Person & email address to contact for further information:
714 Kurt Zeilenga <kurt@OpenLDAP.org>
715 Usage: Attribute Type
716 Specification: RFCXXXX
717 Author/Change Controller: IESG
722 The author gratefully acknowledges the contributions of the IETF
723 LDAPext and LDUP working groups. In particular, Roger Harrison
724 provided many useful suggestions. Also, the author notes that this
725 document builds upon the early works "Extended Operations for Framing
726 LDAP Operations" by Ellen Stokes, Roger Harrison, and Gordon Good and
730 Zeilenga LDAP Grouping [Page 13]
732 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
735 "Profile for Framing LDAPv3 Operations" by Roger Harrison.
747 10.1 Normative References
749 [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
750 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
752 [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
753 Protocol (v3)", RFC 2251, December 1997.
755 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
756 Directory Access Protocol (v3): Attribute Syntax
757 Definitions", RFC 2252, December 1997.
759 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
760 "Authentication Methods for LDAP", RFC 2829, May 2000.
762 [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
763 Access Protocol (v3): Extension for Transport Layer
764 Security", RFC 2830, May 2000.
766 [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
767 Protocol (v3): Technical Specification", RFC 3377,
770 [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
771 RFC 3383), September 2002.
773 [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
774 Specification of Basic Notation", X.680, 1994.
776 [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
777 Canonical, and Distinguished Encoding Rules", X.690, 1994.
780 10.2. Informative References
782 [TXNGRP] K. Zeilenga, "LDAP Transactions" (a work in progress),
786 Zeilenga LDAP Grouping [Page 14]
788 INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
791 draft-zeilenga-ldap-txn-xx.txt.
794 Copyright 2003, The Internet Society. All Rights Reserved.
796 This document and translations of it may be copied and furnished to
797 others, and derivative works that comment on or otherwise explain it
798 or assist in its implementation may be prepared, copied, published and
799 distributed, in whole or in part, without restriction of any kind,
800 provided that the above copyright notice and this paragraph are
801 included on all such copies and derivative works. However, this
802 document itself may not be modified in any way, such as by removing
803 the copyright notice or references to the Internet Society or other
804 Internet organizations, except as needed for the purpose of
805 developing Internet standards in which case the procedures for
806 copyrights defined in the Internet Standards process must be followed,
807 or as required to translate it into languages other than English.
809 The limited permissions granted above are perpetual and will not be
810 revoked by the Internet Society or its successors or assigns.
812 This document and the information contained herein is provided on an
813 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
814 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
815 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
816 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
817 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
842 Zeilenga LDAP Grouping [Page 15]