RFC 4095 - Attaching Meaning to Solicitation Class Keywords 日本語訳

URL : https://tools.ietf.org/html/rfc4095
タイトル : RFC 4095 - 勧誘クラスキーワードに意味の取り付け
翻訳編集 : 自動生成

Network Working Group                                         C. Malamud
Request for Comments: 4095                           Memory Palace Press
Category: Standards Track                                       May 2005

            Attaching Meaning to Solicitation Class Keywords

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2005）。

Abstract

抽象

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new "No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.

この文書では、ありませんが、SMTPサービス拡張を募集RFC 3865で定義されている勧誘クラス・キーワードに関連したURIを見つけるための仕組みを提案しています。勧誘クラスのキーワードは、「org.example.adv」として逆転されたドメイン名からなるシンプルなラベル、です。これらの勧誘クラスのキーワードは、選択されたヘッダフィールドに挿入されたり、新たな「ノー要請：」を含めない、ESMTPサービス拡張に使用されている、ヘッダ、送信者によって挿入された一つ以上の勧誘クラスのキーワードを含めることができます。

This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword.

この文書は、RFC 3401および関連するドキュメントで説明したダイナミックな委譲発見システム（DDDS）に基づいてアプリケーションを指定します。アルゴリズムは、その勧誘クラス・キーワードの意味と使用法に関する詳細な情報が含まれているURIと勧誘クラスのキーワードを関連付けるために指定されています。たとえば、「example.org」ドメインの登録者は、「org.example.adv」勧誘クラス・キーワードに関する詳細な情報が含まれているURIを作成するには、このメカニズムを使用することができます。

Table of Contents

   1. Solicitation Class Keywords .....................................2
      1.1. Terminology ................................................3
   2. The No-Solicit NAPTR Application ................................3
   3. Example .........................................................5
   4. DDDS Application Specification ..................................7
   5. Acknowledgements ................................................8
   6. Security Considerations .........................................8
   7. IANA Considerations .............................................9
   8. References ......................................................9
      8.1. Normative References .......................................9
      8.2. Informative References ....................................10

1. Solicitation Class Keywords

1.募集クラスのキーワード

[RFC3865] defines the concept of a "solicitation class keyword", which is an arbitrary string or label which can be associated with an electronic mail message and transported by the ESMTP mail service as defined in [RFC2821] and related documents. Solicitation class keywords are formatted like domain names, but reversed. For example, the zone administrator of "example.com" might specify a particular solicitation class keyword such as "com.example.adv" that could be inserted in a "No-Solicit:" header by the message sender or in a trace field by a message transfer agent (MTA). This solicitation class keyword is inserted by the sender of the message, who may also insert a variety of other solicitation class keywords as defined by the sender or by other parties.

[RFC3865]は任意の文字列またはラベル[RFC2821]で定義されるように、電子メールメッセージに関連付けられ、ESMTPメールサービスによって搬送することができ、関連文書である「勧誘クラスキーワード」の概念を定義します。勧誘クラス・キーワードは、ドメイン名のようにフォーマットされたが、逆になっています。メッセージ送信者によって、またはトレースフィールドのヘッダー：「無要請」、例えば、「example.com」のゾーン管理者は、そのような中に挿入することができる「com.example.adv」として特定勧誘クラスキーワードを指定することがメッセージ転送エージェント（MTA）によります。この勧誘クラス・キーワードは、送信者または他の関係者によって定義されているようにも他の勧誘クラスのさまざまなキーワードを挿入することができるメッセージの送信者によって挿入されています。

[RFC3865] explicitly places discovery of the meaning of a solicitation class keyword as outside of the scope of the basic ESMTP service extension. For the purposes of message transport, these solicitation class keywords are opaque. However, if RFC 3865 becomes widely used, a mail message might contain a large number of solicitation class keywords. The "No-Solicit:" header has keywords inserted by the sender of the message, which might include the sender's own keywords, as well as those mandated by regulatory authorities or recommended by voluntary industry associations. Likewise, the "received:" trace fields might contain a large number of keywords produced by message transfer agents, filtering software, forwarding software in the message user agent (MUA), or any other system in the chain of delivery.

