Network Working Group M. Rose
Request For Comments: 3080 Invisible Worlds, Inc.
Category: Standards Track March 2001
The Blocks Extensible Exchange Protocol Core
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.
このメモは、接続指向のための一般的なアプリケーションプロトコルカーネルを説明し、非同期の相互作用は、BEEP（ブロック拡張可能交換プロトコル）コアと呼ばれます。 BEEPは、テキストとバイナリメッセージの両方をサポートする、単一のアプリケーションのユーザ識別のコンテキスト内で同時かつ独立の交換を可能にします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. The BEEP Core . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6
2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14
2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 17
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 23
2.4 Session Establishment and Release . . . . . . . . . . . . 25
2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 27
2.6 Asynchrony . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 28
2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 28
2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 29
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 30
3. Transport Security . . . . . . . . . . . . . . . . . . . . 31
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 34
3.1.1 Profile Identification and Initialization . . . . . . . . 34
3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 36
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 36
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 36
4. User Authentication . . . . . . . . . . . . . . . . . . . 37
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 38
4.1.1 Profile Identification and Initialization . . . . . . . . 39
4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 43
5. Registration Templates . . . . . . . . . . . . . . . . . . 44
5.1 Profile Registration Template . . . . . . . . . . . . . . 44
5.2 Feature Registration Template . . . . . . . . . . . . . . 44
6. Initial Registrations . . . . . . . . . . . . . . . . . . 45
6.1 Registration: BEEP Channel Management . . . . . . . . . . 45
6.2 Registration: TLS Transport Security Profile . . . . . . . 45
6.3 Registration: SASL Family of Profiles . . . . . . . . . . 46
6.4 Registration: application/beep+xml . . . . . . . . . . . . 47
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 48
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 50
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 51
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . 53
References . . . . . . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . 55
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 57
Full Copyright Statement . . . . . . . . . . . . . . . . . 58
This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called BEEP.
このメモは、BEEPと呼ばれる接続指向、非同期相互作用のための一般的なアプリケーションプロトコルカーネルを説明します。
At BEEP's core is a framing mechanism that permits simultaneous and independent exchanges of messages between peers. Messages are arbitrary MIME [1] content, but are usually textual (structured using XML [2]).
BEEPのコアでは、ピア間のメッセージの同時かつ独立した交流を可能フレーミングメカニズムです。メッセージは、任意のMIME [1]の内容であるが、通常のテキストである（XMLを用いて構成[2]）。
All exchanges occur in the context of a channel -- a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange.
全ての交換は、チャネルの文脈で発生 - そのようなトランスポート・セキュリティ、ユーザ認証、またはデータ交換として、アプリケーションの明確に定義された局面に結合します。
Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BEEP is the notion of channel management. In addition to defining BEEP's channel management profile, this document defines:
各チャネルは、構文と交換されたメッセージの意味を定義する関連する「プロファイル」を持っています。 BEEPの操作で暗黙のチャネル管理の概念があります。 BEEPのチャネル管理プロファイルを定義するだけで、この文書では定義しています。
o the TLS [3] transport security profile; and,
TLS [3]のトランスポート・セキュリティ・プロファイルO。そして、
o the SASL [4] family of profiles.
O SASL [4]プロファイルの家族。
Other profiles, such as those used for data exchange, are defined by an application protocol designer.
このようなデータ交換のために使用されるような他のプロファイルは、アプリケーションプロトコル設計者によって定義されています。
A BEEP session is mapped onto an underlying transport service. A separate series of documents describe how a particular transport service realizes a BEEP session. For example, [5] describes how a BEEP session is mapped onto a single TCP [6] connection.
BEEPセッションは、基礎となるトランスポートサービス上にマッピングされます。文書の別のシリーズでは、特定のトランスポートサービスがBEEPセッションを実現する方法について説明します。例えば、[5] BEEPセッションは、単一のTCP [6]の接続にマッピングする方法を記載しています。
When a session is established, each BEEP peer advertises the profiles it supports. Later on, during the creation of a channel, the client supplies one or more proposed profiles for that channel. If the server creates the channel, it selects one of the profiles and sends it in a reply; otherwise, it may indicate that none of the profiles are acceptable, and decline creation of the channel.
セッションが確立されると、各BEEPピアは、それがサポートするプロファイルをアドバタイズします。その後、チャネルの作成中に、クライアントはそのチャネルに1つのまたは複数の提案のプロファイルを提供しています。サーバはチャンネルを作成する場合は、プロファイルの1つを選択し、応答でそれを送信します。それ以外の場合は、プロファイルのいずれも許容されないことを示し、およびチャネルの作成を低下する可能性があります。
Channel usage falls into one of two categories:
チャネルの使用は、2つのカテゴリのいずれかに分類されます。
initial tuning: these are used by profiles that perform initialization once the BEEP session is established (e.g., negotiating the use of transport security); although several exchanges may be required to perform the initialization, these channels become inactive early in the BEEP session and remain so for the duration.
初期チューニング：これらはBEEPセッションが確立されると初期化を実行プロファイルによって使用される（例えば、トランスポート・セキュリティの使用を交渉します）。いくつかの交換は初期化を実行するために必要とすることができるが、これらのチャネルは、初期のBEEPセッションで非アクティブになると持続時間のためにそう残ります。
continuous: these are used by profiles that support data exchange; typically, these channels are created after the initial tuning channels have gone quiet.
連続：これらは、データ交換をサポートするプロファイルによって使用されます。初期チューニングチャンネルは静かに消えた後に、通常、これらのチャネルが作成されます。
Note that because of their special nature, only one tuning channel may be established at any given time; in contrast, BEEP allows multiple data exchange channels to be simultaneously in use.
なぜなら彼らの特別な性質の、唯一のチューニングチャネルは、任意の時点で確立されてもよいことに注意してください。対照的に、BEEPは、複数のデータ交換チャネルが使用中で同時にすることを可能にします。
Although BEEP is peer-to-peer, it is convenient to label each peer in the context of the role it is performing at a given time:
BEEPは、ピア・ツー・ピアではあるが、与えられた時間にそれが実行される役割の文脈で各ピアにラベルを付けると便利です。
o When a BEEP session is established, the peer that awaits new connections is acting in the listening role, and the other peer, which establishes a connection to the listener, is acting in the initiating role. In the examples which follow, these are referred to as "L:" and "I:", respectively.
BEEPセッションが確立されると、O、新しい接続を待ち受けるピアはリスニングの役割で行動している、そしてリスナーへの接続を確立し、他のピアは、開始、役割で行動しています。 「L：」以下の実施例では、これらはと呼ばれ、「I」、それぞれ。
o A BEEP peer starting an exchange is termed the client; similarly, the other BEEP peer is termed the server. In the examples which follow, these are referred to as "C:" and "S:", respectively.
O交換を開始するBEEPピアは、クライアントと呼ばれています。同様に、他のBEEPピアはサーバーと呼ばれています。そして：以下の実施例では、これらを「C」と呼ばれる「S」、それぞれ。
Typically, a BEEP peer acting in the server role is also acting in a listening role. However, because BEEP is peer-to-peer in nature, no such requirement exists.
一般的に、サーバーの役割で行動するBEEPピアはまた、リスニングの役割で行動しています。 BEEPは、ピアツーピア性質であるためしかし、そのような要件は存在しません。
BEEP allows three styles of exchange:
BEEPは、為替の3つのスタイルを可能にします：
MSG/RPY: the client sends a "MSG" message asking the server to perform some task, the server performs the task and replies with a "RPY" message (termed a positive reply).
MSG / RPY：クライアントは、いくつかのタスクを実行するためにサーバーを尋ねる「MSG」メッセージを送信し、サーバはタスクを実行し、（正の応答と呼ばれる）「RPY」メッセージで応答します。
MSG/ERR: the client sends a "MSG" message, the server does not perform any task and replies with an "ERR" message (termed a negative reply).
MSG / ERR：クライアントは、「MSG」メッセージを送信し、サーバは「ERR」メッセージで任意のタスクおよび応答を実行しません（負の応答と呼ばれます）。
MSG/ANS: the client sends a "MSG" message, the server, during the course of performing some task, replies with zero or more "ANS" messages, and, upon completion of the task, sends a "NUL" message, which signifies the end of the reply.
MSG / ANS：クライアントは、「MSG」メッセージを送信し、サーバー、いくつかのタスクを実行する過程で、ゼロまたはそれ以上の「ANS」メッセージで応答し、そして、タスクが完了すると、「NUL」メッセージを送信し、リプライの終わりを意味します。
The first two styles are termed one-to-one exchanges, whilst the third style is termed a one-to-many exchange.
第三スタイルは1対多の交換と呼ばれながら、最初の2つのスタイルは、一対一の交流と呼ばれます。
A message is structured according to the rules of MIME. Accordingly, each message may begin with "entity-headers" (c.f., MIME's Section 3 [1]). If none, or only some, of the "entity-headers" are present:
メッセージは、MIMEのルールに従って構造化されます。従って、各メッセージは、「エンティティヘッダ」（C.F.、MIMEの第3 [1]）で開始することができます。なし、または一部だけ、「エンティティヘッダ」の場合は、存在しています：
o the default "Content-Type" is "application/octet-stream"; and,
Oデフォルトの "Content-Type" は "application / octet-stream" です。そして、
o the default "Content-Transfer-Encoding" is "binary".
デフォルトo「のコンテンツ転送エンコードは、」「バイナリ」です。
Normally, a message is sent in a single frame. However, it may be convenient or necessary to segment a message into multiple frames (e.g., if only part of a message is ready to be sent).
通常、メッセージは単一のフレームで送信されます。 （メッセージの一部のみを送信する準備ができている場合、例えば、）しかし、それは複数のフレームにメッセージセグメントに好都合であるかまたは必要であり得ます。
Each frame consists of a header, the payload, and a trailer. The header and trailer are each represented using printable ASCII characters and are terminated with a CRLF pair. Between the header and the trailer is the payload, consisting of zero or more octets.
各フレームは、ヘッダ、ペイロード、およびトレーラから成ります。ヘッダとトレーラは、各印刷可能なASCII文字を使用して表され、CRLFペアで終了されます。ヘッダとトレーラとの間に、ゼロ以上のオクテットからなるペイロードです。
For example, here is a message contained in a single frame that contains a payload of 120 octets spread over 5 lines (each line is terminated with a CRLF pair):
例えば、ここに5行（各行はCRLFペアで終了される）に広がっ120オクテットのペイロードを含む単一フレームに含まれるメッセージです。
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
In this example, note that the entire message is represented in a single frame.
この例では、メッセージ全体が単一のフレームで表現されることに注意してください。
The ABNF [7] for a frame is:
ABNFは、[7]のフレームのためのものです。
frame = data / mapping
フレーム=データ/マッピング
data = header payload trailer
データ=ヘッダペイロードトレーラ
header = msg / rpy / err / ans / nul
ヘッダ= MSG / RPY / ERR /年/ヌル
msg = "MSG" SP common CR LF rpy = "RPY" SP common CR LF ans = "ANS" SP common SP ansno CR LF err = "ERR" SP common CR LF nul = "NUL" SP common CR LF
MSG = "MSG" SP共通CR LFのRPYは= "RPY" SP共通CR LF ANS = "ANS" SP共通SP ansno CR LFは= "ERR" SP共通CR LF NUL = "NUL" SP共通CR LFを誤ります
common = channel SP msgno SP more SP seqno SP size channel = 0..2147483647 msgno = 0..2147483647 more = "." / "*" seqno = 0..4294967295 size = 0..2147483647 ansno = 0..2147483647
共通=チャネルのSPのmsgno SPよりSPのSEQNO SPサイズチャンネル= 0 2147483647 MSGNO = 0 2147483647以上= "" / "*" SEQNO = 0 4294967295サイズ= 0 2147483647 ansno = 0 2147483647
payload = *OCTET
ペイロード= * OCTET
trailer = "END" CR LF
トレーラー= "END" CR LF
mapping = ;; each transport mapping may define additional frames
マッピング= ;;各トランスポート・マッピングは、追加のフレームを定義することができます
The frame header consists of a three-character keyword (one of: "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more parameters. A single space character (decimal code 32, " ") separates each component. The header is terminated with a CRLF pair.
ゼロ以上のパラメータ、続いて：フレームヘッダは、3文字のキーワード（「MSG」、「RPY」、「ERR」、「ANS」、または「NUL」のいずれか）からなります。単一の空白文字（十進コード32は、 "「）各成分を分離します。ヘッダはCRLFペアで終了されます。
The channel number ("channel") must be a non-negative integer (in the range 0..2147483647).
チャンネル番号（「チャネル」）（範囲0 2147483647 IN）非負整数でなければなりません。
The message number ("msgno") must be a non-negative integer (in the range 0..2147483647) and have a different value than all other "MSG" messages on the same channel for which a reply has not been completely received.
メッセージ番号（「MSGNO」）は、（範囲0 2147483647 IN）非負の整数であり、応答が完全に受信されていないため、同じチャネル上の他のすべての「MSG」メッセージとは異なる値を有していなければなりません。
The continuation indicator ("more", one of: decimal code 42, "*", or decimal code 46, ".") specifies whether this is the final frame of the message:
継続インジケータ（の一つ、「複数」：「」、進コード42、「*」、または10進数46）は、このメッセージの最後のフレームであるかどうかを指定します。
intermediate ("*"): at least one other frame follows for the message; or,
中間体（「*」）：少なくとも一つの他のフレームがメッセージの次。または、
complete ("."): this frame completes the message.
完全な（「」）：このフレームは、メッセージを完了します。
The sequence number ("seqno") must be a non-negative integer (in the range 0..4294967295) and specifies the sequence number of the first octet in the payload, for the associated channel (c.f., Section 2.2.1.2).
シーケンス番号（「SEQNO」）は、（範囲0 4294967295 IN）非負の整数であると関連するチャネル（C.F.、セクション2.2.1.2）のために、ペイロード内の最初のオクテットのシーケンス番号を指定しなければなりません。
The payload size ("size") must be a non-negative integer (in the range 0..2147483647) and specifies the exact number of octets in the payload. (This does not include either the header or trailer.)
ペイロードサイズ（「サイズ」）（範囲0 2147483647 IN）非負整数でペイロードのオクテットの正確な数を指定しなければなりません。 （これは、ヘッダ又はトレーラのいずれかを含んでいません。）
Note that a frame may have an empty payload, e.g.,
例えば、フレームが空のペイロードを有していてもよいことに留意されたいです
S: RPY 0 1 * 287 20
S: ...
S: ...
S: END
S: RPY 0 1 . 307 0
S: END
The answer number ("ansno") must be a non-negative integer (in the range 0..4294967295) and must have a different value than all other answers in progress for the message being replied to.
回答数（「ansno」）は、（範囲0 4294967295 IN）非負の整数でなければならず、へ返信されるメッセージのために、進行中のすべての他の回答とは異なる値を有していなければなりません。
There are two kinds of frames: data and mapping. Each transport mapping (c.f., Section 2.5) may define its own frames. For example, [5] defines the SEQ frame. The remainder of this section discusses data frames.
データマッピング：フレームの2種類があります。各トランスポート・マッピング（C.F.、2.5節）は、それ自身のフレームを定義することができます。例えば、[5] SEQフレームを定義します。このセクションの残りの部分は、データフレームを論じています。
When a message is segmented and sent as several frames, those frames must be sent sequentially, without any intervening frames from other messages on the same channel. However, there are two exceptions: first, no restriction is made with respect to the interleaving of frames for other channels; and, second, in a one-to-many exchange, multiple answers may be simultaneously in progress. Accordingly, frames for "ANS" messages may be interleaved on the same channel -- the answer number is used for collation, e.g.,
メッセージがセグメント化といくつかのフレームとして送信される場合、それらのフレームは、同じチャネル上の他のメッセージからの任意の介在フレームなしで、順次送信されなければなりません。しかし、2つの例外がある：まず、制限は、他のチャネルのためのフレームのインターリーブに対して行われません。そして、第二、一対多の交換において、複数回答が進行中で同時にすることができます。したがって、「ANS」メッセージのフレームが同じチャネル上でインターリーブされてもよい - 応答番号を照合するために使用され、例えば、
S: ANS 1 0 * 0 20 0
S: ...
S: ...
S: END
S: ANS 1 0 * 20 20 1
S: ...
S: ...
S: END
S: ANS 1 0 . 40 10 0
S: ...
S: END
which shows two "ANS" messages interleaved on channel 1 as part of a reply to message number 0. Note that the sequence number is advanced for each frame sent on the channel, and is independent of the messages sent in those frames.
そのシーケンス番号がチャネル上で送信されたフレーム毎に高度であり、それらのフレームで送信されたメッセージとは無関係であることを示すメッセージ番号0に注意することは、応答の一部として、チャネル1にインタリーブ二つの「ANS」メッセージを示しています。
There are several rules for identifying poorly-formed frames:
不完全に形成されたフレームを識別するためのいくつかのルールがあります。
o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or "NUL";
Oヘッダは、 "MSG"、 "RPY"、 "ERROR"、 "AND"、または "NUL" で始まらない場合は、
o if any of the parameters in the header cannot be determined or are invalid (i.e., syntactically incorrect);
Oヘッダのパラメータのいずれかが（即ち、構文的に正しくない）を決定することができない、または無効な場合。
o if the value of the channel number doesn't refer to an existing channel;
Oチャンネル番号の値は、既存のチャネルを参照していない場合。
o if the header starts with "MSG", and the message number refers to a "MSG" message that has been completely received but for which a reply has not been completely sent;
Oヘッダは「MSG」で始まり、メッセージ番号が完全に受信されたが、応答が完全に送信されていないため、「MSG」メッセージを参照する場合。
o if the header doesn't start with "MSG", and refers to a message number for which a reply has already been completely received;
Oヘッダは「MSG」で始まり、そして応答が既に完全に受信されたメッセージの数を指していない場合。
o if the header doesn't start with "MSG", and refers to a message number that has never been sent (except during session establishment, c.f., Section 2.3.1.1);
Oヘッダは「MSG」で始まり、そして（セッション確立、C.F.、セクション2.3.1.1時以外）が送信されていないメッセージの数を指していない場合。
o if the header starts with "MSG", "RPY", "ERR", or "ANS", and refers to a message number for which at least one other frame has been received, and the three-character keyword starting this frame and the immediately-previous received frame for this message number are not identical;
Oヘッダは「MSG」、「RPY」、「ERR」、または「ANS」で始まり、そして少なくとも一つの他のフレームが受信されたメッセージの数を指し、そして3文字のキーワードは、このフレームを開始した場合このメッセージ番号の直前の受信フレームが同一ではありません。
o if the header starts with "NUL", and refers to a message number for which at least one other frame has been received, and the keyword of of the immediately-previous received frame for this reply isn't "ANS";
Oヘッダは「NUL」で始まり、そして少なくとも一つの他のフレームが受信されたメッセージの数を意味し、この応答のための直前の受信フレームののキーワードは、「ANS」でない場合、
o if the continuation indicator of the previous frame received on the same channel was intermediate ("*"), and its message number isn't identical to this frame's message number;
O前のフレームの継続インジケータは、同じチャネル上で受信された場合（「*」）中間体であり、そのメッセージ番号は、このフレームのメッセージ番号と同一ではありません。
o if the value of the sequence number doesn't correspond to the expected value for the associated channel (c.f., Section 2.2.1.2); or,
Oシーケンス番号の値は、関連チャネル（C.F.、セクション2.2.1.2）の期待値に対応しない場合、または、
o if the header starts with "NUL", and the continuation indicator is intermediate ("*") or the payload size is non-zero.
Oヘッダは「NUL」で始まり、継続インジケータは、中間体である（「*」）又はペイロードサイズがゼロでない場合。
If a frame is poorly-formed, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
フレームは不完全に形成されている場合、セッションは、応答を生成することなく終了し、そして診断エントリをログに記録することが推奨されます。
The frame payload consists of zero or more octets.
フレームのペイロードは、ゼロ以上のオクテットで構成されています。
Every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a frame is such that the first payload octet is the lowest numbered, and the following payload octets are numbered consecutively. (When a channel is created, the sequence number associated with the first payload octet of the first frame is 0.)
チャネル上の各方向に送信されるすべてのペイロードのオクテットは、関連付けられたシーケンス番号を有しています。フレーム内のペイロードのオクテットの番号付けは、最初のペイロードのオクテットが最も小さい番号であるようであり、そして次のペイロードのオクテットは連続番号が付されています。 （チャネルが作成されると、最初のフレームの最初のペイロードのオクテットに関連付けられたシーケンス番号は0です）
The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult Sections 2 through 5 of [8] for a discussion of the arithmetic properties of sequence numbers.
実際のシーケンス番号空間は0 4294967295（ - 1 2 ** 32）に至るまで、非常に大きいが、有限です。スペースが有限であるため、シーケンス番号を扱う全ての演算を行うモジュロ2 ** 32です。再び1 0 - この符号なしの算術演算は、2 ** 32から彼らサイクルとしてシーケンス番号の関係を維持します。シーケンス番号の演算特性の議論については、[8]の5を介してセクション2を参照してください。
When receiving a frame, the sum of its sequence number and payload size, modulo 4294967296 (2**32), gives the expected sequence number associated with the first payload octet of the next frame received. Accordingly, when receiving a frame if the sequence number isn't the expected value for this channel, then the BEEP peers have lost synchronization, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
フレームを受信した場合、そのシーケンス番号とペイロードサイズ、モジュロ4294967296（2 ** 32）の合計は、次のフレームの最初のペイロードのオクテットに関連付けられている期待シーケンス番号が受信与えます。シーケンス番号は、このチャネルの期待値でない場合、フレームを受信した場合BEEPピアが同期を失っているため、後、セッションが応答を生成することなく終了し、診断エントリが記録されることが推奨されます。
The frame trailer consists of "END" followed by a CRLF pair.
フレームトレーラーがCRLFのペアに続く「END」で構成されています。
When receiving a frame, if the characters immediately following the payload don't correspond to a trailer, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
フレームを受信した場合、すぐにペイロードを以下の文字は、トレーラーに対応しない場合、セッションは応答を生成することなく終了し、そして診断エントリをログに記録することが推奨されます。
The semantics of each message is channel-specific. Accordingly, the profile associated with a channel must define:
各メッセージの意味は、チャネル固有です。従って、チャネルに関連付けられたプロファイルを定義する必要があります。
o the initialization messages, if any, exchanged during channel creation;
初期化メッセージO、もしあれば、チャネルの作成中に交換。
o the messages that may be exchanged in the payload of the channel; and,
チャネルのペイロードに交換され得るメッセージO。そして、
o the semantics of these messages.
これらのメッセージの意味論O。
A profile registration template (Section 5.1) organizes this information.
プロフィール登録テンプレート（セクション5.1）は、この情報を整理します。
When defining the behavior of the profile, the template must specify how poorly-formed "MSG" messages are replied to. For example, the channel management profile sends a negative reply containing an error message (c.f., Section 2.3.1.5).
プロファイルの振る舞いを定義する場合、テンプレートが不十分に形成された「MSG」メッセージがに答えた方法を指定する必要があります。例えば、チャネル管理プロファイルは、エラーメッセージ（C.F.、セクション2.3.1.5）を含む負の応答を送信します。
If a poorly-formed reply is received on channel zero, the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
不完全に形成された応答がチャネルゼロで受信された場合、セッションは、応答を生成することなく終了し、そして診断エントリをログに記録することが推奨されます。
If a poorly-formed reply is received on another channel, then the channel must be closed using the procedure in Section 2.3.1.3.
不完全に形成された応答が別のチャネル上で受信された場合、チャネルは、セクション2.3.1.3の手順を使用して閉鎖されなければなりません。
When a BEEP session starts, only channel number zero is defined, which is used for channel management. Section 6.1 contains the profile registration for BEEP channel management.
BEEPセッションが開始されると、唯一のチャンネル番号ゼロは、チャネルの管理に使用され、定義されます。 6.1節は、BEEPチャネル管理のためのプロファイル登録が含まれています。
Channel management allows each BEEP peer to advertise the profiles that it supports (c.f., Section 2.3.1.1), bind an instance of one of those profiles to a channel (c.f., Section 2.3.1.2), and then later close any channels or release the BEEP session (c.f., Section 2.3.1.3).
チャネル管理は、それが（CF、セクション2.3.1.1）をサポートするプロファイルをアドバタイズする各BEEPピアを可能にする、チャネル（CF、セクション2.3.1.2）にこれらのプロファイルのいずれかのインスタンスを結合し、そしてその後、任意のチャネルまたは放出を閉じBEEPセッション（CF、セクション2.3.1.3）。
A BEEP peer should support at least 257 concurrent channels.
BEEPピアは、少なくとも257個の同時チャネルをサポートする必要があります。
When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero that contains a "greeting" element, e.g.,
BEEPセッションが確立されると、各BEEPピアは、直ちに例えば、「挨拶」要素が含まれているゼロのメッセージ数と正の応答を送信することによって、その可用性を意味します
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
Note that this example implies that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends its greeting -- this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.
この例では、リスニングの役割でBEEPピアはその挨拶を送信するまで開始する役割で、BEEPピアが待機することを意味していることに注意してください - これは、プレゼンテーションのアーティファクトです。実際には、双方のBEEPピアは、独立してその応答を送信します。
The "greeting" element has two optional attributes ("features" and "localize") and zero or more "profile" elements, one for each profile supported by the BEEP peer acting in a server role:
「挨拶」要素は、2つのオプション属性（「機能」および「局在化」）、ゼロ以上の「プロファイル」要素、サーバーロールに作用するBEEPピアによってサポートされる各プロファイルの一つを有します。
o the "features" attribute, if present, contains one or more feature tokens, each indicating an optional feature of the channel management profile supported by the BEEP peer;
O「機能」属性は、存在する場合、一つ以上の特徴トークン、BEEPピアによってサポートされるチャネル管理プロファイルの任意の特徴を示す各含有します。
o the "localize" attribute, if present, contains one or more language tokens (defined in [9]), each identifying a desirable language tag to be used by the remote BEEP peer when generating textual diagnostics for the "close" and "error" elements (the tokens are ordered from most to least desirable); and,
属性「ローカライズ」O、存在する場合、（[9]で定義された）は、1つ以上の言語トークン、「閉じる」および「エラーのテキストの診断を生成する際に、それぞれが遠隔BEEPピアによって使用されることが望ましい言語タグを識別する情報を含んでいます「要素（トークンが最も望ましくに最もから順序付けされます）。そして、
o each "profile" element contained within the "greeting" element identifies a profile, and unlike the "profile" elements that occur within the "start" element, the content of each "profile" element may not contain an optional initialization message.
O「挨拶」要素内に含まれる各「プロファイル」要素は、プロファイルを識別し、「開始」エレメント内で発生する「プロファイル」要素とは異なり、各「プロファイル」元素の含有量は、オプションの初期化メッセージを含んでいてもよいです。
Section 5.2 defines a registration template for optional features.
5.2節は、オプション機能の登録テンプレートを定義します。
When a BEEP peer wants to create a channel, it sends a "start" element on channel zero, e.g.,
BEEPピアは、チャネルを作成したいとき、それは、例えば、チャネルゼロの「スタート」要素を送ります
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
The "start" element has a "number" attribute, an optional "serverName" attribute, and one or more "profile" elements:
「開始」要素は、「番号」属性は、オプションの「serverNameの」属性、および1つ以上の「プロファイル」の要素があります。
o the "number" attribute indicates the channel number (in the range 1..2147483647) used to identify the channel in future messages;
O「番号」属性は将来のメッセージ内のチャネルを識別するために使用される（範囲1 2147483647 IN）チャネル番号を示します。
o the "serverName" attribute, an arbitrary string, indicates the desired server name for this BEEP session; and,
「serverNameの」属性、任意の文字列O、このBEEPセッションのために必要なサーバー名を示します。そして、
o each "profile" element contained with the "start" element has a "uri" attribute, an optional "encoding" attribute, and arbitrary character data as content:
O「開始」要素に含まれる各「プロファイル」要素は、コンテンツとして「URI」属性、任意選択の「コード」属性、および任意の文字データを持っています。
* the "uri" attribute authoritatively identifies the profile;
*「URI」属性は、正式プロファイルを識別します。
* the "encoding" attribute, if present, specifies whether the content of the "profile" element is represented as a base64- encoded string; and,
*「エンコーディング」属性は、存在する場合、「プロファイル」元素の含有量はbase64-エンコードされた文字列として表現されているかどうかを指定します。そして、
* the content of the "profile" element, if present, must be no longer than 4K octets in length and specifies an initialization message given to the channel as soon as it is created.
*「プロファイル」要素の内容は、存在する場合、もはや長さが4Kオクテットよりもとすぐそれが作成されるように、チャンネルに与えられた初期化メッセージを指定する必要があります。
To avoid conflict in assigning channel numbers when requesting the creation of a channel, BEEP peers acting in the initiating role use only positive integers that are odd-numbered; similarly, BEEP peers acting in the listening role use only positive integers that are even-numbered.
チャネルの作成を要求するチャネル番号を割り当てることで、競合を避けるために、開始する役割を使用して奇数のみ正の整数を演技BEEPピア。同様に、BEEPピアはリスニングの役割の使用に偶数のみ正の整数を演技します。
The "serverName" attribute for the first successful "start" element received by a BEEP peer is meaningful for the duration of the BEEP session. If present, the BEEP peer decides whether to operate as the indicated "serverName"; if not, an "error" element is sent in a negative reply.
BEEPピアによって受信された最初の成功した「スタート」要素の「serverNameの」属性はBEEPセッションの持続時間のために有意義です。存在する場合、BEEPピアは示さ「serverNameの」として動作するか否かを判断します。ない場合は、「エラー」の要素は否定応答で送信されます。
When a BEEP peer receives a "start" element on channel zero, it examines each of the proposed profiles, and decides whether to use one of them to create the channel. If so, the appropriate "profile" element is sent in a positive reply; otherwise, an "error" element is sent in a negative reply.
BEEPピアがチャネルゼロの「開始」エレメントを受信すると、提案されたプロファイルの各々を調べ、そしてチャネルを作成するために、それらのいずれかを使用するかどうかを決定します。その場合は、適切な「プロフィール」の要素は、正の応答で送信されます。そうでなければ、「エラー」要素は、負の応答で送信されます。
When creating the channel, the value of the "serverName" attribute from the first successful "start" element is consulted to provide configuration information, e.g., the desired server-side certificate when starting the TLS transport security profile (Section 3.1).
チャネルを作成する場合、最初に成功した「スタート」要素から「serverNameの」属性の値は、例えば、構成情報、TLSトランスポート・セキュリティ・プロファイル（3.1節）を起動所望のサーバ側の証明書を提供するために調べられます。
For example, a successful channel creation might look like this:
例えば、成功したチャンネルの作成は次のようになります。
C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: </start>
C: END
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END
Similarly, an unsuccessful channel creation might look like this:
同様に、失敗したチャンネルの作成は次のようになります。
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='2'>
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
S: ERR 0 1 . 221 127
S: Content-Type: application/beep+xml
S:
S: <error code='501'>number attribute
S: in <start> element must be odd-valued</error>
S: END
Finally, here's an example in which an initialization element is exchanged during channel creation:
最後に、ここで初期化要素は、チャネルの作成時に交換した場合の例です：
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]>
S: </profile>
S: END
When a BEEP peer wants to close a channel, it sends a "close" element on channel zero, e.g.,
BEEPピアがチャネルを閉じることを望むとき、それは、例えば、チャネルゼロの「近い」要素を送信します
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
The "close" element has a "number" attribute, a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content:
属性、およびその内容などの診断オプションのテキスト：「閉」要素は、「番号」属性、「コード」属性、任意「ラングXML」を有します。
o the "number" attribute indicates the channel number;
「番号」O属性は、チャンネル番号を示します。
o the "code" attribute is a three-digit reply code meaningful to programs (c.f., Section 8);
「コード」属性は、プログラム（C.F.、セクション8）に意味のある3桁の応答コードはO。
o the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and,
O「のxml：langの」属性は、（「ローカライズ」リモートBEEPピアによって送信された「挨拶」要素の属性によって義務付けられていない値が提案されていますが、、）要素の内容が書き込まれている言語を識別する。そして、
o the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs.
O診断テキストは、（複数でもよい）、おそらく実装、管理者、およびおそらくはユーザ、決してプログラムに有意義です。
Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used.
属性リモートBEEPピアの最初の選択肢として表示言語が使用されている場合にのみ存在していない：診断のテキストが存在する場合は、「LANG XML」があることに注意してください。
If the value of the "number" attribute is zero, then the BEEP peer wants to release the BEEP session (c.f., Section 2.4) -- otherwise the value of the "number" attribute refers to an existing channel, and the remainder of this section applies.
「番号」属性の値がゼロである場合、BEEPピアがBEEPセッション（CF、2.4節）を放出することを望む - そうでなければ、「数」属性の値は、既存のチャネルを指し、これの残りセクションが適用されます。
A BEEP peer may send a "close" message for a channel whenever all "MSG" messages it has sent on that channel have been acknowledged. (Acknowledgement consists of the first frame of a reply being received by the BEEP peer that sent the MSG "message".)
BEEPピアは、それがそのチャネル上で送信されたすべての「MSG」メッセージが確認されている時はいつでもチャネルのための「クローズ」メッセージを送信することができます。 （謝辞MSG「メッセージを」送信BEEPピアによって受信され、応答の最初のフレームで構成されています。）
After sending the "close" message, that BEEP peer must not send any more "MSG" messages on that channel being closed until the reply to the "close" message has been received (either by an "error" message rejecting the request to close the channel, or by an "ok" message subsequently followed by the channel being successfully started).
「近い」メッセージに対する応答が受信されるまで、「クローズ」メッセージを送信した後、そのBEEPピアは、そのチャネル上の複数の「MSG」メッセージが閉じられて送信してはならない（どちらかの「エラー」メッセージによって要求を拒否することは閉じチャネル、またはその後に正常に起動しているチャンネルに続いて「OK」メッセージ）によります。
NOTE WELL: until a positive reply to the request to close the channel is received, the BEEP peer must be prepared to process any "MSG" messages that it receives on that channel.
よの注：チャネルをクローズするための要求に対する肯定応答が受信されるまで、BEEPピアは、それがそのチャンネルで受信するすべての「MSG」メッセージを処理するために準備する必要があります。
When a BEEP peer receives a "close" message for a channel, it may, at any time, reject the request to close the channel by sending an "error" message in a negative reply.
BEEPピアは、チャネルは、「クローズ」メッセージを受信すると、それは、任意の時点で、負の応答で「エラー」メッセージを送信することによって、チャネルを閉じるために、要求を拒否することができます。
Otherwise, before accepting the request to close the channel, and sending an "ok" message in a positive reply, it must:
それ以外の場合は、チャネルを閉じるように要求を受け付け、正応答で「OK」メッセージを送信する前に、それは次の条件を満たす必要があります。
o finish sending any queued "MSG" messages on that channel of its own;
O任意のは、独自のチャンネルで「MSG」メッセージをキューに入れられた送信終えます。
o await complete replies to any outstanding "MSG" messages it has sent on that channel; and,
Oそれは、そのチャネル上で送信された未処理の「MSG」メッセージへの完全な応答を待ちます。そして、
o finish sending complete replies to any outstanding "MSG" messages it has received on that channel, and ensure that the final frames of those replies have been successfully delivered, i.e.,
O、すなわち、それは、そのチャネル上で受信した未処理の「MSG」メッセージへの完全な応答を送信し終えると、これらの応答の最後のフレームが正常に配信されていることを確認してください
* for transport mappings that guarantee inter-channel ordering of messages, the replies must be sent prior to sending the "ok" message in a positive reply; otherwise,
*メッセージのチャネル間の順序を保証するトランスポート・マッピングのために、応答は肯定応答で「OK」メッセージを送信する前に送信する必要があります。そうでなければ、
* the replies must be sent and subsequently acknowledged by the underlying transport service prior to sending the "ok" message in a positive reply.
*応答が送信され、その後、正の回答に「OK」メッセージを送信する前に基本的な輸送サービスによって確認されなければなりません。
Briefly, a successful channel close might look like this:
簡単に言えば、成功したチャンネルの近くには、次のようになります。
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
S: RPY 0 2 . 392 46
S: Content-Type: application/beep+xml
S:
S: <ok />
S: END
Similarly, an unsuccessful channel close might look like this:
同様に、失敗したチャンネルの近くには、次のようになります。
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
S: ERR 0 2 . 392 79
S: Content-Type: application/beep+xml
S:
S: <error code='550'>still working</error>
S: END
When a BEEP peer agrees to close a channel (or release the BEEP session), it sends an "ok" element in a positive reply.
BEEPピアがチャンネルを閉じる（またはBEEPセッションを解放）することに同意した場合、それは肯定応答で「OK」要素を送信します。
The "ok" element has no attributes and no content.
「OK」要素には、属性とコンテンツがありません。
When a BEEP peer declines the creation of a channel, it sends an "error" element in a negative reply, e.g.,
BEEPピアは、チャネルの作成を拒否するとき、それは、例えば、負の応答で「エラー」要素を送信します
I: MSG 0 1 . 52 115
I: Content-Type: application/beep+xml
I:
I: <start number='2'>
I: <profile uri='http://iana.org/beep/FOO' />
I: </start>
I: END
L: ERR 0 1 . 221 105
L: Content-Type: application/beep+xml
L:
L: <error code='550'>all requested profiles are
L: unsupported</error>
L: END
The "error" element has a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content:
属性、およびその内容などの診断オプションのテキスト：「エラー」要素は、オプション「langのXML」を「コード」属性を有します。
o the "code" attribute is a three-digit reply code meaningful to programs (c.f., Section 8);
「コード」属性は、プログラム（C.F.、セクション8）に意味のある3桁の応答コードはO。
o the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and,
O「のxml：langの」属性は、（「ローカライズ」リモートBEEPピアによって送信された「挨拶」要素の属性によって義務付けられていない値が提案されていますが、、）要素の内容が書き込まれている言語を識別する。そして、
o the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs.
O診断テキストは、（複数でもよい）、おそらく実装、管理者、およびおそらくはユーザ、決してプログラムに有意義です。
Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used.
属性リモートBEEPピアの最初の選択肢として表示言語が使用されている場合にのみ存在していない：診断のテキストが存在する場合は、「LANG XML」があることに注意してください。
In addition, a BEEP peer sends an "error" element whenever:
また、BEEPピアはいつでも、「エラー」要素を送信します。
o it receives a "MSG" message containing a poorly-formed or unexpected element;
Oそれは不完全に形成された、または予期しない元素を含む「MSG」メッセージを受信します。
o it receives a "MSG" message asking to close a channel (or release the BEEP session) and it declines to do so; or
Oそれは、チャネルを閉じる（またはBEEPセッションを解放）するように求める「MSG」メッセージを受信し、それがそうすることを拒否し、または
o a BEEP session is established, the BEEP peer is acting in the listening role, and that BEEP peer is unavailable (in this case, the BEEP acting in the listening role does not send a "greeting" element).
BEEPセッションが確立されるO、BEEPピアはリスニングの役割で行動している、そのBEEPピアは（この場合には、リスニングの役割で行動するBEEPは、「挨拶」の要素を送信しません）使用できません。
In the final case, both BEEP peers terminate the session, and it is recommended that a diagnostic entry be logged by both BEEP peers.
最後のケースでは、両方のBEEPピアがセッションを終了し、診断項目が両方のBEEPピアによって記録することが推奨されます。
When a BEEP session is established, each BEEP peer signifies its availability by immediately sending a positive reply with a message number of zero on channel zero that contains a "greeting" element, e.g.,
BEEPセッションが確立されると、各BEEPピアは、直ちに例えば、「挨拶」要素が含まれているチャネルゼロにゼロのメッセージ数と正の応答を送信することによってその可用性を意味します
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
Alternatively, if the BEEP peer acting in the listening role is unavailable, it sends a negative reply, e.g.,
リスニングの役割で行動するBEEPピアが使用できない場合あるいは、それは、例えば、負の応答を送信します
L: <wait for incoming connection>
I: <open connection>
L: ERR 0 0 . 0 60
L: Content-Type: application/beep+xml
L:
L: <error code='421' />
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
and the "greeting" element sent by the BEEP peer acting in the initiating role is ignored. It is recommended that a diagnostic entry be logged by both BEEP peers.
そして開始する役割で行動するBEEPピアによって送信された「挨拶」の要素は無視されます。診断エントリは、両方のBEEPピアによって記録されることをお勧めします。
Note that both of these examples imply that the BEEP peer in the initiating role waits until the BEEP peer in the listening role sends its greeting -- this is an artifact of the presentation; in fact, both BEEP peers send their replies independently.
これらの例の両方が、リスニングの役割でBEEPピアはその挨拶を送信するまで開始する役割で、BEEPピアが待機することを意味していることに注意してください - これは、プレゼンテーションのアーティファクトです。実際には、双方のBEEPピアは、独立してその応答を送信します。
When a BEEP peer wants to release the BEEP session, it sends a "close" element with a zero-valued "number" attribute on channel zero. The other BEEP peer indicates its willingness by sending an "ok" element in a positive reply, e.g.,
BEEPピアがBEEPセッションを解放したいときは、チャンネルゼロにゼロ値の「数」属性で「クローズ」の要素を送信します。他のBEEPピアは、例えば、肯定応答で「OK」要素を送信することによって、その意欲を示しています
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+xml
C:
C: <close code='200' />
C: END
S: RPY 0 1 . 264 46
S: Content-Type: application/beep+xml
S:
S: <ok />
S: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
Alternatively, if the other BEEP doesn't want to release the BEEP session, the exchange might look like this:
他のBEEPは、BEEPセッションを解放したくない場合は別の方法として、交換は次のようになります。
C: MSG 0 1 . 52 60
C: Content-Type: application/beep+xml
C:
C: <close code='200' />
C: END
S: ERR 0 1 . 264 79
S: Content-Type: application/beep+xml
S:
S: <error code='550'>still working</error>
S: END
If session release is declined, the BEEP session should not be terminated, if possible.
セッション解放を拒否された場合、可能な場合、BEEPセッションは、終了すべきではありません。
All transport interactions occur in the context of a session -- a mapping onto a particular transport service. Accordingly, this memo defines the requirements that must be satisfied by any document describing how a particular transport service realizes a BEEP session.
特定のトランスポート・サービスにマッピング - すべてのトランスポート相互作用は、セッションのコンテキスト内で起こります。したがって、このメモは、特定のトランスポート・サービスは、BEEPセッションを実現する方法を説明する任意の文書が満たさなければならない要件を定義します。
A BEEP session is connection-oriented. A mapping document must define:
BEEPセッションは接続指向です。マッピング・ドキュメントは、定義する必要があります。
o how a BEEP session is established;
BEEPセッションが確立された方法O;
o how a BEEP peer is identified as acting in the listening role;
O BEEPピアがリスニングの役割で行動として識別される方法。
o how a BEEP peer is identified as acting in the initiating role;
O BEEPピアが開始する役割で行動として識別される方法。
o how a BEEP session is released; and,
BEEPセッションが解放される方法O;そして、
o how a BEEP session is terminated.
OどのようにBEEPセッションが終了されます。
A BEEP session is message-oriented. A mapping document must define:
BEEPセッションは、メッセージ指向です。マッピング・ドキュメントは、定義する必要があります。
o how messages are reliably sent and received;
Oどのようにメッセージが確実に送信され、受信されます。
o how messages on the same channel are received in the same order as they were sent; and,
Oどのように同じチャネル上のメッセージは、それらが送信されたのと同じ順序で受信されています。そして、
o how messages on different channels are sent without ordering constraint.
Oどのように異なるチャネル上のメッセージは、制約を注文せずに送信されます。
BEEP accommodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel).
BEEPは、単一のチャネル内および別個のチャネル間の両方、非同期対話を収容します。この機能は、パイプライン化（イントラチャネル）と平行（チャネル間）を可能にします。
A BEEP peer acting in the client role may send multiple "MSG" messages on the same channel without waiting to receive the corresponding replies. This provides pipelining within a single channel.
クライアントの役割で行動するBEEPピアは、対応する応答を受信するために待つことなく、同じチャネル上で複数の「MSG」メッセージを送信することができます。これは、単一チャネル内のパイプラインを提供します。
A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received. As a consequence, the BEEP peer must generate replies in the same order as the corresponding "MSG" messages are received on a given channel.
サーバーの役割で行動するBEEPピアは、それらが受信されているのと同じ順序で各チャネルのすべての「MSG」メッセージを処理しなければなりません。結果として、BEEPピアは、対応する「MSG」メッセージが所与のチャネル上で受信されたのと同じ順序で応答を生成しなければなりません。
Note that in one-to-many exchanges (c.f., Section 2.1.1), the reply to the "MSG" message consists of zero or more "ANS" messages followed by a "NUL" message. In this style of exchange, the "ANS" messages comprising the reply may be interleaved. When the BEEP peer acting in the server role signifies the end of the reply by generating the "NUL" message, it may then process the next "MSG" message received for that channel.
一対多交流（C.F.、セクション2.1.1）において、「MSG」メッセージに対する応答が「NUL」メッセージに続くゼロ以上の「ANS」メッセージからなることに留意されたいです。為替のこのスタイルでは、回答を含む「ANS」のメッセージがインターリーブすることができます。サーバーロールに作用するBEEPピアが「NUL」メッセージを生成することによって応答の終わりを意味する場合、それは、次の「MSG」メッセージは、そのチャネルのために受信処理することができます。
A BEEP peer acting in the client role may send multiple "MSG" messages on different channels without waiting to receive the corresponding replies. The channels operate independently, in parallel.
クライアントの役割で行動するBEEPピアは、対応する応答を受信するために待つことなく、異なるチャネル上の複数の「MSG」メッセージを送信することができます。チャネルは、並行して、独立して動作します。
A BEEP peer acting in the server role may process "MSG" messages received on different channels in any order it chooses. As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding "MSG" messages are received, there is no ordering constraint for replies on different channels.
サーバーの役割で行動するBEEPピアは、それが選択した任意の順序で異なるチャネルで受信した「MSG」メッセージを処理することができます。所与のチャネルに対する応答が対応する「MSG」メッセージが受信されるのと同じ順序で発生しているように見えるものの結果として、異なるチャネル上の応答のための順序制約がありません。
A BEEP peer acting in the server role may send a negative reply before it receives the final "MSG" frame of a message. If it does so, that BEEP peer is obliged to ignore any subsequent "MSG" frames for that message, up to and including the final "MSG" frame.
それは、メッセージの最後の「MSG」フレームを受信する前に、サーバーの役割で行動するBEEPピアは否定応答を送信することができます。そうでない場合は、そのBEEPピアは、最終的な「MSG」フレームなどに、最大、そのメッセージの後続の「MSG」フレームを無視するように義務付けられています。
If a BEEP peer acting in the client role receives a negative reply before it sends the final "MSG" frame for a message, then it is required to send a "MSG" frame with a continuation status of complete (".") and having a zero-length payload.
それはメッセージの最後の「MSG」フレームを送信する前に、クライアントの役割で行動するBEEPピアが負の応答を受信した場合、完全なの継続状態で「MSG」のフレームを送信するために必要とされる（「」）となります長さがゼロのペイロード。
If the processing of a particular message has sequencing impacts on other messages (either intra-channel or inter-channel), then the corresponding profile should define this behavior, e.g., a profile whose messages alter the underlying transport mapping.
特定のメッセージの処理は、他のメッセージ（イントラチャネルまたはチャネル間のいずれか）上で配列決定の影響がある場合、対応するプロファイルは、例えば、そのメッセージは、基礎となるトランスポート・マッピングを変更するプロファイルをこの動作を定義する必要があります。
BEEP is peer-to-peer -- as such both peers must be prepared to receive all messages defined in this memo. Accordingly, an initiating BEEP peer capable of acting only in the client role must behave gracefully if it receives a "MSG" message. Accordingly, all profiles must provide an appropriate error message for replying to unexpected "MSG" messages.
BEEPは、ピア・ツー・ピアである - そのような両方のピアがこのメモで定義されたすべてのメッセージを受信するように調製されなければならないように。したがって、それは「MSG」メッセージを受信した場合、クライアントの役割が正常に動作しなければならないだけに作用することができる開始BEEPピア。したがって、すべてのプロファイルは、予想外の「MSG」メッセージに返信するための適切なエラーメッセージを提供する必要があります。
As a consequence of the peer-to-peer nature of BEEP, message numbers are unidirectionally-significant. That is, the message numbers in "MSG" messages sent by a BEEP peer acting in the initiating role are unrelated to the message numbers in "MSG" messages sent by a BEEP peer acting in the listening role.
BEEPのピア・ツー・ピアの自然の結果として、メッセージ番号は、一方向に重要です。つまり、開始役割で行動するBEEPピアによって送信された「MSG」メッセージのメッセージ番号は、リスニングの役割で行動するBEEPピアによって送信された「MSG」メッセージのメッセージ番号とは無関係です。
For example, these two messages
例えば、これら二つのメッセージ
I: MSG 0 1 . 52 120
I: Content-Type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/SASL/OTP' />
I: </start>
I: END
L: MSG 0 1 . 221 116
L: Content-Type: application/beep+xml
L:
L: <start number='2'>
L: <profile uri='http://iana.org/beep/APEX' />
L: </start>
L: END
refer to different messages sent on channel zero.
チャンネルゼロに送られた異なるメッセージを参照してください。
When a BEEP session is established, plaintext transfer, without privacy, is provided. Accordingly, transport security in BEEP is achieved using an initial tuning profile.
BEEPセッションが確立されると、平文転送は、プライバシーなしで、提供されます。したがって、BEEPにおけるトランスポート・セキュリティは、初期チューニングプロファイルを使用して達成されます。
This document defines one profile:
この文書では、つのプロファイルを定義しています。
o the TLS transport security profile, based on TLS version one [3].
TLSバージョン一方に基づいてTLSトランスポート・セキュリティ・プロファイル、O [3]。
Other profiles may be defined and deployed on a bilateral basis. Note that because of their intimate relationship with the transport service, a given transport security profile tends to be relevant to a single transport mapping (c.f., Section 2.5).
他のプロファイルが定義されており、二国間ベースで展開することができます。なぜならトランスポート・サービスとの親密な関係を、所定のトランスポート・セキュリティ・プロファイルは、単一のトランスポート・マッピング（C.F.、2.5節）に関連する傾向があることに留意されたいです。
When a channel associated with transport security begins the underlying negotiation process, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers. (If the negotiation process fails, then either BEEP peer may instead terminate the session, and it is recommended that a diagnostic entry be logged.)
トランスポート・セキュリティに関連するチャネルは、基礎となるネゴシエーションプロセスを開始するとき、（チャネルゼロを含む）すべてのチャネルがBEEPセッションで閉じられています。したがって、交渉プロセスが完了すると、関係なく、その結果の、新しい挨拶は、両方のBEEPピアによって発行されます。 （ネゴシエーションプロセスが失敗した場合は、いずれかのBEEPピアは代わりに、セッションを終了することができ、診断のエントリがログに記録することが推奨されます。）
A BEEP peer may choose to issue different greetings based on whether privacy is in use, e.g.,
BEEPピアは、例えば、プライバシーが使用されているかどうかに基づいて異なる挨拶を発行することを選択することができ、
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
I: MSG 0 1 . 52 158
I: Content-Type: application/beep+xml
I:
I: <start number='1'> I: <profile uri='http://iana.org/beep/TLS'> I: <![CDATA[<ready />]]> I: </profile> I: </start> I: END L: RPY 0 1 . 110 121 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <![CDATA[<proceed />]]> L: </profile> L: END
I：<=番号を開始する '1'> I：<プロファイルのuri = 'のhttp：//iana.org/beep/TLS'> I：I <[CDATA [<レディ/>]]！>：</プロフィール> I：</スタート> I：ENDのL：RPY 0 1。 110 121 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<プロファイルのuri = 'のhttp：//iana.org/beep/TLS'> L：L <[CDATA [<続行/>]]！> ：</プロフィール> L：END
... successful transport security negotiation ...
...成功したトランスポート・セキュリティネゴシエーション...
L: RPY 0 0 . 0 221 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' /> L: <profile uri='http://iana.org/beep/APEX' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
L：RPY 0 0。 0 221 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<挨拶> L：<プロファイルのuri = 'のhttp：//iana.org/beep/SASL/ANONYMOUS' /> L：<プロファイルのuri =」 http://iana.org/beep/SASL/OTP」/> L：<プロファイルのuri = 'のhttp：//iana.org/beep/APEX' /> L：</挨拶> L：END I：RPY 0 0。 0 52 I：のContent-Type：I：<挨拶/> I：END Iアプリケーション/ビープ音+ xmlの
Of course, not all BEEP peers need be as single-minded:
もちろん、すべてのBEEPピアはとしてひたむきである必要はありません。
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 268
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
L: <profile uri='http://iana.org/beep/SASL/OTP' />
L: <profile uri='http://iana.org/beep/APEX' />
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting /> I: END I: MSG 0 1 . 52 158 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/TLS'> I: <![CDATA[<ready />]]> I: </profile> I: </start> I: END L: RPY 0 1 . 268 121 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <![CDATA[<proceed />]]> L: </profile> L: END
I：<挨拶/> I：END I：MSG 0 1。 52 158 I：のContent-Type：アプリケーション/ビープ音+ xmlのは、I：I：<開始番号= '1'> I：<プロファイルのuri = 'のhttp：//iana.org/beep/TLS'>私は：<！ CDATA [<レディ/>]]> I：</プロフィール> I </スタート> I：ENDのL：RPY 0 1。 268 121 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<プロファイルのuri = 'のhttp：//iana.org/beep/TLS'> L：L <[CDATA [<続行/>]]！> ：</プロフィール> L：END
... failed transport security negotiation ...
...トランスポート・セキュリティネゴシエーションに失敗しました...
L: RPY 0 0 . 0 268 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' /> L: <profile uri='http://iana.org/beep/SASL/OTP' /> L: <profile uri='http://iana.org/beep/APEX' /> L: <profile uri='http://iana.org/beep/TLS' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
L：RPY 0 0。 0 268 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<挨拶> L：<プロファイルのuri = 'のhttp：//iana.org/beep/SASL/ANONYMOUS' /> L：<プロファイルのuri =」 http://iana.org/beep/SASL/OTP '/> L：<プロファイルのuri = 'のhttp：//iana.org/beep/APEX'/> L：<プロファイルのuri =' のhttp：// IANA。 ORG /ビープ音/ TLS」/> L：</挨拶> L：END I：RPY 0 0。 0 52 I：のContent-Type：I：<挨拶/> I：END Iアプリケーション/ビープ音+ xmlの
Section 6.2 contains the registration for this profile.
6.2節は、このプロファイルの登録が含まれています。
The TLS transport security profile is identified as:
TLSトランスポート・セキュリティ・プロファイルは、次のように識別されます。
http://iana.org/beep/TLS
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／ＴＬＳ
in the BEEP "profile" element during channel creation.
チャネルの作成中にBEEP「プロファイル」要素インチ
During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "ready" element. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "ready" element and includes the resulting response in the reply, e.g.,
チャネルの作成時に、BEEP「スタート」要素で対応する「プロファイル」要素は、「準備完了」元素を含んでいてもよいです。チャネルの作成が成功した場合、対応する応答を送信する前に、BEEPピアは、例えば、「準備完了」要素を処理し、応答で得られた応答を含みます
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed />]]>
S: </profile>
S: END
Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g.,
例えば、チャネルを作成することが可能であるが、カプセル化された動作のために失敗します
C: MSG 0 1 . 52 173
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready version="oops" />]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 193
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<error code='501'>version attribute
S: poorly formed in <ready> element</error>]]>
S: </profile>
S: END
In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.
（チャネルの作成に成功したように）、この場合には、正の応答が送信されるが、カプセル化された応答は、操作が失敗した理由についての指示を含んでいます。
Section 7.2 defines the messages that are used in the TLS transport security profile.
7.2節は、TLSトランスポート・セキュリティプロファイルで使用されるメッセージを定義します。
The "ready" element has an optional "version" attribute and no content:
「準備完了」の要素は、オプションの「バージョン」属性なしコンテンツがあります。
o the "version" element defines the earliest version of TLS acceptable for use.
O「バージョン」エレメントは、使用のために許容されるTLSの最も古いバージョンを定義します。
When a BEEP peer sends the "ready" element, it must not send any further traffic on the underlying transport service until a corresponding reply ("proceed" or "error") is received; similarly, the receiving BEEP peer must wait until any pending replies have been generated and sent before it processes a "ready" element.
BEEPピアが「準備完了」要素を送信すると、対応する応答（「続行」または「エラー」）が受信されるまで、それは、基礎となるトランスポート・サービス上の任意のさらなるトラフィックを送信してはなりません。保留中の応答が生成され、それが「準備完了」の要素を処理する前に送信されるまで同様に、受信BEEPピアは待たなければなりません。
The "proceed" element has no attributes and no content. It is sent as a reply to the "ready" element.
「続行」要素には、属性とコンテンツがありません。それは、「準備完了」の要素への応答として送信されます。
When a BEEP peer receives the "ready" element, it must not send any further traffic on the underlying transport service until it generates a corresponding reply. If the BEEP peer decides to allow transport security negotiation, it implicitly closes all channels (including channel zero), and sends the "proceed" element, and awaits the underlying negotiation process for transport security.
BEEPピアが「準備完了」の要素を受信した場合、それは対応する応答を生成するまで、それは基本的な輸送サービスについて、さらにトラフィックを送信してはなりません。 BEEPピアは、トランスポート・セキュリティネゴシエーションを許可することを決定した場合、それは暗黙的に（チャンネルゼロを含む）すべてのチャネルを閉じ、「続行」要素を送信し、トランスポートセキュリティのための基本的な交渉プロセスを待ちます。
When a BEEP peer receives a "proceed" element in reply to its "ready" message, it implicitly closes all channels (including channel zero), and immediately begins the underlying negotiation process for transport security.
BEEPピアはその「準備完了」メッセージへの返信で「続行」要素を受信すると、それは暗黙的に（チャンネルゼロを含む）すべてのチャネルを閉じ、すぐにトランスポートセキュリティのための基本的な交渉プロセスを開始します。
When a BEEP session is established, anonymous access, without trace information, is provided. Accordingly, user authentication in BEEP is achieved using an initial tuning profile.
BEEPセッションが確立されると、匿名アクセスは、トレース情報なしで、提供されます。したがって、BEEPにおけるユーザ認証は、最初のチューニングプロファイルを使用して達成されます。
This document defines a family of profiles based on SASL mechanisms:
この文書では、SASLメカニズムに基づいたプロファイルのファミリーを定義します。
o each mechanism in the IANA SASL registry [15] has an associated profile.
O IANA SASLレジストリ[15]内の各機構は、関連するプロファイルを有します。
Other profiles may be defined and deployed on a bilateral basis.
他のプロファイルが定義されており、二国間ベースで展開することができます。
Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BEEP session; further, no additional attempts at authentication are allowed.
成功した認証が発生するたびに、いずれかのチャンネルで、認証されたアイデンティティは、BEEPセッション上のすべての既存および将来のチャンネルのために更新されます。さらに、認証の追加の試みは許可されません。
Note that regardless of transport security and user authentication, authorization is an internal matter for each BEEP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided (i.e., unauthorized operations might be rejected with error code 530).
かかわらず、トランスポート・セキュリティとユーザー認証の、承認が各BEEPピアの内部の問題であることに注意してください。このように、各ピアは、それが提供された認証証明書に基づいて可能にする操作を制限することを選択することができる（すなわち、不正操作がエラーコード530で拒否される可能性があります）。
Section 6.3 contains the registration for this profile.
6.3節は、このプロファイルの登録が含まれています。
Note that SASL may provide both user authentication and transport security. Once transport security is successfully negotiated for a BEEP session, then a SASL security layer must not be negotiated; similarly, once any SASL negotiation is successful, a transport security profile must not begin its underlying negotiation process.
SASLは、ユーザ認証とトランスポートセキュリティの両方を提供することができることに注意してください。トランスポート・セキュリティが正常にBEEPセッションのために交渉されると、その後、SASLのセキュリティ層を交渉してはいけません。任意のSASL交渉が成功した後も同様に、トランスポート・セキュリティ・プロファイルは、その基礎となる交渉プロセスを開始してはいけません。
Section 4 of the SASL specification [4] requires the following information be supplied by a protocol definition:
[4] SASL仕様のセクション4は、プロトコル定義によって供給される次の情報が必要です。
service name: "beep"
サービス名：「ビープ音」
initiation sequence: Creating a channel using a BEEP profile corresponding to a SASL mechanism starts the exchange. An optional parameter corresponding to the "initial response" sent by the client is carried within a "blob" element during channel creation.
開始配列：SASL機構に対応するBEEPプロファイルを使用してチャネルを作成するには、交換を開始します。クライアントから送信された「初期対応」に対応するオプションのパラメータは、チャンネル作成中に「ブロブ」要素内に運ばれます。
exchange sequence: "Challenges" and "responses" are carried in exchanges of the "blob" element. The "status" attribute of the "blob" element is used both by a server indicating a successful completion of the exchange, and a client aborting the exchange, The server indicates failure of the exchange by sending an "error" element.
交換シーケンス：「挑戦」と「回答」は「ブロブ」要素の交換に運ばれます。 「ブロブ」要素の「ステータス」属性は、交換が正常に完了したことを示すサーバの両方によって使用され、交換を中止クライアントは、サーバが「エラー」要素を送信することにより、交換が失敗したことを示しています。
security layer negotiation: When a security layer starts negotiation, all channels (including channel zero) are closed on the BEEP session. Accordingly, upon completion of the negotiation process, regardless of its outcome, a new greeting is issued by both BEEP peers.
セキュリティ層の交渉：セキュリティ層がネゴシエーションを開始すると、（チャンネルゼロを含む）すべてのチャンネルがBEEPセッションで閉じられています。したがって、交渉プロセスが完了すると、関係なく、その結果の、新しい挨拶は、両方のBEEPピアによって発行されます。
If a security layer is successfully negotiated, it takes effect immediately following the message that concludes the server's successful completion reply.
セキュリティ層が正常にネゴシエートされた場合は、すぐにサーバーの正常終了応答を終了メッセージ次のような効果になります。
use of the authorization identity: This is made available to all channels for the duration of the BEEP session.
認可IDの使用：これは、BEEPセッションの間、すべてのチャンネルに利用できるようになります。
Each SASL mechanism registered with the IANA is identified as:
IANAに登録された各SASLメカニズムは次のように識別されます。
http://iana.org/beep/SASL/mechanism
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／さＳＬ／めちゃにｓｍ
where "MECHANISM" is the token assigned to that mechanism by the IANA.
ここで、「メカニズムは、」IANAによってそのメカニズムに割り当てられたトークンです。
Note that during channel creation, a BEEP peer may provide multiple profiles to the remote peer, e.g.,
例えば、チャネルの作成時、BEEPピアは、リモートピアに複数のプロファイルを提供してもよいことに留意されたいです
C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END
During channel creation, the corresponding "profile" element in the BEEP "start" element may contain a "blob" element. Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g.,
チャネルの作成時に、BEEP「スタート」要素で対応する「プロファイル」要素は、「ブロブ」元素を含んでいてもよいです。例えば、チャネルを作成することが可能であるが、カプセル化された動作のために失敗します
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 178
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<error code='534'>authentication mechanism is
S: too weak</error>]]>
S: </profile>
S: END
In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.
（チャネルの作成に成功したように）、この場合には、正の応答が送信されるが、カプセル化された応答は、操作が失敗した理由についての指示を含んでいます。
Otherwise, the server sends a challenge (or signifies success), e.g.,
そうでなければ、サーバは、例えば、チャレンジを送信（または成功を意味し）、
C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 171
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
</blob>]]>
S: </profile>
S: END
Note that this example implies that the "blob" element in the server's reply appears on two lines -- this is an artifact of the presentation; in fact, only one line is used.
この例では、サーバの応答で「ブロブ」要素が2行で表示されることを意味していることに注意してください - これは、プレゼンテーションのアーティファクトです。実際には、一つだけの行が使用されています。
If a challenge is received, then the client responds and awaits another reply, e.g.,
チャレンジが受信された場合、クライアントは、例えば、応答し、別の応答を待ち
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: RPY 1 0 . 0 66
S: Content-Type: application/beep+xml
S:
S: <blob status='complete' />
S: END
Of course, the client could abort the authentication process by sending "<blob status='abort' />" instead.
もちろん、クライアントは代わりに「<ブロブのステータスが= / 『中止』>」送信して認証プロセスを中止することができます。
Alternatively, the server might reject the response with an error: e.g.,
また、サーバーはエラーで応答を拒否することがあります。例えば、
C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: ERR 1 0 . 0 60
S: Content-Type: application/beep+xml
S:
S: <error code='535' />
S: END
Finally, depending on the SASL mechanism, an initialization element may be exchanged unidirectionally during channel creation, e.g.,
最後に、SASL機構に依存して、初期化要素は、例えば、チャネルの作成中に一方向に交換することができます
C: MSG 0 1 . 52 125
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/CRAM-MD5' />
C: </start>
C: END
S: RPY 0 1 . 221 185
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
jaS5uZXQ+</blob>]]>
S: </profile>
S: END
Note that this example implies that the "blob" element in the server's reply appears on two lines -- this is an artifact of the presentation; in fact, only one line is used.
この例では、サーバの応答で「ブロブ」要素が2行で表示されることを意味していることに注意してください - これは、プレゼンテーションのアーティファクトです。実際には、一つだけの行が使用されています。
Section 7.3 defines the messages that are used for each profile in the SASL family.
7.3節ではSASLファミリの各プロファイルに使用されるメッセージを定義します。
Note that because many SASL mechanisms exchange binary data, the content of the "blob" element is always a base64-encoded string.
多くのSASLメカニズムは、バイナリデータを交換するため、「ブロブ」元素の含有量が常にbase64でエンコードされた文字列であることに留意されたいです。
The "blob" element has an optional "status" attribute, and arbitrary octets as its content:
「ブロブ」の要素は、その内容として、オプションの「状態」属性、および任意のオクテットがあります。
o the "status" attribute, if present, takes one of three values:
O「状態」属性が存在すれば、3つの値のいずれかをとります。
abort: used by a client to indicate that it is aborting the authentication process;
中止：それは認証プロセスを中止していることを示すために、クライアントによって使用されます。
complete: used by a server to indicate that the exchange is complete and successful; or,
完了：交換が完了し、成功していることを示すために、サーバによって使用されます。または、
continue: used by either a client or server, otherwise.
継続：それ以外の場合は、クライアントまたはサーバのいずれかで使用されます。
Finally, note that SASL's EXTERNAL mechanism works with an "external authentication" service, which is provided by one of:
最後に、SASLの外部機構のいずれかによって提供される「外部認証」サービス、で動作することに注意してください：
o a transport security profile, capable of providing authentication information (e.g., Section 3.1), being active on the connection;
Oトランスポート・セキュリティ・プロファイル、認証情報を提供することができる（例えば、セクション3.1）、接続上でアクティブです。
o a network service, capable of providing strong authentication (e.g., IPSec [12]), underlying the connection; or,
O強力な認証を提供することが可能なネットワークサービス、（例えば、IPSecの[12]）、接続の基礎となります。または、
o a locally-defined security service.
ローカルに定義されたセキュリティサービスを、O。
For authentication to succeed, two conditions must hold:
認証が成功するためには、2つの条件が保持する必要があります：
o an external authentication service must be active; and,
O外部認証サービスをアクティブにする必要があります。そして、
o if present, the authentication identity must be consistent with the credentials provided by the external authentication service (if the authentication identity is empty, then an authorization identity is automatically derived from the credentials provided by the external authentication service).
存在する場合にO、認証IDは、外部認証サービスによって提供される資格情報（認証IDが空の場合、承認のアイデンティティを自動的に外部認証サービスによって提供される資格情報から導出される）と一致しなければなりません。
When a profile is registered, the following information is supplied:
プロファイルが登録されている場合は、次の情報が提供されます。
Profile Identification: specify a URI [10] that authoritatively identifies this profile.
プロファイルの同定：権威このプロファイルを識別するURI [10]を指定します。
Message Exchanged during Channel Creation: specify the datatypes that may be exchanged during channel creation.
チャンネルの作成中に交換メッセージ：チャンネルの作成中に交換することができるデータ型を指定します。
Messages starting one-to-one exchanges: specify the datatypes that may be present when an exchange starts.
メッセージは、1対1の交換を開始する：交換の開始時に存在することができるデータ型を指定します。
Messages in positive replies: specify the datatypes that may be present in a positive reply.
肯定応答内のメッセージは、正の応答中に存在することができるデータ型を指定します。
Messages in negative replies: specify the datatypes that may be present in a negative reply.
負の応答にメッセージ：陰性応答中に存在することができるデータのタイプを指定。
Messages in one-to-many exchanges: specify the datatypes that may be present in a one-to-many exchange.
一対多の交換のメッセージ：一対多交換において存在することができるデータ型を指定します。
Message Syntax: specify the syntax of the datatypes exchanged by the profile.
メッセージの構文：プロファイルによって交換されるデータ型の構文を指定します。
Message Semantics: specify the semantics of the datatypes exchanged by the profile.
メッセージの意味：プロファイルによって交換されるデータ型のセマンティクスを指定します。
Contact Information: specify the postal and electronic contact information for the author of the profile.
お問い合わせ先：プロファイルの作成者郵便や電子連絡先情報を指定します。
When a feature for the channel management profile is registered, the following information is supplied:
チャネル管理プロファイルの特徴が登録されている場合、次の情報が供給されます。
Feature Identification: specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-".
機能識別：この機能を識別する文字列を指定します。機能はIANAに登録されていない限り、機能の識別は、「X-」で始まる必要があります。
Feature Semantics: specify the semantics of the feature.
セマンティクスを備えています：機能のセマンティクスを指定します。
Contact Information: specify the postal and electronic contact information for the author of the feature.
お問い合わせ先：機能の作者のために郵便や電子連絡先情報を指定します。
Profile Identification: not applicable
プロフィール同定：適用されません
Messages exchanged during Channel Creation: not applicable
チャンネルの作成時に交換されるメッセージ：適用されません
Messages starting one-to-one exchanges: "start" or "close"
1対1の交換を開始するメッセージ：「開始」または「クローズ」
Messages in positive replies: "greeting", "profile", or "ok"
正の返信でメッセージ：「挨拶」、「プロファイル」、または「OK」
Messages in negative replies: "error"
負の返信でメッセージ：「エラー」
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message Syntax: c.f., Section 7.1
メッセージ構文：C.F.、7.1節
Message Semantics: c.f., Section 2.3.1
メッセージの意味：C.F.、2.3.1項
Contact Information: c.f., the "Author's Address" section of this memo
お問い合わせ先：C.F.、このメモの「作者のアドレス」セクション
Profile Identification: http://iana.org/beep/TLS
プロフィール同定：http://iana.org/beep/TLS
Messages exchanged during Channel Creation: "ready"
メッセージはチャンネルの作成中に交換：「準備完了」
Messages starting one-to-one exchanges: "ready"
1対1の交換を開始するメッセージ：「準備完了」
Messages in positive replies: "proceed"
正の返信でメッセージ：「続行」
Messages in negative replies: "error"
負の返信でメッセージ：「エラー」
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message Syntax: c.f., Section 7.2
メッセージ構文：C.F.、7.2節
Message Semantics: c.f., Section 3.1.3
メッセージの意味：C.F.、3.1.3項
Contact Information: c.f., the "Author's Address" section of this memo
お問い合わせ先：C.F.、このメモの「作者のアドレス」セクション
Profile Identification: http://iana.org/beep/SASL/mechanism, where "mechanism" is a token registered with the IANA
プロフィール識別：http://iana.org/beep/SASL/mechanism、「メカニズム」はIANAに登録されたトークンです
Messages exchanged during Channel Creation: "blob"
メッセージはチャンネルの作成中に交換：「ブロブ」
Messages starting one-to-one exchanges: "blob"
1対1の交換を開始するメッセージ：「ブロブ」
Messages in positive replies: "blob"
「ブロブ」：正の回答のメッセージ
Messages in negative replies: "error"
負の返信でメッセージ：「エラー」
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message Syntax: c.f., Section 7.3
メッセージ構文：C.F.、7.3節
Message Semantics: c.f., Section 4.1.3
メッセージの意味：C.F.、セクション4.1.3
Contact Information: c.f., the "Author's Address" section of this memo
お問い合わせ先：C.F.、このメモの「作者のアドレス」セクション
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: beep+xml
MIMEサブタイプ名：ビープ音+ xmlの
Required parameters: none
必須パラメータ：なし
Optional parameters: charset (defaults to "UTF-8" [13])
オプションのパラメータ：文字セット（デフォルトは "UTF-8" [13]）
Encoding considerations: This media type may contain binary content; accordingly, when used over a transport that does not permit binary transfer, an appropriate encoding must be applied
配慮をコードする：このメディアタイプは、バイナリコンテンツを含む可能性があります。バイナリ転送を可能にしないトランスポート上で使用される際に、適切な符号化が適用されなければなりません
Security considerations: none, per se; however, any BEEP profile which uses this media type must describe its relevant security considerations
セキュリティの考慮事項：なし、それ自体;しかし、このメディアタイプを使用するすべてのBEEPプロフィールは、その関連するセキュリティ上の考慮事項を記述しなければなりません
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Published specification: This media type is a proper subset of the the XML 1.0 specification [2]. Two restrictions are made.
公開された仕様：このメディアタイプは、XML 1.0仕様の適切なサブセットである[2]。二つの制限がなされています。
First, no entity references other than the five predefined general entities references ("&", "<", ">", "'", and """) and numeric entity references may be present.
最初の5つの事前定義された一般的な実体参照以外の実体参照（「＆＃038;」、「＆LTの;」、「＆GT;」、「'は、」、及び「＆QUOT;」）と数値エンティティ参照できます存在します。
Second, neither the "XML" declaration (e.g., <?xml version="1.0" ?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be present. (Accordingly, if another character set other than UTF-8 is desired, then the "charset" parameter must be present.)
第二に、 "XML" 宣言（例えば、の<？xml version = "1.0"？>）も "DOCTYPE" 宣言（例えば、<！DOCTYPE ...>）のいずれもが存在してもよいです。 （別の文字がUTF-8以外に設定されている場合が望まれるため、その後「文字セット」パラメータが存在しなければなりません。）
All other XML 1.0 instructions (e.g., CDATA blocks, processing instructions, and so on) are allowed.
他のすべてのXML 1.0の命令（例えば、CDATAブロック、処理命令など）が許可されます。
Applications which use this media type: any BEEP profile wishing to make use of this XML 1.0 subset
このXML 1.0のサブセットを利用することを希望する任意のBEEPプロフィール：このメディアタイプを使用するアプリケーション
Additional Information: none
追加情報：なし
Contact for further information: c.f., the "Author's Address" section of this memo
詳細についてはお問い合わせ：C.F.、このメモの「作者のアドレス」セクション
Intended usage: limited use
意図している用法：限定使用
Author/Change controller: the IESG
著者/変更コントローラ：IESG
<!-- DTD for BEEP Channel Management, as of 2000-10-29
<！ - 2000年10月29日のようBEEPチャネル管理のためのDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" "http://xml.resource.org/profiles/BEEP/beep.dtd"> %BEEP; -->
<！ENTITY％BEEP PUBLIC " - // IETF // DTD BEEP // EN" "http://xml.resource.org/profiles/BEEP/beep.dtd">％のBEEP。 - >
<!-- DTD data types:
<！ - DTDデータタイプ：
entity syntax/reference example
====== ================ =======
a channel number
CHAN 1..2147483647 1
authoritative profile identification URI c.f., [RFC-2396] http://invisible.net/
権限のプロファイル識別URI C.F.、[RFC-2396 http://invisible.net/
one or more feature tokens, separated by space FTRS NMTOKENS "magic"
スペースFTRS NMTOKENS「魔法」で区切られた1つの以上の特徴のトークン、
a language tag LANG c.f., [RFC-1766] "en", "en-US", etc.
言語タグLANG C.F.、[RFC-1766] "EN"、 "en-USです" など
zero or more language tags LOCS NMTOKENS "en-US"
ゼロまたはそれ以上の言語タグLOCS NMTOKENS「EN-US」
a 3-digit reply code XYZ [1-5][0-9][0-9] 500 -->
3桁の応答コードXYZ [1-5] [0-9] [0-9] 500 - >
<!ENTITY % CHAN "CDATA"> <!ENTITY % URI "CDATA"> <!ENTITY % FTRS "NMTOKENS"> <!ENTITY % LANG "NMTOKEN"> <!ENTITY % LOCS "NMTOKEN"> <!ENTITY % XYZ "CDATA">
<！ENTITY％のCHAN "CDATA"> <！ENTITY％のURI "CDATA"> <！ENTITY％のFTRS "NMTOKENS"> <！ENTITY％のLANG "NMTOKEN"> <！ENTITY％以下のLOCS "NMTOKEN"> <！ENTITY％のXYZ "CDATA">
<!-- BEEP messages, exchanged as application/beep+xml
<！ - BEEPメッセージは、アプリケーション/ビープ音+ XMLとして交換しました
role MSG RPY ERR
======= === === ===
I and L greeting error
I or L start profile error
IまたはL起動プロファイルのエラー
I or L close ok error -->
IまたはL近いOKエラー - >
<!ELEMENT greeting (profile)*> <!ATTLIST greeting features %FTRS; #IMPLIED localize %LOCS; "i-default">
<！ELEMENT挨拶（プロファイル）*> <！ATTLISTの挨拶は、％FTRSています。 #IMPLIEDローカライズ％LOCS。 「私は、デフォルトの」>
<!ELEMENT start (profile)+> <!ATTLIST start number %CHAN; #REQUIRED serverName CDATA #IMPLIED>
<！ELEMENT（プロファイル）を開始+> <！ATTLIST開始番号％CHAN。 #REQUIRED serverNameのCDATA #IMPLIED>
<!-- profile element is empty if contained in a greeting --> <!ELEMENT profile (#PCDATA)> <!ATTLIST profile uri %URI; #REQUIRED encoding (none|base64) "none">
<！ELEMENTプロファイル（#PCDATA）> <！ - ！ - 挨拶に含まれている場合は、プロファイル要素は空です> <ATTLISTプロファイルのURI％URI; #REQUIREDエンコーディング（なし| BASE64） "なし">
<!ELEMENT close (#PCDATA)> <!ATTLIST close number %CHAN; "0" code %XYZ; #REQUIRED xml:lang %LANG; #IMPLIED>
<！ELEMENTの近く（#PCDATA）> <ATTLIST近い番号％CHAN！。 "0" 符号％XYZ。 #REQUIREDのxml：langの％LANG。 #IMPLIED>
<!ELEMENT ok EMPTY>
<！ELEMENT OK EMPTY>
<!ELEMENT error (#PCDATA)> <!ATTLIST error code %XYZ; #REQUIRED xml:lang %LANG; #IMPLIED>
<！ELEMENTエラー（#PCDATA）> <ATTLISTエラーコード％XYZ！。 #REQUIREDのxml：langの％LANG。 #IMPLIED>
<!-- DTD for the TLS Transport Security Profile, as of 2000-09-04
<！ - 2000-09-04のようTLSトランスポート・セキュリティプロファイルのためのDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % TLS PUBLIC "-//IETF//DTD TLS//EN" "http://xml.resource.org/profiles/TLS/tls.dtd"> %TLS; -->
<！ENTITY％TLS PUBLIC " - // IETF // DTD TLS // EN" "http://xml.resource.org/profiles/TLS/tls.dtd">％TLS; - >
<!-- TLS messages, exchanged as application/beep+xml
<！ - TLSメッセージは、アプリケーション/ビープ音+ XMLとして交換しました
role MSG RPY ERR ====== === === === I or L ready proceed error -->
役割MSG RPY ERRは====== === === === IまたはL準備がエラーを続行 - >
<!ELEMENT ready EMPTY> <!ATTLIST ready version CDATA "1">
<！ELEMENT準備EMPTY> <！ATTLIST準備バージョンCDATA "1">
<!ELEMENT proceed EMPTY>
<！ELEMENT EMPTY進みます>
<!-- DTD for the SASL Family of Profiles, as of 2000-09-04
<！ - 2000-09-04のようにプロファイルのSASL家族のためのDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % SASL PUBLIC "-//IETF//DTD SASL//EN" "http://xml.resource.org/profiles/sasl/sasl.dtd"> %SASL; -->
<！ENTITY％SASL PUBLIC " - // IETF // DTD SASL // EN" "http://xml.resource.org/profiles/sasl/sasl.dtd">％のSASL。 - >
<!-- SASL messages, exchanged as application/beep+xml
<！ - SASLメッセージは、アプリケーション/ビープ音+ XMLとして交換しました
role MSG RPY ERR ====== === === === I or L blob blob error -->
役割MSG RPY ERR ====== === === === IまたはLブロブブロブエラー - >
<!ELEMENT blob (#PCDATA)> <!ATTLIST blob xml:space (default|preserve) "preserve" status (abort|complete|continue) "continue">
<！ELEMENTブロブ（#PCDATA）> <！ATTLISTブロブのxml：スペース（デフォルト|保存） "継続" の状態を（| |完全続け中止） "保存">
code meaning ==== ======= 200 success
コードの意味==== ======= 200成功
421 service not available
421サービスは利用できません
450 requested action not taken (e.g., lock already in use)
450要求されたアクションが取られていない（例えば、既に使用中のロック）
451 requested action aborted (e.g., local error in processing)
中止451要求されたアクション（例えば、処理中にローカルエラー）
454 temporary authentication failure
454一時的な認証失敗
500 general syntax error (e.g., poorly-formed XML)
500一般的な構文エラー（例えば、不完全に形成されたXML）
501 syntax error in parameters (e.g., non-valid XML)
パラメータ501構文エラー（例えば、非有効XML）
504 parameter not implemented
504パラメータが実装されていません
530 authentication required
530認証が必要
534 authentication mechanism insufficient (e.g., too weak, sequence exhausted, etc.)
534認証機構不足（例えば、弱すぎる、シーケンス、等を排出）
535 authentication failure
535認証失敗
537 action not authorized for user
537アクションは、ユーザーのために許可されていません
538 authentication mechanism requires encryption
538認証機構は、暗号化が必要
550 requested action not taken (e.g., no requested profiles are acceptable)
550要求されたアクションが取られていない（例えば、ない要求されたプロファイルが許容可能です）
553 parameter invalid
無効なパラメータ553
554 transaction failed (e.g., policy violation)
554トランザクションが失敗した（例えば、ポリシー違反）
The BEEP framing mechanism, per se, provides no protection against attack; however, judicious use of initial tuning profiles provides varying degrees of assurance:
BEEPフレーミングメカニズムは、それ自体は、攻撃に対する保護機能はありません。しかし、初期のチューニングプロファイルの賢明な使用は保証の様々な程度を提供します。
1. If one of the profiles from the SASL family is used, refer to [4]'s Section 9 for a discussion of security considerations.
SASLファミリーのプロファイルのいずれかが使用されている1場合は、セキュリティ上の考慮事項の議論については、[4]のセクション9を参照してください。
2. If the TLS transport security profile is used (or if a SASL security layer is negotiated), then:
2.次いで、TLSトランスポート・セキュリティ・プロファイルが使用される場合（またはSASLセキュリティ層がネゴシエートされている場合）。
1. A man-in-the-middle may remove the security-related profiles
from the BEEP greeting or generate a negative reply to the
"ready" element of the TLS transport security profile. A
BEEP peer may be configurable to refuse to proceed without an
acceptable level of privacy.
2. A man-in-the-middle may cause a down-negotiation to the weakest cipher suite available. A BEEP peer should be configurable to refuse weak cipher suites.
2.のman-in-the-middleは、利用可能な最も弱い暗号スイートにダウン交渉を引き起こす可能性があります。 BEEPピアは、弱い暗号スイートを拒否するように設定する必要があります。
3. A man-in-the-middle may modify any protocol exchanges prior to a successful negotiation. Upon completing the negotiation, a BEEP peer must discard previously cached information about the BEEP session.
3のman-in-the-middle前成功した交渉の任意のプロトコル交換を修正してもよいです。交渉が完了すると、BEEPピアはBEEPセッションに関する以前にキャッシュされた情報を破棄しなければなりません。
As different TLS ciphersuites provide varying levels of security, administrators should carefully choose which ciphersuites are provisioned.
異なるTLSの暗号スイートは、セキュリティのさまざまなレベルを提供するよう、管理者が慎重にプロビジョニングされている暗号スイートを選択する必要があります。
As BEEP is peer-to-peer in nature, before performing any task associated with a message, each channel should apply the appropriate access control based on the authenticated identity and privacy level associated with the BEEP session.
BEEPは、ピアツーピア性質であるように、メッセージに関連付けられた任意のタスクを実行する前に、各チャネルは、BEEPセッションに関連する認証されたアイデンティティおよびプライバシレベルに基づいて、適切なアクセス制御を適用すべきです。
References
リファレンス
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[2]ワールド・ワイド・ウェブ・コンソーシアム、 "拡張マークアップ言語（XML）1.0"、W3C XML、1998年2月、<http://www.w3.org/TR/1998/REC-xml-19980210>。
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3]ダークス、T.、アレン、C.、Treese、W.、Karlton、P.、フライアー、A.、およびP.コッヘル、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[4] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[4]マイヤーズ、J.、 "簡易認証およびセキュリティ層（SASL）"、RFC 2222、1997年10月。
[5] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[5]ローズ、M.、RFC 3081、 "TCP上にBEEPコアのマッピング" を、2001年3月。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[8]エルツ、R.とR.ブッシュ大統領、 "シリアル番号演算"、RFC 1982、1996年8月。
[9] Alvestrand, H., "Tags for the Identification of Languages", RFC BCP 47, RFC 3066, January 2001.
[9] Alvestrand、H.、 "言語識別のためのタグ"、RFC BCP 47、RFC 3066、2001年1月。
[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[10]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, October 1998.
[11]ニューマン、C.、 "ワンタイムパスワードのSASLメカニズム"、RFC 2444、1998年10月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[13] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[14] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[14]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース、バージョン2"、RFC 2078、1997年1月。
[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>
「１５」 ＜ｈっｔｐ：／／ｗっｗ。いし。えづ／いんーのてｓ／いあな／あっしｇんめんｔｓ／さｓｌーめちゃにｓｍｓ＞
Author's Address
著者のアドレス
Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US
マーシャルT.ローズ目に見えない世界、Inc.の1179北マクダウェル大通りペタルマ、CA 94954から6559米
Phone: +1 707 789 3700 EMail: mrose@invisible.net URI: http://invisible.net/
電話：+1 707 789 3700 Eメール：mrose@invisible.net URI：http://invisible.net/
Appendix A. Acknowledgements
付録A.謝辞
The author gratefully acknowledges the contributions of: David Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods, and, James Woodyatt. In particular, Dave Crocker provided helpful suggestions on the nature of segmentation in the framing mechanism.
デビッド・クラーク、デイブ・クロッカー、スティーブデアリング、ウェズリーマイケル・エディ、ヒューストンフランクリン、マルコ・ガゼッタ、ダニー・グッドマン、スティーブ・ハリス、ロバート・ヘリオット、ケン・ハーシュ、グレッグ・ハドソン、ベン・ローリー、カール・マラマッド、マイケル・メオーリング：著者は感謝の貢献を認めて、キースMcCloghrie、ポール・モカペトリス、RL「ボブ・モーガン、フランク・モートン、ダレン新しい、クリス・ニューマン、ジョー・タッチ、ポール・ヴィクシー、ゲイブWachob、ダニエル・ウッズ、および、ジェームズWoodyatt。特に、デイブ・クロッカーはフレーミングメカニズムにおけるセグメンテーションの性質に有用な提案を提供します。
Appendix B. IANA Considerations
付録B. IANAの考慮事項
The IANA registers "beep" as a GSSAPI [14] service name, as specified in Section 4.1.
IANAはセクション4.1で指定されるように、GSSAPI [14]サービス名として「ビープ音」を登録します。
The IANA maintains a list of:
IANAは、のリストを維持します。
o standards-track BEEP profiles, c.f., Section 5.1; and,
O規格トラックBEEPプロファイル、C.F.、セクション5.1。そして、
o standards-track features for the channel management profile, c.f., Section 5.2.
チャンネル管理プロファイルのO規格トラック機能、C.F.、5.2節。
For each list, the IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. As a courtesy to developers of non-standards track BEEP profiles and channel management features, the mailing list bxxpwg@invisible.net may be used to solicit commentary.
各リストについては、IESGは、IANAが割り当てを行う前に仕様を検討するために、指定の専門家を割り当てるための責任があります。非標準トラックBEEPプロファイルおよびチャネル管理機能の開発者への礼儀として、メーリングリストbxxpwg@invisible.netは解説を勧誘するために使用することができます。
The IANA makes the registrations specified in Section 6.2 and Section 6.3. It is recommended that the IANA register these profiles using the IANA as a URI-prefix, and populate those URIs with the respective profile registrations.
IANAはセクション6.2とセクション6.3で指定された登録を行います。 IANAがURI-接頭辞としてIANAを使用してこれらのプロファイルを登録し、それぞれのプロファイルの登録とそれらのURIを移入することをお勧めします。
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機能のための基金は現在、インターネット協会によって提供されます。