RFC3401 日本語訳

3401 Dynamic Delegation Discovery System (DDDS) Part One: TheComprehensive DDDS. M. Mealling. October 2002. (Format: TXT=10172 bytes) (Obsoletes RFC2915, RFC2168) (Updates RFC2276) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        M. Mealling
Request for Comments: 3401                                      VeriSign
Updates: 2276                                               October 2002
Obsoletes: 2915, 2168
Category: Informational

コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 3401のベリサインアップデート: 2276 2002年10月は以下を時代遅れにします。 2915、2168カテゴリ: 情報

              Dynamic Delegation Discovery System (DDDS)
                    Part One: The Comprehensive DDDS

ダイナミックな委譲発見システム(DDDS)パート1: 包括的なDDDS

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document specifies the exact documents that make up the complete
   Dynamic Delegation Discovery System (DDDS).  DDDS is an abstract
   algorithm for applying dynamically retrieved string transformation
   rules to an application-unique string.

このドキュメントは完全なDynamic DelegationディスカバリーSystem(DDDS)を作る正確なドキュメントを指定します。 DDDSは、ダイナミックに検索されたストリング変換規則をアプリケーションユニークなストリングに適用するための抽象的なアルゴリズムです。

   This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC
   2168 and RFC 2915, as well as updates RFC 2276.

RFC3402に伴うこのドキュメント、RFC3403、およびRFC3404はRFC2168とRFC2915を時代遅れにします、アップデートRFC2276と同様に。

1. Intended Audience

1. 対象とする訪問者

   This document and the documents that it references are intended for
   anyone attempting to implement or understand the generic DDDS
   algorithm, URI Resolution, ENUM telephone number to URI resolution,
   and the NAPTR DNS resource record.  The reader is warned that reading
   one of the documents in this series without reading the others will
   probably lead to misunderstandings and interoperability problems.

それが参照をつけるこのドキュメントとドキュメントはジェネリックDDDSアルゴリズム、URI Resolution、URI解決へのENUM電話番号、およびNAPTR DNSリソース記録を実装するか、または理解しているのを試みるだれのためにも、意図します。 読者は他のものを読まないでこのシリーズでドキュメントの1つを読むのがたぶん誤解と相互運用性問題を引き起こすのに注意されます。

2. Introduction

2. 序論

   The Dynamic Delegation Discovery System is used to implement lazy
   binding of strings to data, in order to support dynamically
   configured delegation systems.  The DDDS functions by mapping some
   unique string to data stored within a DDDS Database by iteratively
   applying string transformation rules until a terminal condition is
   reached.  This document defines the entire DDDS by listing the
   documents that make up the complete specification at this time.

Dynamic DelegationディスカバリーSystemはストリングの怠惰な結合をデータに実装するのに使用されます、ダイナミックに構成された委譲システムをサポートするために。DDDSは、DDDS Databaseの中に末期的状態に達するまで繰り返しにストリング変換規則を適用することによって保存されたデータに何らかのユニークなストリングを写像することによって、機能します。 このドキュメントは、このとき完全な仕様を作るドキュメントをリストアップすることによって、全体のDDDSを定義します。

Mealling                     Informational                      [Page 1]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002

情報[1ページ]のRFC3401DDDSを荒びきにします--包括的なDDDS2002年10月

   This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes
   RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5].  This
   document will be updated and or obsoleted when changes are made to
   the DDDS specifications.  Thus the reader is strongly encouraged to
   check the IETF RFC repository for any documents that obsoletes or
   updates this one.

RFC3402、RFC3403、およびRFC3404に伴うこのドキュメントは、RFC2168[8]とRFC2915[6]を時代遅れにして、RFC2276[5]をアップデートします。 そして、このドキュメントをアップデートする、または、変更をDDDS仕様にすると、時代遅れにしています。 したがって、読者がどんなドキュメントのためのこれを時代遅れにするか、またはアップデートするIETF RFC倉庫もチェックするよう強く奨励されます。

3. The Algorithm

3. アルゴリズム

   The DDDS algorithm is defined by RFC 3402 [1].  That document defines
   the following DDDS concepts:

DDDSアルゴリズムはRFC3402[1]によって定義されます。 そのドキュメントは以下のDDDS概念を定義します:

   o  The basic DDDS vocabulary.

o 基本的なDDDSボキャブラリー。

   o  The algorithm.

o アルゴリズム。

   o  The requirements on applications using the algorithm.

o アルゴリズムを使用するアプリケーションに関する要件。

   o  The requirements on databases that store DDDS rules.

