Network Working Group M. Rose
Request for Comments: 3340 Dover Beach Consulting, Inc.
Category: Standards Track G. Klyne
Clearswift Corporation
D. Crocker
Brandenburg InternetWorking
July 2002
The Application Exchange Core
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This memo describes Application Exchange (APEX) Core, an extensible, asynchronous message relaying service for application layer programs.
このメモは、アプリケーション交換（APEX）コア、拡張可能な、アプリケーション層プログラムの非同期メッセージ中継サービスを記述する。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Architecture at a Glance . . . . . . . . . . . . . . . . . 4
2. Service Principles . . . . . . . . . . . . . . . . . . . . 5
2.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . 5
2.2 Naming of Entities . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Comparing Endpoints . . . . . . . . . . . . . . . . . . . 7
3. Service Provisioning . . . . . . . . . . . . . . . . . . . 7
3.1 Connection Establishment . . . . . . . . . . . . . . . . . 7
3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 8
3.5 Relaying Integrity . . . . . . . . . . . . . . . . . . . . 8
3.6 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 9
4. The APEX . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . 9
4.2 Profile Identification and Initialization . . . . . . . . 10
4.3 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Message Semantics . . . . . . . . . . . . . . . . . . . . 11
4.4.1 The Attach Operation . . . . . . . . . . . . . . . . . . . 11
4.4.2 The Bind Operation . . . . . . . . . . . . . . . . . . . . 13
4.4.3 The Terminate Operation . . . . . . . . . . . . . . . . . 14
4.4.4 The Data Operation . . . . . . . . . . . . . . . . . . . . 15
4.4.4.1 Relay Processing of Data . . . . . . . . . . . . . . . . . 17
4.4.4.2 Application Processing of Data . . . . . . . . . . . . . . 18
4.5 APEX Access Policies . . . . . . . . . . . . . . . . . . . 19
4.5.1 Access Policies in the Endpoint-Relay Mode . . . . . . . . 19
4.5.2 Access Policies in the Relay-Relay Mode . . . . . . . . . 20
5. APEX Options . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 The statusRequest Option . . . . . . . . . . . . . . . . . 22
6. APEX Services . . . . . . . . . . . . . . . . . . . . . . 26
6.1 Use of the APEX Core DTD . . . . . . . . . . . . . . . . . 27
6.1.1 Transaction-Identifiers . . . . . . . . . . . . . . . . . 27
6.1.2 The Reply Element . . . . . . . . . . . . . . . . . . . . 28
6.2 The Report Service . . . . . . . . . . . . . . . . . . . . 28
7. Registration Templates . . . . . . . . . . . . . . . . . . 29
7.1 APEX Option Registration Template . . . . . . . . . . . . 29
7.2 APEX Service Registration Template . . . . . . . . . . . . 29
7.3 APEX Endpoint Application Registration Template . . . . . 30
8. Initial Registrations . . . . . . . . . . . . . . . . . . 30
8.1 Registration: The APEX Profile . . . . . . . . . . . . . . 30
8.2 Registration: The System (Well-Known) TCP port number for
apex-mesh . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Registration: The System (Well-Known) TCP port number for
apex-edge . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4 Registration: The statusRequest Option . . . . . . . . . . 31
8.5 Registration: The Report Service . . . . . . . . . . . . . 32
9. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1 The APEX Core DTD . . . . . . . . . . . . . . . . . . . . 32
9.2 The Report Service DTD . . . . . . . . . . . . . . . . . . 34
10. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . 36
References . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39
B. IANA Considerations . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . 40
Network applications can be broadly distinguished by five operational characteristics:
ネットワークアプリケーションは、大きく分けて5つの動作特性によって区別することができます。
o server push or client pull;
サーバプッシュまたはクライアントプルO;
o synchronous (interactive) or asynchronous (batch);
O同期（対話型）または非同期（バッチ）。
o time-assured or time-insensitive;
Oタイム保証または時間と小文字を区別しません。
o best-effort or reliable; and,
ベストエフォート型や信頼性の高いO;そして、
o stateful or stateless.
ステートフルまたはステートレスO。
For example:
例えば：
o the world-wide web is a pull, synchronous, time-insensitive, reliable, stateless service; whilst
ワールドワイドウェブoを引き、同期、時間と小文字を区別しない、信頼性の高い、ステートレスなサービスです。一方で
o Internet mail is a push, asynchronous, time-insensitive, best-effort (without DSN), stateless service.
Oインターネットメールはステートレスサービス、（DSNなし）プッシュ、非同期、時間と小文字を区別しない、ベストエフォートです。
Messaging applications vary considerably in their operational requirements. For example, some messaging applications require assurance of timeliness and reliability, whilst others do not.
メッセージング・アプリケーションは、その運用要件にかなり変化します。他の人がいない間、例えば、いくつかのメッセージングアプリケーションは、適時性と信頼性の保証を必要としています。
These features come at a cost, in terms of both infrastructural and configuration complexity. Accordingly, the underlying service must be extensible to support different requirements in a consistent manner.
これらの機能は、インフラや構成の複雑さの両面で、費用で来ます。したがって、基礎となるサービスは、一貫した方法で、さまざまな要件をサポートするように拡張可能でなければなりません。
This memo defines a core messaging service that supports a range of operational characteristics. The core service supports a variety of tailored services for both user-based and programmatic exchanges.
このメモは動作特性の範囲をサポートしているコア・メッセージング・サービスを定義します。コアサービスは、ユーザーベースとプログラム取引所の両方に合わせたさまざまなサービスをサポートしています。
APEX provides an extensible, asynchronous message relaying service for application layer programs.
APEXは、拡張可能な、アプリケーション層プログラムの非同期メッセージ中継サービスを提供します。
APEX, at its core, provides a best-effort datagram service. Each datagram, simply termed "data", is originated and received by APEX "endpoints" -- applications that dynamically attach to the APEX "relaying mesh".
APEXは、その中核に、ベストエフォート型のデータグラムサービスを提供します。動的APEX「中継網」に添付のアプリケーション - 単に「データ」と呼ばれる各データグラムは、APEX「エンドポイント」によって発信および受信されます。
The data transmitted specifies:
データ送信を指定：
o an originating endpoint;
発信エンドポイントO;
o an opaque content (via a URI-reference);
（URI参照を介して）不透明なコンテンツO。
o one or more recipient endpoints; and,
一の以上の受信者のエンドポイントO;そして、
o zero or more options.
ゼロ以上のオプションのO。
Options are used to alter the semantics of the service, which may occur on a per-recipient or per-data basis, and may be processed by either a single or multiple relays.
オプションは、受信者ごとまたはデータに基づいて発生し得るサービスのセマンティクスを変更するために使用され、単一または複数のリレーによって処理することができます。
Additional APEX services are provided on top of the relaying mesh; e.g., access control and presence information.
追加のAPEXサービスは、中継網の上部に設けられています。例えば、アクセス制御およびプレゼンス情報。
APEX is specified, in part, as a BEEP [1] "profile". Accordingly, many aspects of APEX (e.g., authentication) are provided within the BEEP core. Throughout this memo, the terms "peer", "initiator", "listener", "client", and "server" are used in the context of BEEP. In particular, Section 2.1 of the BEEP core memo discusses the roles that a BEEP peer may perform.
APEXはBEEP [1] "プロファイル" として、部分的には、指定されています。従って、APEX（例えば、認証）の多くの側面は、BEEPコア内に設けられています。このメモを通じて、用語は、「ピア」、「イニシエータ」、「リスナー」、「クライアント」、および「サーバー」BEEPのコンテキストで使用されています。具体的には、BEEPコアメモのセクション2.1は、BEEPピアが実行することができる役割を論じています。
When reading this memo, note that the terms "endpoint" and "relay" are specific to APEX, they do not exist in the context of BEEP.
このメモを読んだとき、用語「エンドポイント」と「リレー」はAPEXに特異的であることに注意してください、彼らはBEEPのコンテキストでは存在しません。
The APEX stack:
APEXスタック：
+-------------+
| APEX | an APEX process is either:
| process |
+-------------+ - an application attached as an APEX
| | endpoint; or,
| APEX |
| | - an APEX relay
+-------------+
| | APEX services are realized as applications
| BEEP | having a special relationship with the APEX
| | relays in their administrative domain
+-------------+
| TCP |
+-------------+
| ... |
+-------------+
The APEX entities:
APEXエンティティ：
administrative domain #1 administrative domain #2
+----------------------------+ +----------------------------+
| +------+ | | +------+ |
| | | | | | | |
| | appl | | | | appl | |
| | | | | | | |
| +......+ +------+ | | +------+ +......+ |
| | | | | | | | | | | |
| |end- | |relay | | | |relay | |end- | |
| | point| | | | | | | | point| |
| +------+ +------+ | | +------+ +------+ |
| | | | | | | | | | | |
| | APEX | | APEX | | | | APEX | | APEX | |
| | | | | | | | | | | |
| +------+ +------+ | | +------+ +------+ |
| || || || | | || || || |
| ============= ================ ============= |
+----------------------------+ +----------------------------+
| <---- APEX relaying mesh ----> |
Note: relaying between administrative domains is configured using SRV RRs. Accordingly, the actual number of relays between two endpoints is not fixed.
注：管理ドメイン間の中継は、SRVのRRを用いて構成されています。従って、2つのエンドポイント間のリレーの実際の数は固定されていません。
APEX is used in two modes:
APEXは、2つのモードで使用されます。
endpoint-relay: in which the endpoint is always the BEEP initiator of the service, whilst relays are always the BEEP listeners. In this context, applications attach as endpoints, and then the transmission of data occurs.
エンドポイント・リレー：リレーはBEEPリスナーが常にある一方で、エンドポイントが、常にサービスのBEEPイニシエータです。この文脈において、アプリケーションは、エンドポイントとして添付し、データの送信が起こります。
relay-relay: in which relays typically, though not necessarily, reside in different administrative domains. In this context, applications bind as relays, and then the transmission of data occurs.
リレーリレー：必ずしも、異なる管理ドメインに存在するが、一般的に中継します。この文脈において、アプリケーションは、リレーのように結合し、データの送信が起こります。
In the endpoint-relay mode, an endpoint (BEEP initiator) may:
エンドポイントリレーモードでは、エンドポイント（BEEP開始剤）があります。
o attach as one or more endpoints;
O 1つ以上のエンドポイントとして添付する。
o send data to other endpoints;
O他のエンドポイントにデータを送信します。
o receive data from other endpoints; and,
O、他のエンドポイントからデータを受信します。そして、
o terminate any of its attachments.
Oその添付ファイルのいずれかを終了します。
A relay (BEEP listener), in addition to servicing requests from a BEEP initiator, may:
BEEPイニシエータからの要求にサービスを提供することに加えて、リレー（BEEPリスナー）、があります。
o terminate any of the endpoint's attachments;
Oエンドポイントの添付ファイルのいずれかを終了します。
o deliver data from other endpoints; and,
O、他のエンドポイントからのデータを配信します。そして、
o indicate the delivery status of data sent earlier by the endpoint.
Oエンドポイントによって以前送信されたデータの配信状態を示しています。
In the relay-relay mode, a relay (BEEP listener or initiator) may:
リレーリレーモードにおいて、リレー（BEEPリスナー又はイニシエータ）があります。
o bind as one or more administrative domains;
O一つ以上の管理ドメインとしてバインド。
o send data;
Oデータを送信します。
o receive data; and,
Oデータを受信し、そして、
o terminate any bindings.
Oすべてのバインディングを終了します。
Endpoints are named using the following ABNF [2] syntax:
エンドポイントは、以下のABNF [2]の構文を使用して名前が付けられます。
;; Domain is defined in [3], either a FQDN or a literal entity = local "@" Domain
;;ドメインは、FQDNまたはドメイン「@」ローカルリテラル実体=のいずれかで、[3]で定義されています
local = address [ "/" subaddress ]
ローカル=アドレス[ "/" サブアドレス]
address = token
アドレス=トークン
subaddress = token
サブアドレス=トークン
;; all non-control characters, excluding "/" and "@" delimiters token = 1*(%x20-2E / %x30-3F / %x41-7E / UTF-8) ;; [4]
;; "/" と "@" 区切り文字を除くすべての非制御文字、トークン= 1 *（％x20-2E /％x30-3F /％x41-7E / UTF-8）;; [4]
Two further conventions are applied when using this syntax:
この構文を使用したときに、2つの更なる規則が適用されます。
the "apex=" convention: All endpoint identities having a local-part starting with "apex=" are reserved for use by APEX services registered with the IANA; and,
「頂点=」大会：で始まるローカル部分を持つすべてのエンドポイントアイデンティティ「頂点=」IANAに登録APEXサービスで使用するために予約されています。そして、
the "subaddress" convention: If the solidus character ("/", decimal code 47) occurs in the local-part, this identifies a subaddress of an endpoint identity (e.g., "fred/appl=wb@example.com" is a subaddress of the APEX endpoint "fred@example.com").
「サブアドレス」大会：ソリダス文字（「/」、10進47）が地元の部分で発生した場合、これは、エンドポイントのアイデンティティ（例えば、「fred/appl=wb@example.com」のサブアドレスを識別し、AでありますAPEXエンドポイント「fred@example.com」のサブアドレス）。
All subaddresses starting with "appl=" are reserved for use by APEX endpoint applications registered with the IANA.
「APPL =」で始まるすべてのサブアドレスは、IANAに登録APEXエンドポイントアプリケーションで使用するために予約されています。
Relays, although not named, serve of behalf of administrative domains, as identified by a FQDN or a domain-literal, e.g., "example.com" or "[10.0.0.1]".
FQDNまたはドメインリテラル、例えば、「example.com」または「[10.0.0.1]」によって識別されるリレーは、名前が付いていないが、管理ドメインの代わりの役割を果たす。
In APEX, "endpoints" and "relays" are the fundamental entities. APEX is carried over BEEP, which has the "peer" as its fundamental entity. The relationship between BEEP peer entities and APEX endpoint and relay entities are defined by APEX's Access Policies (Section 4.5).
APEXでは、「エンドポイント」と「リレーは」基本的なエンティティです。 APEXは、その基本的な実体として「ピア」を持っているBEEP、上で伝送されます。 BEEPピアエンティティとAPEXのエンドポイントとリレーエンティティ間の関係は、APEXのアクセスポリシー（4.5節）によって定義されています。
Note that since the "local" part of an entity is a string of UTF-8 [4] octets, comparison operations on the "local" part use exact matching (i.e., are case-sensitive).
なお、エンティティの「ローカル」部分はUTF-8の文字列があるので、[4]オクテット、「ローカル」部分の使用に比較動作が正確に一致する（すなわち、大文字と小文字が区別されます）。
Accordingly, "fred@example.com" and "Fred@example.com" refer to different endpoints. Of course, relays serving the "example.com" administrative domain may choose to treat the two endpoints identically for the purposes of routing and delivery.
したがって、「fred@example.com」と「Fred@example.com」は、異なるエンドポイントを参照してください。もちろん、「example.com」の管理ドメインにサービスを提供するリレーは、ルーティングと配信のために同一の2つのエンドポイントを処理することもできます。
Finally, note that if an APEX endpoint is represented using a transmission encoding, then, prior to comparison, the encoding is reversed. For example, if the URL encoding is used, then "apex:fred@example.com" is identical to "apex:f%72ed@example.com".
最後に、APEXのエンドポイントが送信符号化を使用して表現される場合、次いで、比較の前に、符号が反転することに注意してください。 URLエンコードが使用されている場合たとえば、その後、「頂点：fred@example.com」は「：f%72ed@example.com頂点」と同じです。
The SRV algorithm [5] is used to determine the IP/TCP addressing information assigned to the relays for an administrative domain identified by a FQDN:
SRVアルゴリズムは、[5] FQDNによって識別される管理ドメインのリレーに割り当てられたIP / TCPアドレス情報を決定するために使用されます。
service: "apex-edge" (for the endpoint-relay mode), or "apex-mesh" (for the relay-relay mode);
サービス：（リレーリレーモード）（エンドポイントリレーモード）、「頂端」、または「頂点メッシュ」。
protocol: "tcp"; and,
プロトコル：「TCP」。そして、
domain: the administrative domain.
ドメイン：管理ドメイン。
If the administrative domain is identified by a domain-literal, then the IP address information is taken directly from the literal and the TCP port number used is assigned by the IANA for the registration in Section 8.2.
管理ドメインは、ドメインリテラルで識別されている場合は、IPアドレス情報がリテラルから直接取得され、使用するTCPポート番号は、8.2節で登録のためにIANAによって割り当てられます。
Authentication is a matter of provisioning for each BEEP peer (c.f., Section 4.5).
認証は、各BEEPピア（C.F.、4.5節）のプロビジョニングの問題です。
An APEX relay might be provisioned to allow a BEEP peer identity to coincide with a given endpoint identity. For example, a relay in the "example.com" administrative domain may be configured to allow a BEEP peer identified as "fred@example.com" to be authorized to attach as the APEX endpoint "fred@example.com".
APEXリレーは、特定のエンドポイントのIDと一致するBEEPピアのアイデンティティを許可するようにプロビジョニングされる可能性があります。例えば、「example.com」の管理ドメイン内の中継は、APEXエンドポイント「fred@example.com」としてアタッチすることを許可される「fred@example.com」として識別BEEPピアを可能にするように構成されてもよいです。
Authorization is a matter of provisioning for each BEEP peer (c.f., Section 4.5).
認可は、各BEEPピア（C.F.、4.5節）のためのプロビジョニングの問題です。
Typically, a relay requires that its BEEP peer authenticate as a prelude to authorization, but an endpoint usually does not require the same of its BEEP peer.
一般的に、リレーは、そのBEEPピアが認可の前置きとして認証する必要がありますが、エンドポイントは、通常、そのBEEPピアの同じを必要としません。
Confidentiality is a matter of provisioning for each BEEP peer.
守秘義務は、各BEEPピアのためのプロビジョニングの問題です。
Typically, any data considered sensitive by an originating endpoint will have its content encrypted for the intended recipient endpoint(s), rather than relying on hop-by-hop encryption. Similarly, an originating endpoint will sign the content if end-to-end authentication is desired.
典型的には、発信元エンドポイントにより敏感であると考えられる任意のデータは、その内容ではなくホップ・バイ・ホップの暗号化に頼るよりも、意図された受信者エンドポイント（複数可）のために暗号化されているであろう。エンドツーエンドの認証が望まれる場合同様、発信エンドポイントは、コンテンツに署名します。
Data are relayed according to SRV entries in the DNS. Accordingly, relaying integrity is a function of the DNS and the applications making use of the DNS. Additional assurance is provided if the BEEP initiator requires that the BEEP listener authenticate itself.
データは、DNSでSRVエントリに従って中継されます。したがって、整合性を中継することはDNSおよびDNSを利用したアプリケーションの機能です。 BEEPイニシエータは、BEEPリスナーが自身を認証することを要求する場合は、追加の保証が提供されます。
Hop-by-hop protection of data transmitted through the relaying mesh (endpoint identities and content) is afforded at the BEEP level through the use of a transport security profile. Other traffic characteristics, e.g., volume and timing of transmissions, are not protected from third-party analysis.
中継メッシュ（エンドポイントIDとコンテンツ）を介して送信されたデータのホップバイホップ保護は、トランスポート・セキュリティ・プロファイルの使用を介してBEEPレベルで与えられます。他のトラフィック特性は、例えば、ボリュームおよび送信のタイミング、サードパーティの解析から保護されていません。
Section 8.1 contains the BEEP profile registration for APEX.
8.1節には、APEXのためのBEEPプロフィールの登録が含まれています。
Each BEEP payload exchanged via APEX consists of an XML document and possibly an arbitrary MIME content.
APEXを介して交換各BEEPペイロードは、XML文書およびおそらく任意のMIMEコンテンツから成ります。
If only an XML document is sent in the BEEP payload, then the mapping to a BEEP payload is straight-forward, e.g.,
のみXML文書がBEEPペイロードで送られる場合、BEEPペイロードへのマッピングは、例えば、ストレートフォワードであります
C: MSG 1 2 . 111 39 C: Content-Type: application/beep+xml C: C: <terminate transID='1' /> C: END
C：MSG 1 2。 111 39 C：コンテンツタイプ：アプリケーション/ビープ+ XMLのC：C：END：C <TRANSID = '1' /終了>を
Otherwise, if an arbitrary MIME content is present, it is indicated by a URI-reference [6] in the XML control document. The URI-reference may contain an absolute-URI (and possibly a fragment-identifier), or it may be a relative-URI consisting only of a fragment-identifier. Arbitrary MIME content is included in the BEEP payload by using a "multipart/related" [7], identified using a "cid" URL [8], and the XML control document occurs as the start of the "multipart/related", e.g.,
任意のMIMEコンテンツが存在する場合それ以外の場合、それはXMLコントロール文書におけるURI参照[6]で示されています。 URI参照は絶対URI（およびおそらくフラグメント識別子）を含んでいてもよい、又はそれだけフラグメント識別子からなる相対URIであってもよいです。任意のMIMEコンテンツは、[7]「関連/マルチパート」を用いてBEEPペイロードに含まれる[8]「CID」URLを使用して識別され、XMLコントロール文書が「マルチパート/関連」、例えば開始として起こります、
C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C: start="<1@example.com>";
C: type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C: <originator identity='fred@example.com' />
C: <recipient identity='barney@example.com' />
C: </data>
C: --boundary C: Content-Type: image/gif C: Content-Transfer-Encoding: binary C: Content-ID: <2@example.com> C: C: ... C: --boundary-- C: END
C：--boundary C：コンテンツタイプ：画像/ gif形式のC：コンテンツ転送エンコード：バイナリC：のContent-ID：<2@example.com> C：C：... C：--boundary-- C：END
Because BEEP provides an 8bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used. Further, note that MIME [9] requires that the value of the "Content-ID" header be globally unique.
BEEPは、8ビット幅の経路を提供するので、「変革」コンテンツ転送符号化（例えば、「BASE64」または「引用符で囲まれた印刷可能」）に使用されるべきではありません。さらに、MIME [9]の「Content-ID」ヘッダの値はグローバルに一意であることを必要とすることに注意してください。
If the arbitrary MIME content is itself an XML document, it may be contained within the control document directly as a "data-content" element, and identified using a URI-reference consisting of only a fragment-identifier, e.g.,
任意のMIMEコンテンツは、XMLドキュメント自体である場合、それは、例えば、直接「データ内容」要素などの制御文書内に含まれ、そしてだけフラグメント識別子からなるURI参照を用いて同定することができます
C: MSG 1 1 . 42 295 C: Content-Type: application/beep+xml C: C: <data content='#Content'> C: <originator identity='fred@example.com' /> C: <recipient identity='barney@example.com' /> C: <data-content Name='Content'> C: <statusResponse transID='86'> C: <destination identity='barney@example.com'> C: <reply code='250' /> C: </destination> C: </statusResponse> C: </data-content> C: </data> C: END
C：MSG 1 1。 42 295 C：のContent-Type：アプリケーション/ビープ音+ XMLのC：C：<データコンテンツ= '＃コンテンツ'> C：<創始identity='fred@example.com '/> C：<受信者の身元=' バーニー@ example.com '/> C <データコンテンツ名= 'コンテンツ'> C <statusResponse TRANSID = '86 '> C <先identity='barney@example.com'> C <応答コード=' 250 '/> C </宛先> C </ statusResponse> C </データコンテンツ> C </データ> C：END
The APEX is identified as
APEXは、次のように識別されます
http://iana.org/beep/APEX
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／あぺＸ
in the BEEP "profile" element during channel creation.
チャネルの作成中にBEEP「プロファイル」要素インチ
No elements are required to be exchanged during channel creation; however, in the endpoint-relay mode, the BEEP initiator will typically include an "attach" element during channel creation, e.g.,
何の要素は、チャネルの作成中に交換する必要はありません。しかし、エンドポイント中継モードでは、BEEP開始剤は、典型的には、例えば、チャネルの作成時に「アタッチ」要素が含まれます
<start number='1'> <profile uri='http://iana.org/beep/APEX'> <![CDATA[<attach endpoint='fred@example.com' transID='1' />]]> </profile> </start>
<開始番号= '1'> <プロファイルのuri = 'のhttp：//iana.org/beep/APEX'> <！[CDATA [<添付endpoint='fred@example.com」TRANSID = '1' />] ]> </プロフィール> </>を開始
Similarly, in the relay-relay mode, the BEEP initiator will typically include an "bind" element during channel creation, e.g.,
同様に、リレーリレーモードでは、BEEP開始剤は、典型的には、例えば、チャネルの作成時に「バインド」要素が含まれます
<start number='1'> <profile uri='http://iana.org/beep/APEX'> <![CDATA[<bind relay='example.com' transID='1' />]]> </profile> </start>
<数=開始 '1'> <プロファイルのuri = 'のhttp：//iana.org/beep/APEX'> <！[CDATA [<バインドリレー= 'example.com' TRANSID = '1' />]]> </プロフィール> </スタート>
Section 9.1 defines the BEEP payloads that are used in the APEX.
9.1節は、APEXで使用されているBEEPペイロードを定義します。
When an application wants to attach to the relaying mesh as a given endpoint, it sends an "attach" element to a relay, e.g.,
アプリケーションが特定のエンドポイントとして、中継網に接続しようとするとき、それは、例えば、リレーに「添付」要素を送ります
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' /> S: <ok />
C：<添付endpoint='fred@example.com」TRANSID = '1' /> S：<OK />
or
または
+-------+ +-------+
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
| appl. | | relay |
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' /> S: <ok /> C: <attach endpoint='wilma@example.com' transID='2' /> S: <ok />
C：<添付endpoint='fred@example.com 'TRANSID = '1'/> S：<OK /> C <endpoint='wilma@example.comを添付' TRANSID = '2' /> S：<OK />
or
または
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' /> S: <error code='537'>access denied</error>
C：<添付endpoint='fred@example.com」TRANSID = '1' /> S：<エラーコード= '537'>アクセスが拒否されました。</エラー>
The "attach" element has an "endpoint" attribute, a "transID" attribute, and contains zero or more "option" elements:
「添付」要素は、「エンドポイント」属性、「TRANSID」属性を持ち、ゼロまたはそれ以上の「オプション」の要素が含まれています。
o the "endpoint" attribute specifies the endpoint that the application wants to attach as;
O「エンドポイント」属性は、アプリケーションがのように添付したいエンドポイントを指定します。
o the "transID" attribute specifies the transaction-identifier associated with this operation; and,
O「TRANSID」属性は、この操作に関連するトランザクション識別子を指定します。そして、
o the "option" elements, if any, specify additional processing options (Section 5).
「オプション」の要素O、もしあれば、追加の処理オプション（第5節）を指定します。
When a relay receives an "attach" element, it performs these steps:
リレーは「添付」要素を受信すると、次の手順を実行します。
1. If the transaction-identifier refers to a previous, non-terminated operation on this BEEP channel, an "error" element having code 555 is returned.
1.トランザクション識別子このBEEPチャネル上で以前、非終了操作を参照している場合、コード555を有する「エラー」要素が返されます。
2. If the relay is in a different administrative domain than this endpoint, an "error" element having code 553 is returned.
前記リレーは、このエンドポイントは別の管理ドメイン内にある場合は、コード553を有する「エラー」要素が返されます。
3. If the application is not authorized to attach as this endpoint (c.f., Section 4.5.1), an "error" element having code 537 is returned.
アプリケーションは、このエンドポイント（C.F.、セクション4.5.1）としてアタッチすることを許可されていない場合3.コード537を有する「エラー」要素が返されます。
5. If another application has already attached as this endpoint, an "error" element having code 554 is returned.
5.別のアプリケーションがすでにこのエンドポイントとして接続している場合、コード554を有する「エラー」要素が返されます。
6. Otherwise, the application is bound as this endpoint, and an "ok" element is returned.
6.それ以外の場合、アプリケーションはこのエンドポイントとしてバインドされ、「OK」要素が返されます。
When an application wants to identify itself as a relay, it sends a "bind" element to another relay, e.g.,
アプリケーションがリレーとして自身を識別したいとき、それは、例えば、別のリレーに「バインド」要素を送信します
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
C: <bind relay='example.com' transID='1' /> S: <ok />
C：<バインドリレー= 'example.com' TRANSID = '1' /> S：<OK />
or
または
+-------+ +-------+
| | -- bind -------> | |
| | | |
| | <--------- ok -- | |
| relay | | relay |
| #1 | -- bind -------> | #2 |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
C: <bind relay='example.com' transID='1' /> S: <ok /> C: <bind relay='rubble.com' transID='2' /> S: <ok />
C：<バインドリレー= 'example.com' TRANSID = '1' /> S：<OK /> C <バインドリレー= 'rubble.com' TRANSID = '2' /> S：<OK />
or
または
+-------+ +-------+
| | -- bind -------> | |
| relay | | relay |
| #1 | <------ error -- | #2 |
+-------+ +-------+
C: <bind relay='example.com' transID='1' /> S: <error code='537'>access denied</error>
C：<バインドリレー= 'example.com' TRANSID = '1' /> S：<エラーコード= '537'>アクセスが拒否されました。</エラー>
The "bind" element has a "relay" attribute, a "transID" attribute, and contains zero or more "option" elements:
「バインド」要素は、「リレー」属性、「TRANSID」属性を持ち、ゼロまたはそれ以上の「オプション」の要素が含まれています。
o the "relay" attribute specifies the administrative domain on whose behalf the application wants to serve;
属性は、アプリケーションがサービスを提供したいと考え、その代わりに、管理ドメインを指定し、「リレー」O。
o the "transID" attribute specifies the transaction-identifier associated with this operation; and,
O「TRANSID」属性は、この操作に関連するトランザクション識別子を指定します。そして、
o the "option" elements, if any, specify additional processing options (Section 5).
「オプション」の要素O、もしあれば、追加の処理オプション（第5節）を指定します。
When a relay receives an "bind" element, it performs these steps:
リレーは、「バインド」要素を受信すると、次の手順を実行します。
1. If the transaction-identifier refers to a previous, non-terminated operation on this BEEP channel, an "error" element having code 555 is returned.
1.トランザクション識別子このBEEPチャネル上で以前、非終了操作を参照している場合、コード555を有する「エラー」要素が返されます。
2. If the application is not authorized to bind on behalf of this administrative domain (c.f., Section 4.5.2), an "error" element having code 537 is returned.
アプリケーションは、この管理ドメイン（C.F.、セクション4.5.2）に代わってバインドするために許可されていない2.場合は、コード537を有する「エラー」の要素が返されます。
4. Otherwise, the application is accepted as serving this administrative domain, and an "ok" element is returned.
4.それ以外の場合、アプリケーションは、この管理ドメインにサービスを提供するものとして受け入れられ、「OK」要素が返されます。
When an application or relay wants to release an attachment or binding, it sends a "terminate" element, e.g.,
アプリケーションまたはリレーが添付または結合を解除したい場合、それは、例えば、「終了」の要素を送信します
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <terminate transID='1' /> S: <ok />
C：S <= '1' / TRANSIDを終了>：<OK />
or
または
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
C: <terminate transID='13' /> S: <error code='550'>unknown transaction-identifier</error>
C：<終了TRANSID = '13' /> S <エラーコード= '550'>未知のトランザクション識別子</エラー>
or
または
+-------+ +-------+
| | <-- terminate -- | |
| appl. | | relay |
| | -- ok ---------> | |
+-------+ +-------+
C: <terminate transID='1' /> S: <ok />
C：S <= '1' / TRANSIDを終了>：<OK />
The "terminate" element has a "transID" attribute, an optional "code" attribute, an optional "xml:lang" attribute, and may contain arbitrary textual content:
「終了」要素は「TRANSID」属性、任意選択の「コード」属性、任意「XML：langの」持っている属性を、任意のテキストコンテンツを含んでいてもよいです。
o the "transID" attribute specifies the transaction-identifier associated with this operation;
O「TRANSID」属性は、この操作に関連するトランザクション識別子を指定します。
o the "code" attribute, if present, is a three-digit reply code meaningful to programs (c.f., Section 10);
「コード」属性O、存在する場合には、プログラム（C.F.、セクション10）に意味のある3桁の応答コードです。
o the "xml:lang" attribute, if present, specifies the language that the element's content is written in; and,
「XML：LANG」O属性が存在する場合、要素の内容が書き込まれていることの言語を指定します。そして、
o the textual content is a diagnostic (possibly multiline) which is meaningful to implementers, perhaps administrators, and possibly even users.
Oテキストコンテンツは、おそらく実装者、管理者、およびおそらくはユーザにとって意味のある診断（おそらく複数行）です。
When an application or relay receives a "terminate" element, it performs these steps:
アプリケーションまたはリレーが「終了」エレメントを受信すると、これらのステップを実行します。
1. If the value of the transaction-identifier is zero, then all associations established by this application over this BEEP session, either as an endpoint attachment or a relay binding, are terminated, and an "ok" element is returned.
1.トランザクション識別子の値がゼロである場合は、すべての関連付けがこのBEEPセッションを介して、このアプリケーションによって確立を、いずれかのエンドポイント付着または結合リレーとして、終了され、そして「OK」要素が返されます。
2. Otherwise, if the transaction-identifier does not refer to a previous unterminated operation on this BEEP channel, an "error" element having code 550 is returned.
トランザクション識別子は、このBEEPチャネル上で前終端されていない操作を参照していない場合2.そうでない場合は、コード550を有する「エラー」要素が返されます。
3. Otherwise, the application is no longer bound as an endpoint or a relay, and an "ok" element is returned.
3.それ以外の場合、アプリケーションはもはやエンドポイントまたはリレーとしてバインドされていない、そして「OK」要素が返されます。
When an application or relay wants to transmit data over the relaying mesh, it sends a "data" element, e.g.,
アプリケーションまたはリレーが中継メッシュを介してデータを送信したい場合、それは、例えば、「データ」エレメントを送信します
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@example.com' /> </data> S: <ok />
C：<データコンテンツ= 'CID：1@example.com'> <創始identity='fred@example.com '/> <受信者identity='barney@example.com' /> </データ> S：<OK />
or
または
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <------ error -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@example.com' /> </data> S: <error code='537'>access denied</error>
C：<データコンテンツ= 'CID：1@example.com'> <発信identity='fred@example.com '/> <受信者identity='barney@example.com' /> </データ> S <エラーコード= '537'>アクセス拒否</エラー>
or
または
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@example.com' /> </data> S: <ok />
C：<データコンテンツ= 'CID：1@example.com'> <創始identity='fred@example.com '/> <受信者identity='barney@example.com' /> </データ> S：<OK />
The "data" element has a "content" attribute, and contains an "originator" element, one or more "recipient" elements, zero or more "option" elements, and, optionally, a "data-content" element:
「データ」要素は、「コンテンツ」属性を有し、「発信」要素、1つ以上の「受信者」要素、ゼロ以上の「オプション」の要素、及び、必要に応じて、「データ内容」要素が含まれています。
o the "content" attribute is a URI-reference that specifies the contents of the data (c.f., Section 4.1);
「コンテンツ」属性Oデータ（C.F.、セクション4.1）の内容を指定するURI参照です。
o the "originator" element refers to the endpoint sending the data;
O「発信」要素は、データを送信するエンドポイントを指します。
o each "recipient" element refers to an endpoint destination for the data;
O各「レシピエント」要素は、データ用のエンドポイントの宛先を指します。
o the "option" elements, if any, specify additional processing options (Section 5), termed per-data options; and,
「オプション」の要素O、もしあれば、追加の処理オプション（セクション5）と呼ばれる単位のデータオプションを指定します。そして、
o the "data-content" element, if present, specifies a nested XML entity that is referenced using a URI fragment-identifier as the value of the "content" attribute.
O「データ内容」要素は、存在する場合、「コンテンツ」属性の値としてURIフラグメント識別子を使用して参照されているネストされたXMLエンティティを指定します。
The "originator" element has an "identity" attribute, and contains zero or more option elements:
「発信元」要素は、「アイデンティティ」の属性を持ち、ゼロ個以上のオプションの要素が含まれています。
o the "identity" attribute specifies the sending endpoint; and
O「アイデンティティ」属性は、送信エンドポイントを指定します。そして
o the "option" elements, if any, specify additional processing options for the originator, termed per-originator options.
「オプション」の要素O、もしあれば、あたりの発信元のオプションと呼ばれる、発信するための追加の処理オプションを指定します。
Each "recipient" element has an "identity" attribute, and contains zero or more option elements:
各「受信者」要素は、「アイデンティティ」の属性を持ち、ゼロ個以上のオプションの要素が含まれています。
o the "identity" attribute specifies the destination endpoint; and
O「アイデンティティ」属性は、宛先エンドポイントを指定します。そして
o the "option" elements, if any, specify additional processing options for this recipient, termed per-recipient options.
「オプション」の要素O、もしあれば、受信者ごとのオプションと呼ばれるこの受信者のための追加の処理オプションを指定します。
When a relay receives a "data" element, it performs these steps:
リレーは、「データ」要素を受信すると、次の手順を実行します。
1. If the BEEP client is not authorized to originate or relay data on behalf of the "originator" endpoint (c.f., Section 4.5), an "error" element having code 537 is returned.
1. BEEPクライアントは、コード537を有する「エラー」の要素が返され、「発信元」のエンドポイント（C.F.、セクション4.5）の代わりにデータを発信または中継するために許可されていない場合。
2. If the recipient endpoint is not in the administrative domain associated with the relay, then an APEX session is established to a relay that accepts data for the recipient's administrative domain, and a new "data" element, containing that "recipient" element and all applicable options, is sent to that relay.
受信者のエンドポイントはリレーに関連する管理ドメイン内にない場合は2、その後、APEXのセッションはその「受信者」の要素を含む、受信者の管理ドメインのためのデータを受け付け、リレー、および新しい「データ」の要素に確立され、すべての適用可能なオプションは、そのリレーに送信されます。
If an APEX session is established, the new "data" is sent, and the recipient's relay returns an "ok" element, then the recipient is considered to be successfully processed.
APEXのセッションが確立されている場合は、新たに「データ」は送信され、受信者のリレーが「OK」の要素を返し、その後、受信者が正常に処理されていると考えられます。
3. Otherwise, if the recipient endpoint is in the same administrative domain as the relay, the APEX access service must check that the originator endpoint is allowed to communicate with the recipient endpoint (the access entries [10] whose "owner" is the recipient must contain a "core:data" token for the originator), and the recipient endpoint must be currently attached.
3.受信者エンドポイントがリレーと同じ管理ドメイン内にあればそうでない場合は、APEXアクセスサービスは、発信エンドポイントは、その「所有者」受信者である受信者エンドポイント（アクセスエントリ[10]との通信を許可されていることを確認しなければなりません）発信者のために：「データコア」トークン、および受信者のエンドポイントは、現在接続されている必要があり含まれている必要があります。
If so, a new "data" element, containing only that "recipient" element, is sent to the corresponding application. If the recipient's endpoint returns an "ok" element, then the recipient is considered to be successfully processed.
もしそうなら、それだけで「受信者」の要素を含む新しい「データ」要素は、対応するアプリケーションに送信されます。受信者のエンドポイントは、「OK」の要素を返す場合、受信者は、正常に処理されていると考えられます。
Providing that these semantics are preserved, a relay may choose to optimize its behavior by grouping multiple recipients in a single "data" element that is subsequently transmitted.
これらのセマンティクスが保存されていることを提供することで、リレーは次に送信される単一の「データ」要素に複数の受信者をグループ化することによって、その動作を最適化することもできます。
Finally, note that a relay receiving a "data" element from an application may be configured to add administrative-specific options.
最後に、アプリケーションから「データ」エレメントを受信するリレー管理者固有のオプションを追加するように構成されてもよいことに留意されたいです。
Regardless, all relays are expressly forbidden from modifying the content of the "data" element at any time.
かかわらず、すべてのリレーが明確に任意の時点で「データ」要素の内容を変更することが禁止されています。
When an application receives a "data" element, it performs these steps:
アプリケーションが「データ」エレメントを受信すると、これらのステップを実行します。
1. If any per-data or per-originator options are present, they are not processed (but may be noted).
1.任意のデータ単位または発信オプションが存在する場合、それらは処理されていない（ただし、留意されてもよいです）。
1. If any per-recipient options are present, they are not processed (but may be noted).
1.任意の受信者ごとのオプションが存在する場合、それらは処理されていない（ただし、留意されてもよいです）。
2. If the application is not attached as the recipient endpoint, then an error in processing has occurred.
2.アプリケーションが受信者エンドポイントとして接続されていない場合、その後の処理でエラーが発生しました。
3. Otherwise, the "data" element is further processed in an application-specific manner, and the recipient is considered to be successfully processed.
3.それ以外の場合は、「データ」エレメントは、さらに、アプリケーション固有の方法で処理され、受信者が正常に処理されると考えられます。
3. If no recipients could be successfully processed, an "error" element is returned; otherwise, an "ok" element is returned.
何の受信者は、正常に処理できなかった場合は3、「エラー」の要素が返されます。そうでない場合は、「OK」要素が返されます。
Access to APEX is provided by the juxtaposition of:
APEXへのアクセスは、の並置によって提供されています。
o authenticating as a BEEP peer;
BEEPピアとして認証O。
o attaching as an APEX endpoint or binding as an APEX relay; and,
APEXエンドポイントとして付着又はAPEXリレーとして結合、O。そして、
o being listed as an actor by the APEX access service (c.f., [10]).
APEXアクセスサービス（C.F.、[10]）によって俳優としてリストされ、O。
Each of these activities occurs according to the policies of the relevant administrative domain:
これらの活動のそれぞれは、関連する管理ドメインのポリシーに従って行われます。
o each administrative domain is responsible for keeping its own house in order through "local provisioning"; and,
O各管理ドメインは、「地元のプロビジョニング」を通じてために、自身の家を維持する責任があります。そして、
o each administrative domain decides the level of trust to associate with other administrative domains.
O各管理ドメインは、他の管理ドメインに関連付ける信頼のレベルを決定します。
o When an application wants to attach to the relaying mesh, local provisioning maps BEEP peer identities to allowed APEX endpoints (c.f., Step 3 of Section 4.4.1).
アプリケーションは、中継網に接続したい場合には、O、地元のプロビジョニングは、APEXエンドポイント（C.F.、セクション4.4.1のステップ3）を許可するBEEPピアIDをマップします。
Typically, the identity function is used, e.g., if an application authenticates itself as the BEEP peer named as "fred@example.com", it is allowed to attach as the APEX endpoint named as "fred@example.com".
識別機能を使用するアプリケーションが「fred@example.com」と命名BEEPピアとして自身を認証する場合、典型的には、例えば、「fred@example.com」と命名APEXエンドポイントとして付着させることができます。
However, using the "subaddress" convention of Section 2.2, an application authorized to attach as a given APEX endpoint is also authorized to attach as any subaddress of that APEX endpoint, e.g., an application authorized to attach as the APEX endpoint "fred@example.com" is also authorized to attach as the APEX endpoint "fred/appl=wb@example.com".
しかし、2.2節の「サブアドレス」規則を使用して、アプリケーションはまた、例えばそのAPEXエンドポイントのいずれかのサブアドレスとして添付することが許可された特定のAPEXエンドポイント、APEXのエンドポイント「の例@フレッドとして添付することが許可アプリケーションとして添付することが許可しました.COMはfred/appl=wb@example.com 『」また、APEXエンドポイントとして添付することが許可されます』。
o When an application wants to send data, local provisioning maps attached endpoints to allowed originators (c.f., Step 1 of Section 4.4.4.1).
Oアプリケーションは、ローカルプロビジョニングマップが許さオリジネーター（C.F.、セクション4.4.4.1のステップ1）にエンドポイントを添付、データを送信したいときに。
Typically, the identity function is used, e.g., if an application attaches as the APEX endpoint named as "fred@example.com", it is allowed to send data originating from the same APEX endpoint. However, other policies are permissible, for example, the administrative domain may allow the application attached as the APEX endpoint named as "wilma@example.com" to send data originating as either "wilma@example.com" or "fred@example.com".
識別機能を使用するアプリケーションが「fred@example.com」と命名APEXエンドポイントとして接続されている場合、典型的には、例えば、同じAPEXエンドポイントからのデータを送信することを許可されています。しかし、他のポリシーは、たとえば、管理ドメインは、「wilma@example.com」という名前のAPEXエンドポイントとして添付アプリケーションは例@のどちらか「wilma@example.com」または「フレッドと元のデータを送信することを可能にする、許容されます。 COM」。
o Finally, when a relay is delivering to an endpoint within its own administrative domain, it consults the recipient's access entry looking for an entry having the originator as an actor (c.f., Step 5.3 of Section 4.4.4.1).
リレーは、独自の管理ドメイン内のエンドポイントに配信しているときO最後に、それは俳優（C.F.、セクション4.4.4.1のステップ5.3）として発信元を持つエントリを探して、受信者のアクセスエントリを調べます。
o When an application wants to bind as a relay on behalf of an administrative domain, local provisioning may map BEEP peer identities to allowed APEX relays (c.f., Step 3).
アプリケーションは、管理ドメインの代わりにリレーとしてバインドしたい場合は、O、地元のプロビジョニングは、APEXリレー（C.F.、ステップ3）を許可するBEEPピアIDをマッピングすることができます。
If so, then typically the identity function is used. e.g., if an application authenticates itself as the BEEP peer named as "example.com", it is allowed to bind as a relay on behalf of the administrative domain "example.com".
もしそうなら、その後、典型的アイデンティティの機能が使用されています。アプリケーションは、「example.com」という名前のBEEPピアとしての地位を認証する場合、例えば、管理ドメイン「example.com」の代わりにリレーとして結合させます。
o When a relay is sending data, no access policies, per se, are applied.
リレーは、それ自体がデータなしアクセスポリシーを、送信しているときは、O、適用されます。
o When a relay is receiving data, local provisioning maps BEEP peer identities to allowed originators (c.f., Step 1 of Section 4.4.4.1).
リレーがデータを受信している場合、O、ローカルプロビジョニングはオリジネーター（C.F.、セクション4.4.4.1のステップ1）を許可するBEEPピアIDをマッピングします。
Typically, the identity function is used, e.g., if a relay authenticates itself as being from the same administrative domain as the originator of the data, then the data is accepted.
リレーは、データの発信元と同じ管理ドメインからのものとしてそれ自体を認証する場合、典型的には、識別機能は、例えば、使用され、その後、データが受け付けられます。
In addition, some relays may also be configured as "trusted" intermediaries, so that if a BEEP peer authenticates itself as being from such a relay, then the data is accepted.
BEEPピアは、リレーからのものとしてそれ自体を認証する場合、データが受け入れられるように加えて、いくつかのリレーはまた、「信頼できる」媒体として構成することができます。
APEX, at its core, provides a best-effort datagram service. Options are used to alter the semantics of the core service.
APEXは、その中核に、ベストエフォート型のデータグラムサービスを提供します。オプションは、コアサービスのセマンティクスを変更するために使用されています。
The semantics of the APEX "option" element are context-specific. Accordingly, the specification of an APEX option must define:
APEX「オプション」の要素の意味はコンテキスト固有です。したがって、APEXオプションの指定は定義する必要があります。
o the identity of the option;
オプションの身元O;
o the context in which the option may appear;
オプションが表示される可能性のある状況O;
o what content, if any, is contained within the option; and,
Oどのようなコンテンツがあれば、オプションの中に含まれています。そして、
o the processing rules for the option.
オプションの処理ルールO。
An option registration template (Section 7.1) organizes this information.
オプションの登録テンプレート（7.1節）は、この情報を整理します。
An "option" element is contained within either a "data", "originator", "recipient", or an "attach" element, all of which are termed the "containing" element. The "option" element has several attributes and contains arbitrary content:
「オプション」の要素は、「データ」、「発信元」、「受信者」、または「含む」要素と呼ばれるすべてが「添付」要素、いずれかの内に含まれています。 「オプション」の要素は、いくつかの属性を持っており、任意のコンテンツが含まれています。
o the "internal" and the "external" attributes, exactly one of which is present, uniquely identify the option;
存在する正確一つは、「内部」および属性「外部」O、一意のオプションを識別する。
o the "targetHop" attribute specifies which relays should process the option;
O「targetHop」属性は、リレーがオプションを処理すべきかを指定します。
o the "mustUnderstand" attribute specifies whether the option, if unrecognized, must cause an error in processing to occur;
O「のmustUnderstand」属性はオプションで、認識されない場合、発生する処理でエラーが発生しなければならないかどうかを指定します。
o the "transID" attribute specifies a transaction-identifier for the option; and,
O「TRANSID」属性は、オプションのトランザクション識別子を指定します。そして、
o the "localize" attribute, if present, specifies one or more language tokens, each identifying a desirable language tag to be used if textual diagnostics are returned to the originator.
「局在化」属性O、存在する場合、テキストの診断が元に戻された場合、望ましい言語タグを識別するそれぞれが使用する、一つ以上の言語のトークンを指定します。
Note that if the containing element is an "attach", then the values of the "targetHop" and "transID" attributes are ignored.
含まれている要素がある場合は、「添付」、そして「targetHop」と「TRANSID」属性の値が無視されることに注意してください。
The value of the "internal" attribute is the IANA-registered name for the option. If the "internal" attribute is not present, then the value of the "external" attribute is a URI or URI with a fragment-identifier. Note that a relative-URI value is not allowed.
「内部」属性の値は、オプションのIANA登録名です。 「内部」属性が存在しない場合は、「外部」属性の値は、フラグメント識別子とURI又はURIです。相対URI値が許可されていないことに注意してください。
The "targetHop" attribute specifies which relay(s) should process the option:
「targetHop」属性はオプションを処理すべきリレー（複数可）を指定します。
this: the option applies to this relay, and must be removed prior to transmitting the containing element.
この：オプションは、このリレーに適用され、前に含む要素を送信するために除去しなければなりません。
final: the option applies to this relay, only if the relay will transmit the containing element directly to the recipient.
最終：オプションでは、リレーが受信者に直接含む要素を伝送する場合にのみ、このリレーに適用されます。
all: the option applies to this relay and is retained for the next.
すべて：オプションは、このリレーに適用され、次のために保持されます。
Note that a final relay does not remove any options as it transmits the containing element directly to the recipient.
それが受信者に直接含む要素を送信するように、最終的なリレーは、任意のオプションを削除しないことに留意されたいです。
The "mustUnderstand" attribute specifies whether the relay may ignore the option if it is unrecognized, and is consulted only if the "targetHop" attribute indicates that the option applies to that relay. If the option applies, and if the value of the "mustUnderstand" attribute is "true", and if the relay does not "understand" the option, then an error in processing has occurred.
「のmustUnderstand」属性は、それが認識されない場合、リレーはオプションを無視するかどうかを指定し、「targetHop」属性はオプションではそのリレーに適用されることを示している場合にのみ参照されます。オプションが適用される場合、および「でmustUnderstand」属性の値が「真」であり、リレーオプションを「理解」していない場合、処理中にエラーが発生した場合。
Section 8.4 contains the APEX option registration for the "statusRequest" option.
8.4節では、「statusRequest」オプションのAPEXオプションの登録が含まれています。
If this option is present, then each applicable relay sends a "statusResponse" message to the originator. This is done by issuing a data operation whose originator is the report service associated with the issuing relay, whose recipient is the endpoint address of the "statusRequest" originator, and whose content is a "statusResponse" element.
このオプションが存在する場合、該当する各リレーは元に「statusResponse」メッセージを送信します。これは、その創始その受信者、およびコンテンツ「statusResponse」要素である「statusRequest」創始者のエンドポイントアドレスで発行リレー、関連付けられたレポートサービスでデータ操作を発行することによって行われます。
A "statusRequest" option MUST NOT be present in any data operation containing a "statusResponse" element. In general, applications should be careful to avoid potential looping behaviors if an option is received in error.
「statusRequest」オプションは、「statusResponse」要素を含む任意のデータ操作中に存在してはなりません。一般に、アプリケーションは、オプションが誤って受信された場合の潜在的なループの振る舞いを避けるために注意しなければなりません。
Consider these examples:
これらの例を考えてみます。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@example.com' /> <option internal='statusRequest' targetHop='final' mustUnderstand='true' transID='86' /> </data> S: <ok />
C：<データコンテンツ= 'CID：1@example.com'> <創始identity='fred@example.com '/> <受信者identity='barney@example.com' /> <オプション内部= 'statusRequest' targetHop =のmustUnderstand = 'true' のTRANSID = '86' /> </データ> S '最終'：<OK />
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@example.com' /> <option internal='statusRequest' targetHop='final' mustUnderstand='true' transID='86' /> </data> S: <ok />
C：<データコンテンツ= 'CID：1@example.com'> <創始identity='fred@example.com '/> <受信者identity='barney@example.com' /> <オプション内部= 'statusRequest' targetHop =のmustUnderstand = 'true' のTRANSID = '86' /> </データ> S '最終'：<OK />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
C: <data content='#Content'> <originator identity='apex=report@example.com' /> <recipient identity='fred@example.com' /> <data-content Name='Content'> <statusResponse transID='86'> <destination identity='barney@example.com'> <reply code='250' /> </destination> </statusResponse> </data-content> </data> S: <ok />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=report@example.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> < statusResponse TRANSID = '86 '> <先identity='barney@example.com'> <応答コード= '250' /> </宛先> </ statusResponse> </データコンテンツ> </データ> S：<OK />
or
または
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@example.com' /> <option internal='statusRequest' targetHop='final' mustUnderstand='true' transID='86' /> </data> S: <ok />
C：<データコンテンツ= 'CID：1@example.com'> <創始identity='fred@example.com '/> <受信者identity='barney@example.com' /> <オプション内部= 'statusRequest' targetHop =のmustUnderstand = 'true' のTRANSID = '86' /> </データ> S '最終'：<OK />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
C: <data content='#Content'> <originator identity='apex=report@example.com' /> <recipient identity='fred@example.com' /> <data-content Name='Content'> <statusResponse transID='86'> <destination identity='barney@example.com'> <reply code='550'>unknown endpoint identity</reply> </destination> </statusResponse> </data-content> </data> S: <ok />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=report@example.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> < statusResponse TRANSID = '86 '> <先identity='barney@example.com'> <応答コード= '550'>未知のエンドポイントアイデンティティ</応答> </宛先> </ statusResponse> </データコンテンツ> </データ> S：<OK />
or
または
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | #1 |
+-------+ +-------+
C: <data content='cid:1@example.com'>
<originator identity='fred@example.com' />
<recipient identity='barney@rubble.com' />
<option internal='statusRequest' targetHop='final'
mustUnderstand='true' transID='86' />
</data>
S: <ok />
+-------+ +-------+
| | -- data -------> | |
| relay | | relay |
| #1 | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@rubble.com' /> <option internal='statusRequest' targetHop='final' mustUnderstand='true' transID='86' /> </data> S: <ok />
C：<データコンテンツ= 'CID：1@example.com'> <創始identity='fred@example.com '/> <受信者identity='barney@rubble.com' /> <オプション内部= 'statusRequest' targetHop =のmustUnderstand = 'true' のTRANSID = '86' /> </データ> S '最終'：<OK />
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| #2 | <--------- ok -- | #2 |
+-------+ +-------+
C: <data content='cid:1@example.com'> <originator identity='fred@example.com' /> <recipient identity='barney@example.com' /> <option internal='statusRequest' targetHop='final' mustUnderstand='true' transID='86' /> </data> S: <ok />
C：<データコンテンツ= 'CID：1@example.com'> <創始identity='fred@example.com '/> <受信者identity='barney@example.com' /> <オプション内部= 'statusRequest' targetHop =のmustUnderstand = 'true' のTRANSID = '86' /> </データ> S '最終'：<OK />
+-------+ +-------+
| | <------- data -- | |
| relay | | relay |
| #1 | -- ok ---------> | #2 |
+-------+ +-------+
C: <data content='#Content'> <originator identity='apex=report@rubble.com' /> <recipient identity='fred@example.com' /> <data-content Name='Content'> <statusResponse transID='86'> <destination identity='barney@rubble.com'> <reply code='250' /> </destination> </statusResponse> </data-content> </data> S: <ok />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=report@rubble.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> < statusResponse TRANSID = '86 '> <先identity='barney@rubble.com'> <応答コード= '250' /> </宛先> </ statusResponse> </データコンテンツ> </データ> S：<OK />
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | #1 |
+-------+ +-------+
C: <data content='#Content'> <originator identity='apex=report@rubble.com' /> <recipient identity='fred@example.com' /> <data-content Name='Content'> <statusResponse transID='86'> <destination identity='barney@rubble.com'> <reply code='250' /> </destination> </statusResponse>
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=report@rubble.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> < statusResponse TRANSID = '86 '> <先identity='barney@rubble.com'> <応答コード= '250' /> </宛先> </ statusResponse>
</data-content> </data> S: <ok />
</データ・コンテンツ> </データ> S：<OK />
Note that a trace of a data's passage through the relaying mesh can be achieved by setting the "targetHop" attribute to "all".
中継網を介してデータの通路の痕跡を「すべて」「targetHop」属性を設定することによって達成することができることに注意してください。
APEX, at its core, provides a best-effort datagram service. Within an administrative domain, all relays must be able to handle messages for any endpoint within that administrative domain. APEX services are logically defined as endpoints but, given their ubiquitous semantics, they do not necessarily need to be associated with a single physical endpoint. As such, they may be provisioned co-resident with each relay within an administrative domain, even though they are logically provided on top of the relaying mesh, i.e.,
APEXは、その中核に、ベストエフォート型のデータグラムサービスを提供します。管理ドメイン内では、すべてのリレーは、その管理ドメイン内の任意のエンドポイント用のメッセージを処理できなければなりません。 APEXサービスは、論理的にエンドポイントとして定義されているが、彼らのユビキタスセマンティクス与えられ、彼らは必ずしも単一の物理的なエンドポイントに関連付けする必要はありません。そのようなものとして、それらは、すなわち、それらは論理的に中継するメッシュの上部に設けられていても、管理ドメイン内の各リレーとの共存をプロビジョニングすることができます
+----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
すなわち、アプリケーションは、「既知のエンドポイント」（WKE）との間でデータを交換することによってAPEXサービスと通信しています。
For example, APEX applications communicate with the report service by exchanging data with the well-known endpoint "apex=report" in the corresponding administrative domain, e.g., "apex=report@example.com" is the endpoint associated with the report service in the "example.com" administrative domain.
例えば、APEXアプリケーションは、例えば、対応する管理ドメインではよく知られているエンドポイント「頂点=レポート」とデータを交換することにより、レポートサービスと通信し、「apex=report@example.com」は、レポートサービスに関連付けられたエンドポイントであります「example.com」管理ドメイン。
The specification of an APEX service must define:
APEXサービスの仕様が定義する必要があります。
o the WKE of the service;
サービスのWAKE O;
o the syntax and sequence of messages exchanged with the service;
サービスで交換されるメッセージの構文および順序O;
o what access control tokens are consulted by the service.
Oどのようなアクセス制御トークンは、サービスによって相談されています。
A service registration template (Section 7.2) organizes this information.
サービス登録テンプレート（7.2節）は、この情報を整理します。
Finally, note that within a single administrative domain, the relaying mesh makes use of the APEX access service in order to determine if an originator is allowed to transmit data to a recipient (c.f., Step 5.3 of Section 4.4.4.1).
最後に、単一の管理ドメイン内で、中継網は発信元が受信者（C.F.、セクション4.4.4.1のステップ5.3）にデータを送信することが許可されているかどうかを判断するために、APEX・アクセス・サービスを使用することに注意してください。
The specification of an APEX service may use definitions found in the APEX core DTD (Section 9.1). For example, the reply operation (Section 6.1.2) is defined to provide a common format for responses.
APEXサービスの仕様は、APEXコアDTD（第9.1節）に見出される定義を使用することができます。例えば、応答操作（セクション6.1.2）応答のための共通フォーマットを提供するために定義されています。
In using APEX's transaction-identifiers, note the following:
APEXのトランザクション識別子を使用して、次の点に注意してください。
o In the endpoint-relay and relay-relay modes, transaction-identifiers are meaningful only during the lifetime of a BEEP channel.
O、エンドポイントリレーとリレーリレーモードでトランザクション識別子はBEEPチャネルの存続期間中にのみ有効です。
For example, when an application issues the attach operation, the associated transaction-identifier has meaning only within the context of the BEEP channel used for the attach operation. When the BEEP connection is released, the channel no longer exists and the application is no longer attached to the relaying mesh.
例えば、アプリケーションは、接続操作を発行したときに、関連するトランザクション識別子は、接続操作に使用BEEPチャネルのコンテキスト内で意味を持ちます。 BEEP接続が解放されると、チャネルはもはや存在せず、アプリケーションはもはや中継網に接続されています。
o In contrast, when an application communicates with an APEX service, transaction-identifiers are often embedded in the data that is sent. This means that transaction-identifiers are potentially long-lived.
アプリケーションはAPEXサービスと通信するとき、Oは対照的に、トランザクション識別子は、多くの場合、送信されたデータに埋め込まれています。これは、トランザクション識別子が潜在的に長寿命であることを意味します。
For example, an application may attach as an endpoint, send data (containing an embedded transaction-identifier) to a service, and, some time later, detach from the relaying mesh. Later on, a second application may attach as the same endpoint, and send data of its own (also containing embedded transaction-identifiers). Subsequently, the second application may receive data from the service responding to the first application's request and containing the transaction-identifier used by the first application.
例えば、アプリケーションは、エンドポイントとして取り付けることができるサービスに（埋め込みトランザクション識別子を含む）データを送信し、そして、いくつかの時間後、中継メッシュから切り離します。後に、第二のアプリケーションが同一のエンドポイントとして付着、及び（また埋め込みトランザクション識別子を含む）それ自身のデータを送信することができます。続いて、第2アプリケーションは、サービスが最初のアプリケーションの要求に応答し、最初のアプリケーションによって使用されるトランザクション識別子を含むからデータを受信することができます。
To minimize the likelihood of ambiguities with long-lived transaction-identifiers, the values of transaction-identifiers generated by applications should appear to be unpredictable.
長寿命トランザクション識別子を持つ曖昧さの可能性を最小限にするために、アプリケーションによって生成されたトランザクション識別子の値は予測できないように見えるはずです。
Many APEX services make use of a reply operation. Although each service defines the circumstances in which a "reply" element is sent, the syntax of the "reply" element is defined in Section 9.1.
多くのAPEXサービスが応答操作を利用します。各サービスは、「返信」要素が送信される状況を定義しているが、「返信」要素の構文はセクション9.1で定義されています。
The "reply" element has a "code" attribute, a "transID" attribute, an optional "xml:lang" attribute, and may contain arbitrary textual content:
「返信」要素は、「コード」属性、「TRANSID」属性、任意「XML：langの」持っている属性を、任意のテキストコンテンツを含んでいてもよいです。
o the "code" element specifies a three-digit reply code (c.f., Section 10);
O「コード」要素は、3桁の応答コード（C.F.、セクション10）を指定します。
o the "transID" attribute specifies the transaction-identifier corresponding to this reply;
O「TRANSID」属性は、この応答に対応するトランザクション識別子を指定します。
o the "xml:lang" attribute, if present, specifies the language that the element's content is written in; and,
「XML：LANG」O属性が存在する場合、要素の内容が書き込まれていることの言語を指定します。そして、
o the textual content is a diagnostic (possibly multiline) which is meaningful to implementers, perhaps administrators, and possibly even users.
Oテキストコンテンツは、おそらく実装者、管理者、およびおそらくはユーザにとって意味のある診断（おそらく複数行）です。
Section 8.5 contains the APEX service registration for the report service:
8.5節では、レポートサービスのAPEXのサービス登録が含まれています。
o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=report".
管理ドメイン内のO、サービスは「頂点=報告書」のよく知られたエンドポイントを使用して対処しています。
o Section 9.2 defines the syntax of the operations exchanged with the service.
Oセクション9.2動作の構文は、サービスと交換規定します。
o A consumer of the service does not initiate communications with the service.
Oサービスの消費者は、サービスとの通信を開始しません。
o The service initiates communications by sending data containing the "statusResponse" operation.
Oサービスは、「statusResponse」操作を含むデータを送信することで通信を開始します。
If a relay processes a "statusRequest" option (Section 5.1), then it sends data to the originator containing a "statusResponse" element (Section 9.2).
リレーは「statusRequest」オプション（5.1節）を処理した場合、それは「statusResponse」要素（9.2節）を含む発信元にデータを送信します。
The "statusResponse" element has a "transID" attribute and contains one or more "destination" elements: o the "transID" attribute specifies the value contained in the "statusRequest" option; and,
「statusResponse」要素は、「TRANSID」属性を持っており、1つ以上の「目的地」の要素が含まれています：「TRANSID」O属性が「statusRequest」オプションに含まれる値を指定します。そして、
o each "destination" element has an "identity" attribute and contains a "reply" element:
O各「宛先」要素は、「アイデンティティ」の属性を持っており、「返信」要素が含まれています。
* the "identity" attribute specifies the recipient endpoint that is being reported on; and,
*「アイデンティティ」属性は、上で報告されている受信者のエンドポイントを指定します。そして、
* the "reply" element (Section 6.1.2) specifies the delivery status of that recipient.
*「返信」要素（6.1.2）は、その受信者の配信状態を指定します。
When an APEX option is registered, the following information is supplied:
APEXオプションが登録されている場合は、次の情報が提供されます。
Option Identification: specify the NMTOKEN or the URI that authoritatively identifies this option.
オプションの同定：NMTOKENや権威には、このオプションを識別するURIを指定します。
Present in: specify the APEX elements in which the option may appear.
存在する：オプションが表示される可能性のあるAPEXの要素を指定します。
Contains: specify the XML content that is contained within the "option" element.
含まれています：「オプション」要素内に含まれているXMLコンテンツを指定します。
Processing Rules: specify the processing rules associated with the option.
処理ルール：オプションに関連した処理規則を指定します。
Contact Information: specify the postal and electronic contact information for the author of the profile.
お問い合わせ先：プロファイルの作成者郵便や電子連絡先情報を指定します。
When an APEX service is registered, the following information is supplied:
APEXサービスが登録されている場合は、次の情報が提供されます。
Well-Known Endpoint: specify the local-part of an endpoint identity, starting with "apex=".
エンドポイントよく知られている：「=頂点」で始まる、エンドポイントのアイデンティティのローカル部分を指定します。
Syntax of Messages Exchanged: specify the elements exchanged with the service.
交換されるメッセージの構文は：サービスと交換要素を指定します。
Sequence of Messages Exchanged: specify the order in which data is exchanged with the service.
交換されるメッセージのシーケンス：データはサービスと交換される順序を指定します。
Access Control Tokens: specify the token(s) used to control access to the service (c.f., [10]).
アクセス制御トークン：（S）トークンを指定するサービス（C.F.、[10]）へのアクセスを制御するために使用されます。
Contact Information: specify the postal and electronic contact information for the author of the profile.
お問い合わせ先：プロファイルの作成者郵便や電子連絡先情報を指定します。
Note that the endpoints "apex=all" and "apex=core" may not be assigned.
エンドポイント「頂点が=すべて」および「頂点=コア」は割り当てられなくてもよいことに留意されたいです。
When an APEX endpoint application is registered, the following information is supplied:
APEXのエンドポイント・アプリケーションが登録されている場合、次の情報が提供されます。
Endpoint Application: specify the subaddress used for an endpoint application, starting with "appl=".
エンドポイントアプリケーション：「= APPL」で始まる、エンドポイント・アプリケーションのために使用されるサブアドレスを指定します。
Application Definition: specify the syntax and semantics of the endpoint application identified by this registration.
アプリケーション定義：この登録によって識別されたエンドポイントのアプリケーションの構文とセマンティクスを指定します。
Contact Information: specify the postal and electronic contact information for the author of the profile.
お問い合わせ先：プロファイルの作成者郵便や電子連絡先情報を指定します。
Profile Identification: http://iana.org/beep/APEX
プロフィール同定：http://iana.org/beep/APEX
Messages exchanged during Channel Creation: "attach", "bind"
メッセージはチャンネルの作成中に交換：「添付」、「バインド」
Messages starting one-to-one exchanges: "attach", "bind", "terminate", or "data"
1対1の交換を開始するメッセージ：「添付」、「バインド」、「終了」、または「データ」
Messages in positive replies: "ok"
正の返信でメッセージ：「OK」
Messages in negative replies: "error"
負の返信でメッセージ：「エラー」
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message Syntax: c.f., Section 9.1
メッセージ構文：C.F.、9.1節
Message Semantics: c.f., Section 4.4
メッセージの意味：C.F.、4.4節
Contact Information: c.f., the "Authors' Addresses" section of this memo
お問い合わせ先：C.F.、「著者のアドレス」このメモのセクション
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1
メッセージフォーマット、タイプ、オペコード、およびシーケンス：C.F.、9.1節
Functions: c.f., Section 4.4
機能：C.F.、4.4節
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの利用：なし
Proposed Name: APEX relay-relay service
提案名：APEXリレーリレーサービス
Short name: apex-mesh
短い名前：頂点メッシュ
Contact Information: c.f., the "Authors' Addresses" section of this memo
お問い合わせ先：C.F.、「著者のアドレス」このメモのセクション
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1
メッセージフォーマット、タイプ、オペコード、およびシーケンス：C.F.、9.1節
Functions: c.f., Section 4.4
機能：C.F.、4.4節
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの利用：なし
Proposed Name: APEX endpoint-relay service
提案名：APEXエンドポイント・リレーサービス
Short name: apex-edge
短い名前：頂点、エッジ
Contact Information: c.f., the "Authors' Addresses" section of this memo
お問い合わせ先：C.F.、「著者のアドレス」このメモのセクション
Option Identification: statusRequest
オプション識別：statusRequest
Present in: APEX's "data" and "recipient" elements
APEXの「データ」と「受け手」の要素：に存在します
Contains: nothing
含まれていません：何も
Processing Rules: c.f., Section 5.1
処理ルール：C.F.、5.1節
Contact Information: c.f., the "Authors' Addresses" section of this memo
お問い合わせ先：C.F.、「著者のアドレス」このメモのセクション
Well-Known Endpoint: apex=report
よく知られているエンドポイント：頂点=報告書
Syntax of Messages Exchanged: c.f., Section 9.2
交換されるメッセージの構文：C.F.、9.2節
Sequence of Messages Exchanged: c.f., Section 6.2
交換されるメッセージのシーケンス：C.F.、6.2節
Access Control Tokens: none
アクセスコントロールトークン：なし
Contact Information: c.f., the "Authors' Addresses" section of this memo
お問い合わせ先：C.F.、「著者のアドレス」このメモのセクション
<!-- DTD for the APEX core, as of 2001-07-09
<！ - 2001-07-09のようAPEXコア用のDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" ""> %APEXCORE; -->
<！ENTITY％APEXCORE PUBLIC " - // IETF // DTD APEX CORE // EN" "">％APEXCORE。 - >
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" ""> %BEEP;
<！ENTITY％BEEP PUBLIC " - // IETF // DTD BEEP // EN" "">％のBEEP。
<!-- DTD data types:
<！ - DTDデータタイプ：
entity syntax/reference example
====== ================ =======
APEX endpoint
ENDPOINT entity, fred@example.com
c.f., Section 2.2
domain, either a FQDN or a literal DOMAIN c.f., [RFC-2821] example.com or [10.0.0.1]
ドメイン、いずれかのFQDNまたはリテラルDOMAINのC.F.、[RFC-2821] example.comまたは[10.0.0.1]
seconds SECONDS 0..2147483647 600
秒SECONDS 0 2147483647 600
timestamp TIMESTAMP c.f., [12] 2000-05-15T13:02:00-08:00
タイムスタンプタイムスタンプC.F.、[12] 2000-05-15T13：02：00-08：00
unique-identifier
シングル識別
UNIQID 1..2147483647 42
UNIQID 1 2147483647 42
unique-identifier OR zero UNIZID 0..2147483647 0 -->
ユニークな識別子またはゼロUNIZID 0 2147483647 0 - >
<!ENTITY % ENDPOINT "CDATA"> <!ENTITY % DOMAIN "CDATA"> <!ENTITY % SECONDS "CDATA"> <!ENTITY % TIMESTAMP "CDATA"> <!ENTITY % UNIQID "CDATA"> <!ENTITY % UNIZID "CDATA">
<！ENTITY％ENDPOINT "CDATA"> <！ENTITY％以下のDOMAIN "CDATA"> <！ENTITY％以下のSECONDS "CDATA"> <！ENTITY％以下のTIMESTAMP "CDATA"> <！ENTITY％のUNIQID "CDATAを"> <！ENTITY％でUNIZID "CDATA">
<!-- APEX messages, exchanged as application/beep+xml
<！ - APEXのメッセージは、アプリケーション/ビープ音+ XMLとして交換しました
role MSG RPY ERR
====== === === ===
I attach ok error
I or L bind ok error
IまたはLバインドOKエラー
I or L terminate ok error
IまたはL [OK]エラーを終了
I or L data ok error -->
IまたはLデータOKエラー - >
<!ELEMENT attach (option*)> <!ATTLIST attach endpoint %ENDPOINT; #REQUIRED transID %UNIQID; #REQUIRED>
<！ELEMENT（*オプション）を取り付け> <ATTLISTエンドポイント％エンドポイントを付けます！。 #REQUIRED TRANSID％UNIQID。 #REQUIRED>
<!ELEMENT bind (option*)> <!ATTLIST bind relay %DOMAIN; #REQUIRED transID %UNIQID; #REQUIRED>
<！ELEMENTバインド（オプション*）> <！ATTLISTバインドリレー％のDOMAIN。 #REQUIRED TRANSID％UNIQID。 #REQUIRED>
<!ELEMENT terminate (#PCDATA)> <!ATTLIST terminate code %XYZ; "250" xml:lang %LANG; #IMPLIED transID %UNIZID; "0">
<！ELEMENT（#PCDATA）を終了> <！ATTLISTコード％XYZを終了します。 "250" のxml：langの％LANG。 #IMPLIED TRANSID％UNIZID。 "0">
<!ELEMENT data (originator,recipient+,option*,data-content?)> <!ATTLIST data content %URI; #REQUIRED>
<！ELEMENTデータ（発信元、受信者+、オプション*、データ・コンテンツは？）> <ATTLISTデータコンテンツ％URI！。 #REQUIRED>
<!ELEMENT originator (option*)>
<！ELEMENT発信（オプション*）>
<!ATTLIST originator identity %ENDPOINT; #REQUIRED>
<！ATTLIST発信アイデンティティ％のENDPOINT。 #REQUIRED>
<!ELEMENT recipient (option*)> <!ATTLIST recipient identity %ENDPOINT; #REQUIRED>
！<！ELEMENT受信者（オプション*）> <ATTLIST受信者の身元％のENDPOINT。 #REQUIRED>
<!ELEMENT data-content ANY> <!ATTLIST Name ID #REQUIRED>
<！ELEMENTデータ・コンテンツANY> <！ATTLIST名ID #REQUIRED>
<!ELEMENT ok EMPTY>
<！ELEMENT OK EMPTY>
<!ELEMENT reply (#PCDATA)> <!ATTLIST reply code %XYZ; #REQUIRED transID %UNIQID; #REQUIRED xml:lang %LANG; #IMPLIED>
<！ELEMENT応答（#PCDATA）> <！ATTLISTの応答コード％XYZ。 #REQUIRED TRANSID％UNIQID。 #REQUIREDのxml：langの％LANG。 #IMPLIED>
<!-- either the "internal" or the "external" attribute is present in an option -->
<！ - のいずれかの「内部」または「外部」属性はオプションに存在しています - >
<!ELEMENT option ANY> <!ATTLIST option internal NMTOKEN "" external %URI; "" targetHop (this|final|all) "final" mustUnderstand (true|false) "false" transID %UNIQID; #REQUIRED localize %LOCS; "i-default">
！<！ELEMENTオプションANY> <ATTLISTオプション内部NMTOKEN "" 外部％URI; "" targetHop（この|最後の|すべての） "最終" のmustUnderstand（真|偽） "偽" TRANSID％UNIQID。 #REQUIREDローカライズ％LOCS。 「私は、デフォルトの」>
<!-- DTD for the APEX report service, as of 2000-12-12
<！ - 2000年12月12日のようAPEXレポートサービス用のDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % APEXREPORT PUBLIC "-//Blocks//DTD APEX REPORT//EN" ""> %APEXREPORT; -->
<！ENTITY％APEXREPORT PUBLIC " - //ブロック// DTD APEX REPORT // EN" "">％APEXREPORT。 - >
<!ENTITY % APEXCORE PUBLIC "-//Blocks//DTD APEX CORE//EN" ""> %APEXCORE;
<！ENTITY％APEXCORE PUBLIC " - //ブロック// DTD APEX CORE // EN" "">％APEXCORE。
<!-- Synopsis of the APEX report service
<！ - APEXレポートサービスの概要
service WKE: apex=report
besokサービス：アペックス=報告書
message exchanges:
メッセージ交換：
service initiates consumer replies
================= ================
statusResponse (nothing)
access control tokens: none -->
アクセス制御トークン：なし - >
<!ELEMENT statusResponse (destination+)> <!ATTLIST statusResponse transID %UNIQID; #REQUIRED>
<！ELEMENT statusResponse（先+）> <ATTLIST statusResponse TRANSID％UNIQID！。 #REQUIRED>
<!ELEMENT destination (reply)> <!ATTLIST destination identity %ENDPOINT; #REQUIRED>
<！ELEMENT先（返信）> <！ATTLIST先アイデンティティ％のENDPOINT。 #REQUIRED>
code meaning
==== =======
250 transaction successful
421 service not available
421サービスは利用できません
450 requested action not taken
450要求されたアクション取りません
451 requested action aborted
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
不十分534認証機構
535 authentication failure
535認証失敗
537 action not authorized for user
537アクションは、ユーザーのために許可されていません
538 authentication mechanism requires encryption
538認証機構は、暗号化が必要
550 requested action not taken
550要求されたアクション取りません
553 parameter invalid
無効なパラメータ553
554 transaction failed (e.g., policy violation)
554トランザクションが失敗した（例えば、ポリシー違反）
555 transaction already in progress
すでに進行中の555取引
Consult Section 3 and Section 4.5 for a discussion of security issues, e.g., relaying integrity.
整合性を中継する、例えば、セキュリティ問題の議論については第3節と4.5節を参照してください。
Although service provisioning is a policy matter, at a minimum, all APEX implementations must provide the following tuning profiles:
サービスプロビジョニングは、ポリシーの問題ですが、最低でも、すべてのAPEXの実装は、以下のチューニングプロファイルを提供する必要があります。
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
認証のために：http://iana.org/beep/SASL/DIGEST-MD5
for confidentiality: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
機密保持のために：http://iana.org/beep/TLS（TLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して）
for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)
（クライアント側の証明書をサポートするTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して）http://iana.org/beep/TLS：両方のために
Further, APEX endpoint implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP [13] or S/MIME [14].
さらに、APEXエンドポイント実装は、OpenPGPの[13]またはS / MIME [14]のようにメッセージの完全性と機密性を提供するMIMEベースのセキュリティサービスを提供することを選択することができます。
Regardless, since APEX is a profile of the BEEP, consult [1]'s Section 9 for a discussion of BEEP-specific security issues.
APEXは、BEEPのプロファイルであるためにかかわらず、BEEP固有のセキュリティ問題の議論のための[1]のセクション9を参照してください。
Finally, the statusRequest option (Section 5.1) may be used to expose private network topology. Accordingly, an administrator may wish to choose to disable this option except at the ingress/egress points for its administrative domain.
最後に、statusRequestオプション（5.1節）は、プライベートネットワークトポロジを公開するために使用することができます。したがって、管理者はその管理ドメインのための入口/出口ポイント以外では、このオプションを無効にするかを選択することもできます。
References
リファレンス
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[1]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[3] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[3] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[4] Yergeau、F.、 "UTF-8、UnicodeとISO 10646の変換フォーマット"、RFC 2044、1996年10月。
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Gulbrandsenの、A.、いるVixie、P.およびL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782 2000年2月。
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[6]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 2396、1998年8月。
[7] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[7]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。
[8] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[8]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[9]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[10] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Access Service", RFC 3341, July 2002.
[10]ローズ、M.、Klyne、G.、およびD.クロッカー、 "アプリケーション所（APEX）アクセスサービス"、RFC 3341、2002年7月。
[11] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Presence Service", Work in Progress.
[11]ローズ、M.、Klyne、G.、およびD.クロッカー、 "アプリケーションエクスチェンジ（APEX）プレゼンスサービス"、ProgressのWork。
[12] Newman, C. and G. Klyne, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[12]ニューマン、C.およびG. Klyne、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年7月。
[13] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[13]エルキンズ、M.、デルTorto、D.、Levien、R.及びT.レスラー、 "OpenPGPのとMIMEセキュリティ"、RFC 3156、2001年8月。
[14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[14] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
Appendix A. Acknowledgements
付録A.謝辞
The authors gratefully acknowledge the contributions of: Jeffrey Altman, Harald Alvestrand, Eric Dixon, Ronan Klyne, Darren New, Chris Newman, Scott Pead, and Bob Wyman.
ジェフリー・アルトマン、ハラルドAlvestrand、エリック・ディクソン、ローナンKlyne、ダレン新しい、クリス・ニューマン、スコットPEAD、ボブ・ワイマン：著者は感謝の貢献を認めます。
Appendix B. IANA Considerations
付録B. IANAの考慮事項
The IANA has registered "APEX" as a standards-track BEEP profile, as specified in Section 8.1.
IANAはセクション8.1で指定されているように、標準化過程のBEEPプロファイルとして「APEX」を登録しました。
The IANA has registered "apex-mesh" as a TCP port number, as specified in Section 8.2.
IANAはセクション8.2で指定されているように、TCPポート番号として「頂点メッシュ」を登録しました。
The IANA has registered "apex-edge" as a TCP port number, as specified in Section 8.3.
IANAはセクション8.3で指定されるように、TCPポート番号として「頂端」が登録されています。
The IANA maintains a list of:
IANAは、のリストを維持します。
o APEX options, c.f., Section 7.1;
APEX Oオプション、C.F.、7.1節。
o APEX services, c.f., Section 7.2; and,
O APEXサービス、C.F.、7.2節。そして、
o APEX endpoint applications, c.f., Section 7.3.
O APEXエンドポイント・アプリケーション、C.F.、7.3節。
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 APEX options and services, the mailing list apexwg@invisible.net may be used to solicit commentary.
各リストについては、IESGは、IANAが割り当てを行う前に仕様を検討するために、指定の専門家を割り当てるための責任があります。非標準規格の開発者への礼儀はAPEXオプションやサービスをトラックとして、メーリングリストapexwg@invisible.netは解説を勧誘するために使用することができます。
The IANA makes the registrations specified in Section 8.4 and Section 8.5.
IANAは、8.4節と8.5節で指定された登録を行います。
Authors' Addresses
著者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング株式会社POB 255268サクラメント、CA 95865から5268米
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
電話：+1 916 483 8878 Eメール：mrose@dbc.mtview.ca.us
Graham Klyne Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
グラハムKlyneクリアスウィフト株式会社1310水辺アーリントンビジネスパークTheale、読書RG7 4SA英国
Phone: +44 11 8903 8903 EMail: Graham.Klyne@MIMEsweeper.com
電話：+44 11 8903 8903 Eメール：Graham.Klyne@MIMEsweeper.com
David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 US
デビッドH.クロッカーブランデンブルクインターネットワーキング675スプルースドライブサニーベール、CA 94086米国
Phone: +1 408 246 8253 EMail: dcrocker@brandenburg.com URI: http://www.brandenburg.com/
電話：+1 408 246 8253 Eメール：dcrocker@brandenburg.com URI：http://www.brandenburg.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。