rfc2926.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,516 行 · 第 1/4 页

     EQUALITY booleanMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
     SINGLE-VALUE
   )

   ( ---place the assigned OID here---
     NAME 'printer-number-up'
     DESC 'Description: This job attribute specifies the number
           of source page-images to impose upon a single side of
           an instance of a selected medium. This attribute is
           INTEGER.

           Default: 1

           Allowed: 1, 2, 3, 4'
     EQUALITY integerMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
     SINGLE-VALUE
   )








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


   ( ---place the assigned OID here---
     NAME 'printer-paper-output'
     DESC 'Description: This attribute describes the mode in
           which pages output are arranged. Default value is
           standard.

           Default: standard

           Allowed: standard, noncollated sort, collated sort,
             stack, unknown.
           Literal:'
     EQUALITY caseIgnoreMatch
     ORDERING caseIgnoreOrderingMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   )

3.0 Attribute Name Conflicts

   LDAP has a flat name space, and attribute names and OIDs must be
   unique in a directory server. In order to avoid name conflicts in the
   translation of SLP templates to LDAP schemas, template developers may
   want to consider prepending the name of the service type to the
   attribute. Postprocessing attribute names to make them unique when
   translated is not possible, because it would require the DA to
   rewrite queries before submitting them to the directory server. In
   addition, developers should use standard LDAP attributes when such
   attributes are available.

   In the above example template, the abstract type name "printer" is
   prepended to attributes to avoid conflicts. The standard
   "description" attribute defined by X.520 [3] is used to translate the
   template description attribute.

4.0 Mapping from Schema to Templates

   The reverse mapping from LDAP schema to SLP service type templates
   requires dealing with both LDAP and ASN.1 data types.  RFC 2252
   defines 33 attribute syntaxes that should be supported by LDAP
   directory servers.  These syntaxes are defined using BNF for strings
   or using ASN.1 for binary  valued attributes defined by X.520.

   Mapping of the LDAP data types into SLP template types is fairly
   straightforward, but mapping arbitrary ASN.1 data types is somewhat
   more complicated and requires encoding the ASN.1 data type into a
   string. To a certain extent, this masks the ASN.1 data type because
   it becomes impossible to distinguish between a native string having




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


   content equivalent to an encoded ASN.1 string. However, inclusion of
   the ASN.1 data type in the comment provides additional information
   should a reverse transformation from SLP to ASN.1 be required.

   The following subsections deal with both LDAP and ASN.1 attribute
   data type mappings.

4.1 Mapping LDAP Attribute Syntaxes to SLP Attribute Types

   The following table contains the mappings for LDAP syntaxes to SLP
   data types:

         LDAP Type                              SLP Type
      --------------------------------------------------------
         ACI Item                                 NA
         Access Point                             NA
         Attribute Type Description               NA
         Audio                                    Opaque
         Binary                                   ASN.1 escape
         Bit String                               String
         Boolean                                  Boolean
         Certificate                              Opaque
         Certificate List                         Opaque
         Certificate Pair                         Opaque
         Country String                           String
         DN                                       String
         Data Quality Syntax                      NA
         Delivery Method                          NA
         Directory String                         String
         DIT Content Rule Description             NA
         DIT Structure Rule Description           NA
         DL Submit Permission                     NA
         DSA Quality Syntax                       NA
         Enhanced Guide                           NA
         Facsimile Telephone Number               String
         Fax                                      Opaque
         Generalized Time                         String
         Guide                                    NA
         IA5 String                               String
         INTEGER                                  Integer
         JPEG                                     Opaque
         LDAP Syntax Description                  NA
         LDAP Schema Definition                   NA
         LDAP Schema Description                  NA
         Master and Shadow Access Points          NA
         Matching Rule Description                NA
         Matching Rule Use Description            NA
         Mail Preference                          NA



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


         MHS OR Address                           String
         Modify Rights                            NA
         Name and Optional UID                    NA
         Name Form Description                    NA
         Numeric String                           String
         Object Class Description                 NA
         Octet String                             Opaque
         OID                                      String
         Other Mailbox                            String
         Postal Address                           String
         Protocol Information                     NA
         Presentation Address                     String
         Printable String                         String
         Substring Assertion                      NA
         Subtree Specification                    NA
         Supplier Information                     NA
         Supplier or Consumer                     NA
         Supplier And Consumer                    NA
         Supported Algorithm                      NA
         DSE Type                                 NA
         Telephone Number                         String
         Teletex Terminal Identifier              String
         Telex Number                             String
         UTC Time                                 String

4.2 Mapping ASN.1 Types to SLP Types

   ASN.1 employs a much richer set of data types than provided by SLP.
   The table below show the mapping of selected ASN.1 data type to their
   nearest SLP equivalent.  Because of the complexity and flexibility of
   ASN.1, a complete list cannot be provided.

   As sample of some ASN.1 encodings and their mappings to SLP:

      ASN.1 type               SLP type
      -----------------------------------------
      INTEGER                  Integer
      BOOLEAN                  Boolean
      ENUMERATED               String
      OBJECT IDENTIFIER        String
      OCTET STRING             Opaque
      REAL                     String

   Data types that do not map directly to SLP data types should be
   defined as either a String, or as Opaque.  ASN.1 types that may only
   contain valid characters for Strings, as defined in X.680 [9] should
   be encoded as strings.  ASN.1 types such as GraphicString that change
   their character set encoding in part way through a value should not



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


   be encoded as strings, however, If such types are required, the SLP
   Opaque type should be used. In either case, the first line of the
   help text is used to indicate the original ASN.1 data type.

   The following subsections describe how to convert from the ASN.1 BER
   [9] to the SLP template for the different types in the table above.

