[要約] RFC 3340は、アプリケーションの交換コアに関する要約と目的を提供します。このRFCの目的は、アプリケーションの交換に関する基本的な要件とプロトコルを定義することです。

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.

Copyright(c)The Internet Society(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
        
1. Introduction
1. はじめに

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 世界的なWebは、プル、同期、時間感受性、信頼性、無国籍サービスです。一方

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.

このメモは、さまざまな運用特性をサポートするコアメッセージングサービスを定義します。コアサービスは、ユーザーベースとプログラマティック交換の両方に対して、さまざまなカスタマイズされたサービスをサポートしています。

1.1 Overview
1.1 概要

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は、そのコアで、最良のデータグラムサービスを提供します。単に「データ」と呼ばれる各データグラムは、頂点「エンドポイント」(頂点に動的に付着するアプリケーション」によって発信され、受信されます。

The data transmitted specifies:

送信されたデータは、次のように指定します。

o an originating endpoint;

o 発信元のエンドポイント。

o an opaque content (via a URI-reference);

o 不透明なコンテンツ(uri-referenceを介して);

o one or more recipient endpoints; and,

o 1つ以上の受信者エンドポイント。そして、

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.

オプションは、サービスのセマンティクスを変更するために使用されます。これは、レシピエントまたはDATAごとに発生する場合があり、単一または複数のリレーによって処理される場合があります。

Additional APEX services are provided on top of the relaying mesh; e.g., access control and presence information.

リレーメッシュの上に追加の頂点サービスが提供されます。たとえば、アクセス制御と存在情報。

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.

頂点は、部分的にはビープ音[1]「プロファイル」として指定されています。したがって、頂点の多くの側面(例:認証)がビープコア内で提供されます。このメモ全体で、「ピア」、「イニシエーター」、「リスナー」、「クライアント」、「サーバー」という用語は、ビープ音のコンテキストで使用されます。特に、ビープコアメモのセクション2.1では、ビープピアが実行できる役割について説明します。

When reading this memo, note that the terms "endpoint" and "relay" are specific to APEX, they do not exist in the context of BEEP.

このメモを読むとき、「エンドポイント」と「リレー」という用語は頂点に固有であることに注意してください。ビープ音のコンテキストには存在しません。

1.2 Architecture at a Glance
1.2 一目でアーキテクチャ

The APEX stack:

頂点スタック:

      +-------------+
      | 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:

頂点エンティティ:

          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 RRSを使用して構成されています。したがって、2つのエンドポイント間のリレーの実際の数は固定されていません。

2. Service Principles
2. サービス原則
2.1 Modes of Operation
2.1 動作モード

APEX is used in two modes:

頂点は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.

Endpoint-relay:エンドポイントは常にサービスのビープイニシエーターであり、リレーは常にビープリスナーです。これに関連して、アプリケーションはエンドポイントとして付着し、データの送信が発生します。

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:

エンドポイントレレイモードでは、エンドポイント(ビープイニシエーター)が可能です。

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:

リレー(ビープリスナー)は、ビープイニシエーターからのリクエストに加えて、5月:

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:

リレーリレーモードでは、リレー(ビープリスナーまたはイニシエーター)があります。

o bind as one or more administrative domains;

o 1つ以上の管理ドメインとしてバインドします。

o send data;

o データを送る;

o receive data; and,

o データを受信します。そして、

o terminate any bindings.

o バインディングを終了します。

2.2 Naming of Entities
2.2 エンティティの命名

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
        

local = address [ "/" subaddress ]

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]
        

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,

「apex =」コンベンション:「apex =」から始まるローカルパートを持つすべてのエンドポイントのアイデンティティは、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").

「サブアドレス」条約:solidus文字( "/"、10進コード47)がローカルパートで発生した場合、これはエンドポイントアイデンティティのサブアドレスを識別します( "fred/appl=wb@example.com"はapex endpoint "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またはドメインリテラルによって識別される管理ドメインに代わってサービスを提供します。

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のアクセスポリシーで定義されています(セクション4.5)。

2.2.1 Comparing Endpoints
2.2.1 エンドポイントの比較

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".

最後に、頂点エンドポイントが伝送エンコードを使用して表されている場合、比較の前に、エンコードが逆になることに注意してください。たとえば、URLエンコードを使用する場合、「apex:fred@example.com」は「apex:f%72ed@example.com」と同じです。

3. Service Provisioning
3. サービスプロビジョニング
3.1 Connection Establishment
3.1 接続確立

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);

サービス:「apex-edge」(エンドポイントレレイモードの場合)または「apex-mesh」(リレーレレイモードの場合);

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によって割り当てられます。

3.2 Authentication
3.2 認証

Authentication is a matter of provisioning for each BEEP peer (c.f., Section 4.5).

認証は、各ビープピアのプロビジョニングの問題です(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".

頂点リレーは、ビープ音のピアアイデンティティが特定のエンドポイントIDと一致するようにプロビジョニングされる場合があります。たとえば、「Example.com」管理ドメインのリレーは、「fred@example.com」として識別されたビープピアをApexエンドポイント「fred@example.com」として添付することを許可するように構成できます。

3.3 Authorization
3.3 許可

Authorization is a matter of provisioning for each BEEP peer (c.f., Section 4.5).

承認は、ビープピアごとにプロビジョニングの問題です(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.

通常、リレーでは、ビープピアが認証の前奏曲として認証される必要がありますが、通常、エンドポイントではビープピアと同じものを必要としません。

3.4 Confidentiality
3.4 機密性

Confidentiality is a matter of provisioning for each BEEP peer.

機密性は、ビープピアごとにプロビジョニングの問題です。

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.

通常、発信元のエンドポイントによって敏感であると見なされるデータは、ホップバイホップ暗号化に依存するのではなく、意図した受信者エンドポイントに対してコンテンツを暗号化します。同様に、エンドツーエンドの認証が必要な場合、発信元のエンドポイントがコンテンツに署名します。

3.5 Relaying Integrity
3.5 整合性の中継

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を使用するアプリケーションの関数です。ビープイニシエーターがビープリスナーがそれ自体を認証することを要求する場合、追加の保証が提供されます。

3.6 Traffic Analysis
3.6 トラフィック分析

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.

リレーするメッシュ(エンドポイントのアイデンティティとコンテンツ)を介して送信されるデータのホップバイホップ保護は、輸送セキュリティプロファイルを使用してビープレベルで提供されます。他のトラフィック特性、例えば送信の量とタイミングは、サードパーティの分析から保護されていません。

4. The APEX
4. 頂点

Section 8.1 contains the BEEP profile registration for APEX.

セクション8.1には、頂点のビーププロファイル登録が含まれています。

4.1 Use of XML and MIME
4.1 XMLとMIMEの使用

Each BEEP payload exchanged via APEX consists of an XML document and possibly an arbitrary MIME content.

APEXを介して交換される各ビープペイロードは、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ドキュメントのみがビープペイロードに送信されている場合、ビープペイロードへのマッピングは簡単です。

      C: MSG 1 2 . 111 39
      C: Content-Type: application/beep+xml
      C:
      C: <terminate transID='1' />
      C: END
        

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-referenceには、絶対尿(およびおそらくフラグメント識別子)が含まれている場合があります。または、フラグメント識別子のみで構成される相対尿である場合があります。任意のMIMEコンテンツは、「MultiPart/関連」[7]を使用してビープペイロードに含まれ、「CID」URL [8]を使用して識別され、XMLコントロールドキュメントは「MultiPart/関連」の開始時に発生します。、

      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
        

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.

ビープ音は8ビット幅のパスを提供するため、「変換される」コンテンツ転移エンコード(例:「base64」または「引用プリント可能」)を使用しないでください。さらに、MIME [9]では、「コンテンツ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
        
4.2 Profile Identification and Initialization
4.2 プロファイルの識別と初期化

The APEX is identified as

頂点はとして識別されます

http://iana.org/beep/APEX

http://iana.org/beep/APEX

in the BEEP "profile" element during channel creation.

チャネル作成中のビープ音の「プロファイル」要素。

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.,

チャネル作成中に交換する要素は必要ありません。ただし、エンドポイントレレイモードでは、ビープイニシエーターには通常、チャネル作成中に「アタッチ」要素が含まれます。

      <start number='1'>
          <profile uri='http://iana.org/beep/APEX'>
              <![CDATA[<attach endpoint='fred@example.com'
                               transID='1' />]]>
          </profile>
      </start>
        

Similarly, in the relay-relay mode, the BEEP initiator will typically include an "bind" element during channel creation, e.g.,

同様に、リレーレレイモードでは、ビープイニシエーターには通常、チャネル作成中に「バインド」要素が含まれます。

      <start number='1'>
          <profile uri='http://iana.org/beep/APEX'>
              <![CDATA[<bind relay='example.com'
                             transID='1' />]]>
          </profile>
      </start>
        
4.3 Message Syntax
4.3 メッセージ構文

Section 9.1 defines the BEEP payloads that are used in the APEX.

セクション9.1は、頂点で使用されるビープペイロードを定義します。

4.4 Message Semantics
4.4 メッセージセマンティクス
4.4.1 The Attach Operation
4.4.1 添付操作

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 />
        

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 />
        

or

または又はそれとも若しくは乃至或るいは

          +-------+                  +-------+
          |       | -- attach -----> |       |
          | appl. |                  | relay |
          |       | <------ error -- |       |
          +-------+                  +-------+
        
        C: <attach endpoint='fred@example.com' transID='1' />
        S: <error code='537'>access denied</error>
        

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」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。そして、

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. トランザクション-Identifierが、このビープチャネルでの以前の非終了操作を指す場合、コード555を持つ「エラー」要素が返されます。

2. If the relay is in a different administrative domain than this endpoint, an "error" element having code 553 is returned.

2. リレーがこのエンドポイントとは異なる管理ドメインにある場合、コード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.

3. アプリケーションがこのエンドポイント(C.F.、セクション4.5.1)として添付することを許可されていない場合、コード537を持つ「エラー」要素が返されます。

4. If any options are present, they are processed.

4. オプションが存在する場合、それらは処理されます。

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」要素が返されます。

4.4.2 The Bind Operation
4.4.2 バインド操作

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 />
        

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 />
        

or

または又はそれとも若しくは乃至或るいは

          +-------+                  +-------+
          |       | -- bind -------> |       |
          | relay |                  | relay |
          |   #1  | <------ error -- |   #2  |
          +-------+                  +-------+
        
        C: <bind relay='example.com' transID='1' />
        S: <error code='537'>access denied</error>
        

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」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。そして、

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. トランザクション-Identifierが、このビープチャネルでの以前の非終了操作を指す場合、コード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.

2. アプリケーションがこの管理ドメイン(C.F.、セクション4.5.2)に代わって拘束されることを許可されていない場合、コード537を持つ「エラー」要素が返されます。

3. If any options are present, they are processed.

3. オプションが存在する場合、それらは処理されます。

4. Otherwise, the application is accepted as serving this administrative domain, and an "ok" element is returned.

4. それ以外の場合、アプリケーションはこの管理ドメインを提供するものとして受け入れられ、「OK」要素が返されます。

4.4.3 The Terminate Operation
4.4.3 終了操作

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 />
        

or

または又はそれとも若しくは乃至或るいは

          +-------+                  +-------+
          |       | -- terminate --> |       |
          | appl. |                  | relay |
          |       | <------ error -- |       |
          +-------+                  +-------+
        
        C: <terminate transID='13' />
        S: <error code='550'>unknown transaction-identifier</error>
        

or

または又はそれとも若しくは乃至或るいは

          +-------+                  +-------+
          |       | <-- terminate -- |       |
          | appl. |                  | relay |
          |       | -- ok ---------> |       |
          +-------+                  +-------+
        
        C: <terminate transID='1' />
        S: <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」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。

o the "code" attribute, if present, is a three-digit reply code meaningful to programs (c.f., Section 10);

o 「コード」属性は、存在する場合、プログラムにとって意味のある3桁の返信コードです(C.F.、セクション10)。

o the "xml:lang" attribute, if present, specifies the language that the element's content is written in; and,

o 「XML:Lang」属性は、存在する場合、要素のコンテンツが書かれている言語を指定します。そして、

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. トランザクション識別子の値がゼロの場合、エンドポイントアタッチメントまたはリレー結合としてこのビープセッションでこのアプリケーションによって確立されたすべての関連付けが終了し、「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.

2. それ以外の場合、トランザクション識別子がこのビープチャネルでの以前の未終端操作を参照していない場合、コード550を持つ「エラー」要素が返されます。

3. Otherwise, the application is no longer bound as an endpoint or a relay, and an "ok" element is returned.

3. それ以外の場合、アプリケーションはエンドポイントまたはリレーとしてバインドされなくなり、「OK」要素が返されます。

4.4.4 The Data Operation
4.4.4 データ操作

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 />
        

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>
        

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 />
        

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 「コンテンツ」属性は、データの内容を指定するURI参照です(C.F.、セクション4.1)。

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 「オプション」要素は、もしあれば、DATAごとのオプションと呼ばれる追加の処理オプション(セクション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:

「Originator」要素には「ID」属性があり、ゼロ以上のオプション要素が含まれています。

o the "identity" attribute specifies the sending endpoint; and

o 「ID」属性は、送信エンドポイントを指定します。そして

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:

各「受信者」要素には「ID」属性があり、ゼロ以上のオプション要素が含まれています。

o the "identity" attribute specifies the destination endpoint; and

o 「ID」属性は、宛先エンドポイントを指定します。そして

o the "option" elements, if any, specify additional processing options for this recipient, termed per-recipient options.

o 「オプション」要素は、もしあれば、この受信者の追加の処理オプションを指定し、レシピエントごとのオプションと呼ばれます。

4.4.4.1 Relay Processing of Data
4.4.4.1 データのリレー処理

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クライアントが「オリジネーター」エンドポイント(C.F.、セクション4.5)に代わってデータを発信またはリレーすることを許可されていない場合、コード537を持つ「エラー」要素が返されます。

2. If any per-data options are present, they are processed.

2. DATAごとのオプションが存在する場合、それらは処理されます。

3. An "ok" element is returned.

3. 「OK」要素が返されます。

4. If any per-originator options are present, they are processed.

4. オリジナーターごとのオプションが存在する場合、それらは処理されます。

5. For each recipient:

5. 各受信者に対して:

1. If any per-recipient options are present, they are processed.

1. レシピエントごとのオプションが存在する場合、それらは処理されます。

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アクセスサービスは、Originatorのエンドポイントが受信者のエンドポイントと通信できることを確認する必要があります(「所有者」が「所有者」が含める必要があるアクセスエントリ[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.

とにかく、すべてのリレーは、いつでも「データ」要素のコンテンツを変更することを明示的に禁じられています。

4.4.4.2 Application Processing of Data
4.4.4.2 データのアプリケーション処理

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. DATAごとまたは単位ごとのオプションが存在する場合、それらは処理されません(ただし、注意することができます)。

2. For each recipient:

2. 各受信者に対して:

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」要素が返されます。

4.5 APEX Access Policies
4.5 頂点アクセスポリシー

Access to APEX is provided by the juxtaposition of:

頂点へのアクセスは、次の並置によって提供されます。

o authenticating as a BEEP peer;

o ビープピアとして認証。

o attaching as an APEX endpoint or binding as an APEX relay; and,

o 頂点のエンドポイントとして取り付けたり、頂点リレーとしてバインディングしたりします。そして、

o being listed as an actor by the APEX access service (c.f., [10]).

o Apex Access Service(C.F.、[10])によって俳優としてリストされています。

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 各管理ドメインは、他の管理ドメインと関連付けるための信頼のレベルを決定します。

4.5.1 Access Policies in the Endpoint-Relay Mode
4.5.1 エンドポイントリレーモードのアクセスポリシー

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 アプリケーションが中継メッシュに接続したい場合、ローカルプロビジョニングマップビープピアアイデンティティをマップして、頂点エンドポイントを許可します(C.F.、ステップ3のセクション4.4.1)。

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」と名付けられたビープピアとして認証されている場合、「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の「サブアドレス」条約を使用して、特定の頂点エンドポイントとして添付することを許可されたアプリケーションは、その頂点エンドポイントのサブアドレスとして添付することも許可されています。.com "は、apexエンドポイント「fred/appl=wb@example.com」として添付することも許可されています。

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エンドポイントとして添付されたアプリケーションを許可する場合があります。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)。

4.5.2 Access Policies in the Relay-Relay Mode
4.5.2 リレーリレーモードのアクセスポリシー

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 アプリケーションが管理ドメインに代わってリレーとしてバインドしたい場合、ローカルプロビジョニングは、アペックスリレーを許可するためにピアアイデンティティをマップすることができます(C.F.、ステップ3)。

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".

もしそうなら、通常、ID関数が使用されます。たとえば、アプリケーションが「Example.com」と名付けられたビープピアとして認証されている場合、管理ドメイン「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)。

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.

さらに、一部のリレーは「信頼できる」仲介者として設定される可能性があるため、ビープ音がそのようなリレーからのものとして認証された場合、データは受け入れられます。

5. APEX Options
5. 頂点オプション

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:

頂点「オプション」要素のセマンティクスはコンテキスト固有です。したがって、頂点オプションの仕様は次のことを定義する必要があります。

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 「内部」と「外部」属性は、そのうちの1つが存在すると、オプションを一意に識別します。

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 「必須」属性は、オプションが認識されていない場合、処理のエラーを発生させる必要があるかどうかを指定します。

o the "transID" attribute specifies a transaction-identifier for the option; and,

o 「TransID」属性は、オプションのトランザクションIDENTIFIERを指定します。そして、

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 「ローカライズ」属性は、存在する場合、1つ以上の言語トークンを指定し、それぞれがテキスト診断がオリジネーターに返される場合に使用される望ましい言語タグを識別します。

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.

「必須」属性は、リレーが認識されていない場合にオプションを無視する可能性があるかどうかを指定し、「Targethop」属性がオプションがそのリレーに適用されることを示した場合にのみ相談されます。オプションが適用され、「必須」属性の値が「真」である場合、リレーがオプションを「理解」しない場合、処理のエラーが発生しました。

5.1 The statusRequest Option
5.1 StatusRequestオプション

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」メッセージを送信します。これは、発行リレーに関連するレポートサービスであり、受信者が「StatusRequest」オリジネーターのエンドポイントアドレスであり、コンテンツが「StatusResponse」要素であるデータ操作を発行することによって行われます。

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」オプションは、「Status Response」要素を含むデータ操作に存在しないでください。一般に、アプリケーションは、オプションが誤って受信された場合、潜在的なループ動作を避けるように注意する必要があります。

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 />
        
                                  +-------+                  +-------+
                                  |       | -- 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 />
        
       +-------+                  +-------+
       |       | <------- 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 />
        

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 />
        
       +-------+                  +-------+
       |       | <------- 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 />
        

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 />
        
                                  +-------+                  +-------+
                                  |       | -- 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 />
        
                                  +-------+                  +-------+
                                  |       | <------- 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 />
        
       +-------+                  +-------+
       |       | <------- 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>
        
            </data-content>
        </data>
     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」属性を「すべて」に設定することにより、データの通過メッシュを通るデータの通過のトレースを実現できることに注意してください。

6. APEX Services
6. 頂点サービス

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   |    |         |
      |  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 =レポート」とデータを交換することにより、レポートサービスと通信します。「Example.com」管理ドメイン。

The specification of an APEX service must define:

頂点サービスの仕様は次のように定義する必要があります。

o the WKE of the service;

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).

最後に、単一の管理ドメイン内で、リレーするメッシュがAPEXアクセスサービスを利用して、オリジネーターが受信者にデータを送信できるかどうかを判断することに注意してください(C.F.、セクション4.4.4.1のステップ5.3)。

6.1 Use of the APEX Core DTD
6.1 Apex Core DTDの使用

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 Core DTD(セクション9.1)にある定義を使用する場合があります。たとえば、返信操作(セクション6.1.2)は、応答の共通形式を提供するために定義されています。

6.1.1 Transaction-Identifiers
6.1.1 トランザクション識別子

In using APEX's transaction-identifiers, note the following:

ApexのトランザクションIDENTIFIERSを使用する際に、次のことに注意してください。

o In the endpoint-relay and relay-relay modes, transaction-identifiers are meaningful only during the lifetime of a BEEP channel.

o Endpoint-relayおよびRelay-lelayモードでは、トランザクション識別子は、ビープ音チャネルの寿命の間にのみ意味があります。

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.

たとえば、アプリケーションがアタッチ操作を発行する場合、関連するトランザクション識別子は、アタッチ操作に使用されるビープチャネルのコンテキスト内でのみ意味があります。ビープ接続がリリースされると、チャネルが存在しなくなり、アプリケーションが中継メッシュに接続されなくなります。

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.

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番目のアプリケーションが同じエンドポイントとして添付され、独自のデータを送信する場合があります(埋め込まれたトランザクション識別子も含まれています)。その後、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.

長寿命のトランザクション識別子によるあいまいさの可能性を最小限に抑えるために、アプリケーションによって生成されるトランザクション識別子の値は予測不可能であると思われるはずです。

6.1.2 The Reply Element
6.1.2 返信要素

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:

「Reply」要素には、「コード」属性、「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」属性は、この返信に対応するトランザクションIDENTIFIERを指定します。

o the "xml:lang" attribute, if present, specifies the language that the element's content is written in; and,

o 「XML:Lang」属性は、存在する場合、要素のコンテンツが書かれている言語を指定します。そして、

o the textual content is a diagnostic (possibly multiline) which is meaningful to implementers, perhaps administrators, and possibly even users.

o テキストコンテンツは、実装者、おそらく管理者、さらにはユーザーにとっても意味のある診断(おそらくマルチライン)です。

6.2 The Report Service
6.2 レポートサービス

Section 8.5 contains the APEX service registration for the report service:

セクション8.5には、レポートサービスの頂点サービス登録が含まれています。

o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=report".

o 管理ドメイン内では、「APEX = Report」のよく知られているエンドポイントを使用して、サービスは対処されます。

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 このサービスは、「status Response」操作を含むデータを送信することにより、通信を開始します。

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)を処理する場合、「Status Response」要素(セクション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,

「status Response」要素には「transID」属性があり、1つ以上の「宛先」要素が含まれています。o「transID」属性は、「statusrequest」オプションに含まれる値を指定します。そして、

o each "destination" element has an "identity" attribute and contains a "reply" element:

o 各「宛先」要素には「ID」属性があり、「返信」要素が含まれています。

* the "identity" attribute specifies the recipient endpoint that is being reported on; and,

* 「ID」属性は、報告されている受信者のエンドポイントを指定します。そして、

* the "reply" element (Section 6.1.2) specifies the delivery status of that recipient.

* 「返信」要素(セクション6.1.2)は、その受信者の配信ステータスを指定します。

7. Registration Templates
7. 登録テンプレート
7.1 APEX Option Registration Template
7.1 頂点オプション登録テンプレート

When an APEX option is registered, the following information is supplied:

頂点オプションが登録されると、次の情報が提供されます。

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.

存在:オプションが表示される可能性のある頂点要素を指定します。

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.

連絡先情報:プロファイルの著者に郵便および電子連絡先情報を指定します。

7.2 APEX Service Registration Template
7.2 頂点サービス登録テンプレート

When an APEX service is registered, the following information is supplied:

頂点サービスが登録されると、次の情報が提供されます。

Well-Known Endpoint: specify the local-part of an endpoint identity, starting with "apex=".

よく知られているエンドポイント:「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]).

アクセスコントロールトークン:サービスへのアクセスを制御するために使用されるトークンを指定します(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.

エンドポイント「apex = all」および「apex = core」には割り当てられない場合があることに注意してください。

7.3 APEX Endpoint Application Registration Template
7.3 APEXエンドポイントアプリケーション登録テンプレート

When an APEX endpoint application is registered, the following information is supplied:

Apex Endpointアプリケーションが登録されると、次の情報が提供されます。

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.

連絡先情報:プロファイルの著者に郵便および電子連絡先情報を指定します。

8. Initial Registrations
8. 初期登録
8.1 Registration: The APEX Profile
8.1 登録:頂点プロファイル

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対Many交換のメッセージ:なし

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。、このメモの「著者のアドレス」セクション

8.2 Registration: The System (Well-Known) TCP port number for apex-mesh
8.2 登録:Apex-Meshのシステム(よく知られている)TCPポート番号

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 Relay-lelayサービス

Short name: apex-mesh

短い名前:apex-mesh

Contact Information: c.f., the "Authors' Addresses" section of this memo

連絡先情報:C.F。、このメモの「著者のアドレス」セクション

8.3 Registration: The System (Well-Known) TCP port number for apex-edge
8.3 登録:Apex-Edgeのシステム(よく知られている)TCPポート番号

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 Endpoint-Relayサービス

Short name: apex-edge

短い名前:Apex-Edge

Contact Information: c.f., the "Authors' Addresses" section of this memo

連絡先情報:C.F。、このメモの「著者のアドレス」セクション

8.4 Registration: The statusRequest Option
8.4 登録:StatusRequestオプション

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。、このメモの「著者のアドレス」セクション

8.5 Registration: The Report Service
8.5 登録:レポートサービス

Well-Known Endpoint: apex=report

よく知られているエンドポイント:APEX =レポート

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。、このメモの「著者のアドレス」セクション

9. DTDs
9. DTDS
9.1 The APEX Core DTD
9.1 頂点コアDTD

<!-- 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 % 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またはリテラルドメインC.F.、[RFC-2821] Example.comまたは[10.0.0.1]のいずれか

seconds SECONDS 0..2147483647 600

秒秒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">
        
   <!--
     APEX messages, exchanged as application/beep+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 bind        (option*)>
   <!ATTLIST bind
             relay       %DOMAIN;          #REQUIRED
             transID     %UNIQID;          #REQUIRED>
        
   <!ELEMENT terminate   (#PCDATA)>
   <!ATTLIST terminate
             code        %XYZ;             "250"
             xml:lang    %LANG;            #IMPLIED
             transID     %UNIZID;          "0">
        
   <!ELEMENT data        (originator,recipient+,option*,data-content?)>
   <!ATTLIST data
             content     %URI;             #REQUIRED>
        
   <!ELEMENT originator  (option*)>
        
   <!ATTLIST originator
             identity    %ENDPOINT;        #REQUIRED>
        
   <!ELEMENT recipient   (option*)>
   <!ATTLIST recipient
             identity    %ENDPOINT;        #REQUIRED>
        
   <!ELEMENT data-content
                         ANY>
   <!ATTLIST Name        ID                #REQUIRED>
        
   <!ELEMENT ok          EMPTY>
        
   <!ELEMENT reply       (#PCDATA)>
   <!ATTLIST reply
             code        %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">

<!要素オプションany> <!attlistオプション内部nmtoken ""外部%uri;"" Targethop(this | final | all) "final"必須 "(true | false)" false "transid%uniqid;#required locized%locs;「i-default」>

9.2 The Report Service DTD
9.2 レポートサービスDTD

<!-- 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 % APEXCORE PUBLIC "-//Blocks//DTD APEX CORE//EN" "">
   %APEXCORE;
        

<!-- Synopsis of the APEX report service

<! - 頂点レポートサービスの概要

service WKE: apex=report

サービスWKE:apex =レポート

message exchanges:

メッセージ交換:

           service initiates    consumer replies
           =================    ================
           statusResponse       (nothing)
        

access control tokens: none -->

アクセスコントロールトークン:なし - >

   <!ELEMENT statusResponse
                         (destination+)>
   <!ATTLIST statusResponse
             transID     %UNIQID;          #REQUIRED>
        
   <!ELEMENT destination (reply)>
   <!ATTLIST destination
             identity    %ENDPOINT;        #REQUIRED>
        
10. Reply Codes
10. 返信コード
      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 538 authentication mechanism requires encryption

537ユーザーに対して許可されていないアクション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トランザクションはすでに進行中です

11. Security Considerations
11. セキュリティに関する考慮事項

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 cipherを使用)

for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)

両方の場合:http://iana.org/beep/tls(tls_rsa_with_3des_ede_cbc_sha ciphaを使用するクライアント側の証明書をサポートする)

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 Endpointの実装は、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はビープ音のプロファイルであるため、ビープ特有のセキュリティの問題についての議論については、[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] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。

[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[2] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強:ABNF」、RFC 2234、1997年11月。

[3] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[3] Klensin、J。、「Simple Mail Transfer Protocol」、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。and 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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子(URI):Generic Syntax」、RFC 2396、1998年8月。

[7] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.

[7] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。

[8] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.

[8] Levinson、E。、「コンテンツIDおよびメッセージ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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション(MIME)パート1:インターネットメッセージボディの形式」、RFC 2045、1996年11月。

[10] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Access Service", RFC 3341, July 2002.

[10] Rose、M.、Klyne、G。およびD. Crocker、「The Application Exchange(Apex)Access Service」、RFC 3341、2002年7月。

[11] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Presence Service", Work in Progress.

[11] Rose、M.、Klyne、G。およびD. Crocker、「The Application Exchange(Apex)Presence Service」、Work in Progress。

[12] Newman, C. and G. Klyne, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.

[12] Newman、C。and 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] Elkins、M.、Del Torto、D.、Levien、R。and T. Roessler、「Mime Security with OpenPGP」、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.

著者は、ジェフリー・アルトマン、ハラルド・アルベスランド、エリック・ディクソン、ロナン・クリン、ダレン・ニュー、クリス・ニューマン、スコット・ピード、ボブ・ワイマンの貢献に感謝します。

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で指定されているように、「Apex」を標準トラックビーププロファイルとして登録しています。

The IANA has registered "apex-mesh" as a TCP port number, as specified in Section 8.2.

IANAは、セクション8.2で指定されているように、「Apex-Mesh」をTCPポート番号として登録しています。

The IANA has registered "apex-edge" as a TCP port number, as specified in Section 8.3.

IANAは、セクション8.3で指定されているように、「Apex-Edge」をTCPポート番号として登録しています。

The IANA maintains a list of:

IANAは次のリストを維持しています:

o APEX options, c.f., Section 7.1;

o 頂点オプション、C.F。、セクション7.1;

o APEX services, c.f., Section 7.2; and,

o Apex Services、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.ローズドーバービーチコンサルティング、Inc。POB 255268サクラメント、CA 95865-5268 US

   Phone: +1 916 483 8878
   EMail: mrose@dbc.mtview.ca.us
        

Graham Klyne Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK

Graham Klyne Clearswift Corporation 1310ウォーターサイドアーリントンビジネスパークシール、RG7 4SA UKを読む

   Phone: +44 11 8903 8903
   EMail: Graham.Klyne@MIMEsweeper.com
        

David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 US

David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale、CA 94086 US

   Phone: +1 408 246 8253
   EMail: dcrocker@brandenburg.com
   URI:   http://www.brandenburg.com/
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。