idnits 2.17.1 draft-martins-ilps-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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT | F. (Lalo) Martins 2 November 4 1996 | Independent software developer 3 Expires: May 4 1997 | Linux Objex development team 5 Internet Location Path System (ILPS) 6 draft-martins-ilps-00.txt 8 Status of this Document 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This document presents a new, uniform method of mapping IP 29 addresses, service identifiers and service-specific info. It does the 30 same work that is done by DNS and URLs. I realize this would be 31 extremally hard to implement, as there is already an immense working 32 base of DNS, but the idea provides so much benefits that I thought I 33 did not have the right not to post it (so maybe the URN folks use it 34 for something). 36 Introduction 38 Currently a good number of Internet users are not experienced 39 computer users, and many of them aren't even willing to learn some 40 kinds of things. For this kind of people, the current model of DNS 41 and URLs is not a clear enought system. 43 This document proposes a method that can join the three stages of 44 finding something in one, reasonable model. As this is designed to 45 mimic unix and msdos paths, I called it the "location path" system. 47 Draft Location Path System November 96 49 Table of Contents 51 This document is presented in five chapters and two appendices. 53 1.Description of the system ....................................... 2 55 2.The lookup protocol ............................................. 3 57 3.Proposed new top-level standard ................................. 5 59 4.Security considerations ......................................... 6 61 a.References ...................................................... 6 63 b.Author's Address ................................................ 6 65 1.Description of the system 67 The Location Path system presents the user with just a path - no 68 access scheme (http:// etc). Optionally, there are part-specifiers 69 (#) and parameters (?). A example location path could look like: 71 /org/ietf/ftp/1id-abstracts.txt 73 It starts like the Domain Name System, just reversed: first the 74 top-level domain, then the more specific ones. 76 This is also an oportunity to fix the problems people are 77 complaining of in the top-level domains. First, US domains could be 78 forced in /us/...; then, international bodies like the IETF or UNO 79 could be on /org/ietf or /org/uno and local US ones on /us/org/... 81 Then the com domains can be split... etc... but this is outside 82 the scope of this document. 84 A client application starts querying any top-level ILPS lookup 85 server about the /org path. The lookup server says it knows where 86 it is. The response is, in human-readable format, "yes - it's ILPS 87 on 123.456.789.0" (for example - for very dumb example). 89 Then, as the reply says "ILPS", the client, using the same 90 connection, asks about /org/ietf. The server may know where this is, 91 or not. if it does, it will issue a similar response, probably giving 92 the IP address of the IETF's private lookup server. Then the client 93 will ask of /org/ietf/ftp, which the top-level server probably won't 94 know. 96 On the first negative message, the client ends the connection and 97 connects to the last positive message - in this case the IETF lookup 98 server - using the specified protocol - in this case, ILPS lookup. 100 Draft Location Path System November 96 102 Then it will ask for /ftp; the reply will be like "yes - it's ftp 103 on 132.151.19.0". As this response, while positive, specifies a 104 protocol that's not ILPS lookup, the client will close connection, 105 open a ftp connection to the specified IP address and consider all 106 remainder of the path to be the ftp path. 108 Some other examples to make it clearer: 110 /us/serv/webcom/www/lalo/ox.html 111 (means current http://www.webcom.com/lalo) 113 /fi/net/funet/irc#linux 115 /br/edu/ufsm/moo 116 (telnet://moo.ufsm.br:7777 - note the port is reported by the 117 lookup server, making things clearer and easier) 119 /us/serv/webcom/pop 121 etc... 123 2.The lookup protocol 125 Location paths are resolved trough queries using a special 126 protocol. This protocol is designed to be very simple - indeed I 127 can't think of anything simplier. 129 The connection is started by the client, trough connecting to a 130 well-known-port on the server. Of course the server's IP address has 131 to be specified. 133 Then the server issues a welcome message, informing the client it 134 is ready for the lookup. Something like 136 Location Paths Lookup server at Somewhere ready. 138 The only input that is accepted in this protocol is a parcial path 139 consisting of parts and slashes. Please note input doesn't need to be 140 preceded by a slash - you can either ask for "org" or "/org". End of 141 input is signaled by a linefeed character. 143 Parts consist on sequences of letters, digits, underscores, and 144 dots (maybe other characters are acceptable; maybe even spaces. This 145 is up to the IETF). They're separated by slashes ("/"). 147 The suggested behaviour is to first ask only about the first part, 148 then the first two ones, etc, until the server issues a negative 149 reply. But this behaviour is not mandatory - if a programmer thinks 150 of something better, this protocol doesn't keep her from doing that. 152 Server responses are given in either three lines, if it is a 153 positive one, or one line, if it is a negative. 155 Draft Location Path System November 96 157 The negative responses are just: "unknown". This can't be mistaken 158 for a positive reply, because in a positive response the first line 159 would consist only of numbers and dots. 161 A positive response consists in three lines: the first one has the 162 IP address that corresponds to the queried path, in ascii format; the 163 second line has the protocol that should be used for the connection 164 (eg http or ftp or pop3). Finally, the third line informs the client 165 to which port number it is supposed to connect. If the default, well- 166 known port is to be used, the third line may optionally be blank. 168 There's no command to end the session. The client may simply close 169 the IP connection. 171 Example session: (The client input is marked with "%", and the 172 server's with "#", but please note there's no real "%" or "#" in the 173 protocol) 175 --------- Session example below --------- 176 #Welcome - ILPS lookup server at Somewhere Internet Provider ready 177 %org 178 #123.456.789.0 179 #ILPS-lookup 180 # 181 %org/ietf 182 #132.151.19.0 183 #ILPS-lookup 184 # 185 %org/ietf/ftp 186 #unknown 187 --------- The client closes connection and goes to 132.151.19.0 ---- 188 #ILPS lookup server at the Internet Enginering Task Force ready 189 %org/ietf/ftp 190 #132.151.19.0 191 #ftp 192 # 193 --------- The client closes connection. Other example: --------- 194 #Welcome - ILPS lookup server at Universidade de Santa Maria ready 195 %br/edu/ufsm/moo 196 #132.1.30.2 197 #telnet 198 #7777 199 --------- End --------- 200 Draft Location Path System November 96 202 3.Proposed new top-level standard 204 This proposal is not really part of the Location Path system, but 205 is included in this document for convenience. 207 Companies, organisations and people in the .com domain are 208 complaining, recently, that there are not enought new domains 209 available. They propose either splitting or duplication of the .com 210 domain, with domains like "corp" or "bizz". 212 This document proposes, first, that all domains belonging to the 213 United States be kept in the /us path. This is not for a personal 214 reason or even for the sake of organization. The reason for this is 215 that he top-level domains, outside /us, are kept for organisations 216 that are really international, like the IETF, the ONU or the world- 217 wide-corporative site of a multinacional corporation (and regional 218 sites would be in /us etc). 220 The non-country top-level domains should be: 222 edu, gov, mil - for the same purpose these are used today; 224 net - almost the same as it is today, but organisations that are 225 today on "org" domains and that have the Internet as its sole 226 field of action like the IETF or w3c should be on "net". 228 serv (or ser) - this domain is to "com" like "net" is to "org"; it 229 is for for-profit-companies that have the Internet as its sole 230 OR MAIN field of action, like service providers, search engines, 231 web-space providers etc. 233 info (or inf) - for companies and organisations on the field of 234 public communications - radios, TVs, newspapers, magazines etc. 236 per - for individuals. Currently it is very rare to see domain names 237 owned by individuals, but these already exist, and will become 238 very common with technologies like cable modems. These shouldn't 239 take up space in the com path. Of course there wouldn't be a 240 top-level /per path; is there any person that is really 241 international (the person herself, not trough an organisation)? 243 com - for any for-profit organisation that doesn't fit on the serv or 244 info categories. 246 This proposal was well thought of, so it should be considered. 247 Just the distinction of serv/inf/com is probably enought to solve 248 today's problems (as almost half com domains would go to serv). 250 Also, it is recommended that all countries follow the same 251 standard. 253 Draft Location Path System November 96 255 4.Security considerations 257 This document doesn't address any security issue. 259 Appendix A.References 261 This document doesn't have any reference, as it addresses a 262 question that was never addressed before. Maybe the RFCs and STDs on 263 DNS and top-level domains should be considered references? 265 Appendix B.Author's Address 267 Fernando Mauro Martins - aka Lalo 269 postal: Rua Mario de Andrade, 912 - cep 14030-340 270 Ribeirao Preto - SP - Brazil 272 phone: +55-11-263 7358 (home and operating base) 274 now how to REALLY contact me: 276 http://webcom.com/lalo | mailto:lalo@webcom.com