rfc2926.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,516 行 · 第 1/4 页

Network Working Group                                           J. Kempf
Request for Comments: 2926                        Sun Microsystems, Inc.
Category: Informational                                         R. Moats
                                                            Coreon, Inc.
                                                           P. St. Pierre
                                                  Sun Microsystems, Inc.
                                                          September 2000


          Conversion of LDAP Schemas to and from SLP Templates

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes a procedure for mapping between Service
   Location Protocol (SLP) service advertisements and lightweight
   directory access protocol (LDAP) descriptions of services.  The
   document covers two aspects of the mapping.  One aspect is mapping
   between SLP service type templates and LDAP directory schema.
   Because the SLP service type template grammar is relatively simple,
   mapping from service type templates to LDAP types is straightforward.
   Mapping in the other direction is straightforward if the attributes
   are restricted to use just a few of the syntaxes defined in RFC 2252.
   If arbitrary ASN.1 types occur in the schema, then the mapping is
   more complex and may even be impossible.  The second aspect is
   representation of service information in an LDAP directory.  The
   recommended representation simplifies interoperability with SLP by
   allowing SLP directory agents to backend into LDAP directory servers.
   The resulting system allows service advertisements to propagate
   easily between SLP and LDAP.












Kempf, et al.                Informational                      [Page 1]

RFC 2926               Conversion of LDAP Schemas         September 2000


Table of Contents

   1.0 Introduction ................................................  2
   2.0 Mapping SLP Templates to LDAP Schema ........................  3
     2.1 Mapping from SLP Attribute Types to LDAP Attribute Types ..  8
       2.1.1 Integer ...............................................  8
       2.1.2 String ................................................  8
       2.1.3 Boolean ...............................................  9
       2.1.4 Opaque ................................................  9
     2.2 Keyword Attributes ........................................  9
     2.3 Template Flags ............................................  9
       2.3.1 Multi-valued ..........................................  9
       2.3.2 Optional .............................................. 10
       2.3.3 Literal ............................................... 10
       2.3.4 Explicit Matching ..................................... 10
     2.4 Default and Allowed Value Lists ........................... 10
     2.5 Descriptive Text .......................................... 11
     2.6 Generating LDAP Attribute OIDs ............................ 11
     2.7 Example ................................................... 11
   3.0 Attribute Name Conflicts .................................... 15
   4.0 Mapping from Schema to Templates ............................ 15
     4.1 Mapping LDAP Attribute Types to SLP Attribute Types ....... 16
     4.2 Mapping ASN.1 Types to SLP Types .......................... 17
       4.2.1 Integer ............................................... 18
       4.2.2 Boolean ............................................... 18
       4.2.3 Enumerated ............................................ 18
       4.2.4 Object Identifier ..................................... 19
       4.2.5 Octet String .......................................... 19
       4.2.6 Real .................................................. 19
     4.3 Example ASN.1 Schema ...................................... 19
   5.0 Representing SLP Service Advertisements in an LDAP DIT ...... 22
   6.0 Internationalization Considerations ......................... 24
   7.0 Security Considerations ..................................... 24
   8.0 References .................................................. 25
   9.0 Authors' Addresses .......................................... 26
   10.0 Full Copyright Statement ................................... 27

1.0 Introduction

   SLP templates [1] are intended to create a simple encoding of the
   syntactic and semantic conventions for individual service types,
   their attributes, and conventions.  They can easily be generated,
   transmitted, read by humans and parsed by programs, as it is a string
   based syntax with required comments.  Directory schemas serve to
   formalize directory entry structures for use with LDAP [2] These
   directories serve to store information about many types of entities.
   Network services are an example of one such entity.




Kempf, et al.                Informational                      [Page 2]

