draft-ietf-urlreg-procedures-07.txt   rfc2717.txt 
Ian King <iking@microsoft.com>
Speech Product Group
MICROSOFT CORPORATION
INTERNET-DRAFT R. Petke Network Working Group R. Petke
<draft-ietf-urlreg-procedures-07.txt> UUNET Technologies Request for Comments: 2717 UUNET Technologies
I. King BCP: 35 I. King
Microsoft Corporation Category: Best Current Practice Microsoft Corporation
August 12, 1999 November 1999
Registration Procedures for URL Scheme Names Registration Procedures for URL Scheme Names
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet Best Current Practices for the
all provisions of Section 10 of RFC2026. Internet-Drafts are Internet Community, and requests discussion and suggestions for
working documents of the Internet Engineering Task Force (IETF), its improvements. Distribution of this memo is unlimited.
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.
Distribution of this Internet-Draft is unlimited.
This Internet-Draft expires March 12, 2000.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document defines the process by which new URL scheme names are This document defines the process by which new URL scheme names are
registered. registered.
1.0 Introduction 1.0 Introduction
A Uniform Resource Locator (URL) is a compact string representation A Uniform Resource Locator (URL) is a compact string representation
of the location for a resource that is available via the Internet. of the location for a resource that is available via the Internet.
RFC 2396 [1] defines the general syntax and semantics of URIs, and, RFC 2396 [1] defines the general syntax and semantics of URIs, and,
by inclusion, URLs. URLs are designated by including a "<scheme>:" by inclusion, URLs. URLs are designated by including a "<scheme>:"
and then a "<scheme-specific-part>". Many URL schemes are already and then a "<scheme-specific-part>". Many URL schemes are already
defined, however, new schemes may need to be defined in the future defined, however, new schemes may need to be defined in the future in
in order to accommodate new Internet protocols and/or procedures. order to accommodate new Internet protocols and/or procedures.
A registration process is needed to ensure that the names of all A registration process is needed to ensure that the names of all such
such new schemes are guaranteed not to collide. Further, the new schemes are guaranteed not to collide. Further, the registration
registration process ensures that URL schemes intended for wide process ensures that URL schemes intended for wide spread, public use
spread, public use are developed in an orderly, well-specified, and are developed in an orderly, well-specified, and public manner.
public manner.
This document defines the registration procedures to be followed This document defines the registration procedures to be followed when
when new URL schemes are created. A separate document, RFC new URL schemes are created. A separate document, RFC 2718,
[URL-GUIDELINES], Guidelines for URL Schemes [2], provides Guidelines for URL Schemes [2], provides guidelines for the creation
guidelines for the creation of new URL schemes. The primary focus of new URL schemes. The primary focus of this document is on the
of this document is on the <scheme> portion of new URL schemes, <scheme> portion of new URL schemes, referred to as the "scheme name"
referred to as the "scheme name" throughout this document. throughout this document.
1.1 Notation 1.1 Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2.0 URL Scheme Name Registration Trees 2.0 URL Scheme Name Registration Trees
2.1 General 2.1 General
In order to increase the efficiency and flexibility of the URL In order to increase the efficiency and flexibility of the URL scheme
scheme name registration process, the need is recognized for name registration process, the need is recognized for multiple
multiple registration "trees". The registration requirements and registration "trees". The registration requirements and specific
specific registration procedures for each tree differ, allowing the registration procedures for each tree differ, allowing the overall
overall registration procedure to accommodate the different natural registration procedure to accommodate the different natural
requirements for URL schemes. For example, a scheme that will be requirements for URL schemes. For example, a scheme that will be
recommended for wide support and implementation by the Internet recommended for wide support and implementation by the Internet
community requires a more complete review than a scheme intended to community requires a more complete review than a scheme intended to
be used for resources associated with proprietary software. be used for resources associated with proprietary software.
The first step in registering a new URL scheme name is to determine The first step in registering a new URL scheme name is to determine
which registration tree the scheme should be registered in. which registration tree the scheme should be registered in.
Determination of the proper registration tree is based on the Determination of the proper registration tree is based on the
intended use for the new scheme and the desired syntax for the intended use for the new scheme and the desired syntax for the scheme
scheme name. name.
This document will discuss in detail the tree that reflects current This document will discuss in detail the tree that reflects current
practice, under IETF ownership and control. It will also set forth practice, under IETF ownership and control. It will also set forth
an outline to assist authors in creating new trees to address an outline to assist authors in creating new trees to address
differing needs for wide acceptance and interoperability, ease of differing needs for wide acceptance and interoperability, ease of
creation and use, and type and "strength" of ownership. creation and use, and type and "strength" of ownership.
2.2 The IETF Tree 2.2 The IETF Tree
The IETF tree is intended for URL schemes of general interest to the The IETF tree is intended for URL schemes of general interest to the
skipping to change at line 114 skipping to change at page 3, line 10
applicability statements for particular applications will be applicability statements for particular applications will be
published from time to time that recommend implementation of, and published from time to time that recommend implementation of, and
support for, URL schemes that have proven particularly useful in support for, URL schemes that have proven particularly useful in
those contexts. those contexts.
2.3 Additional Registration Trees 2.3 Additional Registration Trees
From time to time and as required by the community, the IESG may From time to time and as required by the community, the IESG may
create new top-level registration trees. These trees may require create new top-level registration trees. These trees may require
significant, little or no registration, and may allow change control significant, little or no registration, and may allow change control
to rest in the hands of individuals or groups other than IETF. A to rest in the hands of individuals or groups other than IETF. A new
new tree should only be created if no existing tree can be shown to tree should only be created if no existing tree can be shown to
address the set of needs of some sector of the community. address the set of needs of some sector of the community.
3.0 Requirements for Scheme Name Registration 3.0 Requirements for Scheme Name Registration
3.1 General Requirements 3.1 General Requirements
All new URL schemes, regardless of registration tree, MUST conform All new URL schemes, regardless of registration tree, MUST conform to
to the generic syntax for URLs as specified in RFC 2396. the generic syntax for URLs as specified in RFC 2396.
3.2 The IETF Tree 3.2 The IETF Tree
Registration in the IETF tree requires publication of the URL scheme Registration in the IETF tree requires publication of the URL scheme
syntax and semantics in either an Informational or Standards Track syntax and semantics in either an Informational or Standards Track
RFC. RFC. In general, the creation of a new URL scheme requires a
Standards Track RFC. An Informational RFC may be employed for
registration only in the case of a URL scheme which is already in
wide usage and meets other standards set forth in RFC 2718, 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 URL scheme shall not be
published without IESG approval. This is a departure from practice
for Informational RFCs as set forth in RFC 2026, for the purpose of
ensuring that the registration of URL schemes shall serve the best
interests of the Internet community.
The NAMES of schemes registered in the IETF tree MUST NOT contain The NAMES of schemes registered in the IETF tree MUST NOT contain the
the dash (also known as the hyphen and minus sign) character ('-') dash (also known as the hyphen and minus sign) character ('-')
USASCII value 2Dh. Use of this character can cause confusion with USASCII value 2Dh. Use of this character can cause confusion with
schemes registered in alternative trees (see section 3.3). schemes registered in alternative trees (see section 3.3).
An analysis of the security issues inherent in the new URL scheme An analysis of the security issues inherent in the new URL scheme is
is REQUIRED. (This is in accordance with the basic requirements for REQUIRED. (This is in accordance with the basic requirements for all
all IETF protocols.) URL schemes registered in the IETF tree should IETF protocols.) URL schemes registered in the IETF tree should not
not introduce additional security risks into the Internet Architec- introduce additional security risks into the Internet Architecture.
ture. For example, URLs should not embed information which should For example, URLs should not embed information which should remain
remain confidential, such as passwords, nor should new schemes confidential, such as passwords, nor should new schemes subvert the
subvert the security of existing schemes or protocols (i.e. by security of existing schemes or protocols (i.e. by layering or
layering or tunneling). tunneling).
The "owner" of a URL scheme name registered in the IETF tree is The "owner" of a URL scheme name registered in the IETF tree is
assumed to be the IETF itself. Modification or alteration of the assumed to be the IETF itself. Modification or alteration of the
specification requires the same level of processing (e.g. specification requires the same level of processing (e.g.
Informational or Standards Track RFC) as used for the initial Informational or Standards Track RFC) as used for the initial
registration. Schemes originally defined via an Informational RFC registration. Schemes originally defined via an Informational RFC
may, however, be replaced with Standards Track documents. may, however, be replaced with Standards Track documents.
3.3 Alternative Trees 3.3 Alternative Trees
While public exposure and review of a URL scheme created in an While public exposure and review of a URL scheme created in an
alternative tree is not required, using the IETF Internet-Draft alternative tree is not required, using the IETF Internet-Draft
mechanism for peer review is strongly encouraged to improve the mechanism for peer review is strongly encouraged to improve the
quality of the specification. RFC publication of alternative tree quality of the specification. RFC publication of alternative tree
URL schemes is encouraged but not required. Material may be URL schemes is encouraged but not required. Material may be
published as an Informational RFC by sending it to the RFC Editor published as an Informational RFC by sending it to the RFC Editor
(please follow the instructions to RFC authors, RFC 2223 [3]). (please follow the instructions to RFC authors, RFC 2223 [3]).
The defining document for an alternative tree may require public The defining document for an alternative tree may require public
exposure and/or review for schemes defined in that tree via a exposure and/or review for schemes defined in that tree via a
mechanism other than the IETF Internet-Draft mechanism. mechanism other than the IETF Internet-Draft mechanism.
URL schemes created in an alternative tree must conform to the URL schemes created in an alternative tree must conform to the
generic URL syntax, RFC 2396. The tree's defining document may set generic URL syntax, RFC 2396. The tree's defining document may set
forth additional syntax and semantics requirements above and forth additional syntax and semantics requirements above and beyond
beyond those specified in RFC 2396. those specified in RFC 2396.
All new URL schemes SHOULD follow the Guidelines for URL Schemes, All new URL schemes SHOULD follow the Guidelines for URL Schemes, set
set forth in RFC [URL-GUIDELINES] [2]. forth in RFC 2718 [2].
An analysis of the security issues inherent in the new URL scheme is An analysis of the security issues inherent in the new URL scheme is
encouraged. Regardless of what security analysis is or is not encouraged. Regardless of what security analysis is or is not
performed, all descriptions of security issues must be as accurate performed, all descriptions of security issues must be as accurate as
as possible. In particular, a statement that there are "no security possible. In particular, a statement that there are "no security
issues associated with this scheme" must not be confused with "the issues associated with this scheme" must not be confused with "the
security issues associates with this scheme have not been assessed" security issues associates with this scheme have not been assessed"
or "the security issues associated with this scheme cannot be or "the security issues associated with this scheme cannot be
predicted because of <reason>". predicted because of <reason>".
There is absolutely no requirement that URL schemes created in an There is absolutely no requirement that URL schemes created in an
alternative tree be secure or completely free from risks. alternative tree be secure or completely free from risks.
Nevertheless, the tree's defining document must set forth the Nevertheless, the tree's defining document must set forth the
standard for security considerations, and in any event all known standard for security considerations, and in any event all known
security risks SHOULD be identified. security risks SHOULD be identified.
Change control must be defined for a new tree. Change control may Change control must be defined for a new tree. Change control may be
be vested in the IETF, or in an individual, group or other entity. vested in the IETF, or in an individual, group or other entity. The
The change control standard for the tree must be approved by the change control standard for the tree must be approved by the IESG.
IESG.
The syntax for alternative trees shall be as follows: each tree will The syntax for alternative trees shall be as follows: each tree will
be identified by a unique prefix, which must be established in the be identified by a unique prefix, which must be established in the
same fashion as a URL scheme name in the IETF tree, except that the same fashion as a URL scheme name in the IETF tree, except that the
prefix must be defined by a Standards Track document. Scheme names prefix must be defined by a Standards Track document. Scheme names
in the new tree are then constructed by prepending the prefix to an in the new tree are then constructed by prepending the prefix to an
identifier unique to each scheme in that tree, as prescribed by that identifier unique to each scheme in that tree, as prescribed by that
tree's identifying document: tree's identifying document:
<prefix>'-'<tree-specific identifier> <prefix>'-'<tree-specific identifier>
For instance, the "foo" tree would allow creation of scheme names of For instance, the "foo" tree would allow creation of scheme names of
the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes
an arbitrary USASCII string following the tree's unique prefix. an arbitrary USASCII string following the tree's unique prefix.
4.0 Registration Procedures 4.0 Registration Procedures
4.1 The IETF Tree 4.1 The IETF Tree
The first step in registering a new URL scheme in the IETF tree is The first step in registering a new URL scheme in the IETF tree is to
to publish an IETF Internet-Draft detailing the syntax and publish an IETF Internet-Draft detailing the syntax and semantics of
semantics of the proposed scheme. The draft must, minimally, the proposed scheme. The draft must, minimally, address all of the
address all of the items covered by the template provided in section items covered by the template provided in section 6 of this document.
6 of this document.
After all issues raised during a review period of no less than 4 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. weeks have been addressed, submit the draft to the IESG for review.
The IESG will review the proposed new scheme and either refer the 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 a working group (existing or new) or directly present the
scheme to the IESG for a last call. In the former case, the working 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 group is responsible for submitting a final version of the draft to
the IESG for approval at such time as it has received adequate the IESG for approval at such time as it has received adequate review
review and deliberation. and deliberation.
4.2 Alternative Trees 4.2 Alternative Trees
Registration of URL schemes created in an alternative tree may be Registration of URL schemes created in an alternative tree may be
formal, through IETF documents, IANA registration, or other formal, through IETF documents, IANA registration, or other
acknowledged organization; informal, through a mailing list or acknowledged organization; informal, through a mailing list or other
other publication mechanism; or nonexistent. The registration publication mechanism; or nonexistent. The registration mechanism
mechanism must be documented for each alternative tree, and must be must be documented for each alternative tree, and must be consistent
consistent for all URL scheme names created in that tree. for all URL scheme names created in that tree.
It is the responsibility of the creator of the tree's registration It is the responsibility of the creator of the tree's registration
requirements to establish that the registration mechanism is requirements to establish that the registration mechanism is workable
workable as described; it is within the discretion of the IESG to as described; it is within the discretion of the IESG to reject the
reject the document describing a tree if it determines the document describing a tree if it determines the registration
registration mechanism is impractical or creates an undue burden on mechanism is impractical or creates an undue burden on a party who
a party who will not accept it. (For instance, if an IANA will not accept it. (For instance, if an IANA registration mechanism
registration mechanism is proposed, IESG might reject the tree if is proposed, IESG might reject the tree if its mechanism would create
its mechanism would create undue liability on the part of IANA.) undue liability on the part of IANA.)
While the template in section 6 of this document is intended to While the template in section 6 of this document is intended to apply
apply to URL scheme names in the IETF tree, it is also offered as a to URL scheme names in the IETF tree, it is also offered as a
guideline for those documenting alternative trees. guideline for those documenting alternative trees.
5.0 Change Control 5.0 Change Control
5.1 Schemes in the IETF Tree 5.1 Schemes in the IETF Tree
URL schemes created in the IETF tree are "owned" by the IETF itself URL schemes created in the IETF tree are "owned" by the IETF itself
and may be changed, as needed, by updating the RFC that describes and may be changed, as needed, by updating the RFC that describes
them. Schemes described by Standards Track RFC but be replaced with them. Schemes described by Standards Track RFC but be replaced with
new Standards Track RFCs. Informational RFCs may be replaced by new new Standards Track RFCs. Informational RFCs may be replaced by new
Informational RFCs or Standards Track RFCs. Informational RFCs or Standards Track RFCs.
5.2 Schemes in Alternative Trees 5.2 Schemes in Alternative Trees
URL schemes in an alternative tree that are undocumented (as allowed URL schemes in an alternative tree that are undocumented (as allowed
by that tree's rules) may be changed by their owner at any time by that tree's rules) may be changed by their owner at any time
without notifying the IETF. without notifying the IETF.
URL schemes created in an alternative tree that have been documented URL schemes created in an alternative tree that have been documented
by an Informational RFC, may be changed at any time by the owner, by an Informational RFC, may be changed at any time by the owner,
however, an updated Informational RFC which details the changes however, an updated Informational RFC which details the changes made,
made, must be submitted to the IESG. must be submitted to the IESG.
The owner of a URL scheme registered in an alternative tree and The owner of a URL scheme registered in an alternative tree and
documented by an Informational RFC may pass responsibility for the documented by an Informational RFC may pass responsibility for the
registration to another person or agency by informing the IESG. registration to another person or agency by informing the IESG.
The IESG may reassign responsibility for a URL scheme registered in The IESG may reassign responsibility for a URL scheme registered in
an alternative tree and documented by an Informational RFC. The an alternative tree and documented by an Informational RFC. The most
most common case of this will be to enable changes to be made to common case of this will be to enable changes to be made to schemes
schemes where the scheme name is privately owned by the rules of its where the scheme name is privately owned by the rules of its tree,
tree, and the owner of the scheme name has died, moved out of and the owner of the scheme name has died, moved out of contact or is
contact or is otherwise unable to make changes that are important to otherwise unable to make changes that are important to the community.
the community.
The IESG may reclassify a URL scheme created in an alternative tree The IESG may reclassify a URL scheme created in an alternative tree
and documented via an Informational RFC as "historic" if it and documented via an Informational RFC as "historic" if it
determines that the scheme is no longer in use. determines that the scheme is no longer in use.
6.0 Registration Template 6.0 Registration Template
The following issues should be addressed when documenting a new URL The following issues should be addressed when documenting a new URL
scheme: scheme:
URL scheme name. URL scheme name.
URL scheme syntax. This should be expressed in a clear and URL scheme syntax. This should be expressed in a clear and
concise manner. The use of ABNF is encouraged. Please refer to concise manner. The use of ABNF is encouraged. Please refer to
RFC [URL-GUIDELINES] for guidance on designing and explaining RFC 2718 for guidance on designing and explaining your scheme's
your scheme's syntax. syntax.
Character encoding considerations. It is important to identify Character encoding considerations. It is important to identify
what your scheme supports in this regard. It is obvious that for what your scheme supports in this regard. It is obvious that for
interoperability, it is best if there is a means to support interoperability, it is best if there is a means to support
character sets beyond USASCII, but especially for private character sets beyond USASCII, but especially for private schemes,
schemes, this may not be the case. this may not be the case.
Intended usage. What sort of resource is being identified? If Intended usage. What sort of resource is being identified? If
this is not a 'resource' type of URL (e.g. mailto:), explain the this is not a 'resource' type of URL (e.g. mailto:), explain the
action that should be initiated by the consumer of the URL. If action that should be initiated by the consumer of the URL. If
there is a MIME type associated with this resource, please there is a MIME type associated with this resource, please
identify it. identify it.
Applications and/or protocols which use this URL scheme name. Applications and/or protocols which use this URL scheme name.
Including references to documentation which defines the Including references to documentation which defines the
applications and/or protocols cited is especially useful. applications and/or protocols cited is especially useful.
Interoperability considerations. If you are aware of any details Interoperability considerations. If you are aware of any details
regarding your scheme which might impact interoperability, please regarding your scheme which might impact interoperability, please
identify them here. For example: proprietary or uncommon identify them here. For example: proprietary or uncommon encoding
encoding method; inability to support multibyte character sets; method; inability to support multibyte character sets;
incompatibility with types or versions of underlying protocol incompatibility with types or versions of underlying protocol (if
(if scheme is tunneled over another protocol). scheme is tunneled over another protocol).
Security considerations. Security considerations.
Relevant publications. Relevant publications.
Person & email address to contact for further information. Person & email address to contact for further information.
Author/Change controller. Author/Change controller.
Applications and/or protocols which use this URL scheme name. Applications and/or protocols which use this URL scheme name.
7.0 Security Considerations 7.0 Security Considerations
Information that creates or updates a registration needs to be Information that creates or updates a registration needs to be
authenticated. authenticated.
Information concerning possible security vulnerabilities of a Information concerning possible security vulnerabilities of a
protocol may change over time. Consequently, claims as to the protocol may change over time. Consequently, claims as to the
security properties of a registered URL scheme may change as well. security properties of a registered URL scheme may change as well.
As new vulnerabilities are discovered, information about such As new vulnerabilities are discovered, information about such
vulnerabilities may need to be attached to existing documentation, vulnerabilities may need to be attached to existing documentation, so
so that users are not misled as to the true security properties of a that users are not misled as to the true security properties of a
registered URL scheme. registered URL scheme.
If the IESG agrees to delegate the registration and change control If the IESG agrees to delegate the registration and change control
functions of an alternative tree to a group or individual outside of functions of an alternative tree to a group or individual outside of
the IETF, that group or individual should have sufficient security the IETF, that group or individual should have sufficient security
procedures in place to authenticate registration changes. procedures in place to authenticate registration changes.
8.0 References 8.0 References
[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998 Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[2] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., [2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"Guidelines for new URL Schemes", RFC [URL-GUIDELINES], August "Guidelines for new URL Schemes", RFC 2718, November 1999.
1998
[3] Postel, J., Reynolds, J., "Instructions to RFC Authors", [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
RFC 2223, October 1997. 2223, October 1997.
9.0 Authors' Address 9.0 Authors' Addresses
Rich Petke Rich Petke
UUNET Technologies UUNET Technologies
5000 Britton Road 5000 Britton Road
P. O. Box 5000 P. O. Box 5000
Hilliard, OH 43026-5000 Hilliard, OH 43026-5000
USA USA
Phone: +1 614 723 4157 Phone: +1 614 723 4157
Fax: +1 614 723 8407 Fax: +1 614 723 8407
Email: rpetke@wcom.net EMail: rpetke@wcom.net
Ian King Ian King
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Phone: +1 425-703-2293 Phone: +1 425-703-2293
FAX: +1 425-936-7329 Fax: +1 425-936-7329
Email: iking@microsoft.com EMail: iking@microsoft.com
10. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 38 change blocks. 
122 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/