[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
Obsoletes: 2717,2718 (if approved)                             T. Hardie
Expires: July 4, 2005                                     Qualcomm, Inc.
                                                             L. Masinter
                                                           Adobe Systems
                                                         January 3, 2005


      Guidelines and Registration Procedures for  new URI Schemes
           draft-hansen-2717bis-2718bis-uri-guidelines-02.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 July 4, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides guidelines and recommendations for the
   definition of new URI schemes, and a mechanism to register those URI
   schemes.  The registration requirements have been simplified by
   providing for provisional registrations that need no technical review



Hansen, et al.            Expires July 4, 2005                  [Page 1]

Internet-Draft              New URI Schemes                 January 2005


   and may share names with existing scheme names.

   Please send comments to uri@w3.org [10].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Guidelines for new URI schemes . . . . . . . . . . . . . . . .  4
     2.1   Demonstratable, new, long-lived utility  . . . . . . . . .  4
     2.2   Syntactic compatibility  . . . . . . . . . . . . . . . . .  4
     2.3   Well-Defined . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4   Definition of operations . . . . . . . . . . . . . . . . .  5
     2.5   Character encoding . . . . . . . . . . . . . . . . . . . .  6
     2.6   Clear security considerations  . . . . . . . . . . . . . .  6
     2.7   Scheme Name considerations . . . . . . . . . . . . . . . .  6
   3.  URI Scheme Registration Procedure  . . . . . . . . . . . . . .  7
     3.1   General  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2   Provisional URI Scheme Considerations  . . . . . . . . . .  8
     3.3   Registration Procedures  . . . . . . . . . . . . . . . . .  8
     3.4   Change Control . . . . . . . . . . . . . . . . . . . . . .  9
     3.5   New URI Scheme Registration Template . . . . . . . . . . . 10
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 12
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14






















Hansen, et al.            Expires July 4, 2005                  [Page 2]

Internet-Draft              New URI Schemes                 January 2005


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 both 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' has been difficult to draw: 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, 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.  RFC 2717 proposed that additional registration
   trees might be approved by the IESG, however, no such registration
   trees have been approved.

   This document eliminates RFC 2717's distinction between different
   'trees' for URI schemes; instead there is 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 any review process or criteria.  The intent of the registry
   is to:
   o  provide a low barrier for provisional registrations of URI scheme
      names
   o  provide a central point of discovery for established URI scheme
      names, and easy location of their defining documents;
   o  discourage, but not prevent, multiple definitions of URI scheme
      names for different purposes;




Hansen, et al.            Expires July 4, 2005                  [Page 3]

Internet-Draft              New URI Schemes                 January 2005


   o  help those proposing new URI scheme names to discern established
      trends and conventions, and avoid names that might be confused
      with existing ones.

2.  Guidelines for new URI schemes

   This section gives some considerations when defining new URI schemes.
   These are useful for all schemes (whether or not standards track);
   IETF standards track URI schemes may require review against these
   criteria.

2.1  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.2  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.

   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.

   If there is a strong reason for a URI scheme to not use the RFC XXXX
   syntax, the new scheme definition should follow the syntax of other
   previously registered schemes, if possible.

   Avoid improper use of "//".  The use of double slashes in the first
   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 that do not contain a conformant hierarchical structure
   in their <scheme-specific-part> should not use double slashes
   following the "<scheme>:" string.

2.3  Well-Defined

   While URIs may or may not be useful as locators in practice, a URI
   scheme definition itself should be clear as to how it is expected to



Hansen, et al.            Expires July 4, 2005                  [Page 4]

Internet-Draft              New URI Schemes                 January 2005


   function.  Schemes that are not intended to be used as locators
   should still describe how the resource indicated can be identified by
   software that obtains a URI of that scheme.

   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 URI scheme.

   In many cases, new URI schemes are defined as ways to translate other
   protocols and name spaces into the general framework of URIs.  For
   example, the "ftp" URI scheme translates from the FTP protocol, while
   the "mid" URI scheme translates from the Message-ID field of
   messages.  For such schemes, 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 and other artifacts from the base standards are
   included or not included.  These requirements are elaborated below.

   In some cases, URI schemes do not have particular network protocols
   associated with them, because their use as a locator 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, the contexts of use, and a complete mapping of the locator
   from its source.

2.4  Definition of operations

   In addition to the definition of how a URI identifies a resource, a
   URI scheme definition should also define, if applicable, the set of
   operations that may be performed on a resource using the URI as its
   identifier.  The basis for this model is HTTP; a HTTP resource can be
   operated on by GET, POST, PUT and a number of other operations
   available through the HTTP protocol.  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.




Hansen, et al.            Expires July 4, 2005                  [Page 5]

Internet-Draft              New URI Schemes                 January 2005


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.

2.6  Clear security considerations

   Definitions of URI schemes should be accompanied by a clear analysis
   of the security implications for systems that use the URI scheme.
   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)?
   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)?
   o  URI schemes should not subvert the security of existing schemes or
      protocols (e.g., by layering or tunneling).

