\documentstyle[rfc,fancyheadings,cerndoc]{cernman}
\lhead[RFC XXX]{1 Jan 1994}
\chead{Uniform Resource Locators}
\rhead[1 Jan 1994]{RFC XXXX}
\lfoot[\thepage]{Berners-Lee}
\rfoot[Berners-Lee]{\thepage}
\cfoot{}
\pagestyle{fancy}
\begin{document}
% First page special
\thispagestyle{plain}
\begin{tabular*}{\textwidth}{@{}l@{\extracolsep{\fill}}r@{}}
Uniform Resource Locators&Tim Berners-Lee\\
draft-ietf-uri-url-02.{txt,ps}&CERN\\
Expires 1 July 1994&1 Jan 1994\\[0.5cm]
\end{tabular*}

\begin{center}
\Large\bf\sf
Uniform Resource Locators\\[1cm]
\large A unifying syntax for the expression of names and addresses
of objects on the network\\[1cm]
\end{center}
% --------------------------------------------------------






\section*{Status of this memo}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.  \par 
Internet Drafts are working documents
valid for a maximum of six months.
Internet Drafts may be updated, replaced,
or obsoleted by other documents at
any time.  It is not appropriate
to use Internet Drafts as reference
material or to cite them other than
as a "working draft" or "work in
progress".  \par 
Distribution of this document is
unlimited.  Please send comments
to the author as timbl@info.cern.ch.
or to the discussion list  ietf-url@merit.edu.
\section*{Abstract  }Many protocols and systems for document
search and retrieval are currently
in use, and many more protocols or
refinements of existing protocols
are to be expected in a field whose
expansion is explosive.  \par 
These systems are aiming to achieve
global search and readership of documents
across differing computing platforms,
and despite a plethora of protocols
and data formats.   As protocols
evolve, gateways can allow global
access to remain possible. As data
formats evolve, format conversion
programs can preserve global access.
There is one area, however, in which
it is impractical to make conversions,
and that is in the names and addresses
used to identify objects.  This is
because names and addresses of objects
are passed on in so many ways, from
the backs of envelopes to hypertext
objects, and may have a long life.\par 
A common feature of almost all the
data models of past and proposed
systems is something which can be
mapped onto a concept of "object"
and some kind of name, address, or
identifier for that object.  One
can therefore define a set of name
spaces in which these objects can
be said to exist.\par 
Practical systems need to access
and mix objects which are part of
different existing and proposed systems.
\par 
This paper discusses the requirements
on a universal syntax which can be
used to encapsulate a name in any
registered name space.  This will
allow names in different spaces to
be treated in a common way, even
though names in different spaces
have differing characteristics, as
do the objects to which they refer\par 
The universal syntax to objects available
using existing protocols, and may
be extended with technology.  It
makes a recommendation for a generic
syntax, and for specific forms for
"Uniform Resource Locators" (URLs)of
objects accessible using existing
Internet protocols.\par 
The syntax has been in widespread
use by World-Wide Web software since
1990.







\section*{Terms}The objects on the network which
are to be named and addressed include
typically objects which can be retrieved,
and objects which can be searched.
 There is a great variety of other
objects which may support other operations.
We imply nothing about the contents
of objects in this document. Whereas
human-readable documents are currently
the center of interest of the field,
we envisage all aspects discussed
in this paper applying to generalized
objects when systems to handle them
become available. The "object" is
the unit of reference and need not
correspond to any unit of storage.
We refer to objects which can be
searched as "indexes".  We emphasize
that this is the abstract view of
the client, and these objects need
not correspond to physical files
on computers. We refer to the person
who does the retrieval or searching
as the user.  \par 
Within this document, we use the
terms "name" very generally for a
string of characters describing an
object,  whatever its combination
of properties mentioned below.  (The
term usually has a narrower meaning
but we needed some term for the universal
set.).  This uniform syntax applied
to a generic name is known as a Uniform
Resource Identifier (URI). The term
"address" is reserved for an string
which specifies a more or less physical
location.  The term "locator" refers
to a URL as here defined.  URIs which
have a greater persistence than URLs
are referred to as URNs.







\section*{Characteristics  }This section characteristics of various
naming schemes, requirements which
some ofexisting schemes meet, and
requirements for the URL scheme itself.
URLs, as an introduction of and background
for the Recommendations section.
\subsection*{Uses of names and addresses  }A name allows a user, with the help
of a "client" program, to retrieve
or operate on objects via a "server"
program.  A name may be passed for
example:  
\begin{itemize}
\item In communication of any form between
two people, to refer to a document,
or part of a document;
\item As part of the description of a link
associated with a hypertext document;
\item As part of the result of searching
an index.  
\end{itemize}Some typical requirements on a name
which are met to a varying degree
by various schemes are for example
that the name is
\begin{DL}{allow this much space}
\item[Persistent
] A given name will remain
valid as long as it is needed;  
\item[Extensible
] A given naming syntax
will remain valid through the introduction
of new protocols and directory technologies;
\item[Resolvable
] A name will contain enough
information to allow the document
or index to which it refers to be
accessed, perhaps via resolution
into an intermediate, more physical,
name. 
\item[Unique
] Each object can only have
one such name.  The fact that two
such names are different implies
that the objects to which they refer
are different (in some way).  
\item[Unambiguous
] The fact that two names
are identical implies that the objects
named are the same (in some way).
\end{DL}
The syntax discussed is the syntax
of one name, be it a lasting name
or a physical address.  When a directory
server or hypertext link contains
a set of alternative names, then
that is beyond the scope of this
syntax.  Similarly, a syntax for
describing a compound object is outside
the scope of this syntax.  The specific
locator name spaces (defined under
the umbrella of the general syntax)
each meet the requirements above
to a greater or lesser extent.
\subsection*{Current practice  }Current protocols use many different
standards for names. For some protocols,
such as ISO-10163 Search and Retrieve
protocol\lbrack 16\rbrack , the names returned
in a search are only valid during
the session. For others, such as
FTP\lbrack 9\rbrack , they are lasting names which
may be used for object retrieval
at a later time.  Typically, however,
they are not long-lasting names which
are independent of the location of
the object. Such names may be provided
using directory servers such as x.500.
They will refer to the registration,
however formal or informal, of a
object with a particular organisation
or person.  Both hypertext and  manual
references rely on long- lasting
names.  Current names are basically
location specifiers (addresses).
These may be known as Uniform Resource
Locators (URLs). They give the necessary
parts of an address for a reader
to access an information provider
using the given protocol, and ask
for the object required. Examples
of names used by various protocols
include
\subsubsection*{File Transfer Protocol (Postel 1985):}
\begin{itemize}
\item Host name or IP-address
\item \lbrack TCP port\rbrack   
\item \lbrack user name, password\rbrack   
\item Filename
\end{itemize}
\subsubsection*{W.A.I.S. (Kahle 1990)}
\begin{itemize}
\item Host name or IP-address
\item \lbrack TCP port\rbrack   
\item local document id
\end{itemize}
\subsubsection*{Gopher (Alberti 1991)}
\begin{itemize}
\item Host name or IP-address  
\item \lbrack TCP port\rbrack 
\item database name
\item selector string
\end{itemize}
\subsubsection*{HTTP (Berners-Lee 1991)}
\begin{itemize}
\item Host name or IP-address  
\item \lbrack TCP port\rbrack   
\item local object id
\end{itemize}
\subsubsection*{NNTP (Kantor 1986)}
\paragraph{NNTP  group}
\begin{itemize}
\item Group name
\end{itemize}
\paragraph{NNTP article}
\begin{itemize}
\item Host name
\item unique message identifier
\end{itemize}
\subsubsection*{Prospero links (Neuman 1992)}
\begin{itemize}
\item Host name or IP address  
\item \lbrack UDP port\rbrack   
\item  Host specific object name  
\item \lbrack version\rbrack   
\item \lbrack identifier\rbrack *
\end{itemize}
\subsubsection*{x.500 distinguished name}
\begin{itemize}
\item Country  
\item Organisation  
\item Organisational unit  
\item Person  
\item Local object identifier  
\end{itemize}Other systems with their own naming
schemes include BITNET "LISTSERV"
application, FTAM file retrieval,
SQLnetTM remote database search,
proprietary  distributed file systems,
etc. Conventional syntax for writing
these addresses involve various forms
of punctuation to separate these
parts.  This sometimes,  but not
always, allows the naming scheme
to be deduced from the punctuation.
For example, a name of the form xxx.yyy.zz.edu:/pub.aa.bb.cc
often implies anonymous FTP access.
However, there is no well-defined
algorithm for parsing an arbitrary
name, as there is no common syntax.
\subsection*{Expandability  }There will necessarily be a phase
during which lasting names will become
more  common, as the deployment of
directory services increases to the
point where  every user has direct
or indirect access to one.  Even
then, however, one can envisage more
than one competing directory system,
and cases in which physical  names
are still required.  A directory
service takes a lasting name and
reduces it  to a physical address
(or set of addresses) which, though
less useful for lasting reference,
is the only way to actually retrieve
the object. An addressing syntax
is required which will be able to
encompass existing  physical address
spaces, and be extendible to any
future protocols.  This  requires
that it contain an identifier for
the protocol in use. The format of
the rest  of the address will necessarily
depend to a certain extent on the
protocol.
\subsection*{Relevance  }The life of a name is limited by
any information contained within
it which may  become prematurely
invalid. It is therefore necessary
to limit the contents of a name to
the information required for the
operations above.  Other extraneous
information about the object (its
size, data format, authorisation
details, etc.) may in general change
with time and should not be part
of the name.  One might expect such
information to be part of the "header"
of a object, and for protocols to
allow the header information to be
retrieved independently of the objects
themselves.  Any physical address
may be subject to change with time:
hence we encourage the move to lasting
names and directory services.
\subsection*{Uniqueness  }Clearly one requires unambiguous
names in the sense that one name
should refer to only one logical
object. This is the case with all
the addressing schemes in use, whether
they are directory systems or physical
addresses. (The internet addresses
all rely on the domain name (Mockapetris
1987) of the host to achieve this).
However, given that names can be
translated, many apparently different
names  may lead to the same object.
Any object may therefore be referred
to by many  names. One needs to be
able to know whether two objects,
retrieved through  different paths,
are in fact the same object.  It
is suggested that each object have
a unique "official" name. This name
could be stored in the object in
some representations, or stored in
a database  accessible to the server,
for example.  Any references within
that object should be parsed in the
context of the official name.  In
the presence of a  directory service,
the official name will normally be
the registered name of the object.
However, a name in any scheme will
do, so long as it is completely specified.
On systems which do not allow the
name to be stored (such as anonymous
FTP archive sites), a possible ambiguity
will always exist as to whether two
similarly named objects are in fact
the same.  Note that Internet newsgroup
names are unique world-wide, and
news articles carry a unique message
id. In most other cases, however,
there is no guarantee that dereferencing
a URL will work, or that if it does
the object it refers to will in fact
be the object intended.  URLs such
as FTP addresses are transient in
that files may be moved and even
replaced by different files of the
same name.  This disorganisation
may be limited by good server management,
but a naming scheme which is independent
also of internet host name is obviously
preferable.
\subsection*{Readability by people  }This requirement has been put forward
by several people (Clifford Lynch,
Douglas Engelbart among others),
and disputed by others.  The author's
view is that it will be a while before
technology and standardisation have
reached the point at which names
and addresses will be hidden from
human beings. As long as they must
be written on the backs of envelopes
and "cut and pasted" between workstation
windows, there is a strong need for
names to be  
\begin{itemize}
\item Short  
\item  Composed of printable (preferably
non-white) characters  
\item To a certain extent, understadable
by a human being.
\end{itemize}
\subsection*{Structure of names and addresses}A physical address is required in
order for:
\begin{itemize}
\item The user's program to contact the
server;
\item The server to perform the operation
(e.g. search and index, retrieve
a object,  or look up the name) and
return a result;  
\item The user's program to locate an individual
position or element within a returned
object. 
\end{itemize}This suggests that a name be structured,
such that the parts necessary for
these  three operations be separate
and only used by those system elements
which need  those parts. This corresponds
to the basic principle of information
hiding.  In fact,  four parts are
necessary, including the indicator
of the naming scheme to be used:
\begin{itemize}
\item The naming scheme: a registered identifier
for the protocol.  
\item The name of a suitable server. The
format of this part must be well
defined. It will depend on the lower-layer
protocols in use.  Systems which
use widely distributed information,
such as x.500 and NNTP, do not need
this part as each client generally
contacts his nearest server (or a
particular server).
\item Information to be passed to the server.
This may be private to the server,
as all names may be generated and
used by the same server. This part
of the name should be opaque to the
client.
\item Information to be used by the application
once the object has been retrieved.
This part is private to the application
(or, more strictly, the data format)
and so cannot be defined here.
\end{itemize}Both lasting names and physical addresses
often share a hierarchical structure.
This follows often from the organisation
of the system. From the naming point
of view, it has the advantage that
a reference in one object to another
object need not include that part
of the structure which is common
to both names.
\subsection*{Choices for a universal syntax }The requirements above leave little
room for choice save for the order
and punctuation of the elements of
an address.  It is only reasonable
for the order of writing of the parts
to be consistently from left to right
(or right to left) with increasing
specificity.  Punctuation schemes
fall into two categories (Huitema
1991): tagged schemes in which field
are given names, and fields which
use special characters and field
order. The latter tend to be more
compact schemes.
\begin{verbatim}
	protocol: aftp host: xxx.yyy.edu path:  

        /pub/doc/README

        PR=aftp; H=xx.yy.edu; PA=/pub/doc/README;

        PR:aftp/xx.yy.edu/pub/doc/README
  
        /aftp/xx.yy.edu/pub/doc/README

