[要約] RFC 3341は、APEXアクセスサービスに関する仕様であり、アプリケーションの交換を容易にすることを目的としています。
Network Working Group M. Rose
Request for Comments: 3341 Dover Beach Consulting, Inc.
Category: Standards Track G. Klyne
Clearswift Corporation
D. Crocker
Brandenburg InternetWorking
July 2002
The Application Exchange (APEX) Access Service
Application Exchange（APEX）アクセスサービス
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This memo describes the Application Exchange (APEX) access service, addressed as the well-known endpoint "apex=access". The access service is used to control use of both the APEX "relaying mesh" and other APEX services.
このメモは、よく知られているエンドポイント「apex = access」として扱われているアプリケーション交換（apex）アクセスサービスについて説明しています。アクセスサービスは、Apexの「中継メッシュ」と他のApexサービスの両方の使用を制御するために使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use and Management of Access Information . . . . . . . . . . . 3
2.1 Querying Access Information . . . . . . . . . . . . . . . . . 3
2.2 Retrieval of Access Information . . . . . . . . . . . . . . . 4
2.3 Update of Access Information . . . . . . . . . . . . . . . . . 5
3. Format of Access Entries . . . . . . . . . . . . . . . . . . . 9
3.1 Finding the Appropriate Entry: Matching Owners and Actors . . 11
3.2 Creating and Updating Access Entries . . . . . . . . . . . . . 14
4. The Access Service . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 15
4.2 The Query Operation . . . . . . . . . . . . . . . . . . . . . 16
4.3 The Get Operation . . . . . . . . . . . . . . . . . . . . . . 17
4.4 The Set Operation . . . . . . . . . . . . . . . . . . . . . . 18
4.5 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 20
5. Registration: The Access Service . . . . . . . . . . . . . . . 20
6. The Access Service DTD . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
This memo describes an access service that is built upon the APEX [1] "relaying mesh". The APEX access service is used to control use of both the relaying mesh and other APEX services.
このメモでは、頂点[1]「メッシュの中継」に基づいて構築されたアクセスサービスについて説明しています。頂点アクセスサービスは、中継メッシュと他の頂点サービスの両方の使用を制御するために使用されます。
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 domain. APEX services are logically defined as endpoints but given their ubiquitous semantics they do not necessarily need to be associated with a single physical endpoint. As such, they may be provisioned co-resident with each relay within an administrative domain, even though they are logically provided on top of the relaying mesh, i.e.,
Apexは、そのコアで、最良のデータグラムサービスを提供します。管理ドメイン内では、すべてのリレーがそのドメイン内の任意のエンドポイントのメッセージを処理できる必要があります。頂点サービスは論理的にエンドポイントとして定義されていますが、それらのユビキタスなセマンティクスを考えると、必ずしも単一の物理エンドポイントに関連付ける必要はありません。そのため、リレーのメッシュの上に論理的に提供されている場合でも、それらは管理ドメイン内の各リレーと共同居住者である可能性があります。
+----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
つまり、アプリケーションは「よく知られているエンドポイント」（WKE）とデータを交換することにより、Apexサービスと通信します。
APEX applications communicate with the access service by exchanging data with the well-known endpoint "apex=access" in the corresponding administrative domain, e.g., "apex=access@example.com" is the endpoint associated with the access service in the "example.com" administrative domain.
APEXアプリケーションは、対応する管理ドメインの有名なエンドポイント「APEX =アクセス」とデータを交換することにより、アクセスサービスと通信します。.com "管理ドメイン。
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 of [1]).
単一の管理ドメイン内で、リレーするメッシュが頂点アクセスサービスを利用して、オリジネーターが受信者にデータを送信できるかどうかを判断することに注意してください（C.F.、[1]のセクション4.4.4.1のステップ5.3）。
Access information is organized around access entries, each of which contains:
アクセス情報は、アクセスエントリを中心に編成されており、それぞれに以下が含まれています。
o an owner: an APEX address with which the entry is associated;
o 所有者：エントリが関連付けられている頂点アドレス。
o an actor: an APEX address that is granted permission to perform some action in the context of the owner;
o 俳優：所有者の文脈で何らかのアクションを実行する許可を与えられた頂点アドレス。
o a list of actions; and,
o アクションのリスト。そして、
o a timestamp indicating when the service last created or modified the access entry.
o サービスが最後にアクセスエントリを作成または変更した時期を示すタイムスタンプ。
The access entry for a given owner controls access to a potentially large range of different APEX services, such as data delivery, access control, and presence information. In addition, Section 4.5 of [1] discusses APEX access policies that govern such activities as peer authentication, message relaying, and so on.
特定の所有者のアクセスエントリは、データ配信、アクセス制御、存在情報など、潜在的に広い範囲の異なる頂点サービスへのアクセスを制御します。さらに、[1]のセクション4.5では、ピア認証、メッセージの中継などなどのアクティビティを管理するApexアクセスポリシーについて説明します。
Management of access information falls into three categories:
アクセス情報の管理は3つのカテゴリに分類されます。
o applications may query the access service to see if one or more actions are allowed;
o アプリケーションは、アクセスサービスを照会して、1つ以上のアクションが許可されているかどうかを確認できます。
o applications may retrieve access information associated with an owner/actor combination; and,
o アプリケーションは、所有者/俳優の組み合わせに関連するアクセス情報を取得できます。そして、
o applications may modify (i.e., create, replace, or delete) access information associated with an owner/actor combination.
o アプリケーションは、所有者/俳優の組み合わせに関連付けられたアクセス情報を変更（つまり、作成、交換、または削除）する場合があります。
Each is now described in turn.
それぞれが順番に説明されています。
When an application wants to determine whether one or more actions are allowed for an owner/actor combination, it sends a "query" element to the service, e.g.,
アプリケーションが1つまたは複数のアクションが所有者/俳優の組み合わせに許可されているかどうかを判断したい場合、「クエリ」要素をサービスに送信します。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<query owner='fred@example.com' transID='1'
actor='barney@example.com'
actions='core:data presence:subscribe' />
</data-content>
</data>
S: <ok />
The service immediately responds with either an allow or deny operation containing the same transaction-identifier, where "allow" means that all of the actions listed in the query are permitted, e.g.,
このサービスは、同じトランザクション識別子を含む許可または拒否操作のいずれかですぐに応答します。ここでは、「許可」とは、クエリにリストされているすべてのアクションが許可されていることを意味します。
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<allow transID='1' />
</data-content>
</data>
S: <ok />
or
または又はそれとも若しくは乃至或るいは
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<deny transID='1' />
</data-content>
</data>
S: <ok />
When an application wants to retrieve the access entry associated with an owner/actor combination (typically in preparation for updating that access information), it sends a "get" element to the service, e.g.,
アプリケーションが所有者/俳優の組み合わせに関連付けられたアクセスエントリを取得したい場合（通常、そのアクセス情報を更新する準備ができています）、「取得」要素をサービスに送信します。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<get transID='2'
owner='fred@example.com'
actor='*@example.com' />
</data-content>
</data>
S: <ok />
The service immediately responds with a set operation containing the access entry and the same transaction-identifier, e.g.,
このサービスは、アクセスエントリと同じトランザクション識別子を含むセット操作ですぐに応答します。
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<set transID='2'>
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
When an application wants to create or modify an access entry associated with an owner/actor combination, it sends a "set" element to the service containing the new access entry, e.g.,
アプリケーションが所有者/俳優の組み合わせに関連付けられたアクセスエントリを作成または変更する場合、新しいアクセスエントリを含む「セット」要素をサービスに送信します。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<set transID='1'>
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
Note that Step 4 of Section 4.4 requires that the "lastUpdate" attribute of an access entry be supplied in order to update that entry; accordingly, applications must successfully retrieve an access entry prior to trying to modify that entry. (Naturally, administrators should ensure that applications authorized to modify an access entry are also authorized to retrieve that entry.)
セクション4.4のステップ4では、そのエントリを更新するためにアクセスエントリの「lastUpdate」属性を提供することが必要であることに注意してください。したがって、アプリケーションは、そのエントリを変更しようとする前に、アクセスエントリを正常に取得する必要があります。（当然、管理者は、アクセスエントリの変更を許可されたアプリケーションがそのエントリを取得することを許可されていることを確認する必要があります。）
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
このサービスは、同じトランザクションIDENTIFIERを含む返信操作ですぐに応答します。
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<reply code='250' transID='1' />
</data-content>
</data>
S: <ok />
Note that Steps 6.2 and 9.2 of Section 4.4 require that the access service update the "lastUpdate" attribute of an access entry when it is created or modified.
セクション4.4の手順6.2と9.2は、アクセスサービスが作成または変更されたときにアクセスエントリの「lastUpdate」属性を更新することが必要であることに注意してください。
The service also immediately sends a set operation to the owner attribute associated with the access entry, e.g.,
また、このサービスは、アクセスエントリに関連付けられた所有者属性にすぐに設定操作を送信します。
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<set transID='1'>
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe'
lastUpdate='2000-05-14T23:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
When an application wants to delete the access entry associated with an owner/actor combination, it sends a "set" element to the service omitting the permitted actions, e.g.,
アプリケーションが所有者/俳優の組み合わせに関連付けられているアクセスエントリを削除したい場合、許可されたアクションを省略して「セット」要素をサービスに送信します。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<set transID='2'>
<access owner='fred@example.com'
actor='*@example.com'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
このサービスは、同じトランザクションIDENTIFIERを含む返信操作ですぐに応答します。
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<reply code='250' transID='2' />
</data-content>
</data>
S: <ok />
The service also immediately sends a set operation to the owner attribute associated with the access entry, e.g.,
また、このサービスは、アクセスエントリに関連付けられた所有者属性にすぐに設定操作を送信します。
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<set transID='2'>
<access owner='fred@example.com'
actor='*@example.com'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
Because there are no actions associated with this access entry, the owner knows that the entry has been deleted.
このアクセスエントリに関連するアクションがないため、所有者はエントリが削除されたことを知っています。
Note that because access control supported limited wildcarding of actors, deleting an access entry for a particular owner/actor combination, may modify, rather than remove, permission. Because of this, a special action, "all:none", is used.
Access Controlは俳優の限られたワイルドカードをサポートしているため、特定の所有者/俳優の組み合わせのアクセスエントリを削除することは、許可を削除するのではなく、変更することができることに注意してください。このため、特別なアクション、「すべて：なし」が使用されます。
For example, consider these two access entries:
たとえば、これらの2つのアクセスエントリを考慮してください。
<access owner='fred@example.com'
actor='barney@example.com'
actions='core:data presence:subscribe presence:watch'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
Deleting the first access entry will not remove all permissions for for the actor "barney@example.com".
最初のアクセスエントリを削除しても、アクター「barney@example.com」のすべてのアクセス許可が削除されません。
Instead, the first access entry should be modified thusly:
代わりに、最初のアクセスエントリは次のように変更する必要があります。
<access owner='fred@example.com'
actor='barney@example.com'
actions='all:none'
lastUpdate='2000-05-14T13:20:00-08:00' />
Each administrative domain is responsible for maintaining one or more "access entries" for each of its endpoints and associated subaddresses (regardless of whether those addresses are currently attached to the relaying mesh).
各管理ドメインは、それぞれのエンドポイントと関連するサブアドレスの1つ以上の「アクセスエントリ」を維持する責任があります（これらのアドレスが現在中継メッシュに添付されているかどうかに関係なく）。
A separate access entry is required for each actor or group of actors for whom access permission is specified. Section 6 defines the syntax for access entries. Each access entry has an "owner" attribute, an "actor" attribute, an "actions" attribute, a "lastUpdate" attribute, and no content:
アクセス許可が指定されている各俳優または俳優のグループには、個別のアクセスエントリが必要です。セクション6では、アクセスエントリの構文を定義します。各アクセスエントリには、「所有者」属性、「アクター」属性、「アクション」属性、「lastUpdate」属性、およびコンテンツはありません。
o the "owner" attribute specifies the address (endpoint or subaddress) associated with the access entry;
o 「所有者」属性は、アクセスエントリに関連付けられたアドレス（エンドポイントまたはサブアドレス）を指定します。
o the "actor" attribute specifies an entity or group of entities for whom access permissions are specified, as described below;
o 「Actor」属性は、以下に説明するように、アクセス権限が指定されているエンティティまたはエンティティグループを指定します。
o the "actions" attribute specifies the permissions granted to the actor in the context of the owner; and,
o 「アクション」属性は、所有者のコンテキストでアクターに付与された権限を指定します。そして、
o the "lastUpdate" attribute specifies the date and time that the service last created or modified the access entry.
o 「LastUpDate」属性は、サービスが最後にアクセスエントリを作成または変更した日付と時刻を指定します。
An action is specified as a service/operation pair, e.g., the action "presence:publish" refers to the "publish" operation of the "presence" service. Two service values are reserved:
アクションは、サービス/オペレーションペアとして指定されます。たとえば、アクション「存在：パブリッシュ」とは、「存在感」サービスの「公開」操作を指します。2つのサービス値が予約されています。
o "all" is used to refer to all services, e.g., "all:data"; and,
o 「すべて」は、すべてのサービス、例えば「すべて：データ」を参照するために使用されます。そして、
o "core" is used to refer to the service implemented by the relaying mesh, e.g., the "core:data" permission is consulted by the relaying mesh (c.f., Step 5.3 of Section 4.4.4.1 of [1]).
o 「コア」は、リレーメッシュによって実装されたサービスを参照するために使用されます。たとえば、「コア：データ」許可は、中継メッシュ（C.F.、[1]のセクション4.4.4.1のステップ5.3）によって相談されます。
Further, two operation values are reserved:
さらに、2つの操作値が予約されています。
o "all" is used to refer to all operations, e.g., "presence:all"; and,
o 「すべて」は、すべての操作、例えば「存在：すべて」を参照するために使用されます。そして、
o "none" is used to refer to no operations whatsoever, e.g., "all:none".
o 「なし」は、「すべて：なし」など、操作をまったく参照しないために使用されます。
An actor is an APEX address and is specified using the "entity" syntax specified in Section 2.2 of [1]. However, both the "local" and "domain" parts may contain limited wildcarding:
アクターは頂点アドレスであり、[1]のセクション2.2で指定された「エンティティ」構文を使用して指定されています。ただし、「ローカル」部品と「ドメイン」部品の両方に限られたワイルドカードが含まれている場合があります。
o The "local" part is either:
o 「ローカル」部分は次のとおりです。
* a literal string (e.g., "fred");
* 文字通りの文字列（例： "Fred"）;
* a subaddress wildcard (e.g., "fred/*" or "apex=pubsub/*"); or,
* サブアドレスワイルドカード（例： "fred/*"または "apex = pubsub/*"）;または、
* the value "apex=*", specifying all APEX services;
* すべての頂点サービスを指定する値「apex =*」。
* the value "*", specifying any address other than an APEX service.
* 値「*」、頂点サービス以外のアドレスを指定します。
o The "domain" part is either:
o 「ドメイン」部分は次のとおりです。
* a FQDN (e.g., "example.com");
* fqdn（例： "emple.com"）;
* a domain wildcard (e.g., "*.example.com"); or,
* ドメインワイルドカード（例： "*.example.com"）;または、
* the value "*", specifying all administrative domains.
* すべての管理ドメインを指定する値「*」。
Note that in the case of a domain wildcard, the wildcard itself matches zero or more subdomains, e.g., "*.example.com" matches "example.com", "foo.example.com", "bar.foo.example.com", and so on.)
ドメインワイルドカードの場合、ワイルドカード自体はゼロ以上のサブドメインに一致していることに注意してください。たとえば、「*.example.com」は「embles.com」、 "foo.example.com"、 "bar.foo.exampleに一致します。com」など。）
The following default entries are provided for each owner, but are overridden by an explicitly supplied entry with the same actor value:
次のデフォルトエントリは各所有者に提供されますが、同じアクターの値を持つ明示的に提供されたエントリによってオーバーライドされます。
actor='local@domain' actions='all:all'
actor='apex=*@domain' actions='all:all'
actor='apex=*@*' actions='core:data'
actor='*@*' actions='all:none'
where "local@domain" specifies the owner associated with the access entry.
「local@domain」は、アクセスエントリに関連付けられている所有者を指定します。
For example, the explicit entry
たとえば、明示的なエントリ
actor='*@*' actions='core:data'
allows endpoints from any domain to use the relaying mesh to send data to the owner, but does not override the default entry for "apex=*@domain", which allows all APEX services in the owner's domain access to all actions.
任意のドメインのエンドポイントが中継メッシュを使用して所有者にデータを送信できるようにしますが、「APEX =*@Domain」のデフォルトエントリをオーバーライドすることはできません。
APEX endpoint names can legitimately contain the character '*', but access entries use '*' to indicate wildcarding. Accordingly, the two-character sequence '\*' is used to avoid ambiguity in the "actor" attribute. Similarly, to explicitly specify an endpoint name containing '\' in the "actor" attribute, the two-character sequence '\\' is used.
Apex Endpoint名は、文字「*」を合法的に含めることができますが、アクセスエントリは「*」を使用してワイルドカードを示します。したがって、2文字のシーケンス「\*」は、「アクター」属性のあいまいさを回避するために使用されます。同様に、「アクター」属性に「\」を含むエンドポイント名を明示的に指定するには、2文字のシーケンス「\\」が使用されます。
Note that this convention is used only for the "actor" attribute of the "get" operation and of the "access" entry that appears in the "set" operation; however, this convention is not used in the "query" operation, as this operation does not allow wildcarding.
この条約は、「Get」操作と「セット」操作に表示される「アクセス」エントリの「アクター」属性にのみ使用されることに注意してください。ただし、この操作ではワイルドカードが許可されていないため、この規則は「クエリ」操作では使用されていません。
For example, to specify the endpoint named as "a\b*c@example.com" in the "get" operation or in an "access" entry, the string "a\\b\*c@example.com" is used; but in the "query" operation, the string "a\b*c@example.com" is used. (Of course, as name allocation is a local matter, these complications can be avoided by the simple expedient of not using endpoint names containing '*' or '\'.)
たとえば、「get」操作または「アクセス」エントリで「a \ b*c@example.com」という名前のエンドポイントを指定するには、文字列「\\ b \ *c@example.com」は "です"使用済み;ただし、「クエリ」操作では、文字列「a \ b*c@example.com」が使用されています。（もちろん、名前の割り当ては局所的な問題であるため、これらの合併症は、「*」または「\」を含むエンドポイント名を使用しないという単純な手段によって回避できます。）
The use of actor wildcarding makes it possible for several access entries to apply for a given owner/actor combination. When determining which access entry to use when responding to the query operation, the algorithm is:
俳優のワイルドカードを使用すると、いくつかのアクセスエントリが特定の所有者/俳優の組み合わせに応募できるようになります。クエリ操作に応答するときに使用するアクセスエントリを決定する場合、アルゴリズムは次のとおりです。
o Consider only those access entries that are associated with the given owner.
o 指定された所有者に関連付けられているアクセスエントリのみを検討してください。
o Consider only those access entries in which the actor value matches the actor address in the query. If the wildcard character ('*') is present, then it a match is possible only if each wildcard character can be replaced with a non-empty character sequence (one or more characters) to obtain a value identical to the address in the query.
o アクセスエントリのみを考慮して、アクセスバリューがクエリの俳優アドレスと一致します。ワイルドカード文字（ '*'）が存在する場合、各ワイルドカード文字を空の文字なしシーケンス（1つ以上の文字）に置き換えてクエリのアドレスと同一の値を取得できる場合にのみ一致します。。
o Order those remaining access entries:
o 残りのアクセスエントリを注文してください。
* Use the exactness of the match with the domain part of the actor value as the primary key; and,
* プライマリキーとして、Actor Valueのドメイン部分を使用して、一致の正確さを使用します。そして、
* Use the exactness of the match with the local part of the actor value as the secondary key.
* Actor Valueのローカル部分との試合の正確さをセカンダリキーとして使用します。
o When matching with the domain part, an exact match is the best match; otherwise, the shorter the wildcard match, the higher the priority.
o ドメインパーツと一致する場合、正確な一致が最適な一致です。それ以外の場合、ワイルドカードの一致が短いほど優先度が高くなります。
For example, if the actor's domain is "bar.foo.example.com", a match against an entry of "*.foo.example.com" is better than a match against an entry of "*.example.com".
たとえば、俳優のドメインが「bar.foo.example.com」の場合、「*.foo.example.com」のエントリとの一致は、「*.example.com」のエントリとの一致よりも優れています。
o When matching with the local part, an exact match is the best match; otherwise, the shorter the wildcard match, the higher the priority. This is true regardless of whether the wildcarding is for subaddress or service. (Note that a local part with a wildcard subaddress does not have a non-empty match with the same local part without a subaddress.)
o ローカル部分と一致する場合、正確な一致が最適です。それ以外の場合、ワイルドカードの一致が短いほど優先度が高くなります。これは、ワイルドカードがサブアドレスまたはサービス用かどうかに関係なく当てはまります。（ワイルドカードサブアドレスを持つローカル部分は、サブアドレスなしで同じローカルパーツと空ではない一致を持っていないことに注意してください。）
For example, consider these access entries:
たとえば、これらのアクセスエントリを検討してください。
<access owner='fred@example.com'
actor='wilma@example.com'
actions='all:all'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred@example.com'
actor='mr.slate@example.com'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred/appl=wb@example.com'
actor='barney/appl=wb@example.com'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe presence:watch'
lastUpdate='2000-05-14T13:20:00-08:00' />
<access owner='fred@example.com'
actor='*@*'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
Briefly:
簡単に言えば：
o For addresses within the "example.com" administrative domain:
o 「Example.com」管理ドメイン内のアドレスの場合：
* "fred", "wilma", and all APEX services within the "example.com" administrative domain are allowed access to all operations for "fred@example.com";
* 「Fred」、「Wilma」、および「Example.com」管理ドメイン内のすべてのApexサービスは、「fred@example.com」のすべての操作へのアクセスを許可されています。
* "mr.slate" is allowed access only to send data through the relaying mesh to "fred@example.com";
* 「Mr.Slate」は、リレーするメッシュを介してデータを「fred@example.com」に送信するためにのみアクセスを許可されています。
* "barney/appl=wb" is allowed access only to send data to "fred/ appl=wb", a subaddress of "fred@example.com"; and,
* 「barney/ appl = wb」は、「fred@example.com」のサブアドレスである「fred/ appl = wb」にデータを送信するためにのみアクセスを許可されています。そして、
* any other address within the "example.com" administrative domain is allowed access to send data and invoke the "subscribe" and "watch" operations of the APEX presence service with respect to "fred@example.com".
* 「example.com」管理ドメイン内のその他のアドレスは、データを送信し、「fred@example.com」に関してApex Presenceサービスの「サブスクライブ」および「監視」操作を呼び出すことが許可されています。
o For any address outside the "example.com" administrative domain, the address is allowed access to send data, regardless of whether it is an APEX service.
o 「Example.com」管理ドメインの外側のアドレスについて、Apexサービスであるかどうかに関係なく、アドレスはデータを送信するためのアクセスを許可されます。
Note that although the four default entries are always available, the explicit entry for actor "*@*" overrides the corresponding default entry.
4つのデフォルトエントリは常に利用可能ですが、アクターの明示的なエントリ「*@*」は、対応するデフォルトエントリをオーバーライドすることに注意してください。
The get and set operations are provided as a basic mechanism for creating and updating access rules, for which no special wildcard processing is performed.
GETおよびセット操作は、アクセスルールを作成および更新するための基本的なメカニズムとして提供されます。このメカニズムでは、特別なワイルドカード処理は実行されません。
The actor value for an access entry may contain limited wildcard characters which have special significance only when performing a query operation (cf., Section 3.1). For the purposes of retrieving and updating entries, actor values are treated simply as literal names.
アクセスエントリのアクター価値には、クエリ操作を実行するときにのみ特別な重要性を持つ限られたワイルドカード文字が含まれている場合があります（セクション3.1を参照）。エントリを取得および更新する目的で、俳優の価値は単に文字通りの名前として扱われます。
Section 5 contains the APEX service registration for the access service:
セクション5には、アクセスサービスの頂点サービス登録が含まれています。
o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=access".
o 管理ドメイン内では、「apex = access」のよく知られているエンドポイントを使用して、サービスは対処されます。
o Section 6 defines the syntax of the operations exchanged with the service.
o セクション6では、サービスと交換された操作の構文を定義します。
o A consumer of the service initiates communications by sending data containing a query, get, or set operation.
o サービスの消費者は、クエリ、取得、または設定操作を含むデータを送信することにより、コミュニケーションを開始します。
o The service replies to these operations.
o サービスはこれらの操作に返信します。
o When an access entry is changed, the service sends a notification to the owner associated with the changed entry.
o アクセスエントリが変更されると、サービスは変更されたエントリに関連付けられている所有者に通知を送信します。
An implementation of the service must maintain information about access entries in persistent storage.
サービスの実装は、永続的なストレージのアクセスエントリに関する情報を維持する必要があります。
Consult Section 6.1.1 of [1] for a discussion on the properties of long-lived transaction-identifiers.
長寿命の取引識別子の特性に関する議論については、[1]のセクション6.1.1を参照してください。
Section 4.1 of [1] describes how arbitrary MIME content is exchanged as a BEEP [2] payload. For example, to transmit:
[1]のセクション4.1は、任意のMIMEコンテンツがビープ音[2]ペイロードとしてどのように交換されるかを説明しています。たとえば、送信するには：
<data content='...'>
<originator identity='fred@example.com' />
<recipient identity='apex=access@example.com' />
</data>
where "..." refers to:
ここで、「...」とは次のことを指します
<query owner='fred@example.com' transID='1'
actor='barney@example.com'
actions='core:data presence:subscribe' />
then the corresponding BEEP message might look like this:
その後、対応するビープメッセージは次のようになるかもしれません：
C: MSG 1 2 . 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='apex=access@example.com' />
C: </data>
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <2@example.com>
C:
C: <query owner='fred@example.com' transID='1'
C: actor='barney@example.com'
C: actions='core:data presence:subscribe' />
C: --boundary--
C: END
or this:
またはこれ：
C: MSG 1 1 . 42 267
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C: <originator identity='fred@example.com' />
C: <recipient identity='apex=access@example.com' />
C: <data-content Name='Content'>
C: <query owner='fred@example.com' transID='1'
C: actor='barney@example.com'
C: actions='core:data presence:subscribe' />
C: </data-content>
C: </data>
C: END
When an application wants to see if a particular operation is allowed, it sends a "query" element to the service.
アプリケーションが特定の操作が許可されているかどうかを確認したい場合、「クエリ」要素をサービスに送信します。
The "query" element has an "owner" attribute, an "actor" attribute, an "actions" attribute, a "transID" attribute, and no content:
「クエリ」要素には、「所有者」属性、「アクター」属性、「アクション」属性、「transID」属性、およびコンテンツなしを持っています。
o the "owner" attribute specifies the address associated with the access entry;
o 「所有者」属性は、アクセスエントリに関連付けられたアドレスを指定します。
o the "actor" attribute specifies the address (without wildcarding) for which access permissions are queried;
o 「Actor」属性は、アクセス許可が照会されたアドレス（ワイルドカードなし）を指定します。
o the "actions" attribute specifies one or more actions for which permission is queried; and,
o 「アクション」属性は、許可が照会された1つ以上のアクションを指定します。そして、
o the "transID" attribute specifies the transaction-identifier associated with this operation.
o 「TransID」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。
When the service receives a "query" element, we refer to the "owner" attribute as the "subject". The service performs these steps:
サービスが「クエリ」要素を受信した場合、「所有者」属性を「件名」と呼びます。サービスはこれらの手順を実行します。
1. If the subject is outside this administrative domain, a "reply" element having code 553 is sent to the originator.
1. 被験者がこの管理ドメインの外側にある場合、コード553を持つ「返信」要素がオリジネーターに送信されます。
2. If the subject does not refer to a valid address, a "reply" element having code 550 is sent to the originator.
2. 被験者が有効なアドレスを参照していない場合、コード550を持つ「返信」要素がオリジネーターに送信されます。
3. If the subject's access entry matching the originator does not contain an "access:query" token, a "reply" element having code 537 is sent to the originator.
3. 対象者に一致する被験者のアクセスエントリに「アクセス：クエリ」トークンが含まれていない場合、コード537を持つ「返信」要素がオリジネーターに送信されます。
4. The subject's access entry matching the actor attribute of the query element is selected (cf., Section 3.1).
4. クエリ要素のアクター属性に一致する被験者のアクセスエントリが選択されています（セクション3.1を参照）。
5. If all of the permissions in the "actions" attribute of the query element are contained in the selected access entry, then an "allow" element is sent to the originator.
5. クエリ要素の「アクション」属性のすべての権限が選択したアクセスエントリに含まれている場合、「許可」要素がオリジネーターに送信されます。
6. Otherwise, a "deny" element is sent to the originator.
6. それ以外の場合、「拒否」要素がオリジネーターに送信されます。
Regardless of whether an "allow", "deny", or "reply" element is sent to the originator, the "transID" attribute is identical to the value found in the "query" element sent by the originator.
「許可」、「拒否」、または「返信」要素がオリジネーターに送信されるかどうかに関係なく、「TransID」属性は、オリジネーターが送信した「クエリ」要素で見つかった値と同一です。
Prior to creating or updating an access entry for some owner/actor combination, an application will usually need to retrieve any existing access entry. It does so by sending a "get" element to the service. In particular, a successful response returns a "lastUpdate" value that is necessary when sending a subsequent "set" element.
一部の所有者/俳優の組み合わせのアクセスエントリを作成または更新する前に、アプリケーションは通常、既存のアクセスエントリを取得する必要があります。「取得」要素をサービスに送信することでそうします。特に、応答が成功すると、後続の「セット」要素を送信するときに必要な「lastUpdate」値を返します。
The "get" element has an "owner" attribute, an "actor" attribute, a "transID" attribute, and no content:
「get」要素には、「所有者」属性、「俳優」属性、「transID」属性、およびコンテンツはありません。
o the "owner" attribute specifies the address associated with the access entry;
o 「所有者」属性は、アクセスエントリに関連付けられたアドレスを指定します。
o the "actor" attribute specifies the address (with possible wildcarding) for which access permissions are retrieved; and,
o 「Actor」属性は、アクセス許可が取得されるアドレス（可能なワイルドカード）を指定します。そして、
o the "transID" attribute specifies the transaction-identifier associated with this operation.
o 「TransID」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。
When the service receives a "get" element, we refer to the "owner" attribute as the "subject". The service performs these steps:
サービスが「取得」要素を受信すると、「所有者」属性を「サブジェクト」と呼びます。サービスはこれらの手順を実行します。
1. If the subject is outside this administrative domain, a "reply" element having code 553 is sent to the originator.
1. 被験者がこの管理ドメインの外側にある場合、コード553を持つ「返信」要素がオリジネーターに送信されます。
2. If the subject does not refer to a valid address, a "reply" element having code 550 is sent to the originator.
2. 被験者が有効なアドレスを参照していない場合、コード550を持つ「返信」要素がオリジネーターに送信されます。
3. If the subject's access entry matching the originator does not contain an "access:get" token, a "reply" element having code 537 is sent to the originator.
3. 対象者に一致する被験者のアクセスエントリに「アクセス：取得」トークンが含まれていない場合、コード537を持つ「返信」要素がオリジネーターに送信されます。
4. The subject's access entry whose "actor" attribute identically matches the "actor" attribute of the "get" element is selected.
4. 「Actor」属性が「get」要素の「アクター」属性と同じように一致する被験者のアクセスエントリが選択されます。
5. If no such entry exists, a "reply" element having code 551 is sent to the originator.
5. そのようなエントリが存在しない場合、コード551を持つ「返信」要素がオリジネーターに送信されます。
6. Otherwise, a "set" element corresponding to the selected access entry is sent to the originator.
6. それ以外の場合、選択したアクセスエントリに対応する「セット」要素がオリジネーターに送信されます。
Regardless of whether a "set" or "reply" element is sent to the originator, the "transID" attribute is identical to the value found in the "get" element sent by the originator.
「セット」要素または「返信」要素がオリジネーターに送信されるかどうかに関係なく、「TransID」属性は、発信者が送信した「GET」要素に見つかった値と同一です。
When an application wants to modify (i.e., create, replace, or delete) the access entry associated with an owner/actor combination, it sends a "set" element to the service.
アプリケーションが所有者/俳優の組み合わせに関連付けられたアクセスエントリを変更（つまり、作成、交換、または削除）したい場合、「セット」要素をサービスに送信します。
The "set" element has a "transID" attribute, and contains an "access" element:
「セット」要素には「TransID」属性があり、「アクセス」要素が含まれています。
o the "transID" attribute specifies the transaction-identifier associated with this operation; and,
o 「TransID」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。そして、
o the "access" element contains the access entry to be created, replaced, or deleted.
o 「アクセス」要素には、作成、交換、または削除されるアクセスエントリが含まれています。
The "access" element has an "owner" attribute, an "actor" attribute, an optional "actions" attribute, an optional "lastUpdate" attribute, and no content:
「アクセス」要素には、「所有者」属性、「アクター」属性、オプションの「アクション」属性、オプションの「lastUpdate」属性、およびコンテンツはありません。
o the "owner" attribute specifies the address associated with the access entry;
o 「所有者」属性は、アクセスエントリに関連付けられたアドレスを指定します。
o the "actor" attribute specifies the address (with possible wildcarding) for which access permissions are specified;
o 「Actor」属性は、アクセス許可が指定されているアドレス（可能なワイルドカード）を指定します。
o the "actions" attribute (present only to add or replace an entry) specifies one or more actions for which permission is to be determined; and,
o 「アクション」属性（エントリを追加または交換するためにのみ存在します）は、許可を決定する1つ以上のアクションを指定します。そして、
o the "lastUpdate" attribute (present only to replace or delete an entry) specifies the current timestamp of the access entry that is to be replaced.
o 「lastUpdate」属性（エントリの交換または削除のみに存在）は、交換するアクセスエントリの現在のタイムスタンプを指定します。
When the service receives a "set" element, we refer to the "owner" attribute of the access element as the "subject". The service performs these steps:
サービスが「セット」要素を受信する場合、アクセス要素の「所有者」属性を「サブジェクト」と呼びます。サービスはこれらの手順を実行します。
1. If the subject is outside this administrative domain, a "reply" element having code 553 is sent to the originator.
1. 被験者がこの管理ドメインの外側にある場合、コード553を持つ「返信」要素がオリジネーターに送信されます。
2. If the subject does not refer to a valid address, a "reply" element having code 550 is sent to the originator.
2. 被験者が有効なアドレスを参照していない場合、コード550を持つ「返信」要素がオリジネーターに送信されます。
3. If the subject's access entry matching the originator does not contain an "access:set" token, a "reply" element having code 537 is sent to the originator.
3. 対象者に一致する被験者のアクセスエントリに「アクセス：セット」トークンが含まれていない場合、コード537を持つ「返信」要素がオリジネーターに送信されます。
4. The subject's access entry whose "actor" attribute identically matches the "actor" attribute of the "set" element is selected.
4. 「Actor」属性が「セット」要素の「アクター」属性と同じように一致する被験者のアクセスエントリが選択されます。
5. If no such entry exists and the "lastUpdate" attribute is present in the supplied "set" element, a "reply" element having code 555 is sent to the originator.
5. そのようなエントリが存在せず、「lastupdate」属性が提供された「セット」要素に存在する場合、コード555を持つ「返信」要素がオリジネーターに送信されます。
6. If no such entry exists and the "lastUpdate" attribute is absent in the supplied "set" element, then:
6. そのようなエントリが存在しない場合、「lastupdate」属性が提供された「セット」要素に存在しない場合、次のとおりです。
1. The access entry for the owner/actor combination is created from the supplied "access" element.
1. 所有者/俳優の組み合わせのアクセスエントリは、付属の「アクセス」要素から作成されます。
2. The "lastUpdate" attribute of that access entry set to the service's notion of the current date and time.
2. 現在の日付と時刻のサービスの概念に設定された、そのアクセスエントリの「LastUpDate」属性。
3. A "reply" element having code 250 is sent to the originator.
3. コード250を持つ「返信」要素がオリジネーターに送信されます。
4. A "set" element corresponding to the newly-created access entry is sent to the subject's address.
4. 新しく作成されたアクセスエントリに対応する「セット」要素が被験者のアドレスに送信されます。
7. If the selected entry exists, but its "lastUpdate" attribute is not semantically identical to the "lastUpdate" attribute of the supplied "access" element, a "reply" element having code 555 is sent to the originator.
7. 選択したエントリが存在するが、その「lastUpdate」属性が、付属の「アクセス」要素の「lastUpdate」属性とセマンティックに同一ではない場合、コード555を持つ「返信」要素がオリジネーターに送信されます。
8. If "actions" attribute of the supplied "access" element is not present, then:
8. 「アクション」属性が提供された「アクセス」要素が存在しない場合、次のとおりです。
1. The selected entry is deleted.
1. 選択したエントリが削除されます。
2. A "reply" element having code 250 is sent to the originator.
2. コード250を持つ「返信」要素がオリジネーターに送信されます。
3. A "set" element corresponding to the owner/actor combination, but lacking an "actions" attribute is sent to the subject's address.
3. 所有者/俳優の組み合わせに対応するが、「アクション」属性がない「セット」要素が被験者のアドレスに送信されます。
9. Otherwise:
9. さもないと：
1. The access entry for the owner/actor combination is updated from the supplied "access" element.
1. 所有者/俳優の組み合わせのアクセスエントリは、付属の「アクセス」要素から更新されます。
2. The "lastUpdate" attribute of the updated access entry is set to the service's notion of the current date and time (which should be different from the "lastUpdate" value associated with any replaced entry).
2. 更新されたアクセスエントリの「LastUpDate」属性は、現在の日付と時刻のサービスの概念に設定されています（これは、交換されたエントリに関連付けられた「LastUpDate」値とは異なるはずです）。
3. A "reply" element having code 250 is sent to the originator.
3. コード250を持つ「返信」要素がオリジネーターに送信されます。
4. A "set" element corresponding to the newly-updated access entry is sent to the subject's address.
4. 新しくアップデートされたアクセスエントリに対応する「セット」要素が被験者のアドレスに送信されます。
When sending the "reply" element, the "transID" attribute is identical to the value found in the "set" element sent by the originator.
「返信」要素を送信する場合、「transID」属性は、オリジネーターが送信した「セット」要素に見つかった値と同一です。
While processing operations, the service may respond with a "reply" element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for the definition and an exposition of the syntax of the reply element.
操作の処理中、サービスは「返信」要素で応答する場合があります。[1]のセクション10.2および6.1.2をそれぞれ参照してください。応答要素の構文の定義と説明については、それぞれ参照してください。
Well-Known Endpoint: apex=access
よく知られているエンドポイント：apex =アクセス
Syntax of Messages Exchanged: c.f., Section 6
交換されたメッセージの構文：C.F。、セクション6
Sequence of Messages Exchanged: c.f., Section 4
交換されたメッセージのシーケンス：C.F。、セクション4
Access Control Tokens: access:query, access:get, access:set
Contact Information: c.f., the "Authors' Addresses" section of this memo
連絡先情報：C.F。、このメモの「著者のアドレス」セクション
<!-- DTD for the APEX access service, as of 2001-06-19
<！ - 2001-06-19の時点のApexアクセスサービスのDTD
Refer to this DTD as:
このDTDを次のように参照してください。
<!ENTITY % APEXACCESS PUBLIC "-//IETF//DTD APEX ACCESS//EN" "">
%APEXACCESS;
-->
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%APEXCORE;
<!-- DTD data types:
<！-DTDデータ型：
entity syntax/reference example
====== ================ =======
access actor
ACTOR an ENDPOINT or a *@example.com
wildcard
permitted actions ACTIONS a list of access "core:any access:query" tokens -->
許可されたアクションアクションアクセスのリスト「コア：任意のアクセス：クエリ」トークン - >
<!ENTITY % ACTOR "CDATA">
<!ENTITY % ACTIONS "NMTOKENS">
<!-- Synopsis of the APEX access service
<！ - 頂点アクセスサービスの概要
service WKE: apex=access
サービスWKE：apex =アクセス
message exchanges:
メッセージ交換：
consumer initiates service replies
================== ================
query allow, deny, or reply
get set or reply
set reply
service initiates consumer replies
================= ================
set (nothing)
access control:
アクセス制御：
token target
========== ======
access:query for "owner" of "access" element
access:get for "owner" of "access" element
access:set for "owner" of "access" element
-->
<!ELEMENT query EMPTY>
<!ATTLIST query
owner %ENDPOINT; #REQUIRED
actor %ACTOR; #REQUIRED
actions %ACTIONS; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT get EMPTY>
<!ATTLIST get
owner %ENDPOINT; #REQUIRED
actor %ACTOR; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT set (access)>
<!ATTLIST set
transID %UNIQID; #REQUIRED>
<!ELEMENT allow EMPTY>
<!ATTLIST allow
transID %UNIQID; #REQUIRED>
<!ELEMENT deny EMPTY>
<!ATTLIST deny
transID %UNIQID; #REQUIRED>
<!-- access entries -->
<！ - アクセスエントリ - >
<!ELEMENT access EMPTY>
<!ATTLIST access
owner %ENDPOINT; #REQUIRED
actor %ACTOR; #REQUIRED
actions %ACTIONS; #IMPLIED
lastUpdate %TIMESTAMP; #IMPLIED>
Consult [1]'s Section 11 for a discussion of security issues.
セキュリティ問題の議論については、[1]のセクション11に相談してください。
In addition, timestamps issued by the the access service may disclose location information. If this information is considered sensitive, the special timezone value "-00:00" may be used (after converting the local time accordingly).
さらに、アクセスサービスによって発行されたタイムスタンプは、位置情報を開示する場合があります。この情報が敏感であると見なされる場合、特別なタイムゾーン値「-00：00」を使用できます（それに応じて現地時間を変換した後）。
References
参考文献
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange Core", RFC 3340, July 2002.
[1] Rose、M.、Klyne、G。およびD. Crocker、「The Application Exchange Core」、RFC 3340、2002年7月。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
Authors' Addresses
著者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング、Inc。POB 255268サクラメント、CA 95865-5268 US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Graham Klyne Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
Graham Klyne Clearswift Corporation 1310ウォーターサイドアーリントンビジネスパークシール、RG7 4SA UKを読む
Phone: +44 11 8903 8903
EMail: Graham.Klyne@MIMEsweeper.com
David H. Crocker Brandenburg Consulting 675 Spruce Drive Sunnyvale, CA 94086 US
David H. Crocker Brandenburg Consulting 675 Spruce Drive Sunnyvale、CA 94086 US
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/
The authors gratefully acknowledge the contributions of: Neil Cook, Darren New, Chris Newman, Scott Pead, and Bob Wyman.
著者は、ニール・クック、ダレン・ニュー、クリス・ニューマン、スコット・ピード、ボブ・ワイマンの貢献に感謝します。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。