RFC 2718

RFC 2718: Guidelines for new URL Schemes 🎀

okay bestie, RFC 2718 is an Informational doc from November 1999 🌸 It came from the Network Working Group, written by L. Masinter (Xerox Corporation), H. Alvestrand (Maxware, Pirsenteret), D. Zigmond (WebTV Networks, Inc.), and R. Petke (UUNET Technologies) 👑 The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋

---

Status of This Memo ✨

This memo is here to give info to the Internet community 💅 It does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶

Copyright Notice 💜

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌈

okay so a Uniform Resource Locator (URL) is a compact string that tells you where a resource lives on the Internet 🗺️ This document gives you guidelines for defining new URL schemes, so you can make them the iconic way 🔥

1. Introduction ✨

so a Uniform Resource Locator (URL) is a compact string that shows where a resource is on the Internet 🌸 RFC 2396 [1] lays out the general syntax and semantics of URIs, and, by inclusion, URLs 💖 URLs are marked by putting a "<scheme>:" in front, followed by a "<scheme-specific-part>". Lots of URL schemes already exist 🍓

This document gives guidelines for defining new URL schemes, for anyone defining, registering, or evaluating those definitions 🧚

The process for registering new URL schemes is defined in RFC 2717 [2] 📋

2. Guidelines for new URL schemes 💖

bestie, new URL schemes can really complicate client software 😭 So new schemes need to have demonstrable utility and operability, plus compatibility with existing URL schemes. This section breaks those criteria down 🎀

2.1 Syntactic compatibility 🦋

New URL schemes should follow the same syntactic conventions as existing schemes when that makes sense. If a URI scheme has embedded links in its content and doesn't share syntax with a different scheme, that same content can't be served under the other scheme without rewriting it 🙈 This is already a problem, and with future digital signature schemes, rewriting may not even be possible 💀 So deploying other schemes later could get extremely difficult.

2.1.1 Motivations for syntactic compatibility 💅

Why should new URL schemes share as much of the generic URI syntax (wherever it makes sense) as possible? Look at these, it's so real:

• If fragment syntax isn't shared between two schemes (e.g. <a href="#foo">), you can't move individual completely self referential documents between schemes without rewriting the embedded references within the document. On the Web, fragment syntax is a property of the media type, and the client is the one that evaluates it 🔥
• If fragment syntax isn't shared between different media types with the same capability (e.g. HTML, XML, Word, or image types like GIF, JPEG, PNG), then you can't have a URI reference that can evolve to superior media types as they show up, or even likely work properly today with content negotiation 😭
• If relative syntax isn't shared between two schemes (to the extent of understanding that the URI is relative, and which part of the URI string is relative), e.g. <a href="foo">, you can't move sets of internally self referential documents between schemes without rewriting the embedded URIs 🫶
• If the ".." syntax as a path component in relative URIs isn't shared between schemes, you can't easily have sets of document sets and refer to them across schemes without rewriting the embedded references 🌈
• If the "/" syntax isn't shared (to the extent of understanding that the URI refers to a path relative to the current naming authority, see section 2.1.1), you can't easily move multiple sets of documents up or down a relative hierarchy of names and share a common set between them, without rewriting the content, either inside that scheme or between schemes. The best example is a site with a shared set of GIF, JPEG, and PNG images, where you want to reorganize and change the depth of a subtree from one depth to another, or from one directory to another where the depth isn't the same 🍓
• If naming authority syntax (e.g. what comes after "//" in most URL schemes, see section 2.1.1) and relative path syntax aren't shared (to the extent of understanding that the URI has a naming authority, and which part of the URI string is the naming authority versus the path), you can't share identical name spaces and serve them via different schemes. (Naming authority syntax is a property of the scheme.) HTTP and FTP have the same syntax, for example, and that's been exploited a lot by sites moving from an FTP archive service to an HTTP archive service, so the URLs can be identical except for the scheme. The same content can be served via two schemes at the same time 👑

2.1.2 Improper use of "//" following "<scheme>:" 🙈