\end{verbatim}
Fig 1. Some alternative tagged and
untagged representations \par 
The choice of special symbols for
punctuation tends to be a matter
of taste. It is easier to read  addresses
whose symbols correspond to those
of one's favourite operating system.
A variety of symbols is needed so
that when a name is abbreviated it
is possible to tell which parts have
been omitted. \par 
The  recommendation below uses special
characters in order to achieve a
compact name, and uses where possible
punctuation symbols established in
the internet or unix community.\par 
The choice of escape character for
introducing representations of non-allowed
characters also tends to be a matter
of taste. An ANSI standard exists
in the C language, using the back-slash
character "\char'134 ". The use of this character
on unix command lines, however, can
be a problem as it is interpreted
by many shell programs, and would
have itself to be escaped. \par 
There is a conflict between the need
to be able to represent many characters
including spaces within a URL directly,
and the need to be able to use a
URL in environments which have limited
character sets or in which certain
characters are prone to corruption.
This conflict has been resolved by
use of an hexadecimal escaping method
which may be applied to any characters
forbidden in a given context. When
URLs are moved between contexts,
the set of characters escaped may
be enlarged or reduced unambiguously.\par 
The use of multiple white space characters
is discouraged  in URLs to be printed
or sent by electronic mail.  This
is because of the frequent introduction
of extraneous white space when lines
are wrapped by systems such as mail,
or sheer necessity of narrow column
width, and because of the  inter-conversion
of various forms of white space which
occurs during character code conversion
and the transfer of text between
applications.







