idnits 2.17.1 draft-ietf-urn-dns-ddds-database-06.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: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC2915, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 359 has weird spacing: '... regexp repla...' -- 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 (August 28, 2001) is 8277 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) -- Looks like a reference, but probably isn't: 'A-Z0-9' on line 225 == Unused Reference: '4' is defined on line 483, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 487, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 490, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 493, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 497, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 501, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2141 (ref. '9') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '10') == Outdated reference: A later version (-07) exists of draft-ietf-urn-ddds-00 == Outdated reference: A later version (-07) exists of draft-ietf-urn-uri-res-ddds-00 ** Obsolete normative reference: RFC 2915 (ref. '13') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2168 (ref. '14') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2279 (ref. '15') (Obsoleted by RFC 3629) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mealling 3 Internet-Draft VeriSign 4 Expires: February 26, 2002 August 28, 2001 6 A DDDS Database Using The Domain Name System 7 draft-ietf-urn-dns-ddds-database-06 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 Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on February 26, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This document describes a Dynamic Delegation Discovery System 39 Database using the Domain Name System as a distributed database of 40 Rules. The Keys are domain-names and the Rules are encoded using the 41 NAPTR Resource Record. 43 Since this document officially obsoletes RFC 2915, it is the official 44 specification for the NAPTR DNS Resource Record. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. DDDS Database Specification . . . . . . . . . . . . . . . . 5 51 4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 7 52 4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7 53 4.2 Additional Information Processing . . . . . . . . . . . . . 9 54 4.2.1 Additional Section processing by DNS servers . . . . . . . . 9 55 4.2.2 Additional Section processing by resolver/applications . . . 9 56 4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 9 57 5. Application Specifications . . . . . . . . . . . . . . . . . 10 58 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 12 61 7. Advice for DNS Administrators . . . . . . . . . . . . . . . 14 62 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 64 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 65 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 69 1. Introduction 71 The NAPTR DNS Resource Record was originally produced by the URN 72 Working Group as a way to encode rule-sets in DNS so that the 73 delegated sections of a URI could be decomposed in such a way that 74 they could be changed and re-delegated over time. The result was a 75 Resource Record that included a regular expression that would be used 76 by a client program to rewrite a string into a domain name. Regular 77 expressions were chosen for their compactness to expressivity ratio 78 allowing for a great deal of information to be encoded in a rather 79 small DNS packet. 81 Over time this process was generalized for other Applications and 82 Rule Databases. This document defines a Rules Database absent any 83 particular Application as there may be several Applications all 84 taking advantage of this particular Rules Database. 86 As a result of this generalization, this document, along with RFC 87 ZZZZ [11] and RFC XXXX [12], obsoletes RFC 2168 [14], RFC 2915 [13] 88 and updates RFC 2276 [10]. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [1]. 96 All other terminology, especially capitalized terms, is taken from 97 [11]. 99 3. DDDS Database Specification 101 General Description: 102 This database uses the Domain Name System (DNS) as specified in 103 [3] and [2]. 105 The character set used to specify the various values of the NAPTR 106 records is UTF-8 [15]. Care must be taken to ensure that, in the 107 case where either the input or the output to the substitution 108 expression contains code points outside of the ASCII/Unicode 109 equivalence in UTF-8, any UTF-8 is interpreted as a series of 110 code-points instead of as a series of bytes. This is to ensure 111 that the internationalized features of the POSIX Extended Regular 112 Expressions are able to match their intended code-points. 113 Substitution expressions MUST NOT be written where they depend on 114 a specific POSIX locale since this would cause substutition 115 expressions to loose their ability to be universally applicable. 117 Key Format: 118 A Key is a validly constructed DNS domain-name. 120 Lookup Request: 121 In order to request a set of rules for a given Key, the client 122 issues a request, following standard DNS rules, for NAPTR Resource 123 Records for the given domain-name. 125 Lookup Response: 126 The response to a request for a given Key (domain-name) will be a 127 series of NAPTR records. The format of a NAPTR Resource Record 128 can be found in Section 4. 130 Rule Insertion Procedure: 131 Rules are inserted by adding new records to the appropriate DNS 132 zone. If a Rule produces a Key that exists in a particular zone 133 then only the entity that has administrative control of that zone 134 can specify the Rule associated with that Key. 136 Collision Avoidance: 137 In the case where two Application may use this Database (which is 138 actually the case with the ENUM and URI Resolution Applications), 139 there is a chance of collision between rules where two NAPTR 140 records appear in the same domain but they apply to more than one 141 Appliation. There are three ways to avoid collisions: 143 * create a new zone within the domain in common that contains 144 only NAPTR records that are appropriate for the application. 145 E.g., all URI Resolution records would exist under 146 urires.example.com and all ENUM records would be under 147 enum.example.com. In the case where this is not possible due 148 to lack of control over the upstream delegation the second 149 method is used. 151 * write the regular expression such that it contains enough of 152 the Application Unique string to disambiguate it from any 153 other. For example, the URI Resolution Application would be 154 able to use the scheme name on the left hand side to anchor the 155 regular expression match to that scheme. An ENUM specific 156 record in that same zone would be able to anchor the left hand 157 side of the match with the "+" character which is defined by 158 ENUM to be at the beginning of every Application Unique String. 159 This way a given Appliation Unique String can only match one or 160 the other record, not both. 162 * if two Application use different Flags or Services values then 163 a record from another Application will be ignored since it 164 doesn't apply to the Services/Flags in question. 166 4. NAPTR RR Format 168 4.1 Packet Format 170 The packet format of the NAPTR RR is given below. The DNS type code 171 for NAPTR is 35. 173 The packet format for the NAPTR record is as follows 174 1 1 1 1 1 1 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 176 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 177 | ORDER | 178 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 179 | PREFERENCE | 180 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 181 / FLAGS / 182 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 183 / SERVICES / 184 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 185 / REGEXP / 186 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 187 / REPLACEMENT / 188 / / 189 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 191 and as used here are defined in 192 RFC1035 [2]. 194 ORDER 195 A 16-bit unsigned integer specifying the order in which the NAPTR 196 records MUST be processed in order to accurately represent the 197 ordered list of Rules. The ordering is from lowest to highest. 198 If two records have the same order value then they are considered 199 to be the same rule and should be selected randomly unless the 200 Preference numbers are different which means the randomization is 201 weighted according to the ratio of the Preference values. 203 PREFERENCE 204 Although it is called "preference" in deference to DNS 205 terminology, this field is equivalent to the Priority value in the 206 DDDS Algorithm. It is a 16-bit unsigned integer that specifies 207 the order in which NAPTR records with equal Order values SHOULD be 208 processed, low numbers being processed before high numbers. This 209 is similar to the preference field in an MX record, and is used so 210 domain administrators can direct clients towards more capable 211 hosts or lighter weight protocols. A client MAY look at records 212 with higher preference values if it has a good reason to do so 213 such as not understanding some protocol or service. 215 The important difference between Order and Preference is that once 216 a match is found the client MUST NOT consider records with a 217 different Order but they MAY process records with the same Order 218 but different Preferences. I.e. Preference is used to give 219 weight to rules that are considered the same from an authority 220 standpoint but not from a simple load balancing standpoint. 222 FLAGS 223 A containing flags to control aspects of the 224 rewriting and interpretation of the fields in the record. Flags 225 are single characters from the set [A-Z0-9]. The case of the 226 alphabetic characters is not significant. 228 It is up to the Application specifying how it is using this 229 Database to define the Flags in this field. It must define which 230 ones are terminal and which ones are not. 232 SERVICES 233 A that specifies the Service Parameters 234 applicable to this this delegation path. It is up to the 235 Application Specification to specify the values found in this 236 field. 238 REGEXP 239 A containing a substitution expression that is 240 applied to the original string held by the client in order to 241 construct the next domain name to lookup. See the DDDS Algorithm 242 specification for the syntax of this field. 244 As stated in the DDDS algorithm, The regular expressions MUST NOT 245 be used in a cumulative fashion, that is, they should only be 246 applied to the original string held by the client, never to the 247 domain name produced by a previous NAPTR rewrite. The latter is 248 tempting in some applications but experience has shown such use to 249 be extremely fault sensitive, very error prone, and extremely 250 difficult to debug. 252 REPLACEMENT 253 A which is the next domain-name to query for 254 depending on the potential values found in the flags field. This 255 field is used when the regular expression is a simple replacement 256 operation. Any value in this field MUST be a fully qualified 257 domain-name. Name compression is not to be used for this field. 258 This field and the REGEXP field together make up the Substitution 259 Expression in the DDDS Algorithm. They are also mutually 260 exclusive. If a record is returned that has values for both 261 fields then it is considered to be in error and should be ignored. 263 4.2 Additional Information Processing 265 Additional section processing requires upgraded DNS servers, thus it 266 will take many years before applications can expect to see relevant 267 records in the additional information section. 269 4.2.1 Additional Section processing by DNS servers 271 DNS servers MAY add RRsets to the additional information section that 272 are relevant to the answer and have the same authenticity as the data 273 in the answer section. Generally this will be made up of A and SRV 274 records but the exact records depends on the application. 276 4.2.2 Additional Section processing by resolver/applications 278 Applications MAY inspect the Additional Information section for 279 relevant records but Applications MUST NOT require that records of 280 any type be in the Additional Information section of any DNS response 281 in order for clients to function. All Applications must be capable 282 of handling responses from nameservers that never fill in the 283 Additional Information part of a response. 285 4.3 Master File Format 287 The master file format follows the standard rules in RFC-1035[1]. 288 Order and preference, being 16-bit unsigned integers, shall be an 289 integer between 0 and 65535. The Flags and Services and Regexp 290 fields are all quoted s. Since the Regexp field 291 can contain numerous backslashes and thus should be treated with 292 care. See Section 10 for how to correctly enter and escape the 293 regular expression. 295 5. Application Specifications 297 This DDDS Database is usable by any application that makes use of the 298 DDDS algorithm. In addition to the items required to specify a DDDS 299 Application, an application wishing to use this Database must also 300 define the following values: 302 o What domain the Key that is produced by the First Well Known Rule 303 belongs to. Any application must ensure that its rules do not 304 collide with rules used by another application making use of this 305 Database. For example, the 'foo' application might have all of 306 its First Well Known Keys be found in the 'foo.net' zone. 308 o What the allowed values for the Services and Protocols fields are. 310 o What the expected output is of the terminal rewrite rule 312 6. Examples 314 6.1 URN Example 316 The NAPTR record was originally created for use with the Uniform 317 Resource Name Resolver Discovery System. This example details how a 318 particular URN would use the NAPTR record to find a resolver service 319 that can answer questions about the URN. See [12] for the definitive 320 specification for this Application. 322 Consider a URN namespace based on MIME Content-Ids (this is very 323 hypothetical so do not rely on this). The URN might look like this: 325 urn:cid:199606121851.1@bar.example.com 327 This Application's First Well Known Rule is to extract the characters 328 between the first and second colon. For this URN that would be 329 'cid'. The Application also specifies that, in order to build a 330 Database-valid Key, the string 'urn.arpa' should be appended to the 331 result of the First Well Known Rule. The result is 'cid.urn.arpa'. 333 Next, the client queries the DNS for NAPTR records for the domain- 334 name 'cid.urn.arpa'. The result is a single record: 336 cid.urn.arpa. 337 ;; order pref flags service regexp replacement 338 IN NAPTR 100 10 "" "" "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . 340 Since there is only one record, ordering the responses is not a 341 problem. The replacement field is empty, so the pattern provided in 342 the regexp field is used . We apply that regexp to the entire URN to 343 see if it matches, which it does. The \2 part of the substitution 344 expression returns the string "example.com". Since the flags field 345 is empty, the lookup is not terminal and our next probe to DNS is for 346 more NAPTR records where the new domain is 'example.com'. 348 Note that the rule does not extract the full domain name from the 349 CID, instead it assumes the CID comes from a host and extracts its 350 domain. While all hosts, such as 'bar', could have their very own 351 NAPTR, maintaining those records for all the machines at a site could 352 be an intolerable burden. Wildcards are not appropriate here since 353 they only return results when there is no exactly matching names 354 already in the system. 356 The record returned from the query on "example.com" might look like: 358 example.com. 359 ;; order pref flags service regexp replacement 360 IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. 361 IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. 362 IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com. 364 Continuing with the example, note that the values of the order and 365 preference fields are equal in all records, so the client is free to 366 pick any record. The Application defines the flag 'a' to mean a 367 terminal lookup and that the output of the rewrite will be a domain- 368 name for which an A record should be queried. Once the client has 369 done that, it has the following information: the host, its IP 370 address, the protocol, and the services available via that protocol. 371 Given these bits of information the client has enough to be able to 372 contact that server and ask it questions about the URN. 374 Recall that the regular expression used \2 to extract a domain name 375 from the CID, and \. for matching the literal '.' characters 376 separating the domain name components. Since '\' is the escape 377 character, literal occurances of a backslash must be escaped by 378 another backslash. For the case of the cid.urn.arpa record above, 379 the regular expression entered into the master file should be 380 "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually 381 receives the record, the pattern will have been converted to 382 "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i". 384 6.2 E164 Example 386 The ENUM Working Group in the IETF has specified a service that 387 allows a telephone number to be mapped to a URI. The Application 388 Unique String for the ENUM Application is the E.164 telephone number 389 with the dashes removed. The First Well Known Rule is to remove all 390 characters from the the telephone number and then use the entire 391 number as the first Key. For example, the phone number "770-555- 392 1212" represented as an E.164 number would be "+1-770-555-1212". 393 Converted to the Key it would be "17705551212". 395 The ENUM Application at present only uses this Database. It 396 specifies that, in order to convert the first Key into a form valid 397 for this Database, periods are inserted between each digit, the 398 entire Key is inverted and then "e164.arpa" is appended to the end. 399 The above telephone number would then read 400 "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to 401 retrieve Rewrite Rules as NAPTR records. 403 For this example telephone number we might get back the following 404 NAPTR records: 406 $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. 407 IN NAPTR 100 10 "u" "sip+N2R" "!^.*$!sip:information@foo.se!" . 408 IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@foo.se!" . 410 ENUM uses the same 'u' flag as the URI Resolution Application. This 411 flag states that the Rule is terminal and that the output is a URL 412 which contains the information needed to contact that telephone 413 service. ENUM also uses the same format for its Service Parameters. 414 These state that the available protocols used to access that 415 telephone's service are either the Session Initiation Protocol or 416 SMTP mail. 418 7. Advice for DNS Administrators 420 Beware of regular expressions. Not only are they difficult to get 421 correct on their own, but there is the previously mentioned 422 interaction with DNS. Any backslashes in a regexp must be entered 423 twice in a zone file in order to appear once in a query response. 424 More seriously, the need for double backslashes has probably not been 425 tested by all implementors of DNS servers. 427 In order to mitigate zone file problems, administrators should 428 encourage those writing rewrite rules to utilize the 'default 429 delimiter' feature of the regular expression. In the DDDS 430 specification the regular expression starts with the character that 431 is to be the delimiter. Hence if the first character of the regular 432 expression is an exclamation mark ('!') for example then the regular 433 expression can usually be written without any backslashes. 435 8. Notes 437 A client MUST process multiple NAPTR records in the order 438 specified by the "order" field, it MUST NOT simply use the first 439 record that provides a known Service Parameter combination. 441 When multiple RRs have the same "order" and all other criteria 442 being equal, the client should use the value of the preference 443 field to select the next NAPTR to consider. However, because it 444 will often be the case where preferred protocols or services 445 exist, clients may use this additional criteria to sort the 446 records. 448 If the lookup after a rewrite fails, clients are strongly 449 encouraged to report a failure, rather than backing up to pursue 450 other rewrite paths. 452 9. IANA Considerations 454 The values for the Services and Flags fields will be determined by 455 the Application that makes use of this DDDS Database. Those values 456 may require a registration mechanism and thus may need some IANA 457 resources. This specification by itself does not. 459 10. Security Considerations 461 The NAPTR record, like any other DNS record, can be signed and 462 validated according to the procedures specified in DNSSEC. 464 This Database makes identifiers from other namespaces subject to the 465 same attacks as normal domain names. Since they have not been easily 466 resolvable before, this may or may not be considered a problem. 468 Regular expressions should be checked for sanity, not blindly passed 469 to something like PERL since arbitrary code can be included and 470 subsequently processed. 472 References 474 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 475 Levels", RFC 2119, BCP 14, March 1997. 477 [2] Mockapetris, P., "Domain names - implementation and 478 specification", RFC 1035, STD 13, Nov 1987. 480 [3] Mockapetris, P., "Domain names - concepts and facilities", RFC 481 1034, STD 13, Nov 1987. 483 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 484 specifying the location of services (DNS SRV)", RFC 2782, 485 February 2000. 487 [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 488 RFC 2234, November 1997. 490 [6] Daniel, R., "A Trivial Convention for using HTTP in URN 491 Resolution", RFC 2169, June 1997. 493 [7] IEEE, "IEEE Standard for Information Technology - Portable 494 Operating System Interface (POSIX) - Part 2: Shell and 495 Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. 497 [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 498 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 499 1998. 501 [9] Moats, R., "URN Syntax", RFC 2141, May 1997. 503 [10] Sollins, K., "Architectural Principles of Uniform Resource Name 504 Resolution", RFC 2276, January 1998. 506 [11] Mealling, M., "Dynamic Delegation Discovery System (DDDS)", RFC 507 ZZZZ, draft-ietf-urn-ddds-00.txt (work in progress), May 2000. 509 [12] Mealling, M., "URI Resolution using the Dynamic Delegation 510 Discovery System", RFC XXXX, draft-ietf-urn-uri-res-ddds-00.txt 511 (work in progress), July 2000. 513 [13] Mealling, M. and R. Daniel, "The Naming Authority Pointer 514 (NAPTR) DNS Resource Record", RFC 2915, August 2000. 516 [14] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 517 Identifiers using the Domain Name System", RFC 2168, June 1997. 519 [15] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 520 2279, January 1998. 522 Author's Address 524 Michael Mealling 525 VeriSign 526 505 Huntmar Park Drive 527 Herndon, VA 22070 528 US 530 Phone: +1 770 921-2251 531 EMail: michael@research.netsol.com 532 URI: http://www.verisign.com 534 Full Copyright Statement 536 Copyright (C) The Internet Society (2001). All Rights Reserved. 538 This document and translations of it may be copied and furnished to 539 others, and derivative works that comment on or otherwise explain it 540 or assist in its implementation may be prepared, copied, published 541 and distributed, in whole or in part, without restriction of any 542 kind, provided that the above copyright notice and this paragraph are 543 included on all such copies and derivative works. However, this 544 document itself may not be modified in any way, such as by removing 545 the copyright notice or references to the Internet Society or other 546 Internet organizations, except as needed for the purpose of 547 developing Internet standards in which case the procedures for 548 copyrights defined in the Internet Standards process must be 549 followed, or as required to translate it into languages other than 550 English. 552 The limited permissions granted above are perpetual and will not be 553 revoked by the Internet Society or its successors or assigns. 555 This document and the information contained herein is provided on an 556 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 557 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 558 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 559 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 560 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Acknowledgement 564 Funding for the RFC Editor function is currently provided by the 565 Internet Society.