[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2718) 00 01 02 03 04 05 06 RFC 4395

Network Working Group                                          T. Hansen
Internet-Draft                                         AT&T Laboratories
Expires: April 15, 2005                                        T. Hardie
                                                          Qualcomm, Inc.
                                                             L. Masinter
                                                           Adobe Systems
                                                        October 15, 2004



       Guidelines and Registration Procedures for new URI Schemes
           draft-hansen-2717bis-2718bis-uri-guidelines-00.txt


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 15, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This document provides guidelines and recommendations for the
   definition of new URI schemes, and a mechanism to register those URI
   schemes.





Hansen, et al.           Expires April 15, 2005                 [Page 1]

Internet-Draft              New URI Schemes                 October 2004



   This is a first draft attempt to capture the sense of direction for
   updates to RFC 2717 and RFC 2718.  These changes were discussed at
   the August 26, 2004 URIREV4 BOF: see
   http://lists.w3.org/Archives/Public/uri/2004Aug/0007.html for the
   minutes.  Please send comments to uri@w3.org.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Guidelines for new URI schemes . . . . . . . . . . . . . . . .  5
     2.1   Important Considerations . . . . . . . . . . . . . . . . .  5
       2.1.1   non-Locator schemes  . . . . . . . . . . . . . . . . .  5
       2.1.2   Demonstratable, new, long-lived utility  . . . . . . .  5
       2.1.3   Syntactic compatibility  . . . . . . . . . . . . . . .  5
       2.1.4   Avoid improper use of "//" following "<scheme>:" . . .  6
       2.1.5   Compatibility with relative URIs . . . . . . . . . . .  6
     2.2   Is the scheme well defined?  . . . . . . . . . . . . . . .  6
       2.2.1   Clear mapping from other name spaces . . . . . . . . .  6
       2.2.2   URI schemes associated with network protocols  . . . .  7
       2.2.3   Definition of non-protocol URI schemes . . . . . . . .  7
       2.2.4   Definition of URI schemes not associated with data
               resources  . . . . . . . . . . . . . . . . . . . . . .  7
       2.2.5   Character encoding . . . . . . . . . . . . . . . . . .  7
       2.2.6   Definition of operations . . . . . . . . . . . . . . .  8
     2.3   Demonstrated utility . . . . . . . . . . . . . . . . . . .  8
       2.3.1   Proxy into HTTP/HTML . . . . . . . . . . . . . . . . .  8
     2.4   Are there security considerations? . . . . . . . . . . . .  9
     2.5   Does it start with UR? . . . . . . . . . . . . . . . . . .  9
     2.6   Non-considerations . . . . . . . . . . . . . . . . . . . .  9
       2.6.1   Are all objects accessible?  . . . . . . . . . . . . .  9
   3.  URI Scheme Name Registration . . . . . . . . . . . . . . . . . 10
     3.1   General  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.1   The Permanent URI Scheme Name Status . . . . . . . . . 10
       3.1.2   The Provisional URI Scheme Name Status . . . . . . . . 10
     3.2   Requirements for Scheme Name Registration  . . . . . . . . 10
       3.2.1   General Requirements . . . . . . . . . . . . . . . . . 10
       3.2.2   Permanent URI Scheme Names . . . . . . . . . . . . . . 11
       3.2.3   Provisional URI Scheme Names . . . . . . . . . . . . . 11
     3.3   Registration Procedures  . . . . . . . . . . . . . . . . . 12
       3.3.1   Permanent URI Scheme Names . . . . . . . . . . . . . . 12
       3.3.2   Provisional URI Scheme Names . . . . . . . . . . . . . 13
       3.3.3   Objections to Registration . . . . . . . . . . . . . . 13
     3.4   Change Control . . . . . . . . . . . . . . . . . . . . . . 14
       3.4.1   Permanent URI Scheme Names . . . . . . . . . . . . . . 14
       3.4.2   Provisional URI Scheme Names . . . . . . . . . . . . . 14
     3.5   New URI Scheme Registration Template . . . . . . . . . . . 15
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16




