]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc2926.txt
Remove many (but not all) references to slurpd(8).
[openldap] / doc / rfc / rfc2926.txt
1
2
3
4
5
6
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
14
15
16           Conversion of LDAP Schemas to and from SLP Templates
17
18 Status of this Memo
19
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.
23
24 Copyright Notice
25
26    Copyright (C) The Internet Society (2000).  All Rights Reserved.
27
28 Abstract
29
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.
46
47
48
49
50
51
52
53
54
55
56
57
58 Kempf, et al.                Informational                      [Page 1]
59 \f
60 RFC 2926               Conversion of LDAP Schemas         September 2000
61
62
63 Table of Contents
64
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
99
100 1.0 Introduction
101
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.
110
111
112
113
114 Kempf, et al.                Informational                      [Page 2]
115 \f
116 RFC 2926               Conversion of LDAP Schemas         September 2000
117
118
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.
131
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.
142
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.
152
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].
157
158 2.0 Mapping SLP Templates to LDAP Schema
159
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:
163
164
165
166
167
168
169
170 Kempf, et al.                Informational                      [Page 3]
171 \f
172 RFC 2926               Conversion of LDAP Schemas         September 2000
173
174
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 ) )
188
189    The attributes correspond to various parts of the SLP service
190    template and SLP service advertisement.
191
192    SLP service type templates begin with four definitions that set the
193    context of the template:
194
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.
202
203       template-version - A string containing a major and minor version
204       number, separated by a period.
205
206       template-description - A block of human readable text describing
207       what the service type does.
208
209       template-url-syntax - An ABNF [6] grammar describing the service
210       type specific part of the service URL.
211
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
222
223
224
225
226 Kempf, et al.                Informational                      [Page 4]
227 \f
228 RFC 2926               Conversion of LDAP Schemas         September 2000
229
230
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".
234
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:
238
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       )
246
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       )
254
255    The template-url-syntax definition in the SLP template is described
256    by the following attribute:
257
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       )
266
267    The template-description attribute is translated into the X.520
268    standard attribute "description" [3].
269
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.
277
278
279
280
281
282 Kempf, et al.                Informational                      [Page 5]
283 \f
284 RFC 2926               Conversion of LDAP Schemas         September 2000
285
286
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:
290
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.
295
296       Attribute Type - The SLP attribute type is mapped into the LDAP
297       attribute type.
298
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.
303
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.
308
309       Descriptive Text - The SLP template descriptive text should be
310       mapped into the DESC field.
311
312    We discuss mapping of types, flags, default and allowed values, and
313    descriptive text in the subsections below.
314
315    OIDs for SLP template conversion schema elements are standardized
316    under the enterprise number of SrvLoc.Org (6252) [18].
317
318    For purposes of representing an SLP entry, we also define two
319    standardized LDAP syntaxes and attributes with standardized OIDs.
320
321       ( 1.3.6.1.4.1.6252.2.27.6.2.2
322         DESC 'SLP Service Type'
323       )
324
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].
327
328       ( 1.3.6.1.4.1.6252.2.27.6.2.3
329         DESC 'SLP Scope'
330       )
331
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].
334
335
336
337
338 Kempf, et al.                Informational                      [Page 6]
339 \f
340 RFC 2926               Conversion of LDAP Schemas         September 2000
341
342
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       )
351
352    Defines an attribute for the service type name.
353
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       )
360
361    Defines a multivalued attribute for the scopes.
362
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:
367
368          (service-advert-service-type=service:printer:*)
369
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:
375
376       ( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator')
377
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].
381
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       )
388
389       This attribute contains the SLP URL authenticator, as defined in
390       RFC 2608, Section 9.2 [5].
391
392
393
394 Kempf, et al.                Informational                      [Page 7]
395 \f
396 RFC 2926               Conversion of LDAP Schemas         September 2000
397
398
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       )
405
406       This attribute contains the SLP attribute authenticator, as
407       defined in RFC 2608, Section 9.2 [5].
408
409 2.1 Mapping from SLP Attribute Types to LDAP Attribute Types
410
411    We define the mapping from SLP attribute types to LDAP as follows:
412
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
420
421    The following subsections discuss further details of the mapping.
422
423 2.1.1 Integer
424
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.
428
429 2.1.2 String
430
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.
435
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.
442
443
444
445
446
447
448
449
450 Kempf, et al.                Informational                      [Page 8]
451 \f
452 RFC 2926               Conversion of LDAP Schemas         September 2000
453
454
455 2.1.3 Boolean
456
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.
460
461    The SLP Boolean type maps directly into an LDAP BOOLEAN. The
462    caseIgnoreMatch rule is used for equality matching.
463
464 2.1.4 Opaque
465
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.
469
470 2.2 Keyword Attributes
471
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).
477
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".
483
484 2.3 Template Flags
485
486    SLP template flags can be handled as described in the following
487    subsections.
488
489 2.3.1 Multi-valued
490
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.
493
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.
497
498
499
500
501
502
503
504
505
506 Kempf, et al.                Informational                      [Page 9]
507 \f
508 RFC 2926               Conversion of LDAP Schemas         September 2000
509
510
511 2.3.2 Optional
512
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".
517
518 2.3.3 Literal
519
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.
526
527 2.3.4 Explicit Matching
528
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.
537
538 2.4 Default and Allowed Value Lists
539
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.
547
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.
555
556
557
558
559
560
561
562 Kempf, et al.                Informational                     [Page 10]
563 \f
564 RFC 2926               Conversion of LDAP Schemas         September 2000
565
566
567 2.5 Descriptive Text
568
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.
572
573 2.6 Generating LDAP Attribute OIDs
574
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.
584
585 2.7 Example
586
587    The template included below is a hypothetical abstract printer
588    service template, similar to that described in [10].
589
590       template-type = printer
591
592       template-version = 0.0
593
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.
600
601       template-url-syntax =
602       ;The URL syntax is specific to the printing protocol being
603       ;employed
604
605       description = STRING
606       # This attribute is a free form string that can contain any
607       # site-specific descriptive information about this printer.
608
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
613
614
615
616
617
618 Kempf, et al.                Informational                     [Page 11]
619 \f
620 RFC 2926               Conversion of LDAP Schemas         September 2000
621
622
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.
629
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
634
635       printer-priority-queue = BOOLEAN O
636       FALSE
637       # TRUE indicates this printer or print queue is a priority
638       # queuing device.
639
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
646
647       printer-paper-output = STRING M L O
648       standard
649       # This attribute describes the mode in which pages output
650       # are arranged.
651
652       standard, noncollated sort, collated sort, stack, unknown
653
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:
657
658       template-type = printer:lpr
659
660       template-version = 0.0
661
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.
666
667       template-url-syntax = queue
668       queue = ;The queue name, see RFC 1179.
669
670
671
672
673
674 Kempf, et al.                Informational                     [Page 12]
675 \f
676 RFC 2926               Conversion of LDAP Schemas         September 2000
677
678
679    The LDAP class definition for the "service:printer:lpr" concrete
680    service type is translated as follows:
681
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.
688
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    )
697
698    The attribute definitions are translated as follows:
699
700    ( ---place the assigned OID here---
701      NAME 'printer-security-mechanisms-supported'
702      DESC 'Description: This attribute indicates the security mechanisms
703            supported.
704
705            Default: value
706
707            Allowed: tls, ssl, http-basic, http-digest, none
708
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    )
715
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.
723
724
725
726
727
728
729
730 Kempf, et al.                Informational                     [Page 13]
731 \f
732 RFC 2926               Conversion of LDAP Schemas         September 2000
733
734
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    )
741
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    )
754
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    )
763
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.
770
771            Default: 1
772
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    )
778
779
780
781
782
783
784
785
786 Kempf, et al.                Informational                     [Page 14]
787 \f
788 RFC 2926               Conversion of LDAP Schemas         September 2000
789
790
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.
796
797            Default: standard
798
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    )
807
808 3.0 Attribute Name Conflicts
809
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.
819
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.
824
825 4.0 Mapping from Schema to Templates
826
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.
832
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
838
839
840
841
842 Kempf, et al.                Informational                     [Page 15]
843 \f
844 RFC 2926               Conversion of LDAP Schemas         September 2000
845
846
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.
850
851    The following subsections deal with both LDAP and ASN.1 attribute
852    data type mappings.
853
854 4.1 Mapping LDAP Attribute Syntaxes to SLP Attribute Types
855
856    The following table contains the mappings for LDAP syntaxes to SLP
857    data types:
858
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
895
896
897
898 Kempf, et al.                Informational                     [Page 16]
899 \f
900 RFC 2926               Conversion of LDAP Schemas         September 2000
901
902
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
927
928 4.2 Mapping ASN.1 Types to SLP Types
929
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.
934
935    As sample of some ASN.1 encodings and their mappings to SLP:
936
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
945
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
951
952
953
954 Kempf, et al.                Informational                     [Page 17]
955 \f
956 RFC 2926               Conversion of LDAP Schemas         September 2000
957
958
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.
962
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.
965
966 4.2.1 Integer
967
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.
972
973 4.2.2 Boolean
974
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.
981
982 4.2.3 Enumerated
983
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.
994
995    Example:
996
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
1005
1006
1007
1008
1009
1010 Kempf, et al.                Informational                     [Page 18]
1011 \f
1012 RFC 2926               Conversion of LDAP Schemas         September 2000
1013
1014
1015 4.2.4 Object Identifier
1016
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".
1024
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
1028
1029       identifier = STRING
1030       # ASN.1: OID
1031       # The object identifier for this SNMP agent.
1032
1033 4.2.5 Octet String
1034
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.
1039
1040 4.2.6 Real
1041
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:
1046
1047       weight = STRING
1048       # ASN.1: Real
1049       # The objects weight in pounds.
1050
1051 4.3 Example ASN.1 Schema
1052
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
1062
1063
1064
1065
1066 Kempf, et al.                Informational                     [Page 19]
1067 \f
1068 RFC 2926               Conversion of LDAP Schemas         September 2000
1069
1070
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          }
1086
1087
1088          - The mount host.
1089          mountHost       ATTRIBUTE ::= {
1090                          WITH SYNTAX caseIgnoreString
1091                          EQUALITY MATCHING RULE caseIgnoreMatch
1092                          SINGLE VALUE
1093                          ID { <oid2> }
1094          }
1095
1096
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          }
1104
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          }
1116
1117
1118
1119
1120
1121
1122 Kempf, et al.                Informational                     [Page 20]
1123 \f
1124 RFC 2926               Conversion of LDAP Schemas         September 2000
1125
1126
1127          - Options for the mount operation.
1128          mountOption     ATTRIBUTE ::= {
1129                          WITH SYNTAX caseIgnoreString
1130                          EQUALITY MATCHING RULE caseIgnoreString
1131                          ID { <oid5> }
1132          }
1133
1134
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          }
1142
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          }
1150
1151    The translated SLP template is:
1152
1153       template-type = mount
1154
1155       template-version = 1.0
1156
1157       template-description = "Describes a remote filesystem access
1158       protocol"
1159
1160       template-url-syntax =
1161                    filesystem   = 1*[ DIGIT / ALPHA ]
1162                    urlpath = "/" filesystem
1163
1164       mountHost = STRING L
1165       # ASN.1: Case Ignore String, Single Value
1166       # The mount host
1167
1168       mountDirectory = STRING L
1169       # ASN.1: Case Ignore String, Single Value
1170       # The filesystem to mount
1171
1172
1173
1174
1175
1176
1177
1178 Kempf, et al.                Informational                     [Page 21]
1179 \f
1180 RFC 2926               Conversion of LDAP Schemas         September 2000
1181
1182
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
1189
1190       mountOption = STRING M O L
1191       # ASN.1: Case Ignore String
1192       # mount options for this filesystem
1193
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
1199
1200       mountPassNo = INTEGER O
1201       # ASN.1: Integer, Single Value
1202       # Boot time mount pass number
1203
1204 5.0 Representing SLP Service Advertisements in an LDAP DIT
1205
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.
1214
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.
1220
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.
1228
1229
1230
1231
1232
1233
1234 Kempf, et al.                Informational                     [Page 22]
1235 \f
1236 RFC 2926               Conversion of LDAP Schemas         September 2000
1237
1238
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:
1243
1244    "labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar,
1245    dc=com"
1246
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.
1250
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:
1254
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
1261
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:
1266
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))
1272
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.
1281
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.
1286
1287
1288
1289
1290 Kempf, et al.                Informational                     [Page 23]
1291 \f
1292 RFC 2926               Conversion of LDAP Schemas         September 2000
1293
1294
1295 6.0 Internationalization Considerations
1296
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].
1300
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:
1307
1308       (address;lang-de=44 Bahnhofstrasse, 2365 Weibstadt, Deutschland)
1309
1310    An attribute with a language tag in a specific locale is considered a
1311    separate attribute from attributes in other locales.
1312
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.
1316
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.
1324
1325 7.0 Security Considerations
1326
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.
1334
1335 Acknowledgements
1336
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.
1340
1341
1342
1343
1344
1345
1346 Kempf, et al.                Informational                     [Page 24]
1347 \f
1348 RFC 2926               Conversion of LDAP Schemas         September 2000
1349
1350
1351 8.0 References
1352
1353    [1]  Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
1354         service: Schemes", RFC 2609, April 1999.
1355
1356    [2]  Wahl, W., Howes, T. and S. Kille, "Lightweight Directory Access
1357         Protocol (v3)", RFC 2251, December 1997.
1358
1359    [3]  International Telecommunications Union. The Directory:Selected
1360         Attribute Types.  ITU Recommendation X.520. August, 1997.
1361
1362    [4]  McLaughlin, L., "Line Printer Daemon Protocol, RFC 1179, August
1363         1990.
1364
1365    [5]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
1366         Location Protocol Version 2", RFC 2608, April 1999.
1367
1368    [6]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
1369         Specifications: ABNF", RFC 2234, November 1997.
1370
1371    [7]  Howes, T., "The String Representation of LDAP Search Filters",
1372         RFC 2254, December 1997.
1373
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.
1377
1378    [9]  ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1) -
1379         Specification of Basic Notation. 1994.
1380
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.
1384
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.
1388
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.
1392
1393    [13] Alvestrand, H., "Tags for the Identification of Languages", RFC
1394         1766, December 1997.
1395
1396    [14] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC
1397         2596, May 1999.
1398
1399
1400
1401
1402 Kempf, et al.                Informational                     [Page 25]
1403 \f
1404 RFC 2926               Conversion of LDAP Schemas         September 2000
1405
1406
1407    [15] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
1408         "Authentication Methods for LDAP", RFC 2829, May 2000.
1409
1410    [16] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
1411         Levels", BCP 14, RFC 2119, March 1997.
1412
1413    [17] Dubuisson, O. ASN.1: Communication between Heterogeneous
1414         Systems. OSS Nokalva, 2000.
1415
1416    [18] http://www.srvloc.org
1417
1418 9.0 Authors' Addresses
1419
1420    James Kempf
1421    Sun Microsystems
1422    901 San Antonio Avenue
1423    Palo Alto, CA 94303
1424    USA
1425
1426    Phone: +1 650 786-5890
1427    EMail: james.kempf@sun.com
1428
1429
1430    Ryan Moats
1431    Coreon, Inc.
1432    15621 Drexel Circle
1433    Omaha, NE, 68135
1434    USA
1435
1436    EMail: rmoats@coreon.net
1437
1438
1439    Pete St. Pierre
1440    Sun Microsystems
1441    901 San Antonio Avenue
1442    Palo Alto, CA 94303
1443    USA
1444
1445    Phone: +1 415 786-5790
1446    EMail: Pete.StPierre@Eng.Sun.COM
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Kempf, et al.                Informational                     [Page 26]
1459 \f
1460 RFC 2926               Conversion of LDAP Schemas         September 2000
1461
1462
1463 10.  Full Copyright Statement
1464
1465    Copyright (C) The Internet Society (2000).  All Rights Reserved.
1466
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.
1480
1481    The limited permissions granted above are perpetual and will not be
1482    revoked by the Internet Society or its successors or assigns.
1483
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.
1490
1491 Acknowledgement
1492
1493    Funding for the RFC Editor function is currently provided by the
1494    Internet Society.
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514 Kempf, et al.                Informational                     [Page 27]
1515 \f