idnits 2.17.1 draft-ietf-urn-ddds-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: ---------------------------------------------------------------------------- ** 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 183 has weird spacing: '...im-char ere ...' -- 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 (November 1, 2000) is 8567 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-09) exists of draft-ietf-urn-dns-ddds-database-00 == Outdated reference: A later version (-07) exists of draft-ietf-urn-uri-res-ddds-00 ** Obsolete normative reference: RFC 2915 (ref. '6') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2916 (ref. '7') (Obsoleted by RFC 3761) ** Obsolete normative reference: RFC 2168 (ref. '8') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mealling 3 Internet-Draft Network Solutions, Inc. 4 Expires: May 2, 2001 November 1, 2000 6 Dynamic Delegation Discovery System (DDDS) 7 draft-ietf-urn-ddds-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 This Internet-Draft will expire on May 2, 2001. 29 Copyright Notice 31 Copyright (C) The Internet Society (2000). All Rights Reserved. 33 Abstract 35 This document describes the Dynamic Delegation Discovery System 36 (DDDS). The DDDS defines an abstract algorithm for applying 37 dynamically retrieved string transformation rules to an 38 application-unique string. Well-formed transformation rules will 39 reflect the delegation of management of information associated with 40 the string. This memo does not specify any application or database, 41 although it does define the requirements for doing so. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 5 48 3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 5 49 3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 5 50 3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 7 51 4. Specifying An Application . . . . . . . . . . . . . . . . . . 9 52 5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 11 53 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 54 6.1 An Automobile Parts Identification System . . . . . . . . . . 13 55 6.2 A Document Identification Service . . . . . . . . . . . . . . 14 56 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 58 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 60 1. Introduction 62 The Dynamic Delegation Discovery System is used to map some unique 63 string to data stored within the DDDS by iteratively applying string 64 transformation rules until a terminal condition is reached. This 65 document describes the general algorithm, not any particular 66 application or usage scenario. It is up to other documents to 67 describe how they use the DDDS algorithms. Two such documents are 68 RFXXXX[5] which describes the URI Resolution Application and 69 RFC2916[7] which describes the E.164 Telephone Number to URI Mapping 70 Application. 72 The DDDS's history is an evolution from work done by the Uniform 73 Resource Name Working Group. When Uniform Resource Names[1] were 74 originally formulated there was the desire to locate an 75 authoritative server for a URN which by design contained no 76 information about network locations. A system was formulated that 77 could use a database of rules that could be applied to a URN to find 78 out information about specific chunks of syntax. This system was 79 originally called the Resolver Discovery System[2] and only applied 80 to URNs. 82 Over time other systems began to apply this same algorithm and 83 infrastructure to other, non-URN related, systems. This caused some 84 of the underlying assumptions to change and need clarification. This 85 document, which is one of a series, is an update of those original 86 URN specifications in order to allow new applications and rule 87 databases to be developed in a standardized manner. 89 A direct result of these clarifications and generalizations is that 90 this document, along with RFC YYYY[4] and RFC XXXX[5], obsoletes RFC 91 2168[8] and RFC 2915[6] as well as updates RFC 2276[2]. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 97 this document are to be interpreted as described in RFC 2119. 99 Application Unique String 100 The string that is the target of all the rewrite rules. By the 101 nature of the DDDS algorithm, each string defines a unique 102 delegation path; therefore strings must be chosen to reflect the 103 one-to-one relationship between whatever is being delegated and 104 the string (uniqueness). 106 Rewrite Rule 107 An object containing several pieces of data that, when combined 108 and applied to an Application Unique String, produces a new key 109 that exists in the Rule Database. Also simply known as a Rule. 111 First Well Known Rule 112 This is a rewrite rule that is defined by the application and not 113 actually in the Rule Database. It is used to produce the first 114 valid key. 116 Terminal Rule 117 This Rule is one where the Flags specify that the iterative 118 process is over and that the output of applying this Rule to the 119 Application Unique String will be the intended output of the 120 entire process. 122 Application 123 A set of protocols and specifications that specify actual values 124 for the various generalized parts of the DDDS algorithm. An 125 Application must define the syntax and semantics of the 126 Application Unique String, the First Well Known Rule, and which 127 Databases are valid for the Application. 129 Database 130 Any store of Rules such that a unique key can identify a set of 131 Rules that specify the delegation step used when that particular 132 Key is used. 134 3. The Algorithm 136 The DDDS algorithm is based on the concept of Rewrite Rules. These 137 rules are given unique Keys that are collected into a database that 138 is known as a DDDS Rule Database. A given Rule, when applied to an 139 Application Unique String, transforms that String into new Key that 140 can be used to retrieve a new Rule from the Rule Database. This new 141 rule is then re-applied to the original Application Unique String 142 and the cycle repeats itself until a terminating condition is 143 reached. 145 3.1 Components of a Rule 147 A Rule is made up of 4 pieces of information: 149 A Priority 150 Simply a number used to show which of two otherwise equal rules 151 may have precedence. This allows the database to express rules 152 that are equivalent but weighted for load balancing reasons. 154 A set of Flags 155 Flags are used to specify attributes of the rule that determine 156 if this rule is the last one to be applied. The last rule is 157 called the terminal rule and its output should be the intended 158 result for the application. 160 A description of Services 161 Services are used to specify attributes of a particular 162 delegation branch. For example, two rules may equally apply to a 163 specific delegation decision for a string. One rule can lead to a 164 terminal rule that produces information for use in high 165 availability environments while another may lead to an archival 166 service that may be slower but is more stable over long periods 167 of time. 169 A Substitution Expression 170 This is the actual string modification part of the rule. It is a 171 combination of a POSIX Extended Regular Expression[3] and a 172 replacement string similar to Unix sed(1) search-replace 173 function. See Section 3.2. 175 3.2 Substitution Expression Syntax 177 The syntax of the Substitution Expression part of the rule is a 178 sed-style substitution expression. True sed(1) substitution 179 expressions are not appropriate for use in this application for a 180 variety of reasons, therefore the contents of the regexp field MUST 181 follow this grammar: 183 subst-expr = delim-char ere delim-char repl delim-char *flags 184 delim-char = "/" / "!" / 185 ; All ocurances of a delim_char in a subst_expr must 186 ; be the same character.> 187 ere = 188 repl = *(string / backref) 189 string = *(anychar / escapeddelim) 190 anychar = 191 escapeddelim = "\" delim-char 192 backref = "\" POS-DIGIT 193 flags = "i" 194 POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 196 The result of applying the substitution expression to the String 197 MUST result in a key which obeys the rules of the Database. Since it 198 is possible for the regular expression to be improperly specified, 199 such that a non-conforming key can be constructed, client software 200 SHOULD verify that the result is a legal database key before using 201 it. 203 Backref expressions in the repl portion of the substitution 204 expression are replaced by the (possibly empty) string of characters 205 enclosed by '(' and ')' in the ERE portion of the substitution 206 expression. N is a single digit from 1 through 9, inclusive. It 207 specifies the N'th backref expression, the one that begins with the 208 N'th '(' and continues to the matching ')'. For example, the ERE 210 (A(B(C)DE)(F)G) 212 has backref expressions: 214 \1 = ABCDEFG 215 \2 = BCDE 216 \3 = C 217 \4 = F 218 \5..\9 = error - no matching subexpression 220 The "i" flag indicates that the ERE matching SHALL be performed in a 221 case-insensitive fashion. Furthermore, any backref replacements MAY 222 be normalized to lower case when the "i" flag is given. This flag 223 only has meaning when both the Application and Database define a 224 character set where case insensitivity is valid. 226 The first character in the substitution expression shall be used as 227 the character that delimits the components of the substitution 228 expression. There must be exactly three non-escaped occurrences of 229 the delimiter character in a substitution expression. Since escaped 230 occurrences of the delimiter character will be interpreted as 231 occurrences of that character, digits MUST NOT be used as 232 delimiters. Backrefs would be confused with literal digits were this 233 allowed. Similarly, if flags are specified in the substitution 234 expression, the delimiter character must not also be a flag 235 character. 237 The character set(s) that the substitution expression is in and can 238 act on are dependent both on the Application and on the Database 239 being used. An Application must define what the allowed character 240 sets are for the Application Unique String. A DDDS Database 241 specification must define what character sets are required for 242 producing its keys and for how the substitution expression itself is 243 encoded. The grammar required characters from above only have 244 meaning once a specific character set is defined for the Database or 245 Application. 247 3.3 The Complete Algorithm 249 The following is the exact DDDS algorithm: 251 1. The First Well Known Rule is applied to the Application Unique 252 String which produces a Key 254 2. That Application asks the Database for the ordered set of Rules 255 that are bound to that Key 257 3. The Substitution Expression of each Rule in the list of Rules is 258 applied to the String in the order in which they were received. 259 In some applications and/or databases the result set can express 260 the case where two or more Rules are considered equal. These 261 Rules are treated as the same Rule, each one possibly having a 262 Priority which is used to weight a random selection among the 263 equivalent Rules (this allows for Rules to 'load balance' 264 themselves). 266 4. The first/next Rule with a Substitution Expression that produces 267 anything other than the empty string is examined to see if the 268 parameters in the Services part of the Rule meet the 269 requirements of the Application. 271 5. If the parameters in the Service part of the Rule do not match 272 those required by the Application then go back to Step 4. 274 6. If the Flags part of the Rule designate that this Rule is 275 Terminal, then apply the Substitution Expression to the String 276 and then go to Step 8. 278 7. Apply the Substitution Expression to the String. The output of 279 this rewrite becomes the new Key. To begin the next iteration, 280 return to Step 2 and use this new Key as the Key in that step. 282 8. Notify the Application that the process has finished and provide 283 the Application with the Flags and Services part of the Rule 284 along with the output of the last Substitution Expression. 286 4. Specifying An Application 288 In order for this algorithm to have any usefulness, a specification 289 must be written describing an application and one or more databases. 290 In order to specify an application the following pieces of 291 information are required: 293 Application Unique String: 294 This is the only string that the rewrite rules will apply to. The 295 string must have some regular structure and be unique within the 296 application such that anyone applying Rules taken from the same 297 Database will end up with the same Keys. For example, the URI 298 Resolution application defines the Application Unique String to 299 be a URI. 301 No application is allowed to define an Application Unique String 302 such that the Key obtained by a rewrite rule is treated as the 303 Application Unique String for input to a new rule. This leads to 304 sendmail style rewrite rules which are fragile and error prone. 305 The one single exception to this is when an Application defines 306 some flag or state where the rules for that application are 307 suspended and a new DDDS Application or some other arbitrary set 308 of rules take over. If this is the case then, by definition, none 309 of these rules apply. One such case can be found in the URI 310 Resolution application which defines the 'p' flag which states 311 that the next step is 'protocol specific' and thus outside of the 312 scope of DDDS. 314 First Well Known Rule: 315 This is the first rule that, when applied to the Application 316 Unique String, produces the first valid Key. It can be expressed 317 in the same form as a Rule or it can be something more complex. 318 For example, the URI Resolution application might specify that 319 the rule is that the sequence of characters in the URI up to but 320 not including the first colon (the URI scheme) is the first Key. 322 Valid Databases: 323 The application can define which Databases are valid. For each 324 Database the Application must define how the First Well Known 325 Rule's output (the first Key) is turned into something that is 326 valid for that Database. For example, the URI Resolution 327 application could use the Domain Name System (DNS) as a Database. 328 The operation for turning this first Key into something that was 329 valid for the database would be to to turn it into some DNS-valid 330 domain-name. Additionally, for each Database an Application 331 defines, it must also specify what the valid character sets are 332 that will produce the correct Keys. In the URI Resolution example 333 shown here, the character set of a URI is 7 bit ASCII which 334 matches fairly well with DNS's 8 bit limitation on characters in 335 its zone files. 337 Expected Output: 338 The Application must define what the expected output of the 339 Terminal Rule should be. For example, the URI Resolution 340 application is concerned with finding servers that contain 341 authoritative data about a given URI. Thus the output of the 342 terminal rule would be information (hosts, ports, protocols, etc) 343 that would be used to contact that authoritative server. 345 5. Specifying A Database 347 Additionally, any Application must have at least one corresponding 348 Database from which to retrieve the Rules. It is important to note 349 that a given Database may be used by more than one Application. If 350 this is the case, each rule must be use some combination of its 351 Services and/or substitution expression to match only those 352 Application Unique Strings for which it is valid. 354 A Database specification must include the following pieces of 355 information: 357 General Specification: 358 The Database must have a general specification. This can 359 reference other standards (SQL, DNS, etc) or it can fully specify 360 a novel database system. This specification must be clear as to 361 what allowed character sets exist in order to know in which 362 character set the Rules and subsequence substitution expression 363 are encoded. 365 Lookup Procedure: 366 This specifies how a query is formulated and submitted to the 367 database. In the case of databases that are used for other 368 purposes (such as DNS), the specification must be clear as to how 369 a query is formulated specifically for the database to be a DDDS 370 database. For example, a DNS based Database must specify which 371 Resource Records or Query Types are used. 373 Key Format: 374 If any operations are needed in order to turn a Key into 375 something that is valid for the database then these must be 376 clearly defined. For example, in the case of a DNS database, the 377 Keys must be constructed as valid domain-names. 379 Rule Format: 380 The specification for the output format of a rule. 382 Rule Insertion Procedure: 383 A specification for how a Rule is inserted into the database. 384 This can include policy statements about whether or not a Rule is 385 allowed to be added. 387 Rule Collision Avoidance: 388 Since a Database may be used by multiple Applications (ENUM and 389 URI Resolution for example), the specification must be clear 390 about collisions will be avoided. There are usually two methods 391 for handling this: 1) disallow one key from being valid in two 392 different Applications; 2) if 1 isn't possible then write the 393 substitution expression such that the regular expression part 394 contains enough of the Application Unique String as part of its 395 match to differentiate between the two Applications. 397 6. Examples 399 The examples given here are for pedagogical purposes only. They are 400 specifically taken from fictious applications that have not been 401 specified in any published document. 403 6.1 An Automobile Parts Identification System 405 In this example imagine a system setup where by all automobile 406 manufacturers come together and create a standardized part numbering 407 system for the various parts (nuts, bolts, frames, instruments, etc) 408 that make up the automobile manufacturing and repair process. The 409 problem with such a system is that the auto industry is a very 410 distributed system where parts are built by various third parties 411 distributed around the world. In order to find information about a 412 given part a system must be able to find out who makes that part and 413 contact them about it. 415 To facilitate this distributed system the identification number 416 assigned to a part is assigned hierarchically such that the first 5 417 digits make up a parts manufacturer ID number. The next 3 digits are 418 an auto line identifier (Ford, Toyota, etc). The rest of the digits 419 are assigned by the parts manufacturer according to rules that the 420 manufacturer decides. 422 The auto industry decides to use the DDDS to create a distributed 423 information retrieval system that routes queries to the actual owner 424 of the data. The industry specifies a database and a query syntax 425 for retrieving rewrite rules (the APIDA Network) and then specifies 426 the Auto Parts Identification DDDS Application (APIDA). 428 The APIDA specification would define the following: 430 o Application Unique String: the part number 432 o First Well Known Rule: take the first 5 digits (the manufacturers 433 ID number) and use that as the Key 435 o Valid Databases: The APIDA Network 437 o Expected Output: EDIFAC information about the part 439 The APIDA Network Database specification would define the following: 441 o General Specification: a network of EDI enabled databases and 442 services that, when given a subcomponent of a part number will 443 return an XML encoded rewrite rule 445 o Lookup Procedure: following normal APIDA Network protocols, ask 446 the network for a rewrite rule for the Key. 448 o Key Format: no conversion is required 450 o Rule Format: see APIDA Network documentation for the XML DTD 452 o Rule Insertion Procedure: determined by the authority that has 453 control over each section of the part number. I.e. in order to 454 get a manufacturer ID you must be a member of the Auto Parts 455 Manufacturers Association 457 In order to illustrate how the system would work, imagine the part 458 number "4747301AB7D". The system would take the first 5 digits, 459 '47473' and ask the network for that Rewrite Rule. This Rule would 460 be provided by the parts manufacturers database and would allow the 461 manufacturer to either further sub-delegate the space or point the 462 querier directly at the EDIFAC information in the system. 464 In this example let's suppose that the manufacturer returns a Rule 465 that states that the next 3 digits should be used as part of a query 466 to their service in order to find a new Rule. This new Rule would 467 allow the parts manufacturer to further delegate the query to their 468 parts factories for each auto line. In our example part number the 469 number '01A' denotes the Toyota line of cars. The Rule that the 470 manufacturer returns further delegates the query to a supply house 471 in Japan. This rule also denotes that this Rule is terminal and thus 472 the result of this last query will be the actual information about 473 the part. 475 6.2 A Document Identification Service 477 This example is very similar to the last since the documents in this 478 system can simply be thought of as the auto part in the last 479 example. The difference here is that the information about the 480 document is kept very close to the author (usually on their 481 desktop). Thus there is the probability that the number of 482 delegations can be very deep. Also, in order to keep from having a 483 large flat space of authors, the authors are organized by 484 organizations and departments. 486 Let's suppose that the Application Unique String in this example 487 looks like the following: 489 --:-- 491 The Application specification would look like this: 493 o Application Unique String: the Document ID string given above 494 o First Well Known Rule: the characters up to but not including the 495 first '-' is treated as the first Key. 497 o Valid Databases: the DIS LDAP Directory 499 o Expected Output: a record from an LDAP server containing 500 bibliographic information about the document in XML 502 The Database specification for the DIS LDAP Directory would look 503 like this: 505 o General Specification: the Database uses the LDAP directory 506 service. Each LDAP server has a record that contains the Rewrite 507 Rule. Rules refer to other LDAP servers using the LDAP URL scheme. 509 o Lookup Procedure: using standard LDAP queries, the client asks 510 the LDAP server for information about the Key. 512 o Key Format: no conversion is necessary. 514 o Rule Format: See the LDAP Rewrite Rule specification 516 o Rule Insertion Procedure: See the procedures published by the 517 entity that has authority over that section of the DIS tree. The 518 first section, the organization, is owned by the DIS Agency. 520 In this example, the first lookup is for the organization's Rule. At 521 that point the organization may point the client directly at some 522 large, organization wide database that contains the expected output. 523 Other organizations may decentralize this process so that Rules end 524 up delegating the query all the way down to the authors document 525 management environment of choice. 527 References 529 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 531 [2] Sollins, K., "Architectural Principles of Uniform Resource Name 532 Resolution", RFC 2276, January 1998. 534 [3] The Institute of Electrical and Electronics Engineers, "IEEE 535 Standard for Information Technology - Portable Operating System 536 Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE 537 Std 1003.2-1992, ISBN 1-55937-255-9, January 1993. 539 [4] Mealling, M., "A DDDS Database Using The Domain Name System", 540 RFC YYYY, Internet-Draft 541 draft-ietf-urn-dns-ddds-database-00.txt, May 2000. 543 [5] Mealling, M., "URI Resolution using the Dynamic Delegation 544 Discovery System", RFC XXXX, Internet-Draft 545 draft-ietf-urn-uri-res-ddds-00.txt, July 2000. 547 [6] Mealling, M. and R.D. Daniel, "The Naming Authority Pointer 548 (NAPTR) DNS Resource Record", RFC 2915, August 2000. 550 [7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. 552 [8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 553 Identifiers using the Domain Name System", RFC 2168, June 1997. 555 Author's Address 557 Michael Mealling 558 Network Solutions, Inc. 559 505 Huntmar Park Drive 560 Herndon, VA 22070 561 US 563 Phone: +1 770 935 5492 564 EMail: michaelm@netsol.com 565 URI: http://www.netsol.com 567 Full Copyright Statement 569 Copyright (C) The Internet Society (2000). All Rights Reserved. 571 This document and translations of it may be copied and furnished to 572 others, and derivative works that comment on or otherwise explain it 573 or assist in its implmentation may be prepared, copied, published 574 and distributed, in whole or in part, without restriction of any 575 kind, provided that the above copyright notice and this paragraph 576 are included on all such copies and derivative works. However, this 577 document itself may not be modified in any way, such as by removing 578 the copyright notice or references to the Internet Society or other 579 Internet organizations, except as needed for the purpose of 580 developing Internet standards in which case the procedures for 581 copyrights defined in the Internet Standards process must be 582 followed, or as required to translate it into languages other than 583 English. 585 The limited permissions granted above are perpetual and will not be 586 revoked by the Internet Society or its successors or assigns. 588 This document and the information contained herein is provided on an 589 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 590 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 591 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 592 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 593 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Acknowledgement 597 Funding for the RFC editor function is currently provided by the 598 Internet Society.