idnits 2.17.1 draft-ietf-urn-dns-ddds-database-08.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 6 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 389 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 (February 19, 2002) is 8094 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) == Unused Reference: '5' is defined on line 520, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 533, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 547, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 551, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 553, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-urn-ddds-toc-02 ** Downref: Normative reference to an Informational draft: draft-ietf-urn-ddds-toc (ref. '1') == Outdated reference: A later version (-07) exists of draft-ietf-urn-ddds-06 == Outdated reference: A later version (-09) exists of draft-ietf-urn-dns-ddds-database-07 == Outdated reference: A later version (-07) exists of draft-ietf-urn-uri-res-ddds-06 == Outdated reference: A later version (-11) exists of draft-ietf-urn-net-procedures-10 ** Obsolete normative reference: RFC 2234 (ref. '10') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2396 (ref. '13') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2141 (ref. '14') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '15') ** Obsolete normative reference: RFC 2168 (ref. '16') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2279 (ref. '17') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2916 (ref. '18') (Obsoleted by RFC 3761) Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 4 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: August 20, 2002 February 19, 2002 6 Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 7 Database 8 draft-ietf-urn-dns-ddds-database-08.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 20, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This document describes a Dynamic Delegation Discovery System 40 Database using the Domain Name System as a distributed database of 41 Rules. The Keys are domain-names and the Rules are encoded using the 42 NAPTR Resource Record. 44 Since this document obsoletes RFC 2915, it is the official 45 specification for the NAPTR DNS Resource Record. It is also part of 46 a series that is completely specified in "Dynamic Delegation 47 Discovery System (DDDS) Part One: The Comprehensive DDDS Standard" 48 (RFC WWWW). It is very important to note that it is impossible to 49 read and understand any document in this series without reading the 50 others. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. DDDS Database Specification . . . . . . . . . . . . . . . . 5 57 4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.2 Additional Information Processing . . . . . . . . . . . . . 9 60 4.2.1 Additional Section processing by DNS servers . . . . . . . . 9 61 4.2.2 Additional Section processing by resolver/applications . . . 9 62 4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 9 63 5. Application Specifications . . . . . . . . . . . . . . . . . 10 64 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 11 66 6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 12 67 7. Advice for DNS Administrators . . . . . . . . . . . . . . . 14 68 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 70 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 71 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 75 1. Introduction 77 The Dynamic Delegation Discovery System is used to implement lazy 78 binding of strings to data, in order to support dynamically 79 configured delegation systems. The DDDS functions by mapping some 80 unique string to data stored within a DDDS Database by iteratively 81 applying string transformation rules until a terminal condition is 82 reached. 84 This document describes the way in which the Domain Name System is 85 used as a data store for the Rules that allow a DDDS Application to 86 function. It does not specify any particular application or usage 87 scenario. The entire series of documents is specified in "Dynamic 88 Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS 89 Standard" (RFC WWWW) [1]. It is very important to note that it is 90 impossible to read and understand any document in that series without 91 reading the related documents. 93 The NAPTR DNS Resource Record specified here was originally produced 94 by the URN Working Group as a way to encode rule-sets in DNS so that 95 the delegated sections of a URI could be decomposed in such a way 96 that they could be changed and re-delegated over time. The result 97 was a Resource Record that included a regular expression that would 98 be used by a client program to rewrite a string into a domain name. 99 Regular expressions were chosen for their compactness to expressivity 100 ratio allowing for a great deal of information to be encoded in a 101 rather small DNS packet. 103 Over time this process was generalized for other Applications and 104 Rule Databases. This document defines a Rules Database absent any 105 particular Application as there may be several Applications all 106 taking advantage of this particular Rules Database. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [6]. 114 All other terminology, especially capitalized terms, is taken from 115 [3]. 117 3. DDDS Database Specification 119 General Description: 120 This database uses the Domain Name System (DNS) as specified in 121 [8] and [7]. 123 The character set used to specify the various values of the NAPTR 124 records is UTF-8 [17]. Care must be taken to ensure that, in the 125 case where either the input or the output to the substitution 126 expression contains code points outside of the ASCII/Unicode 127 equivalence in UTF-8, any UTF-8 is interpreted as a series of 128 code-points instead of as a series of bytes. This is to ensure 129 that the internationalized features of the POSIX Extended Regular 130 Expressions are able to match their intended code-points. 131 Substitution expressions MUST NOT be written where they depend on 132 a specific POSIX locale since this would cause substutition 133 expressions to loose their ability to be universally applicable. 135 Key Format: 136 A Key is a validly constructed DNS domain-name. 138 Lookup Request: 139 In order to request a set of rules for a given Key, the client 140 issues a request, following standard DNS rules, for NAPTR Resource 141 Records for the given domain-name. 143 Lookup Response: 144 The response to a request for a given Key (domain-name) will be a 145 series of NAPTR records. The format of a NAPTR Resource Record 146 can be found in Section 4. 148 Rule Insertion Procedure: 149 Rules are inserted by adding new records to the appropriate DNS 150 zone. If a Rule produces a Key that exists in a particular zone 151 then only the entity that has administrative control of that zone 152 can specify the Rule associated with that Key. 154 Collision Avoidance: 155 In the case where two Applications may use this Database (which is 156 actually the case with the ENUM and URI Resolution Applications, 157 Section 6.2), there is a chance of collision between rules where 158 two NAPTR records appear in the same domain but they apply to more 159 than one Appliation. There are three ways to avoid collisions: 161 * create a new zone within the domain in common that contains 162 only NAPTR records that are appropriate for the application. 163 E.g., all URI Resolution records would exist under 164 urires.example.com and all ENUM records would be under 165 enum.example.com. In the case where this is not possible due 166 to lack of control over the upstream delegation the second 167 method is used. 169 * write the regular expression such that it contains enough of 170 the Application Unique string to disambiguate it from any 171 other. For example, the URI Resolution Application would be 172 able to use the scheme name on the left hand side to anchor the 173 regular expression match to that scheme. An ENUM specific 174 record in that same zone would be able to anchor the left hand 175 side of the match with the "+" character which is defined by 176 ENUM to be at the beginning of every Application Unique String. 177 This way a given Appliation Unique String can only match one or 178 the other record, not both. 180 * if two Application use different Flags or Services values then 181 a record from another Application will be ignored since it 182 doesn't apply to the Services/Flags in question. 184 4. NAPTR RR Format 186 4.1 Packet Format 188 The packet format of the NAPTR RR is given below. The DNS type code 189 for NAPTR is 35. 191 The packet format for the NAPTR record is as follows 192 1 1 1 1 1 1 193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 194 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 195 | ORDER | 196 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 197 | PREFERENCE | 198 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 199 / FLAGS / 200 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 201 / SERVICES / 202 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 203 / REGEXP / 204 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 205 / REPLACEMENT / 206 / / 207 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 209 and as used here are defined in 210 RFC1035 [7]. 212 ORDER 213 A 16-bit unsigned integer specifying the order in which the NAPTR 214 records MUST be processed in order to accurately represent the 215 ordered list of Rules. The ordering is from lowest to highest. 216 If two records have the same order value then they are considered 217 to be the same rule and should be selected based on the 218 combination of the Preference values and Services offered. 220 PREFERENCE 221 Although it is called "preference" in deference to DNS 222 terminology, this field is equivalent to the Priority value in the 223 DDDS Algorithm. It is a 16-bit unsigned integer that specifies 224 the order in which NAPTR records with equal Order values SHOULD be 225 processed, low numbers being processed before high numbers. This 226 is similar to the preference field in an MX record, and is used so 227 domain administrators can direct clients towards more capable 228 hosts or lighter weight protocols. A client MAY look at records 229 with higher preference values if it has a good reason to do so 230 such as not supporting some protocol or service very well. 232 The important difference between Order and Preference is that once 233 a match is found the client MUST NOT consider records with a 234 different Order but they MAY process records with the same Order 235 but different Preferences. The only exception to this is noted in 236 the second important Note in the DDDS algorithm specification 237 concerning allowing clients to use more complex Service 238 determination between steps 3 and 4 in the algorithm. Preference 239 is used to give communicate a higher quality of service to rules 240 that are considered the same from an authority standpoint but not 241 from a simple load balancing standpoint. 243 It is important to note that DNS contains several load balancing 244 mechanisms and if load balancing among otherwise equal services 245 should be needed then methods such as SRV records or multiple A 246 records should be utilized to accomplish load balancing. 248 FLAGS 249 A containing flags to control aspects of the 250 rewriting and interpretation of the fields in the record. Flags 251 are single characters from the set A-Z and 0-9. The case of the 252 alphabetic characters is not significant. The field can be empty. 254 It is up to the Application specifying how it is using this 255 Database to define the Flags in this field. It must define which 256 ones are terminal and which ones are not. 258 SERVICES 259 A that specifies the Service Parameters 260 applicable to this this delegation path. It is up to the 261 Application Specification to specify the values found in this 262 field. 264 REGEXP 265 A containing a substitution expression that is 266 applied to the original string held by the client in order to 267 construct the next domain name to lookup. See the DDDS Algorithm 268 specification for the syntax of this field. 270 As stated in the DDDS algorithm, The regular expressions MUST NOT 271 be used in a cumulative fashion, that is, they should only be 272 applied to the original string held by the client, never to the 273 domain name produced by a previous NAPTR rewrite. The latter is 274 tempting in some applications but experience has shown such use to 275 be extremely fault sensitive, very error prone, and extremely 276 difficult to debug. 278 REPLACEMENT 279 A which is the next domain-name to query for 280 depending on the potential values found in the flags field. This 281 field is used when the regular expression is a simple replacement 282 operation. Any value in this field MUST be a fully qualified 283 domain-name. Name compression is not to be used for this field. 285 This field and the REGEXP field together make up the Substitution 286 Expression in the DDDS Algorithm. It is simply a historical 287 optimization specifically for DNS compression that this field 288 exists. The fields are also mutually exclusive. If a record is 289 returned that has values for both fields then it is considered to 290 be in error and SHOULD be either ignored or an error returned. 292 4.2 Additional Information Processing 294 Additional section processing requires upgraded DNS servers, thus it 295 will take many years before applications can expect to see relevant 296 records in the additional information section. 298 4.2.1 Additional Section processing by DNS servers 300 DNS servers MAY add RRsets to the additional information section that 301 are relevant to the answer and have the same authenticity as the data 302 in the answer section. Generally this will be made up of A and SRV 303 records but the exact records depends on the application. 305 4.2.2 Additional Section processing by resolver/applications 307 Applications MAY inspect the Additional Information section for 308 relevant records but Applications MUST NOT require that records of 309 any type be in the Additional Information section of any DNS response 310 in order for clients to function. All Applications must be capable 311 of handling responses from nameservers that never fill in the 312 Additional Information part of a response. 314 4.3 Master File Format 316 The master file format follows the standard rules in RFC-1035. Order 317 and preference, being 16-bit unsigned integers, shall be an integer 318 between 0 and 65535. The Flags and Services and Regexp fields are 319 all quoted s. Since the Regexp field can contain 320 numerous backslashes and thus should be treated with care. See 321 Section 7 for how to correctly enter and escape the regular 322 expression. 324 5. Application Specifications 326 This DDDS Database is usable by any application that makes use of the 327 DDDS algorithm. In addition to the items required to specify a DDDS 328 Application, an application wishing to use this Database must also 329 define the following values: 331 o What domain the Key that is produced by the First Well Known Rule 332 belongs to. Any application must ensure that its rules do not 333 collide with rules used by another application making use of this 334 Database. For example, the 'foo' application might have all of 335 its First Well Known Keys be found in the 'foo.net' zone. 337 o What the allowed values for the Services and Protocols fields are. 339 o What the expected output is of the terminal rewrite rule in 340 addition to how the Flags are actually encoded and utilized. 342 6. Examples 344 6.1 URN Example 346 The NAPTR record was originally created for use with the Uniform 347 Resource Name Resolver Discovery System. This example details how a 348 particular URN would use the NAPTR record to find a resolver service 349 that can answer questions about the URN. See [2] for the definitive 350 specification for this Application. 352 Consider a URN namespace based on MIME Content-Ids (this is very 353 hypothetical so do not rely on this). The URN might look like this: 355 urn:cid:199606121851.1@bar.example.com 357 This Application's First Well Known Rule is to extract the characters 358 between the first and second colon. For this URN that would be 359 'cid'. The Application also specifies that, in order to build a 360 Database-valid Key, the string 'urn.arpa' should be appended to the 361 result of the First Well Known Rule. The result is 'cid.urn.arpa'. 363 Next, the client queries the DNS for NAPTR records for the domain- 364 name 'cid.urn.arpa'. The result is a single record: 366 cid.urn.arpa. 367 ;; order pref flags service regexp replacement 368 IN NAPTR 100 10 "" "" "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . 370 Since there is only one record, ordering the responses is not a 371 problem. The replacement field is empty, so the pattern provided in 372 the regexp field is used. We apply that regexp to the entire URN to 373 see if it matches, which it does. The \2 part of the substitution 374 expression returns the string "example.com". Since the flags field 375 is empty, the lookup is not terminal and our next probe to DNS is for 376 more NAPTR records where the new domain is 'example.com'. 378 Note that the rule does not extract the full domain name from the 379 CID, instead it assumes the CID comes from a host and extracts its 380 domain. While all hosts, such as 'bar', could have their very own 381 NAPTR, maintaining those records for all the machines at a site could 382 be an intolerable burden. Wildcards are not appropriate here since 383 they only return results when there is no exactly matching names 384 already in the system. 386 The record returned from the query on "example.com" might look like: 388 example.com. 389 ;; order pref flags service regexp replacement 390 IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. 391 IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. 392 IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com. 394 Continuing with the example, note that the values of the order and 395 preference fields are equal in all records, so the client is free to 396 pick any record. The Application defines the flag 'a' to mean a 397 terminal lookup and that the output of the rewrite will be a domain- 398 name for which an A record should be queried. Once the client has 399 done that, it has the following information: the host, its IP 400 address, the protocol, and the services available via that protocol. 401 Given these bits of information the client has enough to be able to 402 contact that server and ask it questions about the URN. 404 Recall that the regular expression used \2 to extract a domain name 405 from the CID, and \. for matching the literal '.' characters 406 separating the domain name components. Since '\' is the escape 407 character, literal occurances of a backslash must be escaped by 408 another backslash. For the case of the cid.urn.arpa record above, 409 the regular expression entered into the master file should be 410 "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually 411 receives the record, the pattern will have been converted to 412 "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i". 414 6.2 E164 Example 416 The ENUM Working Group in the IETF has specified a service that 417 allows a telephone number to be mapped to a URI [18]. The 418 Application Unique String for the ENUM Application is the E.164 419 telephone number with the dashes removed. The First Well Known Rule 420 is to remove all characters from the the telephone number and then 421 use the entire number as the first Key. For example, the phone 422 number "770-555-1212" represented as an E.164 number would be "+1- 423 770-555-1212". Converted to the Key it would be "17705551212". 425 The ENUM Application at present only uses this Database. It 426 specifies that, in order to convert the first Key into a form valid 427 for this Database, periods are inserted between each digit, the 428 entire Key is inverted and then "e164.arpa" is appended to the end. 429 The above telephone number would then read 430 "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to 431 retrieve Rewrite Rules as NAPTR records. 433 For this example telephone number we might get back the following 434 NAPTR records: 436 $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. 437 IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" . 438 IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" . 440 Both the ENUM [18] and URI Resolution [4] Applications use the 'u' 441 flag. This flag states that the Rule is terminal and that the output 442 is a URI which contains the information needed to contact that 443 telephone service. ENUM also uses the same format for its Service 444 Parameters. These state that the available protocols used to access 445 that telephone's service are either the Session Initiation Protocol 446 or SMTP mail. 448 7. Advice for DNS Administrators 450 Beware of regular expressions. Not only are they difficult to get 451 correct on their own, but there is the previously mentioned 452 interaction with DNS. Any backslashes in a regexp must be entered 453 twice in a zone file in order to appear once in a query response. 454 More seriously, the need for double backslashes has probably not been 455 tested by all implementors of DNS servers. 457 In order to mitigate zone file problems, administrators should 458 encourage those writing rewrite rules to utilize the 'default 459 delimiter' feature of the regular expression. In the DDDS 460 specification the regular expression starts with the character that 461 is to be the delimiter. Hence if the first character of the regular 462 expression is an exclamation mark ('!') for example then the regular 463 expression can usually be written with fewer backslashes. 465 8. Notes 467 A client MUST process multiple NAPTR records in the order 468 specified by the "order" field, it MUST NOT simply use the first 469 record that provides a known Service Parameter combination. 471 When multiple RRs have the same "order" and all other criteria 472 being equal, the client should use the value of the preference 473 field to select the next NAPTR to consider. However, because it 474 will often be the case where preferred protocols or services 475 exist, clients may use this additional criteria to sort the 476 records. 478 If the lookup after a rewrite fails, clients are strongly 479 encouraged to report a failure, rather than backing up to pursue 480 other rewrite paths. 482 9. IANA Considerations 484 The values for the Services and Flags fields will be determined by 485 the Application that makes use of this DDDS Database. Those values 486 may require a registration mechanism and thus may need some IANA 487 resources. This specification by itself does not. 489 10. Security Considerations 491 The NAPTR record, like any other DNS record, can be signed and 492 validated according to the procedures specified in DNSSEC. 494 This Database makes identifiers from other namespaces subject to the 495 same attacks as normal domain names. Since they have not been easily 496 resolvable before, this may or may not be considered a problem. 498 Regular expressions should be checked for sanity, not blindly passed 499 to something like PERL since arbitrary code can be included and 500 subsequently processed. 502 References 504 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 505 One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- 506 urn-ddds-toc-02.txt (work in progress), February 2002. 508 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 509 Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work 510 in progress), February 2002. 512 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 513 Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- 514 database-07.txt (work in progress), February 2002. 516 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 517 Four: The URI Resolution Application", RFC YYYY, draft-ietf- 518 urn-uri-res-ddds-06.txt (work in progress), February 2002. 520 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 521 Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- 522 urn-net-procedures-10.txt (work in progress), February 2002. 524 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 525 Levels", RFC 2119, BCP 14, March 1997. 527 [7] Mockapetris, P., "Domain names - implementation and 528 specification", RFC 1035, STD 13, Nov 1987. 530 [8] Mockapetris, P., "Domain names - concepts and facilities", RFC 531 1034, STD 13, Nov 1987. 533 [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 534 specifying the location of services (DNS SRV)", RFC 2782, 535 February 2000. 537 [10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 538 RFC 2234, November 1997. 540 [11] Daniel, R., "A Trivial Convention for using HTTP in URN 541 Resolution", RFC 2169, June 1997. 543 [12] IEEE, "IEEE Standard for Information Technology - Portable 544 Operating System Interface (POSIX) - Part 2: Shell and 545 Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. 547 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 548 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 549 1998. 551 [14] Moats, R., "URN Syntax", RFC 2141, May 1997. 553 [15] Sollins, K., "Architectural Principles of Uniform Resource Name 554 Resolution", RFC 2276, January 1998. 556 [16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 557 Identifiers using the Domain Name System", RFC 2168, June 1997. 559 [17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 560 2279, January 1998. 562 [18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 563 2000. 565 Author's Address 567 Michael Mealling 568 VeriSign 569 21345 Ridgetop Circle 570 Sterling, VA 20166 571 US 573 EMail: michael@neonym.net 574 URI: http://www.verisignlabs.com 576 Full Copyright Statement 578 Copyright (C) The Internet Society (2002). All Rights Reserved. 580 This document and translations of it may be copied and furnished to 581 others, and derivative works that comment on or otherwise explain it 582 or assist in its implementation may be prepared, copied, published 583 and distributed, in whole or in part, without restriction of any 584 kind, provided that the above copyright notice and this paragraph are 585 included on all such copies and derivative works. However, this 586 document itself may not be modified in any way, such as by removing 587 the copyright notice or references to the Internet Society or other 588 Internet organizations, except as needed for the purpose of 589 developing Internet standards in which case the procedures for 590 copyrights defined in the Internet Standards process must be 591 followed, or as required to translate it into languages other than 592 English. 594 The limited permissions granted above are perpetual and will not be 595 revoked by the Internet Society or its successors or assigns. 597 This document and the information contained herein is provided on an 598 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 599 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 600 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 601 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 602 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 604 Acknowledgement 606 Funding for the RFC Editor function is currently provided by the 607 Internet Society.