RFC 3305

RFC 3305

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): 明確化と勧告

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   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 名前空間識別子を登録するかを説明し、 この問題についての継続作業の勧告を述べます。

Table of Contents

   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 . . . . . . . . . . . . . . . . . 11

1. The W3C URI Interest Group

   In 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 への勧告の集合です。

2. URI Partitioning

   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 の区画化についての、我々の呼ぶところの「古典的」 な見方と「現代的」な見方の二つの異なる見方の非互換性によるところのものです。

2.1 Classical View

   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つの種別の一つに入れることができるはずです。

2.2 Contemporary View

   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 方式の部分種別を指します。

2.3 Confusion

   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 の違いに言及しようとしていますが、 混乱を解消することに成功してはいません。

3. Registration

   This section examines the state of registration of URI schemes and
   URN namespaces and the mechanisms by which registration currently
   occurs.

この章では、 URI 方式と URN 名前空間の登録の状態と、 登録が現在行われている方式を検査します。

3.1 URI Schemes

3.1.1 Registered URI schemes

   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 の方式を列挙しています。加えて、少数の「予約」 方式名があります。それらはある時点において登録方式となる予定でしたが、 その後に落とされた物です。

3.1.2 Unregistered URI Schemes

   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.

公開 (未登録) 方式と私用方式を区別します。 公開方式 (登録済みであれなかれ。) とは、 それを説明する何らかの公開文書があるものです。

3.1.2.1 Public Unregistered Schemes

   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 の一覧に含められていません。

3.1.2.2 Private Schemes

   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 個追加されているようです。

3.1.3 Registration of URI Schemes

   "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」 を使うように更新することです。

3.1.3.1 IETF Tree

   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 で方式の構文と意味を出版することが必要です。

3.1.3.2 Other Trees

   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 方式は方式名に . が入ることになるので区別することができます。

3.2 URN Namespaces

   A URN namespace is identified by a "Namespace ID" (NID), which is
   registered with IANA (see Section 3.2.4).

URN 名前空間は「名前区間 ID」 (NID) で識別され、これは IANA に登録します。

3.2.1 Registered URN NIDs

   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]
ietf
『IETF 文書用 URN 名前空間』 (RFC 2648) で定義
pin
『ネットワーク解決個人インターネット名 (PIN): 人および組織の URN 名前空間』 (RFC 3043) で定義
issn
『ISSN URN 名前空間中で URN として ISSN を使う』 (RFC 3043) で定義
oid
『物体識別子の URN 名前空間』 (RFC 3061) で定義
newsml
『NewsML 資源用 URN 名前空間』で定義 (RFC 3085)
oasis
『OASIS 用 URN 名前空間』 (RFC 3121) で定義
xmlorg
『XML.org 用 URN 名前空間』 (RFC 3120) で定義
publicid
『公開識別子用 URN 名前空間』 (RFC 3151) で定義
isbn
『国際標準書籍番号を統一資源名として使用』 (RFC 3187) で定義
nbn
『全国書誌番号を統一資源名として使用』 (RFC 3188) で定義

3.2.2 Pending URN NIDs

   There 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 要求の状態を追跡する公式な手段があれば便利でしょう。

3.2.3 Unregistered NIDs

   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 名前空間として登録するべきか不明であることからこの方式を登録していないものと思われます。

3.2.4 Registration Procedures for URN NIDs

   "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 かを決定)。適用範囲 (例えば、「合衆国社会保障番号」)。

4. Additional URI Issues

   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.

5. Recommendations

   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".

6. Security Considerations

   This memo does not raise any known security threats.

このメモは既知の安全上の脅威を引き起こしません。

7. Acknowledgements

   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

References

   [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.

Authors' Addresses

   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

Acknowledgement

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

memo