RFC2169 日本語訳

Network Working Group                                       R. Daniel
Request for Comments: 2169             Los Alamos National Laboratory
Category: Experimental                                      June 1997

コメントを求めるワーキンググループR.ダニエル要求をネットワークでつないでください: 2169年のロスアラモス国立研究所カテゴリ: 実験的な1997年6月

         A Trivial Convention for using HTTP in URN Resolution

つぼの解決にHTTPを使用するための些細なコンベンション

Status of this Memo
===================

このMemoの状態===================

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract:
=========

要約: =========

   The Uniform Resource Names Working Group (URN-WG) was formed to
   specify persistent, location-independent names for network accessible
   resources, as well as resolution mechanisms to retrieve the resources
   given such a name. At this time the URN-WG is considering one
   particular resolution mechanism, the NAPTR proposal [1]. That
   proposal specifies how a client may find a "resolver" for a URN. A
   resolver is a database that can provide information about the
   resource identified by a URN, such as the resource's location, a
   bibliographic description, or even the resource itself. The protocol
   used for the client to communicate with the resolver is not specified
   in the NAPTR proposal.  Instead, the NAPTR resource record provides a
   field that indicates the "resolution protocol" and "resolution
   service requests" offered by the resolver.

Uniform Resource Names作業部会(URN-WG)はしつこい状態で指定するために形成されて、位置独立者はアクセス可能なリソース(与えられたリソースを検索する解決メカニズムと同じくらい良い名前)をネットワークにちなんで命名します。 このとき、URN-WGは1つの特定の解決メカニズム、NAPTR提案[1]を検討しています。 その提案は、クライアントがURNに関してどのように「レゾルバ」を見つけるかもしれないかを指定します。 レゾルバはURNによって特定されたリソースの情報を提供できるデータベースです、リソースの位置、図書目録の記述、またはリソース自体などのようにさえ。 クライアントがレゾルバとコミュニケートするのに使用されるプロトコルはNAPTR提案で指定されません。 代わりに、NAPTRリソース記録は「解決プロトコル」とレゾルバによって提供された「解決サービス要求」を示す野原を供給します。

   This document specifies the "THTTP" resolution protocol - a trivial
   convention for encoding resolution service requests and responses as
   HTTP 1.0 or 1.1 requests and responses.  The primary goal of THTTP is
   to be simple to implement so that existing HTTP servers may easily
   add support for URN resolution. We expect that the databases used by
   early resolvers will be useful when more sophisticated resolution
   protocols are developed later.

このドキュメントは"THTTP"解決プロトコルを指定します--1.1のHTTP1.0か要求と応答として解決サービスのリクエストと応答をコード化するための些細なコンベンション。 THTTPの第一の目標は既存のHTTPサーバが容易にURN解決のサポートを加えることができるくらい実行するのが簡単であることです。 私たちは、より精巧な解決プロトコルが後で開発されるとき、早いレゾルバによって使用されたデータベースが役に立つと予想します。

1.0  Introduction:
==================

1.0序論: ==================

   The NAPTR specification[1] defined a new DNS resource record which
   may be used to discover resolvers for Uniform Resource Identifiers.
   That resource record provides the "services" field to specify the
   "resolution protocol" spoken by the resolver, as well as the
   "resolution services" it offers. Resolution protocols mentioned in

NAPTR仕様[1]はUniform Resource Identifierに関してレゾルバを発見するのに使用されるかもしれない新しいDNSリソース記録を定義しました。 そのリソース記録はレゾルバによって話された「解決プロトコル」を指定するために「サービス」野原を供給します、それが提供する「解決サービス」と同様に。 中に言及された解決プロトコル

Daniel                        Experimental                      [Page 1]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[1ページ]RFC2169HTTP

   that specification are Z3950, THTTP, RCDS, HDL, and RWHOIS. (That
   list is expected to grow over time). The NAPTR specification also
   lists a variety of resolution services, such as N2L (given a URN,
   return a URL); N2R (Given a URN, return the named resource), etc.

