rfc2926.txt

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

                                 EQUALITY MATCHING RULE integerMatch
                                 SINGLE VALUE
                                 ID { <oid6> }
         }

         - Boot time mount pass number.
         mountPassNo     ATTRIBUTE ::= {
                         WITH SYNTAX INTEGER
                         EQUALITY MATCHING RULE integerMatch
                         SINGLE VALUE
                         ID { <oid7> }
         }

   The translated SLP template is:

      template-type = mount

      template-version = 1.0

      template-description = "Describes a remote filesystem access
      protocol"

      template-url-syntax =
                   filesystem   = 1*[ DIGIT / ALPHA ]
                   urlpath = "/" filesystem

      mountHost = STRING L
      # ASN.1: Case Ignore String, Single Value
      # The mount host

      mountDirectory = STRING L
      # ASN.1: Case Ignore String, Single Value
      # The filesystem to mount







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


      mountType = STRING L
      ufs
      # ASN.1: Enumeration, Single Value
      # ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4
      # The type of the filesystem being mounted
      ufs, hsfs, nfs, rfs

      mountOption = STRING M O L
      # ASN.1: Case Ignore String
      # mount options for this filesystem

      mountDumpFrequency = INTEGER O
      0
      # ASN.1: Integer Range, Single Value
      # How often to dump this filesystem
      0, 1, 2, 3, 4, 5, 6, 7, 8, 9

      mountPassNo = INTEGER O
      # ASN.1: Integer, Single Value
      # Boot time mount pass number

5.0 Representing SLP Service Advertisements in an LDAP DIT

   In addition to translating between SLP templates and LDAP schema,
   another area requiring compatibility is the representation of SLP
   service advertisements in an LDAP DIT. A standardized representation
   for service information allows SLP DAs to store service
   advertisements in LDAP, and for LDAP clients to query the DIT for
   those services.  Similarly, if LDAP clients represent service
   information in the same form, SLP clients can benefit from
   interoperability.

   A service advertisement contains the service URL in a 'labeledURI'
   attribute [11]. The labeledURI attribute in a service advertisement
   should only contain the service URL for the service, with no
   additional label. It is recommended that the labeledURI be used as
   the RDN for the service object in the DIT.

   Although service advertisements can appear anywhere within the DIT,
   it is recommended that all services be stored under a single common
   point, or root node, to facilitate searching in a domain. This allows
   a  client to search for all of advertisements of a particular service
   type, say, for all printers.  The recommended parent entry is one
   named "ou=service" below the entry which is the representation of the
   domain, as described in RFC 2247.






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


   For example, a printer service with labeledURI of
   "service:lpr://printsrv/queue1" in the domain foobar.com advertised
   in the LDAP server that holds the entry "dc=foobar,dc=com" tree has
   the following DN:

   "labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar,
   dc=com"

   While this leads to a flat space of service storage, since SLP uses
   search filters from LDAP for searches, these filters can be used for
   one-level searches from the root node.

   The following example illustrates how an advertisement having a
   simple service type is represented. The advertisement (in conceptual
   form) for a printer is:

      Service Type: service:lpr://printsrv/queue1
      Scopes: eng,corp
      Attributes:
        description = A general printer for all to use.
        security-mechanisms-supported = none
      Authentication: none

   The RDN of the object is labeledURI=service:lpr://printsrv/queue1,
   and the following LDAP search filter will return this object, along
   with any others of the service type "service:lpr" that match the
   other attributes:

      (&(service-advert-service-type=service:lpr)
        (service-advert-scopes=eng)
        (service-advert-scopes=corp)
        (description=A general printer for all to use.)
        (security-mechanisms-supported=none))

   Service advertisements in SLP also have a lease time associated with
   them. In LDAP servers that support the extensions for dynamic
   directory services [12], the service advertisement entry objectClass
   should be extended with the dynamicObject class. This allows the
   service advertisement to time out within the LDAP directory server.
   If the LDAP directory server does not support the dynamic directory
   services extension, then advertisement lease timeouts must be handled
   by the SLP agent.

   While the service advertisement schema outlined in this section is
   primarily for SLP DAs that use LDAP as a backing store, if LDAP
   agents register services using the same format, complete
   interoperability with SLP is achieved.




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