RFC 2926               Conversion of LDAP Schemas         September 2000


   Interoperability between SLP and LDAP is important so clients using
   one protocol derive benefit from services registered through the
   other. In addition, LDAP directory servers can serve as the backend
   for SLP directory agents (DAs) if interoperability is possible In
   order to facilitate interoperability, this document creates mappings
   between the SLP template grammar and LDAP directory schema, and
   establishes some conventions for representing service advertisements
   in LDAP directories. The goal of the translation is to allow SLPv2
   queries (which are syntactically and semantically equivalent to
   LDAPv3 string queries [7]) to be submitted to an LDAP directory
   server by an SLP DA backended into LDAP without extensive processing
   by the DA.

   The simple notation and syntactic/semantic attribute capabilities of
   SLP templates map easily into directory schemas, and are easily
   converted into directory schemas, even by automated means.  The
   reverse may not be true. If the LDAP schema contains attributes with
   unrecognized or complex syntaxes, the translation may be difficult or
   impossible.  If, however, the LDAP schema only uses a few of the
   common syntaxes defined in RFC 2252 [8], then the translation is more
   straightforward. In addition, to foster complete bidirectionality,
   the mapping must follow a very specific representation in its DESC
   attributes.

   This document outlines the correct mappings for SLP templates into
   the syntactic representation specified for LDAP directory schema by
   RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in
   the X.209 specification [9], and is used by the LDAPv3 [2] directory
   schema.  Likewise, rules and guidelines are proposed to facilitate
   consistent mapping of ASN.1 based schemas to be translated in the SLP
   template grammar. Finally, a proposal for a representation of service
   advertisements in LDAP directory services is made that facilitates
   SLP interoperability.

   Except when used as elements in the definition of LDAP schemas, 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 RFC 2119 [16].

2.0 Mapping SLP Templates to LDAP Schema

   We define the following abstract object class as the parent class for
   all services.  Any specific service type is a subclass of this, with
   its own attributes:







Kempf, et al.                Informational                      [Page 3]

RFC 2926               Conversion of LDAP Schemas         September 2000


      ( 1.3.6.1.4.1.6252.2.27.6.2.1
        NAME 'slpService'
        DESC 'parent superclass for SLP services'
        ABSTRACT
        SUP top
        MUST  ( template-major-version-number $
                template-minor-version-number $
                description $
                template-url-syntax $
                service-advert-service-type $
                service-advert-scopes )
        MAY   ( service-advert-url-authenticator $
                service-advert-attribute-authenticator ) )

   The attributes correspond to various parts of the SLP service
   template and SLP service advertisement.

   SLP service type templates begin with four definitions that set the
   context of the template:

      template-type - This defines the service type of the template. The
      service type can be a simple service type, like "service:ftp", an
      abstract service type, like "service:printer" or a concrete
      service type, like "service:printer:lpr". The type name can
      additionally include a naming authority, for example
      "service:printer.sun:local".  The name that appears in this field
      omits the "service:" prefix.

      template-version - A string containing a major and minor version
      number, separated by a period.

      template-description - A block of human readable text describing
      what the service type does.

      template-url-syntax - An ABNF [6] grammar describing the service
      type specific part of the service URL.

   The SLP template-type definition is used as the name of the LDAP
   object class for the template, a subclass of the "slpService" class,
   together with the "service" prefix to indicate that the name is for a
   service. In the translating service type name, colons and the period
   separating the naming authority are converted into hyphens. If the
   template defines an SLP concrete type, the concrete type name is
   used; the abstract type name is never used.  For example, the
   template for "service:printer:lpr" is translated into an LDAP object
   class called "service-printer-lpr". Furthermore, if the type name
   contains a naming authority, the naming authority name must be




Kempf, et al.                Informational                      [Page 4]