Hansen, et al.           Expires April 15, 2005                 [Page 2]

Internet-Draft              New URI Schemes                 October 2004



   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 16
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 19














































Hansen, et al.           Expires April 15, 2005                 [Page 3]

Internet-Draft              New URI Schemes                 October 2004



1.  Introduction


   A Uniform Resource Identifier (URI) is a compact string
   representation for identifying resources.  RFC XXXX [6] defines the
   general syntax of URIs.  This document provides guidelines for the
   definition of new URI schemes (for consideration by those who are
   defining and registering or evaluating those definitions), and a
   process and mechanism for registering URI schemes.  This document
   replaces RFCs 2717 [2] and 2718 [3].


   The original terminology for the URI protocol element attempted to
   draw a distinction between 'locators': identifiers used for accessing
   resources available on the Internet, and 'names': identifiers used
   for naming possibly abstract resources, independent of any mechanism
   for accessing them.  The intent was to use the designation "URL"
   (Uniform Resource Locator) for those identifiers that were locators,
   and "URN" (Uniform Resource Name) for those identifiers that were
   names.  In practice, the line between 'locator' and 'name' cannot be
   drawn precisely: locators can be used as names, and names can be used
   as locators.


   As a result, recent documents have used the term "URI" for all
   resource identifiers following the definition of RFC XXXX [6],
   avoiding the term "URL", and reserving the term "URN" explicitly for
   those URIs using the "urn" scheme name (RFC 2141 [1]).  URNs remain a
   distinct class of URIs because of the requirements set out in RFC
   3406 [8]; this document's procedures do not update or supersede the
   procedures set out in RFC 3406.


   RFC 2717 defined a set of registration trees in which URI schemes
   could be registered, one of which was called the IETF Tree, to be
   managed by IANA.  The registration process is needed to ensure that
   the names of all such new schemes are guaranteed not to collide.
   Further, the registration process ensures that URI schemes intended
   for wide spread, public use are developed in an orderly,
   well-specified, and public manner.


   RFC 2717 also allowed additional registration trees to be approved by
   the IESG, although no such registration trees have been approved.


   This document eliminates the distinction between different 'trees'
   for URI schemes, and instead establishes a single namespace for
   registered values.  Within that namespace, there are values that are
   approved as meeting a set of criteria for URI schemes; other scheme
   names may also be registered provisionally or without necessarily
   passing the review process or criteria.  Its intent is to:
   o  provide a central point of discovery for established URI scheme
      names, and easy location of their defining documents;




Hansen, et al.           Expires April 15, 2005                 [Page 4]

Internet-Draft              New URI Schemes                 October 2004



   o  discourage multiple definitions of URI scheme names for different
      purposes;
   o  and to help those proposing new URI scheme names to discern
      established trends and conventions, and to avoid names that might
      be confused with existing ones.


2.  Guidelines for new URI schemes


2.1  Important Considerations


   This section lists important considerations for URI scheme
   definitions.  It is useful for all URI definitions, whether standards
   track or not, to follow these guidelines.  The review process for
   IETF standards track URI schemes may require review against these
   criteria.


2.1.1  non-Locator schemes


   While it is acknowledged that URIs may or may not be useful as
   locators, it is important that the URI scheme definition itself be
   clear as to how it is expected to function.  Schemes that are not
   intended to be used as locators must describe how the resource
   identified should be interpreted by software that obtains a URI of
   that scheme.


2.1.2  Demonstratable, new, long-lived utility


   Because URI schemes are a single, global namespace, the unbounded
   registration of new schemes is harmful to the Internet community.
   For this reason, new URI schemes should have clear utility to the
   broad Internet community, beyond that available with already
   registered URI schemes.


2.1.3  Syntactic compatibility


   RFC XXXX [6] defines a generic syntax for URI schemes with
   hierarchical components and a naming authority.  New URI schemes
   should follow this syntax if appropriate.  The generic handling of
   relative URIs depends on this.


   URI schemes that are not intended for use with relative URIs should
   avoid use of the forward slash "/" character, which is used for
   hierarchical delimiters.


   In some circumstances, when a URI scheme does not fit into the
   existing RFC XXXX syntax, the new scheme definition should follow the
   syntax of other previously registered schemes, if possible.





