idnits 2.17.1 draft-ietf-svrloc-template-conversion-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** There are 12 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 427: '... MUST CONTAIN {...' RFC 2119 keyword, line 433: '... MAY CONTAIN {...' RFC 2119 keyword, line 707: '... MUST CONTAIN {...' RFC 2119 keyword, line 715: '... MAY CONTAIN {...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (1 June 1998) is 9461 days in the past. Is this intentional? -- 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) -- Missing reference section? '1' on line 681 looks like a reference -- Missing reference section? '2' on line 600 looks like a reference -- Missing reference section? '3' on line 552 looks like a reference -- Missing reference section? '4' on line 131 looks like a reference -- Missing reference section? '6' on line 201 looks like a reference -- Missing reference section? '5' on line 355 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Location Working Group Pete St. Pierre 2 INTERNET DRAFT Sun Microsystems 3 1 June 1998 5 Conversion of LDAP Schemas to and from SLP Templates 6 draft-ietf-svrloc-template-conversion-03.txt 8 Status of This Memo 10 This document is a submission by the Service Location Working Group 11 of the Internet Engineering Task Force (IETF). Comments should be 12 submitted to the srvloc@corp.home.net mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To view the entire list of current Internet-Drafts, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 The Lightweight Directory Access Protocol (LDAP) and Service Location 35 Protocol (SLP) are both useful mechanisms for locating service 36 related information on a network. While they do perform similar 37 functions, the way in which the information they provide is formatted 38 is very different. This document describes a set of rules and 39 mappings for translating between the ASN.1 based LDAP schema and 40 an SLP Template as described in the "Service Template and service: 41 Scheme" draft. 43 Contents 45 Status of This Memo i 47 Abstract i 49 1. Motivation 1 51 2. ASN.1 and BER Encodings 1 53 3. ASN.1 Types and LDAP 2 55 4. URLs and Distinguished Names 3 57 5. Mapping from SLP Templates to LDAP Schemas 3 58 5.1. Data Type Mappings . . . . . . . . . . . . . . . . . . . 3 59 5.2. Integer . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.4. Boolean . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.5. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.6. Enumerations . . . . . . . . . . . . . . . . . . . . . . 5 64 5.7. Multi-valued Attributes . . . . . . . . . . . . . . . . . 6 65 5.8. Optional Attributes . . . . . . . . . . . . . . . . . . . 6 66 5.9. Literal Attributes . . . . . . . . . . . . . . . . . . . 6 67 5.10. Explicit Matching . . . . . . . . . . . . . . . . . . . . 6 68 5.11. Template for Translation . . . . . . . . . . . . . . . . 6 69 5.12. Translated Schema . . . . . . . . . . . . . . . . . . . . 8 71 6. Mapping from Schemas to Templates 10 72 6.1. Data Type Mappings . . . . . . . . . . . . . . . . . . . 10 73 6.2. Integer . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.3. Case Ignore String, Case Exact String . . . . . . . . . . 11 75 6.4. Boolean . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.5. Octet String . . . . . . . . . . . . . . . . . . . . . . 11 77 6.6. Binary . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.7. Enumeration . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.8. Rules for Other ASN.1 Primitive Types . . . . . . . . . . 12 80 6.9. Set Of . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.10. Real . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.11. Object Identifier . . . . . . . . . . . . . . . . . . . . 12 83 6.12. Sequence Of . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.13. Schema to be Translated . . . . . . . . . . . . . . . . . 14 85 6.14. SLP Translation . . . . . . . . . . . . . . . . . . . . . 15 87 7. Notes on Matching Operators 16 88 8. Acknowledgments 17 90 A. References 17 92 1. Motivation 94 SLP templates[1] are intended to create a simple encoding of the 95 syntactic and semantic conventions for individual service types, 96 their attributes, and conventions. This can easily be generated, 97 transmitted, read by humans and parsed by programs, as it is a string 98 based syntax with required comments. 100 On the other hand, directory schemas serve to formalize directory 101 entry formulation for use with services like LDAP[2]. These 102 directories serve to store information about many types of entities. 103 Network services are an example of one such entity. 105 The ability to register services across both SLP[3] and schema based 106 directory services is a useful capability. In order to facilitate 107 this, this document creates mappings between the SLP template grammar 108 and the directory schemas. 110 The simple notation and syntactic/semantic attribute capabilities 111 of SLP will map well into directory schemas. This means that 112 service templates will easily be converted into directory schemas. 113 The reverse is not true. Only a certain restricted set of types, 114 matching rules and encoding conventions used with LDAP will be 115 directly mappable into service type templates. There are rules 116 to cover the cases where mapping cannot be done directly. It is 117 believed that the cases which are not supported are the exception 118 rather than the rule. 120 This document will outline the correct mappings for the four basic 121 data types supported by SLP to the ASN.1/BER described in the 122 X.209 specification[4]. This is the encoding used by the LDAP[2] 123 directory schema. Likewise, rules and guidelines will be proposed to 124 facilitate consistent mapping of ASN.1 based schemas to be translated 125 in the SLP template grammar. 127 2. ASN.1 and BER Encodings 129 ASN.1 defined schemas are assumed to be encoded using the Basic 130 Encoding Rules(BER) defined in CCITT Recommendation X.209[4]. The 131 X.209[4] specification contains details of the on-the-wire encoding 132 of ASN.1 values. BER supports 4 types of encodings: Universal, 133 Application, Context Specific and Private. All SLP types will map to 134 Universal BER encoded values. 136 Within the scope of Universal types, there are both primitive 137 encodings and constructed encodings. A primitive encoding is a data 138 value encoding in which the content octets directly represent the 139 value. Constructed encodings are data values encoding in which the 140 content octets are the complete encoding of one or more other data 141 values. [2] 143 This document will deal primarily with mapping ASN.1 primitive 144 encodings to SLP data types. 146 3. ASN.1 Types and LDAP 148 Because of the simplicity of SLP data types, any SLP data type 149 can be represented in ASN.1. This does not mean, however, that 150 all LDAP servers may be able to handle all ASN.1 types we create. 151 Specifically, most LDAP servers do not support ASN.1 enumerations. 153 Also, not all LDAP servers are extensible. While some LDAP servers 154 may allow for the definition of new ASN.1 syntax definitions, there 155 is a base set of types that are common among most LDAP servers. 156 These types are: 158 Distinguished Name 159 Case Ignore String 160 Case Exact String 161 Binary 162 Integer 164 Some LDAP implementations may also support an ASN.1 definition for 165 telephone numbers. This syntax allows for searching without regard 166 for hyphen and parenthesis use. 168 SLP Type ASN.1 Type Common LDAP Type 169 ---------------------------------------------- 170 Integer Integer Integer 171 String String Case Ignore String 172 Boolean Boolean Case Ignore String 173 Opaque Octet String Binary 175 Because of the limitations of many LDAP servers. All SLP data types 176 will be discussed in the context of the common LDAP data types listed 177 above. When coverting from an SLP template to an LDAP schema, these 178 are the preferred data types for translation. For completeness, 179 alternate ASN.1 syntaxs are presented for each data type. It should 180 be noted that deployment of these types may not be supported by all 181 LDAP implementations. 183 4. URLs and Distinguished Names 185 SLP uses URLs to uniquely identify a service instance. These 186 URLs must somehow be converted to unique handles or "Distinguished 187 Names" for inclusion in an LDAP directory. This document proposes a 188 mechanism for storing an SLP URL as a Relative Distinguished Name. 190 5. Mapping from SLP Templates to LDAP Schemas 192 The first step in mapping a template is to create a Distinguished 193 Dame (DN) for the entry. This DN is used to uniquely identify the 194 record within the LDAP hierarchy. We do this in two steps, using the 195 service URL. 197 The first step is to create an DN. Since URLs are likely to contain 198 characters that are not allowed in a DN, we must find a way to 199 remove them. Also, the resulting DN must be unique across all peers 200 in the LDAP name space. In order to meet these criteria, we take 201 the URL and perform an MD5 [6] hash to obtain a unique bit string 202 that represents the URL. This bit string is then represented as hex 203 digits, and used for the value of the DN. 205 Secondly, we create an attribute called "url". This attribute is 206 of type Case Ignore String. In this attribute, we store the actual 207 service URL. 209 For example, the URL service:printer:lpr://www.printserv.net/public 210 would be stored in an LDAP directory with the following two 211 attributes. The value 6a1c0bfa0396f6be0bf73c4d1e8c45f1 is produced 212 from the MD5 hash of the URL, so the attributes would look like: 214 DN = 6a1c0bfa0396f6be0bf73c4d1e8c45f1 215 url = service:printer:lpr://www.printserv.net/public 217 5.1. Data Type Mappings 219 SLP supports four data types. Each of these data types can be mapped 220 into a specific ASN.1 type. In this way, translation of data types 221 can be described easily. All SLP data types are encoded as strings 222 in the protocol. 224 Complexity is added when the SLP data type is expressed as an 225 enumeration. This section describes the translation of each data 226 type to its corresponding ASN.1 type. A discussion of proper 227 enumeration handling follows these mappings. 229 5.2. Integer 231 Both SLP templates and ASN.1 support Integers, so there is a one to 232 one mapping between an SLP Integer attribute and an ASN.1 Integer 233 attribute. On the wire encoding of these two is very different, 234 though. 236 In SLP, all integers are encoded as strings. An integer value of 237 17869 would be represented by a 5 byte string containing the values 238 of the characters '1', '7', '8', '6', and '9' in the character set 239 specified in the request or response packet. 241 The ASN.1 Integer type is encoded in BER according to the rules in 242 section 8 of the X.209 specification. 244 The encoding of an ASN.1 integer value is primitive. The content 245 octets shall consist of one or more octets. The rules ensure that an 246 integer value is always encoded in the smallest possible number of 247 octets. 249 5.3. String 251 SLP strings are encoded as described in section 20.5 of the SLP 252 protocol specification [3]. All value strings are considered case 253 insensitive for matching operations. These strings are mapped to the 254 ASN.1 DisplayString syntax. 256 LDAP servers may or may not support the DisplayString syntax. The 257 preferred representation of an SLP String is Case Ignore String. 259 5.4. Boolean 261 Boolean attributes may have one of two possible values. In SLP, 262 these values are represented as strings, TRUE and FALSE. In SLP's 263 string encoding of a boolean value, case does not matter. 265 ASN.1 supports a Universal, primitive type of boolean. X.209 266 specifies that the Contents field of a FALSE boolean value be encoded 267 as a single octet with a value of zero. A boolean whose value is 268 TRUE shall be encoded as a single octet whose value shall be any 269 non-zero value, at the sender's option. 271 Many LDAP servers do not support a data type of Boolean. For this 272 reason, it is recommended that the SLP boolean type be translated 273 to a Case Ignore String. The value stored in this string should be 274 either "true" or "false". 276 5.5. Opaque 278 SLP values that are encoded as Opaque are really a series of octets. 279 While SLP uses the construct of :, this maps 280 very nicely to the tag/length/value BER encoding of the ASN.1 Octet 281 String. 283 The field of the SLP encoding will not match the field of 284 the BER encoding, as radix-64 encoding results in a 4 to 3 expansion 285 of the original data. Likewise, data presented in radix-64 notation 286 must be converted back to the original byte stream to be encoded in 287 the Contents field of the BER encoding. 289 LDAP servers most commonly support the Binary data type instead 290 of the more generic Octet String. For compatibility across LDAP 291 implementations, SLP Opaque values should be stored using the LDAP 292 data type of Binary. As with Octet Strings, the Binary type should 293 store the original byte stream, not the radix-64 notation used within 294 the SLP protocol. 296 5.6. Enumerations 298 The SLP template grammar provides for the definition of enumerations. 299 Enumerations are defined by listing all possible values for the 300 attribute following any help text provided for that attribute. While 301 the template syntax allows for creation of enumerations, the SLP 302 protocol does not strictly enforce enumerations. These enumerations 303 are still treated as text strings within the protocol, and values 304 outside the scope of the enumeration defined may be present. The 305 template enumeration is intended as a guideline to client side 306 applications as to what values may be expected. 308 An ASN.1 enumeration commonly maps a text string to a numerical 309 value. In the BER encoding, the numerical value is passed as an 310 integer across the wire. The receiving side must then translate 311 the the value to the associated string as defined in the ASN.1 312 description. 314 LDAP servers do not commonly support generic ASN.1 enumerations. 315 For this reason, the preferred conversion for enumerated SLP values 316 is Case Ignore String. LDAP servers will not however be able to 317 perform value checking to assure stored values are in a legal range. 318 Applications should always verify values before making use of them. 320 5.7. Multi-valued Attributes 322 Multi-valued attributes are defined in an SLP template using the 323 'M' flag. This flag indicates that an attribute may have more than 324 one value. All values for a given attribute must be of the same 325 encoding type. The ASN.1 syntax for SET OF is commonly used to 326 define multi-valued ASN.1 objects that must be of the same type. 328 Commonly, LDAP servers assume values may be multi-valued. In these 329 cases, no additional configuration is necessary. 331 5.8. Optional Attributes 333 SLP uses the 'O' flag to indicate an attribute may or may not be 334 present. These optional attributes are defined using the "May" 335 clause in an ASN.1 definition. All other attributes must be defined 336 as a "Must" 338 5.9. Literal Attributes 340 ASN.1 does not have a mechanism to indicate that the values of an 341 attribute may not be translated from one language to another. 343 5.10. Explicit Matching 345 The SLP template syntax uses a flag of 'X' to indicate that an 346 attribute must match exactly with a query made by a client. There 347 is, however, no mechanism to prevent clients from using the 348 sub-string operator with explicit matching attributes. Common 349 practice would be to map this to the ASN.1 matching syntax of 350 "MATCHES EXACTLY". 352 5.11. Template for Translation 354 The template included below is derived from the printer service 355 scheme described in [5]. All translations assume the use of ASN.1 356 data types supported by all LDAP servers. 358 type = printer 359 version = 0.0 360 language = en 362 description = 363 The printer service template describes the attributes 364 supported by network printing devices. Devices may be 365 either directly connected to a network, or connected to a 366 printer spooler that understands the a network queuing 367 protocol such as IPP, lpr or the Salutation Architecture. 369 url-syntax = 370 The URL syntax is specific to the printing protocol being 371 employed 373 description = STRING 374 # This attribute is a free form string that can contain any 375 # site-specific descriptive information about this printer. 377 security-mechanisms-supported = STRING L M 378 none 379 # This attribute indicates the security mechanisms supported 380 tls, ssl, http-basic, http-digest, none 382 operator = STRING L M 383 # A person, or persons responsible for maintaining a 384 # printer on a day-to-day basis, including such tasks 385 # as filling empty media trays, emptying full output 386 # trays, replacing toner cartridges, clearing simple 387 # paper jams, etc. 389 location-address = STRING O 390 # Physical/Postal address for this device. Useful for 391 # nailing down a group of printers in a very large corporate 392 # network. For example: 960 Main Street, San Jose, CA 95130 394 priority-queue = BOOLEAN O 395 FALSE 396 # TRUE indicates this printer or print queue is a priority 397 # queuing device. 399 number-up = INTEGER O 400 1 401 # This job attribute specifies the number of source 402 # page-images to impose upon a single side of an instance 403 # of a selected medium. 404 1, 2, 4 406 paper-output = STRING M L O 407 standard 408 # This attribute describes the mode in which pages output 409 # are arranged. 410 standard, noncollated sort, collated sort, stack, unknown 412 5.12. Translated Schema 414 This translated schema uses the template attributes primarily as 415 comments in the beginning of the schema definition. Since all 416 Objects must support a cannonical name (cn), we use the URL as 417 the value for an object cn. This maps well, as a cn identifies a 418 particular object and a URL identifies a particular resource. 420 -- The printer service template describes the attributes 421 -- supported by network printing devices. Devices may be either 422 -- directly connected to a network, or connected to a printer 423 -- spooler that understands the a network queuing protocol such as 424 -- IPP, lpr or the Salutation Architecture. 425 printer OBJECT-CLASS 426 SUBCLASS OF top 427 MUST CONTAIN { 428 dn, 429 url, 430 description, 431 security-mechanisms-supported 432 } 433 MAY CONTAIN { 434 operator, 435 location-address, 436 priority-queue, 437 number-up, 438 paper-output 439 } 441 dn OBJECT-TYPE 442 SYNTAX Distinguished Name 443 DESCRIPTION 444 "The DN of the printer being described" 446 url OBJECT-TYPE 447 SYNTAX Case Ignore String 448 DESCRIPTION 449 "The URL of the printer being described" 451 description OBJECT-TYPE 452 SYNTAX Case Ignore String 453 DESCRIPTION 454 "This attribute is a free form string that can contain 455 Any site-specific descriptive information about this 456 printer." 458 security-mechanisms-supported OBJECT-TYPE 459 SYNTAX Case Ignore String 460 DESCRIPTION 461 "This attribute indicates the security mechanisms 462 supported. These values are: 463 tls 464 ssl 465 http-basic 466 http-digest 467 none" 469 operator OBJECT-TYPE 470 SYNTAX SET OF Case Ignore String 471 DESCRIPTION 472 "A person, or persons responsible for maintaining a 473 printer on a day-to-day basis, including such tasks 474 as filling empty media trays, emptying full output 475 trays, replacing toner cartridges, clearing simple 476 paper jams, etc." 478 location-address OBJECT-TYPE 479 SYNTAX Case Ignore String 480 DESCRIPTION 481 "Physical/Postal address for this device. Useful for 482 nailing down a group of printers in a very large 483 corporate network. For example: 960 Main Street, 484 San Jose, CA 95130" 486 priority-queue OBJECT-TYPE 487 SYNTAX Case Ignore String 488 DESCRIPTION 489 "TRUE indicates this printer or print queue is a priority 490 queuing device." 492 number-up OBJECT-TYPE 493 SYNTAX INTEGER 494 DESCRIPTION 495 "This job attribute specifies the number of source 496 page-images to impose upon a single side of an instance 497 of a selected medium." 499 paper-output OBJECT-TYPE 500 SYNTAX Case Ignore String 501 DESCRIPTION 502 "This attribute describes the mode in which pages 503 output are arranged. These values are: 504 standard 505 noncollated sort 506 collated sort 507 stack 508 unknown" 510 6. Mapping from Schemas to Templates 512 ASN.1 employs a much richer set of data types than provided by SLP. 513 The table below show the mapping of selected ASN.1 data type to their 514 nearest SLP equivalent. Because of the complexity and flexibility of 515 ASN.1, a complete list cannot be provided. 517 As sample of some ASN.1 encodings and their mappings to SLP: 519 ASN.1 type SLP type 520 --------------------------------------- 521 Integer Integer 522 Case Exact String String 523 Case Ignore String String 524 Boolean Boolean 525 Octet String Opaque 526 Binary Opaque 527 Enumeration String 528 Set Of 'M' flag 529 Real String 530 Object Identifier String 531 Sequence Of Multiple Attributes 533 6.1. Data Type Mappings 535 ASN.1 supports a much larger range of values. As such, a subset 536 will be selected for mapping SLP values. ASN.1 uses BER encoding as 537 described in CCITT Recommendation X.209[2]. BER encodings are based 538 on tuples containing a Type, Length and Contents. 540 6.2. Integer 542 Both SLP templates and ASN.1 support Integers, so there is a one to 543 one mapping between an SLP Integer attribute and an ASN.1 Integer 544 attribute. Details on the encoding of integers is summarized in the 545 SLP template to ASN.1 section above, as well as being explained in 546 detail in RFC2165[3] and the X.209[2] specification. 548 6.3. Case Ignore String, Case Exact String 550 Strings are supported between both SLP and ASN.1. SLP encoding 551 of the strings must conform to the rules for handling special 552 characters, as outlined in RFC 2165 [3]. 554 6.4. Boolean 556 Boolean values are supported by both SLP and ASN.1, though on wire 557 encodings will vary. X.209[2] specifies zero and non-zero encoding 558 for booleans, where SLP encodes booleans using the strings TRUE and 559 FALSE. 561 6.5. Octet String 563 An ASN.1 octet string should be mapped to an Opaque in an SLP 564 template. An octet string is a sequence of bytes, whereas an Opaque 565 is a sequence of bytes that has been encoded using radix64. 567 6.6. Binary 569 An ASN.1 Binary should be mapped to an Opaque in an SLP template. A 570 binary value is a sequence of bytes, whereas an Opaque is a sequence 571 of bytes that has been encoded using radix64. 573 6.7. Enumeration 575 SLP templates support the concept of enumerations through the listing 576 of values in the attribute definition. This is similar to the ASN.1 577 definition of enumerations, though encodings vary. In SLP enumerated 578 values are passed between client and server as strings. BER encodes 579 the ASN.1 enumeration by passing the number of the elements position 580 in the enumeration. This requires both sides to have knowledge of 581 the specific enumeration prior to decoding an enumerations value. 582 Example: 584 color-supported = STRING M 585 none 586 # This attribute specifies whether the Printer supports 587 # color and, if so, what type. 588 none, highlight, three color, four color, monochromatic 590 In this example, 'none' would have a value of 1, 'highlight' would be 591 2, 'three color' would be 3, etc. 593 6.8. Rules for Other ASN.1 Primitive Types 595 It is not reasonable to think that all ASN.1 data types can be 596 accurately represented using the very basic data types defined in 597 ASN.1. As such, data types that do not map directly to SLP data 598 types should be defined as either a String, or as Opaque. ASN.1 599 types that may only contain valid characters for Strings, as defined 600 in X.209[2] should be encoded as strings. If a value may contain 601 illegal string values, the SLP Opaque type should be used. In 602 either case, the first line of the help text is used to indicate the 603 original ASN.1 data type. 605 6.9. Set Of 607 Sets can be accommodated in an SLP template by specifying the 608 attribute is multivalued. The flag 'M' is used to indicate an 609 attribute Can have multiple values. All values must be of the same 610 type. As such, a multivalued attribute of type string could have 611 values of "one, 2, three", but the value 2 would be returned as 612 a string, not an integer. Likewise, a multivalued integer could 613 not have a value of "1, 2, three", as all values would need to be 614 converted to strings, which are illegal for an attribute of type 615 integer. 617 6.10. Real 619 There is no direct mapping between floating point numbers and any 620 SLP data types. As such, attributes are defined as type String. 621 Comments are added to the attribute help text indicating the value 622 was originally an ASN.1 real. For example: 624 weight = STRING 625 # ASN.1: Real 626 # The objects weight in pounds. 628 6.11. Object Identifier 630 Object identifiers(OIDs) are commonly used in the ASN.1 world to 631 identify object and attributes. OIDs are a numerical representation 632 of an elements place in the naming hierarchy. Each element at a 633 particular level of a hierarchy has a unique number assigned within 634 that level of the hierarchy. A sample OID would be the naming tree 635 for SNMP MIBs. 637 iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would be written as 638 the string 1.3.6.1.2.1 640 Because this representation reduces down to a string of dot separated 641 numbers, this maps easily to the SLP String type. The help text for 642 this element should indicate it is an ASN.1 OID 644 identifier = STRING 645 # ASN.1: OID 646 # The object identifier for this SNMP agent. 648 6.12. Sequence Of 650 The ASN.1 construct 'Sequence Of' is probably the least intuitive to 651 map to an SLP template. SLP attributes can only contain values of 652 like type. By definition, this is an ASN.1 SET OF. ASN.1 sequences 653 are made of multiple values of different types. For example, an 654 attribute named 'Engine' may be defined as: 656 engine OBJECT-TYPE 657 SYNTAX SEQUENCE OF { 658 name DisplayString, 659 status INTEGER { 660 unknown(1) 661 running(2) 662 shutdown(3) 663 } 664 } 665 DESCRIPTION 666 "Engine description." 668 In order to map this to an SLP template, we can create multiple 669 attributes and rely on the ordering for association. The above 670 translates as: 672 engine-name = STRING M 673 # The name of one of this craft's engines. 675 engine-status = STRING M 676 unknown 677 # The state of this crafts engines. 678 unknown, running, shutdown 680 To do this, we are relying on an assumption stated in the service: 681 Scheme Draft [1] that all values of a multivalued attribute retain 682 their order. When new values are added, they are added to the end of 683 the list of values. 685 As such, if we had: 686 engine-name = right, left 687 engine-status = running, shutdown 689 We would assume that the engine named right is running and the engine 690 named left is shutdown. 692 6.13. Schema to be Translated 694 In general, ASN.1 provides a much more general set of data types than 695 provided for by SLP. For this reason, it is more complex to convert 696 LDAP schemas to templates for SLP. 698 The following schema represents an example of a schema for an 699 exported filesystem. The section presents it as in ASN.1 and the 700 following section shows the SLP template translation. 702 -- abstraction of a fstab entry (a "mount") 703 -- these lookups would likely be performed by an 704 -- an automounter type application 705 mount OBJECT-CLASS 706 SUBCLASS OF top 707 MUST CONTAIN { 708 -- the mount host 709 mountHost, 710 -- the mount point 711 mountDirectory. 712 -- the mount type 713 mountType 714 } 715 MAY CONTAIN { 716 -- mount options 717 mountOption, 718 -- dump frequency 719 mountDumpFrequency, 720 -- passno 721 mountPassNo 722 } 724 mountHost OBJECT-TYPE 725 SYNTAX Case Ignore String 726 DESCRIPTION 727 "The mount host" 729 mountDirectory 730 SYNTAX Case Ignore String 731 DESCRIPTION 732 "The filesystem to mount" 734 mountType OBJECT-TYPE 735 SYNTAX INTEGER { 736 ufs(1) 737 hsfs(2) 738 nfs(3) 739 rfs(4) 740 } 741 DESCRIPTION 742 "The type of the filesystem being mounted" 744 mountOption OBJECT-TYPE 745 SYNTAX SET OF Case Ignore String 746 DESCRIPTION 747 "mount options for this filesystem" 749 mountDumpFrequency OBJECT-TYPE 750 SYNTAX INTEGER (0..9) 751 DESCRIPTION 752 "How often to dump this filesystem" 754 mountPassNo OBJECT-TYPE 755 SYNTAX Integer 756 DESCRIPTION 757 "Boot time mount pass number" 759 6.14. SLP Translation 761 type = mount 762 version = 1.0 764 language = en 766 description = "This would describe a remote filesystem 767 access protocol" 769 url-syntax = 770 filesystem = 1*[ DIGIT / ALPHA ] 771 urlpath = "/" filesystem 773 mountHost = STRING L 774 # The mount host 776 mountDirectory = STRING L 777 # The filesystem to mount 779 mountType = STRING L 780 ufs 781 # The type of the filesystem being mounted 782 ufs, hsfs, nfs, rfs 784 mountOption = STRING M O L 785 # mount options for this filesystem 787 mountDumpFrequency = INTEGER O 788 0 789 # How often to dump this filesystem 790 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 792 mountPassNo = INTEGER O 793 # Boot time mount pass number 795 7. Notes on Matching Operators 797 The SLP template grammar does not describe the matching properties of 798 attributes, but ASN.1 does. If choosing to add matching properties 799 to an SLP template when converting it to an ASN.1 based schema, the 800 following rules should be kept in mind. 802 LDAP and SLP support the same matching operations, though using 803 slightly different matching semantics. In addition to greaterOrEqual 804 and lessOrEqual, SLP provides for a simple less or greater match. 806 LDAP Search Operators SLP Search Operators 807 and (&) & 808 or (|) | 809 not (!) != 810 equalityMatch (=) == 811 substrings 812 greaterOrEqual (>=) >= 813 lessOrEqual (<=) <= 814 present (=*) 816 ASN.1 provides for three varieties of substring value matching, 817 namely initial, any, and final. In specifying the match capability 818 of an attribute, ASN.1 specifies that a value may match the leading 819 part, any part, or the final part of a string value. Using the SLP 820 search semantics, this is accomplished through the substring (*) 821 operator. Searching for initial, any or final is handled through 822 specific placement of the operator. The following example, taken 823 from RFC2165 illustrates this: 825 initial: "bob*" matches "bob", "bobcat", and "bob and sue" 826 final: "*bob" matches "bob", "bigbob", and "sue and bob" 827 any: "*bob*" matches "bob", "bobcat", "bigbob", 828 and "a bob I know" 830 8. Acknowledgments 832 Thanks to Jonathan Wood for the suggestion to use MD5 hashes to avoid 833 character escape problems between URLs and DNs. 835 A. References 837 [1]E. Guttman, C. Perkins, J. Kempf "Service Templates and service: 838 Schemes", Work in Progress, March, 1987 839 draft-ietf-svrloc-service-scheme-09.txt 841 [2]W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access 842 Protocol", RFC1777. 03/28/1995. 844 [3]J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. "Service 845 Location Protocol", RFC 2165. June 1997. 847 [4]CCITT Recommendation X.209, "Specification of Basic Encoding 848 Rules for Abstract Syntax Notation One (ASN.1), 1988 850 [5]P. St. Pierre, "Definition of printer: URLs for use with Service 851 Location", Work in Progress, March, 1998 852 draft-ietf-svrloc-printer-scheme-02.txt 854 [6]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT 855 Laboratory for Computer Science and RSA Data Security, Inc., 857 Full Copyright Statement 859 Copyright (C) The Internet Society (1997). All Rights Reserved. 861 This document and translations of it may be copied and furnished to 862 others, and derivative works that comment on or otherwise explain it 863 or assist in its implmentation may be prepared, copied, published 864 and distributed, in whole or in part, without restriction of any 865 kind, provided that the above copyright notice and this paragraph 866 are included on all such copies and derivative works. However, 867 this document itself may not be modified in any way, such as by 868 removing the copyright notice or references to the Internet Society 869 or other Internet organizations, except as needed for the purpose 870 of developing Internet standards in which case the procedures 871 for copyrights defined in the Internet Standards process must be 872 followed, or as required to translate it into languages other than 873 English. 875 The limited permissions granted above are perpetual and will not be 876 revoked by the Internet Society or its successors or assigns. 878 This document and the information contained herein is provided on an 879 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 880 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 881 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 882 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 883 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 885 Authors' Address 887 Questions about this memo can be directed to: 889 Pete St. Pierre 890 Sun Microsystems 891 901 San Antonio Avenue 892 Palo Alto, CA 94303 893 USA 894 Phone: +1 415 786-5790 895 email: Pete.StPierre@Eng.Sun.COM