[要約] RFC 3080は、ブロック拡張可能な交換プロトコルのコアに関する規格であり、ブロックチェーン技術の基盤となるプロトコルの設計と機能を提供します。目的は、異なるシステム間でのデータの交換と相互運用性を向上させることです。
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.
Copyright（c）The Internet Society（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.
このメモは、ビープ音（ブロック拡張可能な交換プロトコル）コアと呼ばれる接続指向の非同期相互作用のための一般的なアプリケーションプロトコルカーネルについて説明しています。ビープ音は、単一のアプリケーションユーザーアイデンティティのコンテキスト内で同時に独立した交換を許可し、テキストメッセージとバイナリメッセージの両方をサポートします。
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.
このメモは、ビープ音と呼ばれる接続指向の非同期相互作用のための一般的なアプリケーションプロトコルカーネルについて説明しています。
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's Coreには、ピア間のメッセージの同時に独立した交換を可能にするフレーミングメカニズムがあります。メッセージは任意の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:
各チャネルには、交換されたメッセージの構文とセマンティクスを定義する関連する「プロファイル」があります。ビープ音の操作に暗黙的には、チャネル管理の概念です。ビープ音のチャネル管理プロファイルの定義に加えて、このドキュメントは次のように定義しています。
o the TLS [3] transport security profile; and,
o TLS [3]輸送セキュリティプロファイル。そして、
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.
ビープセッションは、基礎となる輸送サービスにマッピングされます。一連の文書は、特定の輸送サービスがビープセッションをどのように実現するかを説明しています。たとえば、[5]は、ビープセッションが単一の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.
セッションが確立されると、各ビープピアはサポートするプロファイルを宣伝します。その後、チャネルの作成中に、クライアントはそのチャネルに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.
初期チューニング：これらは、ビープ音セッションが確立された後に初期化を実行するプロファイルによって使用されます（たとえば、輸送セキュリティの使用を交渉します）。初期化を実行するにはいくつかの交換が必要になる場合がありますが、これらのチャネルはビープセッションの早期に非アクティブになり、その後もそうです。
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.
特別な性質のため、いつでも1つのチューニングチャネルのみが確立できることに注意してください。対照的に、ビープ音は、複数のデータ交換チャネルを同時に使用することができます。
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:
ビープはピアツーピアですが、特定の時間に実行されている役割のコンテキストで各ピアにラベルを付けるのが便利です。
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.
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 交換を開始するビープピアはクライアントと呼ばれます。同様に、他のビープピアはサーバーと呼ばれます。以下の例では、これらはそれぞれ「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 allows three styles of exchange:
ビープ音により、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.
最初の2つのスタイルは1対1の交換と呼ばれ、3番目のスタイルは1対多数の交換と呼ばれます。
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 デフォルトの「コンテンツタイプ」は「アプリケーション/オクテットストリーム」です。そして、
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行に広がる120オクテットのペイロードを含む単一のフレームに含まれるメッセージがあります（各行はCRLFペアで終了します）。
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 = "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
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
payload = *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」のいずれかのいずれか）で構成され、その後はゼロ以上のパラメーターが続きます。単一のスペース文字（10進コード32 ""）が各コンポーネントを分離します。ヘッダーはCRLFペアで終了します。
The channel number ("channel") must be a non-negative integer (in the range 0..2147483647).
チャネル番号（ "チャネル"）は、非陰性整数（範囲0..2147483647）でなければなりません。
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）でなければならず、返信が完全に受信されていない同じチャネル上の他のすべての「MSG」メッセージとは異なる値を持っている必要があります。
The continuation indicator ("more", one of: decimal code 42, "*", or decimal code 46, ".") specifies whether this is the final frame of the message:
継続インジケーター（「詳細」、1つ：10進コード42、「*」、または小数コード46、 "）は、これがメッセージの最終フレームであるかどうかを指定します。
intermediate ("*"): at least one other frame follows for the message; or,
中間（ "*"）：メッセージに対して少なくとも1つの他のフレームが続きます。または、
complete ("."): this frame completes the message.
Complete（ "。"）：このフレームはメッセージを完成させます。
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）でなければならず、関連するチャネル（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）でなければならず、ペイロード内のオクテットの正確な数を指定します。（これには、ヘッダーまたはトレーラーのいずれも含まれていません。）
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）でなければならず、返信されるメッセージの進行中の他のすべての回答とは異なる値を持たなければなりません。
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つの例外があります。最初に、他のチャネルのフレームのインターリーブに関して制限は行われません。そして、第二に、1対多くの交換では、複数の回答が同時に進行中である可能性があります。したがって、「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にインターリーブされている2つの「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」、「roy」、「er」、「 "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」で始まり、少なくとも1つの他のフレームが受信されたメッセージ番号、およびこのフレームを開始する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」で始まり、少なくとも1つの他のフレームが受信されたメッセージ番号を参照し、この返信のための即時あった受信フレームのキーワードは「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（2 ** 32-1）の範囲です。スペースは有限であるため、シーケンス番号を扱うすべての算術的な算術は、モジュロ2 ** 32を実行します。この署名されていない算術は、2 ** 32-1から0に再びサイクリングする際のシーケンス番号の関係を保持します。シーケンス番号の算術特性の議論については、[8]のセクション2〜5を参照してください。
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.
フレームを受信するとき、そのシーケンス番号とペイロードサイズの合計であるModulo 4294967296（2 ** 32）は、受信した次のフレームの最初のペイロードオクテットに関連付けられた予想シーケンス番号を示します。したがって、シーケンス番号がこのチャネルの期待値でない場合にフレームを受信する場合、ビープピアは同期を失い、セッションは応答を生成せずに終了し、診断エントリを記録することをお勧めします。
The frame trailer consists of "END" followed by a CRLF pair.
フレームトレーラーは、「エンド」に続くCRLFペアで構成されています。
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.
ビープセッションが開始されると、チャネル管理に使用されるチャネル番号ゼロのみが定義されます。セクション6.1には、ビープチャネル管理のプロファイル登録が含まれています。
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).
チャネル管理により、各ビープピアがサポートするプロファイル（C.F.、セクション2.3.1.1）を宣伝し、それらのプロファイルの1つのインスタンスをチャネル（C.F.、セクション2.3.1.2）にバインドし、後でチャネルを閉じるか、リリースすることができます。ビープセッション（C.F.、セクション2.3.1.3）。
A BEEP peer should support at least 257 concurrent channels.
ビープピアは、少なくとも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.,
ビープセッションが確立されると、各ビープピアは、「グリーティング」要素を含むゼロのメッセージ番号ですぐに肯定的な返信を送信することにより、その可用性を意味します。
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.
この例は、リスニングロールのビープピアが挨拶を送るまで、開始の役割のビープピアが待つことを意味することに注意してください。これはプレゼンテーションのアーティファクトです。実際、両方のビープピアは独立して返信を送信します。
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つのオプションの属性（「機能」と「ローカライズ」）とゼロ以上の「プロファイル」要素があります。
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 「機能」属性は、存在する場合、1つ以上の機能トークンが含まれており、それぞれがビープピアによってサポートされているチャネル管理プロファイルのオプションの機能を示しています。
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 「ローカライズ」属性には、存在する場合、1つ以上の言語トークン（[9]で定義）が含まれています。要素（トークンは、ほとんどのものから最も望ましいものに順序付けられます）;そして、
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 「グリーティング」要素に含まれる各「プロファイル」要素はプロファイルを識別し、「start」要素内で発生する「プロファイル」要素とは異なり、各「プロファイル」要素のコンテンツにはオプションの初期化メッセージが含まれない場合があります。
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.,
ビープピアがチャンネルを作成したいとき、チャンネルゼロに「開始」要素を送信します。
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:
「start」要素には、「数字」属性、オプションの「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）を示します。
o the "serverName" attribute, an arbitrary string, indicates the desired server name for this BEEP session; and,
o 任意の文字列である「servername」属性は、このビープセッションの望ましいサーバー名を示します。そして、
o each "profile" element contained with the "start" element has a "uri" attribute, an optional "encoding" attribute, and arbitrary character data as content:
o 「start」要素に含まれる各「プロファイル」要素には、「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.
チャンネルの作成を要求するときにチャネル番号を割り当てる際の競合を回避するために、開始の役割で行動するビープピアは、奇数の断片のみを使用します。同様に、リスニングロールで行動するビープピアは、偶数の肯定的な整数のみを使用します。
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.
ビープピアが受け取った最初の成功「スタート」要素の「servername」属性は、ビープセッションの期間中に意味があります。存在する場合、ビープピアは、示された「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.
ビープピアがチャネルゼロで「開始」要素を受け取ると、提案された各プロファイルを調べ、そのうちの1つを使用してチャネルを作成するかどうかを決定します。その場合、適切な「プロファイル」要素が肯定的な返信で送信されます。それ以外の場合、「エラー」要素が否定的な返信で送信されます。
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.,
ビープピアがチャンネルを閉じたいとき、チャンネルゼロに「閉じる」要素を送信します。
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：lang "属性、およびそのコンテンツとしてのオプションのテキスト診断があります。
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);
o 「コード」属性は、プログラムにとって意味のある3桁の返信コードです（C.F.、セクション8）。
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」属性は、要素のコンテンツが書かれている言語を識別します（値は、リモートビープピアによって送信された「グリーティング」要素の「ローカライズ」属性によって提案されますが、義務付けられていません）。そして、
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.
テキスト診断が存在する場合、「XML：Lang」属性は、リモートビープピアの最初の選択肢として示された言語が使用されている場合にのみ存在しないことに注意してください。
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.
「番号」属性の値がゼロの場合、ビープピアはビープセッション（C.F.、セクション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".)
ビープピアは、そのチャンネルで送信したすべての「MSG」メッセージが認められているときはいつでも、チャンネルに「クローズ」メッセージを送信する場合があります。（謝辞は、MSG「メッセージ」を送信したビープピアが受け取った返信の最初のフレームで構成されています。）
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).
「閉じる」メッセージを送信した後、そのビープピアは、「クローズ」メッセージへの返信が受信されるまで、そのチャンネルの「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.
よく注意：チャンネルを閉じるためのリクエストに対する肯定的な返信が受信されるまで、ビープピアは、そのチャネルで受信する「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.
ビープピアがチャネルの「閉じる」メッセージを受け取ると、否定的な返信で「エラー」メッセージを送信することにより、チャンネルを閉じるリクエストをいつでも拒否する場合があります。
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.
ビープピアがチャンネルを閉じる（またはビープセッションをリリースする）ことに同意すると、肯定的な返信で「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.,
ビープピアがチャネルの作成を拒否すると、否定的な応答で「エラー」要素を送信します。
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:
「エラー」要素には、「コード」属性、オプションの「XML：LANG」属性、およびそのコンテンツとしてのオプションのテキスト診断があります。
o the "code" attribute is a three-digit reply code meaningful to programs (c.f., Section 8);
o 「コード」属性は、プログラムにとって意味のある3桁の返信コードです（C.F.、セクション8）。
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」属性は、要素のコンテンツが書かれている言語を識別します（値は、リモートビープピアによって送信された「グリーティング」要素の「ローカライズ」属性によって提案されますが、義務付けられていません）。そして、
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.
テキスト診断が存在する場合、「XML：Lang」属性は、リモートビープピアの最初の選択肢として示された言語が使用されている場合にのみ存在しないことに注意してください。
In addition, a BEEP peer sends an "error" element whenever:
さらに、ビープピアは、いつでも「エラー」要素を送信します。
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 チャンネルを閉じる（またはビープセッションをリリースする）ことを求める「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).
o ビープセッションが確立され、ビープピアがリスニングの役割で行動しており、そのビープピアは利用できません（この場合、リスニングの役割で作用するビープ音は「挨拶」要素を送信しません）。
In the final case, both BEEP peers terminate the session, and it is recommended that a diagnostic entry be logged by both BEEP peers.
最後のケースでは、両方のビープピアがセッションを終了し、両方のビープピアが診断エントリを記録することをお勧めします。
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.,
ビープセッションが確立されると、各ビープピアは、「グリーティング」要素を含むチャネルゼロのゼロのメッセージ番号ですぐに肯定的な返信を送信することにより、その可用性を意味します。
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.,
あるいは、リスニングの役割で行動するビープピアが利用できない場合、否定的な返信を送信します。
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.
そして、開始の役割で行動するビープピアによって送られた「グリーティング」要素は無視されます。両方のビープピアが診断エントリを記録することをお勧めします。
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.
これらの例の両方が、リスニングロールのビープピアが挨拶を送るまで、開始の役割のビープピアが待つことを意味することに注意してください。これはプレゼンテーションのアーティファクトです。実際、両方のビープピアは独立して返信を送信します。
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.,
ビープピアがビープセッションをリリースしたい場合、チャネルゼロにゼロ値の「数字」属性を持つ「閉じる」要素を送信します。もう1つのビープピアは、肯定的な返信で「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:
あるいは、他のビープ音がビープ音セッションをリリースしたくない場合、交換は次のようになる可能性があります。
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.
セッションのリリースが拒否された場合、可能であればビープセッションを終了しないでください。
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.
すべての輸送の相互作用は、セッションのコンテキストで発生します - 特定の輸送サービスへのマッピング。したがって、このメモは、特定の輸送サービスがビープセッションをどのように実現するかを説明するドキュメントによって満たされなければならない要件を定義します。
A BEEP session is connection-oriented. A mapping document must define:
ビープセッションは接続指向です。マッピングドキュメントは定義する必要があります。
o how a BEEP session is established;
o ビープセッションの確立方法。
o how a BEEP peer is identified as acting in the listening role;
o ビープピアがリスニングの役割で行動することとしてどのように識別されるか。
o how a BEEP peer is identified as acting in the initiating role;
o ビープピアが開始の役割で行動することとしてどのように識別されるか。
o how a BEEP session is released; and,
o ビープセッションのリリース方法。そして、
o how a BEEP session is terminated.
o ビープセッションの終了方法。
A BEEP session is message-oriented. A mapping document must define:
ビープセッションはメッセージ指向です。マッピングドキュメントは定義する必要があります。
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).
ビープ音は、単一のチャネル内と別々のチャネル間の両方で、非同期相互作用に対応します。この機能により、パイプライン（チャネル内）と並列性（チャネル間）が可能になります。
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.
クライアントの役割で行動するビープピアは、対応する返信を受信するのを待つことなく、同じチャネルに複数の「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.
サーバーの役割で行動するビープピアは、特定のチャネルのすべての「MSG」メッセージを受信したのと同じ順序で処理する必要があります。結果として、ビープピアは、特定のチャネルで対応する「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.
1対多数の交換（C.F.、セクション2.1.1）では、「MSG」メッセージへの返信は、ゼロ以上の「ANS」メッセージで構成され、その後の「NUL」メッセージが続くことに注意してください。このスタイルの交換では、返信を含む「ANS」メッセージがインターリーブされる場合があります。サーバーの役割で行動するビープピアが、「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.
クライアントの役割で行動するビープピアは、対応する返信を受信するのを待つことなく、異なるチャネルに複数の「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.
サーバーの役割で行動するビープピアは、選択した順序で異なるチャネルで受信した「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」フレームを受信する前に否定的な返信を送信する場合があります。もしそうなら、そのビープピアは、そのメッセージの後続の「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」フレームを送信する前に否定的な返信を受け取る場合、継続ステータス（ "。"）の継続ステータスを持つ「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.
ビープはピアツーピアです。そのため、このメモで定義されているすべてのメッセージを受信するために、両方のピアを準備する必要があります。したがって、「MSG」メッセージを受信した場合、クライアントの役割でのみ行動できる開始ビープピアは優雅に振る舞う必要があります。したがって、すべてのプロファイルは、予期しない「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.
ビープ音のピアツーピアの性質の結果として、メッセージ番号は一方向に有意です。つまり、開始の役割で行動するビープピアによって送信された「MSG」メッセージのメッセージ番号は、リスニングロールで行動するビープピアが送信した「MSG」メッセージのメッセージ番号とは無関係です。
For example, these two messages
たとえば、これら2つのメッセージ
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.
ビープセッションが確立されると、プライバシーなしのプレーンテキスト転送が提供されます。したがって、初期チューニングプロファイルを使用して、ビープ音の輸送セキュリティが達成されます。
This document defines one profile:
このドキュメントは1つのプロファイルを定義します。
o the TLS transport security profile, based on TLS version one [3].
o TLSバージョン1 [3]に基づくTLS輸送セキュリティプロファイル。
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.)
輸送セキュリティに関連付けられたチャネルが基礎となる交渉プロセスを開始すると、すべてのチャネル（チャネルゼロを含む）がビープセッションで閉じられます。したがって、交渉プロセスが完了すると、その結果に関係なく、両方のビープピアによって新しい挨拶が発行されます。（交渉プロセスが失敗した場合、どちらのビープピアがセッションを終了する場合があり、診断エントリを記録することをお勧めします。）
A BEEP peer may choose to issue different greetings based on whether privacy is in use, e.g.,
ビープピアは、プライバシーが使用されているかどうかに基づいて、さまざまな挨拶をすることを選択できます。
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
... 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
Of course, not all BEEP peers need be as single-minded:
もちろん、すべてのビープピアがひたむきに必要なわけではありません：
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
... 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
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
http://iana.org/beep/TLS
in the BEEP "profile" element during channel creation.
チャネル作成中のビープ音の「プロファイル」要素。
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.,
チャネル作成中、ビープ音の「スタート」要素の対応する「プロファイル」要素には、「準備が整った」要素が含まれる場合があります。チャネル作成が成功した場合、対応する返信を送信する前に、ビープピアは「準備ができた」要素を処理し、結果の応答を返信に含めます。
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:
「Ready」要素には、オプションの「バージョン」属性があり、コンテンツはありません。
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.
ビープピアが「準備が整った」要素を送信したとき、対応する応答（「進行」または「エラー」）が受信されるまで、基礎となる輸送サービスのさらにトラフィックを送信してはなりません。同様に、受信ビープピアは、保留中の返信が生成され、「準備ができた」要素を処理する前に送信されるまで待つ必要があります。
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.
ビープピアが「準備が整った」要素を受け取った場合、対応する応答が生成されるまで、基礎となる輸送サービスにさらにトラフィックを送信してはなりません。ビープピアが輸送セキュリティの交渉を許可することを決定した場合、それはすべてのチャネル（チャネルゼロを含む）を暗黙的に閉じ、「進行」要素を送信し、輸送セキュリティのための基礎となる交渉プロセスを待っています。
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.
ビープピアがその「準備ができた」メッセージへの返信で「進行」要素を受け取ると、すべてのチャネル（チャネルゼロを含む）を暗黙的に閉じ、すぐに輸送セキュリティのための基礎となる交渉プロセスを開始します。
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.
ビープセッションが確立されると、トレース情報なしで匿名アクセスが提供されます。したがって、ビープ音のユーザー認証は、初期チューニングプロファイルを使用して達成されます。
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.
認証が成功すると、任意のチャネルで、ビープ音セッションのすべての既存および将来のチャネルに対して認証されたアイデンティティが更新されます。さらに、認証の追加の試みは許可されていません。
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).
輸送のセキュリティとユーザー認証に関係なく、認可はビープピアごとに内部問題であることに注意してください。そのため、各ピアは、提供された認証資格情報に基づいて許可される操作を制限することを選択できます（つまり、不正な操作はエラーコード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は、ユーザー認証とトランスポートセキュリティの両方を提供する可能性があることに注意してください。輸送セキュリティがビープセッションのために正常に交渉されると、SASLセキュリティ層を交渉してはなりません。同様に、SASLの交渉が成功したら、輸送セキュリティプロファイルが基礎となる交渉プロセスを開始してはなりません。
Section 4 of the SASL specification [4] requires the following information be supplied by a protocol definition:
SASL仕様[4]のセクション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メカニズムに対応するビーププロファイルを使用してチャネルを作成すると、交換が開始されます。クライアントが送信した「初期応答」に対応するオプションのパラメーターは、チャネル作成中に「BLOB」要素内で運ばれます。
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.
交換シーケンス：「課題」と「応答」は、「BLOB」要素の交換で運ばれます。「BLOB」要素の「ステータス」属性は、交換が正常に完了したことを示すサーバーと交換を中止するクライアントの両方で使用されます。サーバーは、「エラー」要素を送信することで交換の障害を示します。
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.
セキュリティ層の交渉：セキュリティレイヤーがネゴシエーションを開始すると、すべてのチャネル（チャネルゼロを含む）がビープセッションで閉じられます。したがって、交渉プロセスが完了すると、その結果に関係なく、両方のビープピアによって新しい挨拶が発行されます。
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の使用：これは、ビープセッションの期間中、すべてのチャネルで利用可能になります。
Each SASL mechanism registered with the IANA is identified as:
IANAに登録されている各SASLメカニズムは、次のように識別されます。
http://iana.org/beep/SASL/mechanism
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.,
チャネル作成中、ビープピアはリモートピアに複数のプロファイルを提供する場合があることに注意してください。
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.,
チャネル作成中、ビープ音の「スタート」要素の対応する「プロファイル」要素には、「ブロブ」要素が含まれる場合があります。チャネルを作成することは可能ですが、カプセル化された操作が失敗する可能性があることに注意してください。
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行に表示されることを意味することに注意してください。これはプレゼンテーションのアーティファクトです。実際、使用されている行は1つだけです。
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.
もちろん、代わりに「<blob status = 'abort' />」を送信することにより、クライアントは認証プロセスを中止できます。
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行に表示されることを意味することに注意してください。これはプレゼンテーションのアーティファクトです。実際、使用されている行は1つだけです。
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メカニズムがバイナリデータを交換するため、「BLOB」要素のコンテンツは常にbase64エンコードされた文字列であることに注意してください。
The "blob" element has an optional "status" attribute, and arbitrary octets as its content:
「BLOB」要素には、オプションの「ステータス」属性があり、そのコンテンツとして任意のオクテットがあります。
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.
1対多くの交換のメッセージ：1対多数の交換に存在する可能性のあるデータ型を指定します。
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対Many交換のメッセージ：なし
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の交換を開始するメッセージ：「Ready」
Messages in positive replies: "proceed"
肯定的な返信のメッセージ：「進行」
Messages in negative replies: "error"
否定的な返信のメッセージ：「エラー」
Messages in one-to-many exchanges: none
1対Many交換のメッセージ：なし
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"
チャネル作成中に交換されるメッセージ：「Blob」
Messages starting one-to-one exchanges: "blob"
1対1の交換を開始するメッセージ：「Blob」
Messages in positive replies: "blob"
肯定的な返信のメッセージ：「Blob」
Messages in negative replies: "error"
否定的な返信のメッセージ：「エラー」
Messages in one-to-many exchanges: none
1対Many交換のメッセージ：なし
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メディアタイプ名：アプリケーション
MIME subtype name: beep+xml
MIMEサブタイプ名：ビープXML
Required parameters: none
必要なパラメーター：なし
Optional parameters: charset (defaults to "UTF-8" [13])
オプションのパラメーター：charset（デフォルトは「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
セキュリティ上の考慮事項：なし、それ自体。ただし、このメディアタイプを使用するビーププロファイルは、関連するセキュリティ上の考慮事項を説明する必要があります
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]の適切なサブセットです。2つの制限が作成されています。
First, no entity references other than the five predefined general entities references ("&", "<", ">", "'", and """) and numeric entity references may be present.
第一に、5つの事前定義された一般的なエンティティ参照（ "＆amp;"、 "＆lt;"、 "＆gt;"、 "＆apos;"、および "＆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以外の別の文字セットが必要な場合、「charset」パラメーターが存在する必要があります。）
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サブセットを使用したいビーププロファイル
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の時点で、ビープチャネル管理用のDTD
Refer to this DTD as:
このDTDを次のように参照してください。
<!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 "Magic"で区切られた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">
<!--
BEEP messages, exchanged as application/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 close okエラー - >
<!ELEMENT greeting (profile)*>
<!ATTLIST greeting
features %FTRS; #IMPLIED
localize %LOCS; "i-default">
<!ELEMENT start (profile)+>
<!ATTLIST start
number %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 close (#PCDATA)>
<!ATTLIST close
number %CHAN; "0"
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT ok EMPTY>
<!ELEMENT error (#PCDATA)>
<!ATTLIST error
code %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;
-->
<!--
TLS messages, exchanged as application/beep+xml
role MSG RPY ERR
====== === === ===
I or L ready proceed error
-->
<!ELEMENT ready EMPTY>
<!ATTLIST ready
version CDATA "1">
<!ELEMENT proceed 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;
-->
<!--
SASL messages, exchanged as application/beep+xml
role MSG RPY ERR
====== === === ===
I or L blob blob error
-->
<!ELEMENT blob (#PCDATA)>
<!ATTLIST blob
xml:space (default|preserve)
"preserve"
status (abort|complete|continue)
"continue">
code meaning
==== =======
200 success
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:
ビープフレーミングメカニズム自体は、攻撃に対する保護を提供しません。ただし、初期チューニングプロファイルの賢明な使用は、さまざまな程度の保証を提供します。
1. If one of the profiles from the SASL family is used, refer to [4]'s Section 9 for a discussion of security considerations.
1. 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.
1. 中間者は、ビープ音からセキュリティ関連のプロファイルを削除するか、TLSトランスポートセキュリティプロファイルの「準備ができた」要素に対する否定的な返信を生成する場合があります。ビープピアは、許容できるレベルのプライバシーなしに進めることを拒否するように構成できる場合があります。
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. 中間の男は、利用可能な最も弱い暗号スイートにダウンネゴシエーションを引き起こす可能性があります。ビープピアは、弱い暗号スイートを拒否するために構成できる必要があります。
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. 中間者は、交渉が成功する前に、プロトコル交換を変更する場合があります。交渉を完了すると、ビープピアはビープ音セッションに関する以前にキャッシュされた情報を捨てなければなりません。
As different TLS ciphersuites provide varying levels of security, administrators should carefully choose which ciphersuites are provisioned.
さまざまなTLS ciphersuitesがさまざまなレベルのセキュリティを提供するため、管理者はどのCiphersuitesがプロビジョニングされているかを慎重に選択する必要があります。
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.
ビープ音は本質的にピアツーピアであるため、メッセージに関連付けられたタスクを実行する前に、各チャネルは、ビープセッションに関連付けられた認証されたアイデンティティとプライバシーレベルに基づいて適切なアクセス制御を適用する必要があります。
References
参考文献
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、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] World Wide Webコンソーシアム、「拡張可能なマークアップ言語（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] Dierks、T.、Allen、C.、Treese、W.、Karlton、P.、Freier、A。and P. Kocher、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[4] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[4] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[5] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[5] Rose、M。、「ビープコアをTCPにマッピング」、RFC 3081、2001年3月。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[8] Elz、R。およびR. Bush、「シリアル番号算術」、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Linn、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.ローズInvisible Worlds、Inc。1179 North McDowell Boulevard Petaluma、CA 94954-6559 US
Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/
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.
著者は、デビッド・クラーク、デイブ・クロッカー、スティーブ・ディーリング、ウェスリー・マイケル・エディ、ヒューストン・フランクリン、マルコ・ガゼッタ、ダニー・グッドマン、スティーブ・ハリス、ロバート・ヘリオット、ケン・ヒルシュ、グレッグ・ハドソン、ベン・ラウリー、カール・マラムード、マイケル・ミールリングの貢献に感謝して認めています。、キース・マクログリー、ポール・モカペトリス、RL 'ボブ・モーガン、フランク・モートン、ダレン・ニュー、クリス・ニューマン、ジョー・タッチ、ポール・ビクシー、ゲイブ・ワチョブ、ダニエル・ウッズ、ジェームス・ウッディアット。特に、デイブ・クロッカーは、フレーミングメカニズムにおけるセグメンテーションの性質について有益な提案を提供しました。
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 標準トラックビーププロファイル、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が割り当てを行う前に、指定された専門家を割り当てて仕様を確認する責任があります。非標準の開発者への礼儀としてビープ音プロファイルとチャネル管理機能を追跡するため、メーリングリスト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は、IANAをURI-Prefixとして使用してこれらのプロファイルを登録し、それらのURIにそれぞれのプロファイル登録を登録することをお勧めします。
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エディター機能の資金は現在、インターネット協会によって提供されています。