Hansen, et al.           Expires April 15, 2005                 [Page 5]

Internet-Draft              New URI Schemes                 October 2004



2.1.4  Avoid improper use of "//" following "<scheme>:"


   The use of double slashes as the first component of the
   <scheme-specific-part> of a URI is not simply an artistic indicator
   that what follows is a URI: Double slashes are used ONLY when the
   syntax of the URI's <scheme-specific-part> contains a hierarchical
   structure as described in RFC XXXX.  In URIs from such schemes, the
   use of double slashes indicates that what follows is the top
   hierarchical element for a naming authority.  (See section ???? of
   RFC XXXX for more details.) URI schemes which do not contain a
   conformant hierarchical structure in their <scheme-specific-part>
   should not use double slashes following the "<scheme>:" string.


2.1.5  Compatibility with relative URIs


   URI schemes should use the generic URI syntax if they are intended to
   be used with relative URIs.  A description of the allowed relative
   forms should be included in the scheme's definition.  Many
   applications use relative URIs extensively.  Specifically,
   o  Can the scheme be parsed according to RFC XXXX - for example, if
      the tokens "//", "/", ";", or "?" are used, do they have the
      meaning given in RFC XXXX?
   o  Does the scheme make sense to use it in relative URIs like those
      RFC XXXX specifies?
   o  If the scheme syntax is designed to be broken into pieces, does
      the documentation for the scheme's syntax specify what those
      pieces are, why it should be broken in this way, and why the
      breaks aren't where RFC XXXX says that they usually should be?
   o  If the scheme has a hierarchy, does it go left-to-right and with
      slash separators like RFC XXXX?


2.2  Is the scheme well defined?


   It is important that the semantics of the "resource" that a URI
   "locates" be well defined.  This might mean different things
   depending on the nature of the URI scheme.


2.2.1  Clear mapping from other name spaces


   In many cases, new URI schemes are defined as ways to translate other
   protocols and name spaces into the general framework of URIs.  The
   "ftp" URI scheme translates from the FTP protocol, while the "mid"
   URI scheme translates from the Message-ID field of messages.


   In either case, the description of the mapping must be complete, must
   describe how characters get encoded or not in URIs, must describe
   exactly how all legal values of the base standard can be represented
   using the URI scheme, and exactly which modifiers, alternate forms




Hansen, et al.           Expires April 15, 2005                 [Page 6]

Internet-Draft              New URI Schemes                 October 2004



   and other artifacts from the base standards are included or not
   included.  These requirements are elaborated below.


2.2.2  URI schemes associated with network protocols


   Most new URI schemes are associated with network resources that have
   one or several network protocols that can access them.  The 'ftp',
   'news', and 'http' schemes are of this nature.  For such schemes, the
   specification should completely describe how URIs are translated into
   protocol actions in sufficient detail to make the access of the
   network resource unambiguous.  If an implementation of the URI scheme
   requires 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 URI schemes


   In some cases, URI schemes do not have particular network protocols
   associated with them, because their use is limited to contexts where
   the access method is understood.  This is the case, for example, with
   the "cid" and "mid" URI schemes.  For these URI schemes, the
   specification should describe the notation of the scheme and a
   complete mapping of the locator from its source.


2.2.4  Definition of URI schemes not associated with data resources


   Most URI schemes locate Internet resources that correspond to data
   objects that can be retrieved or modified.  This is the case with
   "ftp" and "http", for example.  However, some URI schemes do not; for
   example, the "mailto" URI scheme corresponds to an Internet mail
   address.


   If a new URI scheme does not locate resources that are data objects,
   the properties of names in the new space must be clearly defined.


2.2.5  Character encoding


   When describing URI schemes in which (some of) the elements of the
   URI are actually representations of sequences of characters, care
   should be taken not to introduce unnecessary variety in the ways in
   which characters are encoded into octets and then into URI
   characters.  Unless there is some compelling reason for a particular
   scheme to do otherwise, translating character sequences into UTF-8
   (RFC 2279 [4]) and then subsequently using the %HH encoding for
   unsafe octets is recommended.







