RFC4095 日本語訳

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

コメントを求めるワーキンググループC.マラマッド要求をネットワークでつないでください: 4095年のメモリ宮殿プレスカテゴリ: 標準化過程2005年5月

            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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントは、懇願クラスキーワードに関連しているURIを見つけるためにメカニズムを提案します。(URIはRFC3865(ノーSoliciting SMTP Service Extension)で定義されます)。 懇願クラスキーワードは"org.example.adv"などのように逆にされたドメイン名から成る簡単なラベルです。 これらの懇願クラスキーワードは、選択されたヘッダーフィールドに挿入されるか、またはESMTPサービス拡張子に使用されます、新しい「請求しないでください」を含んでいて ヘッダー。(そのヘッダーは送付者によって挿入された1つ以上の懇願クラスキーワードを含むことができます)。

   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.

このドキュメントはRFC3401と関連するドキュメントで説明されたDynamic DelegationディスカバリーSystem(DDDS)に基づくアプリケーションを指定します。 アルゴリズムは、その懇願クラスキーワードの意味と用法に関する詳細を含むURIに懇願クラスキーワードを関連づけるために指定されます。 例えば、"example.org"ドメインの記入者は、"org.example.adv"懇願クラスキーワードの詳細な情報を含むURIを作成するのにこのメカニズムを使用できました。

Malamud                     Standards Track                     [Page 1]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[1ページ]RFC4095は発見2005年5月に請求しません。

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. 懇願クラスキーワード…2 1.1. 用語…3 2. 請求していないNAPTRアプリケーション…3 3. 例…5 4. DDDSアプリケーション仕様…7 5. 承認…8 6. セキュリティ問題…8 7. IANA問題…9 8. 参照…9 8.1. 標準の参照…9 8.2. 有益な参照…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サービス拡張子の範囲の外部として明らかに懇願クラスキーワードの意味の発見を置きます。 メッセージ転送の目的のために、これらの懇願クラスキーワードは不明瞭です。 しかしながら、RFC3865が広く使用されるようになるなら、メール・メッセージは多くの懇願クラスキーワードを含むかもしれません。 「請求しないでください」 ヘッダーはメッセージ送信者、および監督機関によって強制されたか、または自発的の企業団体によって推薦されたものにキーワードを挿入させます。(そのメッセージ送信者は、送付者の自己のキーワードを含むかもしれません)。 同様である、「受け取られている:、」 跡の分野はメッセージ転送エージェントによって作り出された多くのキーワードを含むかもしれません、ソフトウェアをフィルターにかけて、メッセージユーザエージェント(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,

使われたキーワードの数が成長するので、様々な懇願クラスキーワードの後ろで意味を発見するためのメソッドを見つけるのは重要でしょう。 このドキュメントはそのようなメカニズムを指定します、DNS NAPTR Resource Recordを使用することによって詳細を含むURIに懇願クラスキーワードを関連づけて

Malamud                     Standards Track                     [Page 2]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[2ページ]RFC4095は発見2005年5月に請求しません。

   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]では、定義されます。 明白なデザイン目標はできるだけ簡単にシステムを保つことです。 懇願クラスキーワードに関する特定のメタデータを含むXMLベースの構造か説明の書式を定義する他のアプローチを定義などなどのアプローチは除外されました。 代わりに、目標はURIがあるキーワードを単に副a懇願に分類することです。(順番に、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[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]の指定されるとしてのStraightforward-NAPTR(S-NAPTR)アプリケーションと呼ばれるDDDSフレームワークの簡素化があります。 残念ながら、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を使用します。 「キャラクタ」、」、キャラクタのどんなインスタンスにも1番目を代入する、」、:、」 「そして、キャラクタを使用して、懇願クラスキーワードは逆にされます」。. 」 デリミタとして。 これはドメイン名ルックアップキーになります。 例えば、「org.example: 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

さらに、結果として起こるストリングが他のDNSバリディティチェックを満たさなければならないのを覚えているのは重要です。 特に、ドメインラベルは長さが63のキャラクタに制限されます、そして、結果として起こるストリングの全長は253未満のキャラクタであるに違いありません。 どんな非ASCII

Malamud                     Standards Track                     [Page 3]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[3ページ]RFC4095は発見2005年5月に請求しません。

   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.

[RFC3490]と関連するドキュメントのInternationalized Domain Names(IDN)仕様を使用することでキャラクタをコード化しなければなりません。 「非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.

o 「オーダー」と「好み」分野は[RFC3403]で指定されるように処理されることです: 複数の記録を返すなら、合っている「サービス」分野を持っている最も低い「オーダー」値に従ったもの(s)を使用しなければなりません。 最も低いORDER値があるそれらでは、最も低い「好み」があるものは使用されるべきです。

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

o 「旗」分野はキャラクタ「U」を含まなければなりません。

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

o 「サービス」分野は「請求していなかった」状態でストリングだけを含まなければなりません。

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

o "REGEXP"分野はこのセクションのさらに指定されているとしての有効な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"分野は[RFC3402]で「delim-キャラクタ」から成ると定義されて、POSIXは正規表現、別の「delim-キャラクタ」、再取得価額、および最終的な「delim-キャラクタ」を広げました。 このアプリケーションのために、以下の規則は申し込まれます:

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

o 「delim-キャラクタ」は[RFC3402]のセクション3.2で定義されるようにどんな有効なキャラクタであるかもしれません。

   o  The extended regular expression MUST be empty.

o 拡張正規表現は空であるに違いありません。

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

o 再取得価額は[RFC3986]の指定されるとしての有効なURIを含まなければなりません。

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

o 再取得価額SHOULDは[RFC3986]と[RFC2660]の指定されるとしての"ftp"、"http"、および"https"体系に制限されたURIを含んでいます。

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

o URI SHOULDで検索されるドキュメントはそこに含まれたAccessibility Guidelinesを含む[HTML-4.01]に一致しています。

Malamud                     Standards Track                     [Page 4]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[4ページ]RFC4095は発見2005年5月に請求しません。

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:

この例では、1セットのNAPTR記録を"example.com"ゾーンに追加して、「皮肉」か他のDNSユーティリティを使用することで検索できます:

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

[ carl@example.com ]%は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

; <<>>DiG9.2.3<<>>2795.example.com naptr。 グローバルなオプション: printcmd。 答えを得ます: ;; ->>HEADER<<-opcode: QUERY、状態: NOERROR、イド: 43494 ;; 旗: qr aa、第ra。 以下について質問してください。 1 答え: 5、権威: 2 追加しています: 1

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

;; セクションに質問してください: ; 2795.example.com。 NAPTRで

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

;; セクションに答えてください: 2795. example.com。 「NAPTR1 1「U」「iam+病人」の86400!」" http://invalid.example.com/contact.html! " . 2795. example.com。 「NAPTR1 1「U」「一口+病人」の86400!」" http://invalid.example.com/contact.html! " . 2795. example.com。 「NAPTR1 2「U」の86400は「請求しません!」」" http://infinite.example.com/keywordinfo.html! " . 2795. example.com。 「NAPTR2 1「U」の86400は「請求しません!」」" http://infinite.example.com/keywordinfo.html! " . 2795. example.com。 「NAPTR1 1「U」の86400は「請求しません!」」" http://infinite.example.com/keywordinfo.html! " .

Malamud                     Standards Track                     [Page 5]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[5ページ]RFC4095は発見2005年5月に請求しません。

   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] ) ) );

