RFC 2717

Registration Procedures for URL Scheme Names

📅 published November 1999, from ietf

RFC 2717: Registration Procedures for URL Scheme Names 🎀

Okay bestie, let's get the title block out of the way first 💅. This is BCP 35, which makes it a Best Current Practice. It's from November 1999 and was written by R. Petke (UUNET Technologies) and I. King (Microsoft Corporation). Its whole job is explaining how new URL scheme names get registered 🦋. It doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Status of this Memo

This document is a Best Current Practice for the Internet Community 🌸. It's asking for discussion and suggestions for improvements, and anyone can distribute it freely because distribution is unlimited 🫶.

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

Abstract

This document lays out the process for registering new URL scheme names 🧚.

1.0 Introduction ✨

Okay so, a Uniform Resource Locator (URL) is a compact string that tells you where to find a resource on the Internet 🌈. RFC 2396 [1] is the one that defines the general syntax and semantics of URIs, and URLs come along for the ride since they're part of that family 💜. A URL shows up as a "<scheme>:" followed by a "<scheme-specific-part>". Plenty of schemes already exist, but new ones might be needed later to support new Internet protocols and procedures 🍓.

We need a registration process so that the names of all these new schemes are guaranteed not to collide 😭. It also makes sure that schemes meant for wide, public use get developed in an orderly, well-specified, and public way 👑.

This document spells out the registration procedures to follow when new URL schemes get created 💅. There's a separate document, RFC 2718, Guidelines for URL Schemes [2], that gives guidance on actually creating new schemes 🫶. The main focus here is the <scheme> part of a new URL scheme, which this document calls the "scheme name" all the way through ✨.

1.1 Notation

Here's the deal with the key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are all to be read the way RFC 2119 describes them 📚. Those words are a big deal, so treat them seriously 🙈.

2.0 URL Scheme Name Registration Trees 🌳

2.1 General

Okay this part is so smart 🧠. To make registration more efficient and flexible, the document recognizes that there's a need for multiple registration "trees" 🦋. Each tree has its own registration requirements and procedures, so the overall process can handle the different needs URL schemes have 🌸. For example, a scheme that's going to be recommended for wide support and implementation across the Internet community needs a way more thorough review than a scheme meant for resources tied to proprietary software 💀.

The first step when registering a new URL scheme name is figuring out which registration tree the scheme belongs in 💖. That choice depends on what the scheme is for and what syntax the scheme name should have 🎀.

This document goes deep on the tree that reflects current practice, the one under IETF ownership and control 👑. It also sets out an outline to help authors make new trees for different needs, like wide acceptance and interoperability, ease of creation and use, and the type and "strength" of ownership 🍓.

2.2 The IETF Tree

The IETF tree is for URL schemes of general interest to the Internet community 🌈. It exists for schemes that need a substantive review and approval process 🔥. The expectation is that applicability statements for specific applications will get published from time to time, recommending the implementation of and support for URL schemes that have proven especially useful in those contexts ✨.

2.3 Additional Registration Trees

From time to time, and when the community needs it, the IESG may create new top-level registration trees 🧚. These trees might require significant registration, little registration, or none at all 🫶. They may also let change control sit with individuals or groups other than the IETF 🦋. A new tree should only be created if no existing tree can be shown to address the set of needs of some sector of the community 💅.

3.0 Requirements for Scheme Name Registration 📋

3.1 General Requirements

All new URL schemes, no matter which registration tree they're in, MUST conform to the generic syntax for URLs as specified in RFC 2396 💖. No exceptions, bestie 🙅‍♀️.

3.2 The IETF Tree

Registering in the IETF tree means publishing the URL scheme syntax and semantics in either an Informational or Standards Track RFC 📜. Generally, creating a brand-new URL scheme takes a Standards Track RFC 🔥. An Informational RFC can only be used for registration when the URL scheme is already in wide usage and meets the other standards from RFC 2718, like "demonstrated utility" within the Internet Architecture 🌸. The IESG gets broad discretion in deciding whether an Informational RFC works in any given case. It can recommend changes before publication or reject the document outright 💀. An Informational RFC that purports to describe a URL scheme shall not be published without IESG approval 🙈. This is a departure from the usual Informational RFC practice set out in RFC 2026, so that registering URL schemes serves the best interests of the Internet community 👑.