Hansen, et al.           Expires April 15, 2005                 [Page 7]

Internet-Draft              New URI Schemes                 October 2004



2.2.6  Definition of operations


   In some contexts (for example, HTML forms) it is possible to specify
   any one of a list of operations to be performed on a specific URI.
   (Outside forms, it is generally assumed to be something you GET.)


   The URI scheme definition should describe all well-defined operations
   on the URI identifier, and what they are supposed to do.


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


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


2.3  Demonstrated utility


   URI schemes should have demonstrated utility.  New URI schemes are
   expensive things to support.  Often they require special code in
   browsers, proxies, and/or servers.  Having a lot of ways to say the
   same thing needless complicates these programs without adding value
   to the Internet.


   The kinds of things that are useful include:
   o  Things that cannot be referred to in any other way.
   o  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 provide a demonstration of utility is via a gateway which
   provides objects in the new scheme for clients using an existing
   protocol.  It is much easier to deploy gateways to a new service than
   it is to deploy browsers that understand the new URI object.


   Things to look for when thinking about a proxy are:
   o  Is there a single global resolution mechanism whereby any proxy
      can find the referenced object?
   o  If not, is there a way in which the user can find any object of
      this type, and "run his own proxy"?
   o  Are the operations mappable one-to-one (or possibly using
      modifiers) to HTTP operations?
   o  Is the type of returned objects well defined?





Hansen, et al.           Expires April 15, 2005                 [Page 8]

Internet-Draft              New URI Schemes                 October 2004



      *  as MIME content-types?
      *  as something that can be translated to HTML?
   o  Is there running code for a proxy?


2.4  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 URI usage.


   In particular:
   o  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.
   o  Is it possible to fake URIs of this type that point to different
      things in a dangerous way?
   o  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: URI, or the Kerberos login required for AFS access in the
      AFS: URI, for instance)?
   o  Does the mechanism contain passwords or other security information
      that are passed inside the referring document in the clear (as in
      the "ftp" URI, for instance)?


2.5  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 letter, 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 only scheme of its type, or
   pick another name.


2.6  Non-considerations


   Some issues that are often raised but are not relevant to new URI
   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 will be yes and sometimes no; often it will
   depend on factors (like firewalls or client configuration) not




Hansen, et al.           Expires April 15, 2005                 [Page 9]

Internet-Draft              New URI Schemes                 October 2004



   directly related to the scheme itself.


3.  URI Scheme Name Registration


3.1  General


   In order to increase the efficiency and flexibility of the URI scheme
   name registration process, the need is recognized for multiple
   registration statuses.  The registration requirements and specific
   registration procedures for each status differ, allowing the overall
   registration procedure to accommodate the different natural
   requirements for URI schemes.  For example, a scheme that will be
   recommended for wide support and implementation by the Internet
   community requires a more complete review than a scheme intended to
   be used for resources associated with proprietary software.


   The first step in registering a new URI scheme name is to determine
   which status the scheme should be registered with.  Determination of
   the proper category is based on the intended use for the new scheme
   and the desired syntax for the scheme name.


   There are two statuses of URI scheme name registration defined in
   this document: permanent and provisional.


3.1.1  The Permanent URI Scheme Name Status


   The permanent URI scheme name status is intended for URI schemes of
   general interest to the Internet community.  The status exists for
   URI schemes that require a substantive review and approval process.
   It is expected that applicability statements for particular
   applications will be published from time to time that recommend
   implementation of, and support for, URI schemes that have proven
   particularly useful in those contexts.


3.1.2  The Provisional URI Scheme Name Status


   The Provisional URI scheme name category is intended for any URI
   scheme proposed by any developer, without making any claim about its
   usefulness or the quality of its definition.  These URI scheme names
   are intended for private or experimental use.


3.2  Requirements for Scheme Name Registration


3.2.1  General Requirements


   All new URI schemes, regardless of registration status, MUST conform
   to the generic syntax for URIs as specified in RFC XXXX.