Contrary to some examples set in past years, using double slashes as the first component of the <scheme-specific-part> of a URL is not just an artistic signal that what follows is a URL 💅 Double slashes are used ONLY when the URL's <scheme-specific-part> contains a hierarchical structure as described in RFC 2396. In URLs from those schemes, the double slashes show that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes that don't have a conformant hierarchical structure in their <scheme-specific-part> shouldn't use double slashes after the "<scheme>:" string 🦋

2.1.3 Compatibility with relative URLs 🌸

URL schemes should use the generic URL syntax if they're meant to be used with relative URLs. A description of the allowed relative forms should be included in the scheme's definition. Lots of applications use relative URLs extensively, so specifically:

• Can the scheme be parsed according to RFC 2396? For example, if the tokens "//", "/", ";", or "?" are used, do they have the meaning given in RFC 2396?
• Does it make sense to use the scheme in relative URLs like the ones RFC 2396 specifies?
• If the scheme syntax is designed to be broken into pieces, does the scheme's syntax documentation say what those pieces are, why it should be broken that way, and why the breaks aren't where RFC 2396 says they usually should be?
• If the scheme has a hierarchy, does it go left-to-right with slash separators, like RFC 2396?

2.2 Is the scheme well defined? 🧚

It's super important that the semantics of the "resource" a URL "locates" are well defined 💖 What that means can change depending on the kind of URL scheme.

2.2.1 Clear mapping from other name spaces 🎀

A lot of the time, new URL schemes are defined as ways to translate other protocols and name spaces into the general URL framework. The "ftp" URL scheme translates from the FTP protocol, while the "mid" URL scheme translates from the Message-ID field of messages 🍓

Either way, the description of the mapping must be complete, must describe how characters do or don't get encoded in URLs, must describe exactly how all legal values of the base standard can be represented using the URL scheme, and must spell out exactly which modifiers, alternate forms, and other artifacts from the base standards are or aren't included. These requirements are elaborated below 🫶

2.2.2 URL schemes associated with network protocols 🌈

Most new URL schemes are tied to network resources that can be accessed by one or several network protocols 🔥 The 'ftp', 'news', and 'http' schemes are like this. For these schemes, the specification should completely describe how URLs get translated into protocol actions, in enough detail that accessing the network resource is unambiguous. If an implementation of the URL scheme needs some configuration, the configuration elements must be clearly identified. (For example, the 'news' scheme, if implemented using NTTP, requires configuration of the NTTP server.) 👑

2.2.3 Definition of non-protocol URL schemes 💜

Sometimes URL schemes don't have a particular network protocol attached, because they're only used in contexts where the access method is already understood 🙈 The "cid" and "mid" URL schemes are an example of this. For these schemes, the specification should describe the notation of the scheme and give a complete mapping of the locator from its source ✨

2.2.4 Definition of URL schemes not associated with data resources 🦋

Most URL schemes locate Internet resources that correspond to data objects that can be retrieved or modified, like "ftp" and "http" 💅 But some URL schemes don't. For example, the "mailto" URL scheme corresponds to an Internet mail address 📬

If a new URL scheme doesn't locate resources that are data objects, the properties of names in the new space must be clearly defined 🌸

2.2.5 Character encoding 🍓

When you describe URL schemes where (some of) the elements are actually representations of character sequences, be careful not to add unnecessary variety in how characters get encoded into octets and then into URL characters 🧚 Unless there's some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279) [3] and then using the %HH encoding for unsafe octets is recommended 💖

2.2.6 Definition of operations 🔥

