Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations W3C/IETF 合同 IETF 計画関係部会報告: 統一資源識別子 (URI), URL および統一資源名 (URN): 明確化と勧告
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document, a product of the W3C Uniform Resource Identifier (URI) Interest Group, addresses and attempts to clarify issues pertaining to URIs. This document addresses how URI space is partitioned and the relationship between URIs, URLs, and URNs, describes how URI schemes and URN namespaces ids are registered, and presents recommendations for continued work on this subject.
この文書は、 W3C 統一資源識別子 (URI) 関係部会の成果物であり、 URI に関係する問題について言及、明確化しようとするものです。 この文書はどう URI 空間を区画化するかや URI, URL, URN の関係に触れ、どう URI 方式や URN 名前空間識別子を登録するかを説明し、 この問題についての継続作業の勧告を述べます。
1. The W3C URI Interest Group . . . . . . . . . . . . . . . . 2
2. URI Partitioning . . . . . . . . . . . . . . . . . . . . . 2
2.1 Classical View . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Contemporary View . . . . . . . . . . . . . . . . . . . . 3
2.3 Confusion . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Registration . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Registered URI schemes . . . . . . . . . . . . . . . . . . 4
3.1.2 Unregistered URI Schemes . . . . . . . . . . . . . . . . . 4
3.1.2.1 Public Unregistered Schemes . . . . . . . . . . . . . . . 4
3.1.2.2 Private Schemes . . . . . . . . . . . . . . . . . . . . . 5
3.1.3 Registration of URI Schemes . . . . . . . . . . . . . . . 5
3.1.3.1 IETF Tree . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3.2 Other Trees . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 URN Namespaces . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Registered URN NIDs . . . . . . . . . . . . . . . . . . . 5
3.2.2 Pending URN NIDs . . . . . . . . . . . . . . . . . . . . . 6
3.2.3 Unregistered NIDs . . . . . . . . . . . . . . . . . . . . 7
3.2.4 Registration Procedures for URN NIDs . . . . . . . . . . . 7
4. Additional URI Issues . . . . . . . . . . . . . . . . . . 7
5. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . 11In October, 2000 the W3C formed a planning group whose mission was to evaluate the opportunities for W3C work in the area of Uniform Resource Identifiers (URIs) and to develop a proposal for continued work in this area. The Interest Group was composed of W3C members and invited experts from the IETF to participate as well. This document is a set of recommendations from this group, to the W3C and the IETF for work that can and should continue in this area.
2000年10月、 W3C は統一資源識別子 (URI) の領域での W3C の作業の機会を評価し、この領域での継続作業の提案を作成することを目指した計画部会を組織しました。 この関係部会は W3C 会員と、同様に関係する IETF からの招聘専門家で構成されていました。この文書はこの部会からの、 この領域で継続でき、継続するべきである作業についての W3C と IETF への勧告の集合です。
There is some confusion in the web community over the partitioning of URI space, specifically, the relationship among the concepts of URL, URN, and URI. The confusion owes to the incompatibility between two different views of URI partitioning, which we call the "classical" and "contemporary" views.
URI 空間の区画化について、特に URL, URN, URI の概念の間の関係についてはウェブ社会において混乱が見られます。 この混乱は、 URI の区画化についての、我々の呼ぶところの「古典的」 な見方と「現代的」な見方の二つの異なる見方の非互換性によるところのものです。
During the early years of discussion of web identifiers (early to mid 90s), people assumed that an identifier type would be cast into one of two (or possibly more) classes. An identifier might specify the location of a resource (a URL) or its name (a URN), independent of location. Thus a URI was either a URL or a URN. There was discussion about generalizing this by the addition of a discrete number of additional classes; for example, a URI might point to metadata rather than the resource itself, in which case the URI would be a URC (citation). URI space was thus viewed as partitioned into subspaces: URL, URN, and additional subspaces to be defined. The only such additional space ever proposed was Uniform Resource Characteristics (URC) and there never was any buy-in; so without loss of generality, it's reasonable to say that URI space was thought to be partitioned into two classes: URL and URN. Thus, for example, "http:" was a URL scheme, and "isbn:" would (someday) be a URN scheme. Any new scheme would be cast into one of these two classes.
ウェブ識別子の議論の初期の頃 (1990年代の最初から中頃) の間には、 人々は識別し型を二つ (もしかしたらそれ以上) の種別の一つに入れることができると考えていました。識別子は資源の位置を指定する (URL) か、位置とは独立にその名前を指定します (URN)。離散的な数の追加の種別によってこれを一般化することの議論もありました。たとえば、 URI は資源自体ではなくメタデータを指示するかもしれず、この場合には URI は URC (引用) となります。 URI 空間は従って URL や URN や定義されよう追加の部分空間に区画化されてとらえられていました。追加の空間として提案されたのは統一資源性質 (URC) だけで、買い戻された物はありませんでした。ですから一般性を失うことなく、合理的に URI 空間は二つの種別 — URL と URN に区画化されると思われていたと言うことができます。 従って、例えば http: は URL 方式であり、 isbn: は (いつの日か) URN 方式となるはずでした。 任意の新しい方式はこの2つの種別の一つに入れることができるはずです。
Over time, the importance of this additional level of hierarchy
seemed to lessen; the view became that an individual scheme did not
need to be cast into one of a discrete set of URI types, such as
"URL", "URN", "URC", etc. Web-identifier schemes are, in general,
URI schemes, as a given URI scheme may define subspaces. Thus
"http:" is a URI scheme. "urn:" is also a URI scheme; it defines
subspaces, called "namespaces". For example, the set of URNs, of the
form "urn:isbn:n-nn-nnnnnn-n", is a URN namespace. ("isbn" is an URN
namespace identifier. It is not a "URN scheme", nor is it a "URI
scheme.")時が過ぎ、この追加の階層の水準の重要性が分かってきました。 見方は個々の方式は URI の型の離散的集合、「URL」, 「URN」, 「URC」, その他のいずれかに入れる必要はないということになりました。 ウェブ識別子方式は、一般に、 URI 方式であり、 ある URI 方式は部分空間を定義するかもしれません。 従って、 http: は URI 方式であり、 urn: もまた URI 方式です。 こちらは「名前空間」と呼ぶ部分空間を定義しています。 例えば、 urn:isbn:n-nn-nnnnnn-n の形式の URN の集合は URN 名前空間です。 (isbn は URN 名前空間識別子です。これは「URN 方式」でも 「URI 方式」でもありません。)
Further, according to the contemporary view, the term "URL" does not refer to a formal partition of URI space; rather, URL is a useful but informal concept. A URL is a type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network "location"), rather than by some other attributes it may have. Thus, as we noted, "http:" is a URI scheme. An http URI is a URL. The phrase "URL scheme" is now used infrequently, usually to refer to some subclass of URI schemes which exclude URNs.
更に、現代的見方に従うと、用語「URL」は URI 空間の正式な区画を指しません。むしろ、 URL は有用ではあるものの非公式な概念です。 URL は、資源を (他に持ち得る属性ではなく) その主要な接続方式 (例えばそのネットワークの「位置」) の表現によって識別する URI の種類です。 従って、今述べたように http: は URI 方式です。 http URI は URL です。 語句「URL 方式」は今は余り使われず、通常 URN を除外した URI 方式の部分種別を指します。
The body of documents (RFCs, etc) covering URI architecture, syntax,
registration, etc., spans both the classical and contemporary
periods. People who are well-versed in URI matters tend to use "URL"
and "URI" in ways that seem to be interchangeable. Among these
experts, this isn't a problem, but among the Internet community at
large, it is a problem. People are not convinced that URI and URL
mean the same thing, in documents where they (apparently) do. When
one RFC talks about URI schemes (e.g. "URI Syntax" (RFC 2396) [12]),
another talks about URL schemes (e.g. "Registration Procedures for
URL Schemes" (RFC 2717) [1]), and yet another talks of URN schemes
("Architectural Principles of URN Resolution" (RFC 2276) [13]), it is
natural to wonder how they difference, and how they relate to one
another. While RFC 2396, section 1.2, attempts to address the
distinction between URIs, URLs and URNs, it has not been successful
in clearing up the confusion.URI 体系、構文、登録、その他についての文書 (RFC、その他) は古典的期間と現代的機関の両方に渡っています。 URI 関係に詳しい人は「URL」と「URI」を交換可能に見える形で使う傾向にあります。そうした専門家の間で、これは問題ではありませんが、広くインターネット社会においては、これは問題であります。 人々は URI と URL が同じ事を意味すると、 (明らかに) そうである文書で確信しません。ある RFC が URI 方式について話している (例えば「URI 構文」 (RFC 2396)) 時に、別のは URL 方式について話している (例えば「URL 方式の登録手続き」 (RFC 2717)) し、また別のは URN 方式について話していて (「URN 解決の体系的基本方針」 (RFC 2276))、 これらがどう異なり、互いにどう関係しているのかと擬音に思うのが普通です。 RFC 2396 は 1.2 節で URI, URL, URN の違いに言及しようとしていますが、 混乱を解消することに成功してはいません。
This section examines the state of registration of URI schemes and URN namespaces and the mechanisms by which registration currently occurs.
この章では、 URI 方式と URN 名前空間の登録の状態と、 登録が現在行われている方式を検査します。
The official register of URI scheme names is maintained by IANA, at http://www.iana.org/assignments/uri-schemes. For each scheme, the RFC that defines the scheme is listed; for example "http:" is defined by RFC2616 [14]. The table lists 34 schemes (at time of publication of this RFC). In addition, there are a few "reserved" scheme names; at one point in time, these were intended to become registered schemes but have since been dropped.
URI 方式名の公式登録簿は IANA が http://www.iana.org/assignments/uri-schemes で維持しています。 各方式について、その方式を定義する RFC が列挙されています。 例えば、 http: は RFC 2616 で定義されています。この表は (この RFC の出版の時点で) 34 の方式を列挙しています。加えて、少数の「予約」 方式名があります。それらはある時点において登録方式となる予定でしたが、 その後に落とされた物です。
We distinguish between public (unregistered) and private schemes. A public scheme (registered or not) is one for which there is some public document describing it.
公開 (未登録) 方式と私用方式を区別します。 公開方式 (登録済みであれなかれ。) とは、 それを説明する何らかの公開文書があるものです。
Dan Conolly's paper, at http://www.w3.org/Addressing/schemes, provides a list of known public URI schemes, both registered and un-registered, a total of 85 schemes at time of publication of this RFC. 50 or so of these are unregistered (not listed in the IANA register). Some of these URI schemes are obsolete (for example, "phone" is obsolete, superceded by "tel"), while some have an RFC, but are not included in the IANA list.
Dan Connolly の論文 http://www.w3.org/Addressing/schemes は登録済みまたは未登録の既知の公開 URI 方式の一覧を提供していて、この RFC の出版の時点で合計 85 方式あります。 そのうちの50程度が未登録です (IANA 登録簿に列挙されていません)。 未登録 URI 方式のうちのいくつかは時代遅れです (例えば phone は時代遅れで、 tel となりました) が、いくつかは RFC があるのに IANA の一覧に含められていません。
It is probably impossible to determine all of these, and it's not clear that it's worthwhile to try, except perhaps to get some idea of their number. In the minutes of the August 1997 IETF meeting is the observation that there may be 20-40 in use at Microsoft, with 2-3 being added a day, and that WebTV has 24, with 6 added per year.
おそらくそのすべてを決定するのは不可能で、 たぶんその数がおおよそつかむことを除いては試してみる価値があるかも不明です。 1997年8月の IETF 会合の議事録にある観察によれば、20〜40 個が Microsoft により使われている模様で、一日に 2〜3 個追加されており、 WebTV が 24 個持っていて一年に 6 個追加されているようです。
"Registration Procedures for URL Scheme Names" (RFC 2717) [1] specifies procedures for registering scheme names and points to "Guidelines for new URL Schemes" (RFC 2718) [2], which supplies guidelines. RFC 2717 describes an organization of schemes into "trees". It is important to note that these two documents use the historical term 'URL' when in fact, they refer to URIs in general. In fact, one of the recommended tasks in Section 5 is for these documents to be updated to use the term 'URI' instead of 'URL'.
『URL 方式名の登録手続き』 (RFC 2717) は方式名を登録する手続きを規定すると共に 『新しい URL 方式の指針』 (RFC 2718) を指しており、こちらは手引きを供給しています。 RFC 2717 は方式を「木」に組織化することを説明しています。 この2つの文書が、実際には一般に URI を指すために歴史的用語「URL」 を使っていることに注意するのは重要です。実際、 5章の勧告作業の一つはこれらの文書を用語「URL」の代わりに「URI」 を使うように更新することです。
The IETF tree is intended for schemes of general interest to the Internet community, and for those which require a substantive review and approval process. Registration in the IETF tree requires publication of the scheme syntax and semantics in an RFC.
IETF 木はインターネット社会に一般的に関係し、独立の評価・承認手続きが必要な方式に使うことを意図しています。 IETF 木への登録は RFC で方式の構文と意味を出版することが必要です。
Although RFC 2717 describes "alternative trees", no alternative trees
have been registered to date, although a vendor-supplied tree ("vnd")
is pending. URI schemes in alternative trees will be distinguished
because they will have a "." in the scheme name.RFC 2717 は「代替木」に記述していますが、現在まで代替木は登録されていません。
但し販売者供給木 (vnd) が準備中です。
代替木の URI 方式は方式名に .
が入ることになるので区別することができます。
A URN namespace is identified by a "Namespace ID" (NID), which is registered with IANA (see Section 3.2.4).
URN 名前空間は「名前区間 ID」 (NID) で識別され、これは IANA に登録します。
There are two categories of registered URN NIDs:
登録 URN NID には二つの分類があります。
o Informal: These are of the form, "urn-<number>", where <number> is
assigned by IANA. There are four registered (at time of
publication of this RFC) in this category (urn-1, urn-2, urn-3,
and urn-4).非公式: urn-<number> の形式で、
<number> は IANA が割り当てます。
この分類には (この RFC の出版の時点で) 4つの登録
(urn-1, urn-2, urn-3,
urn-4) があります。
o Formal: The official list of registered NIDs is kept by IANA at
http://www.iana.org/assignments/urn-namespaces. At the time of
publication of this RFC it lists ten registered NIDs:公式: 登録 NID の公式な一覧は IANA が http://www.iana.org/assignments/urn-namespaces で保持しています。この RFC の出版の時点で、 十個の登録 NID を列挙しています。
* 'ietf', defined by "URN Namespace for IETF Documents" (RFC
2648) [3] * 'pin', defined by "The Network Solutions Personal Internet Name
(PIN): A URN Namespace for People and Organizations" (RFC 3043)
[4] * 'issn' defined by "Using The ISSN as URN within an ISSN-URN
Namespace" (RFC 3043) [4] * 'oid' defined by "A URN Namespace of Object Identifiers" (RFC
3061) [6] * 'newsml' defined by "URN Namespace for NewsML Resources" (RFC
3085) [7]* 'oasis' defined by "A URN Namespace for OASIS" (RFC 3121) [8]
* 'xmlorg' defined by "A URN Namespace for XML.org" (RFC 3120)
[9] * 'publicid' defined by "A URN Namespace for Public Identifiers"
(RFC 3151) [10] * 'isbn' defined by "Using International Standard Book Numbers as
Uniform Resource Names" (RFC 3187) [15] * 'nbn' defined by "Using National Bibliography Numbers as
Uniform Resource Names" (RFC 3188) [16]ietfpinissnoidnewsmloasisxmlorgpublicidisbnnbnThere are a number of pending URN NID registration requests, but there is no reliable way to discover them, or their status. It would be helpful if there were some formal means to track the status of NID requests such as 'isbn'.
数々の未決の URN NID 登録要求がありますが、 これやその状態を見つける確実な方法はありません。 isbn のような NID 要求の状態を追跡する公式な手段があれば便利でしょう。
In the "unregistered" category (besides the experimental case, not described in this paper), there are entities that maintain namespaces that, while completely appropriate as URNs, just haven't bothered to explore the process of NID registration. The most prominent that comes to mind is 'hdl'. In the case of 'hdl', it has been speculated that this scheme has not been registered because it is not clear to the owners whether it should be registered as a URI scheme or as a URN namespace.
「未登録」の分類には、 (この論文で記述していない実験的な場合は別に、)
完全に URN として適切ではあるものの、単に NSS 登録の手続きを踏んでいない名前空間を維持している団体があります。
名前の挙がるもっとも顕著な物は hdl です。
hdl の場合、所有者がこれを URI 方式として登録するべきか
URN 名前空間として登録するべきか不明であることからこの方式を登録していないものと思われます。
"URN Namespace Definition Mechanisms" (RFC 2611) [11] describes the mechanism to obtain an NID for a URN namespace, which is registered with IANA.
『URN 名前空間定義機構』 (RFC 2611) は URN 名前空間用の NID を得、これを IANA に登録する仕組みを説明しています。
A request for an NID should describe features including: structural characteristic of identifiers (for example, features relevant to caching/shortcuts approaches); specific character encoding rules (e.g., which character should be used for single-quotes); RFCs, standards, etc, that explain the namespace structure; identifier uniqueness considerations; delegation of assignment authority, including how to become an assigner of identifiers; identifier persistence considerations; quality of service considerations; process for identifier resolution; rules for lexical equivalence; any special considerations required for conforming with the URN syntax (particularly applicable in the case of legacy naming systems); validation mechanisms (determining whether a given string is currently a validly-assigned URN); and scope (for example,"United States social security numbers").
NID の要求は、次に挙げる物を含めたその機能を記述するべきです: 識別子の構造的性質 (例えば、キャッシュ付け・近道的手法に関連する機能)。 特定文字符号化規則 (例えば、単一引用符に使用するべき文字)。 名前空間構造を説明する RFC、規格、その他。 割当て権の委譲 (どうやって識別子の割り当て者になるかを含む)。 識別子持続性の考察。サービスの品質の考察。 識別子解決手続き。字句同等性規則。 URN 構造に適合するために必要な特別な考慮点 (遺産命名システムの場合に特に適切)。 妥当性検証機構 (与えられた文字が現在妥当に割り当てられた URN かを決定)。適用範囲 (例えば、「合衆国社会保障番号」)。
There are additional unresolved URI issues not considered by this paper, which we hope will be addressed by a follow-on effort. We have not attempted to completely enumerate these issues, however, they include (but are not limited to) the following:
この論文では考察しておらず、今後の成果物で言及されることを願う未解決の URI の問題が幾つかあります。そうした問題を完全に列挙しようとはしませんが、次のような問題を含みます (がそれに限りません)。
o The use of URIs as identifiers that don't actually identify
network resources (for example, they identify an abstract object,
such as an XML namespace, or a physical object such as a book or
even a person). o IRIs (International Resource Identifiers): the extension of URI
syntax to non-ASCII.We recommend the following:
我々は次を勧告します。
1. The W3C and IETF should jointly develop and endorse a model for
URIs, URLs, and URNs consistent with the "Contemporary View"
described in section 1, and which considers the additional URI
issues listed or alluded to in section 3. 2. RFCs such as 2717 ("Registration Procedures for URL Scheme Names")
and 2718 ("Guidelines for new URL Schemes") should both be
generalized to refer to "URI schemes", rather than "URL schemes"
and, after refinement, moved forward as Best Current Practices in
the IETF. 3. The registration procedures for alternative trees should be
clarified in RFC 2717. 4. Public, but unregistered schemes, should become registered, where
possible. Obsolete schemes should be purged or clearly marked as
obsolete.5. IANA registration information should be updated:
* Add 'urn' to the list of registered URI schemes with a pointer
to the URN namespace registry. * Maintain status information about pending registrations (URI
schemes and URN NID requests ). * Insure that it is clear that the page is the official registry,
e.g., by adding a heading to the effect "This is the Official
IANA Registry of URI Schemes".urn を
URN 名前空間登録簿への参照と共に加える。This memo does not raise any known security threats.
このメモは既知の安全上の脅威を引き起こしません。
The participants in the URI Planning Interest Group are:
URI 計画関係部会の関係者は:
o Tony Coates
o Dan Connolly
o Diana Dack
o Leslie Daigle
o Ray Denenberg
o Martin Duerst
o Paul Grosso
o Sandro Hawke
o Renato Iannella
o Graham Klyne
o Larry Masinter
o Michael Mealling
o Mark Needleman
o Norman Walsh
[1] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999. [2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999. [3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. [4] Mealling, M., "The Network Solutions Personal Internet Name
(PIN): A URN Namespace for People and Organizations", RFC 3043,
January 2001. [5] Rozenfeld, S., "Using The ISSN (International Serial Standard
Number) as URN (Uniform Resource Names) within an ISSN-URN
Namespace", RFC 3044, January 2001. [6] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061,
February 2001. [7] Coates, A., Allen, D. and D. Rivers-Moore, "URN Namespace for
NewsML Resources", RFC 3085, March 2001. [8] Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121,
June 2001. [9] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120,
June 2001. [10] Walsh, N., Cowan, J. and P. Grosso, "A URN Namespace for Public
Identifiers", RFC 3151, August 2001. [11] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN
Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999. [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [13] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998. [14] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. [15] Hakala, J. and H. Walravens, "Using International Standard Book
Numbers as Uniform Resource Names", RFC 3187, October 2001. [16] Hakala, J., "Using National Bibliography Numbers as Uniform
Resource Names", RFC 3188, October 2001.Michael Mealling VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 US
EMail: michael@verisignlabs.com
Ray Denenberg Library of Congress Washington, DC 20540 US
EMail: rden@loc.gov
Copyright (C) The Internet Society (2002). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.