The NAMES of schemes registered in the IETF tree MUST NOT contain the dash (also known as the hyphen and minus sign) character '-', USASCII value 2Dh 🚫. Using that character can cause confusion with schemes registered in alternative trees (see section 3.3) 😭.

An analysis of the security issues inherent in the new URL scheme is REQUIRED 🔒. (This follows the basic requirements for all IETF protocols.) URL schemes registered in the IETF tree should not introduce additional security risks into the Internet Architecture 🛡️. For example, URLs should not embed information that should stay confidential, such as passwords 🙅‍♀️. New schemes also shouldn't subvert the security of existing schemes or protocols, meaning by layering or tunneling 💀.

The "owner" of a URL scheme name registered in the IETF tree is assumed to be the IETF itself 👑. Changing or altering the specification requires the same level of processing (for example, an Informational or Standards Track RFC) that was used for the initial registration 🎀. Schemes first defined through an Informational RFC may, however, be replaced with Standards Track documents 🦋.

3.3 Alternative Trees

Public exposure and review of a URL scheme made in an alternative tree isn't required 🌈. Still, using the IETF Internet-Draft mechanism for peer review is strongly encouraged to improve the quality of the specification 💅. RFC publication of alternative tree URL schemes is encouraged but not required 🧚. Material can be published as an Informational RFC by sending it to the RFC Editor (please follow the instructions to RFC authors, RFC 2223 [3]) 📬.

The defining document for an alternative tree may require public exposure and/or review for schemes defined in that tree through a mechanism other than the IETF Internet-Draft mechanism 🔍.

URL schemes created in an alternative tree must conform to the generic URL syntax in RFC 2396 🍓. The tree's defining document may set out additional syntax and semantics requirements above and beyond what RFC 2396 specifies 🫶.

All new URL schemes SHOULD follow the Guidelines for URL Schemes, set out in RFC 2718 [2] ✨.

An analysis of the security issues inherent in the new URL scheme is encouraged 🔐. Whatever security analysis is or isn't done, all descriptions of security issues must be as accurate as possible 💀. In particular, a statement that there are "no security issues associated with this scheme" must not be confused with "the security issues associated with this scheme have not been assessed," or with "the security issues associated with this scheme cannot be predicted because of <reason>" 🙈. Be precise, babe 💅.

There is absolutely no requirement that URL schemes created in an alternative tree be secure or completely free from risks 😭. Even so, the tree's defining document must set out the standard for security considerations, and in any event all known security risks SHOULD be identified 🔥.

Change control must be defined for a new tree 👑. Change control may be vested in the IETF, or in an individual, group, or other entity 🌸. The change control standard for the tree must be approved by the IESG 🎀.

The syntax for alternative trees shall be as follows: each tree gets identified by a unique prefix 🧚. That prefix has to be established the same way a URL scheme name in the IETF tree is, except the prefix must be defined by a Standards Track document 📜. Scheme names in the new tree are then built by putting the prefix in front of an identifier that's unique to each scheme in that tree, as that tree's identifying document prescribes 🦋:

<prefix>'-'<tree-specific identifier>

For instance, the "foo" tree would allow creation of scheme names like "foo-blahblah:" and "foo-bar:", where the tree prescribes an arbitrary USASCII string after the tree's unique prefix 💖.

4.0 Registration Procedures 🗂️

4.1 The IETF Tree

The first step in registering a new URL scheme in the IETF tree is to publish an IETF Internet-Draft detailing the syntax and semantics of the proposed scheme 📝. The draft must, minimally, address all of the items covered by the template in section 6 of this document 💅.

Once all issues raised during a review period of no less than 4 weeks have been addressed, submit the draft to the IESG for review 🔍.

The IESG will review the proposed new scheme and either refer it to a working group (existing or new) or present it directly to the IESG for a last call 🧚. In the former case, the working group is responsible for submitting a final version of the draft to the IESG for approval once it has received adequate review and deliberation 🫶.

4.2 Alternative Trees

Registration of URL schemes created in an alternative tree may be formal, through IETF documents, IANA registration, or another acknowledged organization 🌈. It can also be informal, through a mailing list or other publication mechanism, or it can be nonexistent 🙈. The registration mechanism must be documented for each alternative tree, and must be consistent for all URL scheme names created in that tree 🎀.

