idnits 2.17.1 draft-ietf-urn-ddds-toc-01.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. ** The abstract seems to contain references ([5], [6], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 11, 2002) is 8135 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: '2' is defined on line 183, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 191, but no explicit reference was found in the text == 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 ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '5') ** Obsolete normative reference: RFC 2915 (ref. '6') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2916 (ref. '7') (Obsoleted by RFC 3761) ** Obsolete normative reference: RFC 2168 (ref. '8') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 2 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: July 12, 2002 January 11, 2002 6 Dynamic Delegation Discovery System (DDDS) Part One: The 7 Comprehensive DDDS Standard 8 draft-ietf-urn-ddds-toc-01.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 July 12, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This document specifies the exact documents that make up the complete 40 Dynamic Delegation Discovery System (DDDS) standard. The DDDS is an 41 abstract algorithm for applying dynamically retrieved string 42 transformation rules to an application-unique string. 44 This document along with RFC XXXX, RFC YYYY and RFC ZZZZ obsolete RFC 45 2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5]. 47 1. Intended Audience 49 This document and the documents that it references are intended for 50 anyone attempting to implement or understand the generic DDDS 51 algorithm, URI Resolution, ENUM telephone number to URI resolution, 52 and the NAPTR DNS resource record. The reader is warned that reading 53 one of the documents in this series without reading the others will 54 probably lead to misunderstandings and interoperability problems. 56 2. Introduction 58 The Dynamic Delegation Discovery System is used to implement lazy 59 binding of strings to data, in order to support dynamically 60 configured delegation systems. The DDDS functions by mapping some 61 unique string to data stored within a DDDS Database by iteratively 62 applying string transformation rules until a terminal condition is 63 reached. This document defines the entire DDDS standard by listing 64 the documents that make up the complete specification at this time. 66 This document along with RFC XXXX, RFC YYYY and RFC ZZZZ obsolete RFC 67 2168 [8] and RFC 2915 [6] as well as update RFC 2276 [5]. This 68 document will be updated and or obsoleted when changes are made to 69 the DDDS specifications. Thus the reader is strongly encouraged to 70 check the IETF RFC repository for any documents that obsolete or 71 update this one. 73 3. The Algorithm 75 The DDDS algorithm is defined by RFC XXXX [1]. That document defines 76 the following DDDS concepts: 78 o The basic DDDS vocabulary 80 o The algorithm 82 o The requirements on applications using the algorithm 84 o The requirements on databases that store DDDS rules 86 RFC XXXX is the actual DDDS algorithm Specification. But the 87 specification by itself is useless without some additional document 88 that defines how and why the algorithm is used. These documents are 89 called Applications and do not actually make up part of the DDDS core 90 specification. Applications require databases in which to store 91 their Rules. These databases are called DDDS Databases and are 92 usually specified in separate documents. But again, these Database 93 specifications are not included in the DDDS core specification 94 itself. 96 4. DDDS Applications 98 No implementation can begin without an Application specification, as 99 this is what provides the concrete instantiation details for the 100 DDDS. Without them the DDDS is nothing more than a general 101 algorithm. Application documents define the following: 103 o the Application Unique String (the thing the delegation rules act 104 on) 106 o the First Well Known Rule (the Rule that says where the process 107 starts) 109 o the list of valid Databases (you can't just use any Database) 111 o the final expected output 113 Some sample Applications are documented in: 115 o "E.164 number and DNS" (RFC 2916) [7]. This Application uses the 116 DDDS to map a telephone number to service endpoints such as SIP or 117 email. 119 o "Dynamic Delegation Discovery System (DDDS) Part Four: The URI 120 Resolution Application" (RFC YYYY) [3]. This Application uses the 121 DDDS to resolve any URI to a set of endpoints or 'resolvers' that 122 can give additional information about the URI independent of its 123 particular URI scheme. 125 5. Currently Standardized Databases 127 Any DDDS Application must use some type of DDDS Database. Database 128 documents define the following: 130 o the general spec for how the Database works 132 o formats for Keys 134 o formats for Rules 136 o Key lookup process 138 o rule insertion procedures 140 o collision avoidance measures 142 A Database cannot be used on its own; there must be at least one 143 Application that uses it. Multiple Databases and Applications are 144 defined, and some Databases will support multiple Applications. 145 However, not every Application uses each Database, and vice versa. 146 Thus, compliance is defined by the combination of a Database and 147 Application specification. 149 One sample Database specification is documented in: 151 o "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 152 Database" (RFC XXXX) [1] (This document is the official 153 specification for the NAPTR DNS Resource Record) 155 6. Security Considerations 157 Any known security issues that arise from the use of algorithms and 158 databases must be specified in the respective specifications. They 159 must be completely and fully described. It is not required that the 160 database and algorithms be secure or that it be free from risks, but 161 that the known risks be identified. Publication of a new database 162 type or algorithm do require a security review, and the security 163 considerations section should be subject to continuing evaluation. 164 Additional security considerations should be addressed by publishing 165 revised versions of the database and algorithm specifications. 167 7. IANA Considerations 169 While this document itself does not create any new requirements for 170 the IANA, the documents in this series create many varied 171 requirements. The IANA Considerations sections in those documents 172 should be reviewed by the IANA to determine the complete set of new 173 registries and requirements. Any new algorithms, databases or 174 applications should take great care in what they require the IANA to 175 do in the future. 177 References 179 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 180 Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work 181 in progress), May 2000. 183 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 184 Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- 185 database-07.txt (work in progress), May 2000. 187 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 188 Four: The URI Resolution Application", RFC YYYY, draft-ietf-urn- 189 uri-res-ddds-05.txt (work in progress), October 2000. 191 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 192 Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-urn- 193 net-procedures-09.txt (work in progress), October 2001. 195 [5] Sollins, K., "Architectural Principles of Uniform Resource Name 196 Resolution", RFC 2276, January 1998. 198 [6] Mealling, M. and R. Daniel, "The Naming Authority Pointer 199 (NAPTR) DNS Resource Record", RFC 2915, August 2000. 201 [7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. 203 [8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 204 Identifiers using the Domain Name System", RFC 2168, June 1997. 206 Author's Address 208 Michael Mealling 209 VeriSign 210 505 Huntmar Park Drive 211 Herndon, VA 22070 212 US 214 Phone: +1 770 921-2251 215 EMail: michaelm@netsol.com 216 URI: http://www.verisign.com 218 Full Copyright Statement 220 Copyright (C) The Internet Society (2002). All Rights Reserved. 222 This document and translations of it may be copied and furnished to 223 others, and derivative works that comment on or otherwise explain it 224 or assist in its implementation may be prepared, copied, published 225 and distributed, in whole or in part, without restriction of any 226 kind, provided that the above copyright notice and this paragraph are 227 included on all such copies and derivative works. However, this 228 document itself may not be modified in any way, such as by removing 229 the copyright notice or references to the Internet Society or other 230 Internet organizations, except as needed for the purpose of 231 developing Internet standards in which case the procedures for 232 copyrights defined in the Internet Standards process must be 233 followed, or as required to translate it into languages other than 234 English. 236 The limited permissions granted above are perpetual and will not be 237 revoked by the Internet Society or its successors or assigns. 239 This document and the information contained herein is provided on an 240 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 241 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 242 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 243 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 244 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 246 Acknowledgement 248 Funding for the RFC Editor function is currently provided by the 249 Internet Society.