# ラベルを逆にして、ドメイン名$ARGV[0]=~tr/を作成してください: // 私の$目標=が接合する、(「」、逆になってください、(分裂、(/、\/、$ARGV[0] ) ) )。

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

# レゾルバのために私の$resを作成してください。= 以下を網状にならせてください:DNS:、:レゾルバ->新しい、。

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

# 私の$質問が$res->と等しいというすべてのnaptr記録が(「$目標」、"NAPTR")について質問すると確かめてください。|| 出てください。

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

# ここでDNSSECチェックをしてください、そして、すべての無効のRRsを捨ててください。

   # 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;

# 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;

   # 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 ;

# 最初の資格を得る記録を印刷してください、そして、#regexpマーカーから私の$オプアート=substrを剥取ってください。(私の$が=$rr[0]->にregexp、0に答える、1)|| 出てください。 印刷は分かれました($オプアート、$に答えます)。 出てください。

Malamud                     Standards Track                     [Page 6]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[6ページ]RFC4095は発見2005年5月に請求しません。

   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" />
           <br />
          </a>
          <br />
          About com.example.2795:<br />
          It has been determined that the content of this
          mail message<br />
          conforms to the spirit of RFC 2795.
          Congratulations?
       </center>
     </body>
   </html>

' carl@example.com% オオヤマネコソース'/discover.pl com.example; '2795'<!DOCTYPE HTML PUBLIC、「過渡的な-//W3C//DTD HTML4.01のアン//「センター>の><href=「monkey.mp3"><img alt=」活発な猿<html><ヘッド><タイトル>About Our Solicitation Class Keyword</タイトル></ヘッド><ボディー><ロゴ」srcは「イメージ/猿_fpo.gif」境界=「0インチ/>の<Br/></a><Br/>About com」と等しいです; 例.2795: <Br/>Itはこのメール・メッセージ<Br/>の内容がRFC2795の精神に従うと決心しています。 おめでとうございます? </センター></ボディー></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 First Well Known Ruleで定義されるようにSolicitation Class Keywordです: 「キャラクタ」、」、キャラクタに代入する、」、:、」 そして、Solicitation Class Keywordは、有効なドメイン名を生産するために逆にされます。 例えば、「com.example: adv」は「副詞example.com」 o Valid Databasesになるでしょう: DNS、__データベースは. o Expected Outputです: A URI○ 「サービス」分野は「請求していなかった」状態でストリングを含まなければならなくて、「旗」分野はストリング「U」を含まなければならなくて、「交換」分野は人影がないに違いなく、指定されるとしてセクション2で"REGEXP"分野をフォーマットしなければなりません。

   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 Resource Recordが「副タイプ」RRとして知られていることに注意してください。(RRは、選択を「下に選び出す」ために追加セレクタがRRの中で利用可能であることを意味します)。 より多くのトラフィックをもたらして、これは、より多くの記録が実際に必要とされるより返されることを意味します。