2.7  Scheme Name considerations

   URI scheme names should be short, but also sufficiently descriptive
   and distinguished to avoid problems.

   Avoid trademark names or other symbols that might have problems with
   the 'ownership' or rights to use the name in Internet protocols.

   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 when the
   described namespace is not.)

   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



Hansen, et al.            Expires July 4, 2005                  [Page 6]

Internet-Draft              New URI Schemes                 January 2005


   name.

3.  URI Scheme Registration Procedure

3.1  General

   The goals for registering URI Schemes are to avoid (when possible)
   duplicate use of the same URI scheme name for different purposes, to
   allow implementors of software that processes URIs to find
   appropriate information about URI schemes, and to encourage and
   facilitate technical review of URI scheme definitions before
   corresponding software is deployed.

   To allow others to determine the results of technical review, the URI
   scheme registration process has two outcomes for URI scheme
   proposals: a 'provisional' status for URI schemes whose definitions
   have not been reviewed or were not accepted by the review process,
   and a 'permanent' status for those schemes that have been accepted by
   IETF review.  Review is based on general agreement that the URI
   scheme definition proposed meets the requirements in Section 2.

   Provisional status is useful for registering legacy URI schemes that
   have already been widely deployed without registration, and for which
   review at this time would be inappropriate.  Provisional status may
   also be useful for private or experimental use.

   Permanent status is intended for use by IETF standards-track
   protocols.  The status requires a substantive review and approval
   process.

   A person wishing to register a URI scheme should first determine
   whether the scheme is appropriate for 'permanent' status, meets the
   guidelines, and if 'permanent' status is desirable.

   Provisional registration of a URI scheme merely requires providing
   IANA with the information in the URI scheme registration template
   (Section 3.5).  It is useful to also provide this information in an
   Internet Draft, especially if the scheme is intended for ultimate
   registration as a 'permanent' URI scheme.

   Permanent registration of a URI scheme requires IETF review and IESG
   approval.  In many cases, permanent registration involves the
   promotion of an existing provisional registration.  In general, the
   creation of a new permanent URI scheme requires a Standards Track
   RFC.  In some cases, a URI scheme registration in an Informational
   RFC may be approved by the IESG for 'permanent' URI registration.





Hansen, et al.            Expires July 4, 2005                  [Page 7]

Internet-Draft              New URI Schemes                 January 2005


3.2  Provisional URI Scheme Considerations

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

   The main requirement for a provisional URI scheme is that there MUST
   NOT already be a corresponding permanent entry with the same URI
   scheme name.  In cases where separate communities have already
   established differing uses of the same URI scheme name for different
   purposes, it is possible to have two or more provisional
   registrations for the same URI scheme name.

   A provisional registration MUST also identify the person submitting
   the registration, and SHOULD contain a citable specification for the
   URI scheme definition, unless credible reasons for not providing this
   are given.

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

   In particular, 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 not a requirement that
   provisional URI name schemes be secure or completely free from risks,
   but all known security risks SHOULD be identified.

   Previously unregistered URI schemes discovered in use may be
   registered by third parties on behalf of those who created the URI
   scheme.

3.3  Registration Procedures

   Someone wishing to register a URI scheme should:
   1.  Check the IANA URI scheme registry to see whether or not there is
       already an entry for the desired name.  If there is already a
       permanent entry under the name, choose a different URI scheme
       name.
   2.  Prepare a URI scheme registration template, as specified in
       Section 3.5.  The URI scheme registration template may be
       contained in an Internet Draft, to facilitate discussion or if
       the URI scheme is intended for permanent status.
   3.  If desired, send a copy of the template or a pointer to the
       Internet Draft (and containing section number) to the mailing



