9/12/2016
`
`https://www.ietf.org/rfc/rfc1738.bct
`
`Network Working Group
`Request for Comments: 1738
`Category: Standards Track
`
`T. Berners-Lee
`CERN
`L. Masinter
`Xerox Corporation
`M. Mccahill
`University of Minnesota
`Editors
`December 1994
`
`Uniform Resource Locators (URL)
`
`Status of this Memo
`
`This document specifies an Internet standards track protocol for the
`Internet community, and requests discussion and suggestions for
`improvements. Please refer to the current edition of the "Internet
`Official Protocol Standards" (STD 1) for the standardization state
`and status of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
`This document specifies a Uniform Resource Locator (URL), the syntax
`and semantics of formalized information for location and access of
`resources via the Internet.
`
`1. Introduction
`
`This document describes the syntax and semantics for a compact string
`representation for a resource available via the Internet. These
`strings are called "Uniform Resource Locators" (URLs).
`
`The specification is derived from concepts introduced by the World(cid:173)
`Wide Web global information initiative, whose use of such objects
`dates from 1990 and is described in "Universal Resource Identifiers
`in WWW", RFC 1630. The specification of URLs is designed to meet the
`requirements laid out in "Functional Requirements for Internet
`Resource Locators" [12].
`
`This document was written by the URI working group of the Internet
`Engineering Task Force. Comments may be addressed to the editors, or
`to the URI-WG <uri@bunyip.com>. Discussions of the group are archived
`at <URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html>
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 1]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`2. General URL Syntax
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`1/22
`
`Netflix 1037 - Page 1
`
`

`
`https://www.ietf.org/rfc/rfc1738.bct
`9/12/2016
`Just as there are many different methods of access to resources,
`there are several schemes for describing the location of such
`resources.
`
`The generic syntax for URLs provides a framework for new schemes to
`be established using protocols other than those defined in this
`document.
`
`URLs are used to 'locate' resources, by providing an abstract
`identification of the resource location. Having located a resource,
`a system may perform a variety of operations on the resource, as
`might be characterized by such words as ·access', 'update',
`'replace', 'find attributes'. In general, only the ·access' method
`needs to be specified for any URL scheme.
`
`2.1. The main parts of URLs
`
`A full BNF description of the URL syntax is given in Section 5.
`
`In general, URLs are written as follows:
`
`<scheme>:<scheme-specific-part>
`
`A URL contains the name of the scheme being used (<scheme>) followed
`by a colon and then a string {the <scheme-specific-part>) whose
`interpretation depends on the scheme.
`
`Scheme names consist of a sequence of characters. The lower case
`letters "a"--"z", digits, and the characters plus("+"), period
`(","), and hyphen("-") are allowed. For resiliency, programs
`interpreting URLs should treat upper case letters as equivalent to
`lower case in scheme names (e.g., allow "HTTP" as well as "http").
`
`2.2. URL Character Encoding Issues
`
`URLs are sequences of characters, i.e., letters, digits, and special
`characters. A URLs may be represented in a variety of ways: e.g., ink
`on paper, or a sequence of octets in a coded character set. The
`interpretation of a URL depends only on the identity of the
`characters used.
`
`In most URL schemes, the sequences of characters in different parts
`of a URL are used to represent sequences of octets used in Internet
`protocols. For example, in the ftp scheme, the host name, directory
`name and file names are such sequences of octets, represented by
`parts of the URL. Within those parts, an octet may be represented by
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 2]
`
`RFC 1738
`
`Uniform Resource Locators {URL)
`
`December 1994
`
`the chararacter which has that octet as its code within the US-ASCII
`[20] coded character set.
`
`In addition, octets may be encoded by a character triplet consisting
`of the character"%" followed by the two hexadecimal digits (from
`"0123456789ABCDEF") which forming the hexadecimal value of the octet.
`(The characters "abcdef" may also be used in hexadecimal encodings.)
`
`Octets must be encoded if they have no corresponding graphic
`character within the US-ASCII coded character set, if the use of the
`corresponding character is unsafe, or if the corresponding character
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`2122.
`
`Netflix 1037 - Page 2
`
`