It's the responsibility of the creator of the tree's registration requirements to establish that the registration mechanism is workable as described 💅. The IESG has the discretion to reject the document describing a tree if it decides the registration mechanism is impractical or creates an undue burden on a party who won't accept it 💀. (For instance, if an IANA registration mechanism is proposed, the IESG might reject the tree if its mechanism would create undue liability on the part of IANA 😭.)

While the template in section 6 of this document is meant to apply to URL scheme names in the IETF tree, it's also offered as a guideline for those documenting alternative trees 🍓.

5.0 Change Control 🔄

5.1 Schemes in the IETF Tree

URL schemes created in the IETF tree are "owned" by the IETF itself 👑. They can be changed as needed by updating the RFC that describes them 🦋. Schemes described by a Standards Track RFC may be replaced with new Standards Track RFCs 🔥. Informational RFCs may be replaced by new Informational RFCs or by Standards Track RFCs 🌸.

5.2. Schemes in Alternative Trees 🦋

okay so URL schemes living in an alternative tree that are undocumented (which that tree's rules allow 💜) may be changed by their owner at any time, and they don't have to tell the IETF 🙈

URL schemes made in an alternative tree that have been documented by an Informational RFC can be changed at any time by the owner. ngl though, an updated Informational RFC that details the changes made must be submitted to the IESG 📄✨

The owner of a URL scheme registered in an alternative tree and documented by an Informational RFC can hand off responsibility for the registration to another person or agency, as long as they inform the IESG 🫶

The IESG may reassign responsibility for a URL scheme registered in an alternative tree and documented by an Informational RFC. The most common version of this is when the scheme name is privately owned under its tree's rules, and the owner has died, gone out of contact, or can't make changes the community really needs 😭🕊️

The IESG may reclassify a URL scheme created in an alternative tree and documented via an Informational RFC as "historic" if it decides the scheme is no longer in use 🥀

6.0 Registration Template ✨

bestie, these are the things you should cover when documenting a new URL scheme 📝

  • URL scheme name.
  • URL scheme syntax. This should be expressed in a clear and concise manner. The use of ABNF is encouraged. Please refer to RFC 2718 for guidance on designing and explaining your scheme's syntax. 🧠
  • Character encoding considerations. It is important to identify what your scheme supports in this regard. It is obvious that for interoperability, it is best if there is a means to support character sets beyond USASCII, but especially for private schemes, this may not be the case. 🌸
  • Intended usage. What sort of resource is being identified? If this is not a 'resource' type of URL (e.g. mailto:), explain the action that should be initiated by the consumer of the URL. If there is a MIME type associated with this resource, please identify it. 💖
  • Applications and/or protocols which use this URL scheme name. Including references to documentation which defines the applications and/or protocols cited is especially useful. 📚
  • Interoperability considerations. If you are aware of any details regarding your scheme which might impact interoperability, please identify them here. For example: proprietary or uncommon encoding method; inability to support multibyte character sets; incompatibility with types or versions of underlying protocol (if scheme is tunneled over another protocol). 🔌
  • Security considerations. 🔐
  • Relevant publications. 📖
  • Person & email address to contact for further information. 📧
  • Author/Change controller. 👑

Applications and/or protocols which use this URL scheme name. (yes, it's listed twice, the vibe is "say it again for the people in the back" 🙋‍♀️)

7.0 Security Considerations 💀

this section is SERIOUS, so pay attention 🔥

Information that creates or updates a registration needs to be authenticated. No skipping this step, babe 🔒

Information about possible security vulnerabilities of a protocol can change over time. That means the security claims for a registered URL scheme can change too. As new vulnerabilities are discovered, information about them may need to be attached to the existing documentation, so that users aren't misled about the true security properties of a registered URL scheme 😱🚨

If the IESG agrees to delegate the registration and change control functions of an alternative tree to a group or individual outside of the IETF, that group or individual should have sufficient security procedures in place to authenticate registration changes. The whole point is keeping the gate locked 🗝️💅

8.0 References 📚

  • [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
  • [2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
  • [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

9.0 Authors' Addresses 🎀

the squad behind this one 🫶

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

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


Ian King
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052-6399
USA
Phone: +1 425-703-2293
Fax: +1 425-936-7329
EMail: iking@microsoft.com

the legal bit, read it all, it's giving formal but it matters 💼

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 🥰✨

📦 where this page comes from