git.sur5r.net Git - openldap/blob - doc/drafts/draft-zeilenga-ldap-grouping-xx.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                         Kurt D. Zeilenga
   8 Intended Category: Standard Track                   OpenLDAP Foundation
   9 Expires in six months                                        3 May 2003
  10
  11
  12
  13                    LDAP: Grouping of Related Operations
  14                   <draft-zeilenga-ldap-grouping-06.txt>
  15
  16
  17 Status of Memo
  18
  19   This document is an Internet-Draft and is in full conformance with all
  20   provisions of Section 10 of RFC2026.
  21
  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>.
  28
  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.''
  36
  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>.
  41
  42   Copyright 2003, The Internet Society.  All Rights Reserved.
  43
  44   Please see the Copyright section near the end of this document for
  45   more information.
  46
  47
  48 Abstract
  49
  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
  53   transactions.
  54
  55
  56
  57
  58 Zeilenga                      LDAP Grouping                     [Page 1]
  59 \f
  60 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
  61
  62
  63 Conventions
  64
  65   Schema definitions are provided using LDAP description formats
  66   [RFC2252].  Definitions provided here are formatted (line wrapped) for
  67   readability.
  68
  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
  72   of [RFC2251].
  73
  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].
  77
  78
  79 1. Introduction
  80
  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].
  85
  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
  89   separate documents.
  90
  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.
  97
  98   Operations can be intermixed regardless of their grouping (or lack of
  99   grouping).  Groups can be nested.
 100
 101   Each group is of a particular type specified when the group is
 102   created.  This type defines the semantics of the group.
 103
 104
 105 2. Protocol Elements
 106
 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:
 110
 111
 112
 113
 114 Zeilenga                      LDAP Grouping                     [Page 2]
 115 \f
 116 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 117
 118
 119     ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
 120       requestName    [0] LDAPOID,
 121       requestValue   [1] OCTET STRING OPTIONAL
 122     }
 123
 124     ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
 125       COMPONENTS of LDAPResult,
 126       responseName   [10] LDAPOID OPTIONAL,
 127       response       [11] OCTET STRING OPTIONAL
 128     }
 129
 130     Control ::= SEQUENCE {
 131       controlType    LDAPOID,
 132       criticality    BOOLEAN DEFAULT FALSE,
 133       controlValue   OCTET STRING OPTIONAL
 134     }
 135
 136
 137 2.1 Common Protocol Elements
 138
 139     groupCookie ::= OCTET STRING
 140
 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.
 144
 145
 146 2.2 Create Grouping Operation
 147
 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.
 154
 155     createGroupingOID ::= "IANA-ASSIGNED-OID.1"
 156
 157
 158 2.2.1 createGroupingRequest
 159
 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:
 164
 165     createGroupingRequestValue ::= SEQUENCE {
 166       createGroupType     [0] LDAPOID,
 167
 168
 169
 170 Zeilenga                      LDAP Grouping                     [Page 3]
 171 \f
 172 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 173
 174
 175       createGroupValue    [1] OCTET STRING OPTIONAL
 176     }
 177
 178   where createGroupType is an object identifier that describes the
 179   specific type of grouping and createGroupValue contains a type
 180   specific payload.
 181
 182
 183 2.2.2 createGroupingResponse
 184
 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:
 189
 190     createGroupingResponseValue ::= SEQUENCE {
 191       createGroupCookie [0] groupCookie OPTIONAL,
 192       createGroupValue  [1] OCTET STRING OPTIONAL
 193     }
 194
 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.
 199
 200
 201 2.3 End Grouping Operation
 202
 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
 208   this operation.
 209
 210     endGroupingOID ::= "IANA-ASSIGNED-OID.2"
 211
 212
 213 2.3.1 endGroupingRequest
 214
 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:
 219
 220     endGroupingRequestValue ::= SEQUENCE {
 221       endGroupCookie  [0] groupCookie,
 222       endGroupValue   [1] OCTET STRING OPTIONAL
 223
 224
 225
 226 Zeilenga                      LDAP Grouping                     [Page 4]
 227 \f
 228 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 229
 230
 231     }
 232
 233   where endGroupCookie is a cookie identifying the grouping and
 234   endGroupValue contains a type specific payload.
 235
 236
 237 2.3.2 endGroupingResponse
 238
 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:
 243
 244     endGroupingResponseValue ::= SEQUENCE {
 245       endGroupValue  [1] OCTET STRING OPTIONAL
 246     }
 247
 248   where endGroupValue is a type specific payload.
 249
 250
 251 2.4 endGroupingNotice
 252
 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:
 259
 260     endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3"
 261
 262     endGroupingNoticeValue ::= SEQUENCE {
 263       endGroupingCookie [0] groupCookie,
 264       endGroupValue     [1] OCTET STRING OPTIONAL
 265     }
 266
 267   where endGroupingCookie is a cookie uniquely identifying the grouping
 268   and endGroupValue contains a type specific payload.
 269
 270
 271 2.5 Action Grouping Operation
 272
 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.
 279
 280
 281
 282 Zeilenga                      LDAP Grouping                     [Page 5]
 283 \f
 284 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 285
 286
 287     actionGroupingOID ::= "IANA-ASSIGNED-OID.4"
 288
 289
 290 2.5.1 actionGroupingRequest
 291
 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:
 296
 297     actionGroupingRequestValue ::= SEQUENCE {
 298       actionGroupCookie    [0] groupCookie,
 299       actionGroupValue     [1] OCTET STRING OPTIONAL
 300     }
 301
 302   where actionGroupCookie is a cookie identifying the grouping and
 303   actionGroupValue contains a type specific payload.
 304
 305
 306 2.5.2 actionGroupingResponse
 307
 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:
 312
 313     actionGroupingResponseValue ::= SEQUENCE {
 314       actionGroupValue  [1] OCTET STRING OPTIONAL
 315     }
 316
 317   where actionGroupValue is a type specific payload.
 318
 319
 320 2.6 infoGroupingNotice
 321
 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:
 327
 328     infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5"
 329
 330     infoGroupingNoticeValue ::= SEQUENCE {
 331       infoGroupingCookie [0] groupCookie,
 332       infoGroupValue     [1] OCTET STRING OPTIONAL
 333     }
 334
 335
 336
 337
 338 Zeilenga                      LDAP Grouping                     [Page 6]
 339 \f
 340 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 341
 342
 343   where infoGroupingCookie is a cookie uniquely identifying the grouping
 344   and infoGroupValue contains a type specific payload.
 345
 346
 347 2.7 groupingControl
 348
 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:
 354
 355     groupingControlOID ::= "IANA-ASSIGNED-OID.6"
 356
 357     groupingControlValue ::= SEQUENCE {
 358       groupingCookie   [0] groupCookie,
 359       groupValue       [1] OCTET STRING OPTIONAL
 360     }
 361
 362   where groupingCookie is a cookie uniquely identifying the grouping and
 363   groupingValue contains a type specific payload.
 364
 365   The value groupingControlOID SHOULD be listed as a value of
 366   supportedControl in the root DSE by servers which support this
 367   control.
 368
 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.
 372
 373
 374 3. Schema Elements
 375
 376   The document describes one attribute type.
 377
 378
 379 3.1. supportedGroupingTypes
 380
 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
 384   defined as:
 385
 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 )
 390
 391
 392
 393
 394 Zeilenga                      LDAP Grouping                     [Page 7]
 395 \f
 396 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 397
 398
 399   The objectIdentifierMatch and OBJECT IDENTIFIER
 400   (1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252].
 401
 402   Servers MUST be capable of recognizing this attribute type by the name
 403   'supportedGroupingTypes'.  Servers MAY recognize the attribute type by
 404   other names.
 405
 406
 407 4. Operational Semantics
 408
 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.
 412
 413
 414 4.1 Grouping Semantics
 415
 416   This subsection details semantics of the protocol elements introduced
 417   in Section 2.
 418
 419
 420 4.1.1 Create Grouping
 421
 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.
 426
 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.
 434
 435
 436 4.1.2 End Grouping
 437
 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
 444   Section 2.3.2.
 445
 446
 447
 448
 449
 450 Zeilenga                      LDAP Grouping                     [Page 8]
 451 \f
 452 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 453
 454
 455 4.1.3 End Group Notice
 456
 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.
 462
 463   If the group contains nested groups, the nested groups are implicitly
 464   ended as well without additional notice.
 465
 466
 467 4.1.4 Action Grouping
 468
 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.
 474
 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.
 478
 479
 480 4.1.5 Info Grouping Notice
 481
 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.
 486
 487
 488 4.2 Nested groupings
 489
 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.
 493
 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.
 497
 498
 499 4.3 Intermixing of unrelated operations
 500
 501   LDAP is designed to allow clients to perform unrelated tasks
 502   concurrently.  In keeping with this design, operations which unrelated
 503
 504
 505
 506 Zeilenga                      LDAP Grouping                     [Page 9]
 507 \f
 508 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 509
 510
 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.
 516
 517   Group type specifications SHOULD NOT disallow unrelated operations
 518   from being intermixed with grouped operations.
 519
 520   Note: a grouping which disallows unrelated operatoins from being
 521   intermixed with grouped operations can be viewed as providing
 522   "framing" semantics.
 523
 524
 525 4.4 Grouped operations
 526
 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.
 531
 532   Requests and Responses associated with grouped operations contain a
 533   groupingControl control as described in Section 2.7.
 534
 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
 538   arbitrary grouping.
 539
 540
 541 4.5 Other Operations
 542
 543   Upon issuing any grouping operation, the semantics of following
 544   operations listed is modified as described below.
 545
 546
 547 4.5.1 abandon
 548
 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).
 551
 552
 553 4.5.2 bind
 554
 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.
 559
 560
 561
 562 Zeilenga                      LDAP Grouping                    [Page 10]
 563 \f
 564 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 565
 566
 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
 570   protocol error.
 571
 572
 573 4.5.3 cancel
 574
 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.
 581
 582
 583 4.5.4 Start TLS
 584
 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.
 591
 592
 593 4.5.5 unbind
 594
 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
 600   ignored.
 601
 602
 603 5. Profiling Requirements
 604
 605   Documents detailing extensions using the grouping mechanism MUST
 606   provide a profile of its use of the mechanism.
 607
 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.
 613
 614   The profile SHALL state which protocol elements of the mechanism it
 615
 616
 617
 618 Zeilenga                      LDAP Grouping                    [Page 11]
 619 \f
 620 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 621
 622
 623   uses.
 624
 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.
 630
 631   The profile MAY define grouping type specific semantics which place
 632   further restrictions upon the grouping related operations.
 633
 634
 635 6. Security Considerations
 636
 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.
 643
 644
 645 7. IANA Considerations
 646
 647 7.1. Future Registration of Grouping Types
 648
 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.
 654
 655
 656 7.2. Object Identifier Registration
 657
 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
 661   suggested:
 662
 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
 668       Comments:
 669           Identifies elements of the LDAP Grouping Operation
 670
 671
 672
 673
 674 Zeilenga                      LDAP Grouping                    [Page 12]
 675 \f
 676 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 677
 678
 679 7.3.  LDAP Protocol Mechanism
 680
 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:
 684
 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
 693       Comments: none
 694
 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
 700
 701       in 2
 702
 703
 704 7.4. supportedGroupingTypes Registration
 705
 706       It is requested that IANA register upon Standards Action the LDAP
 707       'supportedGroupingTypes' descriptor.  The following registration
 708       template is suggested:
 709
 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
 718
 719
 720 8. Acknowledgments
 721
 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
 727
 728
 729
 730 Zeilenga                      LDAP Grouping                    [Page 13]
 731 \f
 732 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 733
 734
 735   "Profile for Framing LDAPv3 Operations" by Roger Harrison.
 736
 737
 738 9. Author's Address
 739
 740   Kurt D. Zeilenga
 741   OpenLDAP Foundation
 742   <Kurt@OpenLDAP.org>
 743
 744
 745 10. References
 746
 747 10.1 Normative References
 748
 749   [RFC2119]  S. Bradner, "Key Words for use in RFCs to Indicate
 750              Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 751
 752   [RFC2251]  M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
 753              Protocol (v3)", RFC 2251, December 1997.
 754
 755   [RFC2252]  M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
 756              Directory Access Protocol (v3):  Attribute Syntax
 757              Definitions", RFC 2252, December 1997.
 758
 759   [RFC2829]  M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
 760              "Authentication Methods for LDAP", RFC 2829, May 2000.
 761
 762   [RFC2830]  J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
 763              Access Protocol (v3): Extension for Transport Layer
 764              Security", RFC 2830, May 2000.
 765
 766   [RFC3377]  J. Hodges, R. Morgan, "Lightweight Directory Access
 767              Protocol (v3): Technical Specification", RFC 3377,
 768              September 2002.
 769
 770   [RFC3383]  K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
 771              RFC 3383), September 2002.
 772
 773   [X.680]    ITU-T, "Abstract Syntax Notation One (ASN.1) -
 774              Specification of Basic Notation", X.680, 1994.
 775
 776   [X.690]    ITU-T, "Specification of ASN.1 encoding rules:  Basic,
 777              Canonical, and Distinguished Encoding Rules", X.690, 1994.
 778
 779
 780 10.2. Informative References
 781
 782   [TXNGRP]   K. Zeilenga, "LDAP Transactions" (a work in progress),
 783
 784
 785
 786 Zeilenga                      LDAP Grouping                    [Page 14]
 787 \f
 788 INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
 789
 790
 791              draft-zeilenga-ldap-txn-xx.txt.
 792
 793
 794 Copyright 2003, The Internet Society.  All Rights Reserved.
 795
 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.
 808
 809   The limited permissions granted above are perpetual and will not be
 810   revoked by the Internet Society or its successors or assigns.
 811
 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.
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Zeilenga                      LDAP Grouping                    [Page 15]
 843 \f