`
`https://www.ietf.org/rfc/rfc1738.bct
`9/12/2016
`is reserved for some other interpretation within the particular URL
`scheme.
`
`No corresponding graphic US-ASCII:
`
`URLs are written only with the graphic printable characters of the
`US-ASCII coded character set. The octets 80-FF hexadecimal are not
`used in US-ASCII, and the octets 00-lF and 7F hexadecimal represent
`control characters; these must be encoded.
`
`Unsafe:
`
`Characters can be unsafe for a number of reasons. The space
`character is unsafe because significant spaces may disappear and
`insignificant spaces may be introduced when URLs are transcribed or
`typeset or subjected to the treatment of word-processing programs.
`The characters"<" and">" are unsafe because they are used as the
`delimiters around URLs in free text; the quote mark(""") is used to
`delimit URLs in some systems. The character"#" is unsafe and should
`always be encoded because it is used in World Wide Web and in other
`systems to delimit a URL from a fragment/anchor identifier that might
`follow it. The character"%" is unsafe because it is used for
`encodings of other characters. Other characters are unsafe because
`gateways and other transport agents are known to sometimes modify
`such characters. These characters are"{", "}", "I", "\", "A", "-",
`''['', '']'', and'''''.
`
`All unsafe characters must always be encoded within a URL. For
`example, the character"#" must be encoded within URLs even in
`systems that do not normally deal with fragment or anchor
`identifiers, so that if the URL is copied into another system that
`does use them, it will not be necessary to change the URL encoding.
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 3]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`Reserved:
`
`Many URL schemes reserve certain characters for a special meaning:
`their appearance in the scheme-specific part of the URL has a
`designated semantics. If the character corresponding to an octet is
`reserved in a scheme, the octet must be encoded. The characters";",
`"/", "?", ":", "@", "="and"&" are the characters which may be
`reserved for special meaning within a scheme. No other characters may
`be reserved within a scheme.
`
`Usually a URL has the same interpretation when an octet is
`represented by a character and when it encoded. However, this is not
`true for reserved characters: encoding a character reserved for a
`particular scheme may change the semantics of a URL.
`
`Thus, only alphanumerics, the special characters"$-_.+!*'(),", and
`reserved characters used for their reserved purposes may be used
`unencoded within a URL.
`
`On the other hand, characters that are not required to be encoded
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`Netflix 1037 - Page 3
`
`

`
`https://www.ietf.org/rfc/rfc1738.bct
`9/12/2016
`(including alphanumerics) may be encoded within the scheme-specific
`part of a URL, as long as they are not being used for a reserved
`purpose.
`
`2.3 Hierarchical schemes and relative links
`
`In some cases, URLs are used to locate resources that contain
`pointers to other resources. In some cases, those pointers are
`represented as relative links where the expression of the location of
`the second resource is in terms of "in the same place as this one
`except with the following relative path". Relative links are not
`described in this document. However, the use of relative links
`depends on the original URL containing a hierarchical structure
`against which the relative link is based.
`
`Some URL schemes (such as the ftp, http, and file schemes) contain
`names that can be considered hierarchical; the components of the
`hierarchy are separated by"/".
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 4]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`3. Specific Schemes
`
`The mapping for some existing standard and experimental protocols is
`outlined in the BNF syntax definition. Notes on particular protocols
`follow. The schemes covered are:
`
`ftp
`http
`gopher
`mailto
`news
`nntp
`telnet
`wais
`file
`prospero
`
`File Transfer protocol
`Hypertext Transfer Protocol
`The Gopher protocol
`Electronic mail address
`USENET news
`USENET news using NNTP access
`Reference to interactive sessions
`Wide Area Information Servers
`Host-specific file names
`Prospero Directory Service
`
`Other schemes may be specified by future specifications. Section 4 of
`this document describes how new schemes may be registered, and lists
`some scheme names that are under development.
`
`3.1. Common Internet Scheme Syntax
`
`While the syntax for the rest of the URL may vary depending on the
`particular scheme selected, URL schemes that involve the direct use
`of an IP-based protocol to a specified host on the Internet use a
`common syntax for the scheme-specific data:
`
`//<user>:<password>@<host>:<port>/<url-path>
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`4122
`
`Netflix 1037 - Page 4
`
`