In some contexts (for example, HTML forms), you can specify any one of a list of operations to perform on a specific URL. (Outside forms, it's generally assumed to be something you GET 💅)

The URL scheme definition should describe all well-defined operations on the URL identifier, and what they're supposed to do 🫶

Some URL schemes (for example, "telnet") provide location information for hooking onto bi-directional data streams, and don't fit the "infoaccess" paradigm of most URLs very well. This should be documented 🌈

NOTE: It is perfectly valid to say that "no operation apart from GET is defined for this URL". It is also valid to say that "there's only one operation defined for this URL, and it's not very GET-like". The important point is that what is defined on this type is described. 💀✨

2.3. Demonstrated utility 💅

Okay so, new URL schemes need to prove they're worth it, bestie 💖 They're expensive to support. Browsers, proxies, and servers often need special code just to handle them. If there are a bunch of ways to say the exact same thing, those programs get messier for no real payoff for the Internet 🫠

The kinds of things that are useful include:

• Things that cannot be referred to in any other way.
• Things where it is much easier to get at them using this scheme than (for instance) a proxy gateway.

2.3.1. Proxy into HTTP/HTML 🧚

One way to show a scheme is useful is with a gateway that serves objects in the new scheme to clients using an existing protocol. It's way easier to deploy gateways for a new service than it is to get browsers to understand a brand-new URL object ✨

Things to look for when you're thinking about a proxy:

• Is there a single global resolution mechanism whereby any proxy can find the referenced object?
• If not, is there a way in which the user can find any object of this type, and "run his own proxy"?
• Are the operations mappable one-to-one (or possibly using modifiers) to HTTP operations?
• Is the type of returned objects well defined?
  • as MIME content-types?
  • as something that can be translated to HTML?
• Is there running code for a proxy?

2.4. Are there security considerations? 🔐

Beyond the security stuff of whatever base mechanism a scheme is built on, you have to think about what can happen during normal URL usage. It's giving "main character problem" 😭

In particular:

• Does the user need to be warned that such a thing is happening without an explicit request (GET for the source of an IMG tag, for instance)? This has implications for the design of a proxy gateway, of course.
• Is it possible to fake URLs of this type that point to different things in a dangerous way?
• Are there mechanisms for identifying the requester that can be used or need to be used with this mechanism (the From: field in a mailto: URL, or the Kerberos login required for AFS access in the AFS: URL, for instance)?
• Does the mechanism contain passwords or other security information that are passed inside the referring document in the clear (as in the ftp URL, for instance)?

2.5. Does it start with UR? 🙈

Any scheme starting with the letters "U" and "R" is about to cause intense debate and generate a lot of heat (but maybe not much light) 🔥 This is especially true if it attaches any of the meanings "uniform", "universal" or "unifying" to the first letter. Literally everyone will have opinions 💀

So any proposal like that should either make sure there's a huge consensus that it'll be the only scheme of its type, or pick another name. Iykyk 🫶

2.6. Non-considerations 🌸

Some issues that get raised a lot, but that aren't relevant to new URL schemes, include the following.

2.6.1. Are all objects accessible? 🦋

Can all objects in the world that are validly identified by a scheme be accessed by any UA implementing it?

Sometimes the answer is yes and sometimes it's no. It often depends on stuff like firewalls or client configuration, which aren't directly related to the scheme itself 🙃

3. Security Considerations 💀

New URL schemes are required to address all security considerations in their definitions. No skipping this one, no cap 🔥

4. References 📚

[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[2] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.

[3] Yergeau, F., "UTF-8, A Transformation Format of Unicode and ISO 10646", RFC 2279, January 1998.

5. Authors' Addresses 🫶

Larry Masinter
Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304

URL: http://purl.org/NET/masinter
EMail: masinter@parc.xerox.com

Harald Tveit Alvestrand
Maxware, Pirsenteret
N-7005 Trondheim
NORWAY

Phone: +47 73 54 57 00
EMail: harald.alvestrand@maxware.no

Dan Zigmond
WebTV Networks, Inc.
305 Lytton Avenue
Palo Alto, CA 94301
USA

Phone: +1-650-614-6071
EMail: djz@corp.webtv.net

Rich Petke
UUNET Technologies
5000 Britton Road
P. O. Box 5000
Hilliard, OH 43026-5000

Phone: +1-614-723-4157
Fax: +1-614-723-8407
EMail: rpetke@wcom.net

6. Full Copyright Statement ⭐

The legal bits stay word-for-word, no paraphrasing the fine print 🙏

Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🌈