RFC4848 日本語訳
4848 Domain-Based Application Service Location Using URIs and theDynamic Delegation Discovery Service (DDDS). L. Daigle. April 2007. (Format: TXT=19341 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Daigle Request for Comments: 4848 Cisco Systems Category: Standards Track April 2007
Daigleがコメントのために要求するワーキンググループL.をネットワークでつないでください: 4848年のシスコシステムズカテゴリ: 標準化過程2007年4月
Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
URIを使用するドメインベースのアプリケーション・サービス位置とダイナミックな代表団発見サービス(DDDS)
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application.
このドキュメントの目的は写像するのを特定用途サービスとプロトコルのためのURIにドメイン名を許容するために新しくて、簡単なDynamic DelegationディスカバリーService(DDDS)アプリケーションを定義することです。 U-NAPTRは、新しいDDDSアプリケーションと定義されますが、事実上、これがStraightforward NAPTR(S-NAPTR)DDDS Applicationの拡大であることを吹き替えしました。
Daigle Standards Track [Page 1] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . 3 2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Permitted Regular Expressions . . . . . . . . . . . . . . . 4 3. Sample U-NAPTR DNS Records . . . . . . . . . . . . . . . . . . 4 4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5 4.1. Application Unique String . . . . . . . . . . . . . . . . . 5 4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . . 5 4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5 4.5.1. Application Services . . . . . . . . . . . . . . . . . 6 4.5.2. Application Protocols . . . . . . . . . . . . . . . . . 6 4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 簡単なURIで可能にされたNAPTR(U-NAPTR。). . . . . . . . . . 3 2.1 旗. . . . . . . . . . . . . . . . . . . . . . 3 2.2を可能にしました。 正規表現. . . . . . . . . . . . . . . 4 3を可能にしました。 U-NAPTR DNS記録. . . . . . . . . . . . . . . . . . 4 4を抽出してください。 DDDS. . . . . . . 5 4.1のU-NAPTRアプリケーションの公式の定義。 アプリケーションのユニークなストリング. . . . . . . . . . . . . . . . . 5 4.2。 最初に、よく知られている規則. . . . . . . . . . . . . . . . . . . 5 4.3。 出力. . . . . . . . . . . . . . . . . . . . . . 5 4.4を予想しました。 旗. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.5。 パラメタ. . . . . . . . . . . . . . . . . . . . 5 4.5.1を修理してください。 アプリケーション・サービス. . . . . . . . . . . . . . . . . 6 4.5.2。 アプリケーション・プロトコル. . . . . . . . . . . . . . . . . 6 4.6。 有効な規則. . . . . . . . . . . . . . . . . . . . . . . . 6 4.7。 有効なデータベース. . . . . . . . . . . . . . . . . . . . . . 7 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 7 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 8 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 8 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 8 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 9
Daigle Standards Track [Page 2] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[2ページ]。
1. Introduction
1. 序論
The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) [7] application to allow mapping of domain names to URIs for particular application services and protocols. This allows the "lookup" of particular services available for given domains, for example.
このドキュメントの目的は写像するのを特定用途サービスとプロトコルのためのURIにドメイン名を許容するために新しくて、簡単なDynamic DelegationディスカバリーService(DDDS)[7]アプリケーションを定義することです。 これは例えば、与えられたドメインに利用可能な特定のサービスの「ルックアップ」を許容します。
Although this is defining a new and separate DDDS Application, dubbed U-NAPTR, it is built from the same principles as the Straightforward NAPTR (S-NAPTR) application, specified in [2]. This specification is not an update of S-NAPTR, but the reader is encouraged to review that document for extensive coverage of motivation and implementation considerations.
U-NAPTRは、これが新しくて別々のDDDS Applicationを定義していますが、それが[2]で指定されたStraightforward NAPTR(S-NAPTR)アプリケーションと同じ原則から建てられるのを吹き替えしました。 この仕様はS-NAPTRの最新版ではありませんが、読者が動機と実現問題の大規模な適用範囲のためのそのドキュメントを再検討するよう奨励されます。
S-NAPTR provides for application service location that does not rely on rigid domain naming conventions. It is deemed "straightforward" in part because it rules out the use of regular expressions in NAPTR records (for the S-NAPTR DDDS Application). However, that also rules out the possibility of providing a URI as the target of DDDS resolution. A number of applications, specified (e.g., [9]) and proposed, find the restriction too limiting, making S-NAPTR a near miss to suit their needs.
S-NAPTRは堅いドメイン命名規則を当てにしないアプリケーション・サービス位置に備えます。 それは、一部NAPTR記録(S-NAPTR DDDS Applicationのための)における正規表現の使用を除外するので、「簡単である」と考えられます。 しかしながら、また、それはDDDS解決の目標としてURIを提供する可能性を除外します。 応募件数であって、指定される、(例えば、[9])で提案されていて、制限があまり制限していると確かめてください、彼らの必要性に合うようにS-NAPTRをニアミスにして。
This U-NAPTR is effectively a modest extension to S-NAPTR, to accommodate the use of URIs as targets, without allowing the full range of possible regular expressions in NAPTR records.
事実上、このU-NAPTRはS-NAPTRへの目標としてURIの使用を収容するためには穏やかな拡大です、NAPTR記録における、最大限の範囲の可能な正規表現を許容しないで。
2. Straightforward URI-Enabled NAPTR (U-NAPTR)
2. 簡単なURIで可能にされたNAPTR(U-NAPTR)
This document assumes the reader is familiar with the S-NAPTR specification [2]. The intention of U-NAPTR is to provide everything that S-NAPTR does, except that it allows the use of the "U" flag in the NAPTR record, and a specific form of REGEXP.
このドキュメントは、読者がS-NAPTR仕様[2]に詳しいと仮定します。 U-NAPTRの意志はS-NAPTRがするすべてを提供することです、NAPTR記録における「U」旗の使用、およびREGEXPの特定のフォームを許容するのを除いて。
2.1. Permitted Flags
2.1. 受入れられた旗
U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus the "U" Flag. For the U-NAPTR DDDS Application, the presence of the "U" Flag in the NAPTR record indicates the REGEXP field must be populated (and, consequently, the REPLACEMENT field is empty). The regular expression in the REGEXP field must be of the limited form described below, and the result of the regular expression evaluation will be a URI that is the result of the DDDS resolution.
U-NAPTRはS-NAPTR(「A」の、または、空の「S」)と同じ旗、および「U」旗を可能にします。 U-NAPTR DDDS Applicationに関しては、NAPTR記録での「U」旗の存在は、REGEXP分野に居住しなければならないのを(その結果、交換分野は人影がありません)示します。 REGEXP分野での正規表現は以下で説明された限局型のものであるに違いありません、そして、正規表現評価の結果はDDDS解決の結果であるURIになるでしょう。
Daigle Standards Track [Page 3] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[3ページ]。
2.2. Permitted Regular Expressions
2.2. 受入れられた正規表現
U-NAPTR permits regular expressions of a form that does a complete replacement of the matched string with a URI, expressed as a constant string. This is essentially a dodge around the fact that the REPLACEMENT field in NAPTR is required to produce only a fully qualified domain name (and, therefore, cannot be used for a URI).
U-NAPTRは一定のストリングとして言い表されたURIとの取り組んでいるストリングの完全な交換をする形式の正規表現を可能にします。 これは本質的にはNAPTRのREPLACEMENT分野が完全修飾ドメイン名(そして、したがって、URIに使用できない)だけを作り出すのに必要であるという事実の周りの言い抜けです。
The specific allowed syntax for U-NAPTR regular expressions is:
U-NAPTR正規表現のための特定の許容構文は以下の通りです。
u-naptr-regexp = "!.*!"<URI>"!"
「u-naptr-regexp=!」 *!「<ユリ>"!"」
where <URI> is as defined in STD 66 [8], the URI syntax specification.
<URI>がSTD66[8]で定義されるようにあるところでは、URI構文仕様です。
With this limited form of regular expression, applications using U-NAPTR need not implement full regular expression parsers.
この限局型の正規表現で、U-NAPTRを使用するアプリケーションは完全な正規表現パーサを実行する必要はありません。
3. Sample U-NAPTR DNS Records
3. サンプルU-NAPTR DNS記録
In the sample NAPTR RRs for example.com shown below, "WP" is the imagined application service tag for "white pages", and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
サンプルでは、"WP"が「ホワイトページ」のための以下では、想像されるアプリケーション・サービスタグであり、「イエム」がアプリケーションであることが示されたNAPTR RRs for example.comが想像される「広げることができるメッセージング」アプリケーション・サービスのためにタグを調整します。
example.com. ;; order pref flags IN NAPTR 100 10 "" "WP:whois++" ( ; service "" ; regexp bunyip.example.com. ; replacement ) IN NAPTR 100 20 "s" "WP:ldap" ( ; service "" ; regexp _ldap._tcp.myldap.example.com. ; replacement ) IN NAPTR 200 10 "u" "EM:protA" ( ; service "!.*!prota://someisp.example.com!" ; regexp "" ; replacement ) IN NAPTR 200 30 "a" "EM:protB" ; service "" ; regexp myprotB.example.com.; replacement )
example.com。 ;; オーダーprefがIN NAPTR100 10に旗を揚げさせる、「「「WP: whois++」」( ; サービス、「「;」 regexp bunyip.example.com。 ; 交換) NAPTR100 20、「s」「WP: ldap」( ; サービス、「「;」 regexp_ldap_tcp.myldap.example.com。 ; 交換) 「IN NAPTR200 10「u」「EM: protA」、(;、」 *!. prota://someisp.example.com!を調整してください 」、regexp、「「; 交換) IN NAPTR200 30“a"、「イエム: protB」、」、。 サービス、「「;」 regexp myprotB.example.com。 交換)
Daigle Standards Track [Page 4] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[4ページ]。
4. Formal Definition of U-NAPTR Application of DDDS
4. DDDSのU-NAPTRアプリケーションの公式の定義
This section formally defines the DDDS Application, as described in [7].
このセクションは[7]で説明されるように正式にDDDS Applicationを定義します。
4.1. Application Unique String
4.1. アプリケーションのユニークなストリング
The Application Unique String is a fully qualified domain name (FQDN) for which an authoritative server for a particular service is sought.
Application Unique Stringは特定のサービスのための正式のサーバが求められる完全修飾ドメイン名(FQDN)です。
4.2. First Well Known Rule
4.2. 最初のよく知られている規則
The "First Well Known Rule" is identity -- that is, the output of the rule is the Application Unique String, the FQDN for which the authoritative server for a particular service is sought.
「最初のよく知られている規則」はアイデンティティです--すなわち、規則の出力はApplication Unique String(特定のサービスのための正式のサーバが求められるFQDN)です。
4.3. Expected Output
4.3. 予想された出力
The expected output of this Application is the information necessary to connect to authoritative server(s) (host, port, protocol, or URI) for an application service within a given domain.
このApplicationの予想された出力は与えられたドメインの中のアプリケーション・サービスのための正式のサーバ(ホスト、ポート、プロトコル、またはURI)に接続する必要情報です。
4.4. Flags
4.4. 旗
This DDDS Application uses only 3 of the Flags defined for the URI/ URN Resolution Application [5]: "S", "A", and "U". No other Flags are valid. If a client obtains a NAPTR RR for a U-NAPTR-using application that contains any other flag, that NAPTR RR should be ignored and processing continues with the next record (if any).
このDDDS ApplicationはURI/URN Resolution Application[5]のために定義された3Flagsだけを使用します: 「S」、「A」、および「U。」 他のどんなFlagsも有効ではありません。 クライアントがいかなる他の旗も含むU-NAPTRを使用しているアプリケーションにNAPTR RRを入手するなら、そのNAPTR RRは無視されるべきです、そして、処理は次の記録(もしあれば)を続行します。
These flags are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a FQDN for which one or more SRV [3] records exist. "A" means that the output of the Rule is a domain name and should be used to lookup address records for that domain. "U" means that the output of the Rule is a URI that should be resolved in order to obtain access to the described service.
これらの旗は端末のルックアップのためのものです。 これは、Ruleが最後のものであり、旗が、次のステージが何であるべきであるかを決定することを意味します。 「S」旗は、この規則の出力が1つ以上のSRV[3]記録が存在するFQDNであることを意味します。 「A」は、Ruleの出力がドメイン名であることを意味して、そのドメインにルックアップアドレス記録に使用されるべきです。 「U」は、Ruleの出力が説明されたサービスへのアクセスを得るために決議されるべきであるURIであることを意味します。
Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target).
DDDSアルゴリズムと一致しています、Flagストリングが空であるなら、次のルックアップは別のNAPTR記録(交換目標のための)のためのものです。
4.5. Service Parameters
4.5. サービスパラメタ
Service Parameters for this Application take the form of a string of characters that follow this ABNF [1]:
このApplicationのためのサービスParametersはこのABNF[1]の後をつける一連のキャラクタの形を取ります:
Daigle Standards Track [Page 5] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[5ページ]。
service-parms = [ [app-service] *(":" app-protocol)] app-service = experimental-service / iana-registered-service app-protocol = experimental-protocol / iana-registered-protocol experimental-service = "x-" 1*30ALPHANUMSYM experimental-protocol = "x-" 1*30ALPHANUMSYM iana-registered-service = ALPHA *31ALPHANUMSYM iana-registered-protocol = ALPHA *31ALPHANUMSYM ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." ALPHANUMSYM = ALPHA / DIGIT / SYM ; The app-service and app-protocol tags are limited to 32 ; characters and must start with an alphabetic character. ; The service-parms are considered case-insensitive.
ianaがサービスを登録している装置実験的なサービス/プロトコルサービス-parms=[装置サービス]*(「:」 装置プロトコル]装置サービス==「x」1*30ALPHANUMSYM実験プロトコルianaがプロトコルを登録している実験的な実験プロトコル/サービス==「x」アルファ*31ALPHANUMSYM ianaによって登録された1*30ALPHANUMSYM ianaによって登録されたサービス=プロトコル=アルファ*31ALPHANUMSYMアルファー=%x41-5A/%x61-7A。 1Zの/1zのDIGIT=%x30-39。 0-9 SYM=%x2B/%x2D/%x2E。 "+" / "-" / "." ALPHANUMSYMはアルファ/ケタ/SYMと等しいです。 装置サービスと装置プロトコルタグは32に制限されます。 キャラクタと必須は英字から始まります。 ; サービス-parmsは大文字と小文字を区別しないと考えられます。
Thus, the Service Parameters may consist of an empty string, just an app-service, or an app-service with one or more app-protocol specifications separated by the ":" symbol.
「したがって、Service Parametersがまさしく1以上がある装置プロトコル仕様が分離した空のストリング、装置サービス、または装置サービスから成るかもしれない、」、:、」 シンボル。
Note that this is similar to, but not the same as the syntax used in the URI DDDS application [5]. The DDDS DNS database requires each DDDS application to define the syntax of allowable service strings. The syntax here is expanded to allow the characters that are valid in any URI scheme name (see [8]). Since "+" (the separator used in the RFC3404 service parameter string) is an allowed character for URI scheme names, ":" is chosen as the separator here.
URI DDDSアプリケーション[5]で使用される構文と同様ですが、これが同じでないことに注意してください。 DDDS DNSデータベースは、許容できるサービスストリングの構文を定義するためにそれぞれのDDDSアプリケーションを必要とします。 ここの構文は、どんなURI計画名でも有効な状態でそうするキャラクタを許容するために広げられます。([8])を見てください。 「以来、「+」 (RFC3404サービスパラメタストリングで使用される分離符)はURI計画名のための許容キャラクタです」、:、」 分離符として、ここで、選ばれています。
4.5.1. Application Services
4.5.1. アプリケーション・サービス
The "app-service" must be an IANA-registered service; see Section 5 for instructions on registering new application service tags.
「装置サービス」はIANAによって登録されたサービスであるに違いありません。 新しいアプリケーション・サービスタグを登録する指示に関してセクション5を見てください。
4.5.2. Application Protocols
4.5.2. アプリケーション・プロトコル
The protocol identifiers that are valid for the "app-protocol" production are standard, registered protocols; see Section 5 for instructions on registering new application protocol tags.
「装置プロトコル」生産に、有効なプロトコル識別子は標準の、そして、登録されたプロトコルです。 新しいアプリケーション・プロトコルタグを登録する指示に関してセクション5を見てください。
4.6. Valid Rules
4.6. 有効な規則
Permitted rules are substitution rules and regular expressions of the following syntax (i.e., a regular expression to replace the domain name with a URI):
規則が受入れられているのは、以下の構文(すなわち、ドメイン名をURIに取り替える正規表現)の代替規則と正規表現です:
u-naptr-regexp = "!.*!"<URI>"!"
「u-naptr-regexp=!」 *!「<ユリ>"!"」
where <URI> is as defined in STD 66 [8], the URI syntax specification.
<URI>がSTD66[8]で定義されるようにあるところでは、URI構文仕様です。
Daigle Standards Track [Page 6] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[6ページ]。
4.7. Valid Databases
4.7. 有効なデータベース
At present, only one DDDS Database is specified for this Application. [4] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain names.
現在のところ、1DDDS DatabaseだけがこのApplicationに指定されます。 [4]は書換規則を含むのにNAPTR DNSリソース記録を使用するDDDS Databaseを指定します。 このデータベースのためのキーズはドメイン名としてコード化されます。
The First Well Known Rule produces a domain name, and this is the Key that is used for the first lookup -- the NAPTR records for that domain are requested.
これは最初のルックアップに使用されるKeyです--First Well Known Ruleはドメイン名を生産します、そして、そのドメインのためのNAPTR記録は要求されています。
DNS servers MAY interpret Flag values and use that information to include appropriate NAPTR, SRV, or A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of [4] for more information on NAPTR records and the Additional Information section of a DNS response packet.
DNSサーバは、DNSパケットのAdditional情報部分に適切なNAPTR、SRV、またはA記録を含むのにFlag値を解釈して、その情報を使用するかもしれません。 クライアントは、追加情報がないかどうかチェックするよう奨励されますが、そうする必要はありません。 NAPTR記録に関する詳しい情報のための[4]のAdditional情報Processing部とDNS応答パケットのAdditional情報部を見てください。
5. IANA Considerations
5. IANA問題
This document does not itself place any requirements on IANA, but provides the basis upon which U-NAPTR-using services can make use of the existing IANA registries for application service tags and application protocol tags (defined in RFC 3958 [2]).
このドキュメントは、IANAに関するどんな要件もどんな場所自体にもしませんが、アプリケーション・サービスタグとアプリケーション・プロトコルタグのためにU-NAPTRを使用しているサービスが存在を利用できる基礎にIANA登録を提供します。(RFC3958[2])では、定義されます。
As is the case for S-NAPTR, all application service and protocol tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Use them at your own risk.
S-NAPTRのためのケースのように、実験的であると「x」から始まるすべてのアプリケーション・サービスとプロトコルタグを考えます、そして、同じストリングの写し使用を防ぐのを設備を全くしません。 自分の責任でそれらを使用してください。
All other application service and protocol tags are registered based on the "specification required" option defined in [6], with the further stipulation that the "specification" is an RFC (of any category).
他のすべてのアプリケーション・サービスとプロトコルタグは「仕様が必要である」という[6]で定義されたオプションに基づいて登録されます、「仕様」がRFC(どんなカテゴリのも)であるというさらなる約款で。
There are no further restrictions placed on the tags other than that they must conform with the syntax defined above (Section 4.5).
これ以上、それらが(セクション4.5)の上で定義された構文に従わなければならない以外に、タグに関して課される制限がありません。
The defining RFC must clearly identify and describe, for each tag being registered:
RFCが登録される各タグのために明確に特定して、説明しなければならない定義:
o Application protocol or service tag
o アプリケーション・プロトコルかサービスタグ
o Intended usage
o 意図している用法
o Interoperability considerations
o 相互運用性問題
Daigle Standards Track [Page 7] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[7ページ]。
o Security considerations (see Section 6 of this document for further discussion of the types of considerations that are applicable)
o セキュリティ問題(適切な問題のタイプのさらなる議論のためのこのドキュメントのセクション6を見ます)
o Any relevant related publications
o どんな関連関連する刊行物
The defining RFC may also include further application-specific restrictions, such as limitations on the types of URIs that may be returned for the application service.
また、定義しているRFCはアプリケーションさらに特有の制限を含むかもしれません、アプリケーション・サービスのために返されるかもしれないURIのタイプにおける制限などのように。
6. Security Considerations
6. セキュリティ問題
U-NAPTR has the same considerations for security as S-NAPTR; see Section 8 of [2]. U-NAPTR has the additional consideration that resolving URIs (from the result of the DDDS resolution) has its own set of security implications, covered in the URI specification (in particular, Section 7 of [8]). In essence, using DNSSEC, client software can be confident that the URI obtained using U-NAPTR is indeed the one specified by the administrator of the domain from which it was retrieved; but the validity of the service reached by resolving that URI is a matter of URI resolution security practices.
U-NAPTRには、S-NAPTRとして同じ問題がセキュリティのためにあります。 [2]のセクション8を見てください。 U-NAPTRには、URI(DDDS解決の結果からの)を決議して、URI仕様でカバーされたそれ自身のセットのセキュリティ意味を持っている追加的約因があります。(特に[8])のセクション7。 本質では、DNSSECを使用して、クライアントソフトウェアは本当に、U-NAPTRを使用することで得られたURIがそれが検索されたドメインの管理者によって指定されたものであると確信している場合があります。 しかし、そのURIを決議することによって達したサービスの正当性はURI解決セキュリティ練習の問題です。
7. Acknowledgements
7. 承認
Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes, Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier versions and catching errors!
以前のバージョンを見直して、誤りを捕らえるためのマーチン・トムソンへの感謝、ジョンKlensin、バーナードAboba、アルフレッドHoenes、ダンRomascanu、Sureshクリシュナン、およびラース・エッゲルト!
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[1] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[2] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[2] Daigle、L.、およびA.ニュートン、「SRV RRsを使用するドメインベースのアプリケーション・サービス位置とダイナミックな代表団発見は(DDDS)を修理します」、RFC3958、2005年1月。
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[3]Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
Daigle Standards Track [Page 8] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[8ページ]。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[5] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)」、RFC3404、2002年10月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
8.2. Informative References
8.2. 有益な参照
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[7] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005.
[8]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC3986、STD66、2005年1月。
[9] Malamud, C., "Attaching Meaning to Solicitation Class Keywords", RFC 4095, May 2005.
[9] マラマッドC. (「懇願クラスキーワードを添付すること」でのRFC4095)は2005がそうするかもしれません。
Author's Address
作者のアドレス
Leslie L. Daigle Cisco Systems 13615 Dulles Technology Drive Herndon, VA 20171 US
レスリーL.Daigleシスコシステムズ13615ダレス技術Driveヴァージニア20171ハーンドン(米国)
EMail: ledaigle@cisco.com; leslie@thinkingcat.com
メール: ledaigle@cisco.com; leslie@thinkingcat.com
Daigle Standards Track [Page 9] RFC 4848 URI-Enabled NAPTR April 2007
Daigle規格はURIで可能にされたNAPTR2007年4月にRFC4848を追跡します[9ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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機能のための基金は現在、インターネット協会によって提供されます。
Daigle Standards Track [Page 10]
Daigle標準化過程[10ページ]
一覧
スポンサーリンク