Hansen, et al.           Expires April 15, 2005                [Page 10]

Internet-Draft              New URI Schemes                 October 2004



3.2.2  Permanent URI Scheme Names


   Permanent registration of a URI scheme requires publication of the
   URI scheme syntax and semantics in either an Informational or
   Standards Track RFC.  In general, the creation of a new permanent URI
   scheme requires a Standards Track RFC.  An Informational RFC may be
   employed for registration only in the case of a URI scheme which is
   already in wide usage and meets other standards set forth in Section
   2, such as "demonstrated utility" within the Internet Architecture;
   the IESG shall have broad discretion in determining whether an
   Informational RFC is suitable in any given case, and may either
   recommend changes to such document prior to publication, or reject it
   for publication.  An Informational RFC purporting to describe a URI
   scheme shall not be published without IESG approval.  This is a
   departure from practice for Informational RFCs as set forth in RFC
   2026 [7], for the purpose of ensuring that the registration of URI
   schemes shall serve the best interests of the Internet community.


   The NAMES of permanent URI name schemes MUST NOT contain the dash
   (also known as the hyphen and minus sign) character ('-') USASCII
   value 2Dh.  Use of this character can cause confusion with private
   URI name schemes.


   An analysis of the security issues inherent in the new URI scheme is
   REQUIRED.  (This is in accordance with the basic requirements for all
   IETF protocols.) Permanent URI name schemes should not introduce
   additional security risks into the Internet Architecture.  For
   example, URIs should not embed information which should remain
   confidential, such as passwords, nor should new schemes subvert the
   security of existing schemes or protocols (i.e.  by layering or
   tunneling).


   The "owner" of a permanet URI scheme name is assumed to be the IETF
   itself.  Modification or alteration of the specification requires the
   same level of processing (e.g.  Informational or Standards Track RFC)
   as used for the initial registration.  Schemes originally defined via
   an Informational RFC may, however, be replaced with Standards Track
   documents.


3.2.3  Provisional URI Scheme Names


   Registration of a provisional URI scheme does not imply any kind of
   endorsement by the IETF, IANA or any other body.


   The main requirements for a provisional URI scheme are that it SHOULD
   have a citable specification, and there MUST NOT be a corresponding
   entry (with the same URI scheme name) with a permanent status.





Hansen, et al.           Expires April 15, 2005                [Page 11]

Internet-Draft              New URI Schemes                 October 2004



   The specification SHOULD indicate an email address for sending
   technical comments and discussion of the proposed URI scheme.


   Provisional URI name schemes MUST conform to the generic URI syntax,
   RFC XXXX.  The provisional URI name scheme's defining document MAY
   set forth additional syntax and semantics requirements above and
   beyond those specified in RFC XXXX.


   All new provisional URI schemes SHOULD follow the Guidelines for URI
   Schemes, set forth in Section 2.


   An analysis of the security issues inherent in the new URI scheme is
   encouraged.  Regardless of what security analysis is or is not
   performed, 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 associates with this scheme have not been assessed"
   or "the security issues associated with this scheme cannot be
   predicted because of <reason>".


   There is absolutely no requirement that provisional URI name schemes
   be secure or completely free from risks.  Nevertheless, the URI name
   scheme's defining document must set forth the standard for security
   considerations, and in any event all known security risks SHOULD be
   identified.


3.3  Registration Procedures


3.3.1  Permanent URI Scheme Names


   The first step in registering a new permanent URI scheme 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 provided in Section 3.5 of this
   document.  There must be an IANA considerations section in the
   Internet-Draft calling for registration of the URI scheme and
   referencing information as required by the registration template
   within the same document.


   After 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 the
   scheme to a working group (existing or new) or directly present the
   scheme 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 at such time as it has received adequate review
   and deliberation.




Hansen, et al.           Expires April 15, 2005                [Page 12]

Internet-Draft              New URI Schemes                 October 2004



   Registration of the URI scheme is then processed as part of the RFC
   publication process.


