📄 rfc1630.txt
字号:
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 [Page 15]
RFC 1630 URIs in WWW June 1994
The data type is specified by a suffix to the URL. Possible
suffixes are:
;type = <type-code> Use FTP type as given to perform data
transfer.
/ Use FTP directory list commands to read
directory
The type code is in the format defined in RFC 959 except that THE
SPACE IS OMITTED FROM THE URL.
Transfer Mode
Stream Mode is always used.
Gopher
The gopher URL specifies the host and optionally the port to which
the client should connect. This is followed by a slash and a single
gopher type code. This type code is used by the client to determine
how to interpret the server's reply and is is not for sending to
server. The command string to be sent to the server immediately
follows the gopher type character. It consists of the gopher
selector string followed by any "Gopher plus" syntax, but always
omitting the trainling CR LF pair.
When the gopher command string contains characters (such a embedded
CR LF and HT characters) not allowed in a URL, these are encoded
using the conventional encoding.
Note that some gopher selector strings begin with a copy of the
gopher type character, in which case that character will occur twice
consecutively. Also note that the gopher selector string may be an
empty string since this is how gopher clients refer to the top-level
directory on a gopher server.
If the encoded command string (with trailing CR LF stripped) would be
void then the gopher type character may be omiited and "1" (ASCII 31
hex) is assumed.
Note that slash "/" in gopher selector strings may not correspond to
a level in a hierarchical structure.
Berners-Lee [Page 16]
RFC 1630 URIs in WWW June 1994
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.
News
The news locators refer to either news group names or article message
identifiers which must conform to the rules for a Message-Id of RFC
1036 (Horton 1987). 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).
A news URL may be dereferenced using NNTP (RFC 977, Kantor 1986)
(The ARTICLE by message-id command ) or using any other protocol for
the conveyance of usenet news articles, or by reference to a body of
news articles already received.
Note 1:
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.
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 working group.
Further extension possible may be to allow the naming of subject
threads as addressable objects.
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
Berners-Lee [Page 17]
RFC 1630 URIs in WWW June 1994
addressed individually or, in general, automatically retrieved, this
is a less desirable, though currently common, solution.
URN
The "Universal Resource Name" is currently (March 1993) under
development in the IETF. A requirements specification is in
preparation. It currently looks as though it will be a short string
suitable for encoding in URI syntax, for which case the "urn:" prefix
is reserved. The URN shall be encoded precisely as defined in the
(future) URN standard, except in that:
If the official description of the URN syntax includes any
constant wrapper characters, then they shall not be omitted from
the URI encoding of the URN;
If the URN has a hierarchical nature, then the slash delimiter
shall be used in the URI encoding;
If the URN has a hierarchical nature, the most significant part
shall be encoded on the left in the URI encoding;
Any characters with reserved meanings in the URI syntax shall be
escape encoded
These rules of course apply to any URI scheme. It is of course
possible that the URN syntax will be chosen such that the URI
encoding will be a 1-1 transcription.
An example might be a name such as
urn:/iana/dns/ch/cern/cn/techdoc/94/1642-3
but the reader should refer to the latest URN drafts or
specifications.
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 need to be prefixed by
"wais:" (by the partial form rules).
Berners-Lee [Page 18]
RFC 1630 URIs in WWW June 1994
The wpath of a WAIS URL consists of encoded fields of the WAIS
identifier, in the same order as inthe WAIS identifier. For each
field, the identifier field number is the digits before the equals
sign, and the field contents follow, encoded in the conventional
encoding, terminated by ";".
file
The other URI schemes (except nntp) share the property that they are
equally valid at any geographical place.
There is however a real practical requirement to be able to generate
a URL for an object in a machine's local file system.
The syntax is similar to the ftp syntax, but in this case the slash
is used to donate boundaries between directory levels of a
hierarchical file system is used. The "client" software converts the
file URL into a file name in the local file name conventions. This
allows local files to be treated just as network objects without any
necessity to use a network server for access. This may be used for
example for defining a user's "home" document in WWW.
There is clearly a danger of confusion that a link made to a local
file should be followed by someone on a different system, with
unexpected and possibly harmful results. Therefore, the convention
is that even a "file" URL is provided with a host part. This allows
a client on another system to know that it cannot access the file
system, or perhaps to use some other local mecahnism to access the
file.
The special value "localhost" is used in the host field to indicate
that the filename should really be used on whatever host one is.
This for example allows links to be made to files which are
distribted on many machines, or to "your unix local password file"
subject of course to consistency across the users of the data.
A void host field is equivalent to "localhost".
Message-Id
For systems which include information transferred using mail
protocols, there is a need to be able to make cross-references
between different items of information, even though, by the nature of
mail, those items are only available to a restricted set of people.
Two schemes are defined. The first, "mid:", refers to the STD 11,
RFC 822 Message-Id of a mail message. This Identifier is already
used in RFC 822 in for example the References and In-Reply-to field.
Berners-Lee [Page 19]
RFC 1630 URIs in WWW June 1994
The rest of the URL after the "mid:" is the RFC822 msg-id with the
constant <> wrapper removed, leaving an identifier whose format in
fact happens to be the same as addr-spec format for mailboxes (though
the semantics are different).
The use of a "mid" URL implies access to a body of mail already
received. If a message has been distributed using NNTP or other
usenet protocols over the news system, then the "news:" form should
be used.
Content-Id
The second scheme, "cid:", is similar to "mid:", but makes reference
to a body part of a MIME message by the value of its content-id
field. This allows, for example, a master document being the first
part of a multipart/related MIME message to refer to component parts
which are transferred in the same message.
Note
Beware however, that content identifiers are only required to be
unique within the context of a given MIME message, and so the cid:
URL is only meaningful with the context the same MIME message. For
a reference outside the message, it would need to be appended to
the message-id of the whole message. A syntax for this has not
been defined.
Schemes for Further Study
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.
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.
Berners-Lee [Page 20]
RFC 1630 URIs in WWW June 1994
NETWORK MANAGEMENT DATABASE
This is a subject for study.
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. In all other cases the "news" scheme should
be used.
The news server name, newsgroup name, and index number of an
article within the newsgroup on that particular server are given.
The NNTP protocol must be used.
Note 1.
This form of URL is not of global accessability, as typically
NNTP servers only allow access from local clients. Note that
the article numbers within groups vary from server to server.
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. This is a local identifier
for a resource which is often available globally, and so is not
recommended except in the case in which incomplete NNTP
implementations on the local server force its adoption.
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.
The path part contains a host specific object name and an optional
version number. If present, the version number is separated 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.
Registration of naming schemes
A new naming scheme may be introduced by defining a mapping onto a
conforming URL syntax, using a new prefix. Experimental prefixes may
be used by mutual agreement between parties, and must start with the
Berners-Lee [Page 21]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -