RFC3340 日本語訳
3340 The Application Exchange Core. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT=74266 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 3340年のドーヴァービーチコンサルティングInc.カテゴリ: 標準化過程G.Klyne Clearswift社のD.医者ブランデンブルクインターネットワーキング2002年7月
The Application Exchange Core
アプリケーション交換コア
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This memo describes Application Exchange (APEX) Core, an extensible, asynchronous message relaying service for application layer programs.
このメモはApplication Exchange(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
1. 一目. . . . . . . . . . . . . . . . . 4 2における序論. . . . . . . . . . . . . . . . . . . . . . . 2 1.1概観. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2構造。 終点. . . . . . . . . . . . . . . . . . . 7 3を比較する実体. . . . . . . . . . . . . . . . . . . . 6 2.2.1のプリンシプルズ. . . . . . . . . . . . . . . . . . . . 5 2.1の運転モード. . . . . . . . . . . . . . . . . . . . 5 2.2命名を修理してください。 保全. . . . . . . . . . . . . . . . . . . . 8 3.6トラヒック分析. . . . . . . . . . . . . . . . . . . . . 9 4をリレーする食糧を供給. . . . . . . . . . . . . . . . . . . 7 3.1するコネクション確立. . . . . . . . . . . . . . . . . 7 3.2認証. . . . . . . . . . . . . . . . . . . . . . 8 3.3認可. . . . . . . . . . . . . . . . . . . . . . 8 3.4秘密性. . . . . . . . . . . . . . . . . . . . . 8 3.5を修理してください。 XMLとMIME. . . . . . . . . . . . . . . . . . . 9 4.2プロフィール識別と初期設定. . . . . . . . 10 4.3メッセージ構文. . . . . . . . . . . . . . . . . . . . . . 11の頂点. . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1使用
Rose, et. al. Standards Track [Page 1] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[1ページ]。
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
4.4が意味論を通信させる、.114.4、.1、操作を付けてください、.114.4、.2、ひもの操作、.134.4、.3、操作を終えてください、.144.4、.4、データ操作. . . . . . . . . . . . . . . . . . . . 15 4.4; 4.1はリレーリレーモード. . . . . . . . . 20 5による終点リレーモード. . . . . . . . 19 4.5.2のアクセス方針でデータ処理. . . . . . . . . . . . . . . . . 17 4.4.4.2アプリケーションデータ処理. . . . . . . . . . . . . . 18 4.5頂点アクセス方針. . . . . . . . . . . . . . . . . . . 19 4.5.1のアクセス方針をリレーします。 頂点オプション. . . . . . . . . . . . . . . . . . . . . . . 20 5.1はstatusRequestオプション. . . . . . . . . . . . . . . . . 22 6です。 頂点は頂点コアDTD. . . . . . . . . . . . . . . . . 27 6.1.1の取引識別子の.266.1使用を修理します。.276.1 .2 レポートが.287に調整する回答要素. . . . . . . . . . . . . . . . . . . . 28 6.2。 登録テンプレート. . . . . . . . . . . . . . . . . . 29 7.1頂点オプション登録テンプレート. . . . . . . . . . . . 29 7.2頂点サービス登録テンプレート. . . . . . . . . . . . 29 7.3頂点終点アプリケーション登録テンプレート. . . . . 30 8。 登録証明書. . . . . . . . . . . . . . . . . . 30 8.1登録に頭文字をつけてください: 頂点プロフィール. . . . . . . . . . . . . . 30 8.2登録: System(よく知っている)TCPは頂点メッシュ.318.3Registrationの数を移植します: System(よく知っている)TCPは頂点縁の.318.4Registrationの数を移植します: statusRequestオプション. . . . . . . . . . 31 8.5登録: レポートサービス. . . . . . . . . . . . . 32 9。 頂点はDTD. . . . . . . . . . . . . . . . . . . . 32 9.2の芯を取ります。DTD、.329.1 レポートサービスDTD. . . . . . . . . . . . . . . . . . 34 10。 回答コード. . . . . . . . . . . . . . . . . . . . . . . 35 11。 セキュリティ問題. . . . . . . . . . . . . . . . . 36参照. . . . . . . . . . . . . . . . . . . . . . . . 36作者のアドレス. . . . . . . . . . . . . . . . . . . . 38A.承認. . . . . . . . . . . . . . . . . . . . . 39B.IANA問題. . . . . . . . . . . . . . . . . . . 39の完全な著作権宣言文. . . . . . . . . . . . . . . . . 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 同期(インタラクティブ)か非同期な(バッチ)。
Rose, et. al. Standards Track [Page 2] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[2ページ]。
o time-assured or time-insensitive;
o 時間で確実であるか時間神経の鈍い。
o best-effort or reliable; and,
o ベストエフォート型か信頼できる。 そして
o stateful or stateless.
o statefulであるか、または国がないです。
For example:
例えば:
o the world-wide web is a pull, synchronous, time-insensitive,
reliable, stateless service; whilst
o 世界的なウェブは牽引力、同時の、そして、時間神経の鈍くて、信頼できて、国がないサービスです。 whilst
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はベストエフォート型データグラムサービスを提供します。 APEX「終点」はそれぞれの単に「データ」と呼ばれたデータグラムを、溯源して、受け取ります--ダイナミックにAPEX「リレーメッシュ」に付くアプリケーション。
The data transmitted specifies:
送られたデータは指定します:
o an originating endpoint;
o 由来している終点。
o an opaque content (via a URI-reference);
o 不明瞭な内容(URI参照を通した)。
o one or more recipient endpoints; and,
o 1つ以上の受取人終点。 そして
o zero or more options.
o ゼロか、より多くのオプション。
Rose, et. al. Standards Track [Page 3] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[3ページ]。
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.
オプションは、受取人かデータあたり1個のベースに起こるかもしれないサービスの意味論を変更するのに使用されて、シングルか複数のリレーのどちらかで処理されるかもしれません。
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]「プロフィール」として一部指定されます。 それに従って、BEEPコアの中でAPEX(例えば、認証)の多くの局面を提供します。 このメモ中では、「同輩」という用語、「創始者」、「リスナー」、「クライアント」、および「サーバ」は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の文脈に存在していません。
1.2 Architecture at a Glance
1.2 一目における構造
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 |
+-------------+
| ... |
+-------------+
+-------------+ | 頂点| APEXの過程はどちらかです: | 過程| +-------------+--APEXとして取り付けられたアプリケーション| | 終点。 または| 頂点| | | - APEXリレー+-------------+ | | APEXサービスはアプリケーションとして実現されます。| ビープ音| APEXとの特別な関係を持っています。| | それらの管理ドメイン+のリレー-------------+ | TCP| +-------------+ | ... | +-------------+
Rose, et. al. Standards Track [Page 4] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[4ページ]。
The APEX entities:
APEX実体:
administrative domain #1 administrative domain #2
+----------------------------+ +----------------------------+
| +------+ | | +------+ |
| | | | | | | |
| | appl | | | | appl | |
| | | | | | | |
| +......+ +------+ | | +------+ +......+ |
| | | | | | | | | | | |
| |end- | |relay | | | |relay | |end- | |
| | point| | | | | | | | point| |
| +------+ +------+ | | +------+ +------+ |
| | | | | | | | | | | |
| | APEX | | APEX | | | | APEX | | APEX | |
| | | | | | | | | | | |
| +------+ +------+ | | +------+ +------+ |
| || || || | | || || || |
| ============= ================ ============= |
+----------------------------+ +----------------------------+
管理ドメイン#1管理ドメイン#2+----------------------------+ +----------------------------+ | +------+ | | +------+ | | | | | | | | | | | appl| | | | appl| | | | | | | | | | | +......+ +------+ | | +------+ +......+ | | | | | | | | | | | | | | |終わり| |リレー| | | |リレー| |終わり| | | | ポイント| | | | | | | | ポイント| | | +------+ +------+ | | +------+ +------+ | | | | | | | | | | | | | | | 頂点| | 頂点| | | | 頂点| | 頂点| | | | | | | | | | | | | | | +------+ +------+ | | +------+ +------+ | | || || || | | || || || | | ============= ================ ============= | +----------------------------+ +----------------------------+
| <---- APEX relaying mesh ----> |
| <。---- メッシュをリレーするAPEX---->|
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:
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 他の終点にデータを送ってください。
Rose, et. al. Standards Track [Page 5] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[5ページ]。
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 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
;; ドメインは地方の"@"[3](FQDNか文字通りの実体のどちらか)=ドメインで定義されます。
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サービスで予約されます。 そして
Rose, et. al. Standards Track [Page 6] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[6ページ]。
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)が地方の部分に起こるなら、これは終点のアイデンティティの「副-アドレス」を特定します(例えば、「フレッド/applは wb@example.com と等しいこと」は、頂点終点" 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かaによってドメイン文字通りで特定されるように命名されませんが、管理ドメインの利益のサーブをリレーする、"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は基本的な実体として「同輩」を持っています。 BEEP同輩実体と、APEX終点とリレー実体との関係はAPEXのAccess Policies(セクション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".
最終的に、APEX終点が次に比較の前にコード化されるトランスミッションを使用することで表されるなら、コード化が逆にされることに注意してください。 例えば、URLコード化が使用されているなら、「頂点: fred@example.com 」は「頂点: 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);
サービス: 「頂点縁」(終点リレーモードのための)、または「頂点メッシュ」(リレーリレーモードのための)。
protocol: "tcp"; and,
以下について議定書の中で述べてください。 "tcp"。 そして
domain: the administrative domain.
ドメイン: 管理ドメイン。
Rose, et. al. Standards Track [Page 7] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[7ページ]。
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.
aでドメイン文字通りで管理ドメインを特定するなら、直接文字通りからIPアドレス情報を取ります、そして、IANAはセクション8.2における登録のためにポートナンバーが使用したTCPを割り当てます。
3.2 Authentication
3.2 認証
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リレーは、BEEP同輩のアイデンティティが与えられた終点のアイデンティティと同時に起こるのを許容するために食糧を供給されるかもしれません。 例えば、"example.com"管理ドメインのリレーは、" fred@example.com "として特定されたBEEP同輩が頂点終点" fred@example.com "として付くのに権限を与えられるのを許容するために構成されるかもしれません。
3.3 Authorization
3.3 認可
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同輩の同じくらいを必要としないのを必要とします。
3.4 Confidentiality
3.4 秘密性
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.
通常、由来している終点によって敏感であると考えられたどんなデータもホップごとの暗号化に依存するよりむしろ意図している受取人終点に内容をコード化するでしょう。 同様に、終わりから終わりへの認証が望まれていると、由来している終点は内容にサインするでしょう。
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を利用する機能です。 BEEP創始者が、BEEPリスナーがそれ自体を認証するのを必要とするなら、追加保証を提供します。
Rose, et. al. Standards Track [Page 8] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[8ページ]。
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.
BEEPレベルで輸送セキュリティプロフィールの使用でホップごとのリレーメッシュ(終点のアイデンティティと内容)を通して送られたデータの保護を提供します。 他の交通の特性(トランスミッションの例えば、ボリュームとタイミング)は、第三者分析から保護されません。
4. The APEX
4. 頂点
Section 8.1 contains the BEEP profile registration for APEX.
セクション8.1はAPEXのためのBEEPプロフィール登録を含みます。
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を通して交換されたそれぞれの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.,
BEEPペイロードでXMLドキュメントだけを送るなら、BEEPペイロードへのマッピングは例えば簡単です。
C: MSG 1 2 . 111 39
C: Content-Type: application/beep+xml
C:
C: <terminate transID='1' />
C: END
C: エムエスジー1 2.11139C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: <は'1'/>transID=C終わります: 終わり
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内容はBEEPペイロードに「Cid」URL[8]を使用することで特定された「複合か関連する」[7]を使用することによって、含まれています、そして、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: エムエスジー1 1.42 1234C: コンテントタイプ: 複合か関連する。 境界は「境界」と等しいです。 C: 「= "<1@example.com を始動してください、gt;、」、。 C: =「+ アプリケーション/ビープ音xml」Cをタイプしてください: C: --境界C: コンテントタイプ: アプリケーション/ビープ音+xml C: コンテントID: <1@example.com>C: C: <データ内容は'Cid: 2@example.com '>Cと等しいです:、' <創始者のアイデンティティが' fred@example.com '/と等しい、gt;、C: <受取人のアイデンティティが' barney@example.com '/と等しい、gt;、C: </データ>。
Rose, et. al. Standards Track [Page 9] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[9ページ]。
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: --境界C: コンテントタイプ: イメージ/gif C: 満足している転送コード化: バイナリーC: コンテントID: <2@example.com>C: C: ... C: --境界--、C: 終わり
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ビットの経路、「変形させる」Content転送コード化を提供します。(例えば、「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
C: エムエスジー1 1.42295C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: '<データ内容は'#内容'>Cと等しいです' <創始者のアイデンティティが' fred@example.com '/と等しい、gt;、C: <受取人のアイデンティティが' barney@example.com '/と等しい、gt;、C: <データ内容名前='内容'>C:、' <statusResponse transIDは86年の'>Cと等しいです:、' <目的地のアイデンティティが' barney@example.com 'と等しい、gt;、C: <回答コードは'250'/>Cと等しいです: </目的地>C: </statusResponse>C: </データ-内容>C: </データ>C: 終わり
4.2 Profile Identification and Initialization
4.2 プロフィール識別と初期設定
The APEX is identified as
APEXは特定されます。
http://iana.org/beep/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創始者は例えばチャンネル創造の間、「付いてください」という要素を通常入れるでしょう。
Rose, et. al. Standards Track [Page 10] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[10ページ]。
<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[<は終点=' 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'/>と等しい]]!></プロフィール></スタート>と等しいこと'と等しいです。
4.3 Message Syntax
4.3メッセージ構文
Section 9.1 defines the BEEP payloads that are used in the APEX.
セクション9.1はAPEXで使用されるBEEPペイロードを定義します。
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 -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 付いてください。----->|、|、| appl。 | | リレー| | | <、-、-、-、-、-、-、-、-- OK--| | +-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />
C: <は'1'/>終点=' fred@example.com 'transID=Sを付けます: <OK/>。
or
または
+-------+ +-------+
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
| appl. | | relay |
| | -- attach -----> | |
| | | |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 付いてください。----->|、|、|、|、|、|、|、| <、-、-、-、-、-、-、-、-- OK--| | | appl。 | | リレー| | | -- 付いてください。----->|、|、|、|、|、|、|、| <、-、-、-、-、-、-、-、-- OK--| | +-------+ +-------+
Rose, et. al. Standards Track [Page 11] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[11ページ]。
C: <attach endpoint='fred@example.com' transID='1' />
S: <ok />
C: <attach endpoint='wilma@example.com' transID='2' />
S: <ok />
C: <は'1'/>終点=' fred@example.com 'transID=Sを付けます: <OK/>C: <は'2'/>終点=' wilma@example.com 'transID=Sを付けます: <OK/>。
or
または
+-------+ +-------+
| | -- attach -----> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 付いてください。----->|、|、| appl。 | | リレー| | | <、-、-、-、-、-- 誤り--| | +-------+ +-------+
C: <attach endpoint='fred@example.com' transID='1' />
S: <error code='537'>access denied</error>
C: <は'1'/>終点=' fred@example.com 'transID=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.
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. さもなければ、アプリケーションはこの終点として制限されています、そして、「間違いありません、な」要素を返します。
Rose, et. al. Standards Track [Page 12] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[12ページ]。
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 |
+-------+ +-------+
+-------+ +-------+ | | -- ひも------->|、|、| リレー| | リレー| | #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 -- | |
+-------+ +-------+
+-------+ +-------+ | | -- ひも------->|、|、|、|、|、|、|、| <、-、-、-、-、-、-、-、-- OK--| | | リレー| | リレー| | #1 | -- ひも------->| #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 |
+-------+ +-------+
+-------+ +-------+ | | -- ひも------->|、|、| リレー| | リレー| | #1 | <、-、-、-、-、-- 誤り--| #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 「リレー」属性はアプリケーションがだれの代理に役立ちたがっているかの管理ドメインを指定します。
Rose, et. al. Standards Track [Page 13] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[13ページ]。
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.
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. さもなければ、この管理ドメインに役立つと申し込みを認めます、そして、「間違いありません、な」要素を返します。
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 -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 終わってください--、>。| | | appl。 | | リレー| | | <、-、-、-、-、-、-、-、-- OK--| | +-------+ +-------+
C: <terminate transID='1' />
S: <ok />
C: <は'1'/>transID=Sを終えます: <OK/>。
or
または
+-------+ +-------+
| | -- terminate --> | |
| appl. | | relay |
| | <------ error -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 終わってください--、>。| | | appl。 | | リレー| | | <、-、-、-、-、-- 誤り--| | +-------+ +-------+
C: <terminate transID='13' />
S: <error code='550'>unknown transaction-identifier</error>
C: '<は13年'/>transID=Sを終えます: <エラーコードは'550'>の未知のトランザクション識別子</誤り>'と等しいです。
or
または
Rose, et. al. Standards Track [Page 14] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[14ページ]。
+-------+ +-------+
| | <-- terminate -- | |
| appl. | | relay |
| | -- ok ---------> | |
+-------+ +-------+
+-------+ +-------+ | | <-- 終わってください--| | | appl。 | | リレー| | | -- OK--------->|、| +-------+ +-------+
C: <terminate transID='1' />
S: <ok />
C: <は'1'/>transID=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"属性はこの操作に関連しているトランザクション識別子を指定します。
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,
o 存在しているなら、「xml: lang」属性は要素の内容が書かれている言語を指定します。 そして
o the textual content is a diagnostic (possibly multiline) which is
meaningful to implementers, perhaps administrators, and possibly
even users.
o 原文の内容はimplementers、恐らく管理者、およびことによるとユーザにとってさえ、重要な病気の特徴(ことによるとマルチライン)です。
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セッションの間のこのアプリケーションによって書き立てられるすべての協会が終えます、そして、「間違いありません、な」要素を返します。
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. さもなければ、トランザクション識別子がこのBEEPチャンネルにおける前の「非-終え」られた操作について言及しないなら、コード550を持っている「誤り」要素を返します。
3. Otherwise, the application is no longer bound as an endpoint or a
relay, and an "ok" element is returned.
3. さもなければ、アプリケーションはもう終点かリレーとして制限されていません、そして、「間違いありません、な」要素を返します。
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.,
リレーメッシュの上にデータを送るアプリケーションかリレー必需品であるときに、それは例えば「データ」要素を送ります。
Rose, et. al. Standards Track [Page 15] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[15ページ]。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| appl。 | | リレー| | #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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@example.com '/と等しい、gt;、</データ>S:、' <OK/>。
or
または
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <------ error -- | |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| appl。 | | リレー| | #1 | <、-、-、-、-、-- 誤り--| | +-------+ +-------+
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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@example.com '/と等しい、gt;、</データ>S:、' <エラーコードは'537'>アクセス拒否</誤り>'と等しいです。
or
または
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| リレー| | 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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@example.com '/と等しい、gt;、</データ>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 「創始者」要素はデータを送りながら、終点について言及します。
Rose, et. al. Standards Track [Page 16] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[16ページ]。
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 もしあれば「オプション」要素は1データあたりのオプションと呼ばれた追加処理オプション(セクション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 もしあれば「オプション」要素は1創始者あたりのオプションと呼ばれた創始者のための追加処理オプションを指定します。
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 もしあれば「オプション」要素は1受取人あたりのオプションと呼ばれたこの受取人に追加処理オプションを指定します。
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. 「創始者」終点(c.f.、セクション4.5)を代表してデータを溯源するか、またはリレーするのにBEEPクライアントに権限を与えないなら、コード537を持っている「誤り」要素を返します。
2. If any per-data options are present, they are processed.
2. 何か1データあたりのオプションが存在しているなら、それらは処理されます。
3. An "ok" element is returned.
3. 「間違いありません、な」要素を返します。
4. If any per-originator options are present, they are processed.
4. 何か1創始者あたりのオプションが存在しているなら、それらは処理されます。
5. For each recipient:
5. 各受取人のために:
1. If any per-recipient options are present, they are processed.
1. 何か1受取人あたりのオプションが存在しているなら、それらは処理されます。
Rose, et. al. Standards Track [Page 17] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[17ページ]。
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セッションが確立されて、新しい「データ」を送って、受取人のリレーが「間違いありません、な」要素を返すなら、受取人によって首尾よく処理されると考えられます。
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.
そうだとすれば、その「受取人」要素だけを含んでいて、新しい「データ」要素を対応するアプリケーションに送ります。 受取人の終点が「間違いありません、な」要素を返すなら、受取人によって首尾よく処理されると考えられます。
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. 何かデータや1創始者あたりのオプションが存在しているなら、それらは処理されません(しかし、注意されるかもしれません)。
2. For each recipient:
2. 各受取人のために:
1. If any per-recipient options are present, they are not
processed (but may be noted).
1. 何か1受取人あたりのオプションが存在しているなら、それらは処理されません(しかし、注意されるかもしれません)。
2. If the application is not attached as the recipient endpoint,
then an error in processing has occurred.
2. アプリケーションが受取人終点として取り付けられないなら、処理における誤りは発生しました。
Rose, et. al. Standards Track [Page 18] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[18ページ]。
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. 首尾よく受取人を全く処理できないなら、「誤り」要素を返します。 さもなければ、「間違いありません、な」要素を返します。
4.5 APEX Access Policies
4.5 頂点アクセス方針
Access to APEX is provided by the juxtaposition of:
以下の並置でAPEXへのアクセスを提供します。
o authenticating as a BEEP peer;
o BEEP同輩として、認証します。
o attaching as an APEX endpoint or binding as an APEX relay; and,
o APEX終点としての付くかAPEXリレーとして付きます。 そして
o being listed as an actor by the APEX access service (c.f., [10]).
o 俳優としてAPEXによって記載されているのがサービスにアクセスします。(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 アプリケーションがリレーメッシュに付きたがっているとき、地方の食糧を供給するのは許容APEX終点(c.f.、セクション4.4.1のStep3)へのBEEP同輩のアイデンティティを写像します。
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 "として指定された頂点終点として付くことができます。
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終点" fred@example.com "が頂点終点「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のStep1、.1)。
Rose, et. al. Standards Track [Page 19] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[19ページ]。
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終点として付くなら、それで、データは同じ頂点終点から発することができます。 しかしながら、他の方針が許されている、例えば、データは" wilma@example.com "か" fred@example.com "のどちらかとして管理ドメインで起因することができるかもしれません" wilma@example.com "として指定されたAPEX終点として取り付けられたアプリケーションで。
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のStep5.3、.1)。
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 アプリケーションがリレーとして管理ドメインを代表して付きたがっているとき、地方の食糧を供給するのは許容APEXリレー(c.f.、Step3)へのBEEP同輩のアイデンティティを写像するかもしれません。
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 リレーがデータを受け取っているとき、地方の食糧を供給するのが許容創始者へのBEEP同輩のアイデンティティを写像する、(c.f.、セクション4.4.4のStep1、.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.
また、さらに、リレーは「信じられた」仲介者として構成されるかもしれません、BEEP同輩がそのようなリレーからいるとそれ自体を認証するならデータを受け入れるように。
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:
APEX「オプション」要素の意味論は文脈特有です。 それに従って、APEXオプションの仕様は以下を定義しなければなりません。
o the identity of the option;
o オプションのアイデンティティ。
Rose, et. al. Standards Track [Page 20] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[20ページ]。
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 "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 存在しているなら、「ローカライズしてください」という属性は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.
決勝: リレーが含んでいる要素を直接受取人に伝える場合にだけ、オプションはこのリレーに適用されます。
Rose, et. al. Standards Track [Page 21] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[21ページ]。
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"属性の値が「本当である」なら、処理における誤りは発生しました。
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"オプションは"statusResponse"要素を含むどんなデータ操作でも存在しているはずがありません。 一般に、オプションを間違って受け取るなら、アプリケーションは潜在的ループの振舞いを避けるのに慎重であるはずです。
Consider these examples:
これらの例を考えてください:
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| appl。 | | リレー| | #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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@example.com '/と等しい、gt;、<オプション内部の='statusRequest'targetHopは'最終的な'mustUnderstandは'本当の'=transID86年'/></データ>Sと等しいこと'と等しいです。 <OK/>。
Rose, et. al. Standards Track [Page 22] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[22ページ]。
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| | <--------- ok -- | #2 |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| リレー| | 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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@example.com '/と等しい、gt;、<オプション内部の='statusRequest'targetHopは'最終的な'mustUnderstandは'本当の'=transID86年'/></データ>Sと等しいこと'と等しいです。 <OK/>。
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
+-------+ +-------+ | | <、-、-、-、-、-、-- データ--| | | appl。 | | リレー| | #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: <回答コードは'250と等しいです。'データが満足させる<が'#Content'><創始者のアイデンティティ='頂点= report@example.com '/と等しい、gt;、<受取人のアイデンティティが' fred@example.com '/と等しい、gt;、<データ内容Nameが'内容'><statusResponse transIDは86年の'><目的地のアイデンティティ=' barney@example.com と等しいこと'と等しい、gt;、'/></目的地></statusResponse>は></データ>Sを</データで満足します'。 <OK/>。
or
または
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| appl。 | | リレー| | #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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@example.com '/と等しい、gt;、<オプション内部の='statusRequest'targetHopは'最終的な'mustUnderstandは'本当の'=transID86年'/></データ>Sと等しいこと'と等しいです。 <OK/>。
Rose, et. al. Standards Track [Page 23] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[23ページ]。
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | |
+-------+ +-------+
+-------+ +-------+ | | <、-、-、-、-、-、-- データ--| | | appl。 | | リレー| | #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: <回答コードは'550と等しいです。'データが満足させる<が'#Content'><創始者のアイデンティティ='頂点= report@example.com '/と等しい、gt;、<受取人のアイデンティティが' fred@example.com '/と等しい、gt;、<データ内容Nameが'内容'><statusResponse transIDは86年の'><目的地のアイデンティティ=' barney@example.com と等しいこと'と等しい、gt;、'>の未知の終点アイデンティティ</回答>の</目的地></statusResponse>は></データ>Sを</データで満足します'。 <OK/>。
or
または
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| #1 | <--------- ok -- | #1 |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| appl。 | | リレー| | #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: データが満足させる<='Cid: 1@example.com '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@rubble.com '/と等しい、gt;、<オプション内部の='statusRequest'targetHopは'最終的な'mustUnderstandは'本当の'=transID86年'/></データ>Sと等しいこと'と等しいです。 <OK/>+-------+ +-------+ | | -- データ------->|、|、| リレー| | リレー| | #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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@rubble.com '/と等しい、gt;、<オプション内部の='statusRequest'targetHopは'最終的な'mustUnderstandは'本当の'=transID86年'/></データ>Sと等しいこと'と等しいです。 <OK/>。
Rose, et. al. Standards Track [Page 24] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[24ページ]。
+-------+ +-------+
| | -- data -------> | |
| relay | | appl. |
| #2 | <--------- ok -- | #2 |
+-------+ +-------+
+-------+ +-------+ | | -- データ------->|、|、| リレー| | 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 '><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが' barney@example.com '/と等しい、gt;、<オプション内部の='statusRequest'targetHopは'最終的な'mustUnderstandは'本当の'=transID86年'/></データ>Sと等しいこと'と等しいです。 <OK/>。
+-------+ +-------+
| | <------- data -- | |
| relay | | relay |
| #1 | -- ok ---------> | #2 |
+-------+ +-------+
+-------+ +-------+ | | <、-、-、-、-、-、-- データ--| | | リレー| | リレー| | #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: <回答コードは'250と等しいです。'データが満足させる<が'#Content'><創始者のアイデンティティ='頂点= report@rubble.com '/と等しい、gt;、<受取人のアイデンティティが' fred@example.com '/と等しい、gt;、<データ内容Nameが'内容'><statusResponse transIDは86年の'><目的地のアイデンティティ=' barney@rubble.com と等しいこと'と等しい、gt;、'/></目的地></statusResponse>は></データ>Sを</データで満足します'。 <OK/>。
+-------+ +-------+
| | <------- data -- | |
| appl. | | relay |
| #1 | -- ok ---------> | #1 |
+-------+ +-------+
+-------+ +-------+ | | <、-、-、-、-、-、-- データ--| | | appl。 | | リレー| | #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: 'データが満足させる<が'#Content'><創始者のアイデンティティ='頂点= report@rubble.com '/と等しい、gt;、<受取人のアイデンティティが' fred@example.com '/と等しい、gt;、<データ内容Nameが'内容'><statusResponse transIDは86年の'><目的地のアイデンティティ=' barney@rubble.com と等しいこと'と等しい、gt;、<回答コード='250'/>の</目的地></statusResponse>'
Rose, et. al. Standards Track [Page 25] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[25ページ]。
</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"属性を「すべて」に設定することによってリレーメッシュを通したデータの通路の跡を達成できることに注意してください。
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 | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
+----------+ +----------+ +----------+ +---------+ | 頂点| | 頂点| | 頂点| | | | アクセス| | 存在| | レポート| | ... | | サービス| | サービス| | サービス| | | +----------+ +----------+ +----------+ +---------+ | | | | | | | | +----------------------------------------------------------------+ | | | APEXコア| | | +----------------------------------------------------------------+
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
すなわち、アプリケーションは、APEXサービスで「よく知られる終点」(WKE)とデータを交換することによって、伝えます。
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アプリケーションはレポートサービスで対応する管理ドメインでよく知られる終点「頂点=レポート」とデータを交換することによって、伝えます、例えば、「頂点= report@example.com 」は"example.com"管理ドメインでのレポートサービスに関連している終点です。
The specification of an APEX service must define:
APEXサービスの仕様は以下を定義しなければなりません。
o the WKE of the service;
o サービスのWKE。
o the syntax and sequence of messages exchanged with the service;
o サービスで交換されたメッセージの構文と系列。
o what access control tokens are consulted by the service.
o サービスでどんなアクセス制御トークンが相談されますか?
Rose, et. al. Standards Track [Page 26] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[26ページ]。
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のStep5.3、.1)。
6.1 Use of the APEX Core DTD
6.1 頂点コア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コアDTD(セクション9.1)で見つけられた定義を使用するかもしれません。 例えば、回答操作(セクション6.1.2)は、応答のための一般的な形式を提供するために定義されます。
6.1.1 Transaction-Identifiers
6.1.1 トランザクション識別子
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.
o アプリケーションがAPEXサービスで伝えるとき、対照的に、トランザクション識別子はしばしば送られるデータに埋め込まれます。 これは、トランザクション識別子が潜在的に長命であることを意味します。
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.
長命のトランザクション識別子であいまいさの見込みを最小にするために、アプリケーションで生成されたトランザクション識別子の値は予測できないように見えるべきです。
Rose, et. al. Standards Track [Page 27] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[27ページ]。
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:
「回答」要素は、「コード」属性、"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,
o 存在しているなら、「xml: lang」属性は要素の内容が書かれている言語を指定します。 そして
o the textual content is a diagnostic (possibly multiline) which is
meaningful to implementers, perhaps administrators, and possibly
even users.
o 原文の内容はimplementers、恐らく管理者、およびことによるとユーザにとってさえ、重要な病気の特徴(ことによるとマルチライン)です。
6.2 The Report Service
6.2 レポートサービス
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:
"statusResponse"要素は、"transID"属性を持っていて、1つ以上の「目的地」要素を含んでいます:
Rose, et. al. Standards Track [Page 28] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[28ページ]。
o the "transID" attribute specifies the value contained in the
"statusRequest" option; and,
o "transID"属性は"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)はその受取人の配送状態を指定します。
7. Registration Templates
7. 登録テンプレート
7.1 APEX Option Registration Template
7.1 頂点オプション登録テンプレート
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.
問い合わせ先: 郵便の、そして、電子の問い合わせ先をプロフィールの作者に指定してください。
7.2 APEX Service Registration Template
7.2 頂点サービス登録テンプレート
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.
メッセージの系列は交換しました: データがサービスで交換されるオーダーを指定してください。
Rose, et. al. Standards Track [Page 29] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[29ページ]。
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.
終点「頂点はすべてと等しく」て、「頂点=コア」が割り当てられないかもしれないことに注意してください。
7.3 APEX Endpoint Application Registration Template
7.3 頂点終点アプリケーション登録テンプレート
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.
問い合わせ先: 郵便の、そして、電子の問い合わせ先をプロフィールの作者に指定してください。
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"
メッセージはChannel Creationの間、交換しました: 「付いてください」、「ひも」
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.、このメモの「作者のアドレス」セクション
Rose, et. al. Standards Track [Page 30] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[30ページ]。
8.2 Registration: The System (Well-Known) TCP port number for apex-mesh
8.2登録: 頂点メッシュのためのSystem(よく知っている)TCPポートナンバー
Protocol Number: TCP
数について議定書の中で述べてください: TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1
メッセージ・フォーマット、タイプ、Opcodes、および系列: 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.、このメモの「作者のアドレス」セクション
8.3 Registration: The System (Well-Known) TCP port number for apex-edge
8.3登録: 頂点縁へのSystem(よく知っている)TCPポートナンバー
Protocol Number: TCP
数について議定書の中で述べてください: TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 9.1
メッセージ・フォーマット、タイプ、Opcodes、および系列: 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.、このメモの「作者のアドレス」セクション
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.、このメモの「作者のアドレス」セクション
Rose, et. al. Standards Track [Page 31] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[31ページ]。
8.5 Registration: The Report Service
8.5登録: レポートサービス
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.、このメモの「作者のアドレス」セクション
9. DTDs
9. DTD
9.1 The APEX Core DTD
9.1 頂点コアDTD
<!--
DTD for the APEX core, as of 2001-07-09
<!--2001年7月9日現在APEXコアへのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%APEXCORE;
-->
<!実体%APEXCORE公共の「-//IETF//DTD頂点コア//アン」、「「>%APEXCORE」 -->。
<!ENTITY % BEEP PUBLIC "-//IETF//DTD BEEP//EN" ""> %BEEP;
<!実体%が公共の「-//IETF//DTDビープ音//アン」を鳴らす、「「>%は鳴ります」。
<!--
DTD data types:
<!--DTDデータ型:
entity syntax/reference example
====== ================ =======
APEX endpoint
ENDPOINT entity, fred@example.com
c.f., Section 2.2
実体構文/参照の例====== ================ ======= APEX終点ENDPOINT実体、 fred@example.com c.f.、セクション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
秒SECONDS0。2147483647 600
timestamp
TIMESTAMP c.f., [12] 2000-05-15T13:02:00-08:00
タイムスタンプTIMESTAMP c.f.、[12]2000-05-15T13: 2時0分から8時0分
unique-identifier
ユニークな識別子
Rose, et. al. Standards Track [Page 32] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[32ページ]。
UNIQID 1..2147483647 42
UNIQID1。2147483647 42
unique-identifier OR zero
UNIZID 0..2147483647 0
-->
ユニークな識別子ORゼロUNIZID0。2147483647 0-->。
<!ENTITY % ENDPOINT "CDATA"> <!ENTITY % DOMAIN "CDATA"> <!ENTITY % SECONDS "CDATA"> <!ENTITY % TIMESTAMP "CDATA"> <!ENTITY % UNIQID "CDATA"> <!ENTITY % UNIZID "CDATA">
<!実体%終点、「CDATA、「><!実体%ドメイン、「CDATA、「><!実体%秒、「CDATA、「><!実体%タイムスタンプ、「CDATA「><!実体%UNIQID」CDATA「><!実体%UNIZID」CDATA">"
<!--
APEX messages, exchanged as application/beep+xml
APEXメッセージであって、アプリケーション/ビープ音+xmlとして交換された<!
role MSG RPY ERR
====== === === ===
I attach ok error
役割のMSG RPY ERR====== === === === 私は間違いない誤りを付けます。
I or L bind ok error
私かLが間違いない誤りを縛ります。
I or L terminate ok error
私かLが間違いない誤りを終えます。
I or L data ok error
-->
私かLデータOK誤り-->。
<!ELEMENT attach (option*)>
<!ATTLIST attach
endpoint %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENTは(オプション*)><を取り付けます!ATTLISTは終点%ENDPOINTを取り付けます。 #transID%UNIQIDが必要でした。 #必要な>。
<!ELEMENT bind (option*)>
<!ATTLIST bind
relay %DOMAIN; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENTは(オプション*)><を縛ります!ATTLISTはリレー%DOMAINを縛ります。 #transID%UNIQIDが必要でした。 #必要な>。
<!ELEMENT terminate (#PCDATA)>
<!ATTLIST terminate
code %XYZ; "250"
xml:lang %LANG; #IMPLIED
transID %UNIZID; "0">
<!ELEMENTはATTLISTが終える><!を終えて(#PCDATA)、%XYZをコード化してください。 「250」 xml: lang%ラング。 #transID%UNIZIDは含意しました。 「0インチの>」
<!ELEMENT data (originator,recipient+,option*,data-content?)>
<!ATTLIST data
content %URI; #REQUIRED>
<!ELEMENTデータ(創始者、受取人+、オプション*、データ内容?)><!ATTLISTデータ内容%URI。 #必要な>。
<!ELEMENT originator (option*)>
<!ELEMENT創始者(オプション*)>。
Rose, et. al. Standards Track [Page 33] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[33ページ]。
<!ATTLIST originator
identity %ENDPOINT; #REQUIRED>
<!ATTLIST創始者アイデンティティ%ENDPOINT。 #必要な>。
<!ELEMENT recipient (option*)>
<!ATTLIST recipient
identity %ENDPOINT; #REQUIRED>
<!ELEMENT受取人(オプション*)><!ATTLIST受取人アイデンティティ%ENDPOINT。 #必要な>。
<!ELEMENT data-content
ANY>
<!ATTLIST Name ID #REQUIRED>
どんな<!ELEMENTデータ内容><!ATTLIST Name ID#REQUIRED>。
<!ELEMENT ok EMPTY>
<!のELEMENTの間違いないEMPTY>。
<!ELEMENT reply (#PCDATA)>
<!ATTLIST reply
code %XYZ; #REQUIRED
transID %UNIQID; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT回答(#PCDATA)><!ATTLIST回答コード%XYZ。 #transID%UNIQIDが必要でした。 #REQUIRED xml: lang%ラング。 #暗示している>。
<!-- 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がどんな><!ATTLISTオプションの内部のNMTOKENにもゆだねる、「「外部の%ユリ」 「「targetHop(これ| 決勝| すべて)の「最終的な」mustUnderstand、(本当の| 偽) 「偽」transID%UNIQID;、」 #REQUIREDは、%がLOCSであるとローカライズします。 「i-デフォルト">"
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;
-->
<!実体%APEXREPORT公共の「-//Blocks//DTD頂点レポート//アン」、「「>%APEXREPORT」 -->。
<!ENTITY % APEXCORE PUBLIC "-//Blocks//DTD APEX CORE//EN" ""> %APEXCORE;
<!実体%APEXCORE公共の「-//Blocks//DTD頂点コア//アン」、「「>%APEXCORE」
<!--
Synopsis of the APEX report service
<!--APEXレポートサービスの構文
Rose, et. al. Standards Track [Page 34] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[34ページ]。
service WKE: apex=report
WKEを調整してください: 頂点=レポート
message exchanges:
交換処理:
service initiates consumer replies
================= ================
statusResponse (nothing)
サービスは消費者回答を開始します。================= ================ statusResponse(何でもない)
access control tokens: none
-->
コントロールトークンにアクセスしてください: なにも-->。
<!ELEMENT statusResponse
(destination+)>
<!ATTLIST statusResponse
transID %UNIQID; #REQUIRED>
<!要素statusResponse(目的地+)><!ATTLIST statusResponse transID%UNIQID。 #必要な>。
<!ELEMENT destination (reply)>
<!ATTLIST destination
identity %ENDPOINT; #REQUIRED>
<!ELEMENT目的地(回答)><!ATTLIST目的地アイデンティティ%ENDPOINT。 #必要な>。
10. Reply Codes
10. 回答コード
code meaning
==== =======
250 transaction successful
コード意味==== ======= 250トランザクションうまくいきます。
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 ユーザのために認可されなかった動作
Rose, et. al. Standards Track [Page 35] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[35ページ]。
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トランザクション
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暗号を使用します)
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暗号を使用します)
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終点実装は、メッセージの保全と秘密性を提供しながらMIMEベースのセキュリティー・サービスを提供するのを選ぶかもしれません、OpenPGP[13]やS/MIME[14]のように。
Regardless, since APEX is a profile of the BEEP, consult [1]'s Section 9 for a discussion of BEEP-specific security issues.
BEEP特有の安全保障問題の議論のための[1]によるAPEXがBEEPのプロフィールであり、相談するので不注意に、セクション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.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[2] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
Rose, et. al. Standards Track [Page 36] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[36ページ]。
[3] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[3]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[4]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2044。
[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」、RFC2782、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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[7] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[7] レヴィンソン、1998年8月、E.、「MIMEの複合の、または、関連の文書内容」RFC2387。
[8] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[8] レヴィンソン、E.、「コンテントIDとMessage ID Uniform Resource Locator」、RFC2392、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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.クロッカー、「アプリケーション交換(頂点)アクセス・サービス」、RFC3341、2002年7月。
[11] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
(APEX) Presence Service", Work in Progress.
[11] 「アプリケーション交換(頂点)存在サービス」というローズ、M.、Klyne、G.、およびD.クロッカーは進行中で働いています。
[12] Newman, C. and G. Klyne, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[12] ニューマン、C.、およびG.Klyneは「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、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.とレヴィエンとR.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」、RFC3156、2001年8月。
[14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[14]Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
Rose, et. al. Standards Track [Page 37] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[37ページ]。
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、ダーレンNewのクリス・ニューマン、スコット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で指定されるように標準化過程ビープ音プロフィールとしての「頂点」を登録しました。
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;
o APEXオプション、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で指定された登録証明書をします。
Rose, et. al. Standards Track [Page 38] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[38ページ]。
Authors' Addresses
作者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
Inc.POB255268サクラメント、カリフォルニア95865-5268米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 8878年の916 483メール: mrose@dbc.mtview.ca.us
Graham Klyne Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
グラハムKlyne Clearswift社1310の水辺アーリントンビジネスパークTheale、読書RG7 4SAイギリス
Phone: +44 11 8903 8903 EMail: Graham.Klyne@MIMEsweeper.com
以下に電話をしてください。 +44 11 8903 8903はメールされます: Graham.Klyne@MIMEsweeper.com
David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 US
デヴィッドH.医者ブランデンブルクインターネットワーキング675は米国でDriveサニーベル、カリフォルニア 94086を小綺麗にします。
Phone: +1 408 246 8253 EMail: dcrocker@brandenburg.com URI: http://www.brandenburg.com/
以下に電話をしてください。 +1 8253年の408 246メール: dcrocker@brandenburg.com ユリ: http://www.brandenburg.com/
Rose, et. al. Standards Track [Page 39] RFC 3340 The Application Exchange Core July 2002
etローズ、アル。 規格はアプリケーション交換コア2002年7月にRFC3340を追跡します[39ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rose, et. al. Standards Track [Page 40]
etローズ、アル。 標準化過程[40ページ]
一覧
スポンサーリンク
