Network Working Group M. Rose
Request for Comments: 3117 Dover Beach Consulting, Inc.
Category: Informational November 2001
On the Design of Application Protocols
Status of this 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.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
このメモは、ブロック拡張可能交換プロトコル（BXXP）のための設計原理を説明します。 BXXPはコネクション型、非同期相互作用のための汎用アプリケーション・プロトコル・フレームワークです。フレームワークは、テキストとバイナリメッセージの両方をサポートする、単一のアプリケーションのユーザ識別のコンテキスト内で同時かつ独立の交換を可能にします。
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
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]完璧なアプリケーションプロトコルであることに近いです：それはミニマルな方法で大規模な、重要な問題を解決します。これは、堅牢で競争の激しい市場で非常に強力な製品提供の基礎を形成するために、コードの一つまたは二つの画面に収まるように、エントリレベルの実装のための十分なシンプル、かつ十分な柔軟性です。モジュロ数奇妙（例えば、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.
SMTPは、もともと1981年に出版されたし、その時以来、アプリケーションプロトコルの多くは、インターネットのために設計されてきたが、起こって再利用の多くがなかった。残念ながら、一つの小さな問題があります。ほとんどが、実際の内容が大幅に変化しても、その機能の動作中に驚くほど似ています：アプリケーションプロトコルはすべて根本的に異なっていたが、これが当てはまらない場合は、これを期待するかもしれません。
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年末には、我々はブロックを交換するためのプロトコルを持っているために必要なことに気づきました。従来の知恵は、アプリケーションプロトコルを必要とするとき、続行する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 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.
例えば、ほとんどのアプリケーションプロトコルは、クライアント/サーバの動作に向け、およびサーバーからデータを引っ張って、クライアントを強調しています。ブロックとは対照的に、クライアントは通常、サーバからデータを引き出し、それはまた、非同期的に（新しい）データをプッシュするためにサーバーを要求することができます。明らかに、我々は我々が望んでいたものに、[2]やSMTP、FTPなどのプロトコルを変異させることができますが、我々はすべてのことをした時点で、基本プロトコルと私たちのプロトコルは類似点よりも相違点を持っているでしょう。換言すれば、既製の実装を変更することのコストはゼロから始めると同等となります。
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.
別のアプローチは、交換プロトコルとして[3] HTTPを使用し、その上でのデータ交換のためのルールを定義することです。例えば、IPP [4]（インターネット印刷プロトコル）は、このアプローチを使用します。基本的な考え方は、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.
残念ながら私たちのためにもHTTP 1.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.
HTTP 1.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のフレーミングメカニズムは、要求/応答モデルのビューに対して非常に硬質であるということです。
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.
第三の選択肢は、電子メールの上にプロトコルを重ね、魅力的でした。残念ながら、私たちのアプリケーションの性質は、比較的小さな応答時間との対話を多く含んでいます。ゼロからのプロトコルを定義する：だから、これは私たちに、最終的な選択肢を残しました。
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.")
開始するには、我々は我々の要求することを考え出し、最もよりも少し厳しいながら、将来のアプリケーションプロトコルの数が多いために適したフレームワーク内に収まることができます。トリックは、キッチンシンクアプローチを避けるためです。 （デイブ・クラークは言っています「アーキテクチャの役割の一つは、あなたが行うことができない何を伝えることですが」）
...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.
第二に、我々は、メッセージ指向のアプリケーションプロトコルを検討するつもりです。 「メッセージ」 - 私たちの辞書では - 単にデータが疎結合システム間で交換構成されています。分類で別のブランチ、密結合システムは、交換パラダイムとしてリモート・プロシージャ・コールを使用しています。コネクション型/コネクション二分法とは異なり、loosely-又は密結合システムの問題は、連続スペクトルに類似しています。幸いなことに、エッジはかなり鋭いです。
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] RPCを使用して、密結合システムです。適切に構成された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 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.
その上でかなりの数の既存のアプリケーション、例えば、我々の要求に適合していないドメイン、（DNS経由で）ネームサービス、（NFS経由）fileservice、このような分散ビデオ会議などのマルチキャスト対応アプリケーション、およびがあります。しかし、これらの要件に適合しないアプリケーションドメイン、例えば、電子メール、ファイル転送、リモートシェル、およびワールドワイドウェブがたくさんあります。だから、私たちは今後に配置されているの賭けは、私たちのフレームワーク内に収まるようなプロトコルを定義するための理由があるように続けることです。
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:
次のステップは、アプリケーションプロトコルが実行しなければならないタスクを見ることですし、それはそれらを実行についてはどのようになります。徹底的な博覧会はダースを識別（あるいはそう）の領域かもしれませんが、私たちが興味を持っているものは以下のとおりです。
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.
このリストの著しい欠如は、命名された - 私たちはなぜ後で説明します。
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ピアがメッセージを送信するとき、それは最初の「DATA」コマンドを送信し、それは、それがメッセージ送信送信します「」 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: 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.
オクテットカウントを使用するプロトコルの一例は、HTTPです。 HTTPのコマンドは、ヘッダとボディ続くリクエスト行から成ります。ヘッダーには、体がどのように大示すオクテット数が含まれています。オクテットカウントの性質は、オクテットスタッフィングの逆です：あなたがメッセージ全体の長さを知っておく必要がありますメッセージの送信を開始することができますが、送信を開始したら、メッセージの内容を見てする必要はありません前に、または受信。
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未満言う）小さい、各メッセージのための接続を確立するためのオーバーヘッドは、データ交換の間に有意な待ち時間に寄与する。
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を使用して交換[11] 822スタイルを使用して符号化されます。 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]のための検索機構と見なされるが、それは、それは、そのほとんどがHTMLページ又はGIFファイルとして参照されるオブジェクトのいずれかであり、実際にMIMEを使用して符号化オブジェクトの検索機構です。
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;
最初の桁：永続的または一過性のいずれか、成功または失敗を示します。
the second digit: indicating the part of the system reporting the situation (e.g., the syntax analyzer); and,
第二桁：状況（例えば、構文解析）を報告システムの一部を示します。そして、
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]第二及び第三の位置で起こり得る値の数を拡張するための便利なメカニズムを提供します。
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応答コードは、診断関連するテキストは、エンドユーザー、管理者、またはプログラマ宛であるかどうかを指定していません。
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 produce systems that don't handle pipelining properly; typically, an error in a request causes subsequent requests in the pipeline to be discarded).
いくつかのアプリケーションプロトコル今日は、同じ接続を介して独立したやりとりを可能にします。実際には、より広く実装のアプローチは、SMTPまたはHTTP 1.1で永続的な接続でパイプライン、例えば、コマンドパイプライン[15]を可能にすることです。パイプラインは、クライアントがサーバの複数の要求を行うことができますが、連続的に処理することを要求する必要があります。 （明示的な指導なしに、多くの実装者が適切にパイプライン処理しないシステムを製造、以来プロトコルは、明示的にパイプラインのサポートを提供する必要があることに注意してください。一般的に、要求におけるエラーは、パイプライン内の後続の要求を破棄する）。
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.
あなたは並列処理を許可する場合残念ながら、あなたはまた、飢餓やデッドロックを回避するために、フロー制御メカニズムが必要です。そうでない場合は、交換の単一のセットは、トランスポート層によって提供される帯域幅を独占することができます。ピアがリソース不足であればさらに、それはメッセージとデッドロックの結果を受け取るために十分なバッファを持っていないかもしれません。
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シーケンス番号とスライディングウィンドウを使用して各受信機は、さらに、許可を受信する前に送信されてもよいデータオクテットの数を示すスライディングウィンドウを管理します。セグメンテーション：しかし、それは今でドロップする第二の靴のための時間です。あなたはフロー制御を行う場合、あなたはまた、送信する前に小さな部分にメッセージを断片化し、その後、彼らが受けているとして、それらを組み立て直すためのセグメンテーションメカニズムが必要です。
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.
別の方法でフレーミングセグメンテーションの影響 - それはあなたがそれを送信する前にメッセージ全体の長さを知っている必要がオクテットカウントの要件を緩和します。セグメンテーションを使用すると、メッセージ全体が使用可能になる前のセグメントの送信を開始することができます。 HTTP 1.1では、あなたは「チャンク」（セグメント）のデータは、この利点を取得することができます。
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.)
おそらく、歴史的な（あるいはヒステリー）の理由から、ほとんどのアプリケーションプロトコルは、認証を行いません。つまり、彼らは、接続または交換されるメッセージの信憑性にピアのIDを認証しません。認証が行われている場合は、それはプロトコルごとにドメイン固有です。例えば、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]（簡易認証セキュリティー層）は、プロトコルピアを認証するためのフレームワークを提供するために開発されました。 SASLを使用すると、認証機構は、例えば、OTP [18]（ワンタイムパスワード）交換をどのように動作するかを説明しましょう。これは、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、[20]です。特定のレース状態を回避するためもののSASLは、HTTPに導入することができなかった理由を少し理由がありますが、HTTP 1.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は、IDを認証するために、明示的なプロトコル交換に加えて、その中に興味深い機能を持っている、それはまた、下の層から提供された暗黙の情報を使用することができます。接続は、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メカニズムに応じて、使用されている、メッセージの完全性やプライバシーのサービスも提供することができます。
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]（アプリケーション設定アクセスプロトコル）が利用可能です。
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つのポート（平文トラフィック用と安全な交通のための他）で待機します。使用、接続が確立されると、平文トラフィックのための単一のポートでリッスンし、（例えば、[24]と[25]）とは対照的に、今日の慣習によって、TLS対応として指定されているアプリケーションプロトコルを実装するサーバーその接続上の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の両方が、「トランスポート・セキュリティ」ではなく「オブジェクトセキュリティ」についてであることに注意してください。これが意味することは、彼らが実際の通信のセキュリティプロパティを提供することに焦点を当てることで、彼らはデータのための任意のセキュリティプロパティは、通信とは独立して交換していません。
Let's briefly compare the properties of the three main connection-oriented application protocols in use today:
のは、簡単に使用中の三つの主要な接続指向アプリケーション・プロトコル今日の性質を比較してみましょう：
Mechanism ESMTP FTP HTTP1.1
-------------- ----------- --------- -------------
Framing stuffing blasting counting
Encoding 822-style binary MIME
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のようにオクテットカウントを使用し、。
When we design an application protocol, there are a few properties that we should keep an eye on.
我々はアプリケーションプロトコルを設計するとき、私たちは目を維持する必要がありますいくつかのプロパティがあります。
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]でプロビジョニングされています。さらに、提案はまた、[28]、例えば、同時学習を減らすためにTCP実装の変更のために検討されています。
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.
サーバーの観点では、それぞれの着信接続を派遣する必要があり、（おそらく）同じリソースに対して認証します。確立された接続の数ではなく、リモート・ユーザの数に基づいて、その結果、サーバーのオーバーヘッドが増加します。公正のと同じ問題が発生する：ユーザーがサーバー上のポンドへの接続の任意の数を引き起こすことができるときのサーバーは、ユーザーごとにリソースを割り当てすることがはるかに困難です。
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.
考慮すべきスケーラビリティのもう一つの重要な側面は、クライアントとサーバの相対的な数字です。 （これも、ピアは、クライアントとサーバーの役割の両方に作用することができるピア・ツー・ピアモデルで真である。）一般的に、サーバーのピアよりも多くのクライアントピアがあります。この場合は、機能要件は、クライアント上にサーバから移行すべき。その理由は、サーバが複数のクライアントとの相互作用する可能性があるということであり、この機能シフトが拡大することが容易になります。
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）はテキストヘッダーを使用します。我々が使用することができ、ヘッダ名と値を制限して喜んでいたならば、私たちは確かに、ヘッダーのためのより効率的な表現を定義することができます。この場合、拡張性、効率よりも重要と見られています。私たちは、ネットワークプロトコルの代わりに、アプリケーションプロトコルを設計していた場合はもちろん、我々は異なるエッジでカミソリを使ってトレードオフを作ると思います。
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.
親指の別のルールは、アプリケーションプロトコルがまったく同じことをやって二つの方法がある場合は、どこかのアプリケーションプロトコルの設計の基礎となるアーキテクチャに問題があるということです。
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.
問題のドメイン内のすべて、縁でさえ面倒な事を収容し、よく設計されています何か：うまくいけば、シンプルで簡単な志向を意味するものではありません。どのようなデザインが簡単になりますと、それは一貫した方法でこれを行うことです。一般的に、これは、エレガントなデザインにつながります。
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.
アプリケーションプロトコルの設計者がそうであるように巧妙なように、アプリケーションプロトコルが解決するように要求されることを予期しない問題がある可能性が高いです。だから、それは機能を追加したり、動作をカスタマイズするために使用することができますフックを提供することが重要です。これは、プロトコルが進化であることを意味し、そして使用される拡張ネゴシエートする進化経路における異なる段階を反映し実装するための方法がなければなりません。
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]などの難設計されたプロトコルは、拡張の概念を中心に構築されることなく機能することができません。
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.
したがって、プロトコルでの明示的な整合性チェックは、彼らは、実装のオーバーヘッドを課した場合でも、非常に便利です。
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（ブロック拡張可能交換プロトコル）と呼ばれるアプリケーションプロトコルのフレームワークを定義しました。それは、「フレームワーク」の代わりに、アプリケーションプロトコルだ理由は、私たちが実際に交換され得るメッセージの種類を指定せずに先に述べたすべてのメカニズムを提供するということです。だから、他の誰かが接続指向、非同期対話を必要とするアプリケーションプロトコルを必要とするとき、彼らはBXXPで始めることができます。これは、アプリケーションプロトコルの最後の10％を定義するための責任、私たちが言うように、ない部分、「有用な作業」です。
So, what does BXXP look like?
だから、何BXXPは見えますか？
Mechanism BXXP
-------------- ----------------------------------------
Framing counting, with a trailer
Encoding MIME, defaulting to text/xml
text / xmlでの不履行、MIMEをコードします
Reporting 3-digit and localized textual diagnostic
3桁およびローカライズされたテキストの診断を報告
Asynchrony channels
非同期チャンネル
Authentication SASL
認証SASL
Privacy SASL or TLS
プライバシーSASLやTLS
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;
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.)
あなたは、フレームを処理するために、すべてのこのようなものを知っている必要がありますので、我々は1つの解析しやすい場所にすべてを置きます。あなたは、おそらく、より効率的な符号化を考案することができますが、コマンドラインは、フレームのごく一部ですので、あなたはそれを最適化するから多くのバウンスを得ないでしょう。フレーミングが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).
もう一つのトリックはヘッダーである：コマンドラインは、すべてのフレーミング情報が含まれているため、ヘッダは、（Content-Typeのような）最小限のMIME情報が含まれていてもよいです。しかしながら、通常、ヘッダは空です。 BXXPのデフォルトのペイロードがXML [30]があるからです。 （実際には、「コンテンツタイプ：text / 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エンコーディングがうまくダウン絞ること。
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があります。
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.
ASN.1を使用しSNMP [31]、の初期の頃には、同じ問題が生じました。最後に、ワーキンググループは、SNMPのためのASN.1の使用は自明だったことに合意したが、誰もが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を使用することは自明です。
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.
加えて、メッセージへの応答は、正または負のいずれかとしてフラグが立てられます。これは、成功または失敗を通知し、受信側は、それが失敗した場合に何をしたいの解析の量にある程度の自由度をピア許可することが容易になります。
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 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".
おそらく、チャネルは拡張メカニズムを提供方法を確認する最も簡単な方法は、セッションが確立されたときに何が起こるかを検討することです。各BXXPピアは直ちにプロファイル各支持を識別するチャネルゼロに挨拶を送信します。 （チャネル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.
正常に起動しています最初のチャネルは、それに関連付けられたトリックを持っている：あなたは、チャネルを開始するために要求したとき、あなたはそれで行く「サービス名」を指定することができます。これは、複数の構成を持つサーバーがクライアントの提案に基づいていずれかを選択することができます。 （便利なアナロジーは、HTTP 1.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.
これが意味することは、TCPの上で座っているかBXXPが直接定義していないということです。代わりに、トランスポートサービスが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 by TCP (sequence numbers and a sliding window). It's proven, and can be trivially implemented by a minimal implementation of BXXP.
この第2の文書はかなりそれが単一のTCP接続を介して多重チャンネルのためのフロー制御メカニズムを導入していることを除いて、「直接TCPを使う」と言います。私たちが使用するメカニズムは、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を実装するサードパーティ製のパッケージを使用することを期待しています。）
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を使用しています。あなたが成功したチャンネルを使用して認証する場合は、そのセッション上の各ピアのための単一のユーザアイデンティティがある（すなわち、認証はセッションごとではなく、チャネルあたりのです）。各セッションは関係なく、どのように多くのチャネルの単一のユーザーに対応し、この設計上の決定の義務は、そのセッションで開いています。これが重要である理由の一つは、それがそのようなサービスの品質のようなサービスのプロビジョニングは、（例えば、[34]のように）ユーザごとの粒度で行われることを可能にすることです。
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プロファイルを定義しました。
We purposefully excluded two things that are common to most application protocols: naming and authorization.
命名と承認：私たちは意図的に、ほとんどのアプリケーションプロトコルに共通する二つのことを除外します。
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は、特に問題ドメインのコンテキストで適切かもしれません。アプリケーションプロトコルの設計者が「役に立つ仕事を」行うために、独自のプロファイルを定義するときに、彼らは問題を自ら命名に対処する必要があります。 BXXPは、プロファイルを識別し、チャネルにそれらを結合するための機構を提供します。これは、プロファイルを定義し、チャネルを使用するのはあなた次第です。
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つです。
So, how do you go about using BXXP? To begin, call it "BEEP", not "BXXP" (we'll explain why momentarily).
だから、どのようにBXXPを使用して行くのですか？開始するには、「BEEP」ではなく、「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]を取得し、それを読んで。次に、独自のプロファイルを定義します。最後に、（C、Javaの、またはTclで）オープンソースのSDKの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.
チャンネル管理プロファイル、SASLのプロファイルの家族、およびトランスポート・セキュリティ・プロファイル：BEEPの仕様では、複数のプロファイル自体を定義します。また、第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のRRの使用[38]）
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:
私たちは、ワーキンググループがBXXPに、いくつかの機能強化を行ったが、IETFは、2000年の夏にBXXPにワーキンググループを形成し、1998年の秋に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ペイロードデフォルトが "application / octet-stream" です。これは主に、ワイヤー効率のためである - あなたは、ワイヤ効率を心配している場合、あなたはおそらく「text / xmlで」を使用してではないでしょう...
o One-to-many exchanges are supported (the client sends one message and the server sends back many replies).
一対多交換がサポートされていますO（クライアントは、一つのメッセージを送信し、サーバーは、多くの回答を送り返し）。
o BXXP is now called BEEP (more comic possibilities).
O BXXPは現在、BEEP（もっと漫画の可能性）と呼ばれています。
Consult Section [35]'s Section 8 for a discussion of BEEP-related security issues.
BEEP関連のセキュリティ問題の議論のためのセクション[35]のセクション8を参照してください。
References
リファレンス
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[2]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、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.0"、RFC 1945、1996年5月。
[4] Herriot, R., "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[4]ヘリオット、R.、 "インターネット印刷プロトコル/ 1.0：コード化とTransport"、RFC 2565、1999年4月。
[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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、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.、ゲティス、J.、モーグル、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[8] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[9] Microsystems, Sun., "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[9]マイクロ、日、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月を。
[10] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[10] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[11]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[12] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[12]バーナーズ=リー、T.、およびD.コノリー、 "ハイパーテキストマークアップ言語 - 2.0"、RFC 1866、1995年11月。
[13] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[13]、RFC 2034、1996年10月 "拡張エラーコードを返すためのSMTPサービス拡張"、N.、フリード。
[14] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, December 1994.
[14]マイヤーズ、J.、 "IMAP4認証メカニズム"、RFC 1731、1994年12月。
[15] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[15]フリード、N.、 "コマンドパイプラインのためのSMTPサービス拡張"、RFC 2197、1997年9月。
[16] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[16]レスコラ、E.、およびA.シフマン、 "セキュアハイパーテキスト転送プロトコル"、RFC 2660、1999年8月。
[17] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[17]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[18] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, October 1998.
[18]ニューマン、C.、 "ワンタイムパスワードのSASLメカニズム"、RFC 2444、1998年10月。
[19] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[19]マイヤーズ、J.、 "認証のためのSMTPサービス拡張"、RFC 2554、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認証：基本とダイジェストアクセス認証"、 RFC 2617、1999年6月。
[21] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[21]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[22] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[22]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[23] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[23]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[24] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[24]ホフマン、P.、 "TLSの上にセキュアなSMTPのためのSMTPサービス拡張"、RFC 2487、1999年1月。
[25] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[25]ニューマン、C.、RFC 2595 "IMAP、POP3、およびACAPとTLSの使用"、1999年6月。
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[26]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、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.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[28] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[28]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[29] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[29]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[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.0"、W3C XML、1998年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）"、STD 15、RFC 1157、1990年5月。
[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-mux-19980710>。
[33] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[33]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[34] Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC 2549, April 1999.
[34] Waitzman、D.、 "サービスの品質を持つ鳥類キャリアによるIP"、RFC 2549、1999年4月。
[35] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[35]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[36] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[36]ローズ、M.、 "TCP上にBEEPコアのマッピング"、RFC 3081、2001年3月。
[37] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001.
[37]新しい、D.とM.ローズ、 "syslogのための信頼性の高い配信"、RFC 3195、2001年11月。
[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 RR（DNSのSRV）"、RFC 2782、2000年2月。
[39] <http://mappa.mundi.net/cartography/Wheel/>
「３９」 ＜ｈっｔｐ：／／まっぱ。むんぢ。ねｔ／かｒとｇらｐｈｙ／うぇえｌ／＞
Author's Address
著者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング株式会社POB 255268サクラメント、CA 95865から5268米
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
電話：+1 916 483 8878 Eメール：mrose@dbc.mtview.ca.us
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。