RFC3117 日本語訳
3117 On the Design of Application Protocols. M. Rose. November 2001. (Format: TXT=57279 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose Request for Comments: 3117 Dover Beach Consulting, Inc. Category: Informational November 2001
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 3117年のドーヴァービーチコンサルティングInc.カテゴリ: 情報の2001年11月
On the Design of Application Protocols
アプリケーション・プロトコルのデザインに関して
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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). BXXP is a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.
このメモはBlocks eXtensible eXchangeプロトコル(BXXP)のために設計原理について説明します。 BXXPは接続指向の、そして、非同期な相互作用のための一般的適用プロトコル枠組みです。 枠組みはただ一つのアプリケーションユーザアイデンティティの文脈の中で同時の、そして、独立している交換を可能にします、原文の、そして、2進の両方のメッセージを支持して。
Rose Informational [Page 1] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[1ページ]のRFC3117
Table of Contents
目次
1. A Problem 19 Years in the Making . . . . . . . . . . . . . . . 3 2. You can Solve Any Problem... . . . . . . . . . . . . . . . . . 6 3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 8 3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.7 Let's Recap . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 14 4.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. The BXXP Framework . . . . . . . . . . . . . . . . . . . . . . 17 5.1 Framing and Encoding . . . . . . . . . . . . . . . . . . . . . 17 5.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6 Things We Left Out . . . . . . . . . . . . . . . . . . . . . . 21 5.7 From Framework to Protocol . . . . . . . . . . . . . . . . . . 22 6. BXXP is now BEEP . . . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
1. 19年間の作成. . . . . . . . . . . . . . . 3 2における問題。 あなたはどんな問題も解決できます… . . . . . . . . . . . . . . . . . 6 3. メカニズム. . . . . . . . . . . . . . . . . . . . . 8 3.1縁ど. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2りコード化. . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3報告. . . . . . . . . . . . . . . . . . . . . . . . . . 9 3について議定書の中で述べてください; 4 非同期. . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5認証. . . . . . . . . . . . . . . . . . . . . . . . 12 3.6プライバシー. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.7は.134をリキャップしましょう。 特性. . . . . . . . . . . . . . . . . . . . . 14 4.1のスケーラビリティ. . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2効率. . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3の簡単さ. . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4伸展性. . . . . . . . . . . . . . . . . . . . . . . . 15 4.5丈夫さ. . . . . . . . . . . . . . . . . . . . . . . . . . 16 5について議定書の中で述べてください。 BXXP枠組み. . . . . . . . . . . . . . . . . . . . . . 17 5.1の縁どりとコード化. . . . . . . . . . . . . . . . . . . . . 17 5.2報告. . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3非同期. . . . . . . . . . . . . . . . . . . . . . . . . . 19 5; 4 私たちが枠組みからプロトコル. . . . . . . . . . . . . . . . . . 22 6まで.215.7に置いた認証. . . . . . . . . . . . . . . . . . . . . . . . 21 5.5プライバシー. . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6もの。 現在、BXXPはBEEP. . . . . . . . . . . . . . . . . . . . . . . 23 7です。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24作者のアドレスの.26の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 27
Rose Informational [Page 2] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[2ページ]のRFC3117
1. A Problem 19 Years in the Making
1. 19年間の作成における問題
SMTP [1] is close to being the perfect application protocol: it solves a large, important problem in a minimalist way. It's simple enough for an entry-level implementation to fit on one or two screens of code, and flexible enough to form the basis of very powerful product offerings in a robust and competitive market. Modulo a few oddities (e.g., SAML), the design is well conceived and the resulting specification is well-written and largely self-contained. There is very little about good application protocol design that you can't learn by reading the SMTP specification.
完全なアプリケーション・プロトコルである近くにSMTP[1]があります: それはミニマリスト方法で大きくて、重要な問題を解決します。 それは、入社の段階実現がコードの1か2個のスクリーンに合うほど簡単であって、強健で競争の激しい市場の非常に強力な製品提供の基礎を形成するほどフレキシブルです。 法、結果として起こる仕様は、数人の奇異(例えば、SAML)であり、デザインがよく発想されて、上手に書かれていて主に独立です。 ほとんど、あなたがSMTP仕様を読むことによって学ぶことができない良いアプリケーション・プロトコルデザインに関して、ありません。
Unfortunately, there's one little problem: SMTP was originally published in 1981 and since that time, a lot of application protocols have been designed for the Internet, but there hasn't been a lot of reuse going on. You might expect this if the application protocols were all radically different, but this isn't the case: most are surprisingly similar in their functional behavior, even though the actual details vary considerably.
残念ながら、1つの問題がほとんどありません: 1981、その時多くのアプリケーション・プロトコルがインターネットに設計されますが、先へ進む多くの再利用がなかったので、SMTPは元々、発行されました。 アプリケーション・プロトコルが根本的にすべて異なるなら、あなたはこれを予想するでしょうにが、これはそうではありません: 大部分は、実際の詳細がかなり異なりますが、彼らの機能的な振舞いにおいて驚くほど同様です。
In late 1998, as Carl Malamud and I were sitting down to review the Blocks architecture, we realized that we needed to have a protocol for exchanging Blocks. The conventional wisdom is that when you need an application protocol, there are four ways to proceed:
1998年後半に、カール・マラマッドと私がBlocks構造を見直すために座っていたとき、私たちは、Blocksを交換するためのプロトコルを必要としたとわかりました。 一般通念はあなたがアプリケーション・プロトコルを必要とするとき、続く4つの方法があるということです:
1. find an existing exchange protocol that (more or less) does what
you want;
1. (多少、)あなたが欲しいことをする既存の交換プロトコルを見つけてください。
2. define an exchange model on top of the world-wide web
infrastructure that (more or less) does what you want;
2. (多少、)あなたが欲しいことをする世界的なウェブインフラストラクチャの上で交換モデルを定義してください。
3. define an exchange model on top of the electronic mail
infrastructure that (more or less) does what you want; or,
3. (多少、)あなたが欲しいことをする電子メールインフラストラクチャの上で交換モデルを定義してください。 または
4. define a new protocol from scratch that does exactly what you
want.
4. 最初から、新しいプロトコルを定義してください。それはまさにあなたが欲しいことをします。
An engineer can make reasoned arguments about the merits of each of the these approaches. Here's the process we followed...
技術者缶の造がそれぞれの長所の議論を推論した、これらのアプローチ。 ここに、私たちが従った過程があります…
The most appealing option is to find an existing protocol and use that. (In other words, we'd rather "buy" than "make".) So, we did a survey of many existing application protocols and found that none of them were a good match for the semantics of the protocol we needed.
最も魅力的なオプションは、既存のプロトコルを見つけて、それを使用することです。 (言い換えれば、私たちは「作成」より「買う方がましです」。) それで、私たちは、多くの既存のアプリケーション・プロトコルの調査をして、それらのいずれが私たちが必要としたプロトコルの意味論のための良いマッチでないことがわかりました。
For example, most application protocols are oriented toward client/server behavior, and emphasize the client pulling data from the server; in contrast with Blocks, a client usually pulls data from
例えば、ほとんどのアプリケーション・プロトコルが、クライアント/サーバの振舞いに向かって適応して、サーバからデータを引いているクライアントを強調します。 Blocks、通常、クライアントがデータを引くaと比べて
Rose Informational [Page 3] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[3ページ]のRFC3117
the server, but it also may request the server to asynchronously push (new) data to it. Clearly, we could mutate a protocol such as FTP [2] or SMTP into what we wanted, but by the time we did all that, the base protocol and our protocol would have more differences than similarities. In other words, the cost of modifying an off-the-shelf implementation becomes comparable with starting from scratch.
また、しかし、サーバ、それは、(新しい)のデータをそれに非同期に押すようサーバに要求するかもしれません。 明確に、私たちはFTP[2]かSMTPなどのプロトコルを欲しかったものに変異させることができましたが、私たちがそのすべてをする時までにベースプロトコルと私たちのプロトコルには類似性より多くの違いがあるでしょう。 言い換えれば、すぐ入手できる実現を変更する費用は最初から始まるのに匹敵するようになります。
Another approach is to use HTTP [3] as the exchange protocol and define the rules for data exchange over that. For example, IPP [4] (the Internet Printing Protocol) uses this approach. The basic idea is that HTTP defines the rules for exchanging data and then you define the data's syntax and semantics. Because you inherit the entire HTTP infrastructure (e.g., HTTP's authentication mechanisms, caching proxies, and so on), there's less for you to have to invent (and code!). Or, conversely, you might view the HTTP infrastructure as too helpful. As an added bonus, if you decide that your protocol runs over port 80, you may be able to sneak your traffic past older firewalls, at the cost of port 80 saturation.
別のアプローチは、交換プロトコルとしてHTTP[3]を使用して、それの上のデータ交換のために規則を決めることです。 例えば、IPP[4](インターネットPrintingプロトコル)はこのアプローチを使用します。 基本的な考え方はHTTPがデータを交換するために規則を決めるということです、そして、次に、あなたはデータの構文と意味論を定義します。 あなたが全体のHTTPインフラストラクチャ(例えば、HTTPの認証機構、プロキシをキャッシュして、など)を引き継ぐので、あなたが発明しなければならないように、より少ない状態で(そして、コード!)、あります。 または、逆に、あなたは、HTTPインフラストラクチャに役立ち過ぎるとみなすかもしれません。 加えられたボーナスあなたのプロトコルがポート80を中を走らせると決めるなら、あなたは、より古いファイアウォールの先で交通に潜入できるかもしれません、ポートの費用で。80飽和。
HTTP has many strengths: it's ubiquitous, it's familiar, and there are a lot of tools available for developing HTTP-based systems. Another good thing about HTTP is that it uses MIME [5] for encoding data.
HTTPには、多くの強さがあります: それは遍在しています、そして、それはなじみ深いです、そして、展開しているHTTPベースのシステムに利用可能な多くのツールがあります。HTTPの周りの別の良いことはデータを暗号化するのにMIME[5]を使用するということです。
Unfortunately for us, even with HTTP 1.1 [6], there still wasn't a good fit. As a consequence of the highly-desirable goal of maintaining compatibility with the original HTTP, HTTP's framing mechanism isn't flexible enough to support server-side asynchronous behavior and its authentication model isn't similar to other Internet applications.
残念ながら、良いフィットがまだ私たちと、HTTP1.1[6]があってもありませんでした。 オリジナルのHTTPとの互換性を維持するという非常に望ましい目標の結果として、HTTPの縁どりメカニズムはサーバサイドの非同期な振舞いを支持するくらいにはフレキシブルではありません、そして、認証モデルは他のインターネットアプリケーションと同様ではありません。
Mapping IPP onto HTTP 1.1 illustrates the former issue. For example, the IPP server is supposed to signal its client when a job completes. Since the HTTP client must originate all requests and since the decision to close a persistent connection in HTTP is unilateral, the best that the IPP specification can do is specify this functionality in a non-deterministic fashion.
HTTP1.1にIPPを写像すると、前の問題は例証します。 例えば、IPPサーバはクライアントのためにいつに合図するべきであるか。仕事は完了します。 HTTPクライアントがすべての要求を溯源しなければならなくて、HTTPにおけるパーシステントコネクションを閉じるという決定が一方的であるので、IPP仕様が尽くすことができるベストは非決定論的なファッションでこの機能性を指定することです。
Further, the IPP mapping onto HTTP shows that even subtle shifts in behavior have unintended consequences. For example, requests in IPP are typically much larger than those seen by many HTTP server implementations -- resulting in oddities in many HTTP servers (e.g., requests are sometimes silently truncated). The lesson is that HTTP's framing mechanism is very rigid with respect to its view of the request/response model.
さらに、HTTPへのIPPマッピングは、振舞いにおける微妙なシフトさえ意図しない結果を得るのを示します。 例えば、通常、IPPでの要求は多くのHTTPサーバで奇異をもたらして、多くのHTTPサーバ実現で見られたものよりはるかに大きいです(例えば要求は時々静かに先端を切られます)。 レッスンはHTTPの縁どりメカニズムが要求/応答モデルの視点に関して非常に堅いということです。
Rose Informational [Page 4] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[4ページ]のRFC3117
Lastly, given our belief that the port field of the TCP header isn't a constant 80, we were immune to the seductive allure of wanting to sneak our traffic past unwary site administrators.
最後に、TCPヘッダーのポート分野が一定の80でないという私たちの信念を考えて、私たちは不注意なサイトの管理者の先で私たちの交通に潜入したい色っぽい魅力に免疫がありました。
The third choice, layering the protocol on top of email, was attractive. Unfortunately, the nature of our application includes a lot of interactivity with relatively small response times. So, this left us the final alternative: defining a protocol from scratch.
メールの上でプロトコルを層にして、3番目の選択は魅力的でした。 残念ながら、私たちのアプリケーションの本質は比較的小さい応答時間がある多くの対話性を含んでいます。 それで、これは最終的な代替手段に私たちを置き去りにしました: 最初から、プロトコルを定義します。
To begin, we figured that our requirements, while a little more stringent than most, could fit inside a framework suitable for a large number of future application protocols. The trick is to avoid the kitchen-sink approach. (Dave Clark has a saying: "One of the roles of architecture is to tell you what you can't do.")
始まるように、私たちは、大部分より厳しい間、私たちの要件が多くの将来のアプリケーション・プロトコルに適した枠組みで合うことができるのを計算しました。 トリックは台所流し台アプローチを避けることです。 (デーブ・クラークは口を出す権利があります: 「構造の役割の1つはあなたが何ができないかをあなたに言うことです」)
Rose Informational [Page 5] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[5ページ]のRFC3117
2. You can Solve Any Problem...
2. あなたはどんな問題も解決できます…
...if you're willing to make the problem small enough.
...あなたが、問題を十分小さくしても構わないと思っているなら。
Our most important step is to limit the problem to application protocols that exhibit certain features:
私たちの最も重要なステップは問題をある特徴を示すアプリケーション・プロトコルに制限することです:
o they are connection-oriented;
o それらは接続指向です。
o they use requests and responses to exchange messages; and,
o 彼らはメッセージを交換するのに要求と応答を使用します。 そして
o they allow for asynchronous message exchange.
o 彼らは非同期な交換処理を考慮します。
Let's look at each, in turn.
順番にそれぞれを見ましょう。
First, we're only going to consider connection-oriented application protocols (e.g., those that work on top of TCP [7]). Another branch in the taxonomy, connectionless, consists of those that don't want the delay or overhead of establishing and maintaining a reliable stream. For example, most DNS [8] traffic is characterized by a single request and response, both of which fit within a single IP datagram. In this case, it makes sense to implement a basic reliability service above the transport layer in the application protocol itself.
最初に、私たちは、接続指向のアプリケーションがプロトコルであると考えるだけです。(例えばTCP[7])の上で働いているもの。 分類学の別のコネクションレスなブランチは信頼できる流れを確立して、維持する遅れかオーバーヘッドを必要としないものから成ります。 例えば、ほとんどのDNS[8]交通がただ一つの要求と応答で特徴付けられます。その両方が単一のIPデータグラムの中に合います。 この場合、それはトランスポート層を超えてアプリケーション・プロトコル自体で基本的な信頼性のサービスを実行する意味になります。
Second, we're only going to consider message-oriented application protocols. A "message" -- in our lexicon -- is simply structured data exchanged between loosely-coupled systems. Another branch in the taxonomy, tightly-coupled systems, uses remote procedure calls as the exchange paradigm. Unlike the connection-oriented/connectionless dichotomy, the issue of loosely- or tightly-coupled systems is similar to a continuous spectrum. Fortunately, the edges are fairly sharp.
2番目に、私たちは、メッセージ指向のアプリケーションがプロトコルであると考えるだけです。 私たちのレキシコンにおける「メッセージ」は弱連結システムの間で交換された単に構造化されたデータです。分類学の別のブランチ(密結合システム)は交換パラダイムとして遠隔手続き呼び出しを使用します。 接続指向の、または、コネクションレスな二分、問題、ゆるみ、または、システムが同様である密結合a連続スペクトル。 幸い、縁はかなり急です。
For example, NFS [9] is a tightly-coupled system using RPCs. When running in a properly-configured LAN, a remote disk accessible via NFS is virtually indistinguishable from a local disk. To achieve this, tightly-coupled systems are highly concerned with issues of latency. Hence, most (but not all) tightly-coupled systems use connection-less RPC mechanisms; further, most tend to be implemented as operating system functions rather than user-level programs. (In some environments, the tightly-coupled systems are implemented as single-purpose servers, on hardware specifically optimized for that one function.)
例えば、NFS[9]はRPCsを使用する密結合システムです。 適切に構成されたLANへ駆け込むとき、NFSを通してアクセスしやすいリモートディスクは実際にはローカルディスクから区別がつきません。 これを達成するために、潜在の問題に密結合システムを非常に心配させます。 したがって、ほとんどの(すべてでない)密結合システムがコネクションレスなRPCメカニズムを使用します。 さらに、大部分は、ユーザレベルプログラムよりむしろオペレーティングシステム機能として実行される傾向があります。(いくつかの環境で、密結合システムはただ一つの目的サーバとしてその1つの機能のために明確に最適化されたハードウェアの上で導入されます。)
Finally, we're going to consider the needs of application protocols that exchange messages asynchronously. The classic client/server model is that the client sends a request and the server sends a
最終的に、私たちはメッセージを非同期に交換するアプリケーション・プロトコルの必要性を考えるつもりです。 古典的なクライアント/サーバモデルはクライアントが要求を送って、サーバがaを送るということです。
Rose Informational [Page 6] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[6ページ]のRFC3117
response. If you think of requests as "questions" and responses as "answers", then the server answers only those questions that it's asked and it never asks any questions of its own. We'll need to support a more general model, peer-to-peer. In this model, for a given transaction one peer might be the "client" and the other the "server", but for the next transaction, the two peers might switch roles.
応答。 あなたが「答え」としての「質問」と応答として要求を考えるなら、サーバは尋ねて、それ自身のどんな質問も決してしないというそれらの質問だけに答えます。 私たちは、より一般的なモデル、ピアツーピアを支持する必要があるつもりです。 このモデルでは、1人の同輩が与えられた取引のための、「クライアント」であるかもしれなく、もう片方が「サーバ」です、しかし、次の取引のために、2人の同輩が役割を切り換えるかもしれません。
It turns out that the client/server model is a proper subset of the peer-to-peer model: it's acceptable for a particular application protocol to dictate that the peer that establishes the connection always acts as the client (initiates requests), and that the peer that listens for incoming connections always acts as the server (issuing responses to requests).
クライアント/サーバモデルがピアツーピアモデルの真部分集合であると判明します: 特定用途プロトコルが、接続を確立する同輩がクライアント(要求を開始する)としていつも務めて、接続要求の聞こうとする同輩がサーバとしていつも務めると決めるのは、許容できます(要求への応答を発行して)。
There are quite a few existing application domains that don't fit our requirements, e.g., nameservice (via the DNS), fileservice (via NFS), multicast-enabled applications such as distributed video conferencing, and so on. However, there are a lot of application domains that do fit these requirements, e.g., electronic mail, file transfer, remote shell, and the world-wide web. So, the bet we are placing in going forward is that there will continue to be reasons for defining protocols that fit within our framework.
私たちの要件に合わないかなり多くの既存のアプリケーションドメイン、例えば、nameservice(DNSを通した)fileservice(NFSを通した)、分配されたビデオ会議などなどのマルチキャストで可能にされた利用があります。 しかしながら、例えばこれらの要件に合う多くのアプリケーションドメイン、電子メール、ファイル転送、リモートシェル、および世界的なウェブがあります。 それで、私たちが進んでいるのに置いている賭けは私たちの枠組みの中で合うプロトコルを定義する理由が続くということです。
Rose Informational [Page 7] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[7ページ]のRFC3117
3. Protocol Mechanisms
3. プロトコルメカニズム
The next step is to look at the tasks that an application protocol must perform and how it goes about performing them. Although an exhaustive exposition might identify a dozen (or so) areas, the ones we're interested in are:
次のステップはアプリケーション・プロトコルが実行しなければならないタスクとどう動き回るかがそれらを実行するのを見ることです。 徹底的な博覧会は1ダースの(or so)領域を特定するかもしれませんが、私たちが興味を持っているものは以下の通りです。
o framing, which tells how the beginning and ending of each message
is delimited;
o 縁どり(それは、それぞれのメッセージの始めと結末がどのように区切られるかを言います)。
o encoding, which tells how a message is represented when exchanged;
o コード化して、どれが、交換するとどのようにメッセージを表すかを言うか。
o reporting, which tells how errors are described;
o どれが、誤りがどのように説明されるかを言うかと報告します。
o asynchrony, which tells how independent exchanges are handled;
o 非同期、;(それは、独立している交換がどのように扱われるかを言います)。
o authentication, which tells how the peers at each end of the
connection are identified and verified; and,
o 認証、;(それは、接続の各端の同輩がどのように特定されて、確かめられるかを言います)。 そして
o privacy, which tells how the exchanges are protected against
third-party interception or modification.
o プライバシー。(そのプライバシーは、交換がどのように第三者妨害か変更に対して保護されるかを言います)。
A notable absence in this list is naming -- we'll explain why later on.
このリストが注目に値する不在は命名です--私たちは後で理由について説明するつもりです。
3.1 Framing
3.1 縁どり
There are three commonly used approaches to delimiting messages: octet-stuffing, octet-counting, and connection-blasting.
メッセージを区切ることへの3つの一般的に使用されたアプローチがあります: 八重奏を詰めて、八重奏を数えて、接続を破壊しています。
An example of a protocol that uses octet-stuffing is SMTP. Commands in SMTP are line-oriented (each command ends in a CR-LF pair). When an SMTP peer sends a message, it first transmits the "DATA" command, then it transmits the message, then it transmits a "." (dot) followed by a CR-LF. If the message contains any lines that begin with a dot, the sending SMTP peer sends two dots; similarly, when the other SMTP peer receives a line that begins with a dot, it discards the dot, and, if the line is empty, then it knows it's received the entire message. Octet-stuffing has the property that you don't need the entire message in front of you before you start sending it. Unfortunately, it's slow because both the sender and receiver must scan each line of the message to see if they need to transform it.
八重奏詰め物を使用するプロトコルに関する例はSMTPです。 SMTPのコマンドは系列指向です(各コマンドはCR-LF組に終わります)。 「SMTP同輩がメッセージを送るとき、最初に、「データ」コマンドを伝えて、次に、メッセージを送って、次に、a」を伝えます。」 (ドット) CR-LFによって続かれています。 メッセージが何かドットで始まる系列を含んでいるなら、送付SMTP同輩は2つのドットを送ります。 もう片方のSMTP同輩がドットで始まる台詞を受けるとき、同様に、ドットを捨てます、そして、系列が空であるなら、全体のメッセージを受け取ったのを知っています。 八重奏詰め物には、特性があります。それを送り始める前にあなたはあなたの正面で全体のメッセージを必要としません。 残念ながら、送付者と受信機の両方が彼らが、それを変える必要であるかどうかを見るメッセージの各系列をスキャンしなければならないので、それは遅いです。
An example of a protocol that uses octet-counting is HTTP. Commands in HTTP consist of a request line followed by headers and a body. The headers contain an octet count indicating how large the body is. The properties of octet-counting are the inverse of octet-stuffing:
八重奏勘定を使用するプロトコルに関する例はHTTPです。 HTTPにおけるコマンドはヘッダーとボディーが支えた要求系列から成ります。 ヘッダーはボディーがどれくらい大きいかを示す八重奏カウントを含んでいます。 八重奏勘定の特性は八重奏詰め物の逆です:
Rose Informational [Page 8] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[8ページ]のRFC3117
before you can start sending a message you need to know the length of the whole message, but you don't need to look at the content of the message once you start sending or receiving.
以前、あなたが全体のメッセージの長さを知るために必要とするメッセージを送り始めることができますが、発信し始めるか、またはいったん受信し始めると、あなたはメッセージの内容を見る必要はありません。
An example of a protocol that uses connection-blasting is FTP. Commands in FTP are line-oriented, and when it's time to exchange a message, a new TCP connection is established to transmit the message. Both octet-counting and connection-blasting have the property that the messages can be arbitrary binary data; however, the drawback of the connection-blasting approach is that the peers need to communicate IP addresses and TCP port numbers, which may be "transparently" altered by NATS [10] and network bugs. In addition, if the messages being exchanged are small (say less than 32k), then the overhead of establishing a connection for each message contributes significant latency during data exchange.
接続爆破を使用するプロトコルに関する例はFTPです。 FTPにおけるコマンドは系列指向です、そして、もうメッセージを交換するべき時間であるとき、新しいTCP接続は、メッセージを送るために確立されます。 八重奏勘定と接続爆破の両方がメッセージが持つことができる特性を持っています。任意のバイナリ・データになってください。 しかしながら、接続を破壊するアプローチの欠点は同輩が、NATS[10]とネットワークバグによって「透過的に」変更されるかもしれないIPアドレスとTCPポートナンバーを伝える必要があるということです。 さらに、交換されるメッセージが小さいなら(32kほど言わないでください)、各メッセージのために取引関係を築くオーバーヘッドはデータ交換の間、重要な潜在を寄付します。
3.2 Encoding
3.2 コード化
There are many schemes used for encoding data (and many more encoding schemes have been proposed than are actually in use). Fortunately, only a few are burning brightly on the radar.
データを暗号化するのに使用される多くの体系があります(ずっと多くのコード化体系が実際に使用中であるというよりも提案されました)。 いくつかだけがレーダーで明るく燃えています。
The messages exchanged using SMTP are encoded using the 822-style [11]. The 822-style divides a message into textual headers and an unstructured body. Each header consists of a name and a value and is terminated with a CR-LF pair. An additional CR-LF separates the headers from the body.
SMTPを使用することで交換されたメッセージは、822スタイル[11]を使用することでコード化されます。 822スタイルがメッセージを原文のヘッダーと不統一なボディーに分割します。 各ヘッダーは、名前と価値から成って、CR-LF組と共に終えられます。 追加CR-LFはボディーからヘッダーを分離します。
It is this structure that HTTP uses to indicate the length of the body for framing purposes. More formally, HTTP uses MIME, an application of the 822-style to encode both the data itself (the body) and information about the data (the headers). That is, although HTTP is commonly viewed as a retrieval mechanism for HTML [12], it is really a retrieval mechanism for objects encoded using MIME, most of which are either HTML pages or referenced objects such as GIFs.
それはHTTPが縁どり目的のためにボディーの長さを示すのに使用するこの構造です。 より正式に、HTTPはMIME(データ(ボディー)自体とデータの情報(ヘッダー)の両方をコード化する822スタイルの適用)を使用します。 すなわち、HTTPはHTML[12]のための回収機構として一般的に見なされますが、それは本当にそれの大部分がGIFsなどのHTML形式のページか参照をつけられたオブジェクトのどちらかであるMIMEを使用することでコード化されたオブジェクトのための回収機構です。
3.3 Reporting
3.3 報告
An application protocol needs a mechanism for conveying error information between peers. The first formal method for doing this was defined by SMTP's "theory of reply codes". The basic idea is that an error is identified by a three-digit string, with each position having a different significance:
アプリケーション・プロトコルは同輩の間にエラー情報を伝えるのにメカニズムを必要とします。 これをするための最初の正式なメソッドはSMTPの「回答コードの理論」によって定義されました。 基本的な考え方は誤りが異なった意味を持っている各位置がある3ケタのストリングによって特定されるということです:
the first digit: indicating success or failure, either permanent or
transient;
最初のケタ: 永久的であるか一時的な成否を示します。
Rose Informational [Page 9] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[9ページ]のRFC3117
the second digit: indicating the part of the system reporting the
situation (e.g., the syntax analyzer); and,
2番目のケタ: 状況(例えば、構文分析器)を報告するシステムの部分を示します。 そして
the third digit: identifying the actual situation.
3番目のケタ: 実際の状況を特定します。
Operational experience with SMTP suggests that the range of error conditions is larger than can be comfortably encoded using a three- digit string (i.e., you can report on only 10 different things going wrong for any given part of the system). So, [13] provides a convenient mechanism for extending the number of values that can occur in the second and third positions.
SMTPの運用経験は、エラー条件の範囲が3ケタストリングを使用することでゆったりコード化できるより大きいと示唆します(すなわち、あなたはシステムの一部を与えていずれのためにも支障をきたす10の別物だけに関して報告できます)。 それで、[13]は2番目と3番目の位置に起こることができる値の数を広げるのに便利なメカニズムを提供します。
Virtually all of the application protocols we've discussed thus far use the three-digit reply codes, although there is less coordination between the designers of different application protocols than most would care to admit. (A variation on the theory of reply codes is employed by IMAP [14] which provides the same information using a different syntax.)
私たちがこれまでのところ議論したアプリケーション・プロトコルのほとんどすべてが3ケタの回答コードを使用します、異なったアプリケーション・プロトコルのデザイナーの間には、より少ないコーディネートが大部分が認めたがっているよりありますが。 (回答コードの理論の変化は異なった構文を使用することで同じ情報を提供するIMAP[14]によって使われます。)
In addition to conveying a reply code, most application protocols also send a textual diagnostic suitable for human, not machine, consumption. (More accurately, the textual diagnostic is suitable for people who can read a widely used variant of the English language.) Since reply codes reflect both positive and negative outcomes, there have been some innovative uses made for the text accompanying positive responses, e.g., prayer wheels [39]. Regardless, some of the more modern application protocols include a language localization parameter for the diagnostic text.
また、回答コードを伝えることに加えて、ほとんどのアプリケーション・プロトコルがマシンではなく、人間に適当な原文の病気の特徴を送ります、消費。 (より正確に、原文の病気の特徴は英語の広く使用された異形を読むことができる人々に適当です。) 回答コードが積極的なものと同様に否定的な結果を反映するので、テキストの付随の積極的な応答(例えば、地蔵車[39])のためにされたいくつかの革新的な用途がありました。 不注意に、より現代のアプリケーション・プロトコルのいくつかが診断テキストのための言語ローカライズパラメタを含んでいます。
Finally, since the introduction of reply codes in 1981, two unresolved criticisms have been raised:
最終的に、1981年の回答コードの導入以来、2つの未定の批評が上げられています:
o a reply code is used both to signal the outcome of an operation
and a change in the application protocol's state; and,
o 回答コードはともにアプリケーション・プロトコルの状態の操作と変化の結果に合図するのにおいて使用されています。 そして
o a reply code doesn't specify whether the associated textual
diagnostic is destined for the end-user, administrator, or
programmer.
o 回答コードは、関連原文の病気の特徴がエンドユーザ、管理者、またはプログラマのために運命づけられているかどうか指定しません。
3.4 Asynchrony
3.4 非同期
Few application protocols today allow independent exchanges over the same connection. In fact, the more widely implemented approach is to allow pipelining, e.g., command pipelining [15] in SMTP or persistent connections in HTTP 1.1. Pipelining allows a client to make multiple requests of a server, but requires the requests to be processed serially. (Note that a protocol needs to explicitly provide support for pipelining, since, without explicit guidance, many implementors
わずかなアプリケーション・プロトコルしか今日、同じ接続の上の独立している交換を許容しません。 事実上、広くより実装しているアプローチはパイプライン処理(例えば、HTTP1.1におけるSMTPかパーシステントコネクションによるコマンド連続送信[15])を許容することです。 パイプライン処理は、クライアントがサーバの複数の要求をするのを許容しますが、順次処理されるという要求を必要とします。 (多くの作成者はプロトコルが、以来明白な指導なしでパイプライン処理のサポートを明らかに提供する必要に注意してください。
Rose Informational [Page 10] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[10ページ]のRFC3117
produce systems that don't handle pipelining properly; typically, an error in a request causes subsequent requests in the pipeline to be discarded).
適切にパイプライン処理を扱わないシステムを作成してください。 通常、要求における誤りでパイプラインでのその後の要求を捨てる、)
Pipelining is a powerful method for reducing network latency. For example, without persistent connections, HTTP's framing mechanism is really closer to connection-blasting than octet-counting, and it enjoys the same latency and efficiency problems.
パイプライン処理は、ネットワークレイテンシを減少させるための強力なメソッドです。 例えば、パーシステントコネクションがなければ、HTTPの縁どりメカニズムが接続爆破の本当に八重奏勘定より近くにあります、そして、それは同じ潜在と効率問題を楽しみます。
In addition to reducing network latency (the pipelining effect), asynchrony also reduces server latency by allowing multiple requests to be processed by multi-threaded implementations. Note that if you allow any form of asynchronous exchange, then support for parallelism is also required, because exchanges aren't necessarily occurring under the synchronous direction of a single peer.
また、ネットワークレイテンシ(パイプライン処理効果)を減少させることに加えて、非同期は、マルチスレッド化された実装によって処理されるという複数の要求を許すことによって、サーバレイテンシを減少させます。 また、どんな形式の非同期な交換も許容するなら平行関係のサポートが必要であることに注意してください、交換が必ず独身の同輩の同期方向の下で起こっているというわけではないので。
Unfortunately, when you allow parallelism, you also need a flow control mechanism to avoid starvation and deadlock. Otherwise, a single set of exchanges can monopolize the bandwidth provided by the transport layer. Further, if a peer is resource-starved, then it may not have enough buffers to receive a message and deadlock results.
また、残念ながら、平行関係を許容するとき、あなたは、飢餓を避けて、行き詰まるためにフロー制御メカニズムを必要とします。 さもなければ、1セットの交換はトランスポート層で供給された帯域幅を独占できます。 さらに、同輩がリソースに飢えているなら、それには、メッセージと行き詰まり結果を受け取ることができるくらいのバッファがないかもしれません。
Flow control is typically implemented at the transport layer. For example, TCP uses sequence numbers and a sliding window: each receiver manages a sliding window that indicates the number of data octets that may be transmitted before receiving further permission. However, it's now time for the second shoe to drop: segmentation. If you do flow control then you also need a segmentation mechanism to fragment messages into smaller pieces before sending and then re- assemble them as they're received.
フロー制御はトランスポート層で通常実装されます。 例えば、TCPは一連番号と引窓を使用します: 各受信機はさらなる許可を受ける前に伝えられるかもしれないデータ八重奏の数を示す引窓を管理します。 しかしながら、現在2番目の靴がもう低下するべき時間です: 分割。 また、あなたがフロー制御をするなら、あなたは、発信する前に、より小さい断片にメッセージを断片化して、次に、それらが受け取られているときそれらを再組み立てるために分割メカニズムを必要とします。
Both flow control and segmentation have an impact on how the protocol does framing. Before we defined framing as "how to tell the beginning and end of each message" -- in addition, we need to be able to identify independent messages, send messages only when flow control allows us to, and segment them if they're larger than the available window (or too large for comfort).
フロー制御と分割の両方がプロトコルがどう縁どりをするかに影響を与えます。 以前、私たちは「どうそれぞれのメッセージの首尾を言う」と縁どりを定義しました--さらに、私たちは、独立しているメッセージを特定できる必要があって、それらが利用可能な窓より大きい、そして、(安らぎには大き過ぎます)であるなら、フロー制御が、私たちがそうするのを許容するメッセージだけとセグメントにそれらを送ってください。
Segmentation impacts framing in another way -- it relaxes the octet- counting requirement that you need to know the length of the whole message before sending it. With segmentation, you can start sending segments before the whole message is available. In HTTP 1.1 you can "chunk" (segment) data to get this advantage.
分割は別の方法的に縁どりに影響を与えます--それはあなたが、それを送る前に全体のメッセージの長さを知る必要があるという八重奏勘定要件を弛緩します。 分割から、あなたは、全体のメッセージが利用可能になる前にセグメントを送り始めることができます。 HTTP1.1では、あなたはそうすることができます。この利点を得る「塊」(セグメント)データ。
Rose Informational [Page 11] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[11ページ]のRFC3117
3.5 Authentication
3.5 認証
Perhaps for historical (or hysterical) reasons, most application protocols don't do authentication. That is, they don't authenticate the identity of the peers on the connection or the authenticity of the messages being exchanged. Or, if authentication is done, it is domain-specific for each protocol. For example, FTP and HTTP use entirely different models and mechanisms for authenticating the initiator of a connection. (Independent of mainstream HTTP, there is a little-used variant [16] that authenticates the messages it exchanges.)
恐らく歴史的で(ヒステリック)の理由で、ほとんどのアプリケーション・プロトコルは認証しません。 すなわち、彼らは接続での同輩のアイデンティティか交換されるメッセージの信憑性を認証しません。 または、認証が完了しているなら、各プロトコルに、ドメイン特有です。 例えば、FTPとHTTPは、接続の創始者を認証するのに完全に異なったモデルとメカニズムを使用します。 (主流のHTTPから独立していて、それが交換するメッセージを認証する少ししか使用されなかった異形[16]があります。)
A large part of the problem is that different security mechanisms optimize for strength, scalability, or ease of deployment. So, a few years ago, SASL [17] (the Simple Authentication and Security Layer) was developed to provide a framework for authenticating protocol peers. SASL let's you describe how an authentication mechanism works, e.g., an OTP [18] (One-Time Password) exchange. It's then up to each protocol designer to specify how SASL exchanges are generically conveyed by the protocol. For example, [19] explains how SASL works with SMTP.
問題のかなりの部分は、メカニズムが強さのために最適化するその異なったセキュリティ、スケーラビリティ、または展開の容易さです。 そのようにと、数年前に、SASL[17](Simple AuthenticationとSecurity Layer)は、プロトコル同輩を認証するのにフレームワークを提供するために開発されました。 SASL、あなたは認証機構がどう動作するかを説明して、例えば、OTP[18](1回のPassword)は交換でいましょう。 SASL交換がプロトコルによってどう一般的に伝えられるかを指定するのは、そして、それぞれのプロトコルデザイナー次第です。 例えば、[19]で、SASLがSMTPと共にどう働いているかがわかります。
A notable exception to the SASL bandwagon is HTTP, which defines its own authentication mechanisms [20]. There is little reason why SASL couldn't be introduced to HTTP, although to avoid certain race- conditions, the persistent connection mechanism of HTTP 1.1 must be used.
SASLバンドワゴンへの注目に値する例外はHTTPです。(そのHTTPはそれ自身の認証機構[20]を定義します)。 ほとんどHTTPにSASLを取り入れられないことができなかった理由があります、あるレース状態を避けるのにHTTP1.1のパーシステントコネクションメカニズムを使用しなければなりませんが。
SASL has an interesting feature in that in addition to explicit protocol exchanges to authenticate identity, it can also use implicit information provided from the layer below. For example, if the connection is running over IPsec [21], then the credentials of each peer are known and verified when the TCP connection is established.
SASLには、アイデンティティを認証する明白なプロトコル交換に加えたそれのおもしろい特徴があります、また、それは層から以下に提供された暗黙の情報を使用できます。 例えば、接続がIPsec[21]をひいているなら、TCP接続が確立されると、それぞれの同輩の資格証明書は、知られていて確かめられます。
Finally, as its name implies, SASL can do more than authentication -- depending on which SASL mechanism is in use, message integrity or privacy services may also be provided.
どのSASLメカニズムが使用中であるかよって、名前が含意するように最終的に、SASLは認証よりそれ以上のことができます、また、メッセージの保全かプライバシーサービスを提供するかもしれません。
3.6 Privacy
3.6 プライバシー
HTTP is the first widely used protocol to make use of a transport security protocol to encrypt the data sent on the connection. The current version of this mechanism, TLS [22], is available to all application protocols, e.g., SMTP and ACAP [23] (the Application Configuration Access Protocol).
HTTPは接続に送られたデータを暗号化するのに輸送セキュリティプロトコルを利用する最初の広く使用されたプロトコルです。 このメカニズムの最新版(TLS[22])は、すべてのアプリケーション・プロトコル、例えば、SMTPに利用可能であって、ACAP[23](Application Configuration Accessプロトコル)です。
Rose Informational [Page 12] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[12ページ]のRFC3117
The key difference between the original mechanism and TLS, is one of provisioning not technology. In the original approach to provisioning, a world-wide web server listens on two ports (one for plaintext traffic and the other for secured traffic); in contrast, by today's conventions, a server implementing an application protocol that is specified as TLS-enabled (e.g., [24] and [25]) listens on a single port for plaintext traffic, and, once a connection is established, the use of TLS on that connection is negotiable.
オリジナルのメカニズムとTLSの主要な違いはどんな技術にも食糧を供給しないものです。 食糧を供給することへのオリジナルのアプローチでは、世界的なウェブサーバーは2つのポート(平文トラフィックのための1つと機密保護しているトラフィックのためのもう片方)の上で聴かれます。 対照的に、今日のコンベンションによって、アプリケーション・プロトコルがそれであると実装するサーバはTLSによって可能にされると指定されます。(例えば、[24]と[25])は平文トラフィックのために単一のポートの上で聴かれて、接続がいったん確立されると、その接続のTLSの使用は交渉可能です。
Finally, note that both SASL and TLS are about "transport security" not "object security". What this means is that they focus on providing security properties for the actual communication, they don't provide any security properties for the data exchanged independent of the communication.
最終的に、SASLとTLSの両方が「オブジェクトセキュリティ」ではなく「輸送セキュリティ」に関するものであることに注意してください。 これが彼らが、セキュリティ資産を実際のコミュニケーションに提供するのは焦点を合わせるということであることを意味すること、それらがコミュニケーションの如何にかかわらず交換されたデータに少しのセキュリティ資産も提供しません。
3.7 Let's Recap
3.7 リキャップしましょう。
Let's briefly compare the properties of the three main connection- oriented application protocols in use today:
簡潔に、今日、使用中の3つの主な接続指向のアプリケーション・プロトコルの特性を比較しましょう:
Mechanism ESMTP FTP HTTP1.1
-------------- ----------- --------- -------------
Framing stuffing blasting counting
メカニズムESMTP FTP HTTP1.1-------------- ----------- --------- ------------- 縁どり詰め物の爆破勘定
Encoding 822-style binary MIME
2進の822スタイルのMIMEをコード化します。
Reporting 3-digit 3-digit 3-digit
3ケタの3ケタが3ケタであると報告します。
Asynchrony pipelining none pipelining
and chunking
非同期パイプライン処理、なにも、パイプライン処理と分魂化
Authentication SASL user/pass user/pass
認証SASLユーザ/パスユーザ/パス
Privacy SASL or TLS none TLS (nee SSL)
プライバシーSASLかTLS、TLSのいずれも(旧姓SSL)
Note that the username/password mechanisms used by FTP and HTTP are entirely different with one exception: both can be termed a "username/password" mechanism.
FTPとHTTPによって使用されるユーザ名/パスワードメカニズムがただ1つを例外として完全に異なっていることに注意してください: 「ユーザ名/パスワード」メカニズムと両方を呼ぶことができます。
These three choices are broadly representative: as more protocols are considered, the patterns are reinforced. For example, POP [26] uses octet-stuffing, but IMAP uses octet-counting, and so on.
これらの3つの選択が広く代表しています: より多くのプロトコルが考えられるとき、パターンは補強されます。 例えば、POP[26]は八重奏詰め物を使用しますが、IMAPは八重奏勘定などを使用します。
Rose Informational [Page 13] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[13ページ]のRFC3117
4. Protocol Properties
4. プロトコルの特性
When we design an application protocol, there are a few properties that we should keep an eye on.
私たちがアプリケーション・プロトコルを設計するとき、私たちが見守るべきであるいくつかの特性があります。
4.1 Scalability
4.1 スケーラビリティ
A well-designed protocol is scalable.
よく設定されたプロトコルはスケーラブルです。
Because few application protocols support asynchrony, a common trick is for a program to open multiple simultaneous connections to a single destination. The theory is that this reduces latency and increases throughput. The reality is that both the transport layer and the server view each connection as an independent instance of the application protocol, and this causes problems.
わずかなアプリケーション・プロトコルしか非同期をサポートしないので、一般的なトリックはプログラムが単一の目的地に複数の同時接続を開くことです。 理論はこれがレイテンシを減少させて、スループットを増強するということです。 現実は両方の輸送に層にされるということであり、サーバ視点はアプリケーション・プロトコルの独立しているインスタンスとして各接続です、そして、これが問題を起こします。
In terms of the transport layer, TCP uses adaptive algorithms to efficiently transmit data as networks conditions change. But what TCP learns is limited to each connection. So, if you have multiple TCP connections, you have to go through the same learning process multiple times -- even if you're going to the same host. Not only does this introduce unnecessary traffic spikes into the network, because TCP uses a slow-start algorithm when establishing a connection, the program still sees additional latency. To deal with the fact that a lack of asynchrony in application protocols causes implementors to make sloppy use of the transport layer, network protocols are now provisioned with increasing sophistication, e.g., RED [27]. Further, suggestions are also being considered for modification of TCP implementations to reduce concurrent learning, e.g., [28].
トランスポート層に関して、TCPは、状態が変えるネットワークとして効率的にデータを送るのに適応型のアルゴリズムを使用します。 しかし、TCPが学ぶことは各接続に制限されます。 それで、複数のTCP接続がありましたら、同じホストに行く予定であっても、あなたは複数の回同じ学習過程に直面しなければなりません。 取引関係を築くとき、TCPが遅れた出発アルゴリズムを使用するのでこれは不要なトラフィックスパイクをネットワークに取り入れるだけではなく、プログラムがまだ追加潜在を見ています。 作成者がアプリケーション・プロトコルにおける、非同期の不足でトランスポート層のずさんな使用をするという事実に対処するために、ネットワーク・プロトコルは現在、増加する洗練(例えば、RED[27])で食糧を供給されます。 また、さらに、提案はTCP実装の変更が同時発生の学習、例えば、[28]を減少させると考えられています。
In terms of the server, each incoming connection must be dispatched and (probably) authenticated against the same resources. Consequently, server overhead increases based on the number of connections established, rather than the number of remote users. The same issues of fairness arise: it's much harder for servers to allocate resources on a per-user basis, when a user can cause an arbitrary number of connections to pound on the server.
サーバで、各接続要求を派遣されて、(たぶん)同じリソースに対して認証しなければなりません。 その結果、サーバオーバーヘッドはリモート・ユーザーの数よりむしろ確立されたポートの数に基づいて上がります。 公正の同じ問題は起こります: サーバは1ユーザあたり1個のベースに関するリソースをはるかに割り当てにくいです、ユーザが接続の特殊活字の数字にサーバを強く打たせることができるなら。
Another important aspect of scalability to consider is the relative numbers of clients and servers. (This is true even in the peer-to- peer model, where a peer can act both in the client and server role.) Typically, there are many more client peers than server peers. In this case, functional requirements should be shifted from the servers onto the clients. The reason is that a server is likely to be interacting with multiple clients and this functional shift makes it easier to scale.
考えるスケーラビリティの別の重要な一面はクライアントとサーバの相対数です。 (これは同輩から同輩へのモデルでさえ本当です。)(そこでは、同輩がクライアントとサーバーの役割で行動できます)。 通常、ずっと多くのクライアント同輩がサーバ同輩よりいます。 この場合、機能条件書はサーバからクライアントに移行するべきです。 理由はサーバが複数のクライアントと対話していそうであるということです、そして、この機能的なシフトで、比例するのは、より簡単になります。
Rose Informational [Page 14] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[14ページ]のRFC3117
4.2 Efficiency
4.2 効率
A well-designed protocol is efficient.
よく設定されたプロトコルは効率的です。
For example, although a compelling argument can be made than octet- stuffing leads to more elegant implementations than octet-counting, experience shows that octet-counting consumes far fewer cycles.
例えば、八重奏勘定より上品な実装への八重奏詰め物の先導よりいやとは言いにくい話をすることができますが、経験は、八重奏勘定が遠くにより少ないサイクルを費やすのを示します。
Regrettably, we sometimes have to compromise efficiency in order to satisfy other properties. For example, 822 (and MIME) use textual headers. We could certainly define a more efficient representation for the headers if we were willing to limit the header names and values that could be used. In this case, extensibility is viewed as more important than efficiency. Of course, if we were designing a network protocol instead of an application protocol, then we'd make the trade-offs using a razor with a different edge.
残念なことに、私たちは、他の特性を満たすために時々効率に感染しなければなりません。 例えば、822(そして、MIME)は原文のヘッダーを使用します。 確かに、私たちが使用できたヘッダー名と値を制限するなら、ヘッダーの、より効率的な表現を定義できるでしょうに。 この場合、伸展性は効率より重要であるとして見なされます。 もちろん、私たちがアプリケーション・プロトコルの代わりにネットワーク・プロトコルを設計しているなら、異なった縁があるかみそりを使用することでトレードオフをするでしょうに。
4.3 Simplicity
4.3 簡単さ
A well-designed protocol is simple.
よく設定されたプロトコルは簡単です。
Here's a good rule of thumb: a poorly-designed application protocol is one in which it is equally as "challenging" to do something basic as it is to do something complex. Easy things should be easy to do and hard things should be harder to do. The reason is simple: the pain should be proportional to the gain.
ここに、良い経験則があります: 何か複雑なことをすることになっているとき何か基本的なことをするのを「挑戦」であるとして不十分に設計されたアプリケーション・プロトコルはそれが等しくそうであるものです。 簡単なものはするのが簡単であるはずです、そして、固いものはするのが、より困難であるべきです。 理由は簡単です: 痛みは利得に比例しているべきです。
Another rule of thumb is that if an application protocol has two ways of doing the exact same thing, then there's a problem somewhere in the architecture underlying the design of the application protocol.
別の経験則はアプリケーション・プロトコルに全く同じことをする2つの方法があるならアーキテクチャにおけるどこかのアプリケーション・プロトコルのデザインの基礎となることにおける問題があるということです。
Hopefully, simple doesn't mean simple-minded: something that's well- designed accommodates everything in the problem domain, even the troublesome things at the edges. What makes the design simple is that it does this in a consistent fashion. Typically, this leads to an elegant design.
希望をいだいて、簡単である、平均純真: よく設計されている何かが縁に問題ドメイン、厄介なものさえのすべてを収容します。 デザインを簡単にすることは一貫したファッションでこれをするということです。 通常、これは優美な意匠に通じます。
4.4 Extensibility
4.4 伸展性
A well-designed protocol is extensible.
よく設定されたプロトコルは広げることができます。
As clever as application protocol designers are, there are likely to be unforeseen problems that the application protocol will be asked to solve. So, it's important to provide the hooks that can be used to add functionality or customize behavior. This means that the protocol is evolutionary, and there must be a way for implementations reflecting different steps in the evolutionary path to negotiate which extensions will be used.
アプリケーション・プロトコルデザイナーは賢いのですが、アプリケーション・プロトコルが解決するように頼まれる予期せぬ問題がありそうです。 それで、機能性を加えるか、または振舞いをカスタマイズするのに使用できるフックを提供するのは重要です。 これは、プロトコルが進化論であり、交渉するために異なったステップを進化の道筋に反映するそれの拡張子が使用される実装のための方法があるに違いないことを意味します。
Rose Informational [Page 15] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[15ページ]のRFC3117
But, it's important to avoid falling into the extensibility trap: the hooks provided should not be targeted at half-baked future requirements. Above all, the hooks should be simple.
しかし、伸展性罠になるのを避けるのは重要です: 生半可な将来の要件で提供されたフックを狙うべきではありません。 何よりも、フックは簡単であるべきです。
Of course good design goes a long way towards minimizing the need for extensibility. For example, although SMTP initially didn't have an extension framework, it was only after ten years of experience that its excellent design was altered. In contrast, a poorly-designed protocol such as Telnet [29] can't function without being built around the notion of extensions.
もちろん、良いデザインは伸展性の必要性を最小にすることに向かってはるばる行きます。 例えば、SMTPには、初めは、拡大フレームワークがありませんでしたが、10年間の経験の後にだけ、素晴らしいデザインは変更されました。 対照的に、拡大の概念の周りに建てられないで、Telnet[29]などの不十分に設計されたプロトコルは機能できません。
4.5 Robustness
4.5 丈夫さ
A well-designed protocol is robust.
よく設定されたプロトコルは強健です。
Robustness and efficiency are often at odds. For example, although defaults are useful to reduce packet sizes and processing time, they tend to encourage implementation errors.
丈夫さと効率はしばしば不和です。 例えば、デフォルトはパケットサイズと処理時間を短縮するために役に立ちますが、それらは、実装誤りを奨励する傾向があります。
Counter-intuitively, Postel's robustness principle ("be conservative
in what you send, liberal in what you accept") often leads to
deployment problems. Why? When a new implementation is initially
fielded, it is likely that it will encounter only a subset of
existing implementations. If those implementations follow the
robustness principle, then errors in the new implementation will
likely go undetected. The new implementation then sees some, but not
widespread deployment. This process repeats for several new
implementations. Eventually, the not-quite-correct implementations
run into other implementations that are less liberal than the initial
set of implementations. The reader should be able to figure out what
happens next.
直観的にカウンタ、ポステルの堅牢性の原則(「あなたが送るもので保守的であってください、あなたが受け入れるものでは、寛容である」)はしばしば展開問題を引き起こします。なぜですか? 新しい実装が初めはさばかれるとき、それは既存の実装の部分集合だけに遭遇しそうでしょう。 それらの実装が堅牢性の原則に従うと、新しい実装における誤りはおそらく非検出されているのに行くでしょう。 そして、新しい実装は広範囲の展開ではなく、いくつかを見ます。 このプロセスはいくつかの新しい実装のために繰り返されます。 結局、全く正しいというわけではない実装は実装の始発ほど寛容でない他の実装を出くわします。 読者は、何が次に起こるかを理解できるべきです。
Accordingly, explicit consistency checks in a protocol are very useful, even if they impose implementation overhead.
それに従って、実装オーバーヘッドを課しても、プロトコルにおける明白な一貫性チェックは非常に役に立ちます。
Rose Informational [Page 16] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[16ページ]のRFC3117
5. The BXXP Framework
5. BXXPフレームワーク
Finally, we get to the money shot: here's what we did.
最終的に、私たちはお金のショットを始めます: ここに、私たちがしたことがあります。
We defined an application protocol framework called BXXP (the Blocks eXtensible eXchange Protocol). The reason it's a "framework" instead of an application protocol is that we provide all the mechanisms discussed earlier without actually specifying the kind of messages that get exchanged. So, when someone else needs an application protocol that requires connection-oriented, asynchronous interactions, they can start with BXXP. It's then their responsibility to define the last 10% of the application protocol, the part that does, as we say, "the useful work".
私たちはBXXP(Blocks eXtensible eXchangeプロトコル)と呼ばれるアプリケーション・プロトコルフレームワークを定義しました。 それがアプリケーション・プロトコルの代わりに「フレームワーク」である理由は私たちが、より早く実際に交換されるメッセージの種類を指定しないで議論したすべてのメカニズムを提供するということです。 それで、他の誰かが接続指向の、そして、非同期な相互作用を必要とするアプリケーション・プロトコルを必要とすると、それらはBXXPから始まることができます。 次に、アプリケーション・プロトコルの最後の10%を定義するのは、それらの責任です、それがする部分、「実質的な仕事」と、私たちが言うとき。
So, what does BXXP look like?
それで、BXXPは何に似ていますか?
Mechanism BXXP
-------------- ----------------------------------------
Framing counting, with a trailer
メカニズムBXXP-------------- ---------------------------------------- トレーラで重要である縁どり
Encoding MIME, defaulting to text/xml
テキスト/xmlをデフォルトとして、MIMEをコード化します。
Reporting 3-digit and localized textual diagnostic
3ケタを報告して、原文の病気の特徴であるとローカライズされます。
Asynchrony channels
非同期チャンネル
Authentication SASL
認証SASL
Privacy SASL or TLS
プライバシーSASLかTLS
5.1 Framing and Encoding
5.1 縁どりとコード化
Framing in BXXP looks a lot like SMTP or HTTP: there's a command line that identifies the beginning of the frame, then there's a MIME object (headers and body). Unlike SMTP, BXXP uses octet-counting, but unlike HTTP, the command line is where you find the size of the payload. Finally, there's a trailer after the MIME object to aid in detecting framing errors.
BXXPで縁どるのはSMTPかHTTPに大いに似ています: フレームの始まりを特定するコマンドラインがあって、次に、MIMEオブジェクト(ヘッダーとボディー)があります。 SMTPと異なって、BXXPは八重奏勘定を使用しますが、HTTPと異なった、コマンドラインはあなたがペイロードのサイズを見つけるところです。 最終的に、縁どり誤りを検出する際に支援するMIMEオブジェクトの後に、トレーラがあります。
Actually, the command line for BXXP has a lot of information, it tells you:
実際に、多くの情報がBXXPのためのコマンドラインにあるとあなたに言います:
o what kind of message is in this frame;
o メッセージの種類はこのフレームのものです。
o whether there's more to the message than just what's in this frame
(a continuation flag);
o メッセージにちょうどこれにあるもの以上があるか否かに関係なく、(継続旗)を縁どってください。
Rose Informational [Page 17] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[17ページ]のRFC3117
o how to distinguish the message contained in this frame from other
messages (a message number);
o 他のメッセージ(メッセージ番号)とこのフレームに含まれたメッセージをどう区別するか。
o where the payload occurs in the sliding window (a sequence number)
along with how many octets are in the payload of this frame; and,
o いくつの八重奏がこのフレームのペイロードにあるかと共にペイロードが引窓(一連番号)に現れるところ。 そして
o which part of the application should get the message (a channel
number).
o アプリケーションの一部がメッセージ(論理機番)を得るべきです。
(The command line is textual and ends in a CR-LF pair, and the
arguments are separated by a space.)
(コマンドラインは、原文であり、CR-LF組に終わって、議論はスペースによって切り離されます。)
Since you need to know all this stuff to process a frame, we put it all in one easy to parse location. You could probably devise a more efficient encoding, but the command line is a very small part of the frame, so you wouldn't get much bounce from optimizing it. Further, because framing is at the heart of BXXP, the frame format has several consistency checks that catch the majority of programming errors. (The combination of a sequence number, an octet count, and a trailer allows for very robust error detection.)
あなたが、フレームを処理するためにこのすべてのものを知る必要があるので、私たちは位置を分析するためにある小休止にそれのすべてを入れます。 あなたがたぶんより効率的なコード化について工夫できましたが、コマンドラインがフレームの非常に小さい部分であるので、あなたはそれを最適化するのから多くの弾みを得ないでしょう。 縁どりがBXXPの中心にあるので、さらに、フレーム形式にはプログラミング・エラーの大部分を捕らえるいくつかの一貫性チェックがあります。 (一連番号、八重奏カウント、およびトレーラの組み合わせは非常に体力を要している誤り検出を考慮します。)
Another trick is in the headers: because the command line contains all the framing information, the headers may contain minimal MIME information (such as Content-Type). Usually, however, the headers are empty. That's because the BXXP default payload is XML [30]. (Actually, a "Content-Type: text/xml" with binary transfer encoding).
別のトリックはヘッダーにあります: コマンドラインがすべての縁どり情報を含んでいるので、ヘッダーは最小量のMIME情報(コンテントタイプなどの)を含むかもしれません。 しかしながら、通常、ヘッダーは空です。 それはBXXPデフォルトペイロードがXML[30]であるからです。 (実際に2進の転送コード化がある「コンテントタイプ: テキスト/xml」。)
We chose XML as the default because it provides a simple mechanism for nested, textual representations. (Alas, the 822-style encoding doesn't easily support nesting.) By design, XML's nature isn't optimized for compact representations. That's okay because we're focusing on loosely-coupled systems and besides there are efficient XML parsers available. Further, there's a fair amount of anecdotal experience -- and we'll stress the word "anecdotal" -- that if you have any kind of compression (either at the link-layer or during encryption), then XML encodings squeeze down nicely.
それが入れ子にされて、原文の表現に簡単なメカニズムを提供するので、私たちはデフォルトとしてXMLを選びました。 (ああ、822スタイルのコード化は容易に巣篭もりをサポートしません。) 故意に、XMLの自然はコンパクトな表現のために最適化されません。 私たちが弱連結システムに焦点を合わせているので、それはオーケーです、そして、さらに、利用可能な効率的なXMLパーサがあります。 さらに、あなたであるならどんな種類の圧縮(リンクレイヤにおける、または、暗号化間の)も持っている公正な量の事例となる経験(私たちは「逸話」という言葉を強調するつもりである)、下がっている当時のXML encodings圧搾がうまくあります。
Even so, use of XML is probably the most controversial part of BXXP. After all, there are more efficient representations around. We agree, but the real issue isn't efficiency, it's ease of use: there are a lot of people who grok the XML thing and there are a lot of XML tools out there. The pain of recreating this social infrastructure far outweighs any benefits of devising a new representation. So, if the "make" option is too expensive, is there something else we can "buy" besides XML? Well, there's ASN.1/BER (just kidding).
たとえそうだとしても、XMLの使用はたぶんBXXPの最も論議を呼んだ部分です。 結局、より効率的な表現が周囲にあります。 実際の問題が効率でない、私たちは同意しますが、それは使いやすさです: XMLのことを共感させる多くの人々がいます、そして、多くのXMLツールがむこうにあります。 遠くにこの社会的下部構造を休養させる痛みは新しい表現について工夫するどんな利益よりも重いです。 それで、「作成」オプションが高価過ぎるなら、私たちがXML以外に「買うことができる」他の何かがありますか? さて、ASN.1/BER(まさしくからかうこと)があります。
Rose Informational [Page 18] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[18ページ]のRFC3117
In the early days of the SNMP [31], which does use ASN.1, the same issues arose. In the end, the working group agreed that the use of ASN.1 for SNMP was axiomatic, but not because anyone thought that ASN.1 was the most efficient, or the easiest to explain, or even well liked. ASN.1 was given axiomatic status because the working group decided it was not going to spend the next three years explaining an alternative encoding scheme to the developer community.
SNMP[31]の初期では、同じ問題は起こりました。(SNMPはASN.1を使用します)。 結局、ワーキンググループは、ASN.1のSNMPの使用が自明でしたが、最も効率的であるか、最も説明しやすいか、またはよく好かれさえするのが、自明であったのがだれでもそのASN.1を考えたからであるというわけではないと同意しました。 ワーキンググループが、開発者社会に体系をコード化しながら次の3年を代替手段を説明するのに費やさないつもりであると決めたので、自明の状態をASN.1に与えました。
So -- and we apologize for appealing to dogma -- use of XML as the favored encoding scheme in BXXP is axiomatic.
そのように--私たちは、教義に求めたことを謝ります--BXXPの好評なコード化体系としてのXMLの使用は自明です。
5.2 Reporting
5.2 報告
We use 3-digit error codes, with a localized textual diagnostic. (Each peer specifies a preferred ordering of languages.)
私たちはローカライズしている原文の病気の特徴がある3ケタのエラーコードを使用します。 (各同輩は言語の都合のよい注文を指定します。)
In addition, the reply to a message is flagged as either positive or negative. This makes it easy to signal success or failure and allow the receiving peer some freedom in the amount of parsing it wants to do on failure.
さらに、メッセージに関する回答は肯定するか否定するとして旗を揚げられます。 これで、それが失敗でしたがっている構文解析の量で成否に合図して、受信同輩に何らかの自由を許容するのは簡単になります。
5.3 Asynchrony
5.3 非同期
Despite the lessons of SMTP and HTTP, there isn't a lot of field experience to rely on when designing the asynchrony features of BXXP. (Actually, there were several efforts in 1998 related to application layer framing, e.g., [32], but none appear to have achieved orbit.)
SMTPとHTTPのレッスンにもかかわらず、BXXPの非同期機能を設計するとき依存する多くの実地経験がありません。 (実際に、1998年に応用層縁どりに関連したいくつかの取り組みがありました、例えば、[32]にもかかわらず、なにも軌道を達成したように見えません。)
So, here's what we did: frames are exchanged in the context of a "channel". Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged over a channel.
それで、ここに、私たちがしたことがあります: 「チャンネル」の文脈でフレームを交換します。 各チャンネルには、チャンネルの上と交換されたメッセージの構文と意味論を定義する関連「プロフィール」があります。
Channels provide both an extensibility mechanism for BXXP and the basis for parallelism. Remember the last parameter in the command line of a BXXP frame? The "part of the application" that gets the message is identified by a channel number.
チャンネルはBXXPのための伸展性メカニズムと平行関係の基礎の両方を提供します。 BXXPフレームのコマンドラインにおける最後のパラメタを覚えていますか? 意味を了解する「アプリケーションの一部」は論理機番によって特定されます。
A profile is defined according to a "Profile Registration" template. The template defines how the profile is identified (using a URI [33]), what kind of messages get exchanged, along with the syntax and semantics of those messages. When you create a channel, you identify a profile and maybe piggyback your first message. If the channel is successfully created, you get back a positive response; otherwise, you get back a negative response explaining why.
「プロフィール登録」テンプレートに従って、プロフィールは定義されます。 テンプレートは、プロフィールがどのように特定されるかを定義します。(それらのメッセージのURI[33])、構文と共にどういうメッセージを交換するか、そして、および意味論を使用します。 チャンネルを創造するとき、あなたは、プロフィールを特定して、多分最初のメッセージを背負います。 チャンネルが首尾よく創造されるなら、あなたは積極的な応答を取り戻します。 さもなければ、あなたは理由がわかる否定応答を取り戻します。
Perhaps the easiest way to see how channels provide an extensibility mechanism is to consider what happens when a session is established. Each BXXP peer immediately sends a greeting on channel zero
チャンネルがどう伸展性メカニズムを提供するかを見る恐らく最も簡単な方法はセッションが確立されるとき、何が起こるかを考えることです。 それぞれのBXXP同輩はすぐに、チャンネルにおける挨拶にゼロを送ります。
Rose Informational [Page 19] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[19ページ]のRFC3117
identifying the profiles that each support. (Channel 0 is used for channel management -- it's automatically created when a session is opened.) If you want transport security, the very first thing you do is to create a channel that negotiates transport security, and, once the channel is created, you tell it to do its thing. Next, if you want to authenticate, you create a channel that performs user authentication, and, once the channel is created, you tell it to get busy. At this point, you create one or more channels for data exchange. This process is called "tuning"; once you've tuned the session, you start using the data exchange channels to do "the useful work".
それぞれが支えるプロフィールを特定します。 (チャンネル0はチャンネル管理に使用されます--セッションが開かれるとき、それは自動的に作成されます。) あなたが輸送セキュリティが欲しいなら、あなたがするまさしくその最初のことが輸送セキュリティを交渉するチャンネルを創造することであり、チャンネルがいったん創造されると、あなたは、自分のやりたいことをやるようにそれに言います。 あなたがそうしたがっている次、認証、あなたはユーザー認証を実行するチャンネルを創造して、チャンネルがいったん創造されると、すぐに取りかかるようにそれに言います。 ここに、あなたはデータ交換のための1個以上のチャンネルを創造します。 このプロセスは「チューニング」と呼ばれます。 いったんセッションを調整すると、あなたは、「実質的な仕事」をするのにデータ交換チャンネルを使用し始めます。
The first channel that's successfully started has a trick associated with it: when you ask to start the channel, you're allowed to specify a "service name" that goes with it. This allows a server with multiple configurations to select one based on the client's suggestion. (A useful analogy is HTTP 1.1's "Host:" header.) If the server accepts the "service name", then this configuration is used for the rest of the session.
第1代首尾よく始まったチャンネルはそれに関連しているトリックを持っています: チャンネルを始動するように頼むとき、あなたはそれを伴う「サービス名」を指定できます。 これで、複数の構成があるサーバはクライアントの提案に基づいて1つを選択できます。 (役に立つ類推は「以下を接待してください」というHTTP1.1のヘッダーです。) サーバが「サービス名」を受け入れるなら、この構成はセッションの残りに使用されます。
To allow parallelism, BXXP allows you to use multiple channels simultaneously. Each channel processes messages serially, but there are no constraints on the processing order for different channels. So, in a multi-threaded implementation, each channel maps to its own thread.
平行関係を許容するために、BXXPはあなたに同時に、複数のチャンネルを使用させます。 各チャンネルは順次メッセージを処理しますが、異なったチャンネルの処理命令には規制が全くありません。 それで、マルチスレッド化された実装では、各チャンネルは自分自身のへのスレッドを写像します。
This is the most general case, of course. For one reason or another, an implementor may not be able to support this. So, BXXP allows for both positive and negative replies when a message is sent. So, if you want the classic client/server model, the client program should simply reject any new message sent by the server. This effectively throttles any asynchronous messages from the server.
これが最も一般的なそうである、もちろん。 理由か別のもの、個人的には、作成者はこれをサポートすることができないかもしれません。 それで、メッセージを送るとき、BXXPは積極的なものと同様に否定的な回答を考慮します。 それで、あなたが古典的なクライアント/サーバモデルが欲しいなら、クライアントプログラムは単にサーバによって送られたどんな新しいメッセージも拒絶するはずです。事実上、これはサーバからのどんな非同期なメッセージも阻止します。
Of course, we now need to provide mechanisms for segmentation and flow control. For the former, we just put a "continuation" or "more to come" flag in the command line for the frame. For the latter, we introduced the notion of a "transport mapping".
もちろん、私たちは現在、分割とフロー制御にメカニズムを提供する必要があります。 前者のために、私たちがただ「継続」を置くか、または「来る以上」はフレームへのコマンドラインで弛みます。 後者のために、私たちは「輸送マッピング」の概念を紹介しました。
What this means is that BXXP doesn't directly define how it sits of top of TCP. Instead, it lists a bunch of requirements for how a transport service needs to support a BXXP session. Then, in a separate document, we defined how you can use TCP to meet these requirements.
これが意味することはBXXPが直接TCPの先端についてどう座るかを定義しないということです。 代わりに、それは輸送サービスが、どうBXXPセッションをサポートする必要があるか多くの要件をリストアップします。 そして、別々のドキュメントでは、私たちはあなたがこれらの必要条件を満たすのにどうTCPを使用できるかを定義しました。
This second document pretty much says "use TCP directly", except that it introduces a flow control mechanism for multiplexing channels over a single TCP connection. The mechanism we use is the same one used
この2番目のドキュメントには「直接TCPを使用してください」とほとんど書かれています、マルチプレクシングチャンネルのために単独のTCP接続にフロー制御メカニズムを取り入れるのを除いて。 私たちが使用するメカニズムは使用される同じ1つです。
Rose Informational [Page 20] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[20ページ]のRFC3117
by TCP (sequence numbers and a sliding window). It's proven, and can be trivially implemented by a minimal implementation of BXXP.
TCP(一連番号と引窓)。 それを立証して、BXXPの最小限の器具で些細なことに実装することができます。
The introduction of flow control is a burden from an implementation perspective -- although TCP's mechanism is conceptually simple, an implementor must take great care. For example, issues such as priorities, queue management, and the like should be addressed. Regardless, we feel that the benefits of allowing parallelism for intra-application streams is worth it. (Besides, our belief is that few application implementors will actually code the BXXP framework directly -- rather, we expect them to use third-party packages that implement BXXP.)
フロー制御の導入は実装見解からの負担です--TCPのメカニズムは概念的に簡単ですが、作成者は高度の注意を取らなければなりません。 例えば、プライオリティや、待ち行列管理や、同様のものなどの問題は扱われるべきです。 不注意に、私たちは、イントラアプリケーションストリームのための平行関係を許容する利益はそれの価値があると感じます。 (そのうえ、私たちの信念はわずかなアプリケーション作成者しか実際に直接BXXPフレームワークをコード化しないということです--むしろ、私たちは、彼らがBXXPを実装する第三者パッケージを使用すると予想します。)
5.4 Authentication
5.4 認証
We use SASL. If you successfully authenticate using a channel, then there is a single user identity for each peer on that session (i.e., authentication is per-session, not per-channel). This design decision mandates that each session correspond to a single user regardless of how many channels are open on that session. One reason why this is important is that it allows service provisioning, such as quality of service (e.g., as in [34]) to be done on a per-user granularity.
私たちはSASLを使用します。 あなたが首尾よくaがチャネルを開設する使用を認証するなら、そのセッションでの各同輩のためのシングルユーザーのアイデンティティがあります(すなわち、認証はチャンネルではなく、セッションです)。 このデザイン決定は、いくつのチャンネルがそのセッションのときにオープンであるかにかかわらず各セッションがシングルユーザーに文通されるのを強制します。 これが重要である1つの理由はサービスの食糧を供給することを許すということです、サービスの質などのように。(例えば、1ユーザあたり1つの粒状で行われる[34])のように。
5.5 Privacy
5.5 プライバシー
We use SASL and TLS. If you successfully complete a transport security negotiation using a channel, then all traffic on that session is secured (i.e., confidentiality is per-session, not per- channel, just like authentication).
私たちはSASLとTLSを使用します。 あなたがチャンネルを使用することで輸送セキュリティ交渉を首尾よく終了するなら、そのセッションでのすべてのトラフィックを保証します。(すなわち、秘密性がセッション単位である、-、チャンネル、まさしく同様の認証)
We defined a BXXP profile that's used to start the TLS engine.
私たちはTLSエンジンを始動するのに使用したBXXPプロフィールを定義しました。
5.6 Things We Left Out
5.6 私たちが置いたもの
We purposefully excluded two things that are common to most application protocols: naming and authorization.
私たちは故意にほとんどのアプリケーション・プロトコルに共通の2つのものを除きました: 命名と承認。
Naming was excluded from the framework because, outside of URIs, there isn't a commonly accepted framework for naming things. To our view, this remains a domain-specific problem for each application protocol. Maybe URIs are appropriate in the context of a particularly problem domain, maybe not. So, when an application protocol designer defines their own profile to do "the useful work", they'll have to deal with naming issues themselves. BXXP provides a mechanism for identifying profiles and binding them to channels. It's up to you to define the profile and use the channel.
ことを命名するための一般的に受け入れられたフレームワークがURIの外にないので、命名はフレームワークから除かれました。 私たちの視点に、これは各アプリケーション・プロトコルのためのドメイン特有の問題のままで残っています。 多分、URIはaの文脈で適切です。特に問題ドメイン、そうでないかもしれない。 それで、アプリケーション・プロトコルデザイナーが「実質的な仕事」をするためにそれら自身のプロフィールを定義するとき、彼らは命名問題自体に対処しなければならないでしょう。 BXXPはプロフィールを特定して、チャンネルにそれらを縛るのにメカニズムを提供します。 プロフィールを定義して、チャンネルを使用するのは、あなた次第です。
Rose Informational [Page 21] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[21ページ]のRFC3117
Similarly, authorization was explicitly excluded from the framework. Every approach to authorization we've seen uses names to identify principals (i.e., targets and subjects), so if a framework doesn't include naming, it can't very well include authorization.
同様に、承認はフレームワークから明らかに除かれました。 私たちが見た承認へのあらゆるアプローチが主体(すなわち、目標と対象)を特定するのに名前を使用するので、フレームワークが、命名するのを含んでいないなら、それはそれほど承認をよく含むことができません。
Of course, application protocols do have to deal with naming and authorization -- those are two of the issues addressed by the applications protocol designer when defining a profile for use with BXXP.
もちろん、アプリケーション・プロトコルは命名と承認に対処しなければなりません--それらはBXXPとの使用のためのプロフィールを定義するときアプリケーションプロトコルデザイナーによって扱われた2つの問題です。
5.7 From Framework to Protocol
5.7 フレームワークからプロトコルまで
So, how do you go about using BXXP? To begin, call it "BEEP", not "BXXP" (we'll explain why momentarily).
それで、あなたは、BXXPを使用することでどのように動き回りますか? 始まるには、それを「BXXPではなく、ビープ音」と呼んでください(私たちはしばらく理由について説明するつもりです)。
First, get the BEEP core specification [35] and read it. Next, define your own profile. Finally, get one of the open source SDKs (in C, Java, or Tcl) and start coding.
まず最初に、BEEPコア仕様[35]を得てください、そして、それを読んでください。 次に、あなた自身のプロフィールを定義してください。 最終的に、オープンソースSDKs(C、Java、またはTclの)の1つを手に入れてください、そして、コード化を始めてください。
The BEEP specification defines several profiles itself: a channel management profile, a family of profiles for SASL, and a transport security profile. In addition, there's a second specification [36] that explains how a BEEP session maps onto a single TCP connection.
BEEP仕様自体は数個のプロフィールを定義します: チャンネル管理プロフィール、SASLのためのプロフィールのファミリー、および輸送セキュリティプロフィール。 その方法がわかる2番目の仕様[36]があります。BEEPセッションは単独のTCP接続に写像します。
For a complete example of an application protocol defined using BEEP, look at reliable syslog [37]. This document exemplifies the formula:
BEEPを使用することで定義されたアプリケーション・プロトコルの完全な例がないかどうか、信頼できるsyslog[37]を見てください。 このドキュメントは公式を例示します:
application protocol = BEEP + 1 or more profiles
+ authorization policies
+ provisioning rules (e.g., use of SRV RRs [38])
アプリケーション・プロトコルはBEEP+1以上プロフィール+承認の方針+食糧を供給する規則と等しいです。(例えば、SRV RRs[38])の使用
Rose Informational [Page 22] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[22ページ]のRFC3117
6. BXXP is now BEEP
6. 現在、BXXPはBEEPです。
We started work on BXXP in the fall of 1998. The IETF formed a working group on BXXP in the summer of 2000. Although the working group made some enhancements to BXXP, three are the most notable:
私たちは1998年秋にBXXPで就業しました。 IETFは2000年夏にワーキンググループをBXXPに形成しました。 ワーキンググループはいくつかの増進をBXXPにしましたが、3は最も注目に値します:
o The payload default is "application/octet-stream". This is
primarily for wire-efficiency -- if you care about wire-
efficiency, then you probably wouldn't be using "text/xml"...
o ペイロードデフォルトは「八重奏アプリケーション/ストリーム」です。 これは主としてワイヤ効率のためのものです--ワイヤ効率を心配するなら、あなたはたぶん「テキスト/xml」を使用していないでしょう…
o One-to-many exchanges are supported (the client sends one message
and the server sends back many replies).
o 多くへの1回の交換がサポートされます(クライアントは1つのメッセージを送ります、そして、サーバは多くの回答を返送します)。
o BXXP is now called BEEP (more comic possibilities).
o BXXPは現在、BEEP(より面白い可能性)と呼ばれます。
7. Security Considerations
7. セキュリティ問題
Consult Section [35]'s Section 8 for a discussion of BEEP-related security issues.
相談してください。BEEP関連の安全保障問題の議論のためのセクション[35]によるセクション8です。
Rose Informational [Page 23] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[23ページ]のRFC3117
References
参照
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[2] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[3] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[3] バーナーズ・リー、T.、フィールディング、R.、およびH.ニールセン、「ハイパーテキストはプロトコルを移します--HTTP/1インチ、RFC1945、1996年5月。」
[4] Herriot, R., "Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
[4] エリオ、R.、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[5]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[6] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[6] フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[7] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[8] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[8]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[9] Microsystems, Sun., "NFS: Network File System Protocol
specification", RFC 1094, March 1989.
[9] マイクロシステムズ、日曜日、「NFS:」 「ネットワークファイルシステムプロトコル仕様」、RFC1094、1989年3月。
[10] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[10]SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[11] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[11] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[12] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
そして、[12] バーナーズ・リー、T.、D.コノリー、「2インチ、RFC1866、1995年ハイパーテキストマークアップランゲージ--11月。」
[13] Freed, N., "SMTP Service Extension for Returning Enhanced Error
Codes", RFC 2034, October 1996.
解放された[13]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[14] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
December 1994.
[14] マイアーズ、J.、「IMAP4認証機構」、RFC1731、1994年12月。
[15] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
2197, September 1997.
解放された[15]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、RFC2197、1997年9月。
Rose Informational [Page 24] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[24ページ]のRFC3117
[16] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer
Protocol", RFC 2660, August 1999.
[16] レスコラとE.とA.シフマン、「安全なハイパーテキスト転送プロトコル」、RFC2660、1999年8月。
[17] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[17] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[18] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998.
[18] ニューマン、C.、「1つの時間パスワードSASLメカニズム」、RFC2444、1998年10月。
[19] Myers, J., "SMTP Service Extension for Authentication", RFC
2554, March 1999.
[19] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[20] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[20] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[21] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[21] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[22] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[22] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[23] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[23] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[24] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS",
RFC 2487, January 1999.
[24] ホフマン、P.、「TLSの上の安全なSMTPのためのSMTPサービス拡張子」、RFC2487、1999年1月。
[25] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[25] ニューマン、C.、「IMAP、POP3、およびACAPとTLSを使用します」、RFC2595、1999年6月。
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996.
[26] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[27] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J.
and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[27] ブレーデンとB.とクラークとD.とクロウクロフトとJ.とデイビーとB.とデアリングとS.とEstrinとD.とフロイドとS.とジェーコブソンとV.とMinshallとG.とヤマウズラとC.とピーターソンとL.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(1998年4月)。
[28] Touch, J., "TCP Control Block Interdependence", RFC 2140, April
1997.
[28] 接触、J.、「TCP制御ブロック相互依存」、RFC2140、1997年4月。
[29] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, May 1983.
[29] ポステルとJ.とJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854、1983年5月。
Rose Informational [Page 25] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[25ページ]のRFC3117
[30] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
xml-19980210>.
[30]ワールドワイドウェブコンソーシアム、「拡張マークアップ言語(XML)1インチ、W3C XML1998年2月、<http://www.w3.org/TR/1998/REC- xml-19980210>。」
[31] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990.
[31] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびC.デーヴィン(「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157)は1990がそうするかもしれません。
[32] World Wide Web Consortium, "SMUX Protocol Specification",
Working Draft, July 1998, <http://www.w3.org/TR/1998/WD-mux-
19980710>.
[32]ワールドワイドウェブコンソーシアム、「SMUXプロトコル仕様」、作業草案、1998年7月、<http://www.w3.org/TR/1998/WD-mux19980710>。
[33] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[33]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[34] Waitzman, D., "IP over Avian Carriers with Quality of Service",
RFC 2549, April 1999.
[34]Waitzman、1999年4月のD.、「サービスの質がある鳥のキャリヤーの上のIP」RFC2549。
[35] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[35] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[36] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[36] M. ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日
[37] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195,
November 2001.
2001年11月の[37]新しいD.とM.ローズ、「syslogのための信頼できるDelivery」RFC3195。
[38] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[38]GulbrandsenとA.とVixieとP.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。
[39] <http://mappa.mundi.net/cartography/Wheel/>
[39] <http://mappa.mundi.net/cartography/Wheel/>。
Author's Address
作者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
Inc.POB255268サクラメント、カリフォルニア95865-5268米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 8878年の916 483メール: mrose@dbc.mtview.ca.us
Rose Informational [Page 26] RFC 3117 On the Design of Application Protocols November 2001
アプリケーション・プロトコル2001年11月のデザインのローズ情報[26ページ]のRFC3117
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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機能のための基金は現在、インターネット協会によって提供されます。
Rose Informational [Page 27]
ローズInformationalです。[27ページ]
一覧
スポンサーリンク
