[要約] RFC 3117は、アプリケーションプロトコルの設計に関するガイドラインを提供しています。その目的は、効果的なアプリケーションプロトコルの設計と実装を促進することです。
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.
Copyright（c）The Internet Society（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]は、完璧なアプリケーションプロトコルに近いものです。これは、ミニマルな方法で大きくて重要な問題を解決します。エントリーレベルの実装がコードの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つの小さな問題があります。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年後半、Carl Malamudと私が座ってブロックアーキテクチャをレビューしていたため、ブロックを交換するためのプロトコルが必要であることに気付きました。従来の知恵は、アプリケーションプロトコルが必要な場合、続行する4つの方法があるということです。
1. find an existing exchange protocol that (more or less) does what you want;
1. （多かれ少なかれ）必要なことを行う既存のExchangeプロトコルを見つけます。
2. define an exchange model on top of the world-wide web infrastructure that (more or less) does what you want;
2. （多かれ少なかれ）必要なことを行う世界的なWebインフラストラクチャの上に、交換モデルを定義します。
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.
最も魅力的なオプションは、既存のプロトコルを見つけてそれを使用することです。（言い換えれば、「make」よりも「購入」したいと思います。）したがって、既存の多くのアプリケーションプロトコルの調査を行いましたが、それらのどれも必要なプロトコルのセマンティクスに適していないことがわかりました。
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.
たとえば、ほとんどのアプリケーションプロトコルは、クライアント/サーバーの動作に向けられており、クライアントがサーバーからデータを引き出すことを強調しています。ブロックとは対照的に、クライアントは通常、サーバーからデータをプルしますが、サーバーに非同期的に（新しい）データをプッシュするように要求する場合があります。明らかに、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]をExchangeプロトコルとして使用し、それをめぐるデータ交換のルールを定義することです。たとえば、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のもう1つの良い点は、データをエンコードするために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.
IPPをHTTP 1.1にマッピングすると、前者の問題を示しています。たとえば、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.
電子メールの上にプロトコルを重ねる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つは、あなたができないことを伝えることです。」）
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]の上で動作するもの）のみを検討します。Connectionlessの分類の別のブランチは、信頼できるストリームの確立と維持の遅延またはオーバーヘッドを望まないもので構成されています。たとえば、ほとんどの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.
第二に、メッセージ指向のアプリケーションプロトコルのみを検討します。「メッセージ」 - レキシコンでは、緩やかに結合されたシステム間で交換される構造化されたデータです。分類法の別のブランチ、厳密に結合されたシステムは、リモートプロシージャコールをExchangeパラダイムとして使用します。接続指向/コネクションレスの二分法とは異なり、ゆるいまたは密着したシステムの問題は、連続的なスペクトルに似ています。幸いなことに、エッジはかなりシャープです。
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つのピアが「クライアント」であり、もう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経由）、Fileservice（NFS経由）、分散ビデオ会議などのマルチキャスト対応アプリケーションなどがあります。ただし、これらの要件、たとえば電子メール、ファイル転送、リモートシェル、世界中のWebに適合するアプリケーションドメインはたくさんあります。したがって、私たちが今後も掲載しているのは、フレームワークに適合するプロトコルを定義する理由が引き続きあるということです。
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:
次のステップは、アプリケーションプロトコルが実行する必要があるタスクと、それらの実行方法を確認することです。徹底的な博覧会は12の（またはそれ以下の）領域を特定するかもしれませんが、私たちが興味を持っている領域は次のとおりです。
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ピアがメッセージを送信すると、最初に「データ」コマンドを送信し、次にメッセージを送信してから「」を送信します。（ドット）CR-LFが続きます。メッセージにドットで始まる行が含まれている場合、送信SMTPピアは2つのドットを送信します。同様に、他のSMTPピアがドットで始まる線を受け取ると、ドットを破棄し、ラインが空の場合、メッセージ全体を受け取ったことがわかります。Octet-Stuffingには、送信を開始する前にメッセージ全体が必要ではないというプロパティがあります。残念ながら、送信者と受信機の両方がメッセージの各行をスキャンして、変換する必要があるかどうかを確認する必要があるため、遅いです。
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.
Octetカウントを使用するプロトコルの例は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接続が確立されます。Octetカウントと接続ブラストの両方に、メッセージが任意のバイナリデータになる可能性があるというプロパティがあります。ただし、接続ブラストアプローチの欠点は、ピアがIPアドレスとTCPポート番号を通信する必要があることです。これは、NAT [10]およびネットワークバグによって「透過的に」変更される可能性があります。さらに、交換されているメッセージが小さい場合（たとえば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を使用して交換されたメッセージは、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スタイルのアプリケーションであるMIMEを使用して、データ自体（ボディ）とデータに関する情報（ヘッダー）の両方をエンコードします。つまり、HTTPは一般にHTMLの検索メカニズムとして見られますが[12]、MIMEを使用してエンコードされたオブジェクトの検索メカニズムであり、そのほとんどはHTMLページまたはGIFなどの参照オブジェクトのいずれかです。
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,
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 返信コードでは、関連するテキスト診断がエンドユーザー、管理者、またはプログラマー向けであるかどうかを指定していません。
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のコマンドパイプライン[15]またはHTTP 1.1の永続的な接続を許可することです。パイプライニングにより、クライアントはサーバーの複数のリクエストを行うことができますが、リクエストをシュタリーで処理する必要があります。（プロトコルは、明示的なガイダンスなしでは、多くの実装者がパイプラインを適切に処理しないシステムを生成するため、パイプラインのサポートを明示的に提供する必要があることに注意してください。通常、リクエストのエラーにより、パイプラインの後続の要求が廃棄されます）。
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.
残念ながら、並列処理を許可する場合、飢starやデッドロックを避けるためのフロー制御メカニズムも必要です。それ以外の場合、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.
セグメンテーションは、別の方法でフレーミングに影響を与えます - それは、メッセージを送信する前に、メッセージ全体の長さを知る必要があるというオクテットカウント要件を緩和します。セグメンテーションを使用すると、メッセージ全体が利用可能になる前にセグメントの送信を開始できます。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.)
おそらく、歴史的な（またはヒステリックな）理由のために、ほとんどのアプリケーションプロトコルは認証を行いません。つまり、交換されるメッセージの接続に関するピアのアイデンティティまたは信頼性を認証しません。または、認証が行われた場合、各プロトコルに対してドメイン固有です。たとえば、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]（1回限りのパスワード）交換を説明しましょう。次に、各プロトコルデザイナー次第で、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には、アイデンティティを認証するための明示的なプロトコル交換に加えて、以下のレイヤーから提供される暗黙の情報を使用することができるという点で、興味深い機能があります。たとえば、接続が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の重要な違いは、テクノロジーではなくプロビジョニングの1つです。プロビジョニングへの元のアプローチでは、世界的なWebサーバーが2つのポートに耳を傾けます（1つはプレーンテキストトラフィック用、もう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とTLの両方が「オブジェクトセキュリティ」ではなく「輸送セキュリティ」に関するものであることに注意してください。これが意味することは、彼らが実際の通信のためにセキュリティプロパティを提供することに焦点を合わせているということです。彼らは、通信とは無関係に交換されたデータのセキュリティプロパティを提供しません。
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
Encoding 822-style binary MIME
822スタイルのバイナリマイムをエンコードします
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（nee 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]はOctet stuffingを使用しますが、IMAPはOctetカウントなどを使用します。
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は接続を確立する際にスロースタートアルゴリズムを使用するため、これはネットワークに不必要なトラフィックスパイクを導入するだけでなく、プログラムにはさらに遅延が表示されるためです。アプリケーションプロトコルに非同期が不足しているため、実装者が輸送層をずさんに使用するという事実に対処するために、ネットワークプロトコルは、たとえば赤の高度化でプロビジョニングされています[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.
サーバーに関しては、各着信接続を発送し、（おそらく）同じリソースに対して（おそらく）認証する必要があります。その結果、サーバーのオーバーヘッドは、リモートユーザーの数ではなく、確立された接続の数に基づいて増加します。同じ公平性の問題が発生します。ユーザーがサーバーで任意の数の接続を引き起こす可能性がある場合、サーバーがユーザーごとにリソースを割り当てることははるかに困難です。
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.
考慮すべきスケーラビリティのもう1つの重要な側面は、クライアントとサーバーの相対的な数です。（これは、ピアツーピアモデルでも当てはまります。ピアは、クライアントとサーバーの役割の両方で行動できます。）通常、サーバーのピアよりも多くのクライアントピアがあります。この場合、機能要件はサーバーからクライアントにシフトする必要があります。その理由は、サーバーが複数のクライアントと対話している可能性が高く、この機能的なシフトにより拡張が容易になるためです。
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.
別の経験則は、アプリケーションプロトコルにまったく同じことを行う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.
うまくいけば、シンプルな意味はシンプルな意味ではありません。適切に設計されたものは、問題ドメインのすべて、端の厄介なものでさえも対応します。デザインをシンプルにしているのは、これを一貫した方法で行うことです。通常、これはエレガントなデザインにつながります。
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.
直感に反して、Postelの堅牢性の原則（「あなたが送るもので保守的であり、あなたが受け入れるものではリベラルである」）は、しばしば展開の問題につながります。なぜ？新しい実装が最初にフィールドされた場合、既存の実装のサブセットのみに遭遇する可能性があります。これらの実装が堅牢性の原則に従うと、新しい実装のエラーは検出されない可能性があります。その後、新しい実装では、広範囲にわたる展開ではありません。このプロセスは、いくつかの新しい実装について繰り返されます。最終的に、完全ではない正しい実装は、最初の実装セットよりもリベラルではない他の実装に登場します。読者は、次に何が起こるかを理解できるはずです。
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
マイムのエンコード、デフォルトのテキスト/XML
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はOctetカウントを使用しますが、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).
別のトリックはヘッダーにあります。コマンドラインにすべてのフレーミング情報が含まれているため、ヘッダーには最小限のMIME情報（コンテンツタイプなど）が含まれる場合があります。ただし、通常、ヘッダーは空です。これは、BXXPデフォルトペイロードがXMLであるためです[30]。（実際、バイナリ転送エンコードを備えた「コンテンツタイプ：テキスト/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のことをgloった人がたくさんいて、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が最も効率的であるか、説明するのが最も簡単であるか、さらにはよく好まれていると誰もが考えたからではありません。ASN.1には、ワーキンググループが開発者コミュニティに代替エンコーディングスキームを説明するために今後3年間は費やさないと判断したため、公理的状態が与えられました。
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.
これが意味することは、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 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を使用します。チャネルを使用して認証を正常に認証すると、そのセッションに各ピアに単一のユーザーIDがあります（つまり、認証はチャネルごとではなくセッションごとです）。この設計上の決定は、各セッションがそのセッションで開いているチャネルの数に関係なく、単一のユーザーに対応することを義務付けています。これが重要である理由の1つは、サービス品質（[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.
ほとんどのアプリケーションプロトコルに共通の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の外では、物事を命名するための一般的に受け入れられているフレームワークはないからです。私たちの見解では、これは各アプリケーションプロトコルのドメイン固有の問題のままです。たぶん、ウリスは特に問題のあるドメインのコンテキストで適切であるかもしれませんが、そうではないかもしれません。したがって、アプリケーションプロトコルデザイナーが「有用な作業」を行うために独自のプロファイルを定義する場合、命名の問題に対処する必要があります。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をどのように使用しますか？まず、「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.
まず、ビープコア仕様[35]を取得して読んでください。次に、独自のプロファイルを定義します。最後に、オープンソースSDKの1つ（C、Java、またはTCL）を取得し、コーディングを開始します。
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のプロファイルファミリ、輸送セキュリティプロファイルです。さらに、ビープ音が単一のTCP接続にどのようにマッピングされるかを説明する2番目の仕様[36]があります。
For a complete example of an application protocol defined using BEEP, look at reliable syslog [37]. This document exemplifies the formula:
ビープ音を使用して定義されたアプリケーションプロトコルの完全な例については、信頼性の高い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]）
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のワーキンググループを形成しました。
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は現在、ビープ音と呼ばれています（より漫画の可能性）。
Consult Section [35]'s Section 8 for a discussion of BEEP-related security issues.
ビープ関連のセキュリティ問題の議論については、セクション[35]のセクション8を参照してください。
References
参考文献
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[2] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[2] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、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] Berners-Lee、T.、Fielding、R。and H. Nielsen、「HyperText Transfer Protocol-HTTP/1.0」、RFC 1945、1996年5月。
[4] Herriot, R., "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[4] Herriot、R。、「インターネット印刷プロトコル/1.0：エンコードとトランスポート」、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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7] Postel、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] Microsystems、Sun.、「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. Holdrege、「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] Crocker、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] Berners -Lee、T。およびD. Connolly、「HyperText Markup Language -2.0」、RFC 1866、1995年11月。
[13] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[13] Freed、N。、「強化されたエラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[14] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, December 1994.
[14] Myers、J。、「IMAP4認証メカニズム」、RFC 1731、1994年12月。
[15] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[15] Freed、N。、「コマンドパイプラインのSMTPサービス拡張」、RFC 2197、1997年9月。
[16] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[16] Rescorla、E。and A. Schiffman、「The Secure HyperText Transfer Protocol」、RFC 2660、1999年8月。
[17] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[17] Myers、J。、「Simple Authentication and Security Layer（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] Myers、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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[21] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[21] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[22] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[22] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[23] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[23] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[24] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[24] Hoffman、P。、「TLSを超える安全なSMTPのSMTPサービス拡張」、RFC 2487、1999年1月。
[25] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[25] ニューマン、C。、「IMAP、POP3およびACAPでTLSを使用」、RFC 2595、1999年6月。
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[26] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン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] 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、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[28] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[28] Touch、J。、「TCP制御ブロック相互依存」、RFC 2140、1997年4月。
[29] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[29] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、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] World Wide Webコンソーシアム、「拡張可能なマークアップ言語（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] Case、J.、Fedor、M.、Schoffstall、M。and C. Davin、「Simple Network Management Protocol（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] World Wide Webコンソーシアム、「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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[36] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[36] Rose、M。、「ビープコアをTCPにマッピング」、RFC 3081、2001年3月。
[37] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001.
[37] New、D。およびM. Rose、「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。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、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.ローズドーバービーチコンサルティング、Inc。POB 255268サクラメント、CA 95865-5268 US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。