[Date Prev][Date Next] [Chronological] [Thread] [Top]

Fwd: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt







I don't think the other messages had the attachment.


Please review the attached draft on vendor information to be added to the root DSE.


This document specifies two new attributes, vendorName and vendorVersion, that can be included in the root DSE to contain vendor-specific information.

Any comments can be sent through ietf-ldapext@netscape.com or directly to me mark_meredith@novell.com

Mark Meredith
Novell Inc
122 E. 1700 S. Provo UT 84606
mark_meredith@novell.com
801-861-2645
---------------------
A boat in the harbor is safe,
but that is not what boats are for.
--John A. Shed
---------------------


______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

   Individual Submission to the LDAPExt Working Group         Mark Meredith
   Internet Draft                                               Novell Inc.
   Document: draft-mmeredith-rootdse-vendor-info-00.txt   November 15, 1999


   Category: Proposed Standard

                        LDAP Root DSE Vendor Information

   Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of [RFC2026].

   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 made obsolete 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.
   Comments and suggestions on this document are encouraged.
   Comments on this document should be sent to the LDAPEXT working group
   discussion list ietf-ldapext@netscape.com or the author.

   1. Abstract

   This document specifies two new attributes, vendorName and vendorVersion,
   that can be included in the root DSE to contain vendor-specific
   information.

   2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2219]

   3. Overview

   The root DSE query is the mechanism used by clients to find out what
   controls, extensions, etc. are available from a given LDAP server.

   It is useful to be able to query an LDAP server to determine the vendor
   of that server and see what version of that vendor?s code is currently
   installed. Since vendors can implement "X-" options for attributes,
   classes, and syntaxes ( described in section 4 of [RFC2251] and section 4
   of [RFC2252] ) that may not be published in the root DSE, this would
   allow users or applications to be able to determine if these features are
   available from a given server.


   M. Meredith              Expires May-2000                          1

      LDAP Root DSE vendor information                     November 1999



   It is also possible for vendors to have an LDAP server implementation to
   be incomplete in some respect or to have implementation quirks that must
   be worked around until they can be fixed in the subsequent release. The
   vendorName and vendorVersion attributes allow client developers to
   identify a specific implementation of LDAP and work around any
   shortcomings of that implementation as needed.

   4. Vendor specific information

   This is an addition to the Server-specific Data Requirements defined in
   section 3.4 of [RFC2251] and the associated syntaxes defined in section 4
   of [RFC2252].

   -   vendorName

   All LDAP server implementations SHOULD maintain a vendorName, which is
   generally the name of the company that wrote the LDAP server code, e.g.
   "Novell, Inc."

     ( 2.16.840.1.113719.1.27.4.43 NAME 'vendorName' SYNTAX
     1.3.6.1.4.1.1466.115.121.1.44 NO-USER-MODIFICATION SINGLE-VALUE USAGE
     dSAOperation )

   -   vendorVersion

   All LDAP server implementations SHOULD maintain a vendorVersion, which is
   the release number of the LDAP server product, (as opposed to the
   supportedLDAPVersion which specifies the version of the LDAP protocol
   supported by this server).

      ( 2.16.840.1.113719.1.27.4.44 NAME 'vendorVersion' SYNTAX
      1.3.6.1.4.1.1466.115.121.1.44 NO-USER-MODIFICATION SINGLE-VALUE USAGE
      dSAOperation )

   5. Notes to Implementers

   Implementers may want to consider tying the vendorVersion attribute value
   to the build mechanism so that it is automatically updated when the
   version number changes.

   6. Security Considerations

   The vendorName and vendorVersion attributes are provided only as an aid
   to help client implementers assess what features may or may not exist in
   a given server implementation. Server and application implementers should
   realize that the existence of a given value in the vendorName or
   vendorVersion attribute is no guarantee that the server was actually
   built by the asserted vendor or that its version is the asserted version
   and should act accordingly.

   7. References


   M. Meredith              Expires May-2000                          2

      LDAP Root DSE vendor information                     November 1999


   RFC2219
          Bradner, S., "Key words for use in RFCs to Indicate Requirement
          Levels", BCP 14, RFC 2119, March 1997

   RFC2026
          Bradner, S., "The Internet Standards Process?Revision 3", BCP 9,
          RFC 2026, October 1996.

   RFC2251
          Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
          Protocol (v3)", RFC 2251, December 1997

   RFC2252
          Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight
          Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
          2252, December 1997

   8. Acknowledgments

   The author would like to thank the generous input and review by
   individuals at Novell including but not limited to Jim
   Sermersheim, Mark Hinckley, Renea Campbell, and Roger Harrison.

   9. Author's Addresses

   Mark Meredith
   Novell Inc.
   122 E. 1700 S. Provo, UT 84606
   Phone: +1 801 861 2645
   Email: mark_meredith@novell.com

   Full Copyright Statement
   Copyright (c) The Internet Society (1999). 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 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

   M. Meredith              Expires May-2000                          3

      LDAP Root DSE vendor information                     November 1999


   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-CHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.




















































   M. Meredith              Expires May-2000                          4