RFC 2926               Conversion of LDAP Schemas         September 2000


   included. For example, the service type name
   "service:printer.sun:local" becomes "service-printer-sun-local".  The
   LDAP object class is always "STRUCTURAL".

   The template-version definition is partitioned into two attributes,
   template-major-version-number and template-minor-version-number. The
   LDAP definition for these attributes is:

      ( 1.3.6.1.4.1.6252.2.27.6.1.1
        NAME 'template-major-version-number'
        DESC 'The major version number of the service type template'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
      )

      ( 1.3.6.1.4.1.6252.2.27.6.1.2
        NAME 'template-minor-version-number'
        DESC 'The minor version number of the service type template'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
      )

   The template-url-syntax definition in the SLP template is described
   by the following attribute:

      ( 1.3.6.1.4.1.6252.2.27.6.1.3
        NAME 'template-url-syntax'
        DESC 'An ABNF grammar describing the service type
              specific part of the service URL'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
        SINGLE-VALUE
      )

   The template-description attribute is translated into the X.520
   standard attribute "description" [3].

   We further establish the convention that SLP template characteristics
   that can't be translated into LDAP are inserted into the DESC field
   of the object class definition. The items are separated by empty
   lines (consisting of two "LINE FEED" characters), are preceded by a
   LINE FEED character, and are tagged at the  beginning of the line to
   indicate what they represent.   This allows the template to be
   reconstructed from the schema by properly parsing the comments.





Kempf, et al.                Informational                      [Page 5]

RFC 2926               Conversion of LDAP Schemas         September 2000


   The bulk of an SLP template consists of attribute definitions.  There
   are four items in an SLP template attribute definition that need to
   be mapped into LDAP:

      Attribute Name - Since SLPv2 attribute names are defined to be
      compatible with LDAPv3, SLP attributes map directly into LDAP
      attributes with no change. Similarly, LDAP attributes map directly
      to SLP attributes.

      Attribute Type - The SLP attribute type is mapped into the LDAP
      attribute type.

      Attribute Flags - The SLP attribute flags are mapped into
      characteristics of the LDAP attribute definition, or into the DESC
      field if no equivalent LDAP attribute definition characteristic
      occurs.

      Default and Allowed Values - These must be handled by the client
      or a DA enabled to handle templates, as in SLP. For reference,
      however, they should be included in the DESC field of the LDAP
      attribute definition.

      Descriptive Text - The SLP template descriptive text should be
      mapped into the DESC field.

   We discuss mapping of types, flags, default and allowed values, and
   descriptive text in the subsections below.

   OIDs for SLP template conversion schema elements are standardized
   under the enterprise number of SrvLoc.Org (6252) [18].

   For purposes of representing an SLP entry, we also define two
   standardized LDAP syntaxes and attributes with standardized OIDs.

      ( 1.3.6.1.4.1.6252.2.27.6.2.2
        DESC 'SLP Service Type'
      )

   Defines the syntax for the service type name. The syntax is defined
   in the BNF for the service URL in RFC 2609 Section 2.1 [1].

      ( 1.3.6.1.4.1.6252.2.27.6.2.3
        DESC 'SLP Scope'
      )

   Defines the syntax for the scope name. The syntax is defined in the
   BNF for scope names in RFC 2608 Section 6.4.1 [5].




Kempf, et al.                Informational                      [Page 6]

RFC 2926               Conversion of LDAP Schemas         September 2000


      ( 1.3.6.1.4.1.6252.2.27.6.1.4
        NAME 'service-advert-service-type'
        DESC 'The service type of the service advertisement, including
              the "service:" prefix.'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.2
        SINGLE-VALUE
      )

   Defines an attribute for the service type name.

      ( 1.3.6.1.4.1.6252.2.27.6.1.5
        NAME 'service-advert-scopes'
        DESC 'A list of scopes for a service advertisement.'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
      )

   Defines a multivalued attribute for the scopes.

   Searches for abstract types can be made with an LDAP query that
   wildcards the concrete type. For example, a search for all service
   advertisements of the printer abstract type can be made with the
   following query:

         (service-advert-service-type=service:printer:*)

   SLP specifies that service URLs and attribute lists can be
   accompanied by a structured authenticator consisting of a digital
   signature and information necessary to verify the signature.  A
   syntax and two standardized SLP attributes are defined for this
   purpose:

      ( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator')

      The syntax of an SLP authenticator is the bytes of the
      authenticator in network byte order, see RFC 2608, Section 9.2