6.0 Internationalization Considerations

   SLP specifies that an RFC 1766 [13] language code accompanies every
   service advertisement. Language codes for service advertisements in
   LDAP must be represented according to RFC 2596 [14].

   RFC 2596 prohibits language codes in DNs, and specifies that a
   directory server which does not support language codes must treat an
   attribute with a language code as an unrecognized attributes.
   According to RFC 2596, language codes are appended to attribute names
   with a semicolon (";"). For example, the following attribute/value
   pair is in the German locale:

      (address;lang-de=44 Bahnhofstrasse, 2365 Weibstadt, Deutschland)

   An attribute with a language tag in a specific locale is considered a
   separate attribute from attributes in other locales.

   If the service advertisement is in the default SLP locale ("en", no
   dialect), then the language code need not be appended to the
   attribute name.

   SLP queries in locales other than the default need not be rewritten
   to include language tags before being submitted to the directory
   server.  RFC 2596 specifies that all entries that match are returned,
   including those with language tags, without requiring the language
   tags to be explicitly present in the query. The SLP DA can then
   postprocess the result to select the entries from the required
   locale.

7.0 Security Considerations

   SLP authenticators are stored with the service advertisement in the
   DIT, as discussed in Section~7ef{slpdit}. LDAP clients need to use
   LDAP authentication [15] to assure that they are connecting with a
   secure server. In particular, SLP DAs that use LDAP as a back end
   store and that implement SLP authentication MUST use LDAP
   authentication to assure that the LDAP entries for their service
   registrations are secure.

Acknowledgements

   Many thanks are due to Mark Wahl whose detailed and insightful
   comments were instrumental in helping improve the technical accuracy
   of this document with respect to LDAP.






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


8.0 References

   [1]  Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
        service: Schemes", RFC 2609, April 1999.

   [2]  Wahl, W., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol (v3)", RFC 2251, December 1997.

   [3]  International Telecommunications Union. The Directory:Selected
        Attribute Types.  ITU Recommendation X.520. August, 1997.

   [4]  McLaughlin, L., "Line Printer Daemon Protocol, RFC 1179, August
        1990.

   [5]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol Version 2", RFC 2608, April 1999.

   [6]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [7]  Howes, T., "The String Representation of LDAP Search Filters",
        RFC 2254, December 1997.

   [8]  Wahl, W., Coulbeck, A., Howe, T. and S. Kille, "Lightweight
        Directory Access Protocol (v3): Attribute Syntax Definition",
        RFC 2252, December 1997.

   [9]  ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1) -
        Specification of Basic Notation. 1994.

   [10] Fleming, P., Jones, K., Lewis, H., and McDonald, I., "Internet
        Printing Protocol (IPP): LDAP Schema for Printer Services", Work
        in Progress.

   [11] Smith, M., "Definition of an X.500 Attribute Type and an Object
        Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079,
        January 1997.

   [12] Yaacovi, Y., Wahl, M. and T. Genovese, "Lightweight Directory
        Access Protocol (v3): Extensions for Dynamic Directory
        Services", RFC 2589, May 1999.

   [13] Alvestrand, H., "Tags for the Identification of Languages", RFC
        1766, December 1997.

   [14] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC
        2596, May 1999.




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


   [15] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
        "Authentication Methods for LDAP", RFC 2829, May 2000.

   [16] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [17] Dubuisson, O. ASN.1: Communication between Heterogeneous
        Systems. OSS Nokalva, 2000.

   [18] http://www.srvloc.org

9.0 Authors' Addresses

   James Kempf
   Sun Microsystems
   901 San Antonio Avenue
   Palo Alto, CA 94303
   USA

   Phone: [phone]
   EMail: [e-mail]


   Ryan Moats
   Coreon, Inc.
   15621 Drexel Circle
   Omaha, NE, 68135
   USA

   EMail: [e-mail]


   Pete St. Pierre
   Sun Microsystems
   901 San Antonio Avenue
   Palo Alto, CA 94303
   USA

   Phone: [phone]
   EMail: [e-mail]











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


10.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kempf, et al.                Informational                     [Page 27]