4.2.1 Integer

   Both SLP templates and ASN.1 support Integers, so there is a one to
   one mapping between an SLP Integer attribute and an ASN.1 Integer
   attribute.  Details on the encoding of integers is summarized in the
   SLP template to ASN.1 section above.

4.2.2 Boolean

   Boolean values are supported by both SLP and ASN.1, though on wire
   encodings differ.  X.680 [9] specifies zero and non-zero encoding for
   booleans, where SLP encodes booleans using the strings TRUE and
   FALSE.  In general, most LDAP servers will use the LDAP Boolean type
   (which is a string), so again the ASN.1 type should be recorded in
   the comment or it will be lost.

4.2.3 Enumerated

   SLP templates support the concept of enumerations through the listing
   of allowed values in the attribute definition.  These enumerations
   are not strictly binding on clients or DAs, but they are similar to
   the ASN.1 definition of enumerations. BER encodes the ASN.1
   enumeration by passing the number of the element's position in the
   enumeration.  This requires both sides to have knowledge of the
   specific enumeration prior to decoding an enumeration's value. SLP
   provides no specific support for transmitting enumerations. They are
   simply String types. Information on the ASN.1 type and ASN.1 encoding
   of the enumeration values is recorded in the comment.

   Example:

   color-supported = STRING   M
   none
   # ASN.1: Enumeration.
   # ASN.1 Mapping: none = 0, highlight = 1, three color = 2,
   #   four color = 4, monochromatic = 5
   #This attribute specifies whether the Printer supports
   # color and, if so, what type.
   none,highlight,three color,four color,monochromatic





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


4.2.4 Object Identifier

   Object identifiers(OIDs) are commonly used in the ASN.1 world to
   identify object and attributes.  OIDs are a numerical representation
   of an element's place in the naming hierarchy. Each element at a
   particular level of a hierarchy has a unique number assigned within
   that level of the hierarchy. A sample OID would be the naming tree
   for SNMP MIBs:  iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would
   be written as the string "1.3.6.1.2.1".

   Because this representation reduces down to a string of dot separated
   numbers, this maps easily to the SLP String type.  The help text for
   this element should indicate it is an ASN.1 OID

      identifier = STRING
      # ASN.1: OID
      # The object identifier for this SNMP agent.

4.2.5 Octet String

   An ASN.1 octet string should be mapped to an Opaque in an SLP
   template.  An octet string is a sequence of bytes, whereas an Opaque
   is a a string that encodes a sequence of bytes. Again, the ASN.1 type
   is lost unless recorded in the comment.

4.2.6 Real

   There is no direct mapping between floating point numbers and any SLP
   data types.  Attributes having the ASN.1 type of Real are mapped to
   SLP type String.  Comments are added to the attribute help text
   indicating the value was originally an ASN.1 real.  For example:

      weight = STRING
      # ASN.1: Real
      # The objects weight in pounds.

4.3 Example ASN.1 Schema

   The following is an example schema for an exported filesystem.  The
   section presents it as in ASN.1 and the following section shows the
   SLP template translation. The template translation does not capture
   the actual attribute format for the Set type, that would be done in
   the LDAP client software making the translation. Note that even
   though the class definition does not conform with the previously
   defined conventions for SLP classes, the schema can still be
   translated into an SLP template.  The syntax used in this example
   follows




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


         -- Abstraction of a fstab entry (a "mount").
         -- These lookups would likely be performed by an
         -- an automounter type application.
         mount   OBJECT-CLASS ::= {
                 SUBCLASS OF { top }
                 MUST CONTAIN { mountHost |
                                mountDirectory |
                                mountType
                              }
                 MAY CONTAIN { mountOption |
                               mountDumpFrequency |
                               mountPassNo
                             }
                 ID { <oid1> }
         }


         - The mount host.
         mountHost       ATTRIBUTE ::= {
                         WITH SYNTAX caseIgnoreString
                         EQUALITY MATCHING RULE caseIgnoreMatch
                         SINGLE VALUE
                         ID { <oid2> }
         }


         - The file system to mount.
         mountDirectory  ATTRIBUTE ::= {
                         WITH SYNTAX caseIgnoreString
                         EQUALITY MATCHING RULE caseIgnoreMatch
                         SINGLE VALUE
                         ID { <oid3> }
         }

         - The type of file system being mounted.
         mountType       ATTRIBUTE ::= {
                         WITH SYNTAX INTEGER { ufs(1),
                                               hsfs(2),
                                               nfs(3),
                                               rfs(4)
                                             }
                         EQUALITY MATCHING RULE integerMatch
                         SINGLE VALUE
                         ID { <oid4> }
         }






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


         - Options for the mount operation.
         mountOption     ATTRIBUTE ::= {
                         WITH SYNTAX caseIgnoreString
                         EQUALITY MATCHING RULE caseIgnoreString
                         ID { <oid5> }
         }


         - How often to dump the file system.
         mountDumpFrequency      ATTRIBUTE :: = {
                                 WITH SYNTAX  INTEGER (0..9)