INTERNET-DRAFT | F. (Lalo) Martins November 4 1996 | Independent software developer Expires: May 4 1997 | Linux Objex development team Internet Location Path System (ILPS) draft-martins-ilps-00.txt Status of this Document This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents a new, uniform method of mapping IP addresses, service identifiers and service-specific info. It does the same work that is done by DNS and URLs. I realize this would be extremally hard to implement, as there is already an immense working base of DNS, but the idea provides so much benefits that I thought I did not have the right not to post it (so maybe the URN folks use it for something). Introduction Currently a good number of Internet users are not experienced computer users, and many of them aren't even willing to learn some kinds of things. For this kind of people, the current model of DNS and URLs is not a clear enought system. This document proposes a method that can join the three stages of finding something in one, reasonable model. As this is designed to mimic unix and msdos paths, I called it the "location path" system. Martins [Page 1] Draft Location Path System November 96 Table of Contents This document is presented in five chapters and two appendices. 1.Description of the system ....................................... 2 2.The lookup protocol ............................................. 3 3.Proposed new top-level standard ................................. 5 4.Security considerations ......................................... 6 a.References ...................................................... 6 b.Author's Address ................................................ 6 1.Description of the system The Location Path system presents the user with just a path - no access scheme (http:// etc). Optionally, there are part-specifiers (#) and parameters (?). A example location path could look like: /org/ietf/ftp/1id-abstracts.txt It starts like the Domain Name System, just reversed: first the top-level domain, then the more specific ones. This is also an oportunity to fix the problems people are complaining of in the top-level domains. First, US domains could be forced in /us/...; then, international bodies like the IETF or UNO could be on /org/ietf or /org/uno and local US ones on /us/org/... Then the com domains can be split... etc... but this is outside the scope of this document. A client application starts querying any top-level ILPS lookup server about the /org path. The lookup server says it knows where it is. The response is, in human-readable format, "yes - it's ILPS on 123.456.789.0" (for example - for very dumb example). Then, as the reply says "ILPS", the client, using the same connection, asks about /org/ietf. The server may know where this is, or not. if it does, it will issue a similar response, probably giving the IP address of the IETF's private lookup server. Then the client will ask of /org/ietf/ftp, which the top-level server probably won't know. On the first negative message, the client ends the connection and connects to the last positive message - in this case the IETF lookup server - using the specified protocol - in this case, ILPS lookup. Martins [Page 2] Draft Location Path System November 96 Then it will ask for /ftp; the reply will be like "yes - it's ftp on 132.151.19.0". As this response, while positive, specifies a protocol that's not ILPS lookup, the client will close connection, open a ftp connection to the specified IP address and consider all remainder of the path to be the ftp path. Some other examples to make it clearer: /us/serv/webcom/www/lalo/ox.html (means current http://www.webcom.com/lalo) /fi/net/funet/irc#linux /br/edu/ufsm/moo (telnet://moo.ufsm.br:7777 - note the port is reported by the lookup server, making things clearer and easier) /us/serv/webcom/pop etc... 2.The lookup protocol Location paths are resolved trough queries using a special protocol. This protocol is designed to be very simple - indeed I can't think of anything simplier. The connection is started by the client, trough connecting to a well-known-port on the server. Of course the server's IP address has to be specified. Then the server issues a welcome message, informing the client it is ready for the lookup. Something like Location Paths Lookup server at Somewhere ready. The only input that is accepted in this protocol is a parcial path consisting of parts and slashes. Please note input doesn't need to be preceded by a slash - you can either ask for "org" or "/org". End of input is signaled by a linefeed character. Parts consist on sequences of letters, digits, underscores, and dots (maybe other characters are acceptable; maybe even spaces. This is up to the IETF). They're separated by slashes ("/"). The suggested behaviour is to first ask only about the first part, then the first two ones, etc, until the server issues a negative reply. But this behaviour is not mandatory - if a programmer thinks of something better, this protocol doesn't keep her from doing that. Server responses are given in either three lines, if it is a positive one, or one line, if it is a negative. Martins [Page 3] Draft Location Path System November 96 The negative responses are just: "unknown". This can't be mistaken for a positive reply, because in a positive response the first line would consist only of numbers and dots. A positive response consists in three lines: the first one has the IP address that corresponds to the queried path, in ascii format; the second line has the protocol that should be used for the connection (eg http or ftp or pop3). Finally, the third line informs the client to which port number it is supposed to connect. If the default, well- known port is to be used, the third line may optionally be blank. There's no command to end the session. The client may simply close the IP connection. Example session: (The client input is marked with "%", and the server's with "#", but please note there's no real "%" or "#" in the protocol) --------- Session example below --------- #Welcome - ILPS lookup server at Somewhere Internet Provider ready %org #123.456.789.0 #ILPS-lookup # %org/ietf #132.151.19.0 #ILPS-lookup # %org/ietf/ftp #unknown --------- The client closes connection and goes to 132.151.19.0 ---- #ILPS lookup server at the Internet Enginering Task Force ready %org/ietf/ftp #132.151.19.0 #ftp # --------- The client closes connection. Other example: --------- #Welcome - ILPS lookup server at Universidade de Santa Maria ready %br/edu/ufsm/moo #132.1.30.2 #telnet #7777 --------- End --------- Martins [Page 4] Draft Location Path System November 96 3.Proposed new top-level standard This proposal is not really part of the Location Path system, but is included in this document for convenience. Companies, organisations and people in the .com domain are complaining, recently, that there are not enought new domains available. They propose either splitting or duplication of the .com domain, with domains like "corp" or "bizz". This document proposes, first, that all domains belonging to the United States be kept in the /us path. This is not for a personal reason or even for the sake of organization. The reason for this is that he top-level domains, outside /us, are kept for organisations that are really international, like the IETF, the ONU or the world- wide-corporative site of a multinacional corporation (and regional sites would be in /us etc). The non-country top-level domains should be: edu, gov, mil - for the same purpose these are used today; net - almost the same as it is today, but organisations that are today on "org" domains and that have the Internet as its sole field of action like the IETF or w3c should be on "net". serv (or ser) - this domain is to "com" like "net" is to "org"; it is for for-profit-companies that have the Internet as its sole OR MAIN field of action, like service providers, search engines, web-space providers etc. info (or inf) - for companies and organisations on the field of public communications - radios, TVs, newspapers, magazines etc. per - for individuals. Currently it is very rare to see domain names owned by individuals, but these already exist, and will become very common with technologies like cable modems. These shouldn't take up space in the com path. Of course there wouldn't be a top-level /per path; is there any person that is really international (the person herself, not trough an organisation)? com - for any for-profit organisation that doesn't fit on the serv or info categories. This proposal was well thought of, so it should be considered. Just the distinction of serv/inf/com is probably enought to solve today's problems (as almost half com domains would go to serv). Also, it is recommended that all countries follow the same standard. Martins [Page 5] Draft Location Path System November 96 4.Security considerations This document doesn't address any security issue. Appendix A.References This document doesn't have any reference, as it addresses a question that was never addressed before. Maybe the RFCs and STDs on DNS and top-level domains should be considered references? Appendix B.Author's Address Fernando Mauro Martins - aka Lalo postal: Rua Mario de Andrade, 912 - cep 14030-340 Ribeirao Preto - SP - Brazil phone: +55-11-263 7358 (home and operating base) now how to REALLY contact me: http://webcom.com/lalo | mailto:lalo@webcom.com Martins [Page 6]