Update drafts to latest revs

doc/drafts/draft-zeilenga-ldap-cancel-xx.txt

+
+
+
+
+
+
+INTERNET-DRAFT                                      Kurt D. Zeilenga
+Intended Category: Standard Track                OpenLDAP Foundation
+Expires: 1 October 2001                                 1 April 2001
+
+
+                      LDAP Cancel Extended Operation
+                   <draft-zeilenga-ldap-cancel-03.txt>
+
+
+1.      Status of this Memo
+
+  This document is an Internet-Draft and is in full conformance with all
+  provisions of Section 10 of RFC2026.
+
+  This document is intended to be, after appropriate review and
+  revision, submitted to the RFC Editor as a Standard Track document.
+  Distribution of this memo is unlimited.  Technical discussion of this
+  document will take place on the IETF LDAP Extension Working Group
+  mailing list <ietf-ldapext@netscape.com>.  Please send editorial
+  comments directly to the author <Kurt@OpenLDAP.org>.
+
+  Internet-Drafts are working documents of the Internet Engineering Task
+  Force (IETF), its areas, and its working groups.  Note that other
+  groups may also distribute working documents as Internet-Drafts.
+  Internet-Drafts are draft documents valid for a maximum of six months
+  and may be updated, replaced, or obsoleted by other documents at any
+  time.  It is inappropriate to use Internet-Drafts as reference
+  material or to cite them other than as ``work in progress.''
+
+  The list of current Internet-Drafts can be accessed at
+  http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
+  Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
+
+  Copyright 2001, The Internet Society.  All Rights Reserved.
+
+  Please see the Copyright section near the end of this document for
+  more information.
+
+
+2.      Abstract
+
+  This specification describes an extended operation to cancel (or
+  abandon) an outstanding operation.   Unlike the LDAP Abandon operation
+  [RFC2251] but like the DAP Abandon operation [X.511], this operation
+  has a response which provides an indication of its outcome.
+
+  The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
+  NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'',  and ``MAY'' in
+
+
+
+Zeilenga                       LDAP Cancel                      [Page 1]
+
+INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
+
+
+  this document are to be interpreted as described in RFC 2119
+  [RFC2119].
+
+
+3.      Background and Intent of Use
+
+  LDAP provides an Abandon operation which clients may use to cancel
+  other operations.  The Abandon operation does not have a response and
+  also calls for there to be no response of the abandoned operation.
+  These semantics provide the client with no clear indication of the
+  outcome of the Abandon operation.
+
+  DAP provides an Abandon operation which does have a response and also
+  requires the abandoned operation to return a response with indicating
+  it was canceled.  The Cancel operation is modeled after the DAP
+  Abandon operation.
+
+  The Cancel operation is intended to be used instead of the LDAP
+  Abandon operation.  This operation may be used to cancel both
+  interrogation and update operations.
+
+
+4.      Cancel Operation
+
+  The Cancel operation is defined as a LDAPv3 Extended Operation
+  [RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
+  This section details the syntax of the Cancel request and response
+  messages and defines additional LDAP resultCodes.
+
+      cancelOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.2
+
+      cancelRequestValue ::= SEQUENCE {
+          cancelID        MessageID
+      }
+
+
+4.1.    Cancel Request
+
+  The Cancel request is an ExtendedRequest with the requestName field
+  containing cancelOID OID and a requestValue field which contains a
+  cancelRequestValue value encoded per [RFC2251, Section 5.1].  The
+  cancelID field contains the message id associated with the operation
+  to be canceled.
+
+
+4.2.    Cancel Response
+
+  A Cancel response is an ExtendedResponse where the responseName and
+
+
+
+Zeilenga                       LDAP Cancel                      [Page 2]
+
+INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
+
+
+  response fields are absent.
+
+
+4.3.    Additional Result Codes
+
+  Implementations of this specification SHALL recognize the following
+  additional resultCode values:
+
+      canceled        (72)
+      noSuchOperation (73)
+      tooLate         (74)
+      cannotCancel    (75)
+
+
+5.      Operational Semantics
+
+  The function of the Cancel Operation is to request that the server
+  cancel an outstanding operation issued within the same session.
+
+  The client requests the cancelation of an outstanding operation by
+  issuing a Cancel Response with a cancelID with the message id
+  identifying the outstanding operation.  The Cancel Request itself has
+  a distinct message id.  Clients SHOULD NOT request cancelation of an
+  operation multiple times.
+
+  If the server is unable to parse the requestValue or the requestValue
+  is absent, the server shall return protocolError.
+
+  If the server is willing and able to cancel the outstanding operation
+  identified by the cancelId, the server SHALL return a Cancel Response
+  with a success resultCode and the canceled operation SHALL fail with
+  canceled resultCode.  Otherwise the Cancel Response SHALL have a
+  non-success resultCode and SHALL NOT have impact upon the outstanding
+  operation (if it exists).
+
+  The server SHALL return noSuchOperation if it has no knowledge of the
+  operation requested to be canceled.
+
+  The server SHALL return cannotCancel if the identified operation does
+  not support cancelation or the cancel operation could not be
+  performed.  The following classes of operations are not cancelable:
+
+    - operations which have no response,
+
+    - operations which associate or disassociate authentication and/or
+      authorization associations,
+
+    - operations which establish or tear-down security services, and
+
+
+
+Zeilenga                       LDAP Cancel                      [Page 3]
+
+INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
+
+
+    - operations which abandon or cancel other operations.
+
+  Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
+  operations are not cancelable.
+
+  If the result of the outstanding operation has been determined by the
+  server, the outstanding operation SHALL NOT be canceled and the cancel
+  operation SHALL result in tooLate.
+
+  Servers SHOULD indicate their support for this extended operation by
+  providing cancelOID as a value of the supportedExtension attribute
+  type in their root DSE.  A server MAY choose to advertise this
+  extension only when the client is authorized and/or has established
+  the necessary security protections to use this operation.  Clients
+  SHOULD verify the server implements this extended operation prior to
+  attempting the operation by asserting the supportedExtension attribute
+  contains a value of cancelOID.
+
+
+6.      Security Considerations
+
+  This operation is intended to allow a user to cancel operations they
+  previously issued.  No user should be allowed to cancel an operation
+  issued by another user (within the same session or not).  However, as
+  this operation may only be used to cancel within the same session and
+  LDAP requires operations to be abandoned upon bind requests, this is a
+  non-issue.
+
+  Some operations should not be cancelable for security reasons.  This
+  specification disallows cancelation of Bind operation and Start TLS
+  extended operation so as to avoid adding complexity to authentication,
+  authorization, and security layer semantics.  Designers of future
+  extended operations and/or controls SHOULD disallow abandonment and
+  cancelation when appropriate.
+
+
+7.      Copyright
+
+  Copyright 2001, The Internet Society.  All Rights Reserved.
+
+  This document and translations of it may be copied and furnished to
+  others, and derivative works that comment on or otherwise explain it
+  or assist in its implementation may be prepared, copied, published and
+  distributed, in whole or in part, without restriction of any kind,
+  provided that the above copyright notice and this paragraph are
+  included on all such copies and derivative works.  However, this
+  document itself may not be modified in any way, such as by removing
+  the copyright notice or references to the Internet Society or other
+
+
+
+Zeilenga                       LDAP Cancel                      [Page 4]
+
+INTERNET-DRAFT        draft-zeilenga-ldap-cancel-03         1 April 2001
+
+
+  Internet organizations, except as needed for the  purpose of
+  developing Internet standards in which case the procedures for
+  copyrights defined in the Internet Standards process must be followed,
+  or as required to translate it into languages other than English.
+
+  The limited permissions granted above are perpetual and will not be
+  revoked by the Internet Society or its successors or assigns.
+
+  This document and the information contained herein is provided on an
+  "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
+  ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
+  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+8.      Bibliography
+
+  [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
+            Requirement Levels", RFC 2119, March 1997.
+
+  [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+            Protocol (v3)", RFC 2251, December 1997.
+
+  [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
+            Access Protocol (v3): Extension for Transport Layer
+            Security", RFC 2830, May 2000.
+
+  [X.511]   ITU-T Rec. X.511, "The Directory: Abstract Service
+            Definition", 1993. (not normative)
+
+
+9.     Acknowledgment
+
+  This document is based upon input from the IETF LDAPext working group.
+
+
+10.     Author's Address
+
+  Kurt D. Zeilenga
+  OpenLDAP Foundation
+  <Kurt@OpenLDAP.org>
+
+
+
+
+
+
+
+
+
+Zeilenga                       LDAP Cancel                      [Page 5]
+

doc/drafts/draft-zeilenga-ldap-features-xx.txt

+
+
+
+
+
+
+INTERNET-DRAFT                                      Kurt D. Zeilenga
+Intended Category: Standard Track                   OpenLDAP Foundation
+Expires: 26 December 2001                           26 June 2001
+
+
+                        Feature Discovery in LDAP
+                  <draft-zeilenga-ldap-features-01.txt>
+
+
+Status of this Memo
+
+  This document is an Internet-Draft and is in full conformance with all
+  provisions of Section 10 of RFC2026.
+
+  This document is intended to be, after appropriate review and
+  revision, submitted to the RFC Editor as an Standard Track document.
+  Distribution of this memo is unlimited.  Technical discussion of this
+  document will take place on the IETF LDAP Extension Working Group
+  mailing list <ietf-ldapext@netscape.com>.  Please send editorial
+  comments directly to the author <Kurt@OpenLDAP.org>.
+
+  Internet-Drafts are working documents of the Internet Engineering Task
+  Force (IETF), its areas, and its working groups.  Note that other
+  groups may also distribute working documents as Internet-Drafts.
+  Internet-Drafts are draft documents valid for a maximum of six months
+  and may be updated, replaced, or obsoleted by other documents at any
+  time.  It is inappropriate to use Internet-Drafts as reference
+  material or to cite them other than as ``work in progress.''
+
+  The list of current Internet-Drafts can be accessed at
+  <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+  Internet-Draft Shadow Directories can be accessed at
+  <http://www.ietf.org/shadow.html>.
+
+  Copyright 2001, The Internet Society.  All Rights Reserved.
+
+  Please see the Copyright section near the end of this document for
+  more information.
+
+
+1. Overview
+
+  LDAP [RFC2251] is an extensible protocol with numerous elective
+  features.  LDAP provides mechanisms for a client to discover supported
+  protocol versions, controls, extended operations, SASL mechanisms, and
+  subschema information.  However, these mechanisms are not designed to
+  support general feature discovery.
+
+
+
+
+Zeilenga             draft-zeilenga-ldap-features-01            [Page 1]
+
+INTERNET-DRAFT           LDAP supportedFeatures             26 June 2001
+
+
+  This document describes a simple, general-purpose mechanism which
+  clients may use to discovery the set of features supported by a
+  server.
+
+  The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
+  NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'',  and ``MAY'' in
+  this document are to be interpreted as described in RFC 2119
+  [RFC2119].
+
+
+2. Discovery of supported features
+
+  Each feature whose support may be discovered SHALL be identified by an
+  Object Identifier (OID).  A server advertises its support for a given
+  feature by providing the OID associated with the feature as a value of
+  the supportedFeatures attribute held in the root DSE.  A client may
+  examine the values of this attribute to determine if a particular
+  feature is supported by the server.
+
+  The supportedFeatures attribute type is described [RFC2252] as
+  follows:
+
+      ( 1.3.6.1.4.1.4203.1.3.5
+        NAME 'supportedFeatures'
+        DESC 'features supported by the server'
+        EQUALITY objectIdentifierMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+        USAGE dSAOperation )
+
+
+3. Security Considerations
+
+  As rogue clients can discover features of a server by other means
+  (such as by trial and error), this feature discovery mechanism is not
+  believed to introduce any new security risk to LDAP.
+
+
+4. Acknowledgment
+
+  This document is based upon input from the IETF LDAPext working group.
+
+
+5. Author's Address
+
+  Kurt D. Zeilenga
+  OpenLDAP Foundation
+  <Kurt@OpenLDAP.org>
+
+
+
+
+Zeilenga             draft-zeilenga-ldap-features-01            [Page 2]
+
+INTERNET-DRAFT           LDAP supportedFeatures             26 June 2001
+
+
+References
+
+  [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
+            Requirement Levels", RFC 2119, March 1997.
+
+  [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+            Protocol (v3)", RFC 2251, December 1997.
+
+  [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
+            Directory Access Protocol (v3):  Attribute Syntax
+            Definitions", RFC 2252, December 1997.
+
+
+Full Copyright
+
+  Copyright 2001, The Internet Society.  All Rights Reserved.
+
+  This document and translations of it may be copied and furnished to
+  others, and derivative works that comment on or otherwise explain it
+  or assist in its implementation may be prepared, copied, published and
+  distributed, in whole or in part, without restriction of any kind,
+  provided that the above copyright notice and this paragraph are
+  included on all such copies and derivative works.  However, this
+  document itself may not be modified in any way, such as by removing
+  the copyright notice or references to the Internet Society or other
+  Internet organizations, except as needed for the  purpose of
+  developing Internet standards in which case the procedures for
+  copyrights defined in the Internet Standards process must be followed,
+  or as required to translate it into languages other than English.
+
+  The limited permissions granted above are perpetual and will not be
+  revoked by the Internet Society or its successors or assigns.
+
+  This document and the information contained herein is provided on an
+  "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
+  ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
+  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga             draft-zeilenga-ldap-features-01            [Page 3]
+

doc/drafts/draft-zeilenga-ldap-opattrs-xx.txt

+
+
+
+
+
+
+INTERNET-DRAFT                                      Kurt D. Zeilenga
+Intended Category: Standard Track                   OpenLDAP Foundation
+Expires: 26 December 2001                           26 June 2001
+
+
+
+                    LDAPv3: All Operational Attributes
+                   <draft-zeilenga-ldap-opattrs-01.txt>
+
+
+Status of this Memo
+
+  This document is an Internet-Draft and is in full conformance with all
+  provisions of Section 10 of RFC2026.
+
+  This document is intended to be, after appropriate review and
+  revision, submitted to the RFC Editor as a Standard Track document.
+  Distribution of this memo is unlimited.  Technical discussion of this
+  document will take place on the IETF LDAP Extensions Working Group
+  mailing list <ietf-ldapext@netscape.com>.  Please send editorial
+  comments directly to the author <Kurt@OpenLDAP.org>.
+
+  Internet-Drafts are working documents of the Internet Engineering Task
+  Force (IETF), its areas, and its working groups.  Note that other
+  groups may also distribute working documents as Internet-Drafts.
+  Internet-Drafts are draft documents valid for a maximum of six months
+  and may be updated, replaced, or obsoleted by other documents at any
+  time.  It is inappropriate to use Internet-Drafts as reference
+  material or to cite them other than as ``work in progress.''
+
+  The list of current Internet-Drafts can be accessed at
+  <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+  Internet-Draft Shadow Directories can be accessed at
+  <http://www.ietf.org/shadow.html>.
+
+  Copyright 2001, The Internet Society.  All Rights Reserved.
+
+  Please see the Copyright section near the end of this document for
+  more information.
+
+
+1.  Overview
+
+  X.500 [X.500] provides a mechanism for clients to request all
+  operational attributes be returned with entries provided in response
+  to a search operation.   This mechanism is often used by clients to
+  discover which operational attributes are present in an entry.
+
+
+
+
+Zeilenga                    LDAP All Op Attrs                   [Page 1]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-opattrs-01         26 June 2001
+
+
+  This documents updates LDAP [RFC2251] to provide a simple mechanism
+  which clients may use to request the return of all operation
+  attributes.  The mechanism is designed for use with existing general
+  purpose LDAP clients (including web browsers which support LDAP URLs)
+  and existing LDAP API.
+
+  The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
+  NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'',  and ``MAY'' in
+  this document are to be interpreted as described in RFC 2119
+  [RFC2119].
+
+
+2.  All Operational Attributes
+
+  The presence of the attribute description "+" (ASCII 43) in the list
+  of attributes in a Search Request SHALL signify a request for the
+  return of all operational attributes.
+
+  As with all search requests, client implementors should note that
+  results may not include all requested attributes due to access
+  controls or other restrictions.  Clients implementors should also note
+  that certain operational attributes may be returned only if requested
+  by name even when "+" is present.  This is because some operational
+  attributes are very expensive to return.
+
+  Servers supporting this feature SHOULD publish the Object Identifier
+  1.3.6.1.4.1.4203.1.5.1 as a value of supportedFeatures [FEATURES]
+  attribute in the root DSE.
+
+
+3.  Interoperability Considerations
+
+  This mechanism is specifically designed to allow users to request all
+  operational attributes using existing LDAP clients.  In particular,
+  the mechanism is designed to be compatible with existing general
+  purpose LDAP clients includes web browsers which support LDAP URLs
+  [RFC2255].
+
+  The addition of this mechanism to LDAPv3 is believed not to cause any
+  significant interoperability issues (this has been confirmed through
+  testing).   Servers which have yet to implement this specification
+  should ignore the "+" as an unrecognized attribute description per
+  [RFC2251, Section 4.5.1].  From the client's perspective, a server
+  which does not return all operational attributes when "+" is requested
+  should be viewed as having other restrictions.
+
+  It is also noted that this mechanism is believed to require no
+  modification of existing LDAP APIs.
+
+
+
+Zeilenga                    LDAP All Op Attrs                   [Page 2]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-opattrs-01         26 June 2001
+
+
+4.  Security Considerations
+
+  This document provides a mechanism which clients may use to discover
+  operational attributes.  Those relying on security by obscurity SHOULD
+  implement appropriate access controls to restricts access to
+  operational attributes per local policy.
+
+
+5.  Acknowledgment
+
+  The "+" mechanism is believed to have been first suggested by Bruce
+  Greenblatt in a November 1998 post to the IETF LDAPext Working Group
+  mailing list.
+
+
+7.  Author's Address
+
+  Kurt D. Zeilenga
+  OpenLDAP Foundation
+  <Kurt@OpenLDAP.org>
+
+
+References
+
+  [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
+            Requirement Levels", RFC 2119, March 1997.
+
+  [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+            Protocol (v3)", RFC 2251, December 1997.
+
+  [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
+            December 1997.
+
+  [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
+            ldap-features-xx.txt (a work in progress).
+
+  [X.500]   ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+            Models and Service",  1993.
+
+
+Copyright 2001, The Internet Society.  All Rights Reserved.
+
+            This document and translations of it may be copied and
+            furnished to others, and derivative works that comment on or
+            otherwise explain it or assist in its implementation may be
+            prepared, copied, published and distributed, in whole or in
+            part, without restriction of any kind, provided that the
+            above copyright notice and this paragraph are included on
+
+
+
+Zeilenga                    LDAP All Op Attrs                   [Page 3]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-opattrs-01         26 June 2001
+
+
+            all such copies and derivative works.  However, this
+            document itself may not be modified in any way, such as by
+            removing the copyright notice or references to the Internet
+            Society or other Internet organizations, except as needed
+            for the  purpose of developing Internet standards in which
+            case the procedures for copyrights defined in the Internet
+            Standards process must be followed, or as required to
+            translate it into languages other than English.
+
+            The limited permissions granted above are perpetual and will
+            not be revoked by the Internet Society or its successors or
+            assigns.
+
+            This document and the information contained herein is
+            provided on an "AS IS" basis and THE AUTHORS, THE INTERNET
+            SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS
+            ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+            LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+            HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+            WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
+            PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    LDAP All Op Attrs                   [Page 4]
+