その仕様は、Z3950と、THTTPと、RCDSと、HDLと、RWHOISです。 (そのリストが時間がたつにつれて成長すると予想されます。) また、NAPTR仕様はN2Lなどのさまざまな解決サービスを記載します(URNを考えて、URLを返してください)。 N2R(命名されたリソースをURN、リターンに与える)など

   This document specifies the "THTTP" (Trivial HTTP) resolution
   protocol.  THTTP is a simple convention for encoding resolution
   service requests and responses as HTTP 1.0 or 1.1 requests and
   responses. The primary goal of THTTP is to have a URN resolution
   protocol that can easily be added to existing HTTP daemons. Other
   resolution protocols are expected to arise over time, so this
   document serves a secondary purpose of illustrating the information
   that needs to be specified for a URN resolution protocol. One of the
   resolution protocols we expect to be developed is an extension of
   HTTP with new methods for the resolution services. Therefore, we use
   "THTTP" as the identifier for this protocol to leave "HTTP" for later
   developments.

このドキュメントは"THTTP"(些細なHTTP)解決プロトコルを指定します。 THTTPは、1.1のHTTP1.0か要求と応答として解決サービスのリクエストと応答をコード化するための簡単なコンベンションです。 THTTPの第一の目標は容易に既存のHTTPデーモンに加えることができるURN解決プロトコルを持つことです。 他の解決プロトコルが時間がたつにつれて起こると予想されて、このドキュメントはURN解決プロトコルに指定される必要がある情報を例証する副次目的に役立ちます。 私たちが開発されると予想する解決プロトコルの1つは解決サービスのための新しい方法があるHTTPの拡大です。 したがって、このプロトコルが「HTTP」を後の開発に残すのに私たちは識別子として"THTTP"を使用します。

   The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1
   [3] specifications. Implementors of this specification should be
   familiar with CGI scripts, or server-specific interfaces, for
   database lookups.

読者がHTTP/1.0[2]と1.1[3]仕様によく知られさせると思われます。 データベースルックアップに、この仕様の作成者はCGIスクリプト、またはサーバ特有のインタフェースに詳しいはずです。

2.0 General Approach:
=====================

2.0 一般的方法: =====================

   The general approach used to encode resolution service requests in
   THTTP is quite simple:

THTTPの解決サービスのリクエストをコード化するのに使用される一般的方法はかなり簡単です:

       GET /uri-res/<service>?<uri>  HTTP/1.0

<uri>HTTP/1.0に/uri-res/<サービス>?手に入れてください。

   For example, if we have the URN "urn:foo:12345-54321" and want a URL,
   we would send the request:

例えば、URN「つぼ:foo:12345-54321」を持って、URLが欲しいと思うなら、私たちは要求を送るでしょう:

       GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.0

HTTP/1.0に/uri-res/N2Lつぼ:foo:12345-54321?手に入れてください。

   The request could also be encoded as an HTTP 1.1 request. This would
   look like:

また、HTTP1.1が要求するように要求をコード化できました。 これに似ているでしょう:

       GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.1
       Host: <whatever host we are sending the request to>

/uri-res/N2L?つぼ:foo:12345-54321HTTP/1.1ホストを手に入れてください: <は私たちが>への要求を送るホストです何でも。

   Responses from the HTTP server follow standard HTTP practice. Status
   codes, such as 200 (OK) or 404 (Not Found) shall be returned.  The
   normal rules for determining cachability, negotiating formats, etc.
   apply.

HTTPサーバからの応答は一般的なHTTP習慣に続きます。 200などのステータスコード(OK)か404(Foundでない)を返すものとします。 cachability、形式を交渉するのなどを決定するための正常な規則は適用されます。

Daniel                        Experimental                      [Page 2]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[2ページ]RFC2169HTTP

   Handling these requests on the server side is easy to implement using
   CGI or other, server-specific, extension mechanisms.  CGI scripts
   will see the incoming URI in the QUERY_STRING environment variable.
   Any %encoded characters in the URN will remain in their %encoded
   state in that string. The script can take the URN, look it up in a
   database, and return the requested information.