o DDDS規則を保存するデータベースに関する要件。

   RFC 3402 is the actual DDDS Algorithm specification.  But the
   specification by itself is useless without some additional document
   that defines how and why the algorithm is used.  These documents are
   called Applications and do not actually make up part of the DDDS core
   specification.  Applications require databases in which to store
   their Rules.  These databases are called DDDS Databases and are
   usually specified in separate documents.  But again, these Database
   specifications are not included in the DDDS core specification
   itself.

RFC3402は実際のDDDS Algorithm仕様です。 しかし、それ自体で仕様はアルゴリズムがどのように、なぜ使用されているかを定義する何らかの追加ドキュメントなしで役に立ちません。 これらのドキュメントは、Applicationsと呼ばれて、実際にDDDSコア仕様の一部を作りません。 アプリケーションはそれらのRulesを保存するデータベースを必要とします。 これらのデータベースは、DDDS Databasesと呼ばれて、通常、別々のドキュメントで指定されます。 しかし、一方、これらのDatabase仕様はDDDSコア仕様自体に含まれていません。

4. DDDS Applications

4. DDDSアプリケーション

   No implementation can begin without an Application specification, as
   this is what provides the concrete instantiation details for the DDDS
   Algorithm.  Without them the DDDS is nothing more than a general
   algorithm.  Application documents define the following:

実装は全くApplication仕様なしで始まることができません、これがDDDS Algorithmのための具体的な具体化詳細を明らかにすることであるので。 それらがなければ、DDDSはただ一般的なアルゴリズムです。 アプリケーションドキュメントは以下を定義します:

   o  the Application Unique String (the thing the delegation rules act
      on).

o Application Unique String(委譲規則が影響するもの)。

   o  the First Well Known Rule (the Rule that says where the process
      starts).

o First Well Known Rule(プロセスがどこで始まるかを言うRule)。

   o  the list of valid Databases (you can't just use any Database).

o 有効なDatabases(あなたはただ少しのDatabaseも使用できない)のリスト。

   o  the final expected output.

o 最終的な予想された出力。

Mealling                     Informational                      [Page 2]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002

情報[2ページ]のRFC3401DDDSを荒びきにします--包括的なDDDS2002年10月

   Some sample Applications are documented in:

いくつかのサンプルApplicationsが以下に記録されます。

   o  "E.164 number and DNS" (RFC 2916) [7].  This Application uses the
      DDDS to map a telephone number to service endpoints such as SIP or
      email.

o 「E.164番号とDNS」(RFC2916)[7]。 このApplicationは、SIPなどのサービス終点に電話番号を写像するか、またはメールするのにDDDSを使用します。

   o  "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
      Resource Identifiers (URI) Resolution Application" (RFC 3404) [3].
      This Application uses the DDDS to resolve any URI to a set of
      endpoints or 'resolvers' that can give additional information
      about the URI independent of its particular URI scheme.

o 「ダイナミックな委譲発見システム(DDDS)パートFour:」 「Uniform Resource Identifier(URI)解決アプリケーション」(RFC3404)[3]。 このApplicationは、特定のURI体系の如何にかかわらずURIに関する追加情報を与えることができる1セットの終点か'レゾルバ'にどんなURIも決議するのにDDDSを使用します。

5. Currently Standardized Databases

5. 現在標準化されたデータベース

   Any DDDS Application must use some type of DDDS Database.  Database
   documents define the following:

どんなDDDS ApplicationもDDDS Databaseのタイプを使用しなければなりません。 データベースドキュメントは以下を定義します:

   o  the general spec for how the Database works.

o Databaseがどう働くか一般的な仕様。

   o  formats for Keys.

o キーズにフォーマットします。

   o  formats for Rules.

o Rulesのために、フォーマットします。

   o  Key lookup process.

o 主要なルックアッププロセス。

   o  rule insertion procedures.

o 挿入手順を統治してください。

   o  collision avoidance measures.

o 衝突回避用レーダー警報装置は測定します。

   A Database cannot be used on its own; there must be at least one
   Application that uses it.  Multiple Databases and Applications are
   defined, and some Databases will support multiple Applications.
   However, not every Application uses each Database, and vice versa.
   Thus, compliance is defined by the combination of a Database and
   Application specification.

それ自身のところでDatabaseを使用できません。 それを使用する少なくとも1Applicationがあるに違いありません。 複数のDatabasesとApplicationsは定義されます、そして、いくつかのDatabasesが複数のApplicationsをサポートするでしょう。 しかしながら、あらゆるApplicationが各Databaseを使用するというわけではありません、そして、逆もまた同様です。 したがって、コンプライアンスはDatabaseとApplication仕様の組み合わせで定義されます。

   One sample Database specification is documented in:

1つのサンプルDatabase仕様が以下に記録されます。

   o  "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
      Name System (DNS) Database" (RFC 3402) [1].  (This document is the
      official specification for the NAPTR DNS Resource Record.)