Malamud                     Standards Track                     [Page 7]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[7ページ]RFC4095は発見2005年5月に請求しません。

   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、テッド・ハーディー、スコットHollenbeck、ラスHousley、デヴィッドKessens、ピーター・コッホ、マイケルMealling、ペッカ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を返すかもしれません。 アプリケーションが特にURIを返す、「https:」 [RFC4033]と関連するドキュメントで定義されるDNS Security Extensionsが使用されていない、計画してください。そうすれば、ユーザは活発な攻撃の可能性を真剣な関心にする信憑性の保証のない幻想を持っているでしょう。 そして、両方のDNS Security Extensions、「https:」 使用される体系、クライアントは2つの異なったデジタル署名合法化文脈が同じドメイン所有者によって管理されているのを保証するために追加方法を採る必要があるでしょう。

   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. RFC3865は懇願クラスキーワードをドメイン名に基礎づけます。 しかしながら、それは、ユーザがだれを信じるべきであるかを定義しません。 送付者か中間的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

3. ドメイン名は永続的な識別子ではありません。 ドメイン名かURIが電子メールメッセージに埋め込まれるならWWWを含むドメイン名を使用するどんなアプリケーションでも将来ドメイン名が異なったゾーンの管理者とそれによって制御される可能性があるとき

Malamud                     Standards Track                     [Page 8]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[8ページ]RFC4095は発見2005年5月に請求しません。

       use of the application described in this document will yield
       different and possibly inconsistent results over time.

本書では説明されたアプリケーションの使用は時間がたつにつれて、異なってことによると矛盾した結果をもたらすでしょう。

   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ルックアップの使用で受取人のリソースにサービス妨害攻撃を実行します。 そのようなメッセージを多くの受取人に送るなら、これはプロバイダーで特定のURI(" http://example.net/index.html "などのURIにアクセスするのを試みる例えば多くの要求)でサービス妨害攻撃をもたらすことができます。 不適切にフォーマットされた懇願クラスキーワード(特に非目下のトップレベルかセカンドレベルドメインがあるそれら)はDNS登録プロバイダーかDNSルートサーバーでサービス妨害攻撃をもたらすかもしれません。

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リソース記録の「サービス」分野に現れるかもしれない値の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はApplication Service Tag Registryを維持します。(Application Service Tag Registryは、S-NAPTR DDDSが[RFC3958]で定義されたアプリケーションであるとサポートするのに使用されます)。 IANAにSERVICE分野への「請求していない」値がこのドキュメント単位で使用中であると忠告して、その結果、他のアプリケーションにApplication Service Tag Registryで使用するべきではありません。

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.とHors、A.とI.ジェイコブズ、「HTML4.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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC2660] レスコラとE.とA.シフマン、「安全なハイパーテキスト転送プロトコル」、RFC2660、1999年8月。

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

[RFC3402]食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。

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

[RFC3403]食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。

Malamud                     Standards Track                     [Page 9]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[9ページ]RFC4095は発見2005年5月に請求しません。

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

[RFC3865]マラマッド、C.、「請求していないシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3865、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.ニュートン、「SRV RRsを使用するドメインベースのアプリケーション・サービス位置とダイナミックな委譲発見は(DDDS)を修理します」、RFC3958、2005年1月。

   [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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、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.、「無限の猿プロトコル群(悪童)」、RFC2795、2000年4月1日。

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

[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

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

[RFC3401]食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。

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

[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、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.食事、「Uniform Resource Identifier(URI)ダイナミックな委譲発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。

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

[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。

Author's Address

作者のアドレス

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

カールマラマッドメモリ宮殿プレスの私書箱300 6、または97476米国

   EMail: carl@media.org

メール: carl@media.org

Malamud                     Standards Track                    [Page 10]

RFC 4095                  No-Solicit Discovery                  May 2005

マラマッド標準化過程[10ページ]RFC4095は発見2005年5月に請求しません。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Malamud                     Standards Track                    [Page 11]

マラマッド標準化過程[11ページ]