idnits 2.17.1 draft-ietf-uri-urn-path-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 473 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** 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 ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 210 has weird spacing: '...ath.urn c2,...' == Line 212 has weird spacing: '...ath.urn d.c,...' == Line 238 has weird spacing: '...ath.urn c, ...' == Line 239 has weird spacing: '...ath.urn d ...' -- 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 (Sept 25, 1995) is 10708 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) -- Missing reference section? '2' on line 328 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 3 The Path URN Specification 4 ************************** 6 draft-ietf-uri-urn-path-00.txt 7 Expires Sept 25, 1995 9 Daniel LaLiberte 10 Michael Shapiro 12 This document is also available in HTML at: 14 16 Status of this memo 17 =================== 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 This Internet Draft expires Sept 25, 1995. 37 Last modified: Mon Mar 20 12:13:51 1995 39 Abstract 40 ======== 42 A new "path" URN scheme is proposed that defines a uniformly 43 hierarchical name space. The resolution of a path URN is a two-step 44 process: locating the resolution server and locating the resource 45 within the server. Existing DNS capabilities are used to locate the 46 resolution server and HTTP is used as the protocol for locating a 47 resource within the server. 49 Introduction 50 ============ 52 Conceptually, the path scheme defines a uniformly hierarchical name 53 space. A path is a sequence of components and an optional opaque 54 string. An example path is: 56 path:/A/B/C/doc.html 58 Names are assigned by naming authorities that are responsible for a 59 subtree of the name space, and naming authories may delegate 60 responsibility to sub-authorities. Each naming authority corresponds 61 to a name resolution service, which may be shared by several 62 naming authorities. 64 In this document, we first describe the name resolution process 65 conceptually. This is followed by a detailed description of our 66 (planned) implementation, the encoding rules, and the discussion of 67 URN requirements. 69 The Name Resolution Process 70 =========================== 72 This section describes the resolution process conceptually but not 73 completely. See the implementation section for the details. 75 The name resolution process involves two steps: First we traverse 76 the path left to right until we find a most-specific server, then we 77 interact with that server to resolve the remainder of the path name. 78 The server has the option of returning a redirection to a URL. 80 The resolution process starts at the path name root located at some 81 fixed, globally known network address. The root corresponds to a 82 name resolution service which resolves the first component of a path 83 into the address of another node. Generally, each node in the 84 hierarchy resolves a path component into another node at the next 85 lower level. This process repeats until no more-specific resolver is 86 found. 88 The name resolver for each node must tell clients whether there is a 89 more-specific resolver for the given path. This information will be 90 used by clients to avoid requesting resolution for components of the 91 path that do not have a more-specific resolver. If there is a 92 more-specific resolver, then the client proceeds with the process of 93 requesting subsequent components of the path. If there is not a 94 more-specific resolver, then this first phase of the resolution 95 process is completed. 97 Clients are expected to make use of caches to retain information 98 about recently visited name resolvers so that resolution of a path 99 can start from the most-specific known resolver instead of at the 100 root. 102 Once the most-specific resolver is found for a particular path, it 103 returns the address of a separate terminal resolver to the client. The 104 client then sends the full path to this terminal resolver. The path 105 scheme defines the protocol for interacting with the terminal resolver 106 as HTTP. 108 The result of the terminal resolution may be any document, identified 109 by Content-type, or it may be a redirection to a URL. The URL may 110 be, for example, an http URL or another path URN. 112 Implementation of Resolution 113 ============================ 115 The implementation of the resolution process follows the abstract 116 two-step process. The first step resolves the name into an IP 117 address and a port number. The second step involves contacting a 118 server at the IP address and port number returned by the first step 119 and, using the HTTP protocol, issuing a GET of the entire URN. 121 Resolving the name into a server and port number 122 +++++++++++++++++++++++++++++++++++++++++++++++++ 124 The resolution of a name into a server and port number is done 125 using existing DNS capabilities. As an aid for the discussion that 126 follows, the following partial document tree is used: 128 / 129 | 130 A 131 | 132 -------------------------- 133 | | 134 B1* B2* 135 | | 136 ---------- | 137 | | | 138 C1 C2* C 139 | 140 D* 142 The nodes marked with * are server nodes. They have one or more 143 (IP-address, port) pairs associated with them. 145 /A/B1 serves all documents under /A/B1 except /A/B1/C2 146 /A/B2 serves all documents under /A/B2 execpt /A/B2/C/D 148 The resolution process proceeds as follows. 150 1. The entire URN, except the scheme and the final component, 151 is converted to a DNS name appended with ".path.urn". For 152 example, 154 path:/A/B2/C1/doc.html is converted to 155 c1.b2.a.path.urn 157 2. Partial-names are built starting with the last three 158 components of the DNS name and iteratively adding 159 components. All DNS records associated with this 160 partial-name are requested using DNS resolvers. 162 o If the TXT record is missing, then the URN does not 163 resolve into a server and the URN is assumed to be 164 invalid. 166 o If there is an A record, then this is a server node. The 167 TXT record lists sub-nodes not handled by this 168 server. 170 o If none of the sub-nodes listed in the TXT 171 record match, then this is the server. 173 o Else this implies that there is a DNS entry for 174 the sub-node. The matching component is 175 added to the partial-name to form a new 176 partial-name and this step is repeated. 178 o If there is no A record 180 o If no A record has been encountered up to this 181 point, the next component of the URN is added 182 to the partial-name to form a new partial-name 183 and this step repeated. 185 o If at least one A record has been encounted up 186 to this point 188 o If none of the sub-nodes listed in the 189 TXT record match the remaining 190 components of the path, then the most 191 recent partial-name that had an A 192 record is the server for this name. 194 o Else this implies that there is a DNS 195 entry for the sub-node. The matching 196 component is added to the partial-name 197 to form a new partial-name and this step 198 is repeated. 200 Once the server DNS entry is located, the IP-address(es) 201 are extracted from the A record and the associated port 202 number(s) extracted from the TXT record. 204 To clarify the above algorithm, some examples are presented. The 205 examples use the partial document tree specified previously. The 206 DNS entries for this partial tree are: 208 TXT A 209 a.path.urn -empty- -none- 210 b1.a.path.urn c2, port=n ip-address 211 c2.b1.a.path.urn port=n ip-address 212 b2.a.path.urn d.c, port=n ip-address 213 d.c.b2.a.path.urn port=n ip-address 215 Example lookups 217 /A/B1/C1/doc.ps 219 a.path.urn no A record 220 repeat with b1.a.path.urn 221 b1.a.path.urn has A record, TXT doesn't have c1 222 this is the server 224 /A/B2/C/D/doc.ps 226 a.path.urn no A record 227 repeat with b2.a.path.urn 228 b2.a.path.urn has A record, TXT has d.c 229 repeat with d.c.b2.a.path.urn 230 d.c.b2.a.path.urn has A record 231 this is the server 233 Alternatively, there could be an entry for c.b2.a.path.urn instead 234 of it being subsumed in b2.a.path.urn: 236 TXT A 237 a.path.urn -empty- -none- 238 b2.a.path.urn c, port=n ip-address 239 c.b2.a.path.urn d -none- 240 d.c.b2.a.path.urn port=n ip-address 242 The lookups proceed as 244 /A/B2/C/D/doc.ps 246 a.path.urn no A record 247 repeat with b2.a.path.urn 248 b2.a.path.urn has A record, TXT has c 249 repeat with c.b2.a.path.urn 250 c.b2.a.path.urn no A record, TXT has d 251 repeat with d.c.b2.a.path.urn 252 d.c.b2.a.path.urn has A record 253 this is the server 255 /A/B2/C/E/doc.ps 257 a.path.urn no A record 258 repeat with b2.a.path.urn 259 b2.a.path.urn has A record, TXT has c 260 repeat with c.b2.a.path.urn 261 c.b2.a.path.urn no A record, TXT does not have e 262 server at b2.a.path.urn 264 Locating the Resource 265 +++++++++++++++++++++ 267 The full path URN is passed to the server using the HTTP protocol 268 as a GET request. The server must either return a full response 269 (with HTTP header and response), or a URI-header in HTTP 270 message types 301 (moved permanently) or 302 (moved 271 temporarily). For the redirect messages, the client should process 272 the URLs normally. 274 If the HTTP server returns a full response, the object returned could 275 be the named object itself, or it might be metadata for the object. In 276 either case, it would be identified by the Content-type header line. If 277 and when URC standards are defined, clients that are capable of 278 handling URCs indicate that in the Accepts header line. For clients 279 that cannot handle URCs, the server could automatically process 280 the URC to instead return a URL for the object, or it could return the 281 object itself. 283 Encoding Syntax 284 =============== 286 ::= "path:" 287 ::= "/" [ ] 288 ::= "" | "/"