[要約] RFC 4501は、DNSのURI（Uniform Resource Identifier）に関する仕様を定めたものであり、DNSとURIの相互運用性を向上させることを目的としています。
Network Working Group S. Josefsson
Request for Comments: 4501 SJD
Category: Standards Track May 2006
Domain Name System Uniform Resource Identifiers
ドメイン名システムユニフォームリソース識別子
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document defines Uniform Resource Identifiers for Domain Name System resources.
このドキュメントでは、ドメイン名システムリソースの均一なリソース識別子を定義します。
Table of Contents
目次
1. Introduction and Background . . . . . . . . . . . . . . . . . 2
2. Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. DNS URI Registration . . . . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
The Domain Name System (DNS) [1] [2] is a widely deployed system used, among other things, to translate host names into IP addresses. Several protocols use Uniform Resource Identifiers (URIs) to refer to data. By defining a URI scheme for DNS data, the gap between these two worlds is bridged. The DNS URI scheme defined here can be used to reference any data stored in the DNS.
ドメイン名システム（DNS）[1] [2]は、特にホスト名をIPアドレスに変換するために使用される広く展開されているシステムです。いくつかのプロトコルは、均一なリソース識別子（URI）を使用してデータを参照しています。DNSデータのURIスキームを定義することにより、これら2つの世界間のギャップが橋渡しされます。ここで定義されているDNS URIスキームは、DNSに保存されているデータを参照するために使用できます。
Data browsers may support DNS URIs by forming DNS queries and rendering DNS responses using HTML [12], which is similar to what is commonly done for FTP [6] resources. Applications that are Multipurpose Internet Mail Extensions (MIME) [7] aware may tag DNS data retrieved using this scheme with the text/dns or application/dns types as specified in [15].
データブラウザーは、DNSクエリを形成し、HTML [12]を使用してDNS応答をレンダリングすることにより、DNS URIをサポートする場合があります。これは、FTP [6]リソースで一般的に行われるものと同様です。多目的インターネットメールエクステンション（MIME）[7]であるアプリケーションは、[15]で指定されているように、このスキームを使用してこのスキームを使用して取得したDNSデータを取得します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [3]に記載されているように解釈される。
Refer to section 1 of [5] for an in-depth discussion of URI classifications. In particular, the reader is assumed to be familiar with the distinction between "name" and "locator". This section describes how the DNS URI scheme is intended to be used and outlines future work that may be required to use URIs with the DNS for some applications.
URI分類の詳細な説明については、[5]のセクション1を参照してください。特に、読者は「名前」と「ロケーター」の区別に精通していると想定されています。このセクションでは、DNS URIスキームを使用する方法を説明し、一部のアプリケーションにDNSでURIを使用するために必要な将来の作業の概要を説明します。
The URI scheme described in this document focuses on the data stored in the DNS. As such, there is no provision to specify any of the fields in the actual DNS protocol. This is intended so that the URI may be used even in situations where the DNS protocol is not used directly. Two examples for this are zone file editors and DNS-related configuration files, which may use this URI scheme to identify data. The application would not use the DNS protocol to resolve the URIs.
このドキュメントで説明されているURIスキームは、DNSに保存されているデータに焦点を当てています。そのため、実際のDNSプロトコルにフィールドを指定する規定はありません。これは、DNSプロトコルが直接使用されない状況でもURIを使用できるように意図されています。これの2つの例は、ゾーンファイルエディターとDNS関連の構成ファイルです。このURIスキームを使用してデータを識別することができます。アプリケーションは、URIを解決するためにDNSプロトコルを使用しません。
A limitation of this design is that it does not accommodate all protocol parameters within the DNS protocol. It is expected that, for certain applications, a more detailed URI syntax that maps more closely to the DNS protocol may be required. However, such a URI definition is not included in this document. This document specifies a URI that is primarily intended to name DNS resources, but it can also be used to locate said resources for simple, yet common, applications.
この設計の制限は、DNSプロトコル内のすべてのプロトコルパラメーターに対応していないことです。特定のアプリケーションでは、DNSプロトコルにより密接にマップするより詳細なURI構文が必要になる場合があると予想されます。ただし、このようなURI定義はこのドキュメントに含まれていません。このドキュメントは、主にDNSリソースに名前を付けることを目的としたURIを指定しますが、シンプルではあるが一般的なアプリケーションのリソースを見つけるためにも使用できます。
This section contains the registration template for the DNS URI scheme in accordance with [11].
このセクションには、[11]に従ってDNS URIスキームの登録テンプレートが含まれています。
URL scheme name: "dns".
URLスキーム名：「DNS」。
URL scheme syntax: A DNS URI designates a DNS resource record set, referenced by domain name, class, type, and, optionally, the authority. The DNS URI follows the generic syntax from RFC 3986 [5] and is described using ABNF [4]. Strings are not case sensitive, and free insertion of linear-white-space is not permitted.
URLスキームの構文：DNS URIは、ドメイン名、クラス、タイプ、およびオプションでは権限で参照されるDNSリソースレコードセットを指定します。DNS URIは、RFC 3986 [5]の汎用構文に従い、ABNF [4]を使用して記載されています。文字列はケースに敏感ではなく、線形ホワイトスペースの自由な挿入は許可されていません。
dnsurl = "dns:" [ "//" dnsauthority "/" ] dnsname ["?" dnsquery]
dnsurl = "dns：" ["//" dnsauthority "/"] dnsname ["？"dnsquery]
dnsauthority = host [ ":" port ] ; See RFC 3986 for the ; definition of "host" and "port".
dnsauthority = host ["：" port];RFC 3986については、「ホスト」と「ポート」の定義。
dnsname = *pchar
; See RFC 3986 for the
; definition of "pchar".
; The "dnsname" field may be a
; "relative" or "absolute" name,
; as per RFC 1034, section 3.1.
; Note further that an empty
; "dnsname" value is to be
; interpreted as the root itself.
; See below on relative dnsnames.
dnsquery = dnsqueryelement [";" dnsquery]
dnsquery = dnsqueryElement [";"dnsquery]
dnsqueryelement = ( "CLASS=" dnsclassval ) / ( "TYPE=" dnstypeval )
; Each clause MUST NOT be used more
; than once.
dnsclassval = 1*digit / "IN" / "CH" /
<Any IANA registered DNS class mnemonic>
dnstypeval = 1*digit / "A" / "NS" / "MD" /
<Any IANA registered DNS type mnemonic>
Unless specified in the URI, the authority ("dnsauthority") is assumed to be locally known, the class ("dnsclassval") to be the Internet class ("IN"), and the type ("dnstypeval") to be the Address type ("A"). These default values match the typical use of DNS: to look up addresses for host names.
URIで指定されていない限り、当局（「dnsauthority」）はローカルで知られていると想定されています。タイプ（ "a"）。これらのデフォルト値は、DNSの典型的な使用と一致します。ホスト名のアドレスを検索します。
A dnsquery element MUST NOT contain more than one occurrence of the "CLASS" and "TYPE" fields. For example, both "dns: example?TYPE=A;TYPE=TXT" and "dns:example?TYPE=A;TYPE=A" are invalid. However, the fields may occur in any order, so that both "dns: example?TYPE=A;CLASS=IN" and "dns:example?CLASS=IN;TYPE=A" are valid.
dnsquery要素には、「クラス」と「タイプ」フィールドの1つ以上の発生を含めてはなりません。たとえば、「dns：example？type = a; type = txt」と「dns：example？type = a; type = a」ただし、フィールドは任意の順序で発生する可能性があるため、両方の「dns：example？type = a; class = in」と "dns：example？class = in; type = a"は有効です。
The digit representation of types and classes MAY be used when a mnemonic for the corresponding value is not well known (e.g., for newly introduced types or classes), but it SHOULD NOT be used for the types or classes defined in the DNS specification [2]. All implementations MUST recognize the mnemonics defined in [2].
タイプとクラスの数字表現は、対応する値のニーモニックがあまり知られていない場合（たとえば、新しく導入されたタイプまたはクラスの場合）使用できますが、DNS仕様で定義されているタイプまたはクラスに使用しないでください[2]。すべての実装は、[2]で定義されているニーモニックを認識する必要があります。
To avoid ambiguity, relative "dnsname" values (i.e., those not ending with ".") are assumed to be relative to the root. For example, "dns: host.example" and "dns:host.example." both refer to the same owner name; namely, "host.example.". Further, an empty "dnsname" value is considered a degenerative form of a relative name, which refers to the root (".").
あいまいさを避けるために、相対的な「dnsname」値（つまり、「 "で終わらないもの）がルートに関連していると想定されます。たとえば、「dns：host.example」および「dns：host.example」。どちらも同じ所有者名を参照しています。つまり、「host.example。」。さらに、空の「dnsname」値は、root（ "。"）を指す相対名の変性形式と見なされます。
To resolve a DNS URI using the DNS protocol [2], a query is created, using as input the dnsname, dnsclassval, and dnstypeval from the URI string (or the appropriate default values). If an authority ("dnsauthority") is given in the URI string, this indicates the server that should receive the DNS query. Otherwise, the default DNS server should receive it.
DNSプロトコル[2]を使用してDNS URIを解決するために、URI文字列（または適切なデフォルト値）からDNSName、DNSClassval、およびDNSTypevalを入力するように使用してクエリが作成されます。権限（「dnsauthority」）がURI文字列に与えられている場合、これはDNSクエリを受信するサーバーを示します。それ以外の場合、デフォルトのDNSサーバーはそれを受信する必要があります。
Note that DNS URIs could be resolved by other protocols than the DNS protocol, or by using the DNS protocol in some other way than as described above (e.g., multicast DNS). DNS URIs do not require the use of the DNS protocol, although it is expected to be the typical usage. The previous paragraph only illustrates how DNS URIs are resolved using the DNS protocol.
DNS URIは、DNSプロトコルよりも他のプロトコルによって、または上記のように他の方法でDNSプロトコルを使用することで解決できることに注意してください（例：マルチキャストDNS）。DNS URIは、典型的な使用法になると予想されていますが、DNSプロトコルの使用を必要としません。前の段落は、DNSプロトコルを使用してDNS URIがどのように解決されるかを示しています。
A client MAY want to check that it understands the dnsclassval and dnstypeval before sending a query, so that it will be able to understand the response. However, a typical example of a client that would not need to check dnsclassval and dnstypeval would be a proxy that would just treat the received answer as opaque data.
クライアントは、クエリを送信する前にDNSClassvalとDNSTypevalを理解していることを確認して、応答を理解できるようにすることができます。ただし、DNSClassvalとDnStypevalを確認する必要がないクライアントの典型的な例は、受け取った回答を不透明なデータとして扱うだけのプロキシです。
Character encoding considerations: Characters are encoded as per RFC 3986 [5]. The DNS protocol does not consider character sets; it simply transports opaque data. In particular, the "dnsname" field of the DNS URI is to be considered an internationalized domain name (IDN) unaware domain name slot, in the terminology of RFC 3940 [14]. The considerations for "host" and "port" are discussed in [5].
文字エンコードの考慮事項：文字はRFC 3986 [5]に従ってエンコードされます。DNSプロトコルは、文字セットを考慮していません。不透明なデータを単純に輸送します。特に、DNS URIの「DNSNAME」フィールドは、RFC 3940の用語で、国際化ドメイン名（IDN）のないドメイン名スロットと見なされます[14]。「ホスト」と「ポート」の考慮事項は[5]で説明されています。
Because "." is used as the DNS label separator, an escaping mechanism is required to encode a "." that is part of a DNS label. The escaping mechanism is described in section 5.1 of RFC 1035 [2]. For example, a DNS label of "exa.mple" can be escaped as "exa\.mple" or "exa\046mple". However, the URI specification disallows the "\" character from occurring directly in URIs, so it must be escaped as "%5c". The single DNS label "exa.mple" is thus encoded as "exa% 5c.mple". The same mechanism can be used to encode other characters, for example, "?" and ";". Note that "." and "%2e" are equivalent within dnsname and are interchangeable.
なぜなら "。"DNSラベルセパレーターとして使用されます。「。」をエンコードするには、逃げるメカニズムが必要です。これはDNSラベルの一部です。脱出メカニズムは、RFC 1035 [2]のセクション5.1で説明されています。たとえば、「exa.mple」のDNSラベルは、「exa \ .mple」または「exa \ 046mple」として逃げることができます。ただし、URI仕様は「\」文字がURISで直接発生することを許可するため、「％5C」として逃げる必要があります。したがって、単一のDNSラベル「exa.mple」は、「exa％5c.mple」としてエンコードされます。同じメカニズムを使用して、他の文字をエンコードすることができます。たとえば、「？」と ";"。ご了承ください "。"「％2e」はdnsname内で同等であり、交換可能です。
This URI specification allows all possible domain names to be encoded, provided the encoding rules are observed per [5]). However, certain applications may restrict the set of valid characters. Care should be taken so that invalid characters in these contexts do not cause harm. In particular, host names in the DNS have certain restrictions. It is up to these applications to limit this subset; this URI scheme places no restrictions.
このURI仕様により、エンコードルールが[5]ごとに観察されている場合、可能なすべてのドメイン名をエンコードできます。ただし、特定のアプリケーションは有効な文字のセットを制限する場合があります。これらの文脈で無効なキャラクターが害を引き起こさないように、注意する必要があります。特に、DNSのホスト名には特定の制限があります。このサブセットを制限するのはこれらのアプリケーション次第です。このURIスキームは制限を課しません。
Intended usage: Whenever it is useful for DNS resources to be referenced by protocol-independent identifiers. Often, this occurs when the data is more important than the access method. Since software in general has coped without this so far, it is not anticipated to be implemented widely, nor migrated to by existing systems, but specific solutions (especially security-related) may find this appropriate.
意図された使用法：DNSリソースがプロトコルに依存しない識別子によって参照されることが役立つ場合はいつでも。多くの場合、これはデータがアクセス方法よりも重要である場合に発生します。ソフトウェアはこれまでにこれなしに対処しているため、広く実装されることも既存のシステムに移行することも予想されていませんが、特定のソリューション（特にセキュリティ関連）はこれが適切である可能性があります。
Applications and/or protocols that use this scheme include Security-related software, DNS administration tools, and network programming packages.
このスキームを使用するアプリケーションおよび/またはプロトコルには、セキュリティ関連ソフトウェア、DNS管理ツール、ネットワークプログラミングパッケージが含まれます。
Interoperability considerations: The data referenced by this URI scheme might be transferred by protocols that are not URI aware (such as the DNS protocol). This is not anticipated to have any serious interoperability impact.
相互運用性の考慮事項：このURIスキームで参照されるデータは、URI認識のないプロトコル（DNSプロトコルなど）によって転送される場合があります。これは、深刻な相互運用性の影響を与えるとは予想されていません。
Interoperability problems may occur if one entity understands a new DNS class/type mnemonic that another entity does not. This is an interoperability problem for DNS software in general, although it is not a major practical problem for current DNS deployments, as the DNS types and classes are fairly static. To guarantee interoperability, implementations can use integers for all mnemonics not defined in [2].
あるエンティティが別のエンティティにはない新しいDNSクラス/タイプのニーモニックを理解している場合、相互運用性の問題が発生する可能性があります。これは一般的にDNSソフトウェアにとって相互運用性の問題ですが、DNSのタイプとクラスはかなり静的であるため、現在のDNS展開にとっては大きな実用的な問題ではありません。相互運用性を保証するために、実装は[2]で定義されていないすべてのニーモニックに対して整数を使用できます。
Interaction with Binary Labels [10] or other extended label types has not been analyzed. However, binary labels appear to be infrequently used in practice.
バイナリラベルとの相互作用[10]または他の拡張ラベルタイプは分析されていません。ただし、バイナリラベルは実際にはまれに使用されているようです。
Contact: simon@josefsson.org
連絡先：simon@josefsson.org
Author/Change Controller: simon@josefsson.org
著者/変更コントローラー：simon@josefsson.org
A DNS URI is of the following general form. This is intended to illustrate, not define, the scheme:
DNS URIは、次の一般的な形式です。これは、スキームを定義するのではなく説明することを目的としています。
dns:[//authority/]domain[?CLASS=class;TYPE=type]
The following illustrates a URI for a resource with the absolute name "www.example.org.", the Internet (IN) class, and the Address (A) type:
以下は、絶対名「www.example.org」、インターネット（in）クラス、およびアドレス（a）タイプのリソースのURIを示しています。
dns:www.example.org.?clAsS=IN;tYpE=A
Since the default class is IN and the default type is A, the same resource can be identified by a shorter URI using a relative name:
デフォルトのクラスが存在し、デフォルトのタイプはaであるため、相対名を使用した短いURIによって同じリソースを識別できます。
dns:www.example.org
DNS：www.example.org
The following illustrates a URI for a resource with the name "simon.example.org" for the CERT type in the Internet (IN) class:
以下は、インターネット（in）クラスの証明書タイプの「simon.example.org」という名前のリソースのURIを示しています。
dns:simon.example.org?type=CERT
DNS：simon.example.org？type = cert
The following illustrates a URI for a resource with the name "ftp.example.org", in the Internet (IN) class and the address (A) type, but from the DNS authority 192.168.1.1 instead of the default authority:
以下は、「FTP.example.org」という名前のリソースのURIを示しています。インターネット（in）クラス（a）タイプ（a）タイプですが、デフォルトの権限の代わりにDNS機関192.168.1.1からです。
dns://192.168.1.1/ftp.example.org?type=A
DNS：//192.168.1.1/ftp.example.org？type = a
The following illustrates various escaping techniques. The owner name would be "world wide web.example\.domain.org", where "\." denotes the character "." as part of a label, and "." denotes the label separator:
以下は、さまざまな脱出技術を示しています。所有者の名前は、「World Wide Web.example \ .domain.org」で、「\。」になります。キャラクターを示します。ラベルの一部として、および「。」ラベルセパレーターを示します：
dns:world%20wide%20web.example%5c.domain.org?TYPE=TXT
dns：world％20wide％20web.example％5c.domain.org？type = txt
The following illustrates a strange but valid DNS resource:
以下は、奇妙だが有効なDNSリソースを示しています。
dns://fw.example.org/*.%20%00.example?type=TXT
Thanks to Stuart Cheshire, Donald Eastlake, Pasi Eronen, Bill Fenner, Ted Hardie, Russ Housley, Peter Koch, Andrew Main, Larry Masinter, Michael Mealling, Steve Mattson, Marcos Sanz, Jason Sloderbeck, Paul Vixie, Sam Weiler, and Bert Wijnen for comments and suggestions. The author acknowledges RSA Laboratories for supporting the work that led to this document.
スチュアート・チェシャー、ドナルド・イーストレイク、パシ・エロネン、ビル・フェンナー、テッド・ハーディ、ラス・ハウリー、ピーター・コッホ、アンドリュー・メイン、ラリー・マシン留め、マイケル・ミーリング、スティーブ・マットソン、マルコス・サンツ、ジェイソン・スロダーベック、ポール・ヴィクシー、サム・ワイラー、ベルト・ウィジネネニーコメントや提案のために。著者は、この文書につながった作業をサポートしているRSA研究所を認めています。
If a DNS URI references domains in the Internet DNS environment, both the URI itself and the information referenced by the URI is public information. If a DNS URI is used within an "internal" DNS environment, both the DNS URI and the data referenced should be handled using the same considerations that apply to DNS data in the "internal" environment.
DNS URIがインターネットDNS環境でドメインを参照する場合、URI自体とURIが参照する情報の両方が公開情報です。DNS URIが「内部」DNS環境内で使用されている場合、「内部」環境のDNSデータに適用される同じ考慮事項を使用して、DNS URIと参照データの両方を処理する必要があります。
If information referenced by DNS URIs are used to make security decisions (such data includes, but is not limited to, certificates stored in the DNS [9]), implementations may need to employ security techniques such as Secure DNS [16], CMS [13], or OpenPGP [8], to protect the data during transport. How to implement this will depend on the usage scenario, and it is not up to this URI scheme to define how the data referenced by DNS URIs should be protected.
DNS URISが参照する情報を使用してセキュリティ決定を行うために使用されます（このようなデータには、DNS [9]に保存されている証明書が含まれますが、これらに限定されません[9]）、実装は安全なDNS [16]、CMSなどのセキュリティ技術を採用する必要がある場合があります。13]、または輸送中のデータを保護するためのOpenPGP [8]。これを実装する方法は、使用法のシナリオに依存し、DNS URIによって参照されるデータを保護する方法を定義するのはこのURIスキームに頼っていません。
If applications accept unknown dnsqueryelement values in a URI (e.g., URI "dns:www.example.org?secret=value") without knowing what the "secret=value" dnsqueryelement means, a covert channel used to "leak" information may be enabled. The implications of covert channels should be understood by applications that accept unknown dnsqueryelement values.
アプリケーションがURIの不明なdnsqueryElement値を受け入れる場合（例：uri "dns：www.example.org？secret = value"）、「secret = value」dnsqueryelementが意味することを知らずに、「リーク」情報に使用される秘密のチャネルは有効になっています。秘密のチャネルの意味は、未知のdnsqueryelement値を受け入れるアプリケーションによって理解されるべきです。
Slight variations, such as the difference between upper and lower case in the dnsname field, can be used as a covert channel to leak information.
DNSNAMEフィールドの高級ケースと小文字の違いなどのわずかなバリエーションは、情報をリークするための秘密のチャネルとして使用できます。
The IANA has registered the DNS URI scheme, using the template in section 3, in accordance with RFC 2717 [11].
IANAは、RFC 2717 [11]に従って、セクション3のテンプレートを使用して、DNS URIスキームを登録しています。
Copyright (c) 2000, 2001, 2002, 2003, 2004, 2005, 2006 Simon Josefsson
Copyright（c）2000、2001、2002、2003、2004、2005、2006 Simon Josefsson
Regarding this entire document or any portion of it, the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.
このドキュメント全体またはその一部に関して、著者は保証を行わず、その使用に起因する損害について責任を負いません。著者は、再配分されたデリバティブ作業に誤解を招く著者またはバージョン情報が含まれていない限り、他の人がそれを使用、変更、および配布する権利を減少させない方法で使用、変更、配布する人に取消不能の許可を与えます。デリバティブ作業は、同様の条件でライセンスされる必要はありません。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[4] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[6] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[6] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[7] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[7] Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、BCP 13、RFC 2048、1996年11月。
[8] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[8] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[9] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999.
[9] Eastlake 3rd、D。およびO. Gudmundsson、「ドメイン名システム（DNS）に証明書の保存」、RFC 2538、1999年3月。
[10] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[10] Crawford、M。、「ドメイン名システムのバイナリラベル」、RFC 2673、1999年8月。
[11] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[11] Petke、R。およびI. King、「URLスキーム名の登録手順」、BCP 35、RFC 2717、1999年11月。
[12] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[12] Connolly、D。およびL. Masinter、「The 'Text/HTML' Media Type」、RFC 2854、2000年6月。
[13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[13] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[14] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[14] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[15] Josefsson, S., "Domain Name System Media Types", RFC 4027, April 2005.
[15] Josefsson、S。、「ドメイン名システムメディアタイプ」、RFC 4027、2005年4月。
[16] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[16] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
Author's Address
著者の連絡先
Simon Josefsson SJD
サイモン・ジョセフソンSJD
EMail: simon@josefsson.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。