Considerations for new UR* schemes

URL schemes are the part in front of the first : in an URL.
The general syntax for URLs is given in RFC 1738.
This document lists some of the concerns that the Apps Area Directors will raise when a new scheme for URLs, URNs or things that look like them are proposed.

It is by no means an exhaustive list, but it might be useful for those who present new schemes for discussion, so that some of the questions that will inevitably be raised can be answered beforehand.

This document has no standard status; it is a personal opinion of the ADs.

Here is IANA's list of URL schemes; a list of URL schemes known to Dan Connoly of the WWW Consortium is given at the W3C Web server.

How to register an URL scheme

New schemes may be registered with the IETF by issuing a standards-track RFC.
The IESG can make exceptions to this rule by allowing publication of Informational or Experimental RFCs that define URL schemes, but only after careful review for consistency with the URI architecture and the protocol for which an URL is being defined.

An IETF working group, URLREG, is attempting to define procedures for registering URL schemes that will serve the community better than the sometimes heavyweight IETF standardization process; until this effort is completed, URLs will only be registered by the IETF if they are standards-track.

Procedures for creating IETF standards are described in the Procedures document in this Webspace.

Note that standardizing an URL scheme does not imply placing the underlying protocol under IETF control; see, for example, the VEMMI URL scheme documented in RFC 2112.

Is the scheme well defined?

This means different things in different contexts.

For some schemes, like news: or ftp:, the spec should give enough information to make at least one valid translation into operations performed in the base protocol, with any "must be configured" fields (like NNTP server name for news) clearly identified.

For other schemes, like a hypothetical isbn: CID, the spec needs to describe exactly how all legal values of the base standard's ID can be represented using the suggested notation, and exactly which modifiers, alternate forms and other artifacts from the base standards are included or not included.

In all cases, encoding rules must be made clear: What octets are put into the URI, and if other octets need to be represented, what convention is used to represent them?
Departure from the %xx convention needs special justification!

Is it useful?

UR* schemes are expensive things to support. Often they require special code in browsers, proxies or servers. Having a lot of ways to say the same thing is not something that adds value to 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.

Are operations on the URL well defined?

In some contexts, like HTML forms, it is possible to specify any one of a list of operations to be performed on a specifc UR*. (Outside forms, it is generally assumed to be something you GET.)

The proposal should list all well-defined operations on the UR* identifier, and what they are supposed to do.

Some identifiers, like the Telnet URL or hypothetical URLs for access to MBONE video channels, provide location information for hooking onto bidirectional 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 UR*". It is also valid to say that "there's only one operation defined for this UR*, and it's not very GET-like". The important point is that what is defined on this type is described.

Can it be proxyed into HTTP/HTML?

It is much easier to deploy gateways to a new service than it is to deploy browsers that understand the new UR* object.

Therefore, proxy servers can be terribly useful things.

That doesn't mean that all new schemes have to be proxied; on the contrary, some very useful ones like mailto: cannot be.

(Another possible mechanism is Java applets, but not all browsers are capable of running Java applets)

Things to look for when thinking about a proxy are:

• 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? ("rough consensus and running code"....)

Are there security considerations?

Above and beyond the security considerations of the base mechanism a scheme builds upon, one must think of things that can happen in the normal course of UR* usage.

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 UR*s 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 long-forgotten 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)?

None of these are black-and-white issues; they do need to be adressed.

Is it relative-URL compatible?

Many applications know and love relative URLs. Therefore, the following questions must be asked:

• Can it be parsed according to RFC 1808 - that is, if the tokens "//", "/", ";", "?" and "#" are used, do they have the meaning given in RFC 1808?
• Does it make sense to use it in relative URLs like those RFC 1808 specifies?
• If something is designed to be broken into pieces, does it document what those pieces are, why it should be broken in this way, and why the breaks aren't where 1808 says that they usually should be?
• If it has a hierarchy, does it go left-to-right and with slash separators like RFC 1808? If not, why not?

Does it start with UR?

Any scheme starting with the letters "U" and "R", in particular if it attaches any of the meanings "uniform", "universal" or "unifying" to the first leter, is going to cause intense debate, and generate much heat (but maybe little light).

Any such proposal should either make sure that there is a large consensus behind it that it will be the scheme of its type, or pick another name.

Questions that will not be asked

The ADs will NOT attach much importance to these questions:

• Is it an URL, an URN or something else?
  This classification has proved interesting in theory, but not terribly useful when evaluating schemes.
• Can all objects in the world that are validly identified by a scheme be accessed by any UA implementing it?
  The answer is, of course, "for some schemes, yes, barring access controls; for other schemes, no".

Last modified: Mon Sep 22 09:14:58 1997