[RFC3865]は、明示的、基本的なESMTPサービス拡張の適用範囲外と勧誘クラス・キーワードの意味の発見を配置します。メッセージトランスポートのために、これらの勧誘クラスのキーワードは不透明です。 RFC 3865が広く使用されてしまう場合は、メールメッセージは、勧誘クラスの多数のキーワードが含まれている場合があります。「無要請：」ヘッダは、送信者の独自のキーワードだけでなく、規制当局によって義務付けや自主的な業界団体が推奨されているものが含まれる可能性があるメッセージの送信者によって挿入されたキーワードを持っています。同様に、「受信した：」フィールドはメッセージ・ユーザ・エージェント（MUA）、または送達の鎖中の任意の他のシステムにソフトウェアを転送し、ソフトウェアをフィルタリングする、メッセージ転送エージェントによって生成されたキーワードが多数含まれている場合がありますトレース。

As the number of keywords employed grows, it will be important to find a method for discovering the meaning behind the various solicitation class keywords. This document specifies such a mechanism, associating a solicitation class keyword with a URI which contains further information by using the DNS NAPTR Resource Record, which is defined in [RFC3403]. An explicit design goal is to keep the system as simple as possible. Approaches such as defining an XML-based structure that would contain specific meta-data about the solicitation class keyword or other approaches that define the format of the explanation were ruled out. Instead, the goal is to simply to associate a solicitation class keyword with a URI, which in turn contains an explanation of the keyword.

使用したキーワードの数が増えるにつれ、様々な勧誘クラスのキーワードの後ろの意味を発見するための方法を見つけることが重要になります。このドキュメントは[RFC3403]で定義されているDNS NAPTRリソースレコードを使用してさらに情報が含まURIと勧誘クラスキーワードを関連付ける、そのような機構を指定します。明示的な設計目標は、できるだけシンプルなシステムを維持することです。このよう勧誘クラスのキーワードや説明のフォーマットを定義する他のアプローチに関する特定のメタデータを含むことになり、XMLベースの構造を定義するようなアプローチが除外されました。代わりに、目標は、単に順番にキーワードの説明が含まれているURI、と勧誘クラスのキーワードを関連付けることです。

1.1. Terminology