サーバ側でこれらの要求を扱うのは何らかのCGIを使用するのにおいて実行しやすいです、サーバ特有です、拡大メカニズム。CGIスクリプトはQUERY_STRING環境変数の入って来るURIを見るでしょう。 URNのコード化されたキャラクタが彼らの%に残っているどんな%もそのストリングで状態をコード化しました。 スクリプトは、URNを取って、データベースでそれを調べて、求められた情報を返すことができます。

   One caveat should be kept in mind. The URN syntax document [4]
   discusses the notion of lexical equivalance and requires that
   resolvers return identical results for URNs that are lexically
   equivalent. Implementors of this specification must be careful to
   obey that rule. For example, the two requests below MUST return
   identical results, since the URNs are lexically equivalent.
       GET /uri-res/N2L?urn:cid:foo@huh.com HTTP/1.0
       GET /uri-res/N2L?URN:CID:foo@huh.com HTTP/1.0

1つの警告が覚えておかれるべきです。 URN構文ドキュメント[4]は、語彙equivalanceの概念について議論して、レゾルバが辞書的に同等なURNsのために同じ結果を返すのを必要とします。 この仕様の作成者はその規則に従うのに慎重であるに違いありません。 例えば、URNsが辞書的に同等であるので、以下での2つの要求が同じ結果を返さなければなりません。 /uri-res/N2L--HTTP/1.0が/uri-res/N2Lを手に入れるつぼ:Cid: foo@huh.com --つぼ:Cid: foo@huh.com HTTP/1.0を得てください。

3.0 Service-specific details:
=============================

3.0 サービス特有の詳細: =============================

   This section goes through the various resolution services established
   in the URN services document [5] and states how to encode each of
   them, how the results should be returned, and any special status
   codes that are likely to arise.

このセクションは、URNサービスドキュメント[5]に確立された様々な解決サービスを使い果たして、それぞれのそれら、結果がどう返されるべきであるか、そして、およびどんな起こりそうな特別なステータスコードもコード化する方法を述べます。

   Unless stated otherwise, the THTTP requests are formed according to
   the simple convention above, either for HTTP/1.0 or HTTP/1.1. The
   response is assumed to be an entity with normal headers and body
   unless stated otherwise. (N2L is the only request that need not
   return a body).

別の方法で述べられない場合、HTTP/1.0かHTTP/1.1における、上の簡単なコンベンションによると、THTTP要求は形成されます。 別の方法で述べられない場合、応答は普通のヘッダーとボディーがある実体であると思われます。 (N2Lはボディーを返す必要はない唯一の要求です。)

3.1  N2L (URN to URL):
----------------------

3.1N2L(URLへのつぼ): ----------------------

   The request is encoded as above. The URL MUST be returned in a
   Location:  header for the convienience of the user in the most common
   case of wanting the resource. If the lookup is successful, a 30X
   status line SHOULD be returned. HTTP/1.1 clients should be sent the
   303 status code. HTTP/1.0 clients should be sent the 302 (Moved
   temporarily) status code unless the resolver has particular reasons
   for using 301 (moved permanently) or 304 (not modified) codes.

要求は同じくらい上でコード化されます。 LocationでURLを返さなければなりません: リソースが欲しいことの最も一般的な場合におけるユーザのconvienienceのためのヘッダー。 ルックアップがうまくいっているa30X状況表示行のSHOULDであるなら、返してください。 HTTP/1.1人のクライアントに303ステータスコードを送るべきです。 レゾルバに301(永久に、動かされる)を使用する特定の理由か304(変更されない)のコードがない場合、302(一時動かされる)ステータスコードをHTTP/1.0人のクライアントに送るべきです。

   Note that access controls may be applied to this, or any other,
   resolution service request. Therefore the 401 (unauthorized) and 403
   (forbidden) status codes are legal responses. The server may wish to
   provide a body in the response to explain the reason for refusing
   access, and/or to provide alternate information about the resource,
   such as the price it will cost to obtain the resource's URL.

