[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                    |                 F. (Lalo) Martins
November 4 1996                   |    Independent software developer
Expires: May 4 1997               |      Linux Objex development team

                Internet Location Path System (ILPS)

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).


   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).


   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:


   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

   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". 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:

   (means current http://www.webcom.com/lalo)


   (telnet://moo.ufsm.br:7777 - note the port is reported by the
    lookup server, making things clearer and easier)



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

--------- Session example below ---------
#Welcome - ILPS lookup server at Somewhere Internet Provider ready
--------- The client closes connection and goes to ----
#ILPS lookup server at the Internet Enginering Task Force ready
--------- The client closes connection. Other example: ---------
#Welcome - ILPS lookup server at Universidade de Santa Maria ready
--------- 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

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]