idnits 2.17.1 draft-ietf-svrloc-template-conversion-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([3], [5], [18], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 120 has weird spacing: '...reverse may n...' == Line 239 has weird spacing: '... at the begin...' == Line 692 has weird spacing: '... binary value...' == Line 1211 has weird spacing: '...sun.com rmo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '17' is defined on line 1169, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (ref. '2') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2254 (ref. '7') (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2252 (ref. '8') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- No information found for draft-ietf-svrloc-printer-scheme-xx - is the name correct? ** Obsolete normative reference: RFC 1766 (ref. '13') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2596 (ref. '14') (Obsoleted by RFC 3866) -- No information found for draft-ietf-ldapext-authmeth-xx - is the name correct? Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT James Kempf 3 Category: Informational Sun Microsystems, Inc. 4 Title: draft-ietf-svrloc-template-conversion-08.txt Ryan Moats 5 Date: July 2000 Coreon, Inc. 6 Pete St. Pierre 7 Sun Microsystems, Inc. 9 Conversion of LDAP Schemas to and from SLP Templates 11 Status of this Memo 13 This document is an individual contribution for consideration by the 14 SrvLoc Working Group of the Internet Engineering Task Force. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Copyright (C) The Internet Society 1999. All Rights Reserved. 39 Abstract 41 This document describes a procedure for mapping between SLP service 42 advertisments and LDAP descriptions of services. The document covers 43 two aspects of the mapping. One aspect is mapping between SLP service 44 type templates and LDAP directory schema. Because the SLP service 45 type template grammer is relatively simple, mapping from service type 46 templates to LDAP types is straightforward. Mapping in the other 47 direction is straightforward if the attributes are restricted to use 48 just a few of the syntaxes defined in RFC 2252. If arbitrary ASN.1 49 types occur in the schema, then the mapping is more complex and may 50 even be impossible. The second aspect is representation of service 51 information in an LDAP directory. The recommended representation 52 simplifies interoperability with SLP by allowing SLP directory agents 53 to backend into LDAP directory servers. The resulting system allows 54 service advertisements to propagate easily between SLP and LDAP. 56 Table of Contents 58 1.0 Introduction 59 2.0 Mapping SLP Templates to LDAP Schema 60 2.1 Mapping from SLP Attribute Types to LDAP Attribute Types 61 2.1.1 Integer 62 2.1.2 String 63 2.1.3 Boolean 64 2.1.4 Opaque 65 2.2 Keyword Attributes 66 2.3 Template Flags 67 2.3.1 Multi-valued 68 2.3.2 Optional 69 2.3.3 Literal 70 2.3.4 Explicit Matching 71 2.4 Default and Allowed Value Lists 72 2.5 Descriptive Text 73 2.6 Generating LDAP Attribute OIDs 74 2.7 Example 75 3.0 Attribute Name Conflicts 76 4.0 Mapping from Schema to Templates 77 4.1 Mapping LDAP Attribute Types to SLP Attribute Types 78 4.2 Mapping ASN.1 Types to SLP Types 79 4.2.1 Integer 80 4.2.2 Boolean 81 4.2.3 Enumerated 82 4.2.4 Object Identifier 83 4.2.5 Octet String 84 4.2.6 Real 85 4.3 Example ASN.1 Schema 86 5.0 Representing SLP Service Advertisements in an LDAP DIT 87 6.0 Internationalization Considerations 88 7.0 Security Considerations 89 8.0 References 90 9.0 Full Copyright Statement 91 10.0 Authors' Addresses 93 1.0 Introduction 95 SLP templates [1] are intended to create a simple encoding of the 96 syntactic and semantic conventions for individual service types, 97 their attributes, and conventions. They can easily be generated, 98 transmitted, read by humans and parsed by programs, as it is a string 99 based syntax with required comments. Directory schemas serve to 100 formalize directory entry structures for use with LDAP [2] These 101 directories serve to store information about many types of entities. 102 Network services are an example of one such entity. 104 Interoperability between SLP and LDAP is important so clients using 105 one protocol derive benefit from services registered through the 106 other. In addition, LDAP directory servers can serve as the backend 107 for SLP directory agents (DAs) if interoperability is possible In 108 order to facilitate interoperability, this document creates mappings 109 between the SLP template grammar and LDAP directory schema, and 110 establishes some conventions for representing service advertisements 111 in LDAP directories. The goal of the translation is to allow SLPv2 112 queries (which are syntactically and semantically equivalent to 113 LDAPv3 string queries [7]) to be submitted to an LDAP directory 114 server by an SLP DA backended into LDAP without extensive processing 115 by the DA. 117 The simple notation and syntactic/semantic attribute capabilities of 118 SLP templates map easily into directory schemas, and are easily 119 converted into directory schemas, even by automated means. The 120 reverse may not be true. If the LDAP schema contains attributes with 121 unrecognized or complex syntaxes, the translation may be difficult or 122 impossible. If, however, the LDAP schema only uses a few of the 123 common syntaxes defined in RFC 2252 [8], then the translation is 124 more straightforward. In addition, to foster complete 125 bidirectionality, the mapping must follow a very specific 126 representation in its DESC attributes. 128 This document outlines the correct mappings for SLP templates into 129 the syntactic representation specified for LDAP directory schema by 130 RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in 131 the X.209 specification [9], and is used by the LDAPv3 [2] directory 132 schema. Likewise, rules and guidelines are proposed to facilitate 133 consistent mapping of ASN.1 based schemas to be translated in the SLP 134 template grammar. Finally, a proposal for a representation of service 135 advertisements in LDAP directory services is made that facilitates 136 SLP interoperability. 138 Except when used as elements in the definition of LDAP schemas, the 139 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [16]. 143 2.0 Mapping SLP Templates to LDAP Schema 145 We define the following abstract object class as the parent class for 146 all services. Any specific service type is a subclass of this, with 147 its own attributes: 149 ( 1.3.6.1.4.1.6252.2.27.6.2.1 150 NAME 'slpService' 151 DESC 'parent superclass for SLP services' 152 ABSTRACT 153 SUP top 154 MUST ( template-major-version-number $ 155 template-minor-version-number $ 156 description $ 157 template-url-syntax $ 158 service-advert-service-type $ 159 service-advert-scopes ) 160 MAY ( service-advert-url-authenticator $ 161 service-advert-attribute-authenticator ) ) 163 The attributes correspond to various parts of the SLP service 164 template and SLP service advertisement. 166 SLP service type templates begin with four definitions that set the 167 context of the template: 169 template-type - This defines the service type of the template. The 170 service type can be a simple service type, like ``service:ftp'', an 171 abstract service type, like ``service:printer'' or a concrete 172 service type, like ``service:printer:lpr''. The type name can 173 additionally include a naming authority, for example 174 ``service:printer.sun:local''. The name that appears in this field 175 omits the ``service:'' prefix. 177 template-version - A string containing a major and minor version 178 number, separated by a period. 180 template-description - A block of human readable text describing 181 what the service type does. 183 template-url-syntax - An ABNF [6] grammer describing the service 184 type specific part of the service URL. 186 The SLP template-type definition is used as the name of the LDAP 187 object class for the template, a subclass of the ``slpService'' 188 class, together with the ``service'' prefix to indicate that the name 189 is for a service. In the translating service type name, colons and 190 the period separating the naming authority are converted into 191 hyphens. If the template defines an SLP concrete type, the concrete 192 type name is used; the abstract type name is never used. For 193 example, the template for ``service:printer:lpr'' is translated into 194 an LDAP object class called ``service-printer-lpr''. Furthermore, if 195 the type name contains a naming authority, the naming authority name 196 must be included. For example, the service type name 197 ``service:printer.sun:local'' becomes ``service-printer-sun-local''. 198 The LDAP object class is always ``STRUCTURAL''. 200 The template-version definition is partitioned into two attributes, 201 template-major-version-number and template-minor-version-number. The 202 LDAP definition for these attributes is: 204 ( 1.3.6.1.4.1.6252.2.27.6.1.1 205 NAME 'template-major-version-number' 206 DESC 'The major version number of the service type template' 207 EQUALITY integerMatch 208 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 209 SINGLE-VALUE 210 ) 212 ( 1.3.6.1.4.1.6252.2.27.6.1.2 213 NAME 'template-minor-version-number' 214 DESC 'The minor version number of the service type template' 215 EQUALITY integerMatch 216 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 217 SINGLE-VALUE 218 ) 220 The template-url-syntax definition in the SLP template is described 221 by the following attribute: 223 ( 1.3.6.1.4.1.6252.2.27.6.1.3 224 NAME 'template-url-syntax' 225 DESC 'An ABNF grammar describing the service type 226 specific part of the service URL' 227 EQUALITY caseExactIA5Match 228 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 229 SINGLE-VALUE 230 ) 232 The template-description attribute is translated into the X.520 233 standard attribute ``description'' [3]. 235 We further establish the convention that SLP template characteristics 236 that can't be translated into LDAP are inserted into the DESC field 237 of the object class definition. The items are separated by empty 238 lines (consisting of two "LINE FEED" characters), are preceded by a 239 LINE FEED character, and are tagged at the beginning of the line to 240 indicate what they represent. This allows the template to be 241 reconstructed from the schema by properly parsing the comments. 243 The bulk of an SLP template consists of attribute definitions. There 244 are four items in an SLP template attribute definition that need to 245 be mapped into LDAP: 247 Attribute Name - Since SLPv2 attribute names are defined to be 248 compatible with LDAPv3, SLP attributes map directly into LDAP 249 attributes with no change. Similarly, LDAP attributes map directly 250 to SLP attributes. 252 Attribute Type - The SLP attribute type is mapped into the LDAP 253 attribute type. 255 Attribute Flags - The SLP attribute flags are mapped into 256 characteristics of the LDAP attribute definition, or into the DESC 257 field if no equivalent LDAP attribute definition characteristic 258 occurs. 260 Default and Allowed Values - These must be handled by the client or 261 a DA enabled to handle templates, as in SLP. For reference, 262 however, they should be included in the DESC field of the LDAP 263 attribute definition. 265 Descriptive Text - The SLP template descriptive text should be 266 mapped into the DESC field. 268 We discuss mapping of types, flags, default and allowed values, and 269 descriptive text in the subsections below. 271 OIDs for SLP template conversion schema elements are standardized 272 under the enterprise number of SrvLoc.Org (6252) [18]. 274 For purposes of representing an SLP entry, we also define two 275 standardized LDAP syntaxes and attributes with standardized OIDs. 277 ( 1.3.6.1.4.1.6252.2.27.6.2.2 278 DESC 'SLP Service Type' 279 ) 281 Defines the syntax for the service type name. The syntax is defined 282 in the BNF for the service URL in RFC 2609 Section 2.1 [1]. 284 ( 1.3.6.1.4.1.6252.2.27.6.2.3 285 DESC 'SLP Scope' 286 ) 288 Defines the syntax for the scope name. The syntax is defined in the 289 BNF for scope names in RFC 2608 Section 6.4.1 [5]. 291 ( 1.3.6.1.4.1.6252.2.27.6.1.4 292 NAME 'service-advert-service-type' 293 DESC 'The service type of the service advertisement, including the 294 "service:" prefix.' 295 EQUALITY caseExactIA5Match 296 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.2 297 SINGLE-VALUE 298 ) 300 Defines an attribute for the service type name. 302 ( 1.3.6.1.4.1.6252.2.27.6.1.5 303 NAME 'service-advert-scopes' 304 DESC 'A list of scopes for a service advertisement.' 305 EQUALITY caseExactIA5Match 306 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3 307 ) 309 Defines a multivalued attribute for the scopes. 311 Searches for abstract types can be made with an LDAP query that 312 wildcards the concrete type. For example, a search for all service 313 advertisements of the printer abstract type can be made with the 314 following query: 316 (service-advert-service-type=service:printer:*) 318 SLP specifies that service URLs and attribute lists can be 319 accompanied by a structured authenticator consisting of a digital 320 signature and information necessary to verify the signature. A 321 syntax and two standardized SLP attributes are defined for this 322 purpose: 324 ( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator') 326 The syntax of an SLP authenticator is the bytes of the 327 authenticator in network byte order, see RFC 2608, Section 9.2 [5]. 329 ( 1.3.6.1.4.1.6252.2.27.6.1.6 330 NAME 'service-advert-url-authenticator' 331 DESC 'The authenticator for the URL, null if none.' 332 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3 333 SINGLE-VALUE 334 ) 336 This attribute contains the SLP URL authenticator, as defined in 337 RFC 2608, Section 9.2 [5]. 339 ( 1.3.6.1.4.1.6252.2.27.6.1.7 340 NAME 'service-advert-attribute-authenticator' 341 DESC 'The authenticator for the attribute list, null if none.' 342 SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3 343 SINGLE_VALUE 344 ) 346 This attribute contains the SLP attribute authenticator, as defined 347 in RFC 2608, Section 9.2 [5]. 349 2.1 Mapping from SLP Attribute Types to LDAP Attribute Types 351 We define the mapping from SLP attribute types to LDAP as follows: 353 SLP Type ASN.1 Type LDAP Type 354 --------------------------------------------------- 355 Integer INTEGER INTEGER 356 String DirectoryString Directory String 357 Boolean BOOLEAN Boolean 358 Opaque OCTET STRING Octet String 359 Keyword (N/A) IA5 String 361 The following subsections discuss further details of the mapping. 363 2.1.1 Integer 365 SLP integers compare as integers when performing a query. LDAP 366 integers behave similarly. Consequently, the mapping from the SLP 367 integer type to LDAP is INTEGER, with the integerMatch matching rule. 369 2.1.2 String 371 SLP strings are encoded as described in the SLP protocol 372 specification [5]. All value strings are considered case insensitive 373 for matching operations. SLP strings are not null terminated and are 374 encoded in UTF-8. 376 SLP strings are mapped to the LDAP Directory String type. The 377 Directory String type exactly matches the SLP string type, i.e. it is 378 a non-null terminated UTF-8 string. The caseIgnoreMatch equality 379 rule, caseIgnoreOrderingMatch ordering rule, and 380 caseIgnoreSubstringsMatch substring rule are used for comparing 381 string attribute values. 383 2.1.3 Boolean 385 Boolean attributes may have one of two possible values. In SLP, 386 these values are represented as strings, TRUE and FALSE. In SLP's 387 string encoding of a boolean value, case does not matter. 389 The SLP Boolean type maps directly into an LDAP BOOLEAN. The 390 caseIgnoreMatch rule is used for equality matching. 392 2.1.4 Opaque 394 SLP attribute values of type Opaque are represented as OCTET STRING 395 in LDAP, and the octetStringMatch matching rule is used to compare 396 them. 398 2.2 Keyword Attributes 400 SLP service type templates allow the definition of keyword 401 attributes. Keyword attributes are attributes whose only 402 characteristic is their presence. Keyword attributes have no flag 403 information, nor any default or allowed values (since, by definition, 404 they have no values). 406 ASN.1 has no concept of keyword attributes. Keyword attributes are 407 translated into a ``May'' clause in the ASN.1 class definition for 408 the service type. If the keyword attribute is present, then its value 409 is of no consequence, but for consistency we make it simply the NUL 410 character, ``\00''. 412 2.3 Template Flags 414 SLP template flags can be handled as described in the following 415 subsections. 417 2.3.1 Multi-valued 419 Multi-valued attributes are defined in an SLP template using the one 420 value. All values for a given attribute must be of the same type. 422 LDAP attribute definitions require that a single valued attribute 423 include the SINGLE-VALUE tag if the attribute is single valued. 424 Otherwise, the attribute is assumed to be multivalued by default. 426 2.3.2 Optional 428 SLP uses the 'O' flag to indicate an attribute may or may not be 429 present. These optional attributes are defined using the "May" 430 clause in the ASN.1 definition class definition for the service type. 431 All other attributes must be defined as a "Must". 433 2.3.3 Literal 435 ASN.1 does not have a mechanism to indicate that the values of an 436 attribute may not be translated from one language to another, since 437 ASN.1 schema are not typically translated. This flag is dropped when 438 translating a template, but presence of the flag should be noted in 439 the DESC field. It should be placed on a separate line and tagged 440 with ``Literal:'' so the template can be reconstructed from the 441 schema. 443 2.3.4 Explicit Matching 445 The SLP template syntax uses a flag of 'X' to indicate that an 446 attribute must be present in order for the query to be properly 447 satisfied. There is no provision for requiring that particular 448 attributes be in a query. Consequently, this flag is dropped when 449 translating a template, but presence of the flag should be noted in 450 the DESC field. It should be placed on a separate line and tagged 451 with ``Explicit:'' so the template can be reconstructed from the 452 schema. 454 2.4 Default and Allowed Value Lists 456 The SLP template grammar provides the capability to define default 457 and allowed values for an attribute. The SLP protocol does not 458 enforce these restrictions on registered attributes, however. The 459 default and allowed values may be used by client side applications, 460 or alternatively it may also be used by DAs to initialize 461 registrations having no attributes and to limit attribute values to 462 the template allowed values. 464 LDAP servers also do not support default and allowed values on 465 attributes. Therefore, enforcement of default and allowed values in 466 SLP templates is left up to the clients or a DA, if the DA is 467 backending into LDAP. The default and allowed values should be 468 included in the DESC field. The comments should be placed on separate 469 lines and labeled with the ``Default:'' and ``Allowed:'' tags to 470 allow reconstruction of the template. 472 2.5 Descriptive Text 474 The descriptive text associated with an attribute definition should 475 be included in the DESC field. It should start on a separate line and 476 begin with the ``Description:'' tag. 478 2.6 Generating LDAP Attribute OIDs 480 LDAP attributes require an OID. In general, there is no a priori way 481 that an algorithm can be defined for generating OIDs, because it will 482 depend on the conventions used by the organization developing the 483 template. In some cases, an organization's procedure for generating 484 OIDs may be regular enough that a template developer can 485 algorithmically generate OIDs off of an assigned root. Whatever means 486 is used, the template developer should assure that unique OIDs are 487 assigned to each SLP attribute that is translated into an LDAP 488 attribute. 490 2.7 Example 492 The template included below is a hypothetical abstract printer 493 service template, similar to that described in [10]. 495 template-type = printer 497 template-version = 0.0 498 template-description = 499 The printer service template describes the attributes 500 supported by network printing devices. Devices may be 501 either directly connected to a network, or connected to a 502 printer spooler that understands the a network queuing 503 protocol such as IPP, lpr or the Salutation Architecture. 505 template-url-syntax = 506 ;The URL syntax is specific to the printing protocol being 507 ;employed 509 description = STRING 510 # This attribute is a free form string that can contain any 511 # site-specific descriptive information about this printer. 513 printer-security-mechanisms-supported = STRING L M 514 none 515 # This attribute indicates the security mechanisms supported 516 tls, ssl, http-basic, http-digest, none 518 printer-operator = STRING O L M 519 # A person, or persons responsible for maintaining a 520 # printer on a day-to-day basis, including such tasks 521 # as filling empty media trays, emptying full output 522 # trays, replacing toner cartridges, clearing simple 523 # paper jams, etc. 525 printer-location-address = STRING O 526 # Physical/Postal address for this device. Useful for 527 # nailing down a group of printers in a very large corporate 528 # network. For example: 960 Main Street, San Jose, CA 95130 530 printer-priority-queue = BOOLEAN O 531 FALSE 532 # TRUE indicates this printer or print queue is a priority 533 # queuing device. 535 printer-number-up = INTEGER O 536 1 537 # This job attribute specifies the number of source 538 # page-images to impose upon a single side of an instance 539 # of a selected medium. 540 1, 2, 4 542 printer-paper-output = STRING M L O 543 standard 544 # This attribute describes the mode in which pages output 545 # are arranged. 547 standard, noncollated sort, collated sort, stack, unknown 549 We assume that the concrete type ``service:printer:lpr'' for printers 550 that speak the LPR protocol [4] has the following template 551 definition: 553 template-type = printer:lpr 555 template-version = 0.0 557 template-description = 558 The printer:lpr service template describes the attributes 559 supported by network printing devices that speak the 560 LPR protocol. No new attributes are included. 562 template-url-syntax = queue 563 queue = ;The queue name, see RFC 1179. 565 The LDAP class definition for the ``service:printer:lpr'' concrete 566 service type is translated as follows: 568 ( ---place the assigned OID here--- 569 NAME 'service-printer-lpr' 570 DESC 'Description: The printer:lpr service template 571 describes the attributes supported by network printing 572 devices that speak the LPR protocol. No new attributes 573 are included. 575 URL Syntax: queue 576 queue = ;The queue name, see RFC 1179.' 577 SUP slpService 578 MUST ( description $ security-mechanisms-supported $ 579 labeledURI) 580 MAY ( operator $ location-address $ priority-queue $ 581 number-up $ paper-output) 582 ) 584 The attribute definitions are translated as follows: 586 ( ---place the assigned OID here--- 587 NAME 'printer-security-mechanisms-supported' 588 DESC 'Description: This attribute indicates the security mechanisms 589 supported. 591 Default: value 592 Allowed: tls, ssl, http-basic, http-digest, none 594 Literal:' 595 EQUALITY caseIgnoreMatch 596 ORDERING caseIgnoreOrderingMatch 597 SUBSTR caseIgnoreSubstringsMatch 598 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 599 ) 601 ( ---place the assigned OID here--- 602 NAME 'printer-operator' 603 DESC 'Description: A person, or persons responsible for 604 maintaining a printer on a day-to-day basis, including 605 such tasks as filling empty media trays, emptying full 606 output trays, replacing toner cartridges, clearing simple 607 paper jams, etc. 609 Literal:' 610 EQUALITY caseIgnoreMatch 611 ORDERING caseIgnoreOrderingMatch 612 SUBSTR caseIgnoreSubstringsMatch 613 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 614 ) 616 ( --place the assigned OID here--- 617 NAME 'printer-location-address' 618 DESC 'Description Physical/Postal address for this device. 619 Useful for nailing down a group of printers in a very 620 large corporate network. For example: 960 Main Street, 621 San Jose, CA 95130.' 622 EQUALITY caseIgnoreMatch 623 ORDERING caseIgnoreOrderingMatch 624 SUBSTR caseIgnoreSubstringsMatch 625 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 626 SINGLE-VALUE 627 ) 629 ( ---place the assigned OID here--- 630 NAME 'printer-priority-queue' 631 DESC 'Description: TRUE indicates this printer or print 632 queue is a priority queuing device.' 633 EQUALITY booleanMatch 634 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 635 SINGLE-VALUE 636 ) 638 ( ---place the assigned OID here--- 639 NAME 'printer-number-up' 640 DESC 'Description: This job attribute specifies the number 641 of source page-images to impose upon a single side of 642 an instance of a selected medium. This attribute is 643 INTEGER. 645 Default: 1 647 Allowed: 1, 2, 3, 4' 648 EQUALITY integerMatch 649 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 650 SINGLE-VALUE 651 ) 653 ( ---place the assigned OID here--- 654 NAME 'printer-paper-output' 655 DESC 'Description: This attribute describes the mode in 656 which pages output are arranged. Default value is 657 standard. 659 Default: standard 661 Allowed: standard, noncollated sort, collated sort, 662 stack, unknown. 663 Literal:' 664 EQUALITY caseIgnoreMatch 665 ORDERING caseIgnoreOrderingMatch 666 SUBSTR caseIgnoreSubstringsMatch 667 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 668 ) 670 3.0 Attribute Name Conflicts 672 LDAP has a flat name space, and attribute names and OIDs must be 673 unique in a directory server. In order to avoid name conflicts in the 674 translation of SLP templates to LDAP schemas, template developers may 675 want to consider prepending the name of the service type to the 676 attribute. Postprocessing attribute names to make them unique when 677 translated is not possible, because it would require the DA to 678 rewrite queries before submitting them to the directory server. In 679 addition, developers should use standard LDAP attributes when such 680 attributes are available. 682 In the above example template, the abstract type name ``printer'' is 683 prepended to attributes to avoid conflicts. The standard 684 ``description'' attribute defined by X.520 [3] is used to translate 685 the template description attribute. 687 4.0 Mapping from Schema to Templates 688 The reverse mapping from LDAP schema to SLP service type templates 689 requires dealing with both LDAP and ASN.1 data types. RFC 2252 690 defines 33 attribute syntaxes that should be supported by LDAP 691 directory servers. These syntaxes are defined using BNF for strings 692 or using ASN.1 for binary valued attributes defined by X.520. 694 Mapping of the LDAP data types into SLP template types is fairly 695 straightforward, but mapping arbitrary ASN.1 data types is somewhat 696 more complicated and requires encoding the ASN.1 data type into a 697 string. To a certain extent, this masks the ASN.1 data type because 698 it becomes impossible to distinguish between a native string having 699 content equivalent to an encoded ASN.1 string. However, inclusion of 700 the ASN.1 data type in the comment provides additional information 701 should a reverse transformation from SLP to ASN.1 be required. 703 The following subsections deal with both LDAP and ASN.1 attribute 704 data type mappings. 706 4.1 Mapping LDAP Attribute Syntaxes to SLP Attribute Types 708 The following table contains the mappings for LDAP syntaxes to SLP 709 data types: 711 LDAP Type SLP Type 712 -------------------------------------------------------- 713 ACI Item NA 714 Access Point NA 715 Attribute Type Description NA 716 Audio Opaque 717 Binary ASN.1 escape 718 Bit String String 719 Boolean Boolean 720 Certificate Opaque 721 Certificate List Opaque 722 Certificate Pair Opaque 723 Country String String 724 DN String 725 Data Quality Syntax NA 726 Delivery Method NA 727 Directory String String 728 DIT Content Rule Description NA 729 DIT Structure Rule Description NA 730 DL Submit Permission NA 731 DSA Quality Syntax NA 732 Enhanced Guide NA 733 Facsimile Telephone Number String 734 Fax Opaque 735 Generalized Time String 736 Guide NA 737 IA5 String String 738 INTEGER Integer 739 JPEG Opaque 740 LDAP Syntax Description NA 741 LDAP Schema Definition NA 742 LDAP Schema Description NA 743 Master and Shadow Access Points NA 744 Matching Rule Description NA 745 Matching Rule Use Description NA 746 Mail Preference NA 747 MHS OR Address String 748 Modify Rights NA 749 Name and Optional UID NA 750 Name Form Description NA 751 Numeric String String 752 Object Class Description NA 753 Octet String Opaque 754 OID String 755 Other Mailbox String 756 Postal Address String 757 Protocol Information NA 758 Presentation Address String 759 Printable String String 760 Substring Assertion NA 761 Subtree Specification NA 762 Supplier Information NA 763 Supplier or Consumer NA 764 Supplier And Consumer NA 765 Supported Algorithm NA 766 DSE Type NA 767 Telephone Number String 768 Teletex Terminal Identifier String 769 Telex Number String 770 UTC Time String 772 4.2 Mapping ASN.1 Types to SLP Types 774 ASN.1 employs a much richer set of data types than provided by SLP. 775 The table below show the mapping of selected ASN.1 data type to their 776 nearest SLP equivalent. Because of the complexity and flexibility of 777 ASN.1, a complete list cannot be provided. 779 As sample of some ASN.1 encodings and their mappings to SLP: 781 ASN.1 type SLP type 782 ----------------------------------------- 783 INTEGER Integer 784 BOOLEAN Boolean 785 ENUMERATED String 786 OBJECT IDENTIFIER String 787 OCTET STRING Opaque 788 REAL String 790 Data types that do not map directly to SLP data types should be 791 defined as either a String, or as Opaque. ASN.1 types that may only 792 contain valid characters for Strings, as defined in X.680 [9] should 793 be encoded as strings. ASN.1 types such as GraphicString that change 794 their character set encoding in part way through a value should not 795 be encoded as strings, however, If such types are required, the SLP 796 Opaque type should be used. In either case, the first line of the 797 help text is used to indicate the original ASN.1 data type. 799 The following subsections describe how to convert from the ASN.1 BER 800 [9] to the SLP template for the different types in the table above. 802 4.2.1 Integer 804 Both SLP templates and ASN.1 support Integers, so there is a one to 805 one mapping between an SLP Integer attribute and an ASN.1 Integer 806 attribute. Details on the encoding of integers is summarized in the 807 SLP template to ASN.1 section above. 809 4.2.2 Boolean 811 Boolean values are supported by both SLP and ASN.1, though on wire 812 encodings differ. X.680 [9] specifies zero and non-zero encoding for 813 booleans, where SLP encodes booleans using the strings TRUE and 814 FALSE. In general, most LDAP servers will use the LDAP Boolean type 815 (which is a string), so again the ASN.1 type should be recorded in 816 the comment or it will be lost. 818 4.2.3 Enumerated 820 SLP templates support the concept of enumerations through the listing 821 of allowed values in the attribute definition. These enumerations 822 are not strictly binding on clients or DAs, but they are similar to 823 the ASN.1 definition of enumerations. BER encodes the ASN.1 824 enumeration by passing the number of the element's position in the 825 enumeration. This requires both sides to have knowledge of the 826 specific enumeration prior to decoding an enumeration's value. SLP 827 provides no specific support for transmitting enumerations. They are 828 simply String types. Information on the ASN.1 type and ASN.1 encoding 829 of the enumeration values is recorded in the comment. 831 Example: 833 color-supported = STRING M 834 none 835 # ASN.1: Enumeration. 836 # ASN.1 Mapping: none = 0, highlight = 1, three color = 2, four color = 4, 837 # monochromatic = 5 838 #This attribute specifies whether the Printer supports 839 # color and, if so, what type. 840 none,highlight,three color,four color,monochromatic 842 4.2.4 Object Identifier 844 Object identifiers(OIDs) are commonly used in the ASN.1 world to 845 identify object and attributes. OIDs are a numerical representation 846 of an element's place in the naming hierarchy. Each element at a 847 particular level of a hierarchy has a unique number assigned within 848 that level of the hierarchy. A sample OID would be the naming tree 849 for SNMP MIBs: iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would 850 be written as the string ``1.3.6.1.2.1''. 852 Because this representation reduces down to a string of dot separated 853 numbers, this maps easily to the SLP String type. The help text for 854 this element should indicate it is an ASN.1 OID 856 identifier = STRING 857 # ASN.1: OID 858 # The object identifier for this SNMP agent. 860 4.2.5 Octet String 862 An ASN.1 octet string should be mapped to an Opaque in an SLP 863 template. An octet string is a sequence of bytes, whereas an Opaque 864 is a a string that encodes a sequence of bytes. Again, the ASN.1 type 865 is lost unless recorded in the comment. 867 4.2.6 Real 869 There is no direct mapping between floating point numbers and any SLP 870 data types. Attributes having the ASN.1 type of Real are mapped to 871 SLP type String. Comments are added to the attribute help text 872 indicating the value was originally an ASN.1 real. For example: 874 weight = STRING 875 # ASN.1: Real 876 # The objects weight in pounds. 878 4.3 Example ASN.1 Schema 880 The following is an example schema for an exported filesystem. The 881 section presents it as in ASN.1 and the following section shows the 882 SLP template translation. The template translation does not capture 883 the actual attribute format for the Set type, that would be done in 884 the LDAP client software making the translation. Note that even 885 though the class definition does not conform with the previously 886 defined conventions for SLP classes, the schema can still be 887 translated into an SLP template. The syntax used in this example 888 follows 890 -- Abstraction of a fstab entry (a "mount"). 891 -- These lookups would likely be performed by an 892 -- an automounter type application. 893 mount OBJECT-CLASS ::= { 894 SUBCLASS OF { top } 895 MUST CONTAIN { mountHost | 896 mountDirectory | 897 mountType 898 } 899 MAY CONTAIN { mountOption | 900 mountDumpFrequency | 901 mountPassNo 902 } 903 ID { } 904 } 906 - The mount host. 907 mountHost ATTRIBUTE ::= { 908 WITH SYNTAX caseIgnoreString 909 EQUALITY MATCHING RULE caseIgnoreMatch 910 SINGLE VALUE 911 ID { } 912 } 914 - The file system to mount. 915 mountDirectory ATTRIBUTE ::= { 916 WITH SYNTAX caseIgnoreString 917 EQUALITY MATCHING RULE caseIgnoreMatch 918 SINGLE VALUE 919 ID { } 920 } 921 - The type of file system being mounted. 922 mountType ATTRIBUTE ::= { 923 WITH SYNTAX INTEGER { ufs(1), 924 hsfs(2), 925 nfs(3), 926 rfs(4) 927 } 928 EQUALITY MATCHING RULE integerMatch 929 SINGLE VALUE 930 ID { } 931 } 933 - Options for the mount operation. 934 mountOption ATTRIBUTE ::= { 935 WITH SYNTAX caseIgnoreString 936 EQUALITY MATCHING RULE caseIgnoreString 937 ID { } 938 } 940 - How often to dump the file system. 941 mountDumpFrequency ATTRIBUTE :: = { 942 WITH SYNTAX INTEGER (0..9) 943 EQUALITY MATCHING RULE integerMatch 944 SINGLE VALUE 945 ID { } 946 } 948 - Boot time mount pass number. 949 mountPassNo ATTRIBUTE ::= { 950 WITH SYNTAX INTEGER 951 EQUALITY MATCHING RULE integerMatch 952 SINGLE VALUE 953 ID { } 954 } 956 The translated SLP template is: 958 template-type = mount 960 template-version = 1.0 962 template-description = "Describes a remote filesystem access protocol" 964 template-url-syntax = 965 filesystem = 1*[ DIGIT / ALPHA ] 966 urlpath = "/" filesystem 968 mountHost = STRING L 969 # ASN.1: Case Ignore String, Single Value 970 # The mount host 972 mountDirectory = STRING L 973 # ASN.1: Case Ignore String, Single Value 974 # The filesystem to mount 976 mountType = STRING L 977 ufs 978 # ASN.1: Enumeration, Single Value 979 # ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4 980 # The type of the filesystem being mounted 981 ufs, hsfs, nfs, rfs 983 mountOption = STRING M O L 984 # ASN.1: Case Ignore String 985 # mount options for this filesystem 987 mountDumpFrequency = INTEGER O 988 0 989 # ASN.1: Integer Range, Single Value 990 # How often to dump this filesystem 991 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 993 mountPassNo = INTEGER O 994 # ASN.1: Integer, Single Value 995 # Boot time mount pass number 997 5.0 Representing SLP Service Advertisments in an LDAP DIT 999 In addition to translating between SLP templates and LDAP schema, 1000 another area requiring compatibility is the representation of SLP 1001 service advertisements in an LDAP DIT. A standardized representation 1002 for service information allows SLP DAs to store service 1003 advertisements in LDAP, and for LDAP clients to query the DIT for 1004 those services. Similarly, if LDAP clients represent service 1005 information in the same form, SLP clients can benefit from 1006 interoperability. 1008 A service advertisement contains the service URL in a 'labeledURI' 1009 attribute [11]. The labeledURI attribute in a service advertisement 1010 should only contain the service URL for the service, with no 1011 additional label. It is recommended that the labeledURI be used as 1012 the RDN for the service object in the DIT. 1014 Although service advertisements can appear anywhere within the DIT, 1015 it is recommended that all services be stored under a single common 1016 point, or root node, to facilitate searching in a domain. This allows 1017 a client to search for all of advertisements of a particular service 1018 type, say, for all printers. The recommended parent entry is one 1019 named "ou=service" below the entry which is the representation of the 1020 domain, as described in RFC 2247. 1022 For example, a printer service with labeledURI of 1023 "service:lpr://printsrv/queue1" in the domain foobar.com advertised 1024 in the LDAP server that holds the entry "dc=foobar,dc=com" tree has 1025 the following DN: 1027 "labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar, dc=com" 1029 While this leads to a flat space of service storage, since SLP uses 1030 search filters from LDAP for searches, these filters can be used for 1031 one-level searches from the root node. 1033 The following example illustrates how an advertisement having a 1034 simple service type is represented. The advertisment (in conceptual 1035 form) for a printer is: 1037 Service Type: service:lpr://printsrv/queue1 1038 Scopes: eng,corp 1039 Attributes: 1040 description = A general printer for all to use. 1041 security-mechanisms-supported = none 1042 Authentication: none 1044 The RDN of the object is labeledURI=service:lpr://printsrv/queue1, 1045 and the following LDAP search filter will return this object, along 1046 with any others of the service type ``service:lpr'' that match the 1047 other attributes: 1049 (&(service-advert-service-type=service:lpr) 1050 (service-advert-scopes=eng) 1051 (service-advert-scopes=corp) 1052 (description=A general printer for all to use.) 1053 (security-mechanisms-supported=none)) 1055 Service advertisements in SLP also have a lease time associated with 1056 them. In LDAP servers that support the extensions for dynamic 1057 directory services [12], the service advertisement entry objectClass 1058 should be extended with the dynamicObject class. This allows the 1059 service advertisment to time out within the LDAP directory server. If 1060 the LDAP directory server does not support the dynamic directory 1061 services extension, then advertisement lease timeouts must be handled 1062 by the SLP agent. 1064 While the service advertisement schema outlined in this section is 1065 primarily for SLP DAs that use LDAP as a backing store, if LDAP 1066 agents register services using the same format, complete 1067 interoperability with SLP is achieved. 1069 6.0 Internationalization Considerations 1071 SLP specifies that an RFC 1766 [13] language code accompanies every 1072 service advertisement. Language codes for service advertisements in 1073 LDAP must be represented according to RFC 2596 [14]. 1075 RFC 2596 prohibits language codes in DNs, and specifies that a 1076 directory server which does not support language codes must treat an 1077 attribute with a language code as an unrecognized attributes. 1078 According to RFC 2596, language codes are appended to attribute names 1079 with a semicolon (``;''). For example, the following attribute/value 1080 pair is in the German locale: 1082 (address;lang-de=44 Bahnhofstrasse, 2365 Weibstadt, Deutschland) 1084 An attribute with a language tag in a specific locale is considered a 1085 separate attribute from attributes in other locales. 1087 If the service advertisement is in the default SLP locale (``en'', no 1088 dialect), then the language code need not be appended to the 1089 attribute name. 1091 SLP queries in locales other than the default need not be rewritten 1092 to include language tags before being submitted to the directory 1093 server. RFC 2596 specifies that all entries that match are returned, 1094 including those with language tags, without requiring the language 1095 tags to be explicitly present in the query. The SLP DA can then 1096 postprocess the result to select the entries from the required 1097 locale. 1099 7.0 Security Considerations 1101 SLP authenticators are stored with the service advertisement in the 1102 DIT, as discussed in Section~7ef{slpdit}. LDAP clients need to use 1103 LDAP authentication [15] to assure that they are connecting with a 1104 secure server. In particular, SLP DAs that use LDAP as a back end 1105 store and that implement SLP authentication MUST use LDAP 1106 authentication to assure that the LDAP entries for their service 1107 registrations are secure. 1109 Acknowledgements 1110 Many thanks are due to Mark Wahl whose detailed and insightful 1111 comments were instrumental in helping improve the technical accuracy 1112 of this draft with respect to LDAP. 1114 8.0 References 1116 [1] E. Guttman, C. Perkins, J. Kempf. Service Templates and service: 1117 Schemes. RFC 2609, April, 1999. 1119 [2] M. Wahl, T. Howes, and S. Kille. Lightweight Directory Access 1120 Protocol (v3). RFC 2251, December, 1997. 1122 [3] International Telecommunications Union. The Directory:Selected 1123 Attribute Types. ITU Recommendation X.520. August, 1997. 1125 [4] L. McLaughlin. Line Printer Daemon Protocol. RFC 1179. August, 1126 1990. 1128 [5] E. Guttman, C ~Perkins, J. Veizades, and M. Day. Service Location 1129 Protocol Version 2. RFC 2608. April, 1999. 1131 [6] D. Crocker and P. Overell. Augmented BNF for Syntax 1132 Specifications: ABNF. RFC 2234. November, 1997. 1134 [7] T. Howes. The String Representation of LDAP Search Filters. RFC 1135 2254. December, 1997. 1137 [8] M. Wahl, A. Coulbeck, T. Howe, and S. Kille. Lightweight 1138 Directory Access Protocol (v3): Attribute Syntax Definition. RFC 1139 2252. December, 1997. 1141 [9] ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1) - 1142 Specification of Basic Notation. 1994. 1144 [10] P. St. Pierre, S. Isaccson, I. McDonald. Definition of printer: 1145 URLs for use with Service Location. draft-ietf-svrloc-printer- 1146 scheme-xx.txt. Work in Progress. 1148 [11] M. Smith. Definition of an X.500 Attribute Type and an Object 1149 Class to Hold Uniform Resource Identifiers (URIs). RFC 2079. January, 1150 1997. 1152 [12] Y. Yaacovi, M. Wahl, and T. Genovese. Lightweight Directory 1153 Access Protocol (v3): Extensions for Dynamic Directory Services. RFC 1154 2589. May, 1999. 1156 [13] H. Alvestrand. Tags for the Identification of Languages. RFC 1157 1766. December, 1997. 1159 [14] M. Wahl and T. Howes. Use of Language Codes in LDAP. RFC 2596. 1160 May, 1999. 1162 [15] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan. Authentication 1163 Methods for LDAP. draft-ietf-ldapext-authmeth-xx.txt. Work in 1164 Progress. 1166 [16] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 1167 Levels. RFC 2119. March 1997. 1169 [17] Dubuisson, O. ASN.1: Communication between Heterogeneous 1170 Systems. OSS Nokalva, 2000. 1172 [18] http://www.srvloc.org 1174 9.0 Full Copyright Statement 1176 Copyright (C) The Internet Society (1997). All Rights Reserved. 1178 This document and translations of it may be copied and furnished to 1179 others, and derivative works that comment on or otherwise explain it 1180 or assist in its implementation may be prepared, copied, published 1181 and distributed, in whole or in part, without restriction of any 1182 kind, provided that the above copyright notice and this paragraph are 1183 included on all such copies and derivative works. However, this 1184 document itself may not be modified in any way, such as by removing 1185 the copyright notice or references to the Internet Society or other 1186 Internet organizations, except as needed for the purpose of 1187 developing Internet standards in which case the procedures for 1188 copyrights defined in the Internet Standards process must be 1189 followed, or as required to translate it into languages other than 1190 English. 1192 The limited permissions granted above are perpetual and will not be 1193 revoked by the Internet Society or its successors or assigns. 1195 This document and the information contained herein is provided on an 1196 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1197 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1198 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1199 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1200 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1202 10.0 Authors' Address 1204 James Kempf Ryan Moats 1205 Sun Microsystems Coreon, Inc. 1206 901 San Antonio Avenue 15621 Drexel Circle 1207 Palo Alto, CA 94303 Omaha, NE, 68135 1208 USA 1210 Phone: +1 650 786-5890 1211 Email: james.kempf@sun.com rmoats@coreon.net 1213 Pete St. Pierre 1214 Sun Microsystems 1215 901 San Antonio Avenue 1216 Palo Alto, CA 94303 1217 USA 1219 Phone: +1 415 786-5790 1220 Email: Pete.StPierre@Eng.Sun.COM