\section*{Recommendations}This section describes the syntax
for "Uniform Resource Locators" (URLs):
that is, basically physical addresses
of objects which are retrievable
using protocols already deployed
on the net.  The generic syntax provides
a framework for new schemes for names
to be resolved using as yet undefined
protocols.  \par 
The syntax is described in two parts.
Firstly, we give the syntax rules
of a completely specified name; secondly,
we give the rules under which parts
of the name may be omitted in a well-defined
context.
\subsection*{Full form  }A complete URL consists of a naming
scheme specifier followed by a string
whose format is a function of the
naming scheme. For locators of information
on the internet, a common syntax
is used for the  IP address part.
A BNF description of the URL syntax
is given in an a later section. The
components are as follows.  Fragment
identifiers and partial URLs are
not involved in the basic URL definition.
\subsection*{Scheme  }Within the URL of a object, the first
element is the name of the scheme,
separated from the rest of the object
by a colon. The rest of the URL follows
the colon in a format depending on
the scheme.
\subsubsection*{Internet protocol parts  }Those schemes which refer to internet
protocols have a common syntax for
the rest of the object name. This
starts with a double slash "//" to
indicate its presence, and continues
until the following slash "/".  Within
that section are  
\begin{DL}{allow this much space}
\item[An optional user name,
] if this must
be quoted to the server, followed
by  a commercial at sign "@".  (Use
of this field is discouraged. Provision
of encoding a password after the
user name, delimited by a colon,
could  be made but obviously is only
useful when the password is public,
in  which case it should not be necessary,
so that is also discouraged.)  
\item[The internet domain name
] of the host
in RFC1037 format (or, optionally
and less advisably, the IP address
as a set of four decimal digits)
\item[The port number,
] if it is not the
default number for the protocol,
is given in decimal notation after
a colon.
\item[Path
] The rest of the locator is known
as the "path". It may define details
of how the client should communicate
with the server, including information
to be passed transparently to the
server without any processing by
the client.  
\end{DL}
The path is interpreted in a manner
dependent on the protocol being used.
However, when it contains slashes,
these must imply a hierarchical structure.
\subsection*{Encoding prohibited characters}When a system uses a local addressing
scheme, it is useful to provide a
mapping from local addresses into
URLs so that references to objects
within the addressing scheme may
be referred to globally, and possibly
accessed through gateway servers.\par 
Any mapping scheme may be defined
provided it is unambiguous, reversible,
and provides valid URLs. It is recommended
that where hierarchical aspects to
the local naming scheme exist, they
be mapped onto the hierarchical URL
path syntax in order to allow the
partial form to be used.  \par 
The following encoding method shall
be used for mapping WAIS, FTP, Prospero
and Gopher addresses onto URLs. Where
the local naming scheme uses ASCII
characters which are not allowed
in the URL,  these may be represented
in the URL by a percent sign "\%"
followed by two hexadecimal digits
(0-9, A-F) giving the ISO Latin 1
code for that character.  Character
codes other than those allowed by
the syntax shall not be used in a
URL. \par 
The same encoding method may be used
for encoding characters whose use,
although technically allowed in a
URL, would be unwise due to problems
of corruption by imperfect gateways
or misrepresentation due to the use
of variant character sets, or which
would simply be awkward in a given
environment.  As a \% sign always
indicates an encoded character, a
URL may be made safer simply by encoding
any characters considered unsafe,
while leaving already encoded characters
still encoded.  \par 
(Note: If a new naming scheme is
introduced which encodes binary data
as opposed to text, then a more compact
encoding such as pure hex or base
64 would be more appropriate.)  \par 
The same considerations apply to
mapping local fragment identifiers
onto the fragmentid part of a URL.







\section*{Specific Schemes  }The mapping for some existing standard
and experimental protocols is outlined
in the BNF syntax definition .  Notes
on particular protocols follow.
\subsection*{HTTP  }The HTTP protocol specifies that
the path is handled transparently
by those who handle URLs, except
for the servers which de-reference
them.   The path is passed by the
client to the server with any request,
but is not otherwise understood by
the client.  The fragmentid part
is not sent with the request.  The
search part, if present, is sent.
Spaces in URLs should be escaped
for transmission in HTTP.
\subsection*{FTP  }The ftp: prefix indicates a file
which is to be picked up from the
file system of the given host. The
FTP protocol is used. The port number
if given gives the port of the FTP
server if not the FTP default. (A
client may in practice use local
file access to retrieve objects which
are available though more efficient
means such as local file open or
NFS mounting, where this is available
and equivalent). \par 
 The syntax allows for the inclusion