Hansen, et al.            Expires July 4, 2005                  [Page 8]

Internet-Draft              New URI Schemes                 January 2005


       list uri-review@ietf.org; participate in the discussion and
       review of the URI scheme; allow a reasonable period (at least 2
       weeks) for discussion and comments.
   4.  Submit the registration template (or a pointer to the Internet
       Draft and containing section number) to IANA at iana@iana.org
       [11].

   Upon receipt of a URI scheme registration request, IANA:
   1.  Checks the submission for completeness; if sections are missing
       or citations are not correct, IANA rejects the registration
       request.
   2.  Checks the current registry for a 'permanent' entry of that name;
       if such a registry exists, IANA rejects the registration request.
   3.  Adds the registration to the 'provisional' registry.

   Registration of a 'permanent' URI scheme happens through the approval
   of publication of an RFC that contains instructions for registration
   in the 'IANA considerations' section of the document.  The IETF
   review should consider whether the URI scheme meets the guidelines in
   Section 2; in addition, permanent registration when there are
   multiple provisional registrations for the same scheme name should be
   avoided.

   In some cases, a new 'permanent' URI scheme will upgrade a previous
   'provisional' registration; IANA should remove the corresponding
   entry from the provisional registry, unless the IANA considerations
   section specifies otherwise.

3.4  Change Control

   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.

   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 that details the changes made, must be submitted to
   the IESG.

   The owner of a provisional URL scheme and documented by an
   Informational RFC may pass responsibility for the registration to
   another person or agency by informing the IESG.




Hansen, et al.            Expires July 4, 2005                  [Page 9]

Internet-Draft              New URI Schemes                 January 2005


   The IESG may reassign responsibility for a provisional URL scheme
   that had been 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.

   A URL scheme that has been registered by a third party may be
   reassigned to the proper owners of that scheme name.

   The IESG may reclassify a URI scheme as "historic", if it determines
   that the scheme is no longer in use.  (This may be done in
   conjunction with marking a protocol as "historic".)

   IANA may remove any provisional URI scheme entry whose corresponding
   specification document is no longer available (e.g., the
   Internet-draft expired, or the URL citation is no longer resolvable).
   Anyone may notify IANA of any such cases by sending an email to
   iana@iana.org [12].  Before removing an entry for this reason, IANA
   SHOULD contact the registered Author/Change controller to determine
   whether a replacement for the specification document 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
      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 that use this URI scheme name.
      Including references to documentation that defines the
      applications and/or protocols cited is especially useful.






Hansen, et al.            Expires July 4, 2005                 [Page 10]

Internet-Draft              New URI Schemes                 January 2005


   Interoperability considerations.  If you are aware of any details
      regarding your scheme that 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 any underlying protocol
      (if the scheme is tunneled over another protocol).
   Security considerations.
   Relevant publications.  For the case of provisional URI scheme
      entries, this may be the URL of a document more completely
      describing the scheme.
   Contact.  Person & email address to contact for further information.
   Author/Change controller.
   Application/protocol.  Applications and/or protocols that 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'.

   This document updates the procedures to be followed by IANA when
   receiving a URI scheme name registration template.

5.  Security Considerations

   New URI schemes are expected 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

   Thanks go to Paul Hoffmann who contributed significantly to the
   development of this document.  Thanks also go to Ira McDonald and the
   members of the uri@w3.org [13] mailing list for their comments on
   earlier drafts.



Hansen, et al.            Expires July 4, 2005                 [Page 11]

Internet-Draft              New URI Schemes                 January 2005


   Parts of this document are based on [2], [3] and [9].

7.  References

7.1  Normative References

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

   [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]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifier (URI): Generic Syntax", October 2004.

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.

URIs

   [10]  <mailto:uri@w3.org>

   [11]  <mailto:iana@iana.org>

   [12]  <mailto:iana@iana.org>

   [13]  <mailto:uri@w3.org>







Hansen, et al.            Expires July 4, 2005                 [Page 12]

Internet-Draft              New URI Schemes                 January 2005


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


   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 July 4, 2005                 [Page 13]

Internet-Draft              New URI Schemes                 January 2005


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 (2005).  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 July 4, 2005                 [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/