アクセス管理がこれ、またはいかなる他のも適用されるかもしれなくて、解決がサービスのリクエストであることに注意してください。 したがって、401(権限のない)と403(禁じられる)のステータスコードが法的な応答です。 サーバはアクセスを拒否する理由について説明して、リソースの交互の情報を提供するためにボディーを応答に提供したがっているかもしれません、それがリソースのURLを得るのにかかる価格などのように。

Daniel                        Experimental                      [Page 3]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[3ページ]RFC2169HTTP

3.2  N2Ls (URN to URLs):
------------------------

3.2N2Ls(URLへのつぼ): ------------------------

   The request is encoded as above. The result is a list of 0 or more
   URLs. The Internet Media Type (aka ContentType) of the result may be
   negotiated using standard HTTP mechanisms if desired. At a minimum
   the resolver should support the text/uri-list media type.  (See
   Appendix A for the definition of this media type). That media type is
   suitable for machine-processing of the list of URLs. Resolvers may
   also return the results as text/html, text/plain, or any other media
   type they deem suitable.

要求は同じくらい上でコード化されます。 結果は0つ以上のURLのリストです。 結果のインターネットメディアType(通称ContentType)は、望まれているなら標準のHTTPメカニズムを使用することで交渉されるかもしれません。 レゾルバが支持するはずである最小限では、uriテキスト/リストメディアはタイプされます。 (このメディアタイプの定義に関してAppendix Aを見ます。) そのメディアタイプはURLのリストのマシン処理に適しています。 また、レゾルバはテキスト/html、テキスト/平野、または彼らが適当であると考えるいかなる他のメディアタイプとしても結果を返すかもしれません。

   No matter what the particular media type, the result MUST be a list
   of the URLs which may be used to obtain an instance of the resource
   identified by the URN. All URIs shall be encoded according to the URI
   specification [6].

特定のメディアタイプが者であっても、結果はURNによって特定されたリソースの例を得るのに使用されるかもしれないURLのリストであるに違いありません。 すべてのURIがURI仕様[6]通りにコード化されるものとします。

   If the client has requested the result be returned as text/html or
   application/html, the result should be a valid HTML docment
   containing the fragment:
   <UL>
   <LI><A HREF="...url 1...">...url 1...</A>
   <LI><A HREF="...url 2...">...url 2...</A>
    etc.
   </UL>
   where the strings ...url n... are replaced by the n'th URL in the
   list.

クライアントが結果を要求したなら、テキスト/htmlかアプリケーション/html、結果が断片を含む有効なHTML docmentであるべきであるので、返してください: 「<UL><李><A HREF=」…「url1」…>…url1…「</A><李><A HREF=」…「url2」…>…url2…</は>などです。 </UL>、どこ、ストリング…url n.リストのn'th URLに取り替えます。

3.3  N2R (URN to Resource):
---------------------------

3.3N2R(リソースへのつぼ): ---------------------------

   The request is encoded as above. The resource is returned using
   standard HTTP mechanisms. The request may be modified using the
   Accept: header as in normal HTTP to specify that the result be given
   in a preferred Internet Media Type.

要求は同じくらい上でコード化されます。 標準のHTTPメカニズムを使用することでリソースを返します。Acceptを使用することで要求を変更するかもしれません: 結果がaで与えられていると指定するコネ正常なHTTPとしてのヘッダーはインターネットメディアTypeを好みました。

3.4  N2Rs (URN to Resources):
-----------------------------

3.4N2Rs(リソースへのつぼ): -----------------------------

   This resolution service returns multiple instances of a resource, for
   example, GIF and JPEG versions of an image. The judgment about the
   resources being "the same" resides with the naming authority that
   issued the URN.

