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