rfc2926.txt

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

      [5].

      ( 1.3.6.1.4.1.6252.2.27.6.1.6
        NAME 'service-advert-url-authenticator'
        DESC 'The authenticator for the URL, null if none.'
        SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
        SINGLE-VALUE
      )

      This attribute contains the SLP URL authenticator, as defined in
      RFC 2608, Section 9.2 [5].



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


      ( 1.3.6.1.4.1.6252.2.27.6.1.7
        NAME 'service-advert-attribute-authenticator'
        DESC 'The authenticator for the attribute list, null if none.'
        SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
        SINGLE_VALUE
      )

      This attribute contains the SLP attribute authenticator, as
      defined in RFC 2608, Section 9.2 [5].

2.1 Mapping from SLP Attribute Types to LDAP Attribute Types

   We define the mapping from SLP attribute types to LDAP as follows:

      SLP Type    ASN.1 Type               LDAP Type
      ---------------------------------------------------
       Integer     INTEGER              INTEGER
       String      DirectoryString      Directory String
       Boolean     BOOLEAN              Boolean
       Opaque      OCTET STRING         Octet String
       Keyword     (N/A)                IA5 String

   The following subsections discuss further details of the mapping.

2.1.1 Integer

   SLP integers compare as integers when performing a query.  LDAP
   integers behave similarly.  Consequently, the mapping from the SLP
   integer type to LDAP is INTEGER, with the integerMatch matching rule.

2.1.2 String

   SLP strings are encoded as described in the SLP protocol
   specification [5].  All value strings are considered case insensitive
   for matching operations.  SLP strings are not null terminated and are
   encoded in UTF-8.

   SLP strings are mapped to the LDAP Directory String type. The
   Directory String type exactly matches the SLP string type, i.e. it is
   a non-null terminated UTF-8 string. The caseIgnoreMatch equality
   rule, caseIgnoreOrderingMatch ordering rule, and
   caseIgnoreSubstringsMatch substring rule are used for comparing
   string attribute values.








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


2.1.3 Boolean

   Boolean attributes may have one of two possible values.  In SLP,
   these values are represented as strings, TRUE and FALSE.  In SLP's
   string encoding of a boolean value, case does not matter.

   The SLP Boolean type maps directly into an LDAP BOOLEAN. The
   caseIgnoreMatch rule is used for equality matching.

2.1.4 Opaque

   SLP attribute values of type Opaque are represented as OCTET STRING
   in LDAP, and the octetStringMatch matching rule is used to compare
   them.

2.2 Keyword Attributes

   SLP service type templates allow the definition of keyword
   attributes.  Keyword attributes are attributes whose only
   characteristic is their presence. Keyword attributes have no flag
   information, nor any default or allowed values (since, by definition,
   they have no values).

   ASN.1 has no concept of keyword attributes. Keyword attributes are
   translated into a "May" clause in the ASN.1 class definition for the
   service type. If the keyword attribute is present, then its value is
   of no consequence, but for consistency we make it simply the NUL
   character, "\00".

2.3 Template Flags

   SLP template flags can be handled as described in the following
   subsections.

2.3.1 Multi-valued

   Multi-valued attributes are defined in an SLP template using the one
   value.  All values for a given attribute must be of the same type.

   LDAP attribute definitions require that a single valued attribute
   include the SINGLE-VALUE tag if the attribute is single valued.
   Otherwise, the attribute is assumed to be multivalued by default.









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


2.3.2 Optional

   SLP uses the 'O' flag to indicate an attribute may or may not be
   present.  These optional attributes are defined using the "May"
   clause in the ASN.1 definition class definition for the service type.
   All other attributes must be defined as a "Must".

2.3.3 Literal

   ASN.1 does not have a mechanism to indicate that the values of an
   attribute may not be translated from one language to another, since
   ASN.1 schema are not typically translated. This flag is dropped when
   translating a template, but presence of the flag should be noted in
   the DESC field. It should be placed on a separate line and tagged
   with "Literal:" so the template can be reconstructed from the schema.

2.3.4 Explicit Matching

   The SLP template syntax uses a flag of 'X' to indicate that an
   attribute must be present in order for the query to be properly
   satisfied.  There is no provision for requiring that particular
   attributes be in a query. Consequently, this flag is dropped when
   translating a template, but presence of the flag should be noted in
   the DESC field. It should be placed on a separate line and tagged
   with "Explicit:" so the template can be reconstructed from the
   schema.

2.4 Default and Allowed Value Lists

   The SLP template grammar provides the capability to define default
   and allowed values for an attribute. The SLP protocol does not
   enforce these restrictions on registered attributes, however.  The
   default and allowed values may be used by client side applications,
   or alternatively it may also be used by DAs to initialize
   registrations having no attributes and to limit attribute values to
   the template allowed values.

   LDAP servers also do not support default and allowed values on
   attributes. Therefore, enforcement of default and allowed values in
   SLP templates is left up to the clients or a DA, if the DA is
   backending into LDAP. The default and allowed values should be
   included in the DESC field. The comments should be placed on separate
   lines and labeled with the "Default:" and "Allowed:" tags to allow
   reconstruction of the template.







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