`
`9/12/2016
`
`https://www.ietf.org/rfc/rfc1738.bct
`
`Some or all of the parts "<user>:<password>@", ":<password>",
`":<port>", and "/<url-path>" may be excluded. The scheme specific
`data start with a double slash"//" to indicate that it complies with
`the common Internet scheme syntax. The different components obey the
`following rules:
`
`user
`An optional user name. Some schemes (e.g., ftp) allow the
`specification of a user name.
`
`password
`An optional password. If present, it follows the user
`name separated from it by a colon.
`
`The user name (and password), if present, are followed by a
`commercial at-sign"@". Within the user and password field, any
`"@",or"/" must be encoded.
`
`..... . '
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 5]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`Note that an empty user name or password is different than no user
`name or password; there is no way to specify a password without
`specifying a user name. E.g., <URL:ftp://@host.com/> has an empty
`user name and no password, <URL:ftp://host.com/> has no user name,
`while <URL:ftp://foo:@host.com/> has a user name of "foo" and an
`empty password.
`
`host
`The fully qualified domain name of a network host, or its IP
`address as a set of four decimal digit groups separated by
`".". Fully qualified domain names take the form as described
`in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
`[5]: a sequence of domain labels separated by".", each domain
`label starting and ending with an alphanumerical character and
`possibly also containing"-" characters. The rightmost domain
`label will never start with a digit, though, which
`syntactically distinguishes all domain names from the IP
`addresses.
`
`port
`The port number to connect to. Most schemes designate
`protocols that have a default port number. Another port number
`may optionally be supplied, in decimal, separated from the
`host by a colon. If the port is omitted, the colon is as well.
`
`url-path
`The rest of the locator consists of data specific to the
`scheme, and is known as the "url-path". It supplies the
`details of how the specified resource can be accessed. Note
`that the"/" between the host (or port) and the url-path is
`NOT part of the url-path.
`
`The url-path syntax depends on the scheme being used, as does the
`manner in which it is interpreted.
`
`3.2. FTP
`
`The FTP URL scheme is used to designate files and directories on
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`5/22.
`
`Netflix 1037 - Page 5
`
`

`
`https://www.ietf.org/rfc/rfc1738.bct
`9/12/2016
`Internet hosts accessible using the FTP protocol (RFC959).
`
`A FTP URL follow the syntax described in Section 3.1. If :<port> is
`omitted, the port defaults to 21.
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 6]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`3.2.1. FTP Name and Password
`
`A user name and password may be supplied; they are used in the ftp
`"USER" and "PASS" commands after first making the connection to the
`FTP server.
`If no user name or password is supplied and one is
`requested by the FTP server, the conventions for "anonymous" FTP are
`to be used, as follows:
`
`The user name "anonymous" is supplied.
`
`The password is supplied as the Internet e-mail address
`of the end user accessing the resource.
`
`If the URL supplies a user name but no password, and the remote
`server requests a password, the program interpreting the FTP URL
`should request one from the user.
`
`3.2.2. FTP url-path
`
`The url-path of a FTP URL has the following syntax:
`
`<cwdl>/<cwd2>/ ... /<cwdN>/<name>;type=<typecode>
`
`Where <cwdl> through <cwdN> and <name> are (possibly encoded) strings
`and <typecode> is one of the characters "a", "i", or "d". The part
`";type=<typecode>" may be omitted. The <cwdx> and <name> parts may be
`empty. The whole url-path may be omitted, including the"/"
`delimiting it from the prefix containing user, password, host, and
`port.
`
`The url-path is interpreted as a series of FTP commands as follows:
`
`Each of the <cwd> elements is to be supplied, sequentially, as the
`argument to a CWD (change working directory) command.
`
`If the typecode is "d", perform a NLST (name list) command with
`<name> as the argument, and interpret the results as a file
`directory listing.
`
`Otherwise, perform a TYPE command with <typecode> as the argument,
`and then access the file whose name is <name> (for example, using
`the RETR command.)
`
`Within a name or CWD component, the characters"/" and";" are
`reserved and must be encoded. The components are decoded prior to
`their use in the FTP protocol.
`In particular, if the appropriate FTP
`sequence to access a particular file requires supplying a string
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`6/22.
`
`Netflix 1037 - Page 6
`
`

`
`https://www.ietf.org/rfc/rfc1738.bct
`9/12/2016
`containing a"/" as an argument to a CWD or RETR command, it is
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 7]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`necessary to encode each"/".
`
`For example, the URL <URL:ftp://myname@host.dom/%2Fetc/motd> is
`interpreted by FTP-ing to "host.dam", logging in as "myname"
`(prompting for a password if it is asked for), and then executing
`"CWD /etc" and then "RETR motd". This has a different meaning from
`<URL:ftp://myname@host.dom/etc/motd> which would "CWD etc" and then
`"RETR motd"; the initial "CWD" might be executed relative to the
`default directory for "myname". On the other hand,
`<URL:ftp://myname@host.dom//etc/motd>, would "CWD "with a null
`argument, then "CWD etc", and then "RETR motd".
`
`FTP URLs may also be used for other operations; for example, it is
`possible to update a file on a remote file server, or infer
`information about it from the directory listings. The mechanism for
`doing so is not spelled out here.
`
`3.2.3. FTP Typecode is Optional
`
`The entire ;type=<typecode> part of a FTP URL is optional. If it is
`omitted, the client program interpreting the URL must guess the
`appropriate mode to use. In general, the data content type of a file
`can only be guessed from the name, e.g., from the suffix of the name;
`the appropriate type code to be used for transfer of the file can
`then be deduced from the data content of the file.
`
`3.2.4 Hierarchy
`
`For some file systems, 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 similar to the
`URL path. This does NOT mean that the URL is a Unix filename.
`
`3.2.5. Optimization
`
`Clients accessing resources via FTP may employ additional heuristics
`to optimize the interaction. For some FTP servers, for example, it
`may be reasonable to keep the control connection open while accessing
`multiple URLs from the same server. However, 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.
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 8]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`7122.
`
`Netflix 1037 - Page 7
`
`

