RFC 1630
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
RFC 1630: Universal Resource Identifiers in WWW 🦋
Okay bestie, let's get the tea first 🫖✨ This is RFC 1630, titled Universal Resource Identifiers in WWW, with the subtitle A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web. It's from the Network Working Group 🧚 and was written by T. Berners-Lee of CERN. The category is Informational and the date is June 1994 💖. The title block doesn't list anything it obsoletes or updates, so there's zero drama there 🙈.
Status of this Memo 📜
This memo gives information to the Internet community 💁. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌸.
IESG Note:
Heads up from the IESG 🚨: the work in this memo does not describe an Internet standard. An Internet standard for general Resource Identifiers is still under development within the IETF 🛠️.
Introduction 🌸
This doc defines the syntax the World-Wide Web initiative uses 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 ones, ones invented for the web itself, and ones that haven't been invented yet 🔮. Access instructions for an individual object under a given protocol get encoded into forms of address string ✨. Other protocols let you use object names of various forms. To abstract the idea of a generic object, the web needs two concepts: the universal set of objects, and the universal set of names or addresses of objects 🧠.
A Universal Resource Identifier (URI) is a member of this universal set. It's a name in a registered name space, or an address referring to a registered protocol or name space 🦋. A Uniform Resource Locator (URL), defined elsewhere, is a form of URI that expresses an address which maps onto an access algorithm using network protocols 📍. The existing URI schemes that 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 🏷️. That area isn't addressed by this document. This doc is written to document existing practice and provide a reference point for URL and URN discussions 📚.
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 💌.
You can read this document 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.
Okay so there are loads of protocols and systems for document search and retrieval in use right now, and even more protocols (or refinements of existing ones) are on the way, because this field is expanding explosively 💥.
These systems are aiming for global search and readership of documents across differing computing platforms, despite a plethora of protocols and data formats 🌐. As protocols evolve, gateways can keep global access possible 🚪. As data formats evolve, format conversion programs can preserve global access 🔄. There's one area, though, where conversions are impractical, and that's the names and addresses used to identify objects 😬. Why? Because names and addresses get passed on in so many ways, from the backs of envelopes to hypertext objects, and they may have a long life 💀.
A common feature of almost all the data models of past and proposed systems is that they can be mapped onto a concept of "object" and some kind of name, address, or identifier for that object 🧩. So you can define a set of name spaces in which these objects can be said to exist 🫧.
Practical systems need to access and mix objects that are part of different existing and proposed systems 🤹. That's why the concept of the universal set of all objects, and therefore the universal set of names and addresses in all name spaces, becomes important 👑. It allows names in different spaces to be treated in a common way, even though names in different spaces have differing characteristics, just like the objects they refer to 💅.
URIs 🔗
This document defines a way to encapsulate a name in any registered name space, and label it with 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 it may be extended with technology 🚀.
The specification of the URI syntax doesn't imply anything about the properties of names and addresses in the various name spaces that get mapped onto the set of URI strings 🙅. Those properties follow from the specifications of the protocols and the associated usage conventions for each scheme 📖.
URLs 📍
For existing Internet access protocols, it's necessary in most cases to define the encoding of the access algorithm into something concise enough to be termed address 🤏. URIs that refer to objects accessed with existing protocols are known as "Uniform Resource Locators" (URLs) ✨. They're listed here as used in WWW, but they're formally defined in a separate document 📄.
URNs 🏷️
There's 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 🎉.
Reserved characters ✨
okay so the path in a URI gets its meaning from whichever scheme it belongs to 🦋 Usually it spells out a name in some namespace, or an algorithm for getting at an object 🧚 Either way, the encoding can use characters the BNF syntax allows, or hexadecimal encoding for everything else 💅
Some reserved characters have special jobs, so let's get into the tea 🍓
THE PERCENT SIGN 💖
The percent sign (%, ASCII 25 hex) is the escape character in the encoding scheme, and it is never allowed for anything else 🙈
HIERARCHICAL FORMS 🌳
The slash (/, ASCII 2F hex) is reserved for delimiting substrings whose relationship is hierarchical 👑 That's what makes partial forms of the URI possible. Substrings made of single or double dots (. or ..) are reserved in a similar way 🫶
The slash between two segments means the segment on the left is more significant than the segment on the right. ("Significance" here only means closeness to the root of the hierarchy, and it makes no value judgement! 💅)
Quick heads up 🙅: any resemblance to unix and other disk operating system filename conventions is 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) is reserved as the delimiter that separates the URI of an object from a fragment identifier ✨
QUERY STRINGS 🔮
The question mark (?, ASCII 3F hex) marks 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 that results from applying the query to the original object 👀
Inside the query string, the plus sign is reserved as shorthand for a space, so real plus signs must be encoded. This was used to make query URIs easier to pass around in systems that didn't allow spaces 🙄
The query string stands for some operation applied to the object, but this spec gives no common syntax or semantics for it. In practice the syntax and semantics may depend on the scheme, and may even depend on the base URI 🤷♀️
OTHER RESERVED CHARACTERS 🌈
The asterisk (*, ASCII 2A hex) and exclamation mark (!, ASCII 21 hex) are reserved for having special significance 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 🧸
Encoding reserved characters 🧩
When a system uses a local addressing scheme, it's really useful to provide a mapping from local addresses into URIs, so references to objects inside that scheme can 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 so the partial form can 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 that 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, so they may NEVER be encoded and unencoded in this way ⚠️
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-claudeand
http://info.cern.ch/albert/bertram/marie%2Dclaudeare identical, as the %2D encodes a hyphen character 🎀
Example 2
The URIs
http://info.cern.ch/albert/bertram/marie-claudeand
http://info.cern.ch/albert/bertram%2Fmarie-claudeare 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%*.fredand
news:12345667123%asdghfh@info.cern.chare illegal, as all % characters imply encodings, and there is no decoding defined for "%*" or "%as" in this recommendation 💀
Partial (relative) form 🧭
Within an 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 lets objects within a group refer to each other without needing space for a complete reference, and it incidentally means the group of objects can 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: 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.
- 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:
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/fthe 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:hand 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 🧚
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 contained 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. ✨ that's the whole vibe ✨
Specific Schemes 🌸
okay so this part is all about the actual schemes, aka what the URL looks like for each protocol 💖 these URIs get called URLs a lot, though the exact definition of "URL" was still being argued about (March 1993) 🤓 the BNF syntax definition has the official mapping, and the notes below cover each protocol. here are the schemes:
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 accessthese next two are proposed as essential for smooshing the web and email together 🫶 but as far as the author knew, nobody had implemented them yet:
mid Message identifiers for electronic mail
cid Content identifiers for MIME body partthe schemes for X.500, network management databases, and Whois++ weren't specified yet and might get studied later 🧚 Prospero and restricted NNTP use weren't implemented either, as far as the author knew. the urn prefix is reserved for encoding a Uniform Resource Name once the IETF working group finishes it 🦋 and new schemes can get registered later too ✨
HTTP
the path is basically handled transparently by anyone who touches a URL, except the servers that actually de-reference them 💅 the client passes the path to the server with every request, but otherwise the client doesn't understand it at all 🙈
the host details don't get passed to the client when the URL is an HTTP URL pointing at the server in question. instead, the string sent starts with the slash right after the host details 🎀 but when an HTTP server is acting as a gateway (or "proxy"), the entire URI gets sent on the HTTP command line, no matter what scheme it uses 👑 the search part (if there is one) gets sent as part of the HTTP command and can be treated like part of the path. the fragment part (the hash sign and everything after it) is never sent with the request ✨ and spaces and control characters in URLs must be escaped for transmission over HTTP, same goes for any other disallowed characters 💀
EXAMPLES ✨
these examples aren't part of the spec, they're just here to illustrate things 🫶
the URI of a server's "welcome" page is usually:
http://www.my.work.com/after the hostname and port, the rest of the URL is opaque to the client, so it can look like basically anything 🌈 these are all pretty typical:
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/462F4F2D4241522A314159265358979323846a URL for a server on a port other than 80 looks like this 🍓
http://info.cern.ch:8000/imaginary/testreferencing a particular part of a document, fragment identifier included, looks like this 🦋
http://www.myu.edu/org/admin/people#andyin that case the string #andy isn't sent to the server. the client holds onto it and uses it once the whole object has been retrieved 🧚
a search on a text database might look like this 🔍
http://info.my.org/AboutUs/Index/Phonebook?dobbinsand a search on another database looks like this 💜
http://info.cern.ch/RDB/EMP?*%20where%20name%%3Ddobbinsin every case the client passes the path string to the server uninterpreted, and the client can't deduce anything from it, which is the whole vibe 💅
FTP
the ftp: prefix means the FTP protocol is being used, as defined in STD 9, RFC 959 or any successor 🌸 the port number, if it's there, gives the port of the FTP server when it isn't the FTP default ✨
User name and password
the syntax lets you include a user name and even a password, for systems that don't use the anonymous FTP convention 🔐 if you don't supply a user or password, the default is to use that convention 💖 so the user name is anonymous and the password is the user's Internet-style mail address 📧
where possible, that mail address should be a usable one for the user, ideally with a DNS host name that resolves to the client's IP address 🫶 fair warning though: servers are currently all over the place about how they treat the anonymous password 🙈
Path
FTP lets you have a sequence of CWD commands (change working directory) and a TYPE command before service commands like RETR (retrieve) or NLIST (etc.) that actually access a file 🎀
the arguments of any CWD commands are the successive segments of the URL, split by slash. the final segment works as the filename argument to RETR for retrieval, or as the directory argument to NLIST 👑
for some file systems (Unix especially), the "/" that shows the hierarchy in the URL matches the delimiter used to build the file name hierarchy, so the filename ends up looking just like the URL path 🌈 this does NOT mean the URL is a Unix filename, bestie 💀
Note: Retrieving subsequent URLs from the same host
there's no common hierarchical model in FTP, so if a directory change command has already been given, it's basically impossible in general to figure out what sequence gets you to another directory for a second retrieval when the paths differ 😭 the only reliable algorithm is to disconnect and reestablish the control connection 🔁
Data type
in general FTP, the data content type of a file can only be deduced from its name, usually the suffix 🦋 that's not standardized. the other option is to transfer the type info outside the URL ✨ a suitable FTP transfer type (for example binary "I" or text "A") has to be deduced from the data content type in turn 💅 it's recommended that conventions for suffixes of public archives get established, though that's outside the scope of this standard 🌸
an FTP URL may optionally specify the FTP data transfer type used to retrieve an object 🎀 most of the methods line up with the FTP "Data Types" ASCII and IMAGE for retrieving a document, specified in FTP by the TYPE command 💖 one method means directory access 📂
the data type is specified by a suffix on the URL. the possible suffixes are:
;type = <type-code> Use FTP type as given to perform data
transfer.
/ Use FTP directory list commands to read
directorythe type code follows the format defined in RFC 959, except that THE SPACE IS OMITTED FROM THE URL 🙃
Transfer Mode
Stream Mode is always used 🌊 no debate, no cap 💅
Gopher
the gopher URL specifies the host, and optionally the port, the client should connect to 🍓 then comes a slash and a single gopher type code. the client uses that code to figure out how to interpret the server's reply, and the code isn't sent to the server 🧚 the command string that does get sent comes right after the gopher type character. it's made up of the gopher selector string followed by any "Gopher plus" syntax, but the trailing CR LF pair is always left off ✨
when the gopher command string has characters that aren't allowed in a URL (like embedded CR LF and HT characters), those get encoded using the conventional encoding 🫶
some gopher selector strings start with a copy of the gopher type character, in which case that character shows up twice in a row 👀 also, the gopher selector string can be an empty string, because that's how gopher clients refer to the top-level directory on a gopher server 🌈
if the encoded command string (with the trailing CR LF stripped) would be void, the gopher type character may be omitted, and "1" (ASCII 31 hex) is assumed 🎀
and heads up: a slash / in a gopher selector string might not match a level in any hierarchical structure 🙈
Mailto
this lets a URL specify an RFC822 addr-spec mail address 💌 one thing to watch: if you use %, like when forming a gatewayed mail address, it has to be converted to %25 in a URL 💅
News
the news locators point to either newsgroup names or article message identifiers, which have to follow the rules for a Message-Id in RFC 1036 (Horton 1987) 📰 a message identifier is easy to spot, since it has the commercial at "@" in it 🧐 these rules mean that inside an article, a reference to a newsgroup or another article will be a valid URL (in the partial form) ✨
a news URL may be dereferenced using NNTP (RFC 977, Kantor 1986) by way of the ARTICLE by message-id command 🔍 or by using any other protocol for conveying usenet news articles, or by pointing at a body of news articles the reader has already received 🦋
Note 1:
among URLs, news: URLs are kind of the odd ones out, because they're location-independent 🌀 they're unsuitable as URN candidates, since the NNTP architecture relies on articles expiring, which means only a small number of articles are available at any time 😭 when a news: URL gets quoted, the assumption is that the reader will fetch the article or group from their local news host 🏠 news host names are NOT part of news URLs 💅
Note 2:
here's the outstanding problem: the message identifier isn't enough to retrieve an expired article, because no algorithm exists for deriving an archive site and file name 💀 adding the date and newsgroup set to the article's URL would make it possible, if there were a directory of archive sites by newsgroup 🗂️
this is a suggested subject of study alongside the NNTP working group 🧠 a possible extension would be to let subject threads be named as addressable objects 🧵
Telnet, rlogin, tn3270
using URLs to represent interactive sessions is a handy extension of using them for objects 🌸 it lets you access information systems that only offer an interactive service and no information server 🖥️ but since information inside that service can't be addressed individually or, in general, retrieved automatically, this is a less desirable solution, even though it's super common right now 😩
URN ✨
okay so the "Universal Resource Name" 🌸 was still being cooked up in the IETF as of March 1993 💅. a requirements spec was in prep, and it looked like it'd be a short string that fits nicely into URI syntax, which is why the urn: prefix is reserved for it 🔒. The URN SHALL be encoded precisely as defined in the (future) URN standard, except 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 apply to literally any URI scheme 🌐. it's also totally possible the URN syntax gets chosen so the URI encoding is a 1-1 transcription 🤩.
an example might be a name like:
urn:/iana/dns/ch/cern/cn/techdoc/94/1642-3but the reader SHOULD refer to the latest URN drafts or specifications 📚🫶.
WAIS 🧚
the public domain WAIS implementation needs the client to know the "type" of an object before it can retrieve it 😭. the server sends that type back along with the internal object identifier in the search response, and the type gets encoded into the path part of the URL so the URL is enough to actually fetch the object 🎀.
inside the WAIS world, names don't need the wais: prefix (per the partial form rules) 💅.
the wpath of a WAIS URL is made of encoded fields of the WAIS identifier, in the same order as in the WAIS identifier. for each field, the identifier field number is the digits before the equals sign, and then the field contents follow, encoded in the conventional encoding and terminated by ";" 🧩.
file 🦋
every URI scheme except nntp is equally valid no matter where in the world you are 🌍. still, there's a real need to be able to make a URL for something sitting in a machine's local file system 🗂️.
the syntax looks a lot like the ftp syntax, but here the slash marks the boundaries between directory levels in a hierarchical file system. the "client" software turns the file URL into a file name using the local file name conventions 🪄. this means local files can be treated just like network objects, with no network server needed for access 🙌. this MAY be used, for example, to define a user's "home" document in WWW 🏠.
ngl there's a clear danger of confusion here 😬. a link made to a local file SHOULD be followed by someone on a different system, and that could lead to unexpected and possibly harmful results. so the convention is that even a file URL gets a host part 🫶. that way, a client on another system knows it can't get at the file system, or maybe it uses some other local mechanism to reach the file 🔐.
the special value "localhost" is used in the host field to say the filename SHOULD really be used on whatever host you're on 🏡. so you can link to files spread across lots of machines, or to "your unix local password file", as long as the data stays consistent across its users 🧠.
a void (empty) host field means the same thing as "localhost" 💜.
Message-Id 💌
if a system moves information over mail protocols, you'll want cross-references between items even though mail only lets a small group of people see them 💌.
there are two schemes. the first, mid:, points at the STD 11, RFC 822 Message-Id of a mail message. RFC 822 already uses this identifier in fields like References and In-Reply-to 💕.
the rest of the URL after the mid: is the RFC822 msg-id with the constant <> wrapper removed. the identifier happens to have the same format as an addr-spec for mailboxes (even though the semantics are different) 🤓.
using a mid URL means you need access to mail that's already been received 📫. if the message got spread over the news system using NNTP or other usenet protocols, then the news: form SHOULD be used 📰.
Content-Id 🎀
the second scheme, cid:, is kind of like mid:, but it points at a body part of a MIME message using its content-id field value 🧩. so a master doc sitting as the first part of a multipart/related MIME message can reference component parts that came in the same message 💖.
Beware, though 🚨: content identifiers are only REQUIRED to be unique within the context of a given MIME message, so the cid: URL only makes sense within that 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", "user friendly names" (ufn), or both, SHOULD be allowed. if any punctuation conversions are needed from the adopted x500 representation (like using slashes between parts of a ufn), they MUST be defined. this is a subject for study 📖.
WHOIS 🔎
this prefix describes access using the "whois++" scheme, which is still in the process of being defined ⏳. 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 a valid whois query string. this is a subject for further study 🔬.
NETWORK MANAGEMENT DATABASE 🛠️
this is a subject for study 📝.
NNTP 📰
this is an alternative form of reference for news articles. it's specifically for use with NNTP servers, especially the incomplete server implementations that don't 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 that newsgroup on that particular server are given. the NNTP protocol MUST be used 🔧.
Note 1. this form of URL is not of global accessibility, since NNTP servers typically only allow access from local clients. also, article numbers within groups vary from server to server 🙈. this form of URL SHOULD NOT be quoted outside this local area, and it SHOULD NOT be used within news articles for wider circulation than the one server. it's a local identifier for a resource that's often available globally, so it is NOT RECOMMENDED, except in the case where 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 a version number is present, it's separated from the host specific object name by the characters %00 (percent zero zero), which is an escaped string terminator (null) 🧚. external Prospero links are represented as URLs of the underlying access method, so they're never 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 they MUST start with the characters "x-" 🧪. the scheme name "urn:" is reserved for the work in progress on a scheme for more persistent names 🔒.
it is proposed that the Internet Assigned Numbers Authority (IANA) handle registration of new schemes 🏛️. any submission of a new URI scheme MUST include a definition of an algorithm for retrieving any object within that scheme. the algorithm MUST take the URI and produce either a set of URL(s) that lead to the desired object, or the object itself, in a well-defined or determinable format 👑.
it is RECOMMENDED that those proposing a new scheme demonstrate its utility and operability by providing a gateway, which provides 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 retrieval by URL, the client software has provision for being configured to use specific gateway locators for indirect access through new naming schemes 🫶.
BNF of Generic URI Syntax 🧮
here's a BNF-ish description of URI syntax, at the level where specific schemes aren't considered yet 🧠. a vertical line "|" indicates alternatives, and [brackets] indicate OPTIONAL parts. spaces are represented 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 📖.
the "generic" production gives a higher level parsing of the same URIs as the other productions. the "national" and "punctuation" characters don't appear in any productions, so they therefore may not appear in URIs 🚫.
fragmentaddress uri [ # fragmentid ]
uri scheme : path [ ? search ]
scheme ialpha
path void | xpalphas [ / path ]
search xalphas [ + search ]
fragmentid xalphas
xalpha alpha | digit | safe | extra | escape
xalphas xalpha [ xalphas ]
xpalpha xalpha | +
xpalphas xpalpha [ xpalpha ]
ialpha alpha [ xalphas ]
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
digit 0 |1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
safe $ | - | _ | @ | . | &
extra ! | * | " | ' | ( | ) | ,
reserved = | ; | / | # | ? | : | space
escape % hex hex
hex digit | a | b | c | d | e | f | A | B | C |
D | E | F
national { | } | vline | [ | ] | \ | ^ | ~
punctuation < | >
void
(end of URI BNF)BNF for specific URL schemes 🌸
okay so this is a BNF-like description of the Uniform Resource Locator syntax 💅 basically a grammar that spells out what a URL is allowed to look like. the rules work like this: a vertical line "|" means "pick one of these" 🔀, and [brackets] mean the stuff inside is optional 🧺. spaces get written as the word "space", and the vertical line character gets written as "vline" (since "|" is already busy doing the alternatives job 😭). single letters stand for single letters. any word longer than one letter is an entity defined somewhere else in the grammar. iykyk 🫶
The current IETF URI Working Group preference is for the prefixedurl production 🎀 (that's as of Nov 1993. back in July 93 it was just plain old url 🙈).
the "national" and "punctuation" characters don't show up in any productions 🚫 so they may not appear in URLs. they're literally not invited to the party 🥲
the "afsaddress" is still hanging around as a historical note 🕰️ but it's not a url production, so think of it as a vintage piece 👗
here's the whole grammar, exactly as written, because we are not touching a single character 🔒
prefixedurl u r l : url
url httpaddress | ftpaddress | newsaddress |
nntpaddress | prosperoaddress | telnetaddress
| gopheraddress | waisaddress |
mailtoaddress | midaddress | cidaddress
scheme ialpha
httpaddress h t t p : / / hostport [ / path ] [ ?
search ]
ftpaddress f t p : / / login / path [ ftptype ]
afsaddress a f s : / / cellname / path
newsaddress n e w s : groupart
nntpaddress n n t p : group / digits
midaddress m i d : addr-spec
cidaddress c i d : content-identifier
mailtoaddress m a i l t o : xalphas @ hostname
waisaddress waisindex | waisdoc
waisindex w a i s : / / hostport / database [ ? search
]
waisdoc w a i s : / / hostport / database / wtype /
wpath
wpath digits = path ; [ wpath ]
groupart * | group | article
group ialpha [ . group ]
article xalphas @ host
database xalphas
wtype xalphas
prosperoaddress prosperolink
prosperolink p r o s p e r o : / / hostport / hsoname [ %
0 0 version [ attributes ] ]
hsoname path
version digits
attributes attribute [ attributes ]
attribute alphanums
telnetaddress t e l n e t : / / login
gopheraddress g o p h e r : / / hostport [/ gtype [
gcommand ] ]
login [ user [ : password ] @ ] hostport
hostport host [ : port ]
host hostname | hostnumber
ftptype A formcode | E formcode | I | L digits
formcode N | T | C
cellname hostname
hostname ialpha [ . hostname ]
hostnumber digits . digits . digits . digits
port digits
gcommand path
path void | segment [ / path ]
segment xpalphas
search xalphas [ + search ]
user alphanum2 [ user ]
password alphanum2 [ password ]
fragmentid xalphas
gtype xalpha
alphanum2 alpha | digit | - | _ | . | +
xalpha alpha | digit | safe | extra | escape
xalphas xalpha [ xalphas ]
xpalpha xalpha | +
xpalphas xpalpha [ xpalphas ]
ialpha alpha [ xalphas ]
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
digit 0 |1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
safe $ | - | _ | @ | . | & | + | -
extra ! | * | " | ' | ( | ) | ,
reserved = | ; | / | # | ? | : | space
escape % hex hex
hex digit | a | b | c | d | e | f | A | B | C |
D | E | F
national { | } | vline | [ | ] | \ | ^ | ~
punctuation < | >
digits digit [ digits ]
alphanum alpha | digit
alphanums alphanum [ alphanums ]
void
(end of URL BNF)References 📚
ok these are the receipts 🧾 (kept word for word, typos and all 😭)
Alberti, R., et.al., "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>
Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)", CERN, December 1991, as updated from time to time, <ftp://info.cern.ch/pub/www/doc/http-spec.txt>
Crocker, D., "Standard for ARPA Internet Text Messages" STD 11, RFC 822, UDel, August 1982.
Davis, F, et al., "WAIS Interface Protocol: Prototype Functional Specification", Thinking Machines Corporation, April 23, 1990. <ftp://quake.think.com/pub/wa is/doc/protspec.txt>
International Standards Organization, Information and Documentation - Search and Retrieve Application Protocol Specification for open Systems Interconnection, ISO-10163.
Horton, M., and R. Adams, "Standard for Interchange of USENET messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987.
Huitema, C., "Naming: strategies and techniques", Computer Networks and ISDN Systems 23 (1991) 107-110.
Kahle, B., "Document Identifiers, or International Standard Book Numbers for the Electronic Age", <ftp: //quake.think.com/pub/wais/doc/doc-ids.txt>
Kantor, B., and P. Lapsley, Kantor, B., and P. Lapsley, "Network News Transfer Protocol", RFC 977, UC San Diego & UC Berkeley, February 1986. <ftp://ds.internic.net/rfc/rfc977.txt>
Kunze, J., "Requirements for URLs", Work in Progress.
Lynch, C., Coalition for Networked Information: "Workshop on ID and Reference Structures for Networked Information", November 1991. See <wais://quake.think.com/wais-discussion-archives?lynch>
Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987, <ftp://ds.internic.net/rfc/rfc1034.txt>
Neuman, B. Clifford, "Prospero: A Tool for Organizing Internet Resources", Electronic Networking: Research, Applications and Policy, Vol 1 No 2, Meckler Westport CT USA, 1992. See also <ftp://prospero.isi.edu/pub/prospero/oir.ps>
Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/Information Sciences Institute, October 1985. <ftp://ds.internic.net/rfc/rfc959.txt>
Sollins, K., and L. Masinter, "Requiremnets for URNs", Work in Progress.
Yeong, W., "Towards Networked Information Retrieval", Technical report 91-06-25-01, June 1991, Performance Systems International, Inc. <ftp://uu.psi.com/wp/nir.txt>
Yeong, W., "Representing Public Archives in the Directory", Work in Progress, November 1991, now expired.
Security Considerations 🔐
bestie, this part is short and kinda scary 💀 The memo itself says: "Security issues are not discussed in this memo." so there's zero security tea in here. if you're building anything with these URLs, go find your security info somewhere else 😭🙏
Author's Address 🖋️
Tim Berners-Lee
World-Wide Web project
CERN
1211 Geneva 23,
Switzerland
Phone: +41 (22)767 3755
Fax: +41 (22)767 7155
EMail: timbl@info.cern.ch📦 where this page comes from
- ietf: rfc1630 1994-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms