RFC3080 日本語訳
3080 The Blocks Extensible Exchange Protocol Core. M. Rose. March 2001. (Format: TXT=82089 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Rose Request For Comments: 3080 Invisible Worlds, Inc. Category: Standards Track March 2001
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 3080年の目に見えない世界Inc.カテゴリ: 2001年の標準化過程行進
The Blocks Extensible Exchange Protocol Core
ブロックの広げることができる交換プロトコルコア
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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(Extensible Exchangeプロトコルを妨げる)コアと呼ばれる接続指向の、そして、非同期な相互作用のために一般的適用プロトコルカーネルについて説明します。 原文の、そして、2進の両方のメッセージを支持して、BEEPはただ一つのアプリケーションユーザアイデンティティの文脈の中で同時の、そして、独立している交換を可能にします。
Rose Standards Track [Page 1] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 4 2。 ビープ音コア. . . . . . . . . . . . . . . . . . . . . . 5 2.1の役割. . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1の.1交換は、.62.2のメッセージを流行に合わせて、.72.2.1フレーム構文. . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1.1フレームヘッダー.92.2.1.2フレーム有効搭載量. . . . . . . . . . . . . . . . . . . . . . 12 2.2.1.3フレームトレーラを縁どっています…; . . . . . . 13 2.2.2 フレーム意味論. . . . . . . . . . . . . . . . . . . . . 14 2.2.2の.1の不十分に形成されたメッセージ. . . . . . . . . . . . . . . . . . 14 2.3チャンネル管理. . . . . . . . . . . . . . . . . . . . 15 2.3.1が意味論を通信させる、.162.3、.1、.1、あいさつメッセージ、.162.3、.1、.2、開始メッセージ、.172.3、.1、.3、近いメッセージ、.202.3、.1、.4、OK Mes賢人、.232.3、.1、.5、Error Message. . . . . . . . . . . . . . . . . . . . 23 2.4Session特権階級とRelease. . . . . . . . . . . . 25 2.5Transport Mappings. . . . . . . . . . . . . . . . . . . . 27 2.5.1Session Management. . . . . . . . . . . . . . . . . . . . 27 2.5.2Message Exchange. . . . . . . . . . . . . . . . . . . . . 27 2; 異なることの間では、.3の先買いの回答. . . . . . . . . . . . . . . . . . . 29 2.6が.282.6に向けられています。6非同期、.282.6、.1、単独のチャンネル、.282.6、.2、.4 干渉. . . . . . . . . . . . . . . . . . . . . . . 29 2.7ピアツーピアの振舞い. . . . . . . . . . . . . . . . . . 30 3。 TLS輸送セキュリティプロフィール. . . . . . . . . . . . 34 3.1.1プロフィール識別と初期設定. . . . . . . . 34 3.1.2メッセージ構文. . . . . . . . . . . . . . . . . . . . . . 35 3.1.3が通信させるセキュリティ. . . . . . . . . . . . . . . . . . . . 31 3.1を輸送してください、意味論、.363.1、.3、.1、持ち合わせのメッセージ、.363.1、.3、.2、メッセージ. . . . . . . . . . . . . . . . . . . 36 4を続かせてください。 ユーザー認証. . . . . . . . . . . . . . . . . . . 37 4.1はプロフィール. . . . . . . . . . . . . . . 38 4.1.1プロフィール識別と初期設定. . . . . . . . 39 4.1.2メッセージ構文. . . . . . . . . . . . . . . . . . . . . . 42 4.1.3メッセージ意味論. . . . . . . . . . . . . . . . . . . . 43 5のSASL家です。 登録テンプレート. . . . . . . . . . . . . . . . . . 44 5.1プロフィール登録テンプレート. . . . . . . . . . . . . . 44 5.2は登録テンプレート. . . . . . . . . . . . . . 44 6を特集します。 登録証明書. . . . . . . . . . . . . . . . . . 45 6.1登録に頭文字をつけてください: チャンネル管理. . . . . . . . . . 45 6.2登録を鳴らしてください: TLS輸送セキュリティプロフィール. . . . . . . 45
Rose Standards Track [Page 2] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[2ページ]。
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
6.3登録: プロフィール. . . . . . . . . . 46 6.4登録のSASL家: アプリケーション/ビープ音+xml.477。 DTD. . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.1は.518にプロフィールDTDのチャンネル管理DTD. . . . . . . . . . . . . . . 48 7.2TLS輸送セキュリティプロフィールDTD. . . . . . . . . . . . 50 7.3SASL家を鳴らします。 回答コード. . . . . . . . . . . . . . . . . . . . . . . 52 9。 セキュリティ問題. . . . . . . . . . . . . . . . . 53参照. . . . . . . . . . . . . . . . . . . . . . . . 54作者の.55のアドレスA.承認. . . . . . . . . . . . . . . . . . . . . 56B.IANA問題. . . . . . . . . . . . . . . . . . . 57の完全な著作権宣言文. . . . . . . . . . . . . . . . . 58
Rose Standards Track [Page 3] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[3ページ]。
1. Introduction
1. 序論
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,
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.
データ交換に使用されるものなどの他のプロフィールはアプリケーション・プロトコルデザイナーによって定義されます。
Rose Standards Track [Page 4] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[4ページ]。
2. The BEEP Core
2. ビープ音コア
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つのカテゴリの1つになります:
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.
彼らの特別な本質のために、その時々で1個の調律チャンネルだけを確立してもよいことに注意してください。 対照的に、BEEPは、複数のデータ交換チャンネルが同時に使用中であることを許容します。
Rose Standards Track [Page 5] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[5ページ]。
2.1 Roles
2.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:
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.
o BEEPセッションが確立されるとき、新しい接続を待つ同輩は聴取の役割で行動しています、そして、もう片方の同輩(リスナーに取引関係を築く)は開始の役割で行動しています。 従う例ではこれらが言及される、「L:」 そして、「私:」、それぞれ。
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が現実にピアツーピアであるので、どんなそのような要件も存在していません。
2.1.1 Exchange Styles
2.1.1 交換様式
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).
エムエスジー/RPY: クライアントは「エムエスジー」メッセージに何らかのタスクを実行するようにサーバに頼ませて、サーバは"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/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.
エムエスジー/ANS: クライアントは、「エムエスジー」メッセージ、何らかのタスクを実行するコースの間のサーバにゼロがある回答を送るか、または、より多くの「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回の交換と呼ばれます。
Rose Standards Track [Page 6] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[6ページ]。
2.2 Messages and Frames
2.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 デフォルト「コンテントタイプ」は「八重奏アプリケーション/流れ」です。 そして
o the default "Content-Transfer-Encoding" is "binary".
o デフォルト「満足している転送コード化」は「2進です」。
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
C: エムエスジー0 1.52120C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/OTP '/>Cと等しいです: </スタート>C: 終わり
In this example, note that the entire message is represented in a single frame.
この例では、全体のメッセージがシングルフレームに表されることに注意してください。
Rose Standards Track [Page 7] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[7ページ]。
2.2.1 Frame Syntax
2.2.1 フレーム構文
The ABNF [7] for a frame is:
フレームへのABNF[7]は以下の通りです。
frame = data / mapping
フレーム=データ/マッピング
data = header payload trailer
データはヘッダーペイロードトレーラと等しいです。
header = msg / rpy / err / ans / nul
ヘッダー=msg / rpy /が間違える、/ 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
「ANS」SPの一般的な"RPY"SPの一般的なmsg=「エムエスジー」SPの一般的なCR LF rpy=CR LF ans=SP ansno CR LFが=「間違えてください」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
トレーラ=「終わり」CR LF
mapping = ;; each transport mapping may define additional frames
マッピング=。 それぞれの輸送マッピングは追加フレームを定義するかもしれません。
Rose Standards Track [Page 8] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[8ページ]。
2.2.1.1 Frame Header
2.2.1.1 フレームヘッダー
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キャラクタのキーワード(: 「エムエスジー」の1つ、"RPY"、「間違えてください」、「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における)であり、異価を持たなければなりません。
The continuation indicator ("more", one of: decimal code 42, "*", or
decimal code 46, ".") specifies whether this is the final frame of
the message:
「継続インディケータ、(「より多くです」、: 小数コード42の1つ、「*」、または小数が46をインチコード化する、」、)、これがメッセージの最終的なフレームであるかどうか指定します:
intermediate ("*"): at least one other frame follows for the
message; or,
中間的(「*」): 他の少なくとも1個のフレームがメッセージのために続きます。 または
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における)、ペイロードの最初の八重奏の一連番号を指定します、関連チャンネルのために(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
S: 20秒間のRPY0 1*287: ... S: ... S: 終わりS: 0秒間のRPY0 1.307: 終わり
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における)、異価を持たなければなりません。
Rose Standards Track [Page 9] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[9ページ]。
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つの交換では、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
S: 0秒間のANS1 0*0 20: ... S: ... S: 終わりS: 1秒間のANS1 0*20 20: ... S: ... S: 終わりS: 0秒間のANS1 0.40 10: ... S: 終わり
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.
回答の一部としてチャンネル1にはさみ込まれた2つの「ANS」メッセージをメッセージ番号0に示しています。 一連番号がチャンネルで送られた各フレームに進められて、それらのフレームで送られたメッセージから独立していることに注意してください。
Rose Standards Track [Page 10] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[10ページ]。
There are several rules for identifying poorly-formed frames:
不十分に形成されたフレームを特定するためのいくつかの規則があります:
o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or
"NUL";
o ヘッダーが「エムエスジー」から始めないか、そして、"RPY"、「間違えてください」、「ANS」、または"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 ヘッダーが「エムエスジー」から始めて、メッセージ番号が完全に受け取られましたが、回答が完全に送られるというわけではなかった「エムエスジー」メッセージを示すなら。
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 ヘッダーが「エムエスジー」から始めないで、回答が完全に既に受け取られたメッセージ番号について言及するなら。
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 ヘッダーが「エムエスジー」から始めないで、一度も送られたことがないメッセージ番号について言及するなら(セッション設立、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 ヘッダーが「エムエスジー」、"RPY"、「間違えてください」、または「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 ヘッダーがこの回答が「ANS」でないので他の少なくとも1個のフレームがすぐに前の容認されたフレームで、どれに関する受け取られていてキーワードであるかについて"NUL"から始めて、メッセージ番号について言及するなら。
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.
フレームが不十分に形成されているなら、応答を発生させないで、セッションは終えられます、そして、診断エントリーが登録されるのは、お勧めです。
Rose Standards Track [Page 11] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[11ページ]。
2.2.1.2 Frame Payload
2.2.1.2 フレーム有効搭載量
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**1〜32--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.
フレームを受けるとき、その一連番号とペイロードサイズの合計(法4294967296(2**32))は受ける隣のフレームの最初のペイロード八重奏に関連しているのに予想された一連番号を与えます。 それに従って、一連番号がこのチャンネルのための期待値でないならフレームを受けるとき、次に、BEEP同輩は同期を失いました、そして、応答を発生させないで、次に、セッションは終えられます、そして、診断エントリーが登録されるのは、お勧めです。
Rose Standards Track [Page 12] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[12ページ]。
2.2.1.3 Frame Trailer
2.2.1.3 フレームトレーラ
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.
フレームを受けるとき、応答を発生させないで、すぐにペイロードの後をつけるキャラクタがトレーラに文通しないなら、セッションは終えられます、そして、診断エントリーが登録されるのは、お勧めです。
Rose Standards Track [Page 13] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[13ページ]。
2.2.2 Frame Semantics
2.2.2 フレーム意味論
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)はこの情報を組織化します。
2.2.2.1 Poorly-formed Messages
2.2.2.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).
プロフィールの動きを定義するとき、テンプレートは不十分に形成された「エムエスジー」メッセージがどう答えられるかを指定しなければなりません。 例えば、チャンネル管理プロフィールがエラーメッセージを含む否定的な返事を送る、(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に手順を用いることでチャンネルを閉店させなければなりません。
Rose Standards Track [Page 14] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[14ページ]。
2.3 Channel Management
2.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).
それぞれのBEEP同輩がチャンネル管理で、それが支えるプロフィールの広告を出すことができる、(c.f.、セクション2.3.1、.1、)aへのそれらのプロフィールの1つの例が向けるひも、(セクション2.3.1のc.f.、.2、)および当時の後の近いいずれもBEEPセッションを向けるか、またはリリースする、(c.f.、セクション2.3 .1 .3)。
A BEEP peer should support at least 257 concurrent channels.
BEEP同輩は少なくとも257個の同時発生のチャンネルを支えるべきです。
Rose Standards Track [Page 15] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[15ページ]。
2.3.1 Message Semantics
2.3.1 メッセージ意味論
2.3.1.1 The Greeting Message
2.3.1.1 あいさつメッセージ
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
L: 接続要求>Iのための<待ち: <の開いている接続>L: RPY0 0.0110、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <挨拶>L: <プロフィールuriは' http://iana.org/beep/TLS '/>Lと等しいです: </挨拶>L: 終わりI: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わり
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同輩によって支えられた各プロフィールあたり1つ:
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つ以上の特徴象徴を含んでいます、それぞれ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 存在しているなら、「集中」属性は1つ以上の言語象徴を含んでいます。([9])で定義されています、「閉鎖」と「誤り」要素のために原文の病気の特徴を発生させるとき、リモート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はオプション機能のために登録テンプレートを定義します。
Rose Standards Track [Page 16] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[16ページ]。
2.3.1.2 The Start Message
2.3.1.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
C: エムエスジー0 1.52120C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/OTP '/>Cと等しいです: </スタート>C: 終わり
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における)が以前は将来のメッセージでよくチャンネルを特定していたのを示します。
o the "serverName" attribute, an arbitrary string, indicates the
desired server name for this BEEP session; and,
o "serverName"属性(任意のストリング)はこの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セッションの持続時間に、BEEP同輩によって受け取られた最初のうまくいっている「始め」要素のための"serverName"属性は重要です。 存在しているなら、BEEP同輩は、示された"serverName"として作動するかどうか決めます。 そうでなければ、否定的な返事で「誤り」要素を送ります。
Rose Standards Track [Page 17] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[17ページ]。
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同輩がチャンネルゼロの「始め」要素を受け取るとき、それは、それぞれの提案されたプロフィールを調べて、チャンネルを創造するのにそれらの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
C: エムエスジー0 1.52178C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/OTP '/>Cと等しいです: <プロフィールuriは' http://iana.org/beep/SASL/ANONYMOUS '/>Cと等しいです: </スタート>C: 終わりS: 87秒間のRPY0 1.221: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <プロフィールuriは' http://iana.org/beep/SASL/OTP '/>Sと等しいです: 終わり
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
C: エムエスジー0 1.52120C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'2'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/OTP '/>Cと等しいです: </スタート>C: 終わりS: 間違え、0 1、.221 127秒間: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <エラーコードは'501と等しいです。'>番号はSを結果と考えます'。 <始めでは、>要素は変に評価された</誤り>Sであるに違いない: 終わり
Rose Standards Track [Page 18] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[18ページ]。
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
C: エムエスジー0 1.52158C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/TLS '>Cと等しいです:、' <[CDATA[<の持ち合わせの/>]]!>C: </プロフィール>C: </スタート>C: 終わりS: 121秒間のRPY0 1.110: コンテントタイプ: + アプリケーション/ビープ音xml S: S: ' http://iana.org/beep/TLS '<プロフィールuri=>S:、' <[CDATA[<は/>を続かせる]]!>S: </プロフィール>S: 終わり
Rose Standards Track [Page 19] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[19ページ]。
2.3.1.3 The Close Message
2.3.1.3 近いメッセージ
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
C: エムエスジー0 2.23571C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: '1'<の近い番号=コードは'200'/>Cと等しいです: 終わり
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 「コード」属性はプログラム(c.f.、セクション8)に重要な3ケタの回答コードです。
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 原文の病気の特徴(マルチラインであるかもしれない)は、implementers、恐らく管理者、およびことによるとユーザにとってさえ重要ですが、決してプログラムを作りません。
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同輩の最初の選択として示された言語が使用されている場合にだけ「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.
「数」属性の値がゼロであるなら、BEEP同輩はBEEPセッション(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".)
それがそのチャンネルで送ったすべての「エムエスジー」メッセージが承認されたときはいつも、BEEP同輩はチャンネルへの「近い」メッセージを送るかもしれません。 (承認は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同輩はそのチャンネルで「近い」メッセージに関する回答を受け取るまで(チャンネルを閉じるという要求を拒絶する「誤り」メッセージ、または次に首尾よく始められたチャンネル存在によって従われた「間違いありません、な」メッセージで)それ以上の「エムエスジー」メッセージを送ってはいけません。
Rose Standards Track [Page 20] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[20ページ]。
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同輩はそのチャンネルの上に受信するというあらゆる「エムエスジー」メッセージを処理する用意ができていなければなりません。
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:
さもなければ、チャンネルを閉じるために要請を受け入れて、積極的な返事における「間違いありません、な」メッセージを送る前に、そうしなければなりません:
o finish sending any queued "MSG" messages on that channel of its
own;
o それ自身のそのチャンネルでどんな列に並ばせられた「エムエスジー」メッセージも送り終えてください。
o await complete replies to any outstanding "MSG" messages it has
sent on that channel; and,
o それがそのチャンネルで送ったあらゆる傑出している「エムエスジー」メッセージに完全な回答をお待ちしてください。 そして
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 それがそのチャンネルで受け取ったどんな傑出している「エムエスジー」メッセージにも完全な回答を送り終えてください、そして、すなわち、それらの回答の最終的なフレームが首尾よく届けられたのを確実にしてください。
* 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,
* メッセージのインターチャネル注文を保証する輸送マッピングに関しては、積極的な返事における「間違いありません、な」メッセージを送る前に、回答を送らなければなりません。 そうでなければ
* the replies must be sent and subsequently acknowledged by the
underlying transport service prior to sending the "ok" message
in a positive reply.
* 回答は、送られて積極的な返事における「間違いありません、な」メッセージを送る前に、次に、基本的な輸送サービスで承認していなければなりません。
Rose Standards Track [Page 21] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[21ページ]。
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
C: エムエスジー0 2.23571C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: '1'<の近い番号=コードは'200'/>Cと等しいです: 終わりS: 46秒間のRPY0 2.392: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <OK/>S: 終わり
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
C: エムエスジー0 2.23571C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: '1'<の近い番号=コードは'200'/>Cと等しいです: 終わりS: 間違え、0 2、.392 79秒間: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <エラーコード='550'>は働く</誤り>Sを静めます'。 終わり
Rose Standards Track [Page 22] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[22ページ]。
2.3.1.4 The OK Message
2.3.1.4 OKメッセージ
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セッションをリリースしてください)、それは「間違いありません、な」要素に積極的な返事を送ります。
The "ok" element has no attributes and no content.
「間違いありません、な」要素には、属性がなくて内容が全くありません。
2.3.1.5 The Error Message
2.3.1.5 エラーメッセージ
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
私: エムエスジー0 1.52115、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <スタート番号は'2'>Iと等しいです:、' ' http://iana.org/beep/FOO '/><プロフィールuri=I: </スタート>I: 終わりL: 間違え、0 1、.221 105、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <エラーコード='550'>は、プロフィールがLであるようすべて要求しました'。 サポートされない</誤り>L: 終わり
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 「コード」属性はプログラム(c.f.、セクション8)に重要な3ケタの回答コードです。
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 原文の病気の特徴(マルチラインであるかもしれない)は、implementers、恐らく管理者、およびことによるとユーザにとってさえ重要ですが、決してプログラムを作りません。
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同輩の最初の選択として示された言語が使用されている場合にだけ「xml: lang」属性が欠けていることに注意してください。
Rose Standards Track [Page 23] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[23ページ]。
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 それは不十分に形成されたか予期していなかった要素を含む「エムエスジー」メッセージを受け取ります。
o it receives a "MSG" message asking to close a channel (or release
the BEEP session) and it declines to do so; or
o それはチャンネルを閉じるように頼む「エムエスジー」メッセージを受け取ります、そして、(ビープ音セッションをリリースしてください)そうするのを断ります。 または
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 BEEPセッションは確立されます、そして、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同輩によって登録されるのは、お勧めです。
Rose Standards Track [Page 24] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[24ページ]。
2.4 Session Establishment and Release
2.4 セッション設立とリリース
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
L: 接続要求>Iのための<待ち: <の開いている接続>L: RPY0 0.0110、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <挨拶>L: <プロフィールuriは' http://iana.org/beep/TLS '/>Lと等しいです: </挨拶>L: 終わりI: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わり
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>
L: 接続要求>Iのための<待ち: <の開いている接続>L: 間違え、0 0、.060、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <エラーコードは'421'/>Lと等しいです: 終わりI: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わりI: <浅からぬ関係>L: <浅からぬ関係>L: 次の接続>のための<待ち
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同輩によって登録されるのは、お勧めです。
Rose Standards Track [Page 25] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[25ページ]。
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同輩は、例えば「間違いありません、な」要素に積極的な返事を送ることによって、意欲を示します。
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>
C: エムエスジー0 1.52 60C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <の近いコードは'200'/>Cと等しいです: 終わりS: 46秒間のRPY0 1.264: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <OK/>S: 終わりI: <浅からぬ関係>L: <浅からぬ関係>L: 次の接続>のための<待ち
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
C: エムエスジー0 1.52 60C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <の近いコードは'200'/>Cと等しいです: 終わりS: 間違え、0 1、.264 79秒間: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <エラーコード='550'>は働く</誤り>Sを静めます'。 終わり
If session release is declined, the BEEP session should not be terminated, if possible.
セッションリリースが断たれるなら、BEEPセッションは、終えられて、可能であるべきではありません。
Rose Standards Track [Page 26] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[26ページ]。
2.5 Transport Mappings
2.5 輸送マッピング
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セッションがわかるかを説明するどんなドキュメントでも満たさなければならない要件を定義します。
2.5.1 Session Management
2.5.1 セッション管理
A BEEP session is connection-oriented. A mapping document must define:
BEEPセッションは接続指向です。 マッピングドキュメントは以下を定義しなければなりません。
o how a BEEP session is established;
o BEEPセッションはどう確立されるか。
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,
o BEEPセッションはどうリリースされるか。 そして
o how a BEEP session is terminated.
o BEEPセッションはどう終えられるか。
2.5.2 Message Exchange
2.5.2 交換処理
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 規制を命令しないで、どう異なったチャンネルに関するメッセージを送るか。
Rose Standards Track [Page 27] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[27ページ]。
2.6 Asynchrony
2.6 非同期
BEEP accommodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel).
BEEPは単独のチャンネルと別々のチャンネルとの非同期な相互作用を収容します。 この特徴はパイプライン処理(イントラチャンネル)と平行関係(インターチャネル)を許容します。
2.6.1 Within a Single Channel
2.6.1 単独のチャンネルの中に
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同輩は同じチャンネルで複数の「エムエスジー」メッセージを送るかもしれません。 これは単独のチャンネルの中にパイプライン処理を提供します。
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同輩は同次で与えられたチャンネルへのすべての「エムエスジー」メッセージを処理しなければなりません。 結果として、BEEP同輩は与えられたチャンネルで対応する「エムエスジー」メッセージを受け取るように同次における回答を発生させなければなりません。
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)では、「エムエスジー」メッセージに関する回答がゼロか"NUL"メッセージがあとに続いたより多くの「ANS」メッセージから成ることに注意してください。 このスタイルの交換では、回答を包括する「ANS」メッセージははさみ込まれるかもしれません。 サーバーの役割で行動しているBEEP同輩が"NUL"メッセージを発生させることによって回答の終わりを意味すると、それはそのチャンネルのために受け取られた次の「エムエスジー」メッセージを処理するかもしれません。
2.6.2 Between Different Channels
2.6.2 異なったチャンネルの間で
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同輩は異なったチャンネルで複数の「エムエスジー」メッセージを送るかもしれません。 チャンネルは独自と、平行で働いています。
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同輩はそれが選ぶどんなオーダーでも異なったチャンネルで受け取られた「エムエスジー」メッセージを処理するかもしれません。 結果として、与えられたチャンネルのための回答は対応する「エムエスジー」メッセージが受信されている同次で発生するように見えますが、異なったチャンネルにおける回答の規制を命令してはいけません。
Rose Standards Track [Page 28] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[28ページ]。
2.6.3 Pre-emptive Replies
2.6.3 先買いの回答
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.
メッセージの最終的な「エムエスジー」フレームを受ける前にサーバーの役割で行動しているBEEP同輩は断りの返事するかもしれません。 そうするなら、そのBEEP同輩がそのメッセージのためにどんなその後の「エムエスジー」フレームも無視するのが強いられます、最終的な「エムエスジー」フレームを含めて。
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.
クライアントの役割で行動しているBEEP同輩が以前否定的な返事を受けるなら、メッセージのために最終的な「エムエスジー」フレームを送ります、完全な状態でa継続状態がある「エムエスジー」フレームを送るそれが必要であるその時、(「」、)、そして、ゼロ・レングスペイロードを持っていること。
2.6.4 Interference
2.6.4 干渉
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.
特定のメッセージの処理が(どちらかのイントラチャンネルかインターチャネル)であるのに配列影響力を他のメッセージに持っているなら、対応するプロフィールはこの振舞い(例えば、メッセージが基本的な輸送マッピングを変更するプロフィール)を定義するはずです。
Rose Standards Track [Page 29] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[29ページ]。
2.7 Peer-to-Peer Behavior
2.7 ピアツーピアの振舞い
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はピアツーピアです--そういうものとして、両方の同輩はこのメモで定義されたすべてのメッセージを受け取る用意ができていなければなりません。 それに従って、クライアントの役割だけで行動できるBEEP同輩がそれであるなら優雅に振る舞わせなければならない開始は「エムエスジー」メッセージを受け取ります。 それに従って、すべてのプロフィールが予期していなかった「エムエスジー」メッセージに答えるための適切なエラーメッセージを提供しなければなりません。
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のピアツーピア自然の結果として、メッセージ番号は単方向、重要です。 すなわち、開始の役割で行動しているビープ音同輩によって送られた「エムエスジー」メッセージのメッセージ番号は聴取の役割で行動しているビープ音同輩によって送られた「エムエスジー」メッセージのメッセージ番号に関係ありません。
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
私: エムエスジー0 1.52120、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <スタート番号は'1'>Iと等しいです:、' ' http://iana.org/beep/SASL/OTP '/><プロフィールuri=I: </スタート>I: 終わりL: エムエスジー0 1.221 116、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <スタート番号は'2'>Lと等しいです:、' <プロフィールuriは' http://iana.org/beep/APEX '/>Lと等しいです: </スタート>L: 終わり
refer to different messages sent on channel zero.
チャンネルゼロで送られた異なったメッセージを参照してください。
Rose Standards Track [Page 30] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[30ページ]。
3. Transport Security
3. 輸送セキュリティ
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:
このドキュメントは1個のプロフィールを定義します:
o the TLS transport security profile, based on TLS version one [3].
o TLS輸送セキュリティはTLSバージョン1に基づいて[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:
L: 接続要求>Iのための<待ち: <の開いている接続>L: RPY0 0.0110、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <挨拶>L: <プロフィールuriは' http://iana.org/beep/TLS '/>Lと等しいです: </挨拶>L: 終わりI: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わりI: エムエスジー0 1.52158、私: コンテントタイプ: + アプリケーション/ビープ音xml I:
Rose Standards Track [Page 31] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[31ページ]。
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
私: <スタート番号は'1'>Iと等しいです:、' ' http://iana.org/beep/TLS '<プロフィールuri=>I:、' <[CDATA[<の持ち合わせの/>]]!>I: </プロフィール>I: </スタート>I: 終わりL: RPY0 1.110 121、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: ' http://iana.org/beep/TLS '<プロフィールuri=>L:、' <[CDATA[<は/>を続かせる]]!>L: </プロフィール>L: 終わり
... 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: RPY0 0.0221、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: 終わりI: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わり
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:
L: 接続要求>Iのための<待ち: <の開いている接続>L: RPY0 0.0268、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/beep/TLS '/>Lと等しいです: </挨拶>L: 終わりI: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I:
Rose Standards Track [Page 32] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[32ページ]。
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: エムエスジー0 1.52158、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <スタート番号は'1'>Iと等しいです:、' ' http://iana.org/beep/TLS '<プロフィールuri=>I:、' <[CDATA[<の持ち合わせの/>]]!>I: </プロフィール>I: </スタート>I: 終わりL: RPY0 1.268 121、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: ' http://iana.org/beep/TLS '<プロフィールuri=>L:、' <[CDATA[<は/>を続かせる]]!>L: </プロフィール>L: 終わり
... 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: RPY0 0.0268、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/beep/TLS '/>Lと等しいです: </挨拶>L: 終わりI: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わり
Rose Standards Track [Page 33] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[33ページ]。
3.1 The TLS Transport Security Profile
3.1 TLS輸送セキュリティプロフィール
Section 6.2 contains the registration for this profile.
セクション6.2はこのプロフィールのための登録を含みます。
3.1.1 Profile Identification and Initialization
3.1.1 プロフィール識別と初期設定
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.
チャンネル作成の間の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
C: エムエスジー0 1.52158C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/TLS '>Cと等しいです:、' <[CDATA[<の持ち合わせの/>]]!>C: </プロフィール>C: </スタート>C: 終わりS: 121秒間のRPY0 1.110: コンテントタイプ: + アプリケーション/ビープ音xml S: S: ' http://iana.org/beep/TLS '<プロフィールuri=>S:、' <[CDATA[<は/>を続かせる]]!>S: </プロフィール>S: 終わり
Rose Standards Track [Page 34] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[34ページ]。
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
C: エムエスジー0 1.52173C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/TLS '>Cと等しいです:、' <[CDATA[<の持ち合わせのバージョン=「おっと」/>]]!>C: </プロフィール>C: </スタート>C: 終わりS: 193秒間のRPY0 1.110: コンテントタイプ: + アプリケーション/ビープ音xml S: S: ' http://iana.org/beep/TLS '<プロフィールuri=>S:、' <[CDATA[<エラーコードは'501'>バージョン属性Sと等しいです: <の持ち合わせの>要素</誤り>で不十分に形成される]]!>S:、' </プロフィール>S: 終わり
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.
この場合、積極的な返事を送りますが(チャンネル作成が成功したので)、カプセル化された応答は操作が失敗した理由に関して指示を含んでいます。
3.1.2 Message Syntax
3.1.2 メッセージ構文
Section 7.2 defines the messages that are used in the TLS transport security profile.
セクション7.2はTLS輸送セキュリティプロフィールで使用されるメッセージを定義します。
Rose Standards Track [Page 35] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[35ページ]。
3.1.3 Message Semantics
3.1.3 メッセージ意味論
3.1.3.1 The Ready Message
3.1.3.1 持ち合わせのメッセージ
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同輩は「準備ができる」要素を処理する前に、どんな未定の回答も生成して、送るまで待たなければなりません。
3.1.3.2 The Proceed Message
3.1.3.2、メッセージを続かせてください。
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同輩がすぐに「準備ができる」メッセージに対して「続いてください」という要素を受け取るとき、それは、それとなく、オール・チャンネル(チャンネルゼロを含んでいます)を閉じて、輸送セキュリティのために基本的な交渉プロセスを開始します。
Rose Standards Track [Page 36] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[36ページ]。
4. User Authentication
4. ユーザー認証
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で拒絶されるかもしれません)。
Rose Standards Track [Page 37] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[37ページ]。
4.1 The SASL Family of Profiles
4.1 プロフィールのSASLファミリー
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:
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メカニズムに対応する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.
承認のアイデンティティの使用: これをオール・チャンネルにとってBEEPセッションの持続時間に利用可能にします。
Rose Standards Track [Page 38] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[38ページ]。
4.1.1 Profile Identification and Initialization
4.1.1 プロフィール識別と初期設定
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.,
例えば、チャンネル作成の間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
C: エムエスジー0 1.52178C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/ANONYMOUS '/>Cと等しいです: <プロフィールuriは' http://iana.org/beep/SASL/OTP '/>Cと等しいです: </スタート>C: 終わりS: 87秒間のRPY0 1.221: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <プロフィールuriは' http://iana.org/beep/SASL/OTP '/>Sと等しいです: 終わり
Rose Standards Track [Page 39] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[39ページ]。
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
C: エムエスジー0 1.52183C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/OTP '>Cと等しいです:、' <[CDATA[<一滴>AGJsb2NrbWFzdGVy</一滴>]]!>C: </プロフィール>C: </スタート>C: 終わりS: 178秒間のRPY0 1.221: コンテントタイプ: + アプリケーション/ビープ音xml S: S: ' http://iana.org/beep/SASL/OTP '<プロフィールuri=>S:、' <!、[CDATA、[<エラーコードが'534'>認証機構と等しい、S: 弱過ぎる</誤り>] >Sです:、' </プロフィール>S: 終わり
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
C: エムエスジー0 1.52183C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/OTP '>Cと等しいです:、' <[CDATA[<一滴>AGJsb2NrbWFzdGVy</一滴>]]!>C: </プロフィール>C: </スタート>C: 終わりS: 171秒間のRPY0 1.221: コンテントタイプ: + アプリケーション/ビープ音xml S: S: ' http://iana.org/beep/SASL/OTP '<プロフィールuri=>S:、' <[CDATA[<一滴>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=</一滴>]]!>S: </プロフィール>S: 終わり
Rose Standards Track [Page 40] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[40ページ]。
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
C: エムエスジー1 0.097C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <一滴>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</一滴>C: 終わりS: 66秒間のRPY1 0.0: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <一滴状態は'完全'/>Sと等しいです: 終わり
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
C: エムエスジー1 0.097C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <一滴>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</一滴>C: 終わりS: 間違え、1 0、.0 60秒間: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <エラーコードは'535'/>Sと等しいです: 終わり
Rose Standards Track [Page 41] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[41ページ]。
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
C: エムエスジー0 1.52125C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/CRAM-MD5 '/>Cと等しいです: </スタート>C: 終わりS: 185秒間のRPY0 1.221: コンテントタイプ: + アプリケーション/ビープ音xml S: S: ' http://iana.org/beep/SASL/CRAM-MD5 '<プロフィールuri=>S:、' <[CDATA[<一滴>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1 jaS5uZXQ+</一滴>]]!>S: </プロフィール>S: 終わり
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つの系列だけが使用されています。
4.1.2 Message Syntax
4.1.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によってコード化されたストリングであることに注意してください。
Rose Standards Track [Page 42] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[42ページ]。
4.1.3 Message Semantics
4.1.3 メッセージ意味論
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つの値の1つを取ります:
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のEXTERNALメカニズムが「外部認証」サービスで働くことに以下に注意してください。(サービスは1時までに提供されます)。
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 存在しているなら、認証のアイデンティティは外部認証サービスで提供する資格証明書と一致しているに違いありません(認証のアイデンティティが空であるなら、外部認証サービスで提供された資格証明書から承認のアイデンティティを自動的に得ます)。
Rose Standards Track [Page 43] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[43ページ]。
5. Registration Templates
5. 登録テンプレート
5.1 Profile Registration Template
5.1 プロフィール登録テンプレート
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.
問い合わせ先: 郵便の、そして、電子の問い合わせ先をプロフィールの作者に指定してください。
5.2 Feature Registration Template
5.2 特徴登録テンプレート
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.
問い合わせ先: 郵便の、そして、電子の問い合わせ先を特徴の作者に指定してください。
Rose Standards Track [Page 44] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[44ページ]。
6. Initial Registrations
6. 初期の登録証明書
6.1 Registration: BEEP Channel Management
6.1登録: ビープ音チャンネル管理
Profile Identification: not applicable
識別の輪郭を描いてください: 適切でない
Messages exchanged during Channel Creation: not applicable
メッセージはChannel Creationの間、交換しました: 適切でない
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.、このメモの「作者のアドレス」セクション
6.2 Registration: TLS Transport Security Profile
6.2登録: TLS輸送セキュリティプロフィール
Profile Identification: http://iana.org/beep/TLS
識別の輪郭を描いてください: http://iana.org/beep/TLS
Messages exchanged during Channel Creation: "ready"
メッセージはChannel Creationの間、交換しました: 「準備ができています」。
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.、このメモの「作者のアドレス」セクション
Rose Standards Track [Page 45] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[45ページ]。
6.3 Registration: SASL Family of Profiles
6.3登録: プロフィールのSASLファミリー
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"
メッセージはChannel Creationの間、交換しました: 「一滴」
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.、このメモの「作者のアドレス」セクション
Rose Standards Track [Page 46] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[46ページ]。
6.4 Registration: application/beep+xml
6.4登録: アプリケーション/ビープ音+xml
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
問題をコード化します: このメディアタイプは2進の内容を含むかもしれません。 それに従って、2進の転送を可能にしない輸送の上で使用されると、適切なコード化を適用しなければなりません。
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
相互運用性問題: なし
Published specification: This media type is a proper subset of the
the XML 1.0 specification [2]. Two restrictions are made.
広められた仕様: このメディアタイプはXML1.0仕様[2]の真部分集合です。 2つの制限をします。
First, no entity references other than the five predefined general
entities references ("&", "<", ">", "'", and
""") and numeric entity references may be present.
「最初に5以外のどんな実体参照も一般実体参照を事前に定義しなかった、("&"、"<"">"、」 apos;、」 """、)、数値実体参照は存在しているかもしれません。
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.)
2番目、どちらの"XML"宣言、(<?例えば、xmlバージョンが等しい、「1インチ?>、)、"DOCTYPE"宣言(例えば、<!DOCTYPE…>)が存在しているかもしれない、」 (UTF-8以外の別の文字集合が望まれているなら、それに従って、"charset"パラメタは存在していなければなりません。)
All other XML 1.0 instructions (e.g., CDATA blocks, processing
instructions, and so on) are allowed.
すべての他のXML1.0指示(例えば、CDATAブロック、処理命令など)が許されています。
Applications which use this media type: any BEEP profile wishing to
make use of this XML 1.0 subset
このメディアタイプを使用するアプリケーション: このXML1.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
Rose Standards Track [Page 47] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[47ページ]。
7. DTDs
7. DTD
7.1 BEEP Channel Management DTD
7.1 ビープ音チャンネル管理DTD
<!--
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;
-->
<!実体%が公共の「-//IETF//DTDビープ音//アン」を鳴らす、「 http://xml.resource.org/profiles/BEEP/beep.dtd 「>%ビープ音」 -->。
<!--
DTD data types:
<!--DTDデータ型:
entity syntax/reference example
====== ================ =======
a channel number
CHAN 1..2147483647 1
実体構文/参照の例====== ================ ======= 論理機番チェン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.
言語タグラングc.f.、[RFC-1766]「アン」、「アン米国」など
zero or more language tags
LOCS NMTOKENS "en-US"
ゼロか、より多くの言語タグLOCS NMTOKENS「アン米国」
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">
<!実体%チェン、「CDATA、「><!実体%ユリ、「CDATA「><!実体%FTRS」NMTOKENS、「><!実体%ラング、「NMTOKEN「><!実体%LOCS」NMTOKEN「><!実体%XYZ」CDATA">"
Rose Standards Track [Page 48] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[48ページ]。
<!--
BEEP messages, exchanged as application/beep+xml
BEEPメッセージであって、アプリケーション/ビープ音+xmlとして交換された<!
role MSG RPY ERR
======= === === ===
I and L greeting error
役割のMSG RPY ERR======= === === === 私とL挨拶誤り
I or L start profile error
私かLスタートプロフィール誤り
I or L close ok error
-->
私かL厳密な間違いない誤り-->。
<!ELEMENT greeting (profile)*>
<!ATTLIST greeting
features %FTRS; #IMPLIED
localize %LOCS; "i-default">
<!ELEMENT挨拶(プロフィール)*><!ATTLIST挨拶特徴%FTRS。 #IMPLIEDは、%がLOCSであるとローカライズします。 「i-デフォルト">"
<!ELEMENT start (profile)+>
<!ATTLIST start
number %CHAN; #REQUIRED
serverName CDATA #IMPLIED>
<!ELEMENTは(プロフィール)+><!ATTLISTスタート番号%チェンを始めます。 #必要なserverName CDATA#は>を含意しました。
<!-- 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近い数の%チェンを閉じます。 「0インチは%XYZをコード化します」。 #REQUIRED xml: lang%ラング。 #暗示している>。
<!ELEMENT ok EMPTY>
<!のELEMENTの間違いないEMPTY>。
<!ELEMENT error (#PCDATA)>
<!ATTLIST error
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT誤り(#PCDATA)><!ATTLISTエラーコード%XYZ。 #REQUIRED xml: lang%ラング。 #暗示している>。
Rose Standards Track [Page 49] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[49ページ]。
7.2 TLS Transport Security Profile DTD
7.2TLSがセキュリティプロフィールDTDを輸送します。
<!--
DTD for the TLS Transport Security Profile, as of 2000-09-04
<!--2000年9月4日現在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公共の「-//IETF//DTD TLS//アン」、「 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><!CDATA「1インチの>」というATTLISTの持ち合わせのバージョン
<!ELEMENT proceed EMPTY>
<!ELEMENTはEMPTY>を続かせます。
Rose Standards Track [Page 50] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[50ページ]。
7.3 SASL Family of Profiles DTD
7.3 プロフィールDTDのSASLファミリー
<!--
DTD for the SASL Family of Profiles, as of 2000-09-04
<!--2000年9月4日現在プロフィールの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公共の「-//IETF//DTD SASL//アン」、「 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====== === === === 私かL一滴一滴誤り-->。
<!ELEMENT blob (#PCDATA)>
<!ATTLIST blob
xml:space (default|preserve)
"preserve"
status (abort|complete|continue)
"continue">
<!ELEMENT一滴(#PCDATA)><!ATTLIST一滴xml: スペース(デフォルト|保護区)「保護区」状態(完全な状態で|中止してください| 続く)、「">"を続けてください。
Rose Standards Track [Page 51] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[51ページ]。
8. Reply Codes
8. 回答コード
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トランザクションは失敗しました。(例えば、方針違反)
Rose Standards Track [Page 52] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[52ページ]。
9. Security Considerations
9. セキュリティ問題
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.
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. 中央の男性は、BEEP挨拶からセキュリティ関連のプロフィールを取り外すか、またはTLS輸送セキュリティプロフィールの「準備ができる」要素に否定的な返事を生成するかもしれません。 合格水準のプライバシーなしで続くのを拒否するのにおいてBEEP同輩は構成可能であるかもしれません。
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. 中央の男性は利用可能な最も弱い暗号スイートに下がっている交渉を引き起こすかもしれません。 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. 中央の男性はうまくいっている交渉の前にどんなプロトコル交換も変更するかもしれません。 交渉を終了すると、BEEP同輩はBEEPセッション頃に以前にキャッシュされた情報を捨てなければなりません。
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.
メッセージに関連しているどんなタスクも実行する前にBEEPが現実にピアツーピアであるので、各チャンネルはBEEPセッションに関連している認証されたアイデンティティとプライバシーレベルに基づく適切なアクセス制御を当てはまるべきです。
Rose Standards Track [Page 53] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[53ページ]。
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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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インチ、W3C XML1998年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.、アレン、C.、Treese、W.、Karlton、P.、フライア、A.、およびP.コッハー、「TLSはバージョン1インチについて議定書の中で述べます、RFC2246、1999年1月」。
[4] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[4] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[5] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[5] M. ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[6] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[7] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[8]ElzとR.とR.ブッシュ、「通し番号演算」、RFC1982、1996年8月。
[9] Alvestrand, H., "Tags for the Identification of Languages", RFC
BCP 47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[9]、RFC BCP47、RFC3066、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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998.
[11] ニューマン、C.、「1つの時間パスワードSASLメカニズム」、RFC2444、1998年10月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[12] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[13]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[14] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[14] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース、バージョン2インチ、RFC2078、1997年1月。」
Rose Standards Track [Page 54] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[54ページ]。
[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>
[15] <http://www.isi.edu/注意している/sasl iana/課題/メカニズム>。
Author's Address
作者のアドレス
Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US
マーシャルT.のバラの目に見えない世界のInc.1179の北のマクドウェル・Boulevardカリフォルニア94954-6559ペタルマ(米国)
Phone: +1 707 789 3700 EMail: mrose@invisible.net URI: http://invisible.net/
以下に電話をしてください。 +1 3700年の707 789メール: mrose@invisible.net ユリ: http://invisible.net/
Rose Standards Track [Page 55] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[55ページ]。
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.
作者は感謝して以下の貢献を承諾します。 デヴィッド・クラーク、デーヴ・クロッカー、スティーブ・デアリング、ウエスリーマイケルEddy、ヒューストン・フランクリン、マルコGazzetta、ダニーGoodman、スティーブ・ハリス、ロバート・エリオ、ケン・ハーシュ、グレッグ・ハドソン、ベン・ローリー、カール・マラマッド、マイケルMealling、キースMcCloghrie、ポールMockapetris、そして、RLはモーガン、フランク・モートン、ダーレンNew、クリス・ニューマン、ジョーTouch、ポールVixie、ゲイブWachob、ダニエル・ウッズを'たたきます'。ジェームスWoodyatt。 特に、デーヴ・クロッカーは分割の本質で縁どりメカニズムに役立つ提案を供給しました。
Rose Standards Track [Page 56] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[56ページ]。
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に居住するのは、お勧めです。
Rose Standards Track [Page 57] RFC 3080 The BEEP Core March 2001
バラ規格は2001年のビープ音コア行進のときにRFC3080を追跡します[57ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rose Standards Track [Page 58]
バラ標準化過程[58ページ]
一覧
スポンサーリンク