この解決サービスは、例えば、リソースの複数の例にGIFを返して、イメージのバージョンをJPEGに返します。 「同じ」リソースに関する判断はURNを発行した命名権威であります。

   The request is encoded as above. The result shall be a MIME
   multipart/alternative message with the alternative versions of the
   resource in seperate body parts. If there is only one version of the
   resource identified by the URN, it MAY be returned without the

要求は同じくらい上でコード化されます。 結果はseperate身体の部分のリソースの異本をもってMIMEの複合の、または、代替のメッセージになるでしょう。 URNによって特定されたリソースの1つのバージョンしかなければ、それなしで戻るかもしれません。

Daniel                        Experimental                      [Page 4]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[4ページ]RFC2169HTTP

   multipart/alternative wrapper. Resolver software SHOULD look at the
   Accept: header, if any, and only return versions of the resource that
   are acceptable according to that header.

複合の、または、代替の包装紙。 レゾルバソフトウェアSHOULDはAcceptを見ます: ヘッダーは単にリソースのそのヘッダーに従って許容できるバージョンを返してください。

3.5  N2C (URN to URC):
----------------------

3.5N2C(URCへのつぼ): ----------------------

   URCs (Uniform Resource Characteristics) are descriptions of other
   resources. This request allows us to obtain a description of the
   resource identified by a URN, as opposed to the resource itself.  The
   description might be a bibliographic citation, a digital signature, a
   revision history, etc. This document does not specify the content of
   any response to a URC request. That content is expected to vary from
   one resolver to another.

URCs(一定のResource Characteristics)は他のリソースの記述です。 私たちはこの要求でURNによって特定されたリソースの記述を得ることができます、リソース自体と対照的に。 記述は図書目録の引用、デジタル署名、改訂履歴であるかもしれませんなど。 このドキュメントはURC要求へのどんな応答の内容も指定しません。 その内容が1人のレゾルバから別のものに異なると予想されます。

   The format of any response to a N2C request MUST be communicated
   using the ContentType header, as is standard HTTP practice. The
   Accept: header SHOULD be honored.

ContentTypeヘッダーを使用して、N2C要求へのどんな応答の書式も伝えなければなりません、一般的なHTTP習慣のように。 受け入れます: ヘッダーSHOULD、光栄に思ってください。

3.6  N2Ns (URN to URNs):
------------------------

3.6N2Ns(つぼへのつぼ): ------------------------

   While URNs are supposed to identify one and only one resource, that
   does not mean that a resource may have one and only one URN. For
   example, consider a resource that has something like "current-
   weather-map" for one URN and "weather-map-for-datetime-x" for another
   URN. The N2Ns service request lets us obtain lists of URNs that are
   believed equivalent at the time of the request. As the weathermap
   example shows, some of the equivalances will be transitory, so the
   standard HTTP mechanisms for communicating cachability MUST be
   honored.

URNsが唯一無二の1つのリソースを特定するべきである間、それは、リソースには唯一無二の1URNがあるかもしれないことを意味しません。 例えば、別のURNのために何か1URNと「datetime-xのための気象地図」のための「現在の天気図」のようなものを持っているリソースを考えてください。 N2Nsサービスのリクエストで、私たちは要求時点で同等であると信じられているURNsのリストを得ることができます。 weathermapの例が示すようにいくらかのequivalancesが一時的になるので、cachabilityを伝えるための標準のHTTPメカニズムは光栄に思っているに違いありません。

   The request is encoded as above. The result is a list of all the
   URNs, known to the resolver, which identify the same resource as the
   input URN. The result shall be encoded as for the N2Ls request above
   (text/uri-list unless specified otherwise by an Accept: header).

要求は同じくらい上でコード化されます。 結果は同じリソースが入力URNであると認識するレゾルバにおいて知られているすべてのURNsのリストです。 結果はN2Ls要求のように(別の方法でAccept: ヘッダーによって指定されない場合/がuri記載するテキスト)を超えてコード化されるものとします。

3.7  L2Ns (URL to URNs):
----------------------