2.5 Descriptive Text

   The descriptive text associated with an attribute definition should
   be included in the DESC field. It should start on a separate line and
   begin with the "Description:" tag.

2.6 Generating LDAP Attribute OIDs

   LDAP attributes require an OID. In general, there is no a priori way
   that an algorithm can be defined for generating OIDs, because it will
   depend on the conventions used by the organization developing the
   template. In some cases, an organization's procedure for generating
   OIDs may be regular enough that a template developer can
   algorithmically generate OIDs off of an assigned root. Whatever means
   is used, the template developer should assure that unique OIDs are
   assigned to each SLP attribute that is translated into an LDAP
   attribute.

2.7 Example

   The template included below is a hypothetical abstract printer
   service template, similar to that described in [10].

      template-type = printer

      template-version = 0.0

      template-description =
      The printer service template describes the attributes supported by
      network printing devices.  Devices may be either directly
      connected to a network, or connected to a printer spooler that
      understands the a network queuing protocol such as IPP, lpr or the
      Salutation  Architecture.

      template-url-syntax =
      ;The URL syntax is specific to the printing protocol being
      ;employed

      description = STRING
      # This attribute is a free form string that can contain any
      # site-specific descriptive information about this printer.

      printer-security-mechanisms-supported = STRING L M
      none
      # This attribute indicates the security mechanisms supported
      tls, ssl, http-basic, http-digest, none





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


      printer-operator = STRING O L M
      # A person, or persons responsible for maintaining a
      # printer on a day-to-day basis, including such tasks
      # as filling empty media trays, emptying full output
      # trays, replacing toner cartridges, clearing simple
      # paper jams, etc.

      printer-location-address = STRING O
      # Physical/Postal address for this device.  Useful for
      # nailing down a group of printers in a very large corporate
      # network.  For example: 960 Main Street, San Jose, CA 95130

      printer-priority-queue = BOOLEAN O
      FALSE
      # TRUE indicates this printer or print queue is a priority
      # queuing device.

      printer-number-up = INTEGER O
      1
      # This job attribute specifies the number of source
      # page-images to impose upon a single side of an instance
      # of a selected medium.
      1, 2, 4

      printer-paper-output = STRING M L O
      standard
      # This attribute describes the mode in which pages output
      # are arranged.

      standard, noncollated sort, collated sort, stack, unknown

   We assume that the concrete type "service:printer:lpr" for printers
   that speak the LPR protocol [4] has the following template
   definition:

      template-type = printer:lpr

      template-version = 0.0

      template-description =
      The printer:lpr service template describes the attributes
      supported by network printing devices that speak the
      LPR protocol. No new attributes are included.

      template-url-syntax = queue
      queue = ;The queue name, see RFC 1179.





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


   The LDAP class definition for the "service:printer:lpr" concrete
   service type is translated as follows:

   ( ---place the assigned OID here---
     NAME  'service-printer-lpr'
     DESC  'Description: The printer:lpr service template
                 describes the attributes supported by network printing
                 devices that speak the LPR protocol. No new attributes
                 are included.

            URL Syntax: queue
                 queue = ;The queue name, see RFC 1179.'
     SUP   slpService
     MUST  ( description $ security-mechanisms-supported $
     labeledURI)
     MAY   ( operator $ location-address $ priority-queue $
             number-up $ paper-output)
   )

   The attribute definitions are translated as follows:

   ( ---place the assigned OID here---
     NAME 'printer-security-mechanisms-supported'
     DESC 'Description: This attribute indicates the security mechanisms
           supported.

           Default: value

           Allowed: tls, ssl, http-basic, http-digest, none

           Literal:'
     EQUALITY caseIgnoreMatch
     ORDERING caseIgnoreOrderingMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   )

   ( ---place the assigned OID here---
     NAME 'printer-operator'
     DESC 'Description: A person, or persons responsible for
           maintaining a printer on a day-to-day basis, including
           such tasks as filling empty media trays, emptying full
           output trays, replacing toner cartridges, clearing simple
           paper jams, etc.







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


           Literal:'
     EQUALITY caseIgnoreMatch
     ORDERING caseIgnoreOrderingMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   )

   ( --place the assigned OID here---
     NAME 'printer-location-address'
     DESC 'Description Physical/Postal address for this device.
           Useful for nailing down a group of printers in a very
           large corporate network.  For example: 960 Main Street,
           San Jose, CA 95130.'
     EQUALITY caseIgnoreMatch
     ORDERING caseIgnoreOrderingMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
     SINGLE-VALUE
   )

   ( ---place the assigned OID here---
     NAME 'printer-priority-queue'
     DESC 'Description: TRUE indicates this printer or print
          queue is a priority queuing device.'