| blob | a7b081d0c5399e27d43a95843190ea8c3c24f7eb |
7 Network Working Group J. Kempf
8 Request for Comments: 2926 Sun Microsystems, Inc.
9 Category: Informational R. Moats
10 Coreon, Inc.
11 P. St. Pierre
12 Sun Microsystems, Inc.
13 September 2000
16 Conversion of LDAP Schemas to and from SLP Templates
18 Status of this Memo
20 This memo provides information for the Internet community. It does
21 not specify an Internet standard of any kind. Distribution of this
22 memo is unlimited.
24 Copyright Notice
26 Copyright (C) The Internet Society (2000). All Rights Reserved.
28 Abstract
30 This document describes a procedure for mapping between Service
31 Location Protocol (SLP) service advertisements and lightweight
32 directory access protocol (LDAP) descriptions of services. The
33 document covers two aspects of the mapping. One aspect is mapping
34 between SLP service type templates and LDAP directory schema.
35 Because the SLP service type template grammar is relatively simple,
36 mapping from service type templates to LDAP types is straightforward.
37 Mapping in the other direction is straightforward if the attributes
38 are restricted to use just a few of the syntaxes defined in RFC 2252.
39 If arbitrary ASN.1 types occur in the schema, then the mapping is
40 more complex and may even be impossible. The second aspect is
41 representation of service information in an LDAP directory. The
42 recommended representation simplifies interoperability with SLP by
43 allowing SLP directory agents to backend into LDAP directory servers.
44 The resulting system allows service advertisements to propagate
45 easily between SLP and LDAP.
58 Kempf, et al. Informational [Page 1]
59 \f
60 RFC 2926 Conversion of LDAP Schemas September 2000
63 Table of Contents
65 1.0 Introduction ................................................ 2
66 2.0 Mapping SLP Templates to LDAP Schema ........................ 3
67 2.1 Mapping from SLP Attribute Types to LDAP Attribute Types .. 8
68 2.1.1 Integer ............................................... 8
69 2.1.2 String ................................................ 8
70 2.1.3 Boolean ............................................... 9
71 2.1.4 Opaque ................................................ 9
72 2.2 Keyword Attributes ........................................ 9
73 2.3 Template Flags ............................................ 9
74 2.3.1 Multi-valued .......................................... 9
75 2.3.2 Optional .............................................. 10
76 2.3.3 Literal ............................................... 10
77 2.3.4 Explicit Matching ..................................... 10
78 2.4 Default and Allowed Value Lists ........................... 10
79 2.5 Descriptive Text .......................................... 11
80 2.6 Generating LDAP Attribute OIDs ............................ 11
81 2.7 Example ................................................... 11
82 3.0 Attribute Name Conflicts .................................... 15
83 4.0 Mapping from Schema to Templates ............................ 15
84 4.1 Mapping LDAP Attribute Types to SLP Attribute Types ....... 16
85 4.2 Mapping ASN.1 Types to SLP Types .......................... 17
86 4.2.1 Integer ............................................... 18
87 4.2.2 Boolean ............................................... 18
88 4.2.3 Enumerated ............................................ 18
89 4.2.4 Object Identifier ..................................... 19
90 4.2.5 Octet String .......................................... 19
91 4.2.6 Real .................................................. 19
92 4.3 Example ASN.1 Schema ...................................... 19
93 5.0 Representing SLP Service Advertisements in an LDAP DIT ...... 22
94 6.0 Internationalization Considerations ......................... 24
95 7.0 Security Considerations ..................................... 24
96 8.0 References .................................................. 25
97 9.0 Authors' Addresses .......................................... 26
98 10.0 Full Copyright Statement ................................... 27
100 1.0 Introduction
102 SLP templates [1] are intended to create a simple encoding of the
103 syntactic and semantic conventions for individual service types,
104 their attributes, and conventions. They can easily be generated,
105 transmitted, read by humans and parsed by programs, as it is a string
106 based syntax with required comments. Directory schemas serve to
107 formalize directory entry structures for use with LDAP [2] These
108 directories serve to store information about many types of entities.
109 Network services are an example of one such entity.
114 Kempf, et al. Informational [Page 2]
115 \f
116 RFC 2926 Conversion of LDAP Schemas September 2000
119 Interoperability between SLP and LDAP is important so clients using
120 one protocol derive benefit from services registered through the
121 other. In addition, LDAP directory servers can serve as the backend
122 for SLP directory agents (DAs) if interoperability is possible In
123 order to facilitate interoperability, this document creates mappings
124 between the SLP template grammar and LDAP directory schema, and
125 establishes some conventions for representing service advertisements
126 in LDAP directories. The goal of the translation is to allow SLPv2
127 queries (which are syntactically and semantically equivalent to
128 LDAPv3 string queries [7]) to be submitted to an LDAP directory
129 server by an SLP DA backended into LDAP without extensive processing
130 by the DA.
132 The simple notation and syntactic/semantic attribute capabilities of
133 SLP templates map easily into directory schemas, and are easily
134 converted into directory schemas, even by automated means. The
135 reverse may not be true. If the LDAP schema contains attributes with
136 unrecognized or complex syntaxes, the translation may be difficult or
137 impossible. If, however, the LDAP schema only uses a few of the
138 common syntaxes defined in RFC 2252 [8], then the translation is more
139 straightforward. In addition, to foster complete bidirectionality,
140 the mapping must follow a very specific representation in its DESC
141 attributes.
143 This document outlines the correct mappings for SLP templates into
144 the syntactic representation specified for LDAP directory schema by
145 RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in
146 the X.209 specification [9], and is used by the LDAPv3 [2] directory
147 schema. Likewise, rules and guidelines are proposed to facilitate
148 consistent mapping of ASN.1 based schemas to be translated in the SLP
149 template grammar. Finally, a proposal for a representation of service
150 advertisements in LDAP directory services is made that facilitates
151 SLP interoperability.
153 Except when used as elements in the definition of LDAP schemas, the
154 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156 document are to be interpreted as described in RFC 2119 [16].
158 2.0 Mapping SLP Templates to LDAP Schema
160 We define the following abstract object class as the parent class for
161 all services. Any specific service type is a subclass of this, with
162 its own attributes:
170 Kempf, et al. Informational [Page 3]
171 \f
172 RFC 2926 Conversion of LDAP Schemas September 2000
175 ( 1.3.6.1.4.1.6252.2.27.6.2.1
176 NAME 'slpService'
177 DESC 'parent superclass for SLP services'
178 ABSTRACT
179 SUP top
180 MUST ( template-major-version-number $
181 template-minor-version-number $
182 description $
183 template-url-syntax $
184 service-advert-service-type $
185 service-advert-scopes )
186 MAY ( service-advert-url-authenticator $
187 service-advert-attribute-authenticator ) )
189 The attributes correspond to various parts of the SLP service
190 template and SLP service advertisement.
192 SLP service type templates begin with four definitions that set the
193 context of the template:
195 template-type - This defines the service type of the template. The
196 service type can be a simple service type, like "service:ftp", an
197 abstract service type, like "service:printer" or a concrete
198 service type, like "service:printer:lpr". The type name can
199 additionally include a naming authority, for example
200 "service:printer.sun:local". The name that appears in this field
201 omits the "service:" prefix.
203 template-version - A string containing a major and minor version
204 number, separated by a period.
206 template-description - A block of human readable text describing
207 what the service type does.
209 template-url-syntax - An ABNF [6] grammar describing the service
210 type specific part of the service URL.
212 The SLP template-type definition is used as the name of the LDAP
213 object class for the template, a subclass of the "slpService" class,
214 together with the "service" prefix to indicate that the name is for a
215 service. In the translating service type name, colons and the period
216 separating the naming authority are converted into hyphens. If the
217 template defines an SLP concrete type, the concrete type name is
218 used; the abstract type name is never used. For example, the
219 template for "service:printer:lpr" is translated into an LDAP object
220 class called "service-printer-lpr". Furthermore, if the type name
221 contains a naming authority, the naming authority name must be
226 Kempf, et al. Informational [Page 4]
227 \f
228 RFC 2926 Conversion of LDAP Schemas September 2000
231 included. For example, the service type name
232 "service:printer.sun:local" becomes "service-printer-sun-local". The
233 LDAP object class is always "STRUCTURAL".
235 The template-version definition is partitioned into two attributes,
236 template-major-version-number and template-minor-version-number. The
237 LDAP definition for these attributes is:
239 ( 1.3.6.1.4.1.6252.2.27.6.1.1
240 NAME 'template-major-version-number'
241 DESC 'The major version number of the service type template'
242 EQUALITY integerMatch
243 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
244 SINGLE-VALUE
245 )
247 ( 1.3.6.1.4.1.6252.2.27.6.1.2
248 NAME 'template-minor-version-number'
249 DESC 'The minor version number of the service type template'
250 EQUALITY integerMatch
251 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
252 SINGLE-VALUE
253 )
255 The template-url-syntax definition in the SLP template is described
256 by the following attribute:
258 ( 1.3.6.1.4.1.6252.2.27.6.1.3
259 NAME 'template-url-syntax'
260 DESC 'An ABNF grammar describing the service type
261 specific part of the service URL'
262 EQUALITY caseExactIA5Match
263 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
264 SINGLE-VALUE
265 )
267 The template-description attribute is translated into the X.520
268 standard attribute "description" [3].
270 We further establish the convention that SLP template characteristics
271 that can't be translated into LDAP are inserted into the DESC field
272 of the object class definition. The items are separated by empty
273 lines (consisting of two "LINE FEED" characters), are preceded by a
274 LINE FEED character, and are tagged at the beginning of the line to
275 indicate what they represent. This allows the template to be
276 reconstructed from the schema by properly parsing the comments.
282 Kempf, et al. Informational [Page 5]
283 \f
284 RFC 2926 Conversion of LDAP Schemas September 2000
287 The bulk of an SLP template consists of attribute definitions. There
288 are four items in an SLP template attribute definition that need to
289 be mapped into LDAP:
291 Attribute Name - Since SLPv2 attribute names are defined to be
292 compatible with LDAPv3, SLP attributes map directly into LDAP
293 attributes with no change. Similarly, LDAP attributes map directly
294 to SLP attributes.
296 Attribute Type - The SLP attribute type is mapped into the LDAP
297 attribute type.
299 Attribute Flags - The SLP attribute flags are mapped into
300 characteristics of the LDAP attribute definition, or into the DESC
301 field if no equivalent LDAP attribute definition characteristic
302 occurs.
304 Default and Allowed Values - These must be handled by the client
305 or a DA enabled to handle templates, as in SLP. For reference,
306 however, they should be included in the DESC field of the LDAP
307 attribute definition.
309 Descriptive Text - The SLP template descriptive text should be
310 mapped into the DESC field.
312 We discuss mapping of types, flags, default and allowed values, and
313 descriptive text in the subsections below.
315 OIDs for SLP template conversion schema elements are standardized
316 under the enterprise number of SrvLoc.Org (6252) [18].
318 For purposes of representing an SLP entry, we also define two
319 standardized LDAP syntaxes and attributes with standardized OIDs.
321 ( 1.3.6.1.4.1.6252.2.27.6.2.2
322 DESC 'SLP Service Type'
323 )
325 Defines the syntax for the service type name. The syntax is defined
326 in the BNF for the service URL in RFC 2609 Section 2.1 [1].
328 ( 1.3.6.1.4.1.6252.2.27.6.2.3
329 DESC 'SLP Scope'
330 )
332 Defines the syntax for the scope name. The syntax is defined in the
333 BNF for scope names in RFC 2608 Section 6.4.1 [5].
338 Kempf, et al. Informational [Page 6]
339 \f
340 RFC 2926 Conversion of LDAP Schemas September 2000
343 ( 1.3.6.1.4.1.6252.2.27.6.1.4
344 NAME 'service-advert-service-type'
345 DESC 'The service type of the service advertisement, including
346 the "service:" prefix.'
347 EQUALITY caseExactIA5Match
348 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.2
349 SINGLE-VALUE
350 )
352 Defines an attribute for the service type name.
354 ( 1.3.6.1.4.1.6252.2.27.6.1.5
355 NAME 'service-advert-scopes'
356 DESC 'A list of scopes for a service advertisement.'
357 EQUALITY caseExactIA5Match
358 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
359 )
361 Defines a multivalued attribute for the scopes.
363 Searches for abstract types can be made with an LDAP query that
364 wildcards the concrete type. For example, a search for all service
365 advertisements of the printer abstract type can be made with the
366 following query:
368 (service-advert-service-type=service:printer:*)
370 SLP specifies that service URLs and attribute lists can be
371 accompanied by a structured authenticator consisting of a digital
372 signature and information necessary to verify the signature. A
373 syntax and two standardized SLP attributes are defined for this
374 purpose:
376 ( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator')
378 The syntax of an SLP authenticator is the bytes of the
379 authenticator in network byte order, see RFC 2608, Section 9.2
380 [5].
382 ( 1.3.6.1.4.1.6252.2.27.6.1.6
383 NAME 'service-advert-url-authenticator'
384 DESC 'The authenticator for the URL, null if none.'
385 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
386 SINGLE-VALUE
387 )
389 This attribute contains the SLP URL authenticator, as defined in
390 RFC 2608, Section 9.2 [5].
394 Kempf, et al. Informational [Page 7]
395 \f
396 RFC 2926 Conversion of LDAP Schemas September 2000
399 ( 1.3.6.1.4.1.6252.2.27.6.1.7
400 NAME 'service-advert-attribute-authenticator'
401 DESC 'The authenticator for the attribute list, null if none.'
402 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
403 SINGLE_VALUE
404 )
406 This attribute contains the SLP attribute authenticator, as
407 defined in RFC 2608, Section 9.2 [5].
409 2.1 Mapping from SLP Attribute Types to LDAP Attribute Types
411 We define the mapping from SLP attribute types to LDAP as follows:
413 SLP Type ASN.1 Type LDAP Type
414 ---------------------------------------------------
415 Integer INTEGER INTEGER
416 String DirectoryString Directory String
417 Boolean BOOLEAN Boolean
418 Opaque OCTET STRING Octet String
419 Keyword (N/A) IA5 String
421 The following subsections discuss further details of the mapping.
423 2.1.1 Integer
425 SLP integers compare as integers when performing a query. LDAP
426 integers behave similarly. Consequently, the mapping from the SLP
427 integer type to LDAP is INTEGER, with the integerMatch matching rule.
429 2.1.2 String
431 SLP strings are encoded as described in the SLP protocol
432 specification [5]. All value strings are considered case insensitive
433 for matching operations. SLP strings are not null terminated and are
434 encoded in UTF-8.
436 SLP strings are mapped to the LDAP Directory String type. The
437 Directory String type exactly matches the SLP string type, i.e. it is
438 a non-null terminated UTF-8 string. The caseIgnoreMatch equality
439 rule, caseIgnoreOrderingMatch ordering rule, and
440 caseIgnoreSubstringsMatch substring rule are used for comparing
441 string attribute values.
450 Kempf, et al. Informational [Page 8]
451 \f
452 RFC 2926 Conversion of LDAP Schemas September 2000
455 2.1.3 Boolean
457 Boolean attributes may have one of two possible values. In SLP,
458 these values are represented as strings, TRUE and FALSE. In SLP's
459 string encoding of a boolean value, case does not matter.
461 The SLP Boolean type maps directly into an LDAP BOOLEAN. The
462 caseIgnoreMatch rule is used for equality matching.
464 2.1.4 Opaque
466 SLP attribute values of type Opaque are represented as OCTET STRING
467 in LDAP, and the octetStringMatch matching rule is used to compare
468 them.
470 2.2 Keyword Attributes
472 SLP service type templates allow the definition of keyword
473 attributes. Keyword attributes are attributes whose only
474 characteristic is their presence. Keyword attributes have no flag
475 information, nor any default or allowed values (since, by definition,
476 they have no values).
478 ASN.1 has no concept of keyword attributes. Keyword attributes are
479 translated into a "May" clause in the ASN.1 class definition for the
480 service type. If the keyword attribute is present, then its value is
481 of no consequence, but for consistency we make it simply the NUL
482 character, "\00".
484 2.3 Template Flags
486 SLP template flags can be handled as described in the following
487 subsections.
489 2.3.1 Multi-valued
491 Multi-valued attributes are defined in an SLP template using the one
492 value. All values for a given attribute must be of the same type.
494 LDAP attribute definitions require that a single valued attribute
495 include the SINGLE-VALUE tag if the attribute is single valued.
496 Otherwise, the attribute is assumed to be multivalued by default.
506 Kempf, et al. Informational [Page 9]
507 \f
508 RFC 2926 Conversion of LDAP Schemas September 2000
511 2.3.2 Optional
513 SLP uses the 'O' flag to indicate an attribute may or may not be
514 present. These optional attributes are defined using the "May"
515 clause in the ASN.1 definition class definition for the service type.
516 All other attributes must be defined as a "Must".
518 2.3.3 Literal
520 ASN.1 does not have a mechanism to indicate that the values of an
521 attribute may not be translated from one language to another, since
522 ASN.1 schema are not typically translated. This flag is dropped when
523 translating a template, but presence of the flag should be noted in
524 the DESC field. It should be placed on a separate line and tagged
525 with "Literal:" so the template can be reconstructed from the schema.
527 2.3.4 Explicit Matching
529 The SLP template syntax uses a flag of 'X' to indicate that an
530 attribute must be present in order for the query to be properly
531 satisfied. There is no provision for requiring that particular
532 attributes be in a query. Consequently, this flag is dropped when
533 translating a template, but presence of the flag should be noted in
534 the DESC field. It should be placed on a separate line and tagged
535 with "Explicit:" so the template can be reconstructed from the
536 schema.
538 2.4 Default and Allowed Value Lists
540 The SLP template grammar provides the capability to define default
541 and allowed values for an attribute. The SLP protocol does not
542 enforce these restrictions on registered attributes, however. The
543 default and allowed values may be used by client side applications,
544 or alternatively it may also be used by DAs to initialize
545 registrations having no attributes and to limit attribute values to
546 the template allowed values.
548 LDAP servers also do not support default and allowed values on
549 attributes. Therefore, enforcement of default and allowed values in
550 SLP templates is left up to the clients or a DA, if the DA is
551 backending into LDAP. The default and allowed values should be
552 included in the DESC field. The comments should be placed on separate
553 lines and labeled with the "Default:" and "Allowed:" tags to allow
554 reconstruction of the template.
562 Kempf, et al. Informational [Page 10]
563 \f
564 RFC 2926 Conversion of LDAP Schemas September 2000
567 2.5 Descriptive Text
569 The descriptive text associated with an attribute definition should
570 be included in the DESC field. It should start on a separate line and
571 begin with the "Description:" tag.
573 2.6 Generating LDAP Attribute OIDs
575 LDAP attributes require an OID. In general, there is no a priori way
576 that an algorithm can be defined for generating OIDs, because it will
577 depend on the conventions used by the organization developing the
578 template. In some cases, an organization's procedure for generating
579 OIDs may be regular enough that a template developer can
580 algorithmically generate OIDs off of an assigned root. Whatever means
581 is used, the template developer should assure that unique OIDs are
582 assigned to each SLP attribute that is translated into an LDAP
583 attribute.
585 2.7 Example
587 The template included below is a hypothetical abstract printer
588 service template, similar to that described in [10].
590 template-type = printer
592 template-version = 0.0
594 template-description =
595 The printer service template describes the attributes supported by
596 network printing devices. Devices may be either directly
597 connected to a network, or connected to a printer spooler that
598 understands the a network queuing protocol such as IPP, lpr or the
599 Salutation Architecture.
601 template-url-syntax =
602 ;The URL syntax is specific to the printing protocol being
603 ;employed
605 description = STRING
606 # This attribute is a free form string that can contain any
607 # site-specific descriptive information about this printer.
609 printer-security-mechanisms-supported = STRING L M
610 none
611 # This attribute indicates the security mechanisms supported
612 tls, ssl, http-basic, http-digest, none
618 Kempf, et al. Informational [Page 11]
619 \f
620 RFC 2926 Conversion of LDAP Schemas September 2000
623 printer-operator = STRING O L M
624 # A person, or persons responsible for maintaining a
625 # printer on a day-to-day basis, including such tasks
626 # as filling empty media trays, emptying full output
627 # trays, replacing toner cartridges, clearing simple
628 # paper jams, etc.
630 printer-location-address = STRING O
631 # Physical/Postal address for this device. Useful for
632 # nailing down a group of printers in a very large corporate
633 # network. For example: 960 Main Street, San Jose, CA 95130
635 printer-priority-queue = BOOLEAN O
636 FALSE
637 # TRUE indicates this printer or print queue is a priority
638 # queuing device.
640 printer-number-up = INTEGER O
641 1
642 # This job attribute specifies the number of source
643 # page-images to impose upon a single side of an instance
644 # of a selected medium.
645 1, 2, 4
647 printer-paper-output = STRING M L O
648 standard
649 # This attribute describes the mode in which pages output
650 # are arranged.
652 standard, noncollated sort, collated sort, stack, unknown
654 We assume that the concrete type "service:printer:lpr" for printers
655 that speak the LPR protocol [4] has the following template
656 definition:
658 template-type = printer:lpr
660 template-version = 0.0
662 template-description =
663 The printer:lpr service template describes the attributes
664 supported by network printing devices that speak the
665 LPR protocol. No new attributes are included.
667 template-url-syntax = queue
668 queue = ;The queue name, see RFC 1179.
674 Kempf, et al. Informational [Page 12]
675 \f
676 RFC 2926 Conversion of LDAP Schemas September 2000
679 The LDAP class definition for the "service:printer:lpr" concrete
680 service type is translated as follows:
682 ( ---place the assigned OID here---
683 NAME 'service-printer-lpr'
684 DESC 'Description: The printer:lpr service template
685 describes the attributes supported by network printing
686 devices that speak the LPR protocol. No new attributes
687 are included.
689 URL Syntax: queue
690 queue = ;The queue name, see RFC 1179.'
691 SUP slpService
692 MUST ( description $ security-mechanisms-supported $
693 labeledURI)
694 MAY ( operator $ location-address $ priority-queue $
695 number-up $ paper-output)
696 )
698 The attribute definitions are translated as follows:
700 ( ---place the assigned OID here---
701 NAME 'printer-security-mechanisms-supported'
702 DESC 'Description: This attribute indicates the security mechanisms
703 supported.
705 Default: value
707 Allowed: tls, ssl, http-basic, http-digest, none
709 Literal:'
710 EQUALITY caseIgnoreMatch
711 ORDERING caseIgnoreOrderingMatch
712 SUBSTR caseIgnoreSubstringsMatch
713 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
714 )
716 ( ---place the assigned OID here---
717 NAME 'printer-operator'
718 DESC 'Description: A person, or persons responsible for
719 maintaining a printer on a day-to-day basis, including
720 such tasks as filling empty media trays, emptying full
721 output trays, replacing toner cartridges, clearing simple
722 paper jams, etc.
730 Kempf, et al. Informational [Page 13]
731 \f
732 RFC 2926 Conversion of LDAP Schemas September 2000
735 Literal:'
736 EQUALITY caseIgnoreMatch
737 ORDERING caseIgnoreOrderingMatch
738 SUBSTR caseIgnoreSubstringsMatch
739 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
740 )
742 ( --place the assigned OID here---
743 NAME 'printer-location-address'
744 DESC 'Description Physical/Postal address for this device.
745 Useful for nailing down a group of printers in a very
746 large corporate network. For example: 960 Main Street,
747 San Jose, CA 95130.'
748 EQUALITY caseIgnoreMatch
749 ORDERING caseIgnoreOrderingMatch
750 SUBSTR caseIgnoreSubstringsMatch
751 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
752 SINGLE-VALUE
753 )
755 ( ---place the assigned OID here---
756 NAME 'printer-priority-queue'
757 DESC 'Description: TRUE indicates this printer or print
758 queue is a priority queuing device.'
759 EQUALITY booleanMatch
760 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
761 SINGLE-VALUE
762 )
764 ( ---place the assigned OID here---
765 NAME 'printer-number-up'
766 DESC 'Description: This job attribute specifies the number
767 of source page-images to impose upon a single side of
768 an instance of a selected medium. This attribute is
769 INTEGER.
771 Default: 1
773 Allowed: 1, 2, 3, 4'
774 EQUALITY integerMatch
775 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
776 SINGLE-VALUE
777 )
786 Kempf, et al. Informational [Page 14]
787 \f
788 RFC 2926 Conversion of LDAP Schemas September 2000
791 ( ---place the assigned OID here---
792 NAME 'printer-paper-output'
793 DESC 'Description: This attribute describes the mode in
794 which pages output are arranged. Default value is
795 standard.
797 Default: standard
799 Allowed: standard, noncollated sort, collated sort,
800 stack, unknown.
801 Literal:'
802 EQUALITY caseIgnoreMatch
803 ORDERING caseIgnoreOrderingMatch
804 SUBSTR caseIgnoreSubstringsMatch
805 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
806 )
808 3.0 Attribute Name Conflicts
810 LDAP has a flat name space, and attribute names and OIDs must be
811 unique in a directory server. In order to avoid name conflicts in the
812 translation of SLP templates to LDAP schemas, template developers may
813 want to consider prepending the name of the service type to the
814 attribute. Postprocessing attribute names to make them unique when
815 translated is not possible, because it would require the DA to
816 rewrite queries before submitting them to the directory server. In
817 addition, developers should use standard LDAP attributes when such
818 attributes are available.
820 In the above example template, the abstract type name "printer" is
821 prepended to attributes to avoid conflicts. The standard
822 "description" attribute defined by X.520 [3] is used to translate the
823 template description attribute.
825 4.0 Mapping from Schema to Templates
827 The reverse mapping from LDAP schema to SLP service type templates
828 requires dealing with both LDAP and ASN.1 data types. RFC 2252
829 defines 33 attribute syntaxes that should be supported by LDAP
830 directory servers. These syntaxes are defined using BNF for strings
831 or using ASN.1 for binary valued attributes defined by X.520.
833 Mapping of the LDAP data types into SLP template types is fairly
834 straightforward, but mapping arbitrary ASN.1 data types is somewhat
835 more complicated and requires encoding the ASN.1 data type into a
836 string. To a certain extent, this masks the ASN.1 data type because
837 it becomes impossible to distinguish between a native string having
842 Kempf, et al. Informational [Page 15]
843 \f
844 RFC 2926 Conversion of LDAP Schemas September 2000
847 content equivalent to an encoded ASN.1 string. However, inclusion of
848 the ASN.1 data type in the comment provides additional information
849 should a reverse transformation from SLP to ASN.1 be required.
851 The following subsections deal with both LDAP and ASN.1 attribute
852 data type mappings.
854 4.1 Mapping LDAP Attribute Syntaxes to SLP Attribute Types
856 The following table contains the mappings for LDAP syntaxes to SLP
857 data types:
859 LDAP Type SLP Type
860 --------------------------------------------------------
861 ACI Item NA
862 Access Point NA
863 Attribute Type Description NA
864 Audio Opaque
865 Binary ASN.1 escape
866 Bit String String
867 Boolean Boolean
868 Certificate Opaque
869 Certificate List Opaque
870 Certificate Pair Opaque
871 Country String String
872 DN String
873 Data Quality Syntax NA
874 Delivery Method NA
875 Directory String String
876 DIT Content Rule Description NA
877 DIT Structure Rule Description NA
878 DL Submit Permission NA
879 DSA Quality Syntax NA
880 Enhanced Guide NA
881 Facsimile Telephone Number String
882 Fax Opaque
883 Generalized Time String
884 Guide NA
885 IA5 String String
886 INTEGER Integer
887 JPEG Opaque
888 LDAP Syntax Description NA
889 LDAP Schema Definition NA
890 LDAP Schema Description NA
891 Master and Shadow Access Points NA
892 Matching Rule Description NA
893 Matching Rule Use Description NA
894 Mail Preference NA
898 Kempf, et al. Informational [Page 16]
899 \f
900 RFC 2926 Conversion of LDAP Schemas September 2000
903 MHS OR Address String
904 Modify Rights NA
905 Name and Optional UID NA
906 Name Form Description NA
907 Numeric String String
908 Object Class Description NA
909 Octet String Opaque
910 OID String
911 Other Mailbox String
912 Postal Address String
913 Protocol Information NA
914 Presentation Address String
915 Printable String String
916 Substring Assertion NA
917 Subtree Specification NA
918 Supplier Information NA
919 Supplier or Consumer NA
920 Supplier And Consumer NA
921 Supported Algorithm NA
922 DSE Type NA
923 Telephone Number String
924 Teletex Terminal Identifier String
925 Telex Number String
926 UTC Time String
928 4.2 Mapping ASN.1 Types to SLP Types
930 ASN.1 employs a much richer set of data types than provided by SLP.
931 The table below show the mapping of selected ASN.1 data type to their
932 nearest SLP equivalent. Because of the complexity and flexibility of
933 ASN.1, a complete list cannot be provided.
935 As sample of some ASN.1 encodings and their mappings to SLP:
937 ASN.1 type SLP type
938 -----------------------------------------
939 INTEGER Integer
940 BOOLEAN Boolean
941 ENUMERATED String
942 OBJECT IDENTIFIER String
943 OCTET STRING Opaque
944 REAL String
946 Data types that do not map directly to SLP data types should be
947 defined as either a String, or as Opaque. ASN.1 types that may only
948 contain valid characters for Strings, as defined in X.680 [9] should
949 be encoded as strings. ASN.1 types such as GraphicString that change
950 their character set encoding in part way through a value should not
954 Kempf, et al. Informational [Page 17]
955 \f
956 RFC 2926 Conversion of LDAP Schemas September 2000
959 be encoded as strings, however, If such types are required, the SLP
960 Opaque type should be used. In either case, the first line of the
961 help text is used to indicate the original ASN.1 data type.
963 The following subsections describe how to convert from the ASN.1 BER
964 [9] to the SLP template for the different types in the table above.
966 4.2.1 Integer
968 Both SLP templates and ASN.1 support Integers, so there is a one to
969 one mapping between an SLP Integer attribute and an ASN.1 Integer
970 attribute. Details on the encoding of integers is summarized in the
971 SLP template to ASN.1 section above.
973 4.2.2 Boolean
975 Boolean values are supported by both SLP and ASN.1, though on wire
976 encodings differ. X.680 [9] specifies zero and non-zero encoding for
977 booleans, where SLP encodes booleans using the strings TRUE and
978 FALSE. In general, most LDAP servers will use the LDAP Boolean type
979 (which is a string), so again the ASN.1 type should be recorded in
980 the comment or it will be lost.
982 4.2.3 Enumerated
984 SLP templates support the concept of enumerations through the listing
985 of allowed values in the attribute definition. These enumerations
986 are not strictly binding on clients or DAs, but they are similar to
987 the ASN.1 definition of enumerations. BER encodes the ASN.1
988 enumeration by passing the number of the element's position in the
989 enumeration. This requires both sides to have knowledge of the
990 specific enumeration prior to decoding an enumeration's value. SLP
991 provides no specific support for transmitting enumerations. They are
992 simply String types. Information on the ASN.1 type and ASN.1 encoding
993 of the enumeration values is recorded in the comment.
995 Example:
997 color-supported = STRING M
998 none
999 # ASN.1: Enumeration.
1000 # ASN.1 Mapping: none = 0, highlight = 1, three color = 2,
1001 # four color = 4, monochromatic = 5
1002 #This attribute specifies whether the Printer supports
1003 # color and, if so, what type.
1004 none,highlight,three color,four color,monochromatic
1010 Kempf, et al. Informational [Page 18]
1011 \f
1012 RFC 2926 Conversion of LDAP Schemas September 2000
1015 4.2.4 Object Identifier
1017 Object identifiers(OIDs) are commonly used in the ASN.1 world to
1018 identify object and attributes. OIDs are a numerical representation
1019 of an element's place in the naming hierarchy. Each element at a
1020 particular level of a hierarchy has a unique number assigned within
1021 that level of the hierarchy. A sample OID would be the naming tree
1022 for SNMP MIBs: iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would
1023 be written as the string "1.3.6.1.2.1".
1025 Because this representation reduces down to a string of dot separated
1026 numbers, this maps easily to the SLP String type. The help text for
1027 this element should indicate it is an ASN.1 OID
1029 identifier = STRING
1030 # ASN.1: OID
1031 # The object identifier for this SNMP agent.
1033 4.2.5 Octet String
1035 An ASN.1 octet string should be mapped to an Opaque in an SLP
1036 template. An octet string is a sequence of bytes, whereas an Opaque
1037 is a a string that encodes a sequence of bytes. Again, the ASN.1 type
1038 is lost unless recorded in the comment.
1040 4.2.6 Real
1042 There is no direct mapping between floating point numbers and any SLP
1043 data types. Attributes having the ASN.1 type of Real are mapped to
1044 SLP type String. Comments are added to the attribute help text
1045 indicating the value was originally an ASN.1 real. For example:
1047 weight = STRING
1048 # ASN.1: Real
1049 # The objects weight in pounds.
1051 4.3 Example ASN.1 Schema
1053 The following is an example schema for an exported filesystem. The
1054 section presents it as in ASN.1 and the following section shows the
1055 SLP template translation. The template translation does not capture
1056 the actual attribute format for the Set type, that would be done in
1057 the LDAP client software making the translation. Note that even
1058 though the class definition does not conform with the previously
1059 defined conventions for SLP classes, the schema can still be
1060 translated into an SLP template. The syntax used in this example
1061 follows
1066 Kempf, et al. Informational [Page 19]
1067 \f
1068 RFC 2926 Conversion of LDAP Schemas September 2000
1071 -- Abstraction of a fstab entry (a "mount").
1072 -- These lookups would likely be performed by an
1073 -- an automounter type application.
1074 mount OBJECT-CLASS ::= {
1075 SUBCLASS OF { top }
1076 MUST CONTAIN { mountHost |
1077 mountDirectory |
1078 mountType
1079 }
1080 MAY CONTAIN { mountOption |
1081 mountDumpFrequency |
1082 mountPassNo
1083 }
1084 ID { <oid1> }
1085 }
1088 - The mount host.
1089 mountHost ATTRIBUTE ::= {
1090 WITH SYNTAX caseIgnoreString
1091 EQUALITY MATCHING RULE caseIgnoreMatch
1092 SINGLE VALUE
1093 ID { <oid2> }
1094 }
1097 - The file system to mount.
1098 mountDirectory ATTRIBUTE ::= {
1099 WITH SYNTAX caseIgnoreString
1100 EQUALITY MATCHING RULE caseIgnoreMatch
1101 SINGLE VALUE
1102 ID { <oid3> }
1103 }
1105 - The type of file system being mounted.
1106 mountType ATTRIBUTE ::= {
1107 WITH SYNTAX INTEGER { ufs(1),
1108 hsfs(2),
1109 nfs(3),
1110 rfs(4)
1111 }
1112 EQUALITY MATCHING RULE integerMatch
1113 SINGLE VALUE
1114 ID { <oid4> }
1115 }
1122 Kempf, et al. Informational [Page 20]
1123 \f
1124 RFC 2926 Conversion of LDAP Schemas September 2000
1127 - Options for the mount operation.
1128 mountOption ATTRIBUTE ::= {
1129 WITH SYNTAX caseIgnoreString
1130 EQUALITY MATCHING RULE caseIgnoreString
1131 ID { <oid5> }
1132 }
1135 - How often to dump the file system.
1136 mountDumpFrequency ATTRIBUTE :: = {
1137 WITH SYNTAX INTEGER (0..9)
1138 EQUALITY MATCHING RULE integerMatch
1139 SINGLE VALUE
1140 ID { <oid6> }
1141 }
1143 - Boot time mount pass number.
1144 mountPassNo ATTRIBUTE ::= {
1145 WITH SYNTAX INTEGER
1146 EQUALITY MATCHING RULE integerMatch
1147 SINGLE VALUE
1148 ID { <oid7> }
1149 }
1151 The translated SLP template is:
1153 template-type = mount
1155 template-version = 1.0
1157 template-description = "Describes a remote filesystem access
1158 protocol"
1160 template-url-syntax =
1161 filesystem = 1*[ DIGIT / ALPHA ]
1162 urlpath = "/" filesystem
1164 mountHost = STRING L
1165 # ASN.1: Case Ignore String, Single Value
1166 # The mount host
1168 mountDirectory = STRING L
1169 # ASN.1: Case Ignore String, Single Value
1170 # The filesystem to mount
1178 Kempf, et al. Informational [Page 21]
1179 \f
1180 RFC 2926 Conversion of LDAP Schemas September 2000
1183 mountType = STRING L
1184 ufs
1185 # ASN.1: Enumeration, Single Value
1186 # ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4
1187 # The type of the filesystem being mounted
1188 ufs, hsfs, nfs, rfs
1190 mountOption = STRING M O L
1191 # ASN.1: Case Ignore String
1192 # mount options for this filesystem
1194 mountDumpFrequency = INTEGER O
1195 0
1196 # ASN.1: Integer Range, Single Value
1197 # How often to dump this filesystem
1198 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
1200 mountPassNo = INTEGER O
1201 # ASN.1: Integer, Single Value
1202 # Boot time mount pass number
1204 5.0 Representing SLP Service Advertisements in an LDAP DIT
1206 In addition to translating between SLP templates and LDAP schema,
1207 another area requiring compatibility is the representation of SLP
1208 service advertisements in an LDAP DIT. A standardized representation
1209 for service information allows SLP DAs to store service
1210 advertisements in LDAP, and for LDAP clients to query the DIT for
1211 those services. Similarly, if LDAP clients represent service
1212 information in the same form, SLP clients can benefit from
1213 interoperability.
1215 A service advertisement contains the service URL in a 'labeledURI'
1216 attribute [11]. The labeledURI attribute in a service advertisement
1217 should only contain the service URL for the service, with no
1218 additional label. It is recommended that the labeledURI be used as
1219 the RDN for the service object in the DIT.
1221 Although service advertisements can appear anywhere within the DIT,
1222 it is recommended that all services be stored under a single common
1223 point, or root node, to facilitate searching in a domain. This allows
1224 a client to search for all of advertisements of a particular service
1225 type, say, for all printers. The recommended parent entry is one
1226 named "ou=service" below the entry which is the representation of the
1227 domain, as described in RFC 2247.
1234 Kempf, et al. Informational [Page 22]
1235 \f
1236 RFC 2926 Conversion of LDAP Schemas September 2000
1239 For example, a printer service with labeledURI of
1240 "service:lpr://printsrv/queue1" in the domain foobar.com advertised
1241 in the LDAP server that holds the entry "dc=foobar,dc=com" tree has
1242 the following DN:
1244 "labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar,
1245 dc=com"
1247 While this leads to a flat space of service storage, since SLP uses
1248 search filters from LDAP for searches, these filters can be used for
1249 one-level searches from the root node.
1251 The following example illustrates how an advertisement having a
1252 simple service type is represented. The advertisement (in conceptual
1253 form) for a printer is:
1255 Service Type: service:lpr://printsrv/queue1
1256 Scopes: eng,corp
1257 Attributes:
1258 description = A general printer for all to use.
1259 security-mechanisms-supported = none
1260 Authentication: none
1262 The RDN of the object is labeledURI=service:lpr://printsrv/queue1,
1263 and the following LDAP search filter will return this object, along
1264 with any others of the service type "service:lpr" that match the
1265 other attributes:
1267 (&(service-advert-service-type=service:lpr)
1268 (service-advert-scopes=eng)
1269 (service-advert-scopes=corp)
1270 (description=A general printer for all to use.)
1271 (security-mechanisms-supported=none))
1273 Service advertisements in SLP also have a lease time associated with
1274 them. In LDAP servers that support the extensions for dynamic
1275 directory services [12], the service advertisement entry objectClass
1276 should be extended with the dynamicObject class. This allows the
1277 service advertisement to time out within the LDAP directory server.
1278 If the LDAP directory server does not support the dynamic directory
1279 services extension, then advertisement lease timeouts must be handled
1280 by the SLP agent.
1282 While the service advertisement schema outlined in this section is
1283 primarily for SLP DAs that use LDAP as a backing store, if LDAP
1284 agents register services using the same format, complete
1285 interoperability with SLP is achieved.
1290 Kempf, et al. Informational [Page 23]
1291 \f
1292 RFC 2926 Conversion of LDAP Schemas September 2000
1295 6.0 Internationalization Considerations
1297 SLP specifies that an RFC 1766 [13] language code accompanies every
1298 service advertisement. Language codes for service advertisements in
1299 LDAP must be represented according to RFC 2596 [14].
1301 RFC 2596 prohibits language codes in DNs, and specifies that a
1302 directory server which does not support language codes must treat an
1303 attribute with a language code as an unrecognized attributes.
1304 According to RFC 2596, language codes are appended to attribute names
1305 with a semicolon (";"). For example, the following attribute/value
1306 pair is in the German locale:
1308 (address;lang-de=44 Bahnhofstrasse, 2365 Weibstadt, Deutschland)
1310 An attribute with a language tag in a specific locale is considered a
1311 separate attribute from attributes in other locales.
1313 If the service advertisement is in the default SLP locale ("en", no
1314 dialect), then the language code need not be appended to the
1315 attribute name.
1317 SLP queries in locales other than the default need not be rewritten
1318 to include language tags before being submitted to the directory
1319 server. RFC 2596 specifies that all entries that match are returned,
1320 including those with language tags, without requiring the language
1321 tags to be explicitly present in the query. The SLP DA can then
1322 postprocess the result to select the entries from the required
1323 locale.
1325 7.0 Security Considerations
1327 SLP authenticators are stored with the service advertisement in the
1328 DIT, as discussed in Section~7ef{slpdit}. LDAP clients need to use
1329 LDAP authentication [15] to assure that they are connecting with a
1330 secure server. In particular, SLP DAs that use LDAP as a back end
1331 store and that implement SLP authentication MUST use LDAP
1332 authentication to assure that the LDAP entries for their service
1333 registrations are secure.
1335 Acknowledgements
1337 Many thanks are due to Mark Wahl whose detailed and insightful
1338 comments were instrumental in helping improve the technical accuracy
1339 of this document with respect to LDAP.
1346 Kempf, et al. Informational [Page 24]
1347 \f
1348 RFC 2926 Conversion of LDAP Schemas September 2000
1351 8.0 References
1353 [1] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
1354 service: Schemes", RFC 2609, April 1999.
1356 [2] Wahl, W., Howes, T. and S. Kille, "Lightweight Directory Access
1357 Protocol (v3)", RFC 2251, December 1997.
1359 [3] International Telecommunications Union. The Directory:Selected
1360 Attribute Types. ITU Recommendation X.520. August, 1997.
1362 [4] McLaughlin, L., "Line Printer Daemon Protocol, RFC 1179, August
1363 1990.
1365 [5] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
1366 Location Protocol Version 2", RFC 2608, April 1999.
1368 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1369 Specifications: ABNF", RFC 2234, November 1997.
1371 [7] Howes, T., "The String Representation of LDAP Search Filters",
1372 RFC 2254, December 1997.
1374 [8] Wahl, W., Coulbeck, A., Howe, T. and S. Kille, "Lightweight
1375 Directory Access Protocol (v3): Attribute Syntax Definition",
1376 RFC 2252, December 1997.
1378 [9] ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1) -
1379 Specification of Basic Notation. 1994.
1381 [10] Fleming, P., Jones, K., Lewis, H., and McDonald, I., "Internet
1382 Printing Protocol (IPP): LDAP Schema for Printer Services", Work
1383 in Progress.
1385 [11] Smith, M., "Definition of an X.500 Attribute Type and an Object
1386 Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079,
1387 January 1997.
1389 [12] Yaacovi, Y., Wahl, M. and T. Genovese, "Lightweight Directory
1390 Access Protocol (v3): Extensions for Dynamic Directory
1391 Services", RFC 2589, May 1999.
1393 [13] Alvestrand, H., "Tags for the Identification of Languages", RFC
1394 1766, December 1997.
1396 [14] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC
1397 2596, May 1999.
1402 Kempf, et al. Informational [Page 25]
1403 \f
1404 RFC 2926 Conversion of LDAP Schemas September 2000
1407 [15] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
1408 "Authentication Methods for LDAP", RFC 2829, May 2000.
1410 [16] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
1411 Levels", BCP 14, RFC 2119, March 1997.
1413 [17] Dubuisson, O. ASN.1: Communication between Heterogeneous
1414 Systems. OSS Nokalva, 2000.
1416 [18] http://www.srvloc.org
1418 9.0 Authors' Addresses
1420 James Kempf
1421 Sun Microsystems
1422 901 San Antonio Avenue
1423 Palo Alto, CA 94303
1424 USA
1426 Phone: +1 650 786-5890
1427 EMail: james.kempf@sun.com
1430 Ryan Moats
1431 Coreon, Inc.
1432 15621 Drexel Circle
1433 Omaha, NE, 68135
1434 USA
1436 EMail: rmoats@coreon.net
1439 Pete St. Pierre
1440 Sun Microsystems
1441 901 San Antonio Avenue
1442 Palo Alto, CA 94303
1443 USA
1445 Phone: +1 415 786-5790
1446 EMail: Pete.StPierre@Eng.Sun.COM
1458 Kempf, et al. Informational [Page 26]
1459 \f
1460 RFC 2926 Conversion of LDAP Schemas September 2000
1463 10. Full Copyright Statement
1465 Copyright (C) The Internet Society (2000). All Rights Reserved.
1467 This document and translations of it may be copied and furnished to
1468 others, and derivative works that comment on or otherwise explain it
1469 or assist in its implementation may be prepared, copied, published
1470 and distributed, in whole or in part, without restriction of any
1471 kind, provided that the above copyright notice and this paragraph are
1472 included on all such copies and derivative works. However, this
1473 document itself may not be modified in any way, such as by removing
1474 the copyright notice or references to the Internet Society or other
1475 Internet organizations, except as needed for the purpose of
1476 developing Internet standards in which case the procedures for
1477 copyrights defined in the Internet Standards process must be
1478 followed, or as required to translate it into languages other than
1479 English.
1481 The limited permissions granted above are perpetual and will not be
1482 revoked by the Internet Society or its successors or assigns.
1484 This document and the information contained herein is provided on an
1485 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1486 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1487 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1488 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1489 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1491 Acknowledgement
1493 Funding for the RFC Editor function is currently provided by the
1494 Internet Society.
1514 Kempf, et al. Informational [Page 27]
1515 \f