`
`9/12/2016
`3.3. HTTP
`
`https://www.ietf.org/rfc/rfc1738.bct
`
`The HTTP URL scheme is used to designate Internet resources
`accessible using HTTP (HyperText Transfer Protocol).
`
`The HTTP protocol is specified elsewhere. This specification only
`describes the syntax of HTTP URLs.
`
`An HTTP URL takes the form:
`
`http://<host>:<port>/<path>?<searchpart>
`
`where <host> and <port> are as described in Section 3.1. If :<port>
`is omitted, the port defaults to 80. No user name or password is
`allowed. <path> is an HTTP selector, and <searchpart> is a query
`string. The <path> is optional, as is the <searchpart> and its
`preceding"?". If neither <path> nor <searchpart> is present, the"/"
`may also be omitted.
`
`Within the <path> and <searchpart> components, "/", ";", "?" are
`reserved. The"/" character may be used within HTTP to designate a
`hierarchical structure.
`
`3.4. GOPHER
`
`The Gopher URL scheme is used to designate Internet resources
`accessible using the Gopher protocol.
`
`The base Gopher protocol is described in RFC 1436 and supports items
`and collections of items (directories). The Gopher+ protocol is a set
`of upward compatible extensions to the base Gopher protocol and is
`described in [2]. Gopher+ supports associating arbitrary sets of
`attributes and alternate data representations with Gopher items.
`Gopher URLs accommodate both Gopher and Gopher+ items and item
`attributes.
`
`3.4.1. Gopher URL syntax
`
`A Gopher URL takes the form:
`
`gopher://<host>:<port>/<gopher-path>
`
`where <gopher-path> is one of
`
`<gophertype><selector>
`<gophertype><selector>%09<search>
`<gophertype><selector>%09<search>%09<gopher+_string>
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 9]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`If :<port> is omitted, the port defaults to 70. <gophertype> is a
`single-character field to denote the Gopher type of the resource to
`which the URL refers. The entire <gopher-path> may also be empty, in
`which case the delimiting"/" is also optional and the <gophertype>
`defaults to "1".
`
`In the Gopher protocol,
`<selector> is the Gopher selector string.
`Gopher selector strings are a sequence of octets which may contain
`any octets except 09 hexadecimal (US-ASCII HT or tab) 0A hexadecimal
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`8/22.
`
`Netflix 1037 - Page 8
`
`