of a user name and even a password
for those systems which do not use
the anonymous FTP convention. The
default, however, if no user or password
is supplied, will be to use that
convention, viz. that the user name
is "anonymous" and the password the
user's mail address. \par 
The adoption of a unix-style syntax
involves the conversion into non-unix
local forms by either the client
or server. Some non-unix servers
do this, but clients wishing to access
sites which do not have unix-style
naming will need certain algorithms
to enable  other file systems to
be identified and treated.  Client
software may also have to be flexible
in terms of the sequence of FTP commands
used with different varieties of
server.  In view of a tendency for
file systems to look increasingly
similar, it was felt that the URL
convention should not be weighed
down by extra mechanisms for identifying
these cases. \par 
The data format of a file can only,
in the general FTP case, be deduced
from the name, normally the suffix
of the name. This is not standardized.
An alternative is for it to be transferred
in information outside the URL. The
transfer mode (binary or text) must
in turn be deduced from the data
format.  It is recommended that conventions
for suffixes of public archives be
established, but it outside the scope
of this paper.
\subsection*{News  }The news locators refer to either
news group names or article message
identifiers which must conform to
the rules of RFC 850.  A message
identifier may be distinguished from
a news group name by the presence
of the commercial at "@" character.
These rules imply that within an
article, a reference to a news group
or to another article will be a valid
URL (in the partial form). \par 
A news URL may be dereferenced using
NNTP or using any other protocol
for the conveyance of usenet news
articles.
\subsubsection*{Note1: }Among URLs the news: URLs are anomalous
in that they are location-independent.
They are unsuitable as URN candidates
because the NNTP architecture relies
on the expiry of articles and therefore
a small number of articles being
available at any time.  When a news:
URL is quoted, the assumption is
that the reader will fetch the article
or group from his or her local news
host.  News host names are NOT part
of news URLs.
\subsubsection*{Note 2:}An outstanding problem is that the
message identifier is insufficient
to allow the retrieval of an expired
article, as no algorithm exists for
deriving an archive site and file
name. The addition of the date and
news group set to the article's URL
would allow this if a directory existed
of archive sites by news group. Suggested
subject of study in conjunction with
NNTP WG.  Further extension possible
may be to allow the naming of subject
threads as addressable objects.
\subsection*{NNTP}This is an alternative form of reference
for news articles, specifically to
be used with NNTP servers, and particularly
those incomplete server implementations
which do not allow retrieval by message
identifier.\par 
The news server name, newsgroup name,
and index number of an article within
the newsgroup on that particular
server are given. 
\subsubsection*{Note1.}This form of URL is not of global
accessiablity, as typically NNTP
servers only allow access from local
clients.  This form or URL should
not be quoted outside this local
area.  It should not be used within
news articles for wider circulation
than the one server.
\subsection*{WAIS  }The current WAIS implementation public
domain requires that a client know
the "type" of a object prior to retrieval.
This value is returned along with
the internal object identifier in
the search response. It has been
encoded into the path part of the
URL in order to make the URL sufficient
for the retrieval of the object.
Within the WAIS world, names do not
of course not need to be prefixed
by "wais:"  (by the partial form
rules).
\subsection*{Prospero  }The Prospero (Neuman, 1991) directory
service is used to resolve the URL
yielding an access method for the
object (which can then itself be
represented as a URL if translated).
The host part contains a host name
or internet address.  The port part
is optional.  \par 
The path part contains a host specific
object name and an optional version
number. If present, the version number
is seperated from the  host specific
object name by the characters "\%00"
(percent zero zero), this being an
escaped string terminator (null).
 External Prospero links are represented
as URLs of the underlying access
method and are not represented as
Prospero URLs.
\subsection*{Gopher  }The first character of the URL path
part (after the initial single slash)
is a single-character "type" field
which is that used by the Gopher
protocol.  The rest of the path is
the "selector string", with disallowed
characters encoded. Note that some
selector strings begin with a copy
of the gopher type character, in
which case that character will occur
twice consecutively in the URL. If
the type character and selector are
omitted, the type defaults to "1".
Gopher links which refer to non-Gopher
protocols are represented directly
as URLs of the underlying access
method and are not represented as
Gopher URLs.
\subsection*{Mailto}This allows a URL to specify an RFC822
addr-spec mail address.  Note that
use of \% , for example as used in
forming a gatewayed mail address,
requires conversion to \%25 in a URL.\par 
This semantics may be considered
to be that the object referred to
by the mailto: URL is the set of
messages sent to or from that address.
There is no algorithm to retrieve
this set, but the SMTP protocol allows
messages to be added to it, and any
given user may be aware of a subset
of its members.
\subsection*{Telnet, rlogin, tn3270  }The use of URLs to represent interactive
sessions is a convenient extension
to their uses for objects.  This
allows access to information systems
which only provide an interactive
service, and no information server.
As information within the service
cannot be addressed individually
or, in general, automatically retrieved,
this is a less desirable, though
currently common, solution.
\subsection*{x500  }The mapping of x500 names onto URLs
is not defined here. A decision is
required as to whether "distinguished
names" or "user friendly names" (ufn),
or both, should be allowed. If any
punctuation conversions are needed
from the adopted x500 representation
(such as the use of slashes between
parts of a ufn) they must be defined.
This is a subject for study.
\subsection*{WHOIS  }This prefix describes the access
using the "whois++" scheme in the
process of definition. The host name
part is the same as for other IP
based schemes. The path part can
be either a whois handle for a whois
object, or it can be a valid whois
query string. This is a subject for
further study.
\subsection*{Network Management Database  }This is a subject for study.
\subsection*{Registration of naming schemes  }A new naming scheme may be introduced
by defining a mapping onto a conforming
URL syntax, using a new scheme identifier.
Experimental scheme identifiers may
be used by mutual agreement between
parties, and must start with the
characters "x-".  The scheme name
"urn:" is reserved for the work in
progress on a scheme for more persistent
names.  Therefore URNs (Names) and
URLs (Locators)  be distinguishable.
An object which is either a URL or
a URN is known as a URI (Identifier).\par 
It is proposed that the Internet
Assigned Numbers Authority (IANA)
perform the function of registration
of new schemes. Any submission of
a new URI scheme must include a definition
of an algorithm for the retrieval
of any object within that scheme.
The algorithm must take  the URI
and produce either a set of URL(s)
which will lead to the desired object,
or the object itself, in a well-defined
or determinable format.\par 
It is recommended that those proposing
a new scheme demonstrate its utility
and operability by the provision
of a gateway which will provide images
of objects in the new scheme for
clients using an existing protocol.
If the new scheme is not a locator
scheme, then the properties of names
in the new space should be clearly
defined.  It is likewise recommended
that, where a protocol allows for
retrieval by URI, that the client
software have provision for being
configured to use specific gateway
locators for indirect access through
new naming schemes.