o 「ダイナミックな委譲発見システム(DDDS)パートThree:」 「ドメインネームシステム(DNS)データベース」(RFC3402)[1]。 (このドキュメントはNAPTR DNS Resource Recordのための公式の仕様書です。)

6. Security Considerations

6. セキュリティ問題

   Any known security issues that arise from the use of algorithms and
   databases must be specified in the respective specifications.  They
   must be completely and fully described.  It is not required that the
   database and algorithms be secure or that it be free from risks, but

それぞれの仕様でアルゴリズムとデータベースの使用から起こるどんな知られている安全保障問題も指定しなければなりません。 それらについて完全に、そして完全に説明しなければなりません。 データベースとアルゴリズムが安全であるか、またはしかし、それにはリスクがないのが必要ではありません。

Mealling                     Informational                      [Page 3]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002

情報[3ページ]のRFC3401DDDSを荒びきにします--包括的なDDDS2002年10月

   that the known risks be identified.  Publication of a new database
   type or algorithm does require a security review, and the security
   considerations section should be subject to continuing evaluation.
   Additional security considerations should be addressed by publishing
   revised versions of the database and algorithm specifications.

知られている危険は特定されます。 新しいデータベースタイプかアルゴリズムの公表は安全レビューを必要とします、そして、セキュリティ問題部は継続する評価を受けることがあるべきです。 追加担保問題はデータベースとアルゴリズム仕様の出版改訂版によって扱われるべきです。

7. IANA Considerations

7. IANA問題

   While this document itself does not create any new requirements for
   the IANA, the documents in this series create many varied
   requirements.  The IANA Considerations sections in those documents
   should be reviewed by the IANA to determine the complete set of new
   registries and requirements.  Any new algorithms, databases or
   applications should take great care in what they require the IANA to
   do in the future.

このドキュメント自体はIANAのためのどんな新しい要件も作成しませんが、このシリーズにおけるドキュメントは多くの様々な要件を作成します。 それらのドキュメントのIANA Considerations部は、完全なセットの新しい登録と要件を決定するためにIANAによって見直されるはずです。 どんな新しいアルゴリズム、データベースかアプリケーションがIANAが将来するそれらが、必要であることにおける高度の注意を取るべきです。

References

参照

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

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

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

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

   [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
       Four: The Uniform Resource Identifiers (URI) Resolution
       Application", RFC 3404, October 2002.

[3] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)解決アプリケーション」、RFC3404、2002年10月。

   [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
       Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.

[4] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は5を分けます」。 「URI.ARPA課題手順」、RFC3405、2002年10月。

   [5] Sollins, K., "Architectural Principles of Uniform Resource Name
       Resolution", RFC 2276, January 1998.

[5]Sollins、1998年1月のK.、「一定のリソース名前解決の建築プリンシプルズ」RFC2276。

   [6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR)
       DNS Resource Record", RFC 2915, August 2000.

[6] 食事とM.とR.ダニエル、「命名権威指針(NAPTR)DNSリソース記録」、RFC2915、2000年8月。

   [7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.

[7]Faltstromと、P.と、「E.164番号とDNS」、RFC2916、9月2000日

   [8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
       Identifiers using the Domain Name System", RFC 2168, June 1997.

[8] ダニエルとR.とM.食事、「ドメインネームシステムを使用するUniform Resource Identifierの決議」、RFC2168、1997年6月。

Mealling                     Informational                      [Page 4]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002

情報[4ページ]のRFC3401DDDSを荒びきにします--包括的なDDDS2002年10月

Author's Address

作者のアドレス

   Michael Mealling
   VeriSign
   21345 Ridgetop Circle
   Sterling, VA  20166
   US

ベリサイン21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル

   EMail: michael@neonym.net
   URI:   http://www.verisignlabs.com

メール: michael@neonym.net ユリ: http://www.verisignlabs.com

Mealling                     Informational                      [Page 5]

RFC 3401             DDDS - The Comprehensive DDDS          October 2002

情報[5ページ]のRFC3401DDDSを荒びきにします--包括的なDDDS2002年10月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

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

Mealling                     Informational                      [Page 6]

食事情報です。[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

-単項演算子 負号

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る