`
`9/12/2016
`https://www.ietf.org/rfc/rfc1738.txt
`(US-ASCII character LF), and 0D (US-ASCII character CR).
`
`Gopher clients specify which item to retrieve by sending the Gopher
`selector string to a Gopher server.
`
`Within the <gopher-path>, no characters are reserved.
`
`Note that some Gopher <selector> strings begin with a copy of the
`<gophertype> character, in which case that character will occur twice
`consecutively. The Gopher selector string may be an empty string;
`this is how Gopher clients refer to the top-level directory on a
`Gopher server.
`
`3.4.2 Specifying URLs for Gopher Search Engines
`
`If the URL refers to a search to be submitted to a Gopher search
`engine, the selector is followed by an encoded tab (%09) and the
`search string. To submit a search to a Gopher search engine, the
`Gopher client sends the <selector> string (after decoding), a tab,
`and the search string to the Gopher server.
`
`3.4.3 URL syntax for Gopher+ items
`
`URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+
`string. Note that in this case, the %09<search> string must be
`supplied, although the <search> element may be the empty string.
`
`The <gopher+_string> is used to represent information required for
`retrieval of the Gopher+ item. Gopher+ items may have alternate
`views, arbitrary sets of attributes, and may have electronic forms
`associated with them.
`
`To retrieve the data associated with a Gopher+ URL, a client will
`connect to the server and send the Gopher selector, followed by a tab
`and the search string (which may be empty), followed by a tab and the
`Gopher+ commands.
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 10]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`3.4.4 Default Gopher+ data representation
`
`When a Gopher server returns a directory listing to a client, the
`Gopher+ items are tagged with either a"+" (denoting Gopher+ items)
`or a"?" (denoting Gopher+ items which have a +ASK form associated
`with them). A Gopher URL with a Gopher+ string consisting of only a
`"+" refers to the default view (data representation) of the item
`while a Gopher+ string containing only a"?" refer to an item with a
`Gopher electronic form associated with it.
`
`3.4.5 Gopher+ items with electronic forms
`
`Gopher+ items which have a +ASK associated with them (i.e. Gopher+
`items tagged with a"?") require the client to fetch the item's +ASK
`attribute to get the form definition, and then ask the user to fill
`out the form and return the user's responses along with the selector
`string to retrieve the item. Gopher+ clients know how to do this but
`depend on the"?" tag in the Gopher+ item description to know when to
`
`https://www.ietf.org/rfc/rfc1738. txt
`
`9/22
`
`Netflix 1037 - Page 9
`
`

`
`9/12/2016
`https://www.ietf.org/rfc/rfc1738.txt
`handle this case. The"?" is used in the Gopher+ string to be
`consistent with Gopher+ protocol's use of this symbol.
`
`3.4.6 Gopher+ item attribute collections
`
`To refer to the Gopher+ attributes of an item, the Gopher URL's
`Gopher+ string consists of"!" or"$". "!" refers to the all of a
`Gopher+ item's attributes. "$" refers to all the item attributes for
`all items in a Gopher directory.
`
`3.4.7 Referring to specific Gopher+ attributes
`
`To refer to specific attributes, the URL's gopher+_string is
`"!<attribute_name>" or "$<attribute_name>". For example, to refer to
`the attribute containing the abstract of an item, the gopher+_string
`would be "!+ABSTRACT".
`
`To refer to several attributes, the gopher+_string consists of the
`attribute names separated by coded spaces. For example,
`"!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes
`of an item.
`
`3.4.8 URL syntax for Gopher+ alternate views
`
`Gopher+ allows for optional alternate data representations (alternate
`views) of items. To retrieve a Gopher+ alternate view, a Gopher+
`client sends the appropriate view and language identifier (found in
`the item's +VIEW attribute). To refer to a specific Gopher+ alternate
`view, the URL's Gopher+ string would be in the form:
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 11]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`+<view_name>%20<language_name>
`
`For example, a Gopher+ string of "+application/postscript%20Es_ES"
`refers to the Spanish language postscript alternate view of a Gopher+
`item.
`
`3.4.9 URL syntax for Gopher+ electronic forms
`
`The gopher+_string for a URL that refers to an item referenced by a
`Gopher+ electronic form (an ASK block) filled out with specific
`values is a coded version of what the client sends to the server.
`The gopher+_string is of the form:
`
`+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2 value>%0D%0A.%0D%0A
`
`To retrieve this item, the Gopher client sends:
`
`<a_gopher_selector><tab>+<tab>l<cr><lf>
`+-l<cr><lf>
`<ask_iteml_value><cr><lf>
`<ask_item2_value><cr><lf>
`.<cr><lf>
`
`to the Gopher server.
`
`3.5. MAILTO
`
`https://www.ietf.org/rfc/rfc1738. txt
`
`10/22
`
`Netflix 1037 - Page 10
`
`

`
`https://www.ietf.org/rfc/rfc1738.bct
`9/12/2016
`The mailto URL scheme is used to designate the Internet mailing
`address of an individual or service. No additional information other
`than an Internet mailing address is present or implied.
`
`A mailto URL takes the form:
`
`mailto:<rfc822-addr-spec>
`
`where <rfc822-addr-spec> is (the encoding of an) addr-spec, as
`specified in RFC 822 [6]. Within mailto URLs, there are no reserved
`characters.
`
`Note that the percent sign("%") is commonly used within RFC 822
`addresses and must be encoded.
`
`Unlike many URLs, the mailto scheme does not represent a data object
`to be accessed directly; there is no sense in which it designates an
`object. It has a different use than the message/external-body type in
`MIME.
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 12]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`3.6. NEWS
`
`The news URL scheme is used to refer to either news groups or
`individual articles of USENET news, as specified in RFC 1036.
`
`A news URL takes one of two forms:
`
`news:<newsgroup-name>
`news:<message-id>
`
`A <newsgroup-name> is a period-delimited hierarchical name, such as
`"comp.infosystems.www.misc". A <message-id> corresponds to the
`Message-ID of section 2.1.5 of RFC 1036, without the enclosing"<"
`and">"; it takes the form <unique>@<full_domain_name>. A message
`identifier may be distinguished from a news group name by the
`presence of the commercial at"@" character. No additional characters
`are reserved within the components of a news URL.
`
`If <newsgroup-name> is"*" (as in <URL:news:*>), it is used to refer
`to "all available news groups".
`
`The news URLs are unusual in that by themselves, they do not contain
`sufficient information to locate a single resource, but, rather, are
`location-independent.
`
`3.7. NNTP
`
`The nntp URL scheme is an alternative method of referencing news
`articles, useful for specifying news articles from NNTP servers (RFC
`977).
`
`A nntp URL take the form:
`
`nntp://<host>:<port>/<newsgroup-name>/<article-number>
`
`where <host> and <port> are as described in Section 3.1. If :<port>
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`11/22
`
`Netflix 1037 - Page 11
`
`

`
`9/12/2016
`is omitted, the port defaults to 119.
`
`https://www.ietf.org/rfc/rfc1738.bct
`
`The <newsgroup-name> is the name of the group, while the <article(cid:173)
`number> is the numeric id of the article within that newsgroup.
`
`Note that while nntp: URLs specify a unique location for the article
`resource, most NNTP servers currently on the Internet today are
`configured only to allow access from local clients, and thus nntp
`URLs do not designate globally accessible resources. Thus, the news:
`form of URL is preferred as a way of identifying news articles.
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 13]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`3.8. TELNET
`
`The Telnet URL scheme is used to designate interactive services that
`may be accessed by the Telnet protocol.
`
`A telnet URL takes the form:
`
`telnet://<user>:<password>@<host>:<port>/
`
`as specified in Section 3.1. The final"/" character may be omitted.
`If :<port> is omitted, the port defaults to 23. The :<password> can
`be omitted, as well as the whole <user>:<password> part.
`
`This URL does not designate a data object, but rather an interactive
`service. Remote interactive services vary widely in the means by
`which they allow remote logins; in practice, the <user> and
`<password> supplied are advisory only: clients accessing a telnet URL
`merely advise the user of the suggested username and password.
`
`3.9. WAIS
`
`The WAIS URL scheme is used to designate WAIS databases, searches, or
`individual documents available from a WAIS database. WAIS is
`described in [7]. The WAIS protocol is described in RFC 1625 [17];
`Although the WAIS protocol is based on 239.50-1988, the WAIS URL
`scheme is not intended for use with arbitrary 239.50 services.
`
`A WAIS URL takes one of the following forms:
`
`wais://<host>:<port>/<database>
`wais://<host>:<port>/<database>?<search>
`wais://<host>:<port>/<database>/<wtype>/<wpath>
`
`where <host> and <port> are as described in Section 3.1. If :<port>
`is omitted, the port defaults to 210. The first form designates a
`WAIS database that is available for searching. The second form
`designates a particular search. <database> is the name of the WAIS
`database being queried.
`
`The third form designates a particular document within a WAIS
`database to be retrieved. In this form <wtype> is the WAIS
`designation of the type of the object. Many WAIS implementations
`require that a client know the "type" of an object prior to
`retrieval, the type being returned along with the internal object
`identifier in the search response. The <wtype> is included in the
`
`https://www.ietf.org/rfc/rfc1738. bet
`
`12/22
`
`Netflix 1037 - Page 12
`
`

`
`https://www.ietf.org/rfc/rfc1738.txt
`9/12/2016
`URL in order to allow the client interpreting the URL adequate
`information to actually retrieve the document.
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 14]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`The <wpath> of a WAIS URL consists of the WAIS document-id, encoded
`as necessary using the method described in Section 2.2. The WAIS
`document-id should be treated opaquely; it may only be decomposed by
`the server that issued it.
`
`3.10 FILES
`
`The file URL scheme is used to designate files accessible on a
`particular host computer. This scheme, unlike most other URL schemes,
`does not designate a resource that is universally accessible over the
`Internet.
`
`A file URL takes the form:
`
`file://<host>/<path>
`
`where <host> is the fully qualified domain name of the system on
`which the <path> is accessible, and <path> is a hierarchical
`directory path of the form <directory>/<directory>/ ... /<name>.
`
`For example, a VMS file
`
`DISK$USER:[MY.NOTES]NOTE123456.TXT
`
`might become
`
`<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>
`
`As a special case, <host> can be the string "localhost" or the empty
`string; this is interpreted as 'the machine from which the URL is
`being interpreted'.
`
`The file URL scheme is unusual in that it does not specify an
`Internet protocol or access method for such files; as such, its
`utility in network protocols between hosts is limited.
`
`3.11 PROSPERO
`
`The Prospero URL scheme is used to designate resources that are
`accessed via the Prospero Directory Service. The Prospero protocol is
`described elsewhere [14].
`
`A prospero URLs takes the form:
`
`prospero://<host>:<port>/<hsoname>;<field>=<value>
`
`where <host> and <port> are as described in Section 3.1. If :<port>
`is omitted, the port defaults to 1525. No username or password is
`
`Berners-Lee, Masinter & Mccahill
`
`[Page 15]
`
`RFC 1738
`
`Uniform Resource Locators (URL)
`
`December 1994
`
`https://www.ietf.org/rfc/rfc1738. txt
`
`13/22
`
`Netflix 1037 - Page 13
`
`

