idnits 2.17.1 draft-ietf-svrloc-template-conversion-05.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? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([4], [7]), 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 1228 has weird spacing: '...sun.com jay...' == 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1135, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1156, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (ref. '3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1179 (ref. '5') ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2254 (ref. '9') (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2252 (ref. '10') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-06) exists of draft-ietf-svrloc-printer-scheme-03 -- Possible downref: Normative reference to a draft: ref. '12' -- Duplicate reference: RFC2252, mentioned in '15', was also mentioned in '10'. ** Obsolete normative reference: RFC 2252 (ref. '15') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2596 (ref. '16') (Obsoleted by RFC 3866) -- No information found for draft-ietf-ldapext-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. '17' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineerinf Task Force James Kempf 2 INTERNET DRAFT Sun Microsystems 3 22 October 1999 Ryan Moats 4 AT&T Laboratories 5 Pete St. Pierre 6 Sun Microsystems 8 Conversion of LDAP Schemas to and from SLP Templates 9 draft-ietf-svrloc-template-conversion-05.txt 11 Status of This Memo 13 This document is a submission by the Service Location Working Group 14 of the Internet Engineering Task Force (IETF). Comments should be 15 submitted to the srvloc@srvloc.org mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at: 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes a procedure for mapping between SLP service 41 advertisments and LDAP descriptions of services. The document 42 covers two aspects of the mapping. One aspect is mapping between 43 SLP service type templates and LDAP directory schema. Because the 44 SLP service type template grammer is relatively simple, mapping from 45 service type templates to LDAP types is straightforward. Mapping 46 in the other direction is straightforward if the LDAP schema is 47 restricted to the set of attribute types defined in RFC 2252. If 48 arbitrary ASN.1 types occur in the schema, then the mapping is 49 more complex and may even be impossible. The second aspect is 50 representation of service information in an LDAP directory. The 51 recommended representation simplifies interoperability with SLP by 52 allowing SLP directory agents to backend into LDAP directory servers. 53 The resulting system allows service advertisements to propagate 54 easily between SLP and LDAP. 56 Contents 58 Status of This Memo i 60 Abstract ii 62 1. Introduction 1 64 2. Mapping SLP Templates to LDAP Schema 2 65 2.1. Mapping from SLP Attribute Types to LDAP Attribute Types 6 66 2.1.1. Integer . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.2. String . . . . . . . . . . . . . . . . . . . . . 7 68 2.1.3. Boolean . . . . . . . . . . . . . . . . . . . . . 7 69 2.1.4. Opaque . . . . . . . . . . . . . . . . . . . . . 7 70 2.2. Keyword Attributes . . . . . . . . . . . . . . . . . . . 7 71 2.3. Template Flags . . . . . . . . . . . . . . . . . . . . . 8 72 2.3.1. Multi-valued . . . . . . . . . . . . . . . . . . 8 73 2.3.2. Optional . . . . . . . . . . . . . . . . . . . . 8 74 2.3.3. Literal . . . . . . . . . . . . . . . . . . . . . 8 75 2.3.4. Explicit Matching . . . . . . . . . . . . . . . . 8 76 2.4. Default and Allowed Value Lists . . . . . . . . . . . . . 9 77 2.5. Descriptive Text . . . . . . . . . . . . . . . . . . . . 9 78 2.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 3. Attribute Name Conflicts 13 82 4. Mapping from Schema to Templates 13 83 4.1. Mapping LDAP Attribute Types to SLP Attribute Types . . . 14 84 4.2. Mapping ASN.1 Types to SLP Types . . . . . . . . . . . . 15 85 4.2.1. Integer . . . . . . . . . . . . . . . . . . . . . 16 86 4.2.2. Case Ignore String, Case Exact String . . . . . . 16 87 4.2.3. Boolean . . . . . . . . . . . . . . . . . . . . . 16 88 4.2.4. Octet String . . . . . . . . . . . . . . . . . . 17 89 4.2.5. Binary . . . . . . . . . . . . . . . . . . . . . 17 90 4.2.6. Enumeration . . . . . . . . . . . . . . . . . . . 17 91 4.2.7. Set . . . . . . . . . . . . . . . . . . . . . . . 17 92 4.2.8. Real . . . . . . . . . . . . . . . . . . . . . . 18 93 4.2.9. Object Identifier . . . . . . . . . . . . . . . . 18 94 4.2.10. Sequence . . . . . . . . . . . . . . . . . . . . 19 95 4.3. Example ASN.1 Schema . . . . . . . . . . . . . . . . . . 19 97 5. Representing SLP Service Advertisments in an LDAP DIT 21 99 6. Internationalization Considerations 23 101 7. Security Considerations 23 103 1. Introduction 105 SLP templates [2] are intended to create a simple encoding of the 106 syntactic and semantic conventions for individual service types, 107 their attributes, and conventions. They can easily be generated, 108 transmitted, read by humans and parsed by programs, as it is a string 109 based syntax with required comments. Directory schemas serve to 110 formalize directory entry structures for use with LDAP [3]. These 111 directories serve to store information about many types of entities. 112 Network services are an example of one such entity. 114 Interoperability between SLP and LDAP is important so clients using 115 one protocol derive benefit from services registered through the 116 other. In addition, LDAP directory servers can serve as the backend 117 for SLP directory agents (DAs) if interoperability is possible In 118 order to facilitate interoperability, this document creates mappings 119 between the SLP template grammar and LDAP directory schema, and 120 establishes some conventions for representing service advertisements 121 in LDAP directories. The goal of the translation is to allow SLPv2 122 queries (which are syntatically and semantically equivalent to LDAPv3 123 string queries [9]) to be submitted to an LDAP directory server by an 124 SLP DA backended into LDAP without extensive processing by the DA. 126 The simple notation and syntactic/semantic attribute capabilities 127 of SLP templates map easily into directory schemas, and are easily 128 converted into directory schemas, even by automated means. The 129 reverse may not be true. If the LDAP schema contains arbitrary ASN.1 130 types, the translation may be difficult or impossible. If, however, 131 the LDAP schema contains the types described in RFC 2252 [10], then 132 the translation is more straightforward. 134 This document outlines the correct mappings for SLP templates into 135 the syntatic representation specified for LDAP directory schema by 136 RFC 2252 [10]. This syntax is a subset of the ASN.1/BER described in 137 the X.209 specification [11], and is used by the LDAPv3 [3] directory 138 schema. Likewise, rules and guidelines are proposed to facilitate 139 consistent mapping of ASN.1 based schemas to be translated in the 140 SLP template grammar. Finally, a proposal for a representation 141 of service advertisements in LDAP directory services is made that 142 facilitates SLP interoperability. 144 2. Mapping SLP Templates to LDAP Schema 146 We define the following abstract object class as the parent class for 147 all services. Any specific service type may add other attributes: 149 ( 1.3.6.1.4.1.42.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 ) 162 ) 164 The attributes correspond to various parts of the SLP service 165 template and SLP service advertisement. 167 SLP service type templates begin with four definitions that set the 168 context of the template: 170 template-type 172 This defines the service type of the template. The service 173 type can be a simple service type, like ``service:ftp'', an 174 abstract service type, like ``service:printer'' or a concrete 175 service type, like ``service:printer:lpr''. The type name 176 can additionally include a naming authority, for example 177 ``service:printer.sun:local''. The name that appears in this 178 field omits the ``service:'' prefix. 180 template-version 182 A string containing a major and minor version number, separated 183 by a period. 185 template-description 187 A block of human readable text describing what the service type 188 does. 190 template-url-syntax 192 An ABNF [7] grammer describing the service type specific part 193 of the service URL. 195 The SLP template-type definition is used as the name of the ASN.1 196 class for the template, a subclass of the ``slpService'' class, 197 together with the ``service'' prefix to indicate that the name 198 is for a service. In the translating service type name, colons 199 and the period separating the naming authority are converted 200 into hyphens. If the template defines an SLP concrete type, 201 the concrete type name is used; the abstract type name is never 202 used. For example, the template for ``service:printer:lpr'' is 203 translated into an ASN.1 class called ``service-printer-lpr''. 204 Furthermore, if the type name contains a naming authority, the naming 205 authority name must be included. For example, the service type name 206 ``service:printer.sun:local'' becomes ``service-printer-sun-local''. 207 The ASN.1 class is always ``STRUCTURAL''. 209 The template-version definition is partitioned into two attributes, 210 template-major-version-number and template-minor-version-number. The 211 LDAP definition for these attributes is: 213 ( 1.3.6.1.4.1.42.2.27.6.1.1 214 NAME 'template-major-version-number' 215 DESC 'The major version number of the service type template' 216 EQUALITY integerMatch 217 SYNTAX INTEGER 218 SINGLE-VALUE 219 NO-USER-MODIFICATION 220 ) 222 ( 1.3.6.1.4.1.42.2.27.6.1.2 223 NAME 'template-minor-version-number' 224 DESC 'The minor version number of the service type template' 225 SYNTAX INTEGER 226 EQUALITY integerMatch 227 SINGLE-VALUE 228 NO-USER-MODIFICATION 229 ) 231 These attributes are marked NO-USER-MODIFICATION because they are 232 set by the definition of the template, and they are required (MUST 233 contain) attributes in the ASN.1 class translated from the template. 235 The template-url-syntax definition in the SLP template is described 236 by the following attribute: 238 ( 1.3.6.1.4.1.42.2.27.6.1.3 239 NAME 'template-url-syntax' 240 DESC 'An ABNF grammar describing the service type 241 specific part of the service URL' 242 SYNTAX IA5String 243 EQUALITY caseExactMatch 244 SINGLE-VALUE 245 ) 247 The template-description attribute is translated into the X.520 248 standard attribute ``description'' [4]. 250 We further establish the convention that SLP template characteristcs 251 that can't be translated into LDAP are inserted into the DESC field 252 of the object class definition. The items are separated by empty 253 lines, start on a new line, and are tagged at the beginning of the 254 line to indicate what they represent. This allows the template to be 255 reconstructed from the schema by properly parsing the comments. 257 The bulk of an SLP template consists of attribute definitions. There 258 are four items in an SLP template attribute definition that need to 259 be mapped into LDAP: 261 Attribute Name 263 Since SLPv2 attribute names are defined to be compatible with 264 LDAPv3, SLP attributes map directly into LDAP attributes with 265 no change. Similarly, LDAP attributes map directly to SLP 266 attributes. 268 Attribute Type 270 The SLP attribute type is mapped into the LDAP attribute type. 272 Attribute Flags 274 The SLP attribute flags are mapped into characterics of 275 the LDAP attribute definition, or into the DESC field if no 276 equivalent LDAP attribute definition characteristic occurs. 278 Default and Allowed Values 280 These must be handled by the client or a DA enabled to handle 281 templates, as in SLP. For reference, however, they should be 282 included in the DESC field of the LDAP attribute definition. 284 Descriptive Text 286 The SLP template descriptive text should be mapped into the 287 DESC field. 289 We discuss mapping of types, flags, default and allowed values, and 290 descriptive text in the subsections below. 292 For purposes of representing an SLP entry, we also define two 293 standardized LDAP attributes with standardized OIDs. These 294 attributes are: 296 ( 1.3.6.1.4.1.42.2.27.6.1.4 297 NAME 'service-advert-service-type' 298 DESC 'The service type of the service advertisement, including the 299 "service:" prefix.' 300 SYNTAX IA5String 301 SINGLE-VALUE 302 EQUALITY caseIgnoreMatch 303 ) 305 ( 1.3.6.1.4.1.42.2.27.6.1.5 306 NAME 'service-advert-scopes' 307 DESC 'A list of scopes for a service advertisement.' 308 SYNTAX IA5String 309 EQUALITY caseIgnoreMatch 310 ) 312 Searchs for abstract types can be made with an LDAP query that 313 wildcards the concrete type. For example, a search for all service 314 advertisements of the printer abstract type can be made with the 315 following query: 317 (service-advert-service-type=service:printer:*) 319 SLP specifies that service URLs and attribute lists can be 320 accompanied by a structured authenticator consisting of a digital 321 signature and information necessary to verify the signature. Two 322 standardized SLP attributes are defined for this purpose: 324 ( 1.3.6.1.4.1.42.2.27.6.1.6 325 NAME 'service-advert-url-authenticator' 326 DESC 'The authenticator for the URL, null if none.' 327 SYNTAX Binary 328 SINGLE-VALUE 329 ) 331 ( 1.3.6.1.4.1.42.2.27.6.1.7 332 NAME 'service-advert-attribute-authenticator' 333 DESC 'The authenticator for the attribute list, null if none.' 334 SYNTAX Binary 335 SINGLE_VALUE 336 ) 338 2.1. Mapping from SLP Attribute Types to LDAP Attribute Types 340 We define the mapping from SLP attribute types to LDAP as follows: 342 SLP Type ASN.1 Type LDAP Type 343 ---------------------------------------------- 344 Integer Integer INTEGER 345 String String Directory String 346 Boolean String Boolean 347 Opaque BINARY BINARY 348 Keyword String IA5String 350 The following subsections discuss further details of the mapping. 352 2.1.1. Integer 354 SLP integers compare as integers when performing a query. LDAP 355 integers behave similarly Consequently, the mapping from the SLP 356 integer type to LDAP is INTEGER, with the integerMatch matching rule. 358 2.1.2. String 360 SLP strings are encoded as described in the SLP protocol 361 specification [6]. All value strings are considered case insensitive 362 for matching operations. SLP strings are not null terminated and are 363 encoded in UTF-8. 365 SLP strings are mapped to the LDAP Directory String type. The 366 Directory String type exactly matches the SLP string type, i.e. 367 it is a non-null terminated UTF-8 string. The caseIgnoreMatch 368 equality rule, caseIgnoreOrderingMatch ordering rule, and 369 caseIgnoreSubstringsMatch substring rule are used for comparing 370 string attribute values. 372 2.1.3. Boolean 374 Boolean attributes may have one of two possible values. In SLP, 375 these values are represented as strings, TRUE and FALSE. In SLP's 376 string encoding of a boolean value, case does not matter. 378 The SLP Boolean type maps directly into an LDAP Boolean. The 379 caseIgnoreMatch rule is used for equality matching. 381 2.1.4. Opaque 383 SLP attribute values of type Opaque are represented as BINARY in 384 LDAP. 386 2.2. Keyword Attributes 388 SLP service type templates allow the definition of keyword 389 attributes. Keyword attributes are attributes whose only 390 characteristic is their presence. Keyword attributes have no flag 391 information, nor any default or allowed values (since, by definition, 392 they have no values). 394 ASN.1 has no concept of keyword attributes. Keyword attributes are 395 translated into a ``May'' clause in the ASN.1 class defintion for the 396 service type. If the keyword attribute is present, then its value 397 is of no consequence, but for consistency we make it simply the NUL 398 character, ``\00''. 400 2.3. Template Flags 402 SLP template flags can be handled as described in the following 403 subsections. 405 2.3.1. Multi-valued 407 Multi-valued attributes are defined in an SLP template using the 'M' 408 flag. This flag indicates that an attribute may have more than one 409 value. All values for a given attribute must be of the same type. 411 LDAP attribute definitions require that a single valued attribute 412 include the SINGLE-VALUE tag if the attribute is single valued. 413 Otherwise, the attribute is assumed to be multivalued by default. 415 2.3.2. Optional 417 SLP uses the 'O' flag to indicate an attribute may or may not be 418 present. These optional attributes are defined using the "May" 419 clause in the ASN.1 definition class definition for the service type. 420 All other attributes must be defined as a "Must" 422 2.3.3. Literal 424 ASN.1 does not have a mechanism to indicate that the values of an 425 attribute may not be translated from one language to another, since 426 ASN.1 schema are not typically translated. This flag is dropped when 427 translating a template, but presence of the flag should be noted in 428 the DESC field. It should be placed on a separate line and tagged 429 with ``Literal:'' so the template can be reconstructed from the 430 schema. 432 2.3.4. Explicit Matching 434 The SLP template syntax uses a flag of 'X' to indicate that an 435 attribute must be present in order for the query to be properly 436 satisfied. There is no provision for requiring that particular 437 attributes be in a query. Consequently, 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 ``Explicit:'' so the template can be reconstructed from the 441 schema. 443 2.4. Default and Allowed Value Lists 445 The SLP template grammar provides the capability to define 446 default and allowed values for an attribute. The SLP protocol 447 does not enforce these restrictions on registered attributes, 448 however. The default and allowed values may be used by client 449 side applications, or alternatively it may also be used by DAs to 450 initialize registrations having no attributes and to limit attribute 451 values to the template allowed values. 453 LDAP servers also do not support default and allowed values on 454 attributes. Therefore, enforcement of default and allowed values 455 in SLP templates is left up to the clients or a DA, if the DA 456 is backending into LDAP. The default and allowed values should 457 be included in the DESC field. The comments should be placed on 458 separate lines and labelled with the ``Default:'' and ``Allowed:'' 459 tags to allow reconstruction of the tempalte. 461 2.5. Descriptive Text 463 The descriptive text associated with an attribute definition should 464 be included in the DESC field. It should start on a separate line 465 and begin with the ``Description:'' tag. 467 2.6. Example 469 The template included below is a hypothetical abstract printer 470 service template, similar to that described in [12]. 472 template-type = printer 474 template-version = 0.0 476 template-description = 477 The printer service template describes the attributes 478 supported by network printing devices. Devices may be 479 either directly connected to a network, or connected to a 480 printer spooler that understands the a network queuing 481 protocol such as IPP, lpr or the Salutation Architecture. 483 template-url-syntax = 484 ;The URL syntax is specific to the printing protocol being 485 ;employed 487 description = STRING 488 # This attribute is a free form string that can contain any 489 # site-specific descriptive information about this printer. 491 printer-security-mechanisms-supported = STRING L M 492 none 493 # This attribute indicates the security mechanisms supported 494 tls, ssl, http-basic, http-digest, none 496 printer-operator = STRING O L M 497 # A person, or persons responsible for maintaining a 498 # printer on a day-to-day basis, including such tasks 499 # as filling empty media trays, emptying full output 500 # trays, replacing toner cartridges, clearing simple 501 # paper jams, etc. 503 printer-location-address = STRING O 504 # Physical/Postal address for this device. Useful for 505 # nailing down a group of printers in a very large corporate 506 # network. For example: 960 Main Street, San Jose, CA 95130 508 printer-priority-queue = BOOLEAN O 509 FALSE 510 # TRUE indicates this printer or print queue is a priority 511 # queuing device. 513 printer-number-up = INTEGER O 514 1 515 # This job attribute specifies the number of source 516 # page-images to impose upon a single side of an instance 517 # of a selected medium. 518 1, 2, 4 520 printer-paper-output = STRING M L O 521 standard 522 # This attribute describes the mode in which pages output 523 # are arranged. 524 standard, noncollated sort, collated sort, stack, unknown 526 We assume that the concrete type ``service:printer:lpr'' for 527 printers that speak the LPR protocol [5] has the following template 528 definition: 530 template-type = printer:lpr 532 template-version = 0.0 534 template-description = 535 The printer:lpr service template describes the attributes 536 supported by network printing devices that speak the 537 LPR protocol. No new attributes are included. 539 template-url-syntax = queue 540 queue = ;The queue name, see RFC 1179. 542 The LDAP class definition for the ``service:printer:lpr'' concrete 543 service type is translated as follows. We use attribute names 544 instead of oids in MUST and MAY for clarity: 546 ( 547 NAME 'service-printer-lpr' 548 DESC `Description: The printer:lpr service template 549 describes the attributes supported by network printing 550 devices that speak the LPR protocol. No new attributes 551 are included.' 553 URL Syntax: queue 554 queue = ;The queue name, see RFC 1179.' 555 SUP 'slpService' 556 MUST ( description \$ security-mechanisms-supported \$ 557 labelledURI) 558 MAY ( operator \$ location-address \$ priority-queue \$ 559 number-up \$ paper-output) 560 ) 562 The attribute definitions are translated as follows: 564 ( 565 NAME 'printer-security-mechanisms-supported' 566 DESC 'Description: This attribute indicates the security mechanisms 567 supported. 569 Default: value 571 Allowed: tls, ssl, http-basic, http-digest, none 573 Literal:' 574 EQUALITY caseIgnoreMatch 575 ORDERING caseIgnoreOrderingMatch 576 SUBSTR caseIgnoreSubstringMatch 577 SYNTAX 'Directory String' 578 ) 580 ( 581 NAME 'printer-operator' 582 DESC 'Description: A person, or persons responsible for 583 maintaining a printer on a day-to-day basis, including 584 such tasks as filling empty media trays, emptying full 585 output trays, replacing toner cartridges, clearing simple 586 paper jams, etc. 588 Literal:' 589 EQUALITY caseIgnoreMatch 590 ORDERING caseIgnoreOrderingMatch 591 SUBSTR caseIgnoreSubstringMatch 592 SYNTAX 'Directory String' 593 ) 595 ( 596 NAME 'printer-location-address' 597 DESC 'Description Physical/Postal address for this device. 598 Useful for nailing down a group of printers in a very 599 large corporate network. For example: 960 Main Street, 600 San Jose, CA 95130.' 601 EQUALITY caseIgnoreMatch 602 ORDERING caseIgnoreOrderingMatch 603 SUBSTR caseIgnoreSubstringMatch 604 SYNTAX 'Directory String' 605 SINGLE-VALUE 606 ) 608 ( 609 NAME 'printer-priority-queue' 610 DESC 'Description: TRUE indicates this printer or print 611 queue is a priority queuing device.' 612 EQUALITY caseIgnoreMatch 613 SYNTAX 'Boolean' 614 SINGLE-VALUE 615 ) 617 ( 618 NAME 'printer-number-up' 619 DESC 'Description: This job attribute specifies the number 620 of source page-images to impose upon a single side of 621 an instance of a selected medium. This attribute is 622 INTEGER. 624 Default: 1 626 Allowed: 1, 2, 3, 4' 627 SYNTAX 'Integer' 628 EQUALITY integerMatch 629 SINGLE-VALUE 630 ) 631 ( 632 NAME 'printer-paper-output' 633 DESC 'Description: This attribute describes the mode in 634 which pages output are arranged. Default value is 635 standard. 637 Default: standard 639 Allowed: standard, noncollated sort, collated sort, 640 stack, unknown. 641 Literal:' 642 EQUALITY caseIgnoreMatch 643 ORDERING caseIgnoreOrderingMatch 644 SUBSTR caseIgnoreSubstringMatch 645 SYNTAX 'Directory String' 646 ) 648 3. Attribute Name Conflicts 650 LDAP has a flat name space, and attribute names and OIDs must be 651 unique in a directory server. In order to avoid name conflicts in 652 the translation of SLP templates to LDAP schemas, template developers 653 may want to consider prepending the name of the service type to 654 the attribute. Postprocessing attribute names to make them unique 655 when translated is not possible, because it would require the DA to 656 rewrite queries before submitting them to the directory server. In 657 addition, developers should use standard LDAP attributes when such 658 attributes are available. 660 In the above example template, the abstract type name ``printer'' 661 is prepended to attributes to avoid conflicts. The standard 662 ``description'' attribute defined by X.520 [4] is used to translate 663 the template description attribute. 665 4. Mapping from Schema to Templates 667 The reverse mapping from LDAP schema to SLP service type templates 668 requires dealing with both LDAP and ASN.1 data types. RFC 2252 669 defines 57 LDAP attribute data types that should be supported by LDAP 670 directory servers. These data type are defined on top of the ASN.1 671 typing system used by X.500, but directory servers are also required 672 to support standard X.500 ASN.1 data types using the LDAP Binary type 673 escape. 675 Mapping of the LDAP data types into SLP template types is fairly 676 straightforward, but mapping arbitrary ASN.1 data types is somewhat 677 more complicated and requires encoding the ASN.1 data type into a 678 string. To a certain extent, this masks the ASN.1 data type because 679 it becomes impossible to distinguish between a native string having 680 content equivalent to an encoded ASN.1 string. However, inclusion of 681 the ASN.1 data type in the comment provides additional information 682 should a reverse transformation from SLP to ASN.1 be required. 684 The following subsections deal with both LDAP and ASN.1 attribute 685 data type mappings. 687 4.1. Mapping LDAP Attribute Types to SLP Attribute Types 689 The following table contains the mappings for LDAP data types to SLP 690 data types: 692 LDAP Type SLP Type 693 -------------------------------------------------------- 694 ACI Item NA 695 Access Point NA 696 Attribute Type Description NA 697 Audio Opaque 698 Binary ASN.1 escape 699 Bit String String 700 Boolean Boolean 701 Certificate Opaque 702 Certificate List Opaque 703 Certificate Pair Opaque 704 Country String String 705 DN String 706 Data Quality Syntax NA 707 Delivery Method NA 708 Directory String String 709 DIT Content Rule Description NA 710 DIT Structure Rule Description NA 711 DL Submit Permission NA 712 DSA Quality Synax NA 713 Enhanced Guide NA 714 Facsimile Telephone Number String 715 Fax Opaque 716 Generalized Time String 717 Guide NA 718 IA5 String String 719 INTEGER Integer 720 JPEG Opaque 721 LDAP Syntax Description NA 722 LDAP Schema Definition NA 723 LDAP Schema Description NA 724 Master and Shadow Access Points NA 725 Matching Rule Description NA 726 Matching Rule Use Description NA 727 Mail Preference NA 728 MHS OR Address String 729 Modify Rights NA 730 Name and Optional UID NA 731 Name Form Description NA 732 Numeric String String 733 Object Class Description NA 734 Octet String Opaque 735 OID String 736 Other Mailbox String 737 Postal Address String 738 Protocol Information NA 739 Presentation Address String 740 Printable String String 741 Subset Assertion NA 742 Subtree Specification NA 743 Supplier Information NA 744 Supplier or Consumer NA 745 Supplier And Consumer NA 746 Supported Algorithm NA 747 Telephone Number String 748 Teletex Terminal Identifier String 749 Telex Number String 750 UTC Time String 752 If the SLP type is NA in the above table, the LDAP type is involved 753 in schema representation or some other internal function, or is 754 otherwise unlikely to appear in the schema definition for a service 755 type. 757 4.2. Mapping ASN.1 Types to SLP Types 759 ASN.1 employs a much richer set of data types than provided by SLP. 760 The table below show the mapping of selected ASN.1 data type to their 761 nearest SLP equivalent. Because of the complexity and flexibility of 762 ASN.1, a complete list cannot be provided. 764 As sample of some ASN.1 encodings and their mappings to SLP: 766 ASN.1 type SLP type 767 ----------------------------------------- 768 Integer Integer 769 Case Exact String String 770 Case Ignore String String 771 Boolean Boolean 772 Octet String Opaque 773 Binary Opaque 774 Enumeration String 775 Set Of Formatted String 776 Real String 777 Object Identifier String 778 Sequence Of Formatted String 780 Data types that do not map directly to SLP data types should be 781 defined as either a String, or as Opaque. ASN.1 types that may only 782 contain valid characters for Strings, as defined in X.680 [11] should 783 be encoded as strings. If a value may contain illegal string values, 784 the SLP Opaque type should be used. In either case, the first line 785 of the help text is used to indicate the original ASN.1 data type. 787 The following subsections describe how to convert from the ASN.1 788 BER [11] to the SLP template for the different types in the table 789 above. 791 4.2.1. Integer 793 Both SLP templates and ASN.1 support Integers, so there is a one to 794 one mapping between an SLP Integer attribute and an ASN.1 Integer 795 attribute. Details on the encoding of integers is summarized in the 796 SLP template to ASN.1 section above. 798 4.2.2. Case Ignore String, Case Exact String 800 Strings are supported between both SLP and ASN.1. SLP encoding 801 of the strings must conform to the rules for handling special 802 characters, as outlined in RFC XXX [6]. Note that, unless the ASN.1 803 type is recorded into the comment, the reverse translation will lose 804 the ASN.1 type. 806 4.2.3. Boolean 808 Boolean values are supported by both SLP and ASN.1, though on wire 809 encodings differ. X.680 [11] specifies zero and non-zero encoding 810 for booleans, where SLP encodes booleans using the strings TRUE and 811 FALSE. In general, most LDAP servers will use the LDAP Boolean type 812 (which is a string), so again the ASN.1 type should be recorded in 813 the comment or it will be lost. 815 4.2.4. Octet String 817 An ASN.1 octet string should be mapped to an Opaque in an SLP 818 template. An octet string is a sequence of bytes, whereas an Opaque 819 is a a string that encodes a sequence of bytes. Again, the ASN.1 820 type is lost unless recorded in the comment. 822 4.2.5. Binary 824 An ASN.1 Binary should be mapped to an Opaque in an SLP template. A 825 binary value is a sequence of bytes, whereas an Opaque is a a string 826 that encodes a sequence of bytes. Again, the ASN.1 type is lost 827 unless recorded in the comment. 829 4.2.6. Enumeration 831 SLP templates support the concept of enumerations through the listing 832 of allowed values in the attribute definition. These enumerations 833 are not strictly binding on clients or DAs, but they are similar 834 to the ASN.1 definition of enumerations. BER encodes the ASN.1 835 enumeration by passing the number of the element's position in the 836 enumeration. This requires both sides to have knowledge of the 837 specific enumeration prior to decoding an enumeration's value. SLP 838 provides no specific support for transmitting enumerations. They are 839 simply String types. Information on the ASN.1 type and ASN. encoding 840 of the enumeration values is recorded in the comment. 842 Example: 844 color-supported = STRING M 845 none 846 # ASN.1: Enumeration. 847 # ASN.1 Mapping: none = 0, highlight = 1, three color = 2, four color = 4, 848 # monochrmatic = 5 849 #This attribute specifies whether the Printer supports 850 # color and, if so, what type. 851 none,highlight,three color,four color,monochromatic 853 4.2.7. Set 855 ASN.1 Sets can be accommodated in an SLP template by simply 856 concatenating the set elements into a string, separated by 857 whitespace. Searches for individual set elements in SLP can use the 858 LDAP wildcard syntax. For example, given a translated Set attribute 859 with value ``one two three'', a search can be made for attributes 860 with set value ``two'' by using the LDAP wildcard ``*two*''. 862 Problems arise if the set contains as one or more of its 863 elements a data item that is, itself, a set. Without some 864 delimiter, the elements of both sets would run together and become 865 indistinguishable. To avoid this problem, we use curly braces ``{}'' 866 to delimit a set. Thus the set in the above example becomes ``{ one 867 two three }''. 869 Since sets have no implicit ordering, the ordering of the values in 870 the string is unimportant. Note that sets cannot be represented as 871 multivalued attributes because it is possible that an LDAP attribute 872 having the ASN.1 Set type may additionally be multivalued. The 873 template's help text should indicate the original ASN.1 type to 874 facilitate backwards conversion. 876 4.2.8. Real 878 There is no direct mapping between floating point numbers and any 879 SLP data types. Attributes having the ASN.1 type of Real are mapped 880 to SLP type String. Comments are added to the attribute help text 881 indicating the value was originally an ASN.1 real. For example: 883 weight = STRING 884 # ASN.1: Real 885 # The objects weight in pounds. 887 4.2.9. Object Identifier 889 Object identifiers(OIDs) are commonly used in the ASN.1 world to 890 identify object and attributes. OIDs are a numerical representation 891 of an element's place in the naming hierarchy. Each element at a 892 particular level of a hierarchy has a unique number assigned within 893 that level of the hierarchy. A sample OID would be the naming tree 894 for SNMP MIBs: iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would 895 be written as the string ``1.3.6.1.2.1''. 897 Because this representation reduces down to a string of dot separated 898 numbers, this maps easily to the SLP String type. The help text for 899 this element should indicate it is an ASN.1 OID 901 identifier = STRING 902 # ASN.1: OID 903 # The object identifier for this SNMP agent. 905 4.2.10. Sequence 907 The ASN.1 Sequence type is handled exactly like the Set type. The 908 sequence elements are converted to strings and inserted into a string 909 with whitespace separators. Sequences are delimited with angle 910 brackets ``<>''. An example encoded sequence is ``< one two three 911 >''. Unlike sets, the ordering of items in a sequence is important 912 and should be respected by client software. The SLP template 913 attribute help text should indicate that the attribute was translated 914 from an ASN.1 sequence. 916 4.3. Example ASN.1 Schema 918 The following is an example schema for an exported filesystem. The 919 section presents it as in ASN.1 and the following section shows 920 the SLP template translation. The template translation does not 921 capture the actual attribute format for the Set type, that would 922 be done in the LDAP client software making the translation. Note 923 that even though the class definition does not conform with the 924 previously defined conventions for SLP classes, the schema can still 925 be translated into an SLP template. 927 -- abstraction of a fstab entry (a "mount") 928 -- these lookups would likely be performed by an 929 -- an automounter type application 930 mount OBJECT-CLASS 931 SUBCLASS OF top 932 MUST CONTAIN { 933 -- the mount host 934 mountHost, 935 -- the mount point 936 mountDirectory. 937 -- the mount type 938 mountType 939 } 940 MAY CONTAIN { 941 -- mount options 942 mountOption, 943 -- dump frequency 944 mountDumpFrequency, 945 -- passno 946 mountPassNo 947 } 949 mountHost OBJECT-TYPE 950 SYNTAX Case Ignore String 951 DESCRIPTION 952 "The mount host" 954 mountDirectory OBJECT-TYPE 955 SYNTAX Case Ignore String 956 DESCRIPTION 957 "The filesystem to mount" 959 mountType OBJECT-TYPE 960 SYNTAX INTEGER { 961 ufs(1) 962 hsfs(2) 963 nfs(3) 964 rfs(4) 965 } 966 DESCRIPTION 967 "The type of the filesystem being mounted" 969 mountOption OBJECT-TYPE 970 SYNTAX SET OF Case Ignore String 971 DESCRIPTION 972 "mount options for this filesystem" 974 mountDumpFrequency OBJECT-TYPE 975 SYNTAX INTEGER (0..9) 976 DESCRIPTION 977 "How often to dump this filesystem" 979 mountPassNo OBJECT-TYPE 980 SYNTAX Integer 981 DESCRIPTION 982 "Boot time mount pass number" 984 The translated SLP template is: 986 template-type = mount 988 template-version = 1.0 990 template-description = "Describes a remote filesystem access protocol" 992 template-url-syntax = 993 filesystem = 1*[ DIGIT / ALPHA ] 994 urlpath = "/" filesystem 996 mountHost = STRING L 997 # ASN.1: Case Ignore String 998 # The mount host 1000 mountDirectory = STRING L 1001 # ASN.1: Case Ignore String 1002 # The filesystem to mount 1004 mountType = STRING L 1005 ufs 1006 # ASN.1: Enumeration 1007 # ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4 1008 # The type of the filesystem being mounted 1009 ufs, hsfs, nfs, rfs 1011 mountOption = STRING M O L 1012 # ASN.1: Set of Case Ignore String 1013 # mount options for this filesystem 1015 mountDumpFrequency = INTEGER O 1016 0 1017 # ASN.1: Integer Range 1018 # How often to dump this filesystem 1019 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 1021 mountPassNo = INTEGER O 1022 # ASN.1: Integer 1023 # Boot time mount pass number 1025 5. Representing SLP Service Advertisments in an LDAP DIT 1027 In addition to translating between SLP templates and LDAP schema, 1028 another area requiring compatibility is the representation 1029 of SLP service advertisements in an LDAP DIT. A standardized 1030 representation for service information allows SLP DAs to store 1031 service advertisements in LDAP, and for LDAP clients to query 1032 the DIT for those services. Similarly, if LDAP clients represent 1033 service information in the same form, SLP clients can benefit from 1034 interoperability. 1036 In addition, a service advertisement contains the service URL in a 1037 'labelledURI' attribute [13]. The labelledURI attribute in a service 1038 advertisement should only contain the service URL for the service, 1039 with no additional label.It is recommended that the labelledURI be 1040 used as the RDN for the service object in the DIT. 1042 Although service advertisements can appear anywhere within the 1043 DIT, it is recommended that all services be stored under a single 1044 common point to facilitates searching. This allows a client to 1045 search for all of advertisements of a particular service type, say, 1046 for all printers. The recommended storage point is a container 1047 node named "oc=service" under the root node for the local LDAP 1048 server. For example, a printer service with labelledURI of 1049 "service:lpr://printsr/queue1" advertised in the LDAP server that 1050 holds the root for the "dc=foobar, dc=com" tree would have the 1051 following DN: 1053 "labelledURI=service:lpr://printsr/queue1, oc=service, dc=foobar, dc=com" 1055 While this leads to a flat space of service storage, since SLP uses 1056 search filters from LDAP for searches, these filters can be used for 1057 one-level searches from the root node. 1059 A few examples should clarify. The following example illustrates how 1060 an advertisement having a simple service type is represented. The 1061 advertisment for a printer is: 1063 Service URL: service:lpr://printsrv/queue1 1064 Scopes: eng, corp 1065 Attributes: description = A general printer for all to use. 1066 security-mechanisms-supported = none 1067 No Authentication 1069 The RDN of the object is labelledURI=service:lpr://printsrv/queue1, 1070 and the following LDAP search filter will return this object, along 1071 with any others of the service type ``service:lpr'' that match the 1072 other attributes: 1074 (&(service-advert-service-type=service:lpr) 1075 (service-advert-scopes=eng,corp) 1076 (description=A general printer for all to use) 1077 (security-mechanisms-supported=none)) 1079 Service advertisements in SLP also have a lease time associated 1080 with them. In LDAP servers that support the extensions for dynamic 1081 directory services [14], the service advertisement entry objectClass 1082 should be extended with the dynamicObject class. This allows the 1083 service advertisment to time out within the LDAP directory server. 1084 If the LDAP directory server does not support the dynamic directory 1085 services extension, then advertisement lease timeouts must be handled 1086 by the SLP agent. 1088 While the service advertisement schema outlined in this section 1089 is primarily for SLP DAs that use LDAP as a backing store, if 1090 LDAP agents register services using the same format, complete 1091 interoperability with SLP is achieved. 1093 6. Internationalization Considerations 1095 SLP specifies that an RFC 1766 [15] language code accompanies every 1096 service advertisement. Language codes for service advertisements in 1097 LDAP must be represented according to RFC 2596 [16]. 1099 RFC 2596 prohibits language codes in DNs, and specifies that a 1100 directory server which does not support language codes must treat 1101 an attribute with a language code as an unrecognized attributes. 1102 According to RFC 2596, language codes are appended to attribute names 1103 with a semicolon (``;''). For example, the following attribute/value 1104 pair is in the German locale: 1106 (address;lang-de=44 Bahnhofstrasse, 2365 Maennerstadt, Germany) 1108 An attribute with a language tag in a specific locale is considered a 1109 separate attribute from attributes in other locales. 1111 If the service advertisement is in the default SLP locale (``en'', 1112 no dialect), then the language code need not be appended to the 1113 attribute name. 1115 SLP queries in locales other than the default need not be rewritten 1116 to include language tags before being submitted to the directory 1117 server. RFC 2596 specifies that all entries that match are returned, 1118 including those with language tags, without requiring the language 1119 tags to be explicitly present in the query. The SLP DA can then 1120 postprocess the result to select the entries from the required 1121 locale. 1123 7. Security Considerations 1125 SLP authenticators are stored with the service advertisement in 1126 the DIT, as discussed in Section 5. LDAP clients need to use LDAP 1127 authentication [17] to assure that they are connecting with a secure 1128 server. In particular, SLP DAs that use LDAP as a back end store 1129 and that implement SLP authentication MUST use LDAP authentication 1130 to assure that the LDAP entries for their service registrations are 1131 secure. 1133 References 1135 [1] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 1136 Levels. RFC 2119, March 1997. 1138 [2] E. Guttman, C. Perkins, J. Kempf. Service Templates and 1139 service:Schemes. RFC 2609, April, 1999. 1141 [3] M. Wahl, T. Howes, and S. Kille. Lightweight Directory Access 1142 Protocol (v3). RFC 2251, December, 1997. 1144 [4] International Telecommunications Union The Directory:Selected 1145 Attribute Types ITU Recommendation X.520, August, 1997. 1147 [5] L. McLaughlin Line Printer Daemon Protocol RFC 1179, August, 1148 1990. 1150 [6] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service 1151 Location Protocol version 2. RFC 2608, April 1999. 1153 [7] D. Crocker and P Overell. Augmented BNF for Syntax 1154 Specifications: ABNF. RFC 2234 November 1997. 1156 [8] ITU-T Rec. X.500. The Directory: Overview of Concepts, Models, 1157 and Service. 1993. 1159 [9] T. Howes. The String Representation of LDAP Search Filters. 1160 RFC 2254, December 1997. 1162 [10] M. Wahl, A. Coulbeck, T. Howe, and S. Kille. Lightweight 1163 Directory Access Protocol (v3): Attribute Syntax Definition. 1164 RFC 2252, December, 1997. 1166 [11] ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1) - 1167 Specification of Basic Notation. 1994. 1169 [12] P. St. Pierre, S. Isaccson, I. McDonald. Definition 1170 of printer: URLs for use with Service Location 1171 draft-ietf-svrloc-printer-scheme-03.txt Work in Progress 1173 [13] M. Smith. Definition of an X.500 Attribute Type and an Object 1174 Class to Hold Uniform Resource Identifiers (URIs). RFC 2079, 1175 January, 1997. 1177 [14] Y. Yaacovi, M. Wahl, and T. Genovese. Lightweight Directory 1178 Access Protocol (v3): Extensions for Dynamic Directory 1179 Services. RFC 2589, May, 1999. 1181 [15] H. Alverstrand. Tags for the Identification of Lanaguages. RFC 1182 2252, December, 1997. 1184 [16] M. Wahl and T. Howes. Use of Language Codes in LDAP. RFC 2596, 1185 May, 1999. 1187 [17] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan. 1188 Authentication Methods in LDAP. draft-ietf-ldapext-authmeth-xx.txt. 1189 A work in progress. 1191 Full Copyright Statement 1193 Copyright (C) The Internet Society (1997). All Rights Reserved. 1195 This document and translations of it may be copied and furnished to 1196 others, and derivative works that comment on or otherwise explain it 1197 or assist in its implmentation may be prepared, copied, published 1198 and distributed, in whole or in part, without restriction of any 1199 kind, provided that the above copyright notice and this paragraph 1200 are included on all such copies and derivative works. However, 1201 this document itself may not be modified in any way, such as by 1202 removing the copyright notice or references to the Internet Society 1203 or other Internet organizations, except as needed for the purpose 1204 of developing Internet standards in which case the procedures 1205 for copyrights defined in the Internet Standards process must be 1206 followed, or as required to translate it into languages other than 1207 English. 1209 The limited permissions granted above are perpetual and will not be 1210 revoked by the Internet Society or its successors or assigns. 1212 This document and the information contained herein is provided on an 1213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1219 Authors' Address 1221 James Kempf Ryan Moats 1222 Sun Microsystems AT&T Laboratories 1223 901 San Antonio Avenue 15621 Drexel Circle 1224 Palo Alto, CA 94303 Omaha, NE, 68135 1225 USA 1227 Phone: +1 650 786-5890 +1 402 894-9456 1228 Email: james.kempf@sun.com jayhawk@att.com 1230 Pete St. Pierre 1231 Sun Microsystems 1232 901 San Antonio Avenue 1233 Palo Alto, CA 94303 1234 USA 1236 Phone: +1 415 786-5790 1237 Email: Pete.StPierre@Eng.Sun.COM