idnits 2.17.1 draft-ietf-urn-dns-ddds-database-07.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 378 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 (October 28, 2001) is 8214 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: '4' is defined on line 505, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 509, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 526, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 529, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 532, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 536, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 542, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 545, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-urn-ddds-toc-00 ** 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-05 == 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-05 == Outdated reference: A later version (-11) exists of draft-ietf-urn-net-procedures-09 ** 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) Summary: 11 errors (**), 0 flaws (~~), 18 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: April 28, 2002 October 28, 2001 6 Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 7 Database 8 draft-ietf-urn-dns-ddds-database-07.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 April 28, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). 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 there is a chance of collision between rules where two NAPTR 158 records appear in the same domain but they apply to more than one 159 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 randomly unless the 218 Preference numbers are different which means the randomization is 219 weighted according to the ratio of the Preference values. 221 PREFERENCE 222 Although it is called "preference" in deference to DNS 223 terminology, this field is equivalent to the Priority value in the 224 DDDS Algorithm. It is a 16-bit unsigned integer that specifies 225 the order in which NAPTR records with equal Order values SHOULD be 226 processed, low numbers being processed before high numbers. This 227 is similar to the preference field in an MX record, and is used so 228 domain administrators can direct clients towards more capable 229 hosts or lighter weight protocols. A client MAY look at records 230 with higher preference values if it has a good reason to do so 231 such as not understanding some protocol or service. 233 The important difference between Order and Preference is that once 234 a match is found the client MUST NOT consider records with a 235 different Order but they MAY process records with the same Order 236 but different Preferences. I.e. Preference is used to give 237 weight to rules that are considered the same from an authority 238 standpoint but not from a simple load balancing standpoint. 240 FLAGS 241 A containing flags to control aspects of the 242 rewriting and interpretation of the fields in the record. Flags 243 are single characters from the set A-Z and 0-9. The case of the 244 alphabetic characters is not significant. The field can be empty. 246 It is up to the Application specifying how it is using this 247 Database to define the Flags in this field. It must define which 248 ones are terminal and which ones are not. 250 SERVICES 251 A that specifies the Service Parameters 252 applicable to this this delegation path. It is up to the 253 Application Specification to specify the values found in this 254 field. 256 REGEXP 257 A containing a substitution expression that is 258 applied to the original string held by the client in order to 259 construct the next domain name to lookup. See the DDDS Algorithm 260 specification for the syntax of this field. 262 As stated in the DDDS algorithm, The regular expressions MUST NOT 263 be used in a cumulative fashion, that is, they should only be 264 applied to the original string held by the client, never to the 265 domain name produced by a previous NAPTR rewrite. The latter is 266 tempting in some applications but experience has shown such use to 267 be extremely fault sensitive, very error prone, and extremely 268 difficult to debug. 270 REPLACEMENT 271 A which is the next domain-name to query for 272 depending on the potential values found in the flags field. This 273 field is used when the regular expression is a simple replacement 274 operation. Any value in this field MUST be a fully qualified 275 domain-name. Name compression is not to be used for this field. 276 This field and the REGEXP field together make up the Substitution 277 Expression in the DDDS Algorithm. They are also mutually 278 exclusive. If a record is returned that has values for both 279 fields then it is considered to be in error and should be ignored. 281 4.2 Additional Information Processing 283 Additional section processing requires upgraded DNS servers, thus it 284 will take many years before applications can expect to see relevant 285 records in the additional information section. 287 4.2.1 Additional Section processing by DNS servers 289 DNS servers MAY add RRsets to the additional information section that 290 are relevant to the answer and have the same authenticity as the data 291 in the answer section. Generally this will be made up of A and SRV 292 records but the exact records depends on the application. 294 4.2.2 Additional Section processing by resolver/applications 296 Applications MAY inspect the Additional Information section for 297 relevant records but Applications MUST NOT require that records of 298 any type be in the Additional Information section of any DNS response 299 in order for clients to function. All Applications must be capable 300 of handling responses from nameservers that never fill in the 301 Additional Information part of a response. 303 4.3 Master File Format 305 The master file format follows the standard rules in RFC-1035. Order 306 and preference, being 16-bit unsigned integers, shall be an integer 307 between 0 and 65535. The Flags and Services and Regexp fields are 308 all quoted s. Since the Regexp field can contain 309 numerous backslashes and thus should be treated with care. See 310 Section 10 for how to correctly enter and escape the regular 311 expression. 313 5. Application Specifications 315 This DDDS Database is usable by any application that makes use of the 316 DDDS algorithm. In addition to the items required to specify a DDDS 317 Application, an application wishing to use this Database must also 318 define the following values: 320 o What domain the Key that is produced by the First Well Known Rule 321 belongs to. Any application must ensure that its rules do not 322 collide with rules used by another application making use of this 323 Database. For example, the 'foo' application might have all of 324 its First Well Known Keys be found in the 'foo.net' zone. 326 o What the allowed values for the Services and Protocols fields are. 328 o What the expected output is of the terminal rewrite rule in 329 addition to how the Flags are actually encoded and utilized. 331 6. Examples 333 6.1 URN Example 335 The NAPTR record was originally created for use with the Uniform 336 Resource Name Resolver Discovery System. This example details how a 337 particular URN would use the NAPTR record to find a resolver service 338 that can answer questions about the URN. See [2] for the definitive 339 specification for this Application. 341 Consider a URN namespace based on MIME Content-Ids (this is very 342 hypothetical so do not rely on this). The URN might look like this: 344 urn:cid:199606121851.1@bar.example.com 346 This Application's First Well Known Rule is to extract the characters 347 between the first and second colon. For this URN that would be 348 'cid'. The Application also specifies that, in order to build a 349 Database-valid Key, the string 'urn.arpa' should be appended to the 350 result of the First Well Known Rule. The result is 'cid.urn.arpa'. 352 Next, the client queries the DNS for NAPTR records for the domain- 353 name 'cid.urn.arpa'. The result is a single record: 355 cid.urn.arpa. 356 ;; order pref flags service regexp replacement 357 IN NAPTR 100 10 "" "" "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . 359 Since there is only one record, ordering the responses is not a 360 problem. The replacement field is empty, so the pattern provided in 361 the regexp field is used. We apply that regexp to the entire URN to 362 see if it matches, which it does. The \2 part of the substitution 363 expression returns the string "example.com". Since the flags field 364 is empty, the lookup is not terminal and our next probe to DNS is for 365 more NAPTR records where the new domain is 'example.com'. 367 Note that the rule does not extract the full domain name from the 368 CID, instead it assumes the CID comes from a host and extracts its 369 domain. While all hosts, such as 'bar', could have their very own 370 NAPTR, maintaining those records for all the machines at a site could 371 be an intolerable burden. Wildcards are not appropriate here since 372 they only return results when there is no exactly matching names 373 already in the system. 375 The record returned from the query on "example.com" might look like: 377 example.com. 378 ;; order pref flags service regexp replacement 379 IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. 380 IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. 381 IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com. 383 Continuing with the example, note that the values of the order and 384 preference fields are equal in all records, so the client is free to 385 pick any record. The Application defines the flag 'a' to mean a 386 terminal lookup and that the output of the rewrite will be a domain- 387 name for which an A record should be queried. Once the client has 388 done that, it has the following information: the host, its IP 389 address, the protocol, and the services available via that protocol. 390 Given these bits of information the client has enough to be able to 391 contact that server and ask it questions about the URN. 393 Recall that the regular expression used \2 to extract a domain name 394 from the CID, and \. for matching the literal '.' characters 395 separating the domain name components. Since '\' is the escape 396 character, literal occurances of a backslash must be escaped by 397 another backslash. For the case of the cid.urn.arpa record above, 398 the regular expression entered into the master file should be 399 "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually 400 receives the record, the pattern will have been converted to 401 "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i". 403 6.2 E164 Example 405 The ENUM Working Group in the IETF has specified a service that 406 allows a telephone number to be mapped to a URI. The Application 407 Unique String for the ENUM Application is the E.164 telephone number 408 with the dashes removed. The First Well Known Rule is to remove all 409 characters from the the telephone number and then use the entire 410 number as the first Key. For example, the phone number "770-555- 411 1212" represented as an E.164 number would be "+1-770-555-1212". 412 Converted to the Key it would be "17705551212". 414 The ENUM Application at present only uses this Database. It 415 specifies that, in order to convert the first Key into a form valid 416 for this Database, periods are inserted between each digit, the 417 entire Key is inverted and then "e164.arpa" is appended to the end. 418 The above telephone number would then read 419 "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to 420 retrieve Rewrite Rules as NAPTR records. 422 For this example telephone number we might get back the following 423 NAPTR records: 425 $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. 426 IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" . 427 IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" . 429 ENUM uses the same 'u' flag as the URI Resolution Application. This 430 flag states that the Rule is terminal and that the output is a URL 431 which contains the information needed to contact that telephone 432 service. ENUM also uses the same format for its Service Parameters. 433 These state that the available protocols used to access that 434 telephone's service are either the Session Initiation Protocol or 435 SMTP mail. 437 7. Advice for DNS Administrators 439 Beware of regular expressions. Not only are they difficult to get 440 correct on their own, but there is the previously mentioned 441 interaction with DNS. Any backslashes in a regexp must be entered 442 twice in a zone file in order to appear once in a query response. 443 More seriously, the need for double backslashes has probably not been 444 tested by all implementors of DNS servers. 446 In order to mitigate zone file problems, administrators should 447 encourage those writing rewrite rules to utilize the 'default 448 delimiter' feature of the regular expression. In the DDDS 449 specification the regular expression starts with the character that 450 is to be the delimiter. Hence if the first character of the regular 451 expression is an exclamation mark ('!') for example then the regular 452 expression can usually be written without any backslashes. 454 8. Notes 456 A client MUST process multiple NAPTR records in the order 457 specified by the "order" field, it MUST NOT simply use the first 458 record that provides a known Service Parameter combination. 460 When multiple RRs have the same "order" and all other criteria 461 being equal, the client should use the value of the preference 462 field to select the next NAPTR to consider. However, because it 463 will often be the case where preferred protocols or services 464 exist, clients may use this additional criteria to sort the 465 records. 467 If the lookup after a rewrite fails, clients are strongly 468 encouraged to report a failure, rather than backing up to pursue 469 other rewrite paths. 471 9. IANA Considerations 473 The values for the Services and Flags fields will be determined by 474 the Application that makes use of this DDDS Database. Those values 475 may require a registration mechanism and thus may need some IANA 476 resources. This specification by itself does not. 478 10. Security Considerations 480 The NAPTR record, like any other DNS record, can be signed and 481 validated according to the procedures specified in DNSSEC. 483 This Database makes identifiers from other namespaces subject to the 484 same attacks as normal domain names. Since they have not been easily 485 resolvable before, this may or may not be considered a problem. 487 Regular expressions should be checked for sanity, not blindly passed 488 to something like PERL since arbitrary code can be included and 489 subsequently processed. 491 References 493 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 494 One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- 495 urn-ddds-toc-00.txt (work in progress), October 2001. 497 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 498 Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work 499 in progress), May 2000. 501 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 502 Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- 503 database-07.txt (work in progress), May 2000. 505 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 506 Four: The URI Resolution Application", RFC YYYY, draft-ietf- 507 urn-uri-res-ddds-05.txt (work in progress), October 2000. 509 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 510 Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- 511 urn-net-procedures-09.txt (work in progress), October 2001. 513 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 514 Levels", RFC 2119, BCP 14, March 1997. 516 [7] Mockapetris, P., "Domain names - implementation and 517 specification", RFC 1035, STD 13, Nov 1987. 519 [8] Mockapetris, P., "Domain names - concepts and facilities", RFC 520 1034, STD 13, Nov 1987. 522 [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 523 specifying the location of services (DNS SRV)", RFC 2782, 524 February 2000. 526 [10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 527 RFC 2234, November 1997. 529 [11] Daniel, R., "A Trivial Convention for using HTTP in URN 530 Resolution", RFC 2169, June 1997. 532 [12] IEEE, "IEEE Standard for Information Technology - Portable 533 Operating System Interface (POSIX) - Part 2: Shell and 534 Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. 536 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 537 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 538 1998. 540 [14] Moats, R., "URN Syntax", RFC 2141, May 1997. 542 [15] Sollins, K., "Architectural Principles of Uniform Resource Name 543 Resolution", RFC 2276, January 1998. 545 [16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 546 Identifiers using the Domain Name System", RFC 2168, June 1997. 548 [17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 549 2279, January 1998. 551 Author's Address 553 Michael Mealling 554 VeriSign 555 505 Huntmar Park Drive 556 Herndon, VA 22070 557 US 559 Phone: +1 770 921-2251 560 EMail: michael@research.netsol.com 561 URI: http://www.verisign.com 563 Full Copyright Statement 565 Copyright (C) The Internet Society (2001). All Rights Reserved. 567 This document and translations of it may be copied and furnished to 568 others, and derivative works that comment on or otherwise explain it 569 or assist in its implementation may be prepared, copied, published 570 and distributed, in whole or in part, without restriction of any 571 kind, provided that the above copyright notice and this paragraph are 572 included on all such copies and derivative works. However, this 573 document itself may not be modified in any way, such as by removing 574 the copyright notice or references to the Internet Society or other 575 Internet organizations, except as needed for the purpose of 576 developing Internet standards in which case the procedures for 577 copyrights defined in the Internet Standards process must be 578 followed, or as required to translate it into languages other than 579 English. 581 The limited permissions granted above are perpetual and will not be 582 revoked by the Internet Society or its successors or assigns. 584 This document and the information contained herein is provided on an 585 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 586 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 587 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 588 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 589 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 591 Acknowledgement 593 Funding for the RFC Editor function is currently provided by the 594 Internet Society.