`
`9/12/2016
`
`https://www.ietf.org/rfc/rfc1738.bct
`
`allowed.
`
`The <hsoname> is the host-specific object name in the Prospero
`protocol, suitably encoded. This name is opaque and interpreted by
`the Prospero server. The semicolon";" is reserved and may not
`appear without quoting in the <hsoname>.
`
`Prospero URLs are interpreted by contacting a Prospero directory
`server on the specified host and port to determine appropriate access
`methods for a resource, which might themselves be represented as
`different URLs. External Prospero links are represented as URLs of
`the underlying access method and are not represented as Prospero
`URLs.
`
`Note that a slash"/" may appear in the <hsoname> without quoting and
`no significance may be assumed by the application. Though slashes
`may indicate hierarchical structure on the server, such structure is
`not guaranteed. Note that many <hsoname>s begin with a slash, in
`which case the host or port will be followed by a double slash: the
`slash from the URL syntax, followed by the initial slash from the
`<hsoname>. (E.g., <URL:prospero://host.dom//pros/name> designates a
`<hsoname> of "/pros/name".)
`
`In addition, after the <hsoname>, optional fields and values
`associated with a Prospero link may be specified as part of the URL.
`When present, each field/value pair is separated from each other and
`from the rest of the URL by a";" (semicolon). The name of the field
`and its value are separated by a"=" (equal sign). If present, these
`fields serve to identify the target of the URL. For example, the
`OBJECT-VERSIO