3.3.2  Provisional URI Scheme Names


   Registration of provisional URI scheme names may be submitted by one
   of the following methods:
   o  An IANA considerations section in a defining RFC, calling for
      registration of the URI scheme and referencing information as
      required by the registration template within the same document.
      Registration of the URI scheme is then processed as part of the
      RFC publication process.
   o  Send a copy of the template to the designated email discussion
      list [????].  Allow a reasonable period - at least 2 weeks - for
      discussion and comments, then send the template to IANA at the
      designated email address [????].  IANA will publish the template
      information if the requested name and the specification document
      meet the criteria noted in Section 3.2.3, unless the IESG or their
      designated expert have requested that it not be published (see
      Section 3.3.3).  IESG's designated expert should confirm to IANA
      that the registration criteria have been satisfied.


   When a new permanent URI scheme name is recorded, IANA will remove
   any corresponding entries (with the same URI scheme name and
   protocol) from the provisional registry.


   Companies and other bodies that desire a private name space for URI
   scheme names are encouraged to use a prefix based on their domain
   name, expressed in reverse order.  For example, a URI scheme name of
   com-example-info might be registered by the vendor that owns the
   example.com domain name.


3.3.3  Objections to Registration


   Listing of an entry in the provisional repository should not be
   lightly refused.  An entry MAY be refused if there is some credible
   reason to believe that such registration will be harmful.  In the
   absence of such objection, IANA SHOULD allow any registration that
   meets the criteria set out in Section 3.2.2 and Section Section
   3.2.3.  Some reasonable grounds for refusal might be:
   o  There is IETF consensus that publication is considered likely to
      harm the Internet technical infrastructure in some way.
   o  Disreputable or frivolous use of the registration facilities.
   o  The proposal is sufficiently lacking in purpose, or misleading
      about its purpose, that it can be held to be a waste of time and
      effort.
   o  Conflict with some current IETF activity.





Hansen, et al.           Expires April 15, 2005                [Page 13]

Internet-Draft              New URI Schemes                 October 2004



   Note that objections or disagreements about technical detail are not,
   of themselves, considered grounds to refuse listing in the
   provisional repository.  After all, one of its purposes is to allow
   developers to communicate with a view to combining their ideas,
   expertise and energy to the maximum benefit of the Internet
   community.


   Publication in an RFC or other form of Open Standard document (per
   RFC 2026 [7], section 7) is sufficient grounds for publication in the
   permanent registry.


   To assist IANA in determining whether or not there is a sustainable
   objection to any registration, IESG nominates a designated expert to
   liaise with IANA about new registrations.  For the most part, the
   designated expert's role is to confirm to IANA that the registration
   criteria have been satisfied.


   The IESG or their designated expert MAY require any change or
   commentary to be attached to any registry entry.


   Note: It is not an error for two different entities to register the
   same provisional URI scheme name for two different purposes.  One of
   the purposes for this registry is to help make people aware of what
   URI scheme names are being used by other entities.


   The IESG is the final arbiter of any objection.


3.4  Change Control


3.4.1  Permanent URI Scheme Names


   Permanent URI name schemes are "owned" by the IETF itself and may be
   changed, as needed, by updating the RFC that describes them.  Schemes
   described by Standards Track RFC may be replaced with new Standards
   Track RFCs.  Informational RFCs may be replaced by new Informational
   RFCs or Standards Track RFCs.


3.4.2  Provisional URI Scheme Names


   Provisional URL schemes that are undocumented may be changed by their
   owner at any time without notifying the IETF.


   Provisional URL schemes that have been documented by an Informational
   RFC, may be changed at any time by the owner.  However, an updated
   Informational RFC which details the changes made, must be submitted
   to the IESG.


   The owner of a provisional URL scheme and documented by an




Hansen, et al.           Expires April 15, 2005                [Page 14]

