Network Working Group T. Berners-Lee
`Request for Comments: 1630 CERN
`Category: Informational June 1994
`
` Universal Resource Identifiers in WWW
`
` A Unifying Syntax for the Expression of
` Names and Addresses of Objects on the Network
` as used in the World-Wide Web
`
`Status of this Memo
`
` This memo provides information for the Internet community. This memo
` does not specify an Internet standard of any kind. Distribution of
` this memo is unlimited.
`
`IESG Note:
`
` Note that the work contained in this memo does not describe an
` Internet standard. An Internet standard for general Resource
` Identifiers is under development within the IETF.
`
`Introduction
`
` This document defines the syntax used by the World-Wide Web
` initiative to encode the names and addresses of objects on the
` Internet. The web is considered to include objects accessed using an
` extendable number of protocols, existing, invented for the web
` itself, or to be invented in the future. Access instructions for an
` individual object under a given protocol are encoded into forms of
` address string. Other protocols allow the use of object names of
` various forms. In order to abstract the idea of a generic object,
` the web needs the concepts of the universal set of objects, and of
` the universal set of names or addresses of objects.
`
` A Universal Resource Identifier (URI) is a member of this universal
` set of names in registered name spaces and addresses referring to
` registered protocols or name spaces. A Uniform Resource Locator
` (URL), defined elsewhere, is a form of URI which expresses an address
` which maps onto an access algorithm using network protocols. Existing
` URI schemes which correspond to the (still mutating) concept of IETF
` URLs are listed here. The Uniform Resource Name (URN) debate attempts
` to define a name space (and presumably resolution protocols) for
` persistent object names. This area is not addressed by this document,
` which is written in order to document existing practice and provide a
` reference point for URL and URN discussions.
`
`Berners-Lee [Page 1]
`
`APPLE 1011 - Page 1
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` The world-wide web protocols are discussed on the mailing list www-
` talk-request@info.cern.ch and the newsgroup comp.infosystems.www is
` preferable for beginner’s questions. The mailing list uri-
` request@bunyip.com has discussion related particularly to the URI
` issue. The author may be contacted as timbl@info.cern.ch.
`
` This document is available in hypertext form at:
`
` http://info.cern.ch/hypertext/WWW/Addressing/URL/URI_Overview.html
`
`The Need For a Universal Syntax
`
` This section describes the concept of the URI and does not form part
` of the specification.
`
` 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.
`
` 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.
`
` 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.
`
` Practical systems need to access and mix objects which are part of
` different existing and proposed systems. Therefore, the concept of
` the universal set of all objects, and hence the universal set of
` names and addresses, in all name spaces, becomes important. This
` allows 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.
`
`Berners-Lee [Page 2]
`
`APPLE 1011 - Page 2
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` URIs
`
` This document defines a way to encapsulate a name in any
` registered name space, and label it with the the name space,
` producing a member of the universal set. Such an encoded and
` labelled member of this set is known as a Universal Resource
` Identifier, or URI.
`
` The universal syntax allows access of objects available using
` existing protocols, and may be extended with technology.
`
` The specification of the URI syntax does not imply anything about
` the properties of names and addresses in the various name spaces
` which are mapped onto the set of URI strings. The properties
` follow from the specifications of the protocols and the associated
` usage conventions for each scheme.
`
` URLs
`
` For existing Internet access protocols, it is necessary in most
` cases to define the encoding of the access algorithm into
` something concise enough to be termed address. URIs which refer
` to objects accessed with existing protocols are known as "Uniform
` Resource Locators" (URLs) and are listed here as used in WWW, but
` to be formally defined in a separate document.
`
` URNs
`
` There is currently a drive to define a space of more persistent
` names than any URLs. These "Uniform Resource Names" are the
` subject of an IETF working group’s discussions. (See Sollins and
` Masinter, Functional Specifications for URNs, circulated
` informally.)
`
` The URI syntax and URL forms have been in widespread use by
` World-Wide Web software since 1990.
`
`Berners-Lee [Page 3]
`
`APPLE 1011 - Page 3
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
`Design Criteria and Choices
`
` This section is not part of the specification: it is simply an
` explanation of the way in which the specification was derived.
`
` Design criteria
`
` The syntax was designed to be:
`
` Extensible New naming schemes may be added later.
`
` Complete It is possible to encode any naming
` scheme.
`
` Printable It is possible to express any URI using
` 7-bit ASCII characters so that URIs may,
` if necessary, be passed using pen and ink.
`
` Choices for a universal syntax
`
` For the syntax itself there is little choice except for the order
` and punctuation of the elements, and the acceptable characters and
` escaping rules.
`
` The extensibility requirement is met by allowing an arbitrary (but
` registered) string to be used as a prefix. A prefix is chosen as
` left to right parsing is more common than right to left. The
` choice of a colon as separator of the prefix from the rest of the
` URI was arbitrary.
`
` The decoding of the rest of the string is defined as a function of
` the prefix. New prefixed are introduced for new schemes as
` necessary, in agreement with the registration authority. The
` registration of a new scheme clearly requires the definition of
` the decoding of the URI into a given name space, and a definition
` of the properties and, where applicable, resolution protocols, for
` the name space.
`
` The completeness requirement is easily met by allowing
` particularly strange or plain binary names to be encoded in base
` 16 or 64 using the acceptable characters.
`
` The printability requirement could have been met by requiring all
` schemes to encode characters not part of a basic set. This led to
` many discussions of what the basic set should be. A difficult
` case, for example, is when an ISO latin 1 string appears in a URL,
` and within an application with ISO Latin-1 capability, it can be
` handled intact. However, for transport in general, the non-ASCII
`
`Berners-Lee [Page 4]
`
`APPLE 1011 - Page 4
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` characters need to be escaped.
`
` The solution to this was to specify a safe set of characters, and
` a general escaping scheme which may be used for encoding "unsafe"
` characters. This "safe" set is suitable, for example, for use in
` electronic mail. This is the canonical form of a URI.
`
` 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 "\". 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. It is also a
` character which is not available on certain keyboards. The equals
` sign is commonly used in the encoding of names having
` attribute=value pairs. The percent sign was eventually chosen as
` a suitable escape character.
`
` There is a conflict between the need to be able to represent many
` characters including spaces within a URI directly, and the need to
` be able to use a URI 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.
`
` The use of white space characters is risky in URIs to be printed
` or sent by electronic mail, and the use of multiple white space
` characters is very risky. 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. This is why the canonical
` form for URIs has all white spaces encoded.
`
`Reommendations
`
` This section describes the syntax for URIs as used in the WorldWide
` Web initiative. The generic syntax provides a framework for new
` schemes for names to be resolved using as yet undefined protocols.
`
`URI syntax
`
` A complete URI 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
`
`Berners-Lee [Page 5]
`
`APPLE 1011 - Page 5
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` address part. A BNF description of the URL syntax is given in an a
` later section. The components are as follows. Fragment identifiers
` and relative URIs are not involved in the basic URL definition.
`
` SCHEME
`
` Within the URI of a object, the first element is the name of the
` scheme, separated from the rest of the object by a colon.
`
` PATH
`
` The rest of the URI follows the colon in a format depending on the
` scheme. The path is interpreted in a manner dependent on the
` protocol being used. However, when it contains slashes, these
` must imply a hierarchical structure.
`
`Reserved characters
`
` The path in the URI has a significance defined by the particular
` scheme. Typically, it is used to encode a name in a given name
` space, or an algorithm for accessing an object. In either case, the
` encoding may use those characters allowed by the BNF syntax, or
` hexadecimal encoding of other characters.
`
` Some of the reserved characters have special uses as defined here.
`
` THE PERCENT SIGN
`
` The percent sign ("%", ASCII 25 hex) is used as the escape
` character in the encoding scheme and is never allowed for anything
` else.
`
` HIERARCHICAL FORMS
`
` The slash ("/", ASCII 2F hex) character is reserved for the
` delimiting of substrings whose relationship is hierarchical. This
` enables partial forms of the URI. Substrings consisting of single
` or double dots ("." or "..") are similarly reserved.
`
` The significance of the slash between two segments is that the
` segment of the path to the left is more significant than the
` segment of the path to the right. ("Significance" in this case
` refers solely to closeness to the root of the hierarchical
` structure and makes no value judgement!)
`
`Berners-Lee [Page 6]
`
`APPLE 1011 - Page 6
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` Note
`
` The similarity to unix and other disk operating system filename
` conventions should be taken as purely coincidental, and should
` not be taken to indicate that URIs should be interpreted as
` file names.
`
` HASH FOR FRAGMENT IDENTIFIERS
`
` The hash ("#", ASCII 23 hex) character is reserved as a delimiter
` to separate the URI of an object from a fragment identifier .
`
` QUERY STRINGS
`
` The question mark ("?", ASCII 3F hex) is used to delimit the
` boundary between the URI of a queryable object, and a set of words
` used to express a query on that object. When this form is used,
` the combined URI stands for the object which results from the
` query being applied to the original object.
`
` Within the query string, the plus sign is reserved as shorthand
` notation for a space. Therefore, real plus signs must be encoded.
` This method was used to make query URIs easier to pass in systems
` which did not allow spaces.
`
` The query string represents some operation applied to the object,
` but this specification gives no common syntax or semantics for it.
` In practice the syntax and sematics may depend on the scheme and
` may even on the base URI.
`
` OTHER RESERVED CHARACTERS
`
` The astersik ("*", ASCII 2A hex) and exclamation mark ("!" , ASCII
` 21 hex) are reserved for use as having special signifiance within
` specific schemes.
`
`Unsafe characters
`
` In canonical form, certain characters such as spaces, control
` characters, some characters whose ASCII code is used differently in
` different national character variant 7 bit sets, and all 8bit
` characters beyond DEL (7F hex) of the ISO Latin-1 set, shall not be
` used unencoded. This is a recommendation for trouble-free
` interchange, and as indicated below, the encoded set may be extended
` or reduced.
`
`Berners-Lee [Page 7]
`
`APPLE 1011 - Page 7
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
`Encoding reserved characters
`
` When a system uses a local addressing scheme, it is useful to provide
` a mapping from local addresses into URIs so that references to
` objects within the addressing scheme may be referred to globally, and
` possibly accessed through gateway servers.
`
` For a new naming scheme, any mapping scheme may be defined provided
` it is unambiguous, reversible, and provides valid URIs. 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.
`
` It is also recommended that the conventional scheme below be used in
` all cases except for any scheme which encodes binary data as opposed
` to text, in which case a more compact encoding such as pure
` hexadecimal or base 64 might be more appropriate. For example, the
` conventional URI encoding method is used for mapping WAIS, FTP,
` Prospero and Gopher addresses in the URI specification.
`
` CONVENTIONAL URI ENCODING SCHEME
`
` Where the local naming scheme uses ASCII characters which are not
` allowed in the URI, these may be represented in the URL by a
` percent sign "%" immediately 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 unencoded in a URI.
`
` REDUCED OR INCREASED SAFE CHARACTER SETS
`
` The same encoding method may be used for encoding characters whose
` use, although technically allowed in a URI, 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. Because a % sign always indicates
` an encoded character, a URI may be made "safer" simply by encoding
` any characters considered unsafe, while leaving already encoded
` characters still encoded. Similarly, in cases where a larger set
` of characters is acceptable, % signs can be selectively and
` reversibly expanded.
`
` Before two URIs can be compared, it is therefore necessary to
` bring them to the same encoding level.
`
` However, the reserved characters mentioned above have a quite
` different significance when encoded, and so may NEVER be encoded
` and unencoded in this way.
`
`Berners-Lee [Page 8]
`
`APPLE 1011 - Page 8
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` The percent sign intended as such must always be encoded, as its
` presence otherwise always indicates an encoding. Sequences which
` start with a percent sign but are not followed by two hexadecimal
` characters are reserved for future extension. (See Example 3.)
`
` Example 1
`
` The URIs
`
` http://info.cern.ch/albert/bertram/marie-claude
`
` and
`
` http://info.cern.ch/albert/bertram/marie%2Dclaude
`
` are identical, as the %2D encodes a hyphen character.
`
` Example 2
`
` The URIs
`
` http://info.cern.ch/albert/bertram/marie-claude
`
` and
`
` http://info.cern.ch/albert/bertram%2Fmarie-claude
`
` are NOT identical, as in the second case the encoded slash does not
` have hierarchical significance.
`
` Example 3
`
` The URIs
`
` fxqn:/us/va/reston/cnri/ietf/24/asdf%*.fred
`
` and
`
` news:12345667123%asdghfh@info.cern.ch
`
` are illegal, as all % characters imply encodings, and there is no
` decoding defined for "%*" or "%as" in this recommendation.
`
`Partial (relative) form
`
` Within a object whose URI is well defined, the URI of another object
` may be given in abbreviated form, where parts of the two URIs are the
` same. This allows objects within a group to refer to each other
`
`Berners-Lee [Page 9]
`
`APPLE 1011 - Page 9
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` without requiring the space for a complete reference, and it
` incidentally allows the group of objects to be moved without changing
` any references. It must be emphasized that when a reference is
` passed in anything other than a well controlled context, the full
` form must always be used.
`
` In the World-Wide Web applications, the context URI is that of the
` document or object containing a reference. In this case partial URIs
` can be generated in virtual objects or stored in real objects,
` without the need for dramatic change if the higher-order parts of a
` hierarchical naming system are modified. Apart from terseness, this
` gives greater robustness to practical systems, by enabling
` information hiding between system components.
`
` The partial form relies on a property of the URI syntax that certain
` characters ("/") and certain path elements ("..", ".") have a
` significance reserved for representing a hierarchical space, and must
` be recognized as such by both clients and servers.
`
` A partial form can be distinguished from an absolute form in that the
` latter must have a colon and that colon must occur before any slash
` characters. Systems not requiring partial forms should not use any
` unencoded slashes in their naming schemes. If they do, absolute URIs
` will still work, but confusion may result. (See note on Gopher
` below.)
`
` The rules for the use of a partial name relative to the URI of the
` context are:
`
` If the scheme parts are different, the whole absolute URI must
` be given. Otherwise, the scheme is omitted, and:
`
` If the partial URI starts with a non-zero number of consecutive
` slashes, then everything from the context URI up to (but not
` including) the first occurrence of exactly the same number of
` consecutive slashes which has no greater number of consecutive
` slashes anywhere to the right of it is taken to be the same and
` so prepended to the partial URL to form the full URL. Otherwise:
`
` The last part of the path of the context URI (anything following
` the rightmost slash) is removed, and the given partial URI
` appended in its place, and then:
`
` Within the result, all occurrences of "xxx/../" or "/." are
` recursively removed, where xxx, ".." and "." are complete path
` elements.
`
`Berners-Lee [Page 10]
`
`APPLE 1011 - Page 10
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` Note: Trailing slashes
`
` If a path of the context locator ends in slash, partial URIs are
` treated differently to the URI with the same path but without a
` trailing slash. The trailing slash indicates a void segment of the
` path.
`
` Note: Gopher
`
` The gopher system does not have the concept of relative URIs, and the
` gopher community currently allows / as data characters in gopher URIs
` without escaping them to %2F. Relative forms may not in general be
` used for documents served by gopher servers. If they are used, then
` WWW software assumes, normally correctly, that in fact they do have
` hierarchical significance despite the specifications. The use of HTTP
` rather than gopher protocol is however recommended.
`
` Examples
`
` In the context of URI
`
` magic://a/b/c//d/e/f
`
` the partial URIs would expand as follows:
`
` g magic://a/b/c//d/e/g
`
` /g magic://a/g
`
` //g magic://g
`
` ../g magic://a/b/c//d/g
`
` g:h g:h
`
` and in the context of the URI
`
` magic://a/b/c//d/e/
`
` the results would be exactly the same.
`
`Fragment-id
`
` This represents a part of, fragment of, or a sub-function within, an
` 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.
`
`Berners-Lee [Page 11]
`
`APPLE 1011 - Page 11
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` Specific syntaxes for representing fragments in text documents by
` line and character range, or in graphics by coordinates, or in
` structured documents using ladders, are suitable for standardization
` but not defined here.
`
` 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.
`
` 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 continued and containing objects, is
` not addressed by this document.
`
` Fragment identifiers do 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.
`
` There is no implication that a fragment identifier refers to anything
` which can be extracted as an object in its own right. It may, for
` example, refer to an indivisible point within an object.
`
`Specific Schemes
`
` The mapping for URIs onto some existing standard and experimental
` protocols is outlined in the BNF syntax definition. Notes on
` particular protocols follow. These URIs are frequently referred to
` as URLs, though the exact definition of the term URL is still under
` discussion (March 1993). The schemes covered are:
`
` http Hypertext Transfer Protocol (examples)
`
` ftp File Transfer protocol
`
` gopher Gopher protocol
`
` mailto Electronic mail address
`
` news Usenet news
`
` telnet, rlogin and tn3270
` Reference to interactive sessions
`
` wais Wide Area Information Servers
`
` file Local file access
`
`Berners-Lee [Page 12]
`
`APPLE 1011 - Page 12
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` The following schemes are proposed as essential to the unification of
` the web with electronic mail, but not currently (to the author’s
` knowledge) implemented:
`
` mid Message identifiers for electronic mail
`
` cid Content identifiers for MIME body part
`
` The schemes for X.500, network management database, and Whois++ have
` not been specified and may be the subject of further study. Schemes
` for Prospero, and restricted NNTP use are not currently implemented
` as far as the author is aware.
`
` The "urn" prefix is reserved for use in encoding a Uniform Resource
` Name when that has been developed by the IETF working group.
`
` New schemes may be registered at a later time.
`
`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 host details are not passed on to the client when the URL is an
` HTTP URL which refers to the server in question. In this case the
` string sent starts with the slash which follows the host details.
` However, when an HTTP server is being used as a gateway (or "proxy")
` then the entire URI, whether HTTP or some other scheme, is passed on
` the HTTP command line. The search part, if present, is sent as part
` of the HTTP command, and may in this respect be treated as part of
` the path. No fragmentid part of a WWW URI (the hash sign and
` following) is sent with the request. Spaces and control characters
` in URLs must be escaped for transmission in HTTP, as must other
` disallowed characters.
`
` EXAMPLES
`
` These examples are not part of the specification: they are
` provided as illustations only. The URI of the "welcome" page to a
` server is conventionally
`
` http://www.my.work.com/
`
` As the rest of the URL (after the hostname an port) is opaque
` to the client, it shows great variety but the following are all
` fairly typical.
`
`Berners-Lee [Page 13]
`
`APPLE 1011 - Page 13
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
`http://www.my.uni.edu/info/matriculation/enroling.html
`
`http://info.my.org/AboutUs/Phonebook
`
`http://www.library.my.town.va.us/Catalogue/76523471236%2Fwen44--4.98
`
`http://www.my.org/462F4F2D4241522A314159265358979323846
`
` A URL for a server on a different port to 80 looks like
`
` http://info.cern.ch:8000/imaginary/test
`
` A reference to a particular part of a document may, including the
` fragment identifier, look like
`
` http://www.myu.edu/org/admin/people#andy
`
` in which case the string "#andy" is not sent to the server, but is
` retained by the client and used when the whole object had been
` retrieved.
`
` A search on a text database might look like
`
` http://info.my.org/AboutUs/Index/Phonebook?dobbins
`
` and on another database
`
` http://info.cern.ch/RDB/EMP?*%20where%20name%%3Ddobbins
`
` In all cases the client passes the path string to the server
` uninterpreted, and for the client to deduce anything from
`
`FTP
`
` The ftp: prefix indicates that the FTP protocol is used, as defined
` in STD 9, RFC 959 or any successor. The port number, if present,
` gives the port of the FTP server if not the FTP default.
`
` User name and password
`
` 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 Internet-style mail
` address.
`
`Berners-Lee [Page 14]
`
`APPLE 1011 - Page 14
`
`

`
`
`RFC 1630 URIs in WWW June 1994
`
` Where possible, this mail address should correspond to a usable
` mail address for the user, and preferably give a DNS host name
` which resolves to the IP address of the client. Note that servers
` currently vary in their treatment of the anonymous password.
`
` Path
`
` The FTP protocol allows for a sequence of CWD commands (change
` working directory) and a TYPE command prior to service commands
` such as RETR (retrieve) or NLIST (etc.) which actually access a
` file.
`
` The arguments of any CWD commands are successive segment parts of
` the URL delimited by slash, and the final segment is suitable as
` the filename argument to the RETR command for retrieval or the
` directory argument to NLIST.
`
` For some file systems (Unix in particular), the "/" used to denote
` the hierarchical structure of the URL corresponds to the delimiter
` used to construct a file name hierarchy, and thus, the filename
` will look the same as the URL path. This does NOT mean that the
` URL is a Unix filename.
`
` Note: Retrieving subsequent URLs from the same host
`
` There is no common hierarchical model to the FTP protocol, so if a
` directory change command has been given, it is impossible in
` general to deduce what sequence should be given to navigate to
` another directory for a second retrieval, if the paths are
` different. The only reliable algorithm is to disconnect and
` reestablish the control connection.
`
` Data type
`
` The data content type 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. A suitable FTP transfer type (for
` example binary "I" or text "A") must in turn be deduced from the
` data content type. It is recommended that conventions for
` suffixes of public archives be established, but it is outside the
` scope of this standard.
`
` An FTP URL may optionally specify the FTP data transfer type by
` which an object is to be retrieved. Most of the methods correspond
` to the FTP "Data Types" ASCII and IMAGE for the retrieval of a
` document, as specified in FTP by the TYPE command. One method
` indicates directory access.
`
`Berners-Lee [Pa