\section*{BNF syntax}This is a BNF-like description of
the Uniform Resource Locator syntax.
A vertical  line "$|$"  indicates alternatives,
and \lbrack brackets\rbrack   indicate optional
parts.  Spaces are representated
by the word "space", and the vertical
line character by "vline".   Single
letters stand for single letters.
All words of more than one letter
below are entities described somewhere
in this description.  \par 
The current IETF URI working group
prefereence  is for the prefiexedurl
production. (Nov 1993. July 93: url).\par 
The "generic" production gives a
higher level parsing of the same
URLs as the other productions.  The
"national" and "punctuation" characters
fo not appear in any productions
and therefore may not appear in URLs.\par 
The "afsaddress" is left in as historical
note, but is not a url production
\begin{DL}{allow this much space}
\item[prefixedurl
] u r l : url
\item[fragmentaddress
] uri \lbrack  \# fragmentid
\rbrack   
\item[uri
] url $|$ generic
\item[ur l
] generic $|$ httpaddress $|$ ftpaddress
$|$ newsaddress $|$ nntpaddress $|$ prosperoaddress
$|$ telnetaddress  $|$ gopheraddress
$|$ waisaddress $|$ mailtoaddress 
\item[generic
] scheme :  path \lbrack  ? search
\rbrack   
\item[scheme
] ialpha  
\item[httpaddress
] h t t p :   / / hostport
\lbrack   / path \rbrack  \lbrack  ? search \rbrack   
\item[ftpaddress
] f t p : / / login / path
\item[afsaddress
] a f s : / / cellname /
path  
\item[newsaddress
] n e w s : groupart  
\item[nntpaddress
] n n t p : group /  digits
\item[mailtoaddress
] m a i l t o : : xalphas
@ hostname
\item[waisaddress
] waisindex $|$ waisdoc 
\item[waisindex
] w a i s : / / hostport
/ database \lbrack  ? search \rbrack   
\item[waisdoc
] w a i s : / / hostport /
database / wtype  / path
\item[groupart
] * $|$ group $|$ article  
\item[group
] ialpha \lbrack  . group \rbrack   
\item[article
] xalphas @ host  
\item[database
] xalphas  
\item[wtype
] xalphas  
\item[prosperoaddress
] prosperolink  
\item[prosperolink
] p r o s p e r o : /
/ hostport / hsoname \lbrack  \%  0 0 version
\lbrack  attributes \rbrack  \rbrack   
\item[hsoname
] path  
\item[version
] digits  
\item[attributes
] attribute \lbrack  attributes
\rbrack   
\item[attribute
] alphanums  
\item[telnetaddress
] t e l n e t : / / login
\item[gopheraddress
] g o p h e r : / / hostport
\lbrack / gtype  \lbrack  selector \rbrack  \rbrack  \lbrack  ? search
\rbrack   
\item[login
] \lbrack  user \lbrack  : password \rbrack  @ \rbrack  hostport
\item[hostport
] host \lbrack  : port \rbrack   
\item[host
] hostname $|$ hostnumber  
\item[cellname
] hostname  
\item[hostname
] ialpha \lbrack   .  hostname \rbrack 
\item[hostnumber
] digits . digits . digits
. digits
\item[port
] digits  
\item[selector
] path  
\item[path
] void $|$  xpalphas  \lbrack   / path
\rbrack   
\item[search
] xalphas \lbrack  + search \rbrack   
\item[user
] xalphas 
\item[password
] xalphas
\item[fragmentid
] xalphas  
\item[gtype
] xalpha  
\item[xalpha
] alpha $|$ digit $|$ safe $|$ extra
$|$ escape  
\item[xalphas
] xalpha \lbrack  xalphas \rbrack   
\item[xpalpha
] xalpha $|$ +  
\item[xpalphas
] xpalpha \lbrack  xpalpha \rbrack   
\item[ialpha
] alpha \lbrack  xalphas \rbrack 
\item[alpha
] a $|$ b $|$ c $|$ d $|$ e $|$ f $|$ g $|$
h $|$ i $|$ j $|$ k $|$ l $|$ m $|$ n $|$ o  $|$
p $|$ q $|$ r $|$ s $|$ t $|$ u $|$ v $|$ w $|$ x
$|$ y $|$ z $|$ A $|$ B $|$ C  $|$ D $|$ E $|$ F
$|$ G $|$ H $|$ I $|$ J $|$ K $|$ L $|$ M $|$ N $|$
O $|$ P $|$  Q $|$ R $|$ S $|$ T $|$ U $|$ V $|$
W $|$ X $|$ Y $|$ Z  
\item[
] 0 $|$1 $|$ 2 $|$ 3 $|$ 4 $|$ 5 $|$ 6 $|$ 7 $|$ 8
$|$ 9  
\item[safe
] \$ $|$ - $|$ \_ $|$ @ $|$ . $|$ \&  $|$ + $|$
-
\item[extra
] ! $|$ * $|$ " $|$  ' $|$ ( $|$ ) $|$ :
$|$ ; $|$ , $|$ space  
\item[escape
] \% hex hex  
\item[hex
] digit $|$ a $|$ b $|$ c $|$ d $|$ e $|$ f
$|$ A $|$ B $|$ C $|$ D $|$ E $|$ F  
\item[national
] \{ $|$ \} $|$ vline $|$ \lbrack  $|$ \rbrack  $|$
\char'134  $|$ {\char94} $|$ \~  
\item[punctuation
] $<$ $|$ $>$
\item[digits
] digit \lbrack  digits \rbrack   
\item[alphanum
] alpha $|$ digit  
\item[alphanums
] alphanum \lbrack  alphanums \rbrack 
\item[void
]
\end{DL}








