One document matched: draft-ietf-iri-4395bis-irireg-03.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
	  <!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
	  <!ENTITY rfc2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
	  <!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
	  <!ENTITY rfc3978 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3978.xml">
	  <!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
	  <!ENTITY rfc3987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
	  ]>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='no'?>
<?rfc compact='yes'?>
<!-- <?rfc-ext parse-xml-in-artwork='yes' ?> -->
<!-- <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> -->

<rfc docName="draft-ietf-iri-4395bis-irireg-03" ipr="trust200902" obsoletes="4395" category="bcp">
  <front>
    <title abbrev='New URI/IRI Schemes'>Guidelines and Registration Procedures for New URI/IRI Schemes</title>
    <author initials='T.' surname='Hansen' fullname='Tony Hansen'>
      <organization>AT&T Laboratories</organization>
      <address>
        <postal>
          <street>200 Laurel Ave.</street>
          <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>
          <country>USA</country>
        </postal>
        <email>tony+urireg@maillennium.att.com</email>
      </address>
    </author>
    <author initials='T.' surname='Hardie' fullname='Ted Hardie'>
      <organization>Panasonic Wireless Research Lab</organization>
      <address>
        <postal>
          <street>10900 Tantau Ave.</street>
          <city>Cupertino</city>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <phone>+1 408 628 5864</phone>
        <email>ted.ietf@gmail.com</email>
      </address>
    </author>
    <author initials='L.' surname='Masinter' fullname='Larry Masinter'>
      <organization>Adobe</organization>
      <address>
        <postal>
          <street>345 Park Ave.</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95110</code>
          <country>US</country>
        </postal>
        <phone>+1 408 536 3024</phone>
        <email>masinter@adobe.com</email>
        <uri>http://larry.masinter.net</uri>
      </address>
    </author>
    <date year='2011' />
    <area>Applications</area>
    <keyword>URI scheme</keyword>
    <keyword>IRI scheme</keyword>
    <keyword>IRI</keyword>
    <keyword>Internationalized Resource Identifier</keyword>
    <keyword>uniform resource identifier</keyword>
    <keyword>URI registration</keyword>
    <abstract>
      <t>
	This document updates the guidelines and recommendations for the 
        definition of Uniform Resource Identifier (URI) schemes,
        and extends the registry and guidelines to apply when 
        the schemes are used with Internationalized Resource
        Identifiers (IRIs).
	It also updates the process and IANA registry for URI/IRI schemes.
	It obsoletes RFC 4395.
      </t>
    </abstract>
  </front>
  
  <middle>
    <section title='Introduction'>
      <t>
	The Uniform Resource Identifier (URI) protocol element and generic 
        syntax is defined by <xref target='RFC3986' />.
	Each URI 
        begins with a scheme name, as defined by Section 3.1 of RFC 3986, that 
        refers to a specification for identifiers within that scheme. 
        The URI syntax provides a federated and extensible naming system,  where each 
        scheme's specification may further restrict the syntax and define the semantics of 
        identifiers using that scheme.
	As originally defined, URIs only
        allowed a limited repertoire of characters chosen from US-ASCII.
      </t>

      <t>
        An Interationalized Resource Identifier (IRI), as defined by
        <xref target='RFC3987bis' />, extends the URI syntax to allow characters
        from a much greater repertoire, to accomodate resource identifiers
        from the world's languages.
	The same schemes used in URIs are used in IRIs.
	The term Resource Identifier (RI) is used as a shorthand for both
	URIs and IRIs.
	<xref target='RFC3987' />
        introduced IRIs by defining a mapping between URIs and IRIs;
        <xref target='RFC3987bis'/> updates that definition, allowing
        an IRI to be interpreted directly without translating into a URI.
      </t>

      <t>
	This document obsoletes <xref target='RFC4395' />,
	which in turn obsoleted <xref target='RFC2717' /> and
	<xref target='RFC2718' />.
	Recent documents have used the terms "URI"/"IRI" for all 
        resource identifiers, avoiding the term "URL" and reserving the term 
        "URN" explicitly for those URIs/IRIs using the "urn" scheme name
	(<xref target='RFC2141' />).
	URN "namespaces" (<xref target='RFC3406' />) are specific to the "urn"
	scheme and are not covered explicitly by this specification.
      </t>

      <t>
	This document extends the URI scheme registry to
        be a registry of URI/IRI schemes (i.e., applicable to both
        URIs and IRIs).
	This document also provides updated guidelines for 
        the definition of new schemes, for consideration by those who are 
        defining, registering, or evaluating those definitions, as well as a 
        process and mechanism for registering URI/IRI schemes within the IANA URI 
        scheme registry.
	There is a single namespace for registered schemes.
	Within that namespace, there are values that are 
        approved as meeting a set of criteria for permanent URI/IRI schemes.
	Other scheme names may also be registered provisionally or historically,
	without necessarily meeting those criteria.
	The intent of the registry is to: 
	<t>
	</t>
        <list style='symbols'> 
          <t>
	    provide a central point of 
            discovery for established URI/IRI scheme names, and easy location of their 
            defining documents;
	  </t>

          <t>
	    discourage use of the same scheme name for different purposes;
	  </t>

          <t>
	    help those proposing new 
            scheme names to discern established trends and conventions, and 
            avoid names that might be confused with existing ones;
	  </t> 
          <t>
	    encourage registration by setting a low barrier for provisional 
	    registrations.
	  </t> 
        </list>
      </t>
      <t>
	There is no separate, independent registry or registration process for IRIs: 
	the URI Scheme Registry is to be used for both URIs and IRIs.
        Previously, those who wish to describe resource identifiers that are useful
	as IRIs were encouraged to define the corresponding URI syntax, and
	note that the IRI usage follows the rules and transformations
	defined in <xref target='RFC3987' />. This document changes
        that advice to encourage explicit definition of the scheme and
        allowable syntax elements within the larger character repertoire
        of IRIs, as defined by <xref target='RFC3987bis'/>.
      </t>
      <t>
	A scheme definition cannot override the overall syntax for IRIs.
	For example, this means that fragment identifiers (#) cannot be re-used outside
	the generic syntax restrictions, and in particular scheme-specific syntax cannot override the
	fragment identifier syntax because it is generic.
      </t>
    </section>
    <section title="Conformance Guidelines">      
      <t>
	Within this document, the key words MUST, MAY, SHOULD, REQUIRED, 
        RECOMMENDED, and so forth are used within the general meanings established
        in <xref target='RFC2119' />, within the context that they are requirements
        on future registration specifications.
      </t>
    </section>
    <section title='Guidelines for Permanent URI/IRI Scheme Definitions' anchor='guidelines'>
      <t>
	This section gives considerations for new URI/IRI schemes. 
        Meeting these guidelines is REQUIRED for permanent scheme registration.
	Meeting these guidelines is also RECOMMENDED
        for provisional registration, as described in <xref target='provguide' />.
      </t>
      <section title='Demonstratable, New, Long-Lived Utility'>
        <t>
	  The use and deployment of new URI/IRI schemes in the Internet infrastructure
	  is costly; some parts of URI/IRI processing may be scheme-dependent,
	  and deployed software already processes URIs and IRIs of well-known schemes.
	  Introducing a new scheme may require additional software, not
	  only for client software and user agents but also in additional
	  parts of the network infrastructure (gateways,
	  proxies, caches) <xref target='W3CWebArch' />.
	  URI/IRI schemes constitute a single, global namespace; it is desirable to avoid
	  contention over use of short, mnemonic scheme names. For these reasons,
	  the unbounded registration of new schemes is harmful. 
	  New URI/IRI schemes SHOULD have clear utility to the broad 
          Internet community, beyond that available with already registered URI/IRI
          schemes.
	</t>
      </section>
      
      <?rfc needLines="10" ?>
      <section title='Syntactic Compatibility' anchor='syntaxguide'>
        <t>
	  <xref target='RFC3986' /> defines the generic syntax 
          for all URI schemes, along with the syntax of common URI components 
          that are used by many URI schemes to define hierarchical identifiers. 
          <xref target='RFC3987' /> and subsequently <xref target='RFC3987bis'/>
          extended this generic syntax
          to cover IRIs.
          All URI/IRI scheme specifications MUST define their own syntax such that 
          all strings matching their scheme-specific syntax will also match the 
          <absolute&nbhy;URI> grammar described in <xref target="RFC3987bis" />. 
        </t>
        <t>
	  New schemes SHOULD reuse the common components of <xref target="RFC3987bis" /> 
          for the definition of hierarchical naming schemes. However, if there 
          is a strong reason for a scheme not to use the hierarchical 
          syntax, then the new scheme definition SHOULD follow the 
          syntax of previously registered schemes.
	</t>
        <t>
	  Schemes that are not intended for use with relative URIs/IRIs SHOULD 
          avoid use of the forward slash "/" character, which is used for 
          hierarchical delimiters, and the complete path segments "." and ".." 
          (dot-segments).
	</t>
        <t>
	  Avoid improper use of "//". The use of double slashes in the first 
          part of a URI/IRI is not an artistic indicator that what follows is a 
          URI/IRI: Double slashes are used ONLY when the syntax of the 
          <scheme-specific-part> contains a hierarchical structure.
          In URIs and IRIs from such schemes, the use of double 
          slashes indicates that what follows is the top hierarchical element 
          for a naming authority. (Section 3.2 of RFC 3986 has more 
          details.) Schemes that do not contain a conformant hierarchical 
          structure in their <scheme-specific-part> SHOULD NOT use double 
          slashes following the "<scheme>:" string.
	</t>
	<t>
	  New schemes SHOULD clearly define the role of <xref target='RFC3986' />
	  reserved characters in URIs/IRIs of the scheme being defined. The syntax	
	  of the new scheme should be clear about which of the "reserved" set	
	  of characters are used as delimiters within	
	  the URIs/IRIs of the new scheme, and when those characters must be escaped,	
	  versus when they may be used without escaping.
	</t>
      </section>
      
      <section title='Well-Defined' anchor='defguide'>
        <t>
	  While URIs/IRIs may or may not be defined as locators in practice, a
          scheme definition itself MUST be clear as to how it is expected to 
          function. Schemes that are not intended to be used as locators SHOULD 
          describe how the resource identified can be determined or accessed by 
          software that obtains a URI/IRI of that scheme.
	</t>
	<?rfc needLines="10" ?>
        <t>
	  For schemes that function as locators, it is important that the 
          mechanism of resource location be clearly defined. This might mean 
          different things depending on the nature of the scheme.
	</t>
        <t>
	  In many cases, new schemes are defined as ways to translate 
          between other namespaces or protocols and the general framework of 
          URIs. For example, the "ftp" scheme translates into the FTP 
          protocol, while the "mid" scheme translates into a Message-ID 
          identifier of an email message. For such schemes, the description of 
          the mapping must be complete, and in sufficient detail so that the 
          mapping in both directions is clear: how to map from a URI/IRI into an 
          identifier or set of protocol actions or name in the target 
          namespace, and how legal values in the base namespace, or legal 
          protocol interactions, might be represented in a valid URI or IRI. In 
          particular, the mapping should describe the mechanisms for encoding 
          binary or character strings within valid character sequences in a 
          URI/IRI (See <xref target='charguide' /> for guidelines). 
	  If not all legal values or protocol interactions of the base 
          standard can be represented using the scheme, the definition 
          should be clear about which subset are allowed, and why.
	</t>
      </section>
      
      <section title='Definition of Operations' anchor='opsdefn'>
        <t>
	  As part of the definition of how a URI/IRI identifies a resource, a 
          scheme definition SHOULD define the applicable set of 
          operations that may be performed on a resource using the RI as its 
          identifier. A model for this is HTTP; an HTTP resource can be 
          operated on by GET, POST, PUT, and a number of other operations 
          available through the HTTP protocol. The scheme definition should 
          describe all well-defined operations on the resource identifier, and what 
          they are supposed to do.
	</t>
        <t>
	  Some schemes don't fit into the "information access" paradigm 
          of URIs/IRIs. For example, "telnet" provides location information for 
          initiating a bi-directional data stream to a remote host; the only 
          operation defined is to initiate the connection. In any case, the 
          operations appropriate for a scheme should be documented.
	</t>
        <t>
	  Note: It is perfectly valid to say that "no operation apart from 
          GET is defined for this RI". It is also valid to say that "there's 
          only one operation defined for this RI, and it's not very GET-like". 
          The important point is that what is defined on this scheme is 
          described.
	</t>
      </section>
      
      <section title='Context of Use' anchor='contextofuse'>
        <t>
	  In general, URIs/IRIs are used within a broad range of protocols and	
	  applications. Most commonly, URIs/IRIs are used as references to	
	  resources within directories or hypertext documents, as hyperlinks to	
	  other resources. In some cases, a scheme is intended for use	
	  within a different, specific set of protocols or applications. If	
	  so, the scheme definition SHOULD describe the intended use and include	
	  references to documentation that define the applications and/or	
	  protocols cited.
	</t>
      </section>

      <section title='Internationalization and Character Encoding' 
               anchor='charguide'>
        <t>
	  When describing schemes in which (some of) the elements of the 
          URI or IRI are actually representations of human-readable text, care should 
          be taken not to introduce unnecessary variety in the ways in which 
          characters are encoded into octets and then into characters; see 
          <xref target='RFC3987bis' />
          and Section 2.5 of <xref target='RFC3986'/> for guidelines.
	  If URIs/IRIs of a scheme contain any text fields,
          the scheme definition MUST describe the ways in which characters
          are encoded and any compatibility issues with IRIs of the scheme.
	</t>
	<t>
          Specifications for IRIs schemes MUST be described in terms of processing
          an IRI as a sequence of Unicode codepoints, without reference to the encoding of those code points as a sequence of bytes, using UTF-8 or UTF-16.
	  The scheme specification SHOULD be as restrictive as possible regarding what characters
	  are allowed in the URI/IRI, because some characters can create several different
	  security considerations (see for example <xref target='RFC4690'/>).
	</t>
	<t>
	  All percent-encoded variants are automatically included by definition for any character given in an IRI production.
	  This means that if you want to restrict the URI percent-encoded forms in some way, you must restrict the Unicode forms that would lead to them.
	</t>
      </section>
      
      <section title='Clear Security Considerations' anchor='secguide'>
        <t>
	  Definitions of schemes MUST be accompanied by a clear 
          analysis of the security implications for systems that use the
          scheme; this follows the practice of Security Consideration sections
          within IANA registrations <xref target='RFC5226' />.
	</t>
        <t>
	  In particular, Section 7 of RFC 3986 <xref target='RFC3986'/>
          describes general security considerations for URIs, while
          Section ??? of <xref target='RFC3987bis' /> gives those
          for IRIs. 
          The definition of an individual URI/IRI
          scheme should note which of these apply to the specified scheme.
	</t>
      </section>
      
      <section title='Scheme Name Considerations' anchor='nameguide'>
        <t>
	  Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; 
          this sytax remains the same for IRIs.
          New registered schemes registrations MUST follow this syntax,
          which only allows a limited repertoire of characters (taken
          from US-ASCII). Although the syntax for the scheme name in
          URI/IRIs is case insensitive, the scheme names itself
          MUST be registered using lowercase letters.
	</t>
        <t>
	  
	  URI/IRI scheme names should be short, but also sufficiently
	  descriptive and distinguished to avoid problems.
	  
	</t>
        <t>
	  Avoid names or other symbols that might cause problems with 
          rights to use the name in IETF specifications
	  and Internet protocols. For example, be careful with
	  trademark and service mark names. (See Section 7.4 of
	  <xref target='RFC3978' />.)
	</t>
        <t>
	  Avoid using names that are either very general purpose or associated 
          in the community with some other application or protocol. Avoid 
          scheme names that are overly general or grandiose in scope (e.g., 
          that allude to their "universal" or "standard" nature.)
	</t>
        <t>
	  Organizations 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.
	</t>
      </section>
    </section>
    
    <section title='Guidelines for Provisional URI/IRI Scheme Registration' 
	     anchor='provguide'>
      <t>
	Provisional registration can be an intermediate step on the way to
	permanent registration, e.g., before the scheme specification is
	finalized. Provisional registration is also appropriate for schemes
	that are known to be used, but where a definitive specification is not
	available. There is no time limit for provisional registration.
      </t>
      
      <t>
	While the guidelines in <xref target='guidelines' /> are REQUIRED
        for permanent registration, they are RECOMMENDED 
        for provisional registration. For a provisional registration,
        the following are REQUIRED: 
	<t>
	</t>
	<list style='symbols'>
	  <t>
	    The 
            scheme name meets the syntactic requirements of
	    <xref target='nameguide' />
	    and the encoding requirements of <xref target='charguide'/>.
	  </t>
	  <t>
	    There is not already an entry with the 
            same scheme name. (In the unfortunate case that there are
            multiple, different uses of the same scheme name, the IESG may approve
            a request to modify an existing entry to note the separate use.)
          </t> 
          <t>
	    Contact information identifying the person supplying the 
            registration is included. Previously unregistered schemes 
            discovered in use may be registered by third parties 
            (even if not on behalf of those who created the scheme).
            In this case, both the registering party 
            and the scheme creator SHOULD be identified.
	  </t>
	  <t>
	    If no permanent, 
            citable specification for the scheme definition is included, 
            credible reasons for not providing it should be given.
	  </t>
	  <t>
	    A valid 
            Security Considerations section, as required by Section 6 of
	    <xref target='RFC5226'/>.
	  </t>
	  <t>
	    If the scheme definition does not meet the 
            guidelines laid out in <xref target='guidelines' />, the differences 
            and reasons SHOULD be noted.
	  </t>
	</list>
      </t>
    </section>
    <section title='Guidelines for Historical URI/IRI Scheme Registration' anchor='histguide'>
      <t>
	In some circumstances, it is appropriate to note a URI scheme that was
        once in use or registered but for whatever reason is no longer in common use
        or the use is not recommended. In this case, it is possible for an individual
        to request that the scheme be registered (newly, or as an update to an
        existing registration) as 'historical'. Any scheme that is no longer
        in common use MAY be designated as historical; the registration should
        contain some indication to where the scheme was previously defined or
        documented.
      </t>
    </section>
    
    <?rfc needLines="10" ?>
    <section title='URI/IRI Scheme Registration Procedure' anchor='process'>
      <section title='General'>
        <t>
	  The URI/IRI registration process is described in the terminology of 
          <xref target='RFC5226'/>.
	  The registration process is an optional 
          mailing list review, followed by "Expert Review".
	  The registration request should note the desired status. 
          The Designated Expert will evaluate the request against 
          the criteria of the requested status.
	  In the case of a permanent registration 
          request, the Designated Expert may:
	  <list style='symbols'>
	    <t>
	      Accept the specification of the scheme 
              for permanent registration.
	    </t>
	    <t>
	      Suggest provisional 
              registration instead.
	    </t>
	    <t>
	      Request IETF review and IESG approval; 
              in the meanwhile, suggest provisional registration.
	    </t>
	  </list>
	</t>
        <t>
	  URI/IRI scheme definitions contained within other IETF documents 
          (Informational, Experimental, or Standards-Track RFCs) must also 
          undergo Expert Review; in the case of Standards-Track documents, 
          permanent registration status approval is required.
	</t>
	
	<t>The registration procedure for URI schemes is intended to be very
	  lightweight for non-contentious registrations.  For the most part, we
	  expect the good sense of submitters and reviewers, guided by these
	  procedures, to achieve an acceptable and useful consensus for the
	  community.</t>
	
	<t> In exceptional cases, where the negotiating parties cannot form a
	  consensus, the final arbiter of any contested registration shall be the
	  IESG.</t>
	<t>
	  If parties achieve consensus on a registration proposal that does not
	  fully conform to the strict wording of this procedure, this should be
	  drawn to the attention of a relevant member of the IESG.
	</t>
	
      </section>
      
      <section title='Registration Procedures'>
        <t>
	  Someone wishing to register a new URI/IRI scheme MUST:
	  <vspace/>
	  <list style='numbers'> 
            <t>
	      Check the IANA URI scheme registry to see whether 
              or not there is already an entry for the desired name. If there is 
              already an entry under the name, choose a different URI scheme 
              name, or update the existing scheme definition.
	    </t> 
            <t>
	      Prepare a URI/IRI scheme registration template, as specified 
              in <xref target='template' />. The scheme registration 
              template may be contained in an Internet Draft, submitted alone,
              or as part of 
              some other permanently available, stable, protocol specification.
              The template may also be submitted
	      in some other form (as part of another document or as a stand-alone
	      document), but the contents will be treated as an "IETF Contribution"
	      under the guidelines of <xref target='RFC3978' />.
	    </t> 
            <t>
	      Send a copy of the template or a pointer to 
              the containing document (with specific reference to the section with 
              the template) to the mailing list
	      <eref target='uri-review@ietf.org'>uri-review@ietf.org</eref>,
	      requesting review.
	      In addition, request review on other relevant mailing lists as appropriate.
	      For example, 
	      general discussion of URI/IRI syntactical issues could be discussed on
	      uri@w3.org;
	      schemes for a network protocol could be discussed on a mailing list for that protocol.
              Allow a reasonable time for discussion and comments.
              Four weeks is reasonable for a permanent registration requests.
	    </t>
	    <t>
	      Respond to review comments and make revisions to the proposed registration
	      as needed to bring it into line with the guidelines given in this document.
	    </t>
            <t>
	      Submit the 
              (possibly updated) registration template (or pointer to document 
              containing it) to IANA at iana@iana.org, specifying 
              whether 'permanent' or 'provisional' registration is requested.
	    </t> 
          </list>
	</t>
        <t>
	  Upon receipt of a URI/IRI scheme registration request, the
          following steps MUST be followed:
	  <t>
	  </t>
	  <list style='numbers'>
	    <t>
	      IANA checks the submission for completeness; if 
              sections are missing or citations are not correct, IANA may reject the 
              registration request.
	    </t>
	    <t>
	      IANA checks the current registry for a entry 
              with the same name; if such a registry exists, IANA may reject the 
              registration request.
	    </t>
	    <t>
	      IANA requests Expert Review of the 
              registration request against the corresponding guidelines (from this document.)
	    </t>
            <t>
	      The Designated Expert may request additional review
	      or discussion, as necessary.
	    </t>
            <t>
	      If 
              Expert Review recommends registration 'provisional'
              or 'permanent' registration, IANA adds the registration to the 
              appropriate registry.
	    </t>
	    <t>
	      Unless Expert Review has explicitly 
              rejected the registration request within two weeks, IANA should automatically 
              add the registration in the 'provisional' registry.
	    </t>
	  </list>
	</t>
        <t>
	  Either based on an explicit request or independently initiated, the 
          Designated Expert or IESG may request the upgrade of a 'provisional' 
          registration to a 'permanent' one. In such cases, IANA should move 
          the corresponding entry from the provisional registry.
	</t>
      </section>
      <section title='Change Control'>
        <t>
	  Registrations may be updated in each registry by the same mechanism 
          as required for an initial registration. In cases where the original 
          definition of the scheme is contained in an IESG-approved document, 
          update of the specification also requires IESG approval.
	</t>
        <t>
	  Provisional registrations may be updated by the original registrant 
          or anyone designated by the original registrant. In addition, the IESG may reassign 
          responsibility for a provisional registration scheme, or may request
	  specific changes to a scheme registration.
          This will enable changes to be made to 
          schemes where the original registrant is out of contact, or 
          unwilling or unable to make changes.
	</t>
        <t>
	  Transition from 'provisional' to 'permanent' status may be requested
          and approved in the same manner as a new 'permanent' registration.
          Transition from 'permanent' to 'historical' status requires IESG approval.
          Transition from 'provisional' to 'historical' may be requested by anyone authorized to update the provisional registration.
	</t>
      </section>

      <section title='URI/IRI Scheme Registration Template' anchor='template'>
        <t>
	  This template describes the fields that must be supplied in a URI/IRI
          scheme registration request: 
	  <t>
	  </t>      
	  <list style='hanging' hangIndent='2'>
	    <t hangText='Resource Identifier (RI) Scheme name:'> <vspace />
	      See <xref target='nameguide' /> for guidelines.
	    </t> 
	    <t hangText='Status:'> <vspace /> This 
	      reflects the status requested, and should be one of 'permanent',  
	      'provisional', or 'historical'.
	    </t>
	    <t hangText='Scheme syntax:'> <vspace />
	      See <xref target='syntaxguide' /> for guidelines.
	    </t>
	    <t hangText='Scheme semantics:'> <vspace />
	      See <xref target='defguide' /> and <xref target='opsdefn' /> for guidelines.
	    </t>        
	    <t hangText='Encoding considerations:'> 
	      <vspace /> See <xref target='defguide' /> and <xref target='charguide' /> for guidelines.
	    </t>
	    <t hangText='Applications/protocols that use this scheme name:'> <vspace /> 
	      See <xref target='contextofuse' />.
	    </t> 
	    <t hangText='Interoperability considerations:'> <vspace />
              If the person or group registering the scheme is aware of any 
	      details regarding the scheme that might impact interoperability, 
	      identify them here. For example: proprietary or uncommon 
	      encoding methods; inability to support multibyte character sets; 
	      incompatibility with types or versions of any underlying protocol.
	    </t>
	    <t hangText='Security considerations:'><vspace />
	      See <xref target='secguide' /> for guidelines.
	    </t>
	    <t hangText='Contact:'> <vspace />
	      Person 
	      (including contact information) to contact for further information.
	    </t>
	    <t hangText='Author/Change controller:'> <vspace /> Person (including contact information)
	      authorized to change this, if a provisional registration.
	    </t>
	    <t hangText='References:'> <vspace /> Include full citations for all referenced
	      documents. Registration templates for provisional registration may
	      be included in an Internet Draft; when the documents expire or are approved for
	      publication as an RFC, the registration will be updated.
	    </t>
	  </list> 
	</t>
      </section>
    </section>
    
    <section title='The "example" Scheme'>
      <t>
	There is a need for a URI/IRI Scheme name that can be used for examples in documentation
	without fear of conflicts with current or future actual schemes.
	The URI/IRI Scheme "example" is hereby registered as a Permanent URI/IRI Scheme for that purpose.
	<list style='hanging' hangIndent='2'>
	  <t hangText='Scheme name:'>
	    example
	  </t>
	  <t hangText='Status:'>
	    permanent
	  </t>
	  <t hangText='Scheme syntax:'>
	    The entire range of allowable syntax for URI/IRI schemes specified in <xref target='RFC3987bis'/>
	    is allowed for "example" URI/IRIs.
	  </t>
	  <t hangText='Scheme semantics:'>
	    URI/IRIs in the "example" scheme should be used for documentation purposes only.
	    The use of "example" URIs/IRIs must not be used as locators, identify any resources, or
	    specify any particular set of operations.
	  </t>
	  <t hangText='Encoding considerations:'>
	    See Section 2.5 of <xref target="RFC3986"/> for guidelines.
	  </t>
	  <t hangText='Applications/protocols that use this URI scheme name:'>
	    The "example" URI should be used for documentation purposes only.
	    It MUST not be used for any protocol.
	  </t>
	  <t hangText='Interoperability considerations:'>
	    None.
	  </t>
	  <t hangText='Security considerations:'>
	    None.
	  </t>
	  <t hangText='Contact:'>
	    N/A
	  </t>
	  <t hangText='Author/Change controller:'>
	    IETF
	  </t>
	  <t hangText='References:'>
	    This RFC XXXX.
	    <vspace/>
	    RFC Editor Note: Replace XXXX with this RFC's reference.
	  </t>
	</list>
      </t>
    </section>
    <section title='IANA Considerations'>
      <t>
	Previously, the former "URL Scheme" registry was replaced by the
        Uniform Resource Identifier scheme registry.
	The process
        was based on <xref target='RFC5226' /> "Expert Review" with an initial
        (optional) mailing list review.</t><t>
	The updated template has an additional field for the status 
        of the scheme, and the procedures for entering new name 
        schemes have been augmented.
	<xref target='process' /> establishes
        the process for new URI/IRI scheme registration.
      </t>
      <t>
	IANA is requested to update the name of the registry "URI Schemes" to "URI/IRI Schemes".
	The registry should be updated to point to this document.
	For the tables within that registry
	"Permanent URI Schemes" should become "Permanent URI/IRI Schemes",
	"Provisional URI Schemes" should become "Provisional URI/IRI Schemes", and
	"Historical URI Schemes" should become "Historical URI/IRI Schemes".
      </t>
      <t>
	The example URI scheme "example" is hereby registered.
	(See the template above for registration.)
      </t>
    </section>
    
    <section title='Security Considerations'>
      <t>
	All registered values are expected to contain accurate security consideration
        sections; 'permanent' registered scheme names are expected to contain
        complete definitions.
      </t>
      <t>
	Information concerning possible security vulnerabilities of a 
        protocol may change over time. Consequently, claims as to the security 
        properties of a registered URI/IRI 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.
      </t>
    </section>
    <section title='Acknowledgements'>
      <t>
	Many thanks to Patrick Faltstrom for his comments on this version.
      </t>
      <t>
	Many thanks to Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel,
        Tony Hammond, Charles Lindsey, Mark Baker,
        and other members of the uri@w3.org
        mailing list for their comments on earlier versions.
      </t>
      <t>
	Parts of this document are based on <xref target='RFC2717' />,
	<xref target='RFC2718' /> and <xref target='RFC3864' />. Some of the ideas 
        about use of URIs were taken from the "Architecture of the World Wide 
        Web" <xref target='W3CWebArch'/>.
      </t>
    </section>
  </middle>
  <?rfc needLines="20" ?>
  <back>
    <section title="Changes Since RFC 4395">
      <t>
	<list style='numbers'>
	  <t> Significant edits to be clear that a "URI scheme" and an "IRI scheme" 
            are the same thing.</t>
	  <t>
	    Added the "example:" URL Scheme.
	  </t>
	  <t>
	    Allow for IRI-specific scheme registration.
	  </t>
	  <t>
	    Clarify that the URI scheme registry is also the IRI scheme registry.
	  </t>
	</list>
      </t>
    </section>
    <references title='Normative References'>
      &rfc2119;
      &rfc2141;
      &rfc5226;
      &rfc3978;
      &rfc3986;
      
      <reference anchor="RFC3987bis" 
		 target="http://tools.ietf.org/id/draft-ietf-iri-3987bis">
	
	<front>
          <title>Internationalized Resource Identifiers (IRIs)</title>
          <author initials="M." surname="Duerst"/>
	  <author initials="L." surname="Masinter" fullname="Larry Masinter"/>
          <author initials="M." surname="Suignard"/>
	  <date year="2010" month="September" day="31" />
        </front>
      </reference>
      
      
    </references>
    
    <references title='Informative References'>
      <?rfc include='reference.RFC.2717' ?>
      <?rfc include='reference.RFC.2718' ?>
      <?rfc include='reference.RFC.3406' ?>
      <?rfc include='reference.RFC.3864' ?>
      &rfc3987;
      <?rfc include='reference.RFC.4395' ?>
      <?rfc include='reference.RFC.4690' ?>
      <reference anchor='W3CWebArch' target='http://www.w3.org/TR/webarch/'>
        <front>
          <title>Architecture of the World Wide Web, Volume One</title>
          <author>
            <organization abbrev="W3C TAG">W3C Technical Architecture Group</organization>
          </author>
          <date year="2004" month="December"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>