3.7L2Ns(つぼへのURL): ----------------------

   The request is encoded as above. The response is a list of any URNs
   known to be assigned to the resource at the given URL. The result
   shall be encoded as for the N2Ls and N2Ns requests.

要求は同じくらい上でコード化されます。 応答は与えられたURLのリソースに割り当てられるのが知られているどんなURNsのリストです。 結果はN2LsとN2Ns要求のようにコード化されるものとします。

Daniel                        Experimental                      [Page 5]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[5ページ]RFC2169HTTP

3.8  L2Ls (URL to URLs):
------------------------

3.8L2Ls(URLへのURL): ------------------------

   The request is encoded as described above. The result is a list of
   all the URLs that the resolver knows are associated with the resource
   located by the given URL. This is encoded as for the N2Ls, N2Ns, and
   L2Ns requests.

要求は上で説明されるようにコード化されます。 結果はレゾルバが与えられたURLによって見つけられているリソースに関連しているのを知っているすべてのURLのリストです。 これはN2Ls、N2Ns、およびL2Ns要求のようにコード化されます。

3.9  L2C (URL to URC):
----------------------

3.9L2C(URCへのURL): ----------------------

   The request is encoded as above, the response is the same as for the
   N2C request.

応答がN2C要求のように上で同じであるときに、要求はコード化されます。

Daniel                        Experimental                      [Page 6]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[6ページ]RFC2169HTTP

Appendix A: The text/uri-list Internet Media Type
=================================================
[This appendix will be augmented or replaced by the registration of the
text/uri-list IMT once that registration has been performed].

付録A: uriテキスト/リストインターネットメディアType================================================= [いったんその登録を実行すると、この付録をuriテキスト/リストIMTの登録に増大するか、または取り替えるでしょう。]

   Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns,
   L2Ls, result in a list of URIs being returned to the client. The
   text/uri-list Internet Media Type is defined to provide a simple
   format for the automatic processing of such lists of URIs.

N2Lsなどのいくつかの解決サービスのリクエスト、N2Ns、L2Ns(L2Ls)はクライアントに返されるURIのリストをもたらします。 uriテキスト/リストインターネットメディアTypeは、URIのそのようなリストの自動処理のための簡単な形式を提供するために定義されます。

   The format of text/uri-list resources is:

uriテキスト/リストリソースの形式は以下の通りです。

   1) Any lines beginning with the '#' character are comment lines
      and are ignored during processing. (Note that '#' is a character
      that may appear in URIs, so it only denotes a comment when it is the
      first character on a line).
   2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
      according to the URI specification RFC[6]. Each URI shall appear on
      one and only one line.
   3) As for all text/* formats, lines are terminated with a CR LF pair,
      although clients should be liberal in accepting lines with only
      one of those characters.

1) '#'キャラクタと共に始まるどんな線も、注釈行であり、処理の間、無視されます。 (線の上の最初のキャラクタであるときにだけ、コメントを指示するために'#'がURIに現れるかもしれないキャラクタであることに注意してください。) 2) 残っている非注釈行はURI仕様RFC[6]によると、コード化されたURIであるに違いありません(URNsかURL)。 各URIは唯一無二の1つの線の上に現れるものとします。 3) すべてのテキスト/*形式に関して、線はCR LF組と共に終えられます、クライアントが1だけでそれらのキャラクタに線を受け入れるのにおいて寛容であるべきですが。

   In applications where one URI has been mapped to a list of URIs, such
   as in response to the N2Ls request, the first line of the text/uri-
   list response SHOULD be a comment giving the original URI.

N2Ls要求に対応したなど1つのURIがURIのリストに写像されたアプリケーション、テキスト/uriリスト応答SHOULDの最初の線では、オリジナルのURIを与えるコメントになってください。

   An example of such a result for the N2L request is shown below in
   figure 1.

N2L要求のためのそのような結果に関する例は図1に以下に示されます。

        # urn:cid:foo@huh.org
        http://www.huh.org/cid/foo.html
        http://www.huh.org/cid/foo.pdf
        ftp://ftp.foo.org/cid/foo.txt

# つぼ:Cid: foo@huh.org http://www.huh.org/Cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt

               Figure 1: Example of the text/uri-list format

図1: uriテキスト/リスト形態に関する例

Appendix B:  n2l.pl script
==========================

付録B: n2l. plスクリプト==========================

   This is a simple CGI script for the N2L resolution service. It
   assumes the presence of a DBM database to store the URN to URL
   mappings. This script does not specify standard behavior, it is
   provided merely as a courtesy for implementors. In fact, this script
   does not process incoming Accept: headers, nor does it generate
   status codes. Such behavior should be part of a real script for any
   of the resolution services.

これはN2L解決サービスのための簡単なCGIスクリプトです。 それは、DBMデータベースの存在がURLマッピングにURNを格納すると仮定します。 このスクリプトは標準の振舞いを指定しないで、単に作成者のための礼儀としてそれを提供します。 事実上、このスクリプトは入って来るAcceptを処理しません: ヘッダー、または、それはステータスコードを発生させません。 そのような振舞いは解決サービスのどれかのための本当のスクリプトの一部であるべきです。

Daniel                        Experimental                      [Page 7]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[7ページ]RFC2169HTTP

    #!/bin/perl
    # N2L  - performs urn to url  resolution

#/bin/perl#N2L--、url解決につぼを実行します。

    $n2l_File = "...filename for DBM database...";

「$n2l_ファイル=」…「DBMデータベースのためのファイル名」…;

    $urn = $ENV{'QUERY_STRING'} ;

$つぼ=$ENVは'_ストリングについて質問します'。

    # Sanity check on the URN. Minimum length of a valid URN is
    # 7 characters - "urn:", a 1-character Namespace ID, ":", and
    # a 1-character namespace-specific string. More elaborate
    # sanity checks should be part of a real resolver script.
    if(length($urn)<7)
    {
        $error=1;
    }

# URNにおける健全度チェック。 「有効なURNの最小の長さは#7キャラクタです--、「つぼ:」、1キャラクタのNamespace ID、」、: 」 1キャラクタの#a名前空間特有のストリング。 より入念な#健全度チェックが本当のレゾルバスクリプトの一部であるべきである、(長さ($つぼ)の<7)です。$誤り=1。

    if(!$error)
    {
        # Convert lexically equivalent versions of a URI into
        # a canonical version for DB lookups.
        $urn =~ s/^urn:([^:]*):(.*)$/sprintf("urn:%s:%s", lc $1, $2)/ie;

($誤り)である、#Convert、DBルックアップ$つぼの=~s/^つぼのための#a正準なバージョンへのURIの辞書的に同等なバージョン:、[^:、]、*) : (. *)$/sprintf(「つぼ: %s: %s」は1ドルをlcします、2ドルである)/ie。

        dbmopen(%lu,$n2l_File,0444);
        if($lu{$urn})
        {
            $url=$lu{$urn};
            print STDOUT "Location: $url\n\n";
        }else{
            $error=2;
        }
        dbmclose(%lu);
    }

dbmopen(%Lu、$n2l_ファイル、0444)。 ($Lu$つぼ)である、$urlは$Lu$つぼと等しいです; STDOUTを印刷してください、「位置: $url\n\n」;、ほか、$誤り=2;、dbmclose(%Lu)。 }

    if($error)
    {
        print "Content-Type: text/html \n\n";
        print "<html>\n";
        print "<head><title>URN Resolution: N2L</title></head>\n";
        print "<BODY>\n";
        print "<h1>URN to URL resolution failed for the URN:</h1>\n";
        print "<hr><h3>$urn</h3>\n";
        print "</body>\n";
        print "</html>\n";
    }

($誤り)です。印刷..コンテントタイプ..テキスト..印刷..印刷..ヘッド..タイトル..つぼ..解決..タイトル..ヘッド..印刷..ボディー..印刷..URL..解決..失敗..印刷..時間..つぼ..印刷..ボディー..印刷

    exit;

出てください。

Daniel                        Experimental                      [Page 8]

RFC 2169                 HTTP in URN Resolution                June 1997

つぼの解決1997年6月のダニエル実験的な[8ページ]RFC2169HTTP

References:
===========

参照: ===========

   [1] Daniel, Ron and Michael Mealling, RFC 2168, "Resolution of Uniform
       Resource Identifiers using the Domain Name System", June 1997.

[1] ダニエルとロンとマイケルMealling、RFC2168、「ドメインネームシステムを使用するUniform Resource Identifierの決議」、1997年6月。

   [2] Berners-Lee, T, R. Fielding, H. Frystyk, RFC 1945, "Hypertext
       Transfer Protocol -- HTTP/1.0", T. Berners-Lee, May 1996.

[2] バーナーズ・リー、T、R.フィールディング、H.Frystyk、RFC1945、「HTTP/1インチ、T.バーナーズ・リー、1996年ハイパーテキスト転送プロトコル--5月。」

   [3] Fielding, R., J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee,
       RFC 2068, "Hypertext Transfer Protocol -- HTTP/1.1", Jan. 1997.

[3] フィールディング、R.、J.Gettys、J.C.ムガール人、H.Frystyk、T.バーナーズ・リー、RFC2068「HTTP/1.1インチ、1997年ハイパーテキスト転送プロトコル--1月」。

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

R.、RFC2141、「つぼの構文」という[4]堀は1997がそうするかもしれません。

   [5] URN-WG. "URN Resolution Services". Work In Progress.

[5] つぼ-WG。 「つぼの解決サービス。」 進行中で、働いてください。

   [6] Berners-Lee, T., RFC 1630, "Universal Resource Identifiers in WWW:
       A Unifying Syntax for the Expression of Names and Addresses of
       Objects on the Network as used in the World-Wide Web", June 1994.

[6] バーナーズ・リー、T.、RFC1630、「WWWの普遍的なリソース識別子:」 1994年6月の「WWWに使用されるNetworkの上のObjectsのNamesとAddressesのExpressionのためのUnifying Syntax。」

Security Considerations
=======================

セキュリティ問題=======================

   Communications with a resolver may be of a sensitive nature. Some
   resolvers will hold information that should only be released to
   authorized users. The results from resolvers may be the target of
   spoofing, especially once electronic commerce transactions are common
   and there is money to be made by directing users to pirate
   repositories rather than repositories which pay royalties to
   rightsholders. Resolution requests may be of interest to traffic
   analysts. The requests may also be subject to spoofing.

レゾルバとのコミュニケーションは敏感な本質のものであるかもしれません。 何人かのレゾルバが認定ユーザに発表されるだけであるべきである情報を保持するでしょう。 レゾルバからの結果は特に、いったん電子商取引取引が一般的であり、ロイヤリティをrightsholdersに支払う倉庫よりむしろ倉庫に海賊を働かせるようユーザに指示することによって稼がれるお金があるとだますという目標であるかもしれません。 交通アナリストに、解決要求は興味深いかもしれません。 また、要求もスプーフィングを受けることがあるかもしれません。

   The requests and responses in this draft are amenable to encoding,
   signing, and authentication in the manner of any other HTTP traffic.

この草稿における要求と応答はいかなる他のHTTP交通の方法でもコード化、調印、および認証に従順です。

Author Contact Information:
===========================

問い合わせ先を書いてください: ===========================

   Advanced Computing Lab, MS B287
   Los Alamos National Laboratory
   Los Alamos, NM, USA, 87545
   voice:  +1 505 665 0597
   fax:    +1 505 665 4939
   email:  rdaniel@lanl.gov

高度なComputing Lab、MS B287ロスアラモス国立研究所ロスアラモス(ニューメキシコ)米国87545声: +1 0597年の505 665ファックス: +1 4939年の505 665メール: rdaniel@lanl.gov

Daniel                        Experimental                      [Page 9]

ダニエルExperimentalです。[9ページ]