Internet-Draft              New URI Schemes                 October 2004



   Informational RFC may pass responsibility for the registration to
   another person or agency by informing the IESG.


   The IESG may reassign responsibility for a provisional URL scheme
   registered in an alternative tree and documented by an Informational
   RFC.  The most common case of this will be to enable changes to be
   made to schemes where the scheme name is privately owned, and the
   owner of the scheme name has died, moved out of contact or is
   otherwise unable to make changes that are important to the community.


   The IESG may reclassify a provisional URL scheme and documented via
   an Informational RFC as "historic", if it determines that the scheme
   is no longer in use.


   IANA MAY remove any provisional URI scheme entry whose corresponding
   specification document is no longer available (e.g., expired
   Internet-draft, or URI not resolvable).  Anyone may notify IANA of
   any such cases by sending an email to the designated email address
   [????].  Before removing an entry for this reason, IANA SHOULD
   contact the registered Author/Change controller to determine whether
   a replacement for the specification document (consistent with the
   requirements of section Section 3.2) is available.


3.5  New URI Scheme Registration Template


   The following issues should be addressed when documenting a new URI
   scheme:
   URI scheme name.
   Status.  This will be one of 'permanent', 'provisional' or
      'historic'.
   URI scheme syntax.  This should be expressed in a clear and concise
      manner.  The use of ABNF is encouraged.  Please refer to Section
      2.1 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 URI (e.g.  mailto:), explain the
      action that should be initiated by the consumer of the URI.  If
      there is a MIME type associated with this resource, please
      identify it.
   Applications and/or protocols which use this URI scheme name.
      Including references to documentation which defines the
      applications and/or protocols cited is especially useful.






Hansen, et al.           Expires April 15, 2005                [Page 15]

Internet-Draft              New URI Schemes                 October 2004



   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.
   Contact.  Person & email address to contact for further information.
   Author/Change controller.
   Application/protocol.  Applications and/or protocols which use this
      URI scheme name.


4.  IANA Considerations


   This document updates the Uniform Resource Identifier (URI) Schemes
   registration table.  The template has an additional field for the
   status of the URI name scheme, and the procedures for entering new
   name schemes have been augmented.  All existing URI name schemes in
   the existing table should be given the status of 'permanent'.


5.  Security Considerations


   New URI schemes are required to address all security considerations
   in their definitions.


   Information that creates or updates a registration needs to be
   authenticated.


   Information concerning possible security vulnerabilities of a
   protocol may change over time.  Consequently, claims as to the
   security properties of a registered URI scheme may change as well.
   As new vulnerabilities are discovered, information about such
   vulnerabilities may need to be attached to existing documentation, so
   that users are not misled as to the true security properties of a
   registered URI scheme.


6.  Acknowledgements


   Some of the text for the provisional registration status is based on
   [9].


7.  References


7.1  Normative References


   [1]  Moats, R., "URN Syntax", RFC 2141, May 1997.





Hansen, et al.           Expires April 15, 2005                [Page 16]

Internet-Draft              New URI Schemes                 October 2004



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


   [3]  Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
        "Guidelines for new URL Schemes", RFC 2718, November 1999.


   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.


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


   [6]  "Uniform Resource Identifiers (URI): Generic Syntax", ????.


7.2  Informative References


   [7]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.


   [8]  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
        "Uniform Resource Names (URN) Namespace Definition Mechanisms",
        BCP 66, RFC 3406, October 2002.


   [9]  Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures
        for Message Header Fields", BCP 90, RFC 3864, September 2004.



Authors' Addresses


   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA


   EMail: tony+urireg@maillennium.att.com



   Ted Hardie
   Qualcomm, Inc.
   675 Campbell Technology Parkway
   Suite 200
   Campbell, CA
   USA


   EMail: hardie@qualcomm.com






Hansen, et al.           Expires April 15, 2005                [Page 17]

Internet-Draft              New URI Schemes                 October 2004



   Larry Masinter
   Adobe Systems
   345 Park Ave
   San Jose, CA  95110
   US


   Phone: +1 408 536 3024
   EMail: LMM@acm.org
   URI:   http://larry.masinter.net











































Hansen, et al.           Expires April 15, 2005                [Page 18]

Internet-Draft              New URI Schemes                 October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Hansen, et al.           Expires April 15, 2005                [Page 19]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/