1.1. 用語

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 BCP 14, [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、[RFC2119]に記載されているように解釈されます。

2. The No-Solicit NAPTR Application

2.無要請NAPTRアプリケーション

The DDDS framework of [RFC3401] and related documents provides a powerful set of mechanisms that can yield sophisticated applications such as ENUM as specified in [RFC3761]. There is a simplification of the DDDS framework called the Straightforward-NAPTR (S-NAPTR) application as specified in [RFC3958]. Unfortunately, S-NAPTR does not permit the use of the "U" flag for terminal lookups and does not support the regular expression field of the NAPTR RR. Since a replacement field in a NAPTR record must contain only a domain name, and our goal is to find a URI, this document does not use the S-NAPTR mechanism.

[RFC3401]及び関連文書のDDDSフレームワークは[RFC3761]で指定されるように、このようなENUMなどの高度なアプリケーションを得ることができる機構の強力なセットを提供します。 [RFC3958]で指定されるようにDDDSフレームワークの単純化は簡単-NAPTR（S-NAPTR）アプリケーションと呼ばあります。残念ながら、S-NAPTRは、端末のルックアップのための「U」フラグの使用を許可しないとNAPTR RRの正規表現のフィールドをサポートしていません。 NAPTRレコード内の置換フィールドは、ドメイン名のみが含まれている必要があり、そして私たちの目標は、URIを見つけることですので、この文書では、S-NAPTRメカニズムを使用していません。

This document uses the NAPTR RR to do a single lookup from solicitation class keyword to URI. The character "." is first substituted for any instances of the character ":" and then the solicitation class keyword is reversed, using the character "." as the delimiter. This becomes the domain name lookup key. For example, "org.example:ADV" becomes "ADV.example.org".

この文書は、URIへの勧誘クラス・キーワードから単一のルックアップを行うためにNAPTR RRを使用しています。キャラクター "。" 「：」最初の文字のすべてのインスタンスに代入され、その後、勧誘クラス・キーワードは、文字を使用して、逆転されます「」区切り文字として。これは、ドメイン名のルックアップキーとなります。たとえば、 "org.example：ADVは" "ADV.example.org" になります。

Note On Domain Names: RFC3865 states that a solicitation class keyword consists of a valid domain name followed by the ":" character and by additional valid characters. Several points are important to remember for implementors. Since domain names are case insensitive and the ":" character is translated to the "." character, for purposes of this DDDS application, the following solicitation class keywords are syntactically equivalent: "com.example:ADV", "com.Example:adv", and "com:example:ADV".

ドメイン名に関する注意：「：」の文字と、追加の有効な文字でRFC3865が勧誘クラス・キーワードが続く有効なドメイン名で構成されていることを述べています。いくつかのポイントは、実装者のために覚えておくことが重要です。ドメイン名は大文字小文字を区別しないとので、「：」の文字がに変換されます「」キャラクターは、このDDDS出願の目的のために、以下の勧誘クラスのキーワードは、構文的に等価である： "com.example：ADV"、 "com.Example：ADV"、および "COM：例：ADV"。

In addition, it is important to remember that the resulting string must meet other DNS validity checks. In particular, domain labels are limited to 63 characters in length and the total length of the resulting string must be less than 253 characters. Any non-ASCII characters must be encoded using the Internationalized Domain Names (IDN) specifications in [RFC3490] and related documents. Note that non-ASCII characters may be encoded after the ":" character as well.

また、結果の文字列は、他のDNSの有効性チェックを満たさなければならないことを覚えておくことが重要です。具体的には、ドメインのラベルの長さは63文字に制限され、得られた文字列の合計の長さが253文字以下でなければなりません。非ASCII文字は、国際化ドメイン名（IDN）[RFC3490]で仕様および関連文書を使用してエンコードする必要があります。「：」の文字を同様に非ASCII文字が後に符号化することができることに注意してください。

The fields of the NAPTR RR are used as follows:

次のようにNAPTR RRのフィールドが使用されます。

o The "ORDER" and "PREFERENCE" fields are to be processed as specified in [RFC3403]: if multiple records are returned, the one(s) with the lowest "ORDER" value that have a matching "SERVICE" field MUST be used. Of those with the lowest ORDER value, those with the lowest "PREFERENCE" SHOULD be used.

[RFC3403]で指定されるように「順序」および「PREFERENCE」フィールドoを処理すべきである：複数のレコードが返された場合、マッチング「SERVICE」フィールドを持っている最も低い「順序」の値を有するもの（複数可）を使用しなければなりません。最下位値を持つこれらのうち、最低の「PREFERENCE」のものを使用する必要があります。

o The "FLAGS" field MUST contain the character "U".

O「FLAGS」フィールドには、文字「U」を含まなければなりません。

o The "SERVICES" field MUST contain only the string "no-solicit".

「SERVICES」フィールドは文字列のみを含まなければならないoを「無勧誘ません」。

o The "REGEXP" field MUST contain a valid URI as further specified in this section.

「REGEXP」フィールドOなど、さらに、このセクションで指定された有効なURIを含まなければなりません。

o The "REPLACEMENT" field MUST be empty.

O「交換」フィールドが空である必要があります。

The "REGEXP" field is defined in [RFC3402] as consisting of a "delim-character", a POSIX Extended Regular Expression, another "delim-character", a replacement value, and a final "delim-character". For this application the following rules apply:

「REGEXP」フィールドは、「DELIM文字」、POSIX拡張正規表現、別の「DELIM文字」は、交換値、及び最終的な「DELIM文字」からなると[RFC3402]で定義されています。このアプリケーションでは、次の規則が適用されます。

o The "delim-character" MAY be any valid character as defined in section 3.2 of [RFC3402].

[RFC3402]のセクション3.2で定義されているO「でdelim文字は、」任意の有効な文字である場合があります。

o The extended regular expression MUST be empty.

O拡張正規表現は空でなければなりません。

o The replacement value MUST contain a valid URI as specified in [RFC3986].

[RFC3986]で指定されるように、O置換値は、有効なURIを含まなければなりません。

o The replacement value SHOULD contain a URI limited to the "ftp", "http", and "https" schemes as specified in [RFC3986] and [RFC2660].

[RFC3986]及び[RFC2660]で指定されるように置換値がURIを含むべきであるoをすると、「FTP」、「HTTP」と「HTTPS」の方式に限定されるもの。

o The document that is retrieved at the URI SHOULD conform to [HTML-4.01], including the Accessibility Guidelines contained therein.

oをURIで検索された文書は、その中に含まれるアクセシビリティガイドラインを含む、[HTML-4.01]に準拠すべきです。

3. Example

3.例

In this example, a set of NAPTR records are added to the "example.com" zone and can be retrieved using "dig" or other DNS utilities:

この例では、NAPTRレコードのセットは、「example.com」ゾーンに追加され、「DIG」または他のDNSユーティリティを使用して取得することができます。

[carl@example.com]% dig 2795.example.com naptr

【carl@example.com】％DIG 2795.example.com NAPTR

; <<>> DiG 9.2.3 <<>> 2795.example.com naptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43494 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 1

; << >>掘る9.2.3 << >> 2795.example.com NAPTR ;;グローバルオプション：printcmd ;;答えを得た：;; - >> HEADER << - オペコード：QUERY、状態：NOERROR、ID：43494 ;;フラグ：QR単三番目のRA; QUERY：1、ANSWER：5、AUTHORITY：2、ADDITIONAL：1

;; QUESTION SECTION: ;2795.example.com. IN NAPTR

;;質問セクション：; 2795.example.com。 NAPTR、IN

;; ANSWER SECTION: 2795.example.com. 86400 IN NAPTR 1 1 "U" "iam+invalid" "!!http://invalid.example.com/contact.html!" . 2795.example.com. 86400 IN NAPTR 1 1 "U" "sip+invalid" "!!http://invalid.example.com/contact.html!" . 2795.example.com. 86400 IN NAPTR 1 2 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" . 2795.example.com. 86400 IN NAPTR 2 1 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" . 2795.example.com. 86400 IN NAPTR 1 1 "U" "no-solicit" "!!http://infinite.example.com/keywordinfo.html!" .

;; ANSWERセクション：2795.example.com。 NAPTR 1 1 "U" "無効+ IAM" IN 86400 "!!のhttp：！//invalid.example.com/contact.html" 。 2795.example.com。 NAPTR 1 1 "U" "SIP +無効" IN 86400 "!!のhttp：！//invalid.example.com/contact.html" 。 2795.example.com。無送信請求 "" 2 "U" NAPTR IN 1 86400 "!!のhttp：！//infinite.example.com/keywordinfo.html" 。 2795.example.com。無送信請求 "" 1 "U" NAPTR IN 2 86400 "!!のhttp：！//infinite.example.com/keywordinfo.html" 。 2795.example.com。無送信請求 "" 1 "U" NAPTR IN 1 86400 "!!のhttp：！//infinite.example.com/keywordinfo.html" 。

A simple utility written in PERL accepts a lookup key and returns a URI using the specifications in this document. This example is non-normative:

Perlで書かれたシンプルなユーティリティは、検索キーを受け取り、この文書の仕様を使用してURIを返します。この例では、非規範的です：

#!/usr/bin/perl

＃！/ usr / bin / perlの部分

# THIS SAMPLE CODE IS NOT NORMATIVE

＃このサンプルコードは規範的ではありません

# This program accepts a solicitation class keyword and # returns a URI on success. It dies quietly on failure. use strict;

＃このプログラムは、勧誘クラスのキーワードを受け入れ、＃成功した場合にURIを返します。それは失敗に静かに死にます。厳密に使用します。

# http://www.net-dns.org/ use Net::DNS;

＃http://www.net-dns.org/ネット:: DNSを使用します。

   # reverse the label to create a domain name
   $ARGV[0] =~ tr/:/./ ;
   my $target = join( ".", reverse( split( /\./, $ARGV[0] ) ) );

# create a resolver my $res = Net::DNS::Resolver->new;

＃リゾルバを作成する私の$ RES =ネット:: DNS :: Resolver->新しいです。

# find all naptr records my $query = $res->query( "$target", "NAPTR" ) || exit ;

＃すべてのNAPTRが私の$クエリ= $ RES->クエリ（ "$ターゲット"、 "NAPTRを"）を記録見つける||出口 ;

# Do your DNSSEC checks here, throw away all invalid RRs

＃ここにあなたDNSSECのチェックを行い、離れてすべて無効RRを投げます

# get the answers, strip out non-matching services, # sort by order, preference my @rr = sort { # sort records numerically by order, preference $a->order <=> $b->order || $a->preference <=> $b->preference } grep { $_->service =~ /no-solicit/ } $query->answer;

＃は、答えを得る、非マッチングサービスを取り除く、＃のソート順によって、好みの私@rr =ソート{＃ソートレコードの数値順序によって、好み$ A->オーダー<=> $ B->オーダー|| $ A->好み<=> $ B->好み}のgrep {$ _->サービス=〜/無勧誘/} $ query->答え。

   # print the first qualifying record, strip out the
   # regexp markers
   my $op = substr( my $answer = $rr[0]->regexp , 0, 1 )
      || exit ;
   print split ( $op, $answer ) ; exit ;

Running the sample code gives the following results:

サンプルコードを実行すると、以下の結果が得られます。

[carl@example.com]% lynx -source `./discover.pl com.example.2795` <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>About Our Solicitation Class Keyword</title> </head> <body> <center> <a href="monkey.mp3"> <img alt="bouncy monkey logo" src="images/monkey_fpo.gif" border="0" /> </a> About com.example.2795: It has been determined that the content of this mail message conforms to the spirit of RFC 2795. Congratulations? </center> </body> </html>

[carl@example.com] ./discover.pl com.example.2795` `-source％のオオヤマネコ<DOCTYPE HTML PUBLIC！ " - // W3C // DTD HTML 4.01移行// EN"> <HTML> <HEAD>私たちの勧誘クラスのキーワードについての<title> </ TITLE> </ HEAD> <BODY> <センター> <a href="monkey.mp3"> <IMG ALT = "弾む猿のロゴ" SRC = "画像/ monkey_fpo.gif"国境=「0」/> /> のcom.example.2795について： このメールメッセージ の内容は、の精神に準拠していることを決定されていますRFC 2795.おめでとうございますか！ </センター> </ body> </ html>この

4. DDDS Application Specification

4. DDDSアプリケーション仕様書

The following definitions apply to this application:

以下の定義は、このアプリケーションに適用されます。

o Application Unique String: The application unique string is a Solicitation Class Keyword as defined in [RFC3865]. o First Well Known Rule: The character "." is substituted for the character ":" and then the Solicitation Class Keyword is reversed in order to produce a valid domain name. For example, "com.example:adv" would become "adv.example.com". o Valid Databases: The DNS _is_ the database. o Expected Output: A URI. o The "SERVICE" field MUST contain the string "no-solicit", the "FLAGS" field MUST contain the string "U", the "REPLACEMENT" field MUST be empty, and the "REGEXP" field MUST be formatted as specified in Section 2.

Oアプリケーション固有文字列：アプリケーション固有の文字列は、[RFC3865]で定義されているよう勧誘クラスのキーワードです。まずよく知られているルールO：「」の文字「：」の文字に置換され、その後、勧誘クラスのキーワードは有効なドメイン名を生成するために逆転されます。たとえば、 "com.example：ADV" "adv.example.com" になるだろう。 O有効なデータベース：DNSデータベースを_is_。 O予想される出力：URI。「SERVICE」フィールドは、文字列「非要請」を含まなければならないO、「フラグ」フィールドは、文字列「U」、「交換」フィールドは空である必要があり含まなければなりません、とで指定されるように「REGEXP」フィールドは、フォーマットする必要があります第2節。

Wildcards are appropriate for this application, allowing multiple solicitation class keywords that share a common prefix to all point to the same URI. Note that the NAPTR Resource Record is known as a "subtyping" RR, which means that additional selectors are available within the RR to "winnow down" the choices. This means more records are returned than are actually needed, resulting in more traffic.

ワイルドカードは、同じURIへのすべてのポイントに共通の接頭辞を共有する複数の勧誘クラスのキーワードをできるように、このアプリケーションに適しています。 NAPTRリソースレコードを追加セレクタは選択肢を「ダウン選り出す」ためにRR内で利用可能であることを意味し、「サブタイプ」RR、として知られていることに留意されたいです。これは、より多くのレコードがより多くのトラフィックが生じ、実際に必要とされるよりも、返されることを意味します。

But, this also means that wildcards may have unintended effects of multiple types of NAPTR resource records are used. Implementors and zone administrators should exercise care in the use of such wildcards in this application.

しかし、これはまた、ワイルドカードは、NAPTRリソースレコードの複数の種類の意図しない影響が使用されていてもよいことを意味します。実装者およびゾーン管理者は、このアプリケーションでは、このようなワイルドカードの使用には注意を払う必要があります。

5. Acknowledgements

5.謝辞

The author would like to thank the following for their helpful suggestions and reviews of this document: Leslie Daigle, Spencer Dawkins, Arnt Gulbrandsen, Ted Hardie, Scott Hollenbeck, Russ Housley, David Kessens, Peter Koch, Michael Mealling, Pekka Savola, Mark Townsley, and Margaret Wasserman.

著者は彼らの有益な提案や、このドキュメントのレビューのために次のことを感謝したいと思います：レスリーDaigle氏、スペンサードーキンスARNT Gulbrandsenの、テッドハーディー、スコットホレンベック、ラスHousley、デビッドKessens、ピーター・コッホ、マイケル・メオーリング、ペッカSavola、マークTownsley 、およびマーガレットワッサーマン。

6. Security Considerations

6.セキュリティの考慮事項

This document specifies an application which depends on the Domain Name System to associate a solicitation class keyword with a URI. Four security considerations are raised by this application:

この文書は、URIと勧誘クラスのキーワードを関連付けるためにドメイン・ネーム・システムに依存するアプリケーションを指定します。 4つのセキュリティ上の考慮事項は、このアプリケーションによって提起されています。

1. If the domain name lookup has been compromised, the application may return a URI with incorrect guidance on the use of a particular solicitation class keyword. In particular, if the application returns a URI with the "https:" scheme, and the DNS Security Extensions as defined in [RFC4033] and related documents are not used, the user would have an unwarranted illusion of authenticity making the possibility of active attacks a serious concern. Even if both DNS Security Extensions and the "https:" scheme are used, the client will need to take additional steps to ensure that the two different digital signature validation contexts are being administered by the same domain owner.

1.ドメイン名検索が侵害された場合、アプリケーションは特定の勧誘クラス・キーワードの使用上の間違った指導をURIを返すことがあります。アプリケーションは、「HTTPS：」でURIを返す場合、特に、スキーム、およびDNSセキュリティ拡張[RFC4033]で定義されており、関連文書が使用されていないとして、ユーザーが能動的な攻撃の可能性を作る本物の不当な錯覚を持っているでしょう深刻な懸念。 DNSセキュリティ拡張機能と「HTTPS：」両方の場合であっても方式が使用され、クライアントは、二つの異なるデジタル署名の検証コンテキストが同じドメインの所有者によって管理されていることを確認するために、追加の手順を実行する必要があります。

2. RFC 3865 bases solicitation class keywords on domain names. However, it does not define whom a user should trust. A sender or an intermediate MTA could insert a solicitation class keyword in a message and then use the application defined in this document to mislead the message recipient. For example, a malicious direct marketer might insert a keyword such as "org.example.certified.message" and use a URI to somehow indicate that the message (wrongly) has some official status. As with any URI, users must take further steps that are outside the scope of this specification to determine what and whom to believe.

ドメイン名2. RFC 3865の塩基勧誘クラスのキーワード。しかし、それはユーザーが信頼すべき人は定義されていません。送信者または中間MTAは、メッセージに要請クラスキーワードを挿入し、メッセージの受信者を欺くために、この文書で定義されたアプリケーションを使用することができます。たとえば、悪質なダイレクトマーケティング担当者は、このような「org.example.certified.message」としてキーワードを挿入して、URIを使用する可能性がありますに何らかの形でメッセージが（誤って）いくつかの公式の地位を持っていることを示しています。任意のURIと同じように、ユーザーが信じることを何と誰かを決定するために、この仕様の範囲外であるさらなるステップを取る必要があります。

3. Domain names are not persistent identifiers. As with any application that uses domain names, including the World Wide Web, if a domain name or a URI is embedded in an electronic mail message, there is a possibility that in the future the domain name will be controlled by a different zone administrator and that use of the application described in this document will yield different and possibly inconsistent results over time.

3.ドメイン名は永続的な識別子ではありません。ドメイン名またはURIを電子メールメッセージに埋め込まれている場合、ワールド・ワイド・ウェブを含むドメイン名を、使用するすべてのアプリケーションと同じように、将来的にドメイン名が異なるゾーン管理者によって制御される可能性があるとこの文書に記載されたアプリケーションの使用は、時間の経過とともに異なる、おそらく一貫性のない結果をもたらします。

4. A malicious sender could insert a large number of solicitation class keywords or improperly formatted solicitation keywords, thus performing a Denial of Service attack on the recipient's resources through the use of an excessive number of DNS lookups. If such a message is sent to many recipients, this can result in a Denial of Service attack on the provider at a particular URI (e.g., a large number of requests attempting to access a URI such as "http://example.net/index.html"). Improperly formatted solicitation class keywords, particularly those with a non-existent top level or second level domain, could result in a Denial of Service attack on DNS registry providers or the DNS root servers.

4.悪意のある送信者は、このようにDNSルックアップの過剰な数を使用して、受信者のリソース上のサービス拒否攻撃を実行する、勧誘クラスのキーワードや不適切な形式勧誘多数のキーワードを挿入することができます。このようなメッセージが多くの受信者に送信された場合、これはhttp://example.net/」として、特定のURI（例えば、URIにアクセスしようとする多数の要求で、プロバイダのサービス拒否攻撃につながることができますindex.htmlを "）。不適切な形式勧誘クラスのキーワード、存在しないトップレベルまたはセカンドレベルドメインと特には、DNSのレジストリプロバイダまたはDNSルートサーバーへのDoS攻撃につながる可能性があります。

7. IANA Considerations

7. IANAの考慮事項

There is no central registry maintained by the IANA of values that might appear in the "SERVICE" field of a NAPTR resource record. Thus, no direct IANA actions are required.

NAPTRリソースレコードの「SERVICE」フィールドに表示されることがあります値のIANAによって維持一切中央レジストリはありません。このように、何も直接IANAのアクションは必要ありません。

However, the IANA does maintain an Application Service Tag Registry, which is used to support the S-NAPTR DDDS application defined in [RFC3958]. The IANA is advised that the "no-solicit" value for the SERVICE field is in use per this document and thus should not be used in the Application Service Tag Registry for other applications.

しかし、IANAは[RFC3958]で定義されたS-NAPTR DDDSアプリケーションをサポートするために使用されるアプリケーションサービスタグレジストリを維持し。 IANAは、サービスフィールドの「ノー要請」値は、この文書ごとに使用中であるため、他のアプリケーションのアプリケーションサービスタグレジストリに使用すべきではないことをお勧めします。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[HTML-4.01] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C REC REC-html401-19991224, December 1999.

[HTML-4.01] Raggett、D.、オードブル、A.、およびI.ジェイコブス、 "HTML 4.01仕様書"、W3C REC REC-html401-19991224、1999年12月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.

[RFC2660]レスコラ、E.およびA.シフマン、 "セキュアハイパーテキスト転送プロトコル"、RFC 2660、1999年8月。

[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.

[RFC3402] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム"、RFC 3402、2002年10月。

[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.

[RFC3403] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。

[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.

[RFC3865]マラマッド、C.、 "いいえ募集簡易メール転送プロトコル（SMTP）サービスの拡張"、RFC 3865、2004年9月。

[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.

[RFC3958] Daigle氏、L.とA.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。

8.2. Informative References

8.2. 参考文献

[RFC2795] Christey, S., "The Infinite Monkey Protocol Suite (IMPS)", RFC 2795, 1 April 2000.

[RFC2795] Christey、S.、 "無限猿プロトコルスイート（IMPS）"、RFC 2795、2000年4月1日。

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。

[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.

[RFC3401] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.

[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。

[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.

[RFC3761] Faltstrom、P.とM. Mealling、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。

Author's Address

著者のアドレス

Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US

カール・マラマッドメモリ宮殿を押し私書箱300シックス、OR 97476米国

EMail: carl@media.org

メールアドレス：carl@media.org

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2005）。

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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。