\section*{Security considerations  }The URL scheme does not in itself
pose a security threat. Users should
beware that there is no general guarantee
that a URL which at one time points
to a given object continues to do
so, and does not even at some later
time point to a different object
due to the movement of objects on
servers.\par 
The use of URLs containing passwords
is clearly unwise.







\section*{Conclusion}A need has been demonstrated, and
a number of requirements have been
stated for uniform resource locators
(URLs). A scheme has been proposed
which builds on existing conventions
to define a syntax for URLs.  This
scheme has been in serious use by
World-Wide Web (W3) initiative since
1991.  Adoption of the scheme in
correspondence, standards and software
will ease the use of references to
on-line information in a flexible
way as the coming information age
arrives.







\section*{Acknowledgements  }This paper builds on the basic W3
design and much discussion of these
issues by many people on the network.
The discussion was particularly stimulated
by articles by Clifford Lynch (1991),
Brewster Kahle (1991) and Wengyik
Yeong (1991b). Contributions from
John Curran (NEARnet), Clifford Neuman
(ISI) Ed Vielmetti (MSEN) and later
the IETF URL BOF and URI working
group have been incorporated into
this issue of this paper.  \par 
The draft url4  (Internet Draft 00)
was generated from url3 following
discussion and overall approval of
the URL working group on 29 March
1993. The paper url3 had been generated
from udi2 in the light of discussion
at the UDI BOF meeting at the Boston
IETF in July 1992. Draft url4 was
Internet Draft 00. Draft url5 incorporated
changes suggested by Clifford Neuman,
and draft url6 (ID 01) incorporated
character group changes and a few
other fixes defined by the IETF URI
WG in submitting it as a proposed
standard.  URL7 (Internet Draft 02)
incorporated changes introduced at
the Amsterdam IETF and refined in
net discussion.







\chapter{Appendices}The following are not formally part
of this document.







\section{Fragment-id  }This represents a part of, fragment
of, or a sub-function within, an
object or object. Its syntax and
semantics are defined by the application
responsible for the object, or the
specification of the content type
of the object. The only definition
here is of the allowed characters
by which it may be represented in
a URL.  \par 
The fragment-id follows the URL of
the whole object from which it is
separated by a hash sign (\#).  If
the fragment-id is void, the hash
sign may be omitted: A void fragment-id
with or without the hash sign means
that the URL refers to the whole
object.\par 
While this hook is allowed for identification
of fragments, the question of addressing
of parts of objects, or of the grouping
of objects and relationship between
contined and containing objects,
is not addressed by this object.\par 
This object does not address the
question of objects which are different
versions of a "living" object, nor
of expressing the relationships between
different versions and the living
object.







\section{Partial form  }In a certain limited set of cases,
generally within a certain application,
it may be useful to pass only a section
of the URL. Within a object whose
URL is well defined, the URL of another
object may be given in abbreviated
form, where parts of the two URLs
are the same. This allows objects
within a group to refer to each other
without requiring the space for a
complete reference, and it incidentally
allows the group of objects  to be
moved without changing any references.
This is not discussed in detail here,
it is only mentioned so that the
characters required by the technique
be reserved for that purpose.  It
must be emphasised that when a reference
is passed in anything other than
a well controlled context, the full
form must always be used.  \par 
The partial form relies on a property
of the URL syntax that certain characters
("/") and certain path elements ("..",
".") have a significance reserved
for representing a hierarchical space,
and must be recognised as such by
both clients and servers.  \par 
A partial form can be distinguished
from a full form in that a full form
must have a colon and that colon
must occur before any slash characters.\par 
The rules for the use of a partial
name are:  
\begin{itemize}
\item If the scheme parts  are different,
the whole absolute locator must be
given. Otherwise, the scheme is omitted,
and:
\item If the host and/or port parts are
the different, the host, port name
and all the rest of the locator must
be given.
\item If the access and host parts are
the same, then the path may be given
in absolute (fully qualified) or
relative form. Within the path:
\item If a leading slash is present, the
path is absolute. Otherwise, a relative
path is interpreted as follows: 
\item The last part of the path of the
context locator (anything following
the rightmost slash) is removed,
and the given partial URL appended
in its place.
\item Within the result,  all occurrences
of "xxx/../"  or "/." are recursively
removed, where xxx, ".." and "."
are complete path elements.
\end{itemize}Note:  If a path of the context locator
end in slash, partial URLs will be
treated differently to their treatment
with respect to the same path without
a slash.   Using a trailing slash
on a directory name is not therefore
recommended.  The signifcance of
a trailing slash may be considered
as that of the locator of a file
with void name within that  directory.







\section{Wrappers for URIs in plain text}This section does not formally form
part of the URL specification.\par 
URIs, including URLs, will ideally
be transmitted though protocols which
accept them and data formats which
define a context for them.  However,
in practice nowadays there are many
occasions when URLs are included
in plain ASCII non-marked-up text
such as electronic mail and usenet
news messages.\par 
In this case, it is convenient to
have a separate wrapper syntax to
define delimiters which will enable
the human or automated reader to
recognize that the URI is a URI.\par 
The recommendation is that the angle
brackets (less than and greater than
signs) of the ASCII set be used for
this purpose.\par 
These wrappers do not form part of
the URL, are not mandatory, and should
not be used in contexts (such as
SGML parameters, HTTP requests, etc)
in which delimiters are already specified.
\subsubsection{Example}
\begin{verbatim}		Yes, Jim, I found it under <ftp://info.cern.ch/pub> but
		you can probably pick it up from <ftp://ds.internic.net/rfc>.


\end{verbatim}








\chapter{References}
\begin{DL}{allow this much space}
\item[Alberti, R., et.al.  (1991)
] "Notes
on the Internet Gopher  Protocol"
University of Minnesota, December
1991,  $<$ftp://boombox.micro.umn.edu/pub/gopher/gopher\_protocol$>$
. See also  $<$gopher://gopher.micro.umn.edu/00/Information
About Gopher/About Gopher$>$
\item[Berners-Lee, T ., (1991)
] "Hypertext
Transfer Protocol (HTTP)" , CERN,
December 1991,  $<$ftp://info.cern.ch/pub/www/doc/http-spec.txt$>$
\item[Crocker 
]"Standard for ARPA Internet
Text Messages" . David H. Crocker,
RFC822, 
\item[Davis, F, et  al., (1990)
] "WAIS Interface
Protocol: Prototype  Functional Specification",
Thinking Machines Corporation,  April
23, 1990  $<$ftp://quake.think.com/pub/wais/doc/protspec.txt$>$
\item[International Standards Organization,
(1991)
] Information and  Documentation
- Search and Retrieve Application
Protocol  Specification for open
Systems Interconnection, ISO-10163
\item[Huitema, C., (1991)
] "Naming: strategies
and techniques",  Computer Networks
and ISDN Systems 23 (1991) 107-110.
\item[Kahle, Brewster, (1991) 
]"Document
Identifiers,  or  International Standard
Book Numbers for the Electronic Age",
$<$ftp://quake.think.com/pub/wais/doc/doc-ids.txt$>$
\item[Kantor, B., and Lapsley, P., (1986)
]
"A proposed standard for  the stream-based
transmission of news", Internet RFC-977,
February 1986. $<$ftp://ds.internic.net/rfc/rfc977.txt$>$
\item[Lynch, C., Coallition for Networked
Information: (1991)  
]"Workshop on
ID and Reference Structures for Networked
Information", November 1991. See
$<$wais://quake.think.com/wais-discussion-archives?lynch$>$
\item[Mockapetris, P., (1987)
] "Domain names
+ concepts and  facilities", RFC-1034,
USC-ISI, November 1987,  $<$ftp://ds.internic.net/rfc/rfc1034.txt$>$
\item[Neuman, B. Clifford, (1992)
] "Prospero:
A Tool for Organizing  Internet Resources",
Electronic Networking: Research,
Applications and Policy, Vol 1 No
2, Meckler Westport CT  USA.  See
also  $<$ftp://prospero.isi.edu/pub/prospero/oir.ps$>$
\item[Postel, J. and Reynolds, J. (1985)
]
"File Transfer Protocol  (FTP)",
Internet RFC-959, October 1985. $<$ftp://ds.internic.net/rfc/rfc959.txt$>$
\item[Yeong, W., (1991a)
] "Towards Networked
Information Retrieval",  Technical
report 91-06-25-01, June 1991, Performance
Systems International, Inc.  $<$ftp://uu.psi.com/wp/nir.txt$>$
\item[Yeong, W., (1991b),
] "Representing
Public Archives in the  Directory",
Internet Draft, November 1991, now
expired.
\end{DL}

\section{Author's address  }
\begin{verbatim}
			   Tim Berners-Lee  
		Address:   World-Wide Web project  
			   CERN,
			   1211 Geneva 23,
		           Switzerland
 
	    	Telephone: +41 (22)767 3755
		Fax:       +41 (22)767 7155 
		Email:     timbl@info.cern.ch

\end{verbatim}


\end{document}
