git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldup-framing-xx.txt

   1
   2 Extended Operations for Framing LDAP Operations
   3 Internet-Draft
   4 Intended Category: Standards Track
   5 Expires: September 10, 2000
   6
   7
   8                                                             Ellen Stokes
   9                                                          IBM Corporation
  10
  11                                                           Roger Harrison
  12                                                             Novell, Inc.
  13
  14                                                              Gordon Good
  15                                            Netscape Communications Corp.
  16
  17                                                           March 10, 2000
  18
  19             Extended Operations for Framing LDAP Operations
  20                 Filename: draft-ietf-ldup-framing-00.txt
  21
  22 Table of Contents
  23
  24 1.    Status of this Memo.............................................2
  25 2.    Abstract........................................................2
  26 3.    Overview........................................................2
  27 4.    Protocol element definitions....................................3
  28 4.1   StartFramedProtocolRequest Extended Operation...................3
  29 4.2   StartFramedProtocolResponse Extended Operation..................3
  30 4.3   EndFramedProtocolRequest Extended Operation.....................4
  31 4.4   EndFramedProtocolResponse Extended Operation....................4
  32 5.    Acknowledgments.................................................5
  33 6.    References......................................................5
  34 7.    Author's Addresses..............................................5
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Stokes, Harrison and Good                                       [Page 1]
  56 \f
  57 Internet-Draft               LDUP Workgroup               March 10, 2000
  58
  59
  60 1. Status of this Memo
  61
  62    This document is an Internet-Draft and is in full conformance with
  63    all provisions of Section 10 of RFC2026.
  64
  65    Internet-Drafts are working documents of the Internet Engineering
  66    Task Force (IETF), its areas, and its working groups. Note that other
  67    groups may also distribute working documents as Internet-Drafts.
  68
  69    Internet-Drafts are draft documents valid for a maximum of six months
  70    and may be updated, replaced, or obsoleted by other documents at any
  71    time.  It is inappropriate to use Internet- Drafts as reference
  72    material or to cite them other than as "work in progress."
  73
  74     The list of current Internet-Drafts can be accessed at
  75      http://www.ietf.org/ietf/1id-abstracts.txt
  76
  77      The list of Internet-Draft Shadow Directories can be accessed at
  78      http://www.ietf.org/shadow.html.
  79
  80 .
  81
  82    This Internet Draft expires September 10, 2000.
  83
  84
  85 2. Abstract
  86
  87    Certain types of LDAP applications can benefit from the ability to
  88    specify the beginning and end of a related group of operations.  For
  89    example, the LDUP multimaster update protocol [ARCHITECTURE] requires
  90    that two servers agree to begin a session to transfer pending
  91    replication updates. This document provides a framework for
  92    constructing protocols that feature a framed set of related
  93    operations.  It defines a pair of LDAPv3 extended operations that
  94    provide begin-end framing, and a pair of extended operations used to
  95    respond the begin-end framing operations. The nature of the actual
  96    LDAP operations carried inside these framing operations is not
  97    specified in this document.
  98
  99    All protocol elements described here are LDAP Version 3 extended
 100    operations. LDAP Version 3 is described in RFC 2251 [LDAPv3].
 101
 102    Certain terms used in this document are defined in the document "LDAP
 103    Replication Architecture" [ARCHITECTURE].
 104
 105    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 106    "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
 107    to be interpreted as described in RFC 2119 [KEYWORDS].
 108
 109 3. Overview
 110
 111    This document describes two LDAPv3 Extended Operations that are used
 112    to signal the beginning and end of a set of grouped operations, and
 113
 114
 115
 116 Stokes, Harrison and Good                                       [Page 2]
 117 \f
 118 Internet-Draft               LDUP Workgroup               March 10, 2000
 119
 120
 121    two LDAPv3 extended operations that are used to respond to these
 122    operations. These extended operations provide a framework that may be
 123    used when developing a protocol that requires begin-end framing.
 124
 125 4. Protocol element definitions
 126
 127 4.1 StartFramedProtocolRequest Extended Operation
 128
 129    The StartFramedProtocolRequest extended operation indicates that the
 130    initiator wishes to begin transmission of a set of related LDAP
 131    operations. The requestValue of the StartFramedProtocolRequest
 132    extended operation contains an OID that describes the specific framed
 133    protocol being initiated, and a protocol-specific payload.
 134
 135    An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
 136
 137       ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
 138           requestName    [0] LDAPOID,
 139           requestValue   [1] OCTET STRING OPTIONAL
 140       }
 141
 142    The requestName portion of the StartFramedProtocolRequest must be the
 143    OID "2.16.840.1.113719.1.142.100.1".
 144
 145    The requestValue of the StartFramedProtocolRequest must be set to the
 146    BER-encoding of the following:
 147
 148       StartFramedProtocolRequestValue ::= SEQUENCE {
 149                 framedProtocolOID LDAPOID,
 150                 framedProtocolPayload OPTIONAL OCTET STRING
 151       }
 152
 153    The parameters in the requestValue of the StartFramedProtocolRequest
 154    are:
 155
 156       - framedProtocolOID: An OID that uniquely identifies the protocol
 157         framed by this operation.  - framedProtocolPayload: An octet
 158       string that contains protocol-specific
 159         information.
 160
 161
 162 4.2 StartFramedProtocolResponse Extended Operation
 163
 164    The StartFramedProtocolResponse extended operation is sent in
 165    response to a StartFramedProtocolResponse extended operation.
 166
 167    An LDAPv3 Extended Response is defined in [LDAPv3] as follows:
 168
 169
 170
 171
 172 Stokes, Harrison and Good                                       [Page 3]
 173 \f
 174 Internet-Draft               LDUP Workgroup               March 10, 2000
 175
 176
 177       ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
 178           COMPONENTS of LDAPResult,
 179           responseName  [10] LDAPOID OPTIONAL,
 180           response      [11] OCTET STRING OPTIONAL
 181       }
 182
 183    The responseName of the StartFramedProtocolResponse must be the OID
 184    "2.16.840.1.113719.1.142.100.2".
 185
 186    The response of the StartFramedProtocolResponse is set to the BER-
 187    encoding of a protocol-specific response.
 188
 189 4.3 EndFramedProtocolRequest Extended Operation
 190
 191    The EndFramedProtocolRequest extended operation indicates the end a
 192    set of related LDAP operations. The requestValue of the
 193    EndFramedProtocolRequest extended operation contains a protocol-
 194    specific payload.
 195
 196    An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
 197
 198       ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
 199           requestName    [0] LDAPOID,
 200           requestValue   [1] OCTET STRING OPTIONAL
 201       }
 202
 203    The requestName of the EndFramedProtocolRequest must be the OID
 204    "2.16.840.1.113719.1.142.100.4".
 205
 206    The requestValue of the EndFramedProtocolRequest is set to the BER-
 207    encoding of a protocol-specific response.
 208
 209 4.4 EndFramedProtocolResponse Extended Operation
 210
 211    The EndFramedProtocolResponse extended operation is sent in response
 212    to an EndFramedProtocolRequest.
 213
 214    An LDAPv3 Extended Response is defined in [LDAPv3] as follows:
 215
 216       ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
 217           COMPONENTS of LDAPResult,
 218           responseName  [10] LDAPOID OPTIONAL,
 219           response      [11] OCTET STRING OPTIONAL
 220       }
 221
 222    The responseName of the EndFramedProtocolResponse must be the OID
 223    "2.16.840.1.113719.1.142.100.5".
 224
 225
 226
 227
 228 Stokes, Harrison and Good                                       [Page 4]
 229 \f
 230 Internet-Draft               LDUP Workgroup               March 10, 2000
 231
 232
 233    The response of the EndFramedProtocolResponse is set to the BER-
 234    encoding of a protocol-specific response.
 235
 236 5. Acknowledgments
 237
 238 The authors gratefully acknowledge the contributions of the IETF LDUP
 239 working group.
 240
 241 6. References
 242
 243
 244 [KEYWORDS]
 245      S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
 246      els", Harvard University, RFC 2119, March 1997.
 247
 248
 249 [ARCHITECTURE]
 250      J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec-
 251      ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999.
 252
 253
 254 [LDAPv3]
 255      M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
 256      (v3)", RFC 2251, December 1997.
 257
 258 7. Author's Addresses
 259
 260    Ellen Stokes
 261    IBM
 262    11400 Burnet Rd
 263    Austin, TX 78758
 264    USA
 265    EMail: stokes@austin.ibm.com
 266    phone: +1 512 838 3725
 267    fax:   +1 512 838 0156
 268
 269    Roger Harrison
 270    Novell, Inc.
 271    122 E. 1700 S.
 272    Provo, UT 84606
 273    USA
 274    EMail: roger_harrison@novell.com
 275    Phone: +1 801 861 2642
 276
 277    Gordon Good
 278    Netscape Communications Corp.
 279    501 E. Middlefield Rd.
 280    Mailstop MV068
 281
 282
 283
 284 Stokes, Harrison and Good                                       [Page 5]
 285 \f
 286 Internet-Draft               LDUP Workgroup               March 10, 2000
 287
 288
 289    Mountain View, CA 94043
 290    USA
 291    EMail:  ggood@netscape.com
 292    Phone:  +1 650 937-3825
 293
 294
 295 Appendix A - Complete ASN.1 Definition
 296
 297 StartFramedProtocolRequest ::= ExtendedRequest
 298
 299 StartFramedProtocolRequestValue ::= SEQUENCE {
 300           framedProtocolOID LDAPOID,
 301           framedProtocolPayload OPTIONAL OCTET STRING
 302 }
 303
 304 StartFramedProtocolResponse ::= ExtendedResponse
 305
 306 EndFramedProtocolRequest ::= ExtendedRequest
 307
 308 EndFramedProtocolResponse ::= ExtendedResponse
 309
 310 Full Copyright Statement
 311
 312 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 313
 314 This document and translations of it may be copied and furnished to oth-
 315 ers, and derivative works that comment on or otherwise explain it or
 316 assist in its implementation may be prepared, copied, published and dis-
 317 tributed, in whole or in part, without restriction of any kind, provided
 318 that the above copyright notice and this paragraph are included on all
 319 such copies and derivative works.  However, this document itself may not
 320 be modified in any way, such as by removing the copyright notice or
 321 references to the Internet Society or other Internet organizations,
 322 except as needed for the purpose of developing Internet standards in
 323 which case the procedures for copyrights defined in the Internet Stan-
 324 dards process must be followed, or as required to translate it into
 325 languages other than English.
 326
 327 The limited permissions granted above are perpetual and will not be
 328 revoked by the Internet Society or its successors or assigns.
 329
 330 This document and the information contained herein is provided on an "AS
 331 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
 332 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
 333 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
 334 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
 335 NESS FOR A PARTICULAR PURPOSE.
 336
 337
 338
 339
 340 Stokes, Harrison and Good                                       [Page 6]