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
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This memo describes 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）アクセスサービスは、よく知られているエンドポイント「=頂点アクセス」として扱わについて説明します。アクセスサービスは、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.
このメモはAPEX [1]「中継網」上に構築されているアクセスサービスを記述します。 APEXアクセスサービスは、中継メッシュと他のAPEXサービスの両方の使用を制御するために使用されます。
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 | | 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=access@example.com」は、「例では、アクセスサービスに関連付けられたエンドポイントであります.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]).
単一の管理ドメイン内に、中継メッシュ発信元が受信者（[1]のセクション4.4.4.1のC.F.、ステップ5.3）にデータを送信するために許可されているかどうかを決定するために、APEX・アクセス・サービスを利用することに留意されたいです。
Access information is organized around access entries, each of which contains:
アクセス情報が含まれているの各アクセスエントリ、中心に構成されています。
o an owner: an APEX address with which the entry is associated;
O所有者：エントリが関連付けられているAPEXアドレス。
o an actor: an APEX address that is granted permission to perform some action in the context of the owner;
俳優のO：所有者のコンテキストでいくつかのアクションを実行する権限を付与されているAPEXアドレス。
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.
所与の所有者のアクセスエントリは、データ配信、アクセス制御、およびプレゼンス情報など、異なるAPEXサービスの潜在的に大きな範囲へのアクセスを制御します。また、セクション4.5 [1]のように中継ピア認証、メッセージなどの活動を管理し、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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='fred@example.com '/> <受信者identity='apex=access@example.com' /> <データコンテンツ名= 'コンテンツ'> <クエリowner='fred@example.com 'TRANSID = '1' actor='barney@example.com' アクション= 'コア：データの有無：購読' /> </データ・コンテンツ> </データ> 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=access@example.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> <許可TRANSID = '1' /> </データ・コンテンツ> </データ> 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='fred@example.com '/> <受信者identity='apex=access@example.com' /> <データコンテンツ名= 'コンテンツ'> < GET TRANSID = '2' owner='fred@example.com 'actor='*@example.com' /> </データ・コンテンツ> </データ> 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=access@example.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> <設定TRANSID = '2'> <アクセスowner='fred@example.com 'actor='*@example.com' アクション= 'コア：データの有無：購読' LASTUPDATE = '2000-05-14T13：02：00〜 8時' /> </設定> </データ・コンテンツ> </データ> 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='wilma@example.com '/> <受信者identity='apex=access@example.com' /> <データコンテンツ名= 'コンテンツ'> <設定TRANSID = '1'> <アクセスowner='fred@example.com 'actor='*@example.com' アクション= 'コア：データの有無：購読' LASTUPDATE = '2000-05-14T13：02：00〜 8時' /> </設定> </データ・コンテンツ> </データ> 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（注）アクセスエントリの「最終更新日」属性がそのエントリを更新するために供給されることを必要とします。したがって、アプリケーションが正常にそのエントリを変更しようとする前に、アクセスエントリを取得する必要があります。 （当然のことながら、管理者がアクセスエントリを変更するために許可されたアプリケーションはまた、そのエントリを取得するために許可されていることを確認する必要があります。）
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
サービスは直ちに例えば、同じトランザクション識別子を含む応答操作を応答します、
+-------+ +-------+
| | <------- 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=access@example.com '/> <受信者identity='wilma@example.com' /> <データコンテンツ名= 'コンテンツ'> <コードを返信= '250' TRANSID = '1' /> </データコンテンツ> </データ> 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.
ステップ6.2および4.4節の9.2は、それが作成または変更されたときにアクセスサービスは、アクセスエントリーの「最終更新日」属性を更新することを必要とすることに注意してください。
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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=access@example.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> <設定TRANSID = '1'> <アクセスowner='fred@example.com 'actor='*@example.com' アクション= 'コア：データの有無：購読' LASTUPDATE = '2000-05-14T23：02：00〜 8時' /> </設定> </データ・コンテンツ> </データ> 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='wilma@example.com '/> <受信者identity='apex=access@example.com' /> <データコンテンツ名= 'コンテンツ'> <設定TRANSID = '2'> <アクセスowner='fred@example.com 'actor='*@example.com' LASTUPDATE = '2000-05-14T13：02：00-08：00' /> </設定> </データ・コンテンツ> </データ> S：<OK />
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
サービスは直ちに例えば、同じトランザクション識別子を含む応答操作を応答します、
+-------+ +-------+
| | <------- 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=access@example.com '/> <受信者identity='wilma@example.com' /> <データコンテンツ名= 'コンテンツ'> <コードを返信= '250' TRANSID = '2' /> </データコンテンツ> </データ> 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 />
C：<データコンテンツ= '＃コンテンツ'> <創始identity='apex=access@example.com '/> <受信者identity='fred@example.com' /> <データコンテンツ名= 'コンテンツ'> <設定TRANSID = '2'> <アクセスowner='fred@example.com 'actor='*@example.com' LASTUPDATE = '2000-05-14T13：02：00-08：00' /> </設定> </データ・コンテンツ> </データ> 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.
アクセス制御は、特定の所有者/俳優の組み合わせのアクセスエントリを削除し、俳優の限られたワイルドカードをサポートするので、許可を変更するのではなく、除去することができることに留意されたいです。このため、特別なアクション、「すべて：なし」が使用されています。
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' />
<アクセスowner='fred@example.com 'actor='*@example.com' アクション= 'コア：データ' 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:
代わりに、最初のアクセスエントリは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節は、アクセスエントリーの構文を定義します。各アクセスエントリは、「所有者」属性、「俳優」属性、「アクション」属性、「最終更新日」属性、および無コンテンツがあります。
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「俳優」属性は、エンティティまたは後述のようにアクセス権限が、指定されている誰のためにエンティティのグループを指定します。
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「最終更新日」属性はサービスが最後にアクセスエントリを作成または変更された日付と時刻を指定します。
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 "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「なし」は、「ALL：なし」、例えば、何らの操作を指すために使用されません。
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:
俳優はAPEXアドレス、[1]のセクション2.2で指定された「実体」構文を使用して指定されています。しかし、「ローカル」と「ドメイン」の部分の両方が制限されたワイルドカードを含めることができます。
o The "local" part is either:
O「ローカル」の部分は、いずれかです：
* a literal string (e.g., "fred");
*リテラル文字列（例えば、「フレッド」）。
* a subaddress wildcard (e.g., "fred/*" or "apex=pubsub/*"); or,
* the value "apex=*", specifying all APEX services;
*値は「頂点= *」、すべてのAPEXサービスを指定します。
* the value "*", specifying any address other than an APEX service.
*値は「*」、APEXサービス以外の任意のアドレスを指定します。
o The "domain" part is either:
O「ドメイン」の部分は、いずれかです：
* a FQDN (e.g., "example.com");
* A FYADN（EG "eksample.tsum"）;
* 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と」マッチ「example.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'
俳優= 'ローカル@ドメイン' アクション= 'all：すべての' 役者= '頂点= * @ドメインのアクション= 'all：すべての'=俳優の頂点= * @ *'アクション= 'コア：データ' 俳優= '* @ *」アクション= 'すべて：なし'
where "local@domain" specifies the owner associated with the access entry.
ここで、「ローカル@ドメイン」は、アクセスエントリに関連付けられている所有者を指定します。
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のサービスを可能にする「頂点= * @ドメイン」のデフォルトのエントリを上書きしません。
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エンドポイント名は、合法的に「*」文字を含めることができますが、アクセスエントリーは「*」ワイルドカードを示すために使用します。したがって、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.
この規則は、唯一の「取得」操作と「設定」の操作で表示される「アクセス」のエントリのの「俳優」属性に使用されていることに注意してください。この操作は、ワイルドカードを許可しないようしかし、この規則は、「クエリ」操作で使用されていません。
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 '\'.)
例えば、「取得」操作または「アクセス」のエントリでの「\ b*c@example.com」と名付けられたエンドポイント、文字列を指定するには、「\\ B \ *c@example.comは」中古;しかし、「クエリ」の操作で、文字列は「\ 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,
*主キーとして俳優値のドメイン部分と一致の正確さを使用します。そして、
* Use the exactness of the match with the local part of the actor value as the secondary key.
*二次キーとして俳優の値のローカル部分との一致の正確さを使用してください。
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' />
<アクセスowner='fred@example.com「actor='wilma@example.comのアクション= 'all：すべての' LASTUPDATE = '2000-05-14T13：20：00-08：00' /> <アクセス所有者= 'fred@example.com' actor='mr.slate@example.com 'アクション= 'コア：データ' LASTUPDATE = '2000-05-14T13：20：00-08：00'/> <アクセス所有者=' フレッド/appl=wb@example.com 'actor='barney/appl=wb@example.com' アクション= 'コア：データ' LASTUPDATE = '2000-05-14T13：20：00-08：00' /> <アクセスowner='fred@example.com 'actor='*@example.com' アクション= 'コア：データの有無：プレゼンスを購読する：見て' 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' />
<アクセスowner='fred@example.com」俳優= '* @ *' アクション= 'コア：データ' LASTUPDATE = '2000-05-14T13：20：00-08：00' />
Briefly:
簡単に言えば：
o For addresses within the "example.com" administrative domain:
「example.com」の管理ドメイン内のアドレスの場合○：
* "fred", "wilma", and all APEX services within the "example.com" administrative domain are allowed access to all operations for "fred@example.com";
*「フレッド」、「ウィルマ」、および「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,
*「バーニー/ APPL = WBは、」のみ「APPL = WBフレッド/」、「fred@example.com」のサブアドレスにデータを送信するためのアクセスを許可されています。そして、
* 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のプレゼンスサービスの「観る」「購読する」と操作を起動します。
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.
「example.com」の管理ドメイン外の任意のアドレスの場合oは、アドレスに関係なく、それは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.
取得および設定操作は、特別なワイルドカード処理が行われないため、アクセスルールを作成および更新するための基本的な機構として設けられています。
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節では、アクセスサービスのAPEXのサービス登録が含まれています。
o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=access".
管理ドメイン内のO、サービスは「頂点=アクセス」のよく知られたエンドポイントを使用して対処しています。
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コンテンツがBEEP [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' />
<クエリowner='fred@example.com 'TRANSID = '1' actor='barney@example.com' アクション= 'コア：データの有無：購読' />
then the corresponding BEEP message might look like this:
その後、対応するBEEPメッセージは次のようになります。
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
C：MSG 1 1。 42 267 C：コンテンツタイプ：アプリケーション/ビープ+ xmlのC：C：<データコンテンツ= '＃コンテンツ'> C <発信identity='fred@example.com '/> C <受信者アイデンティティ=' 頂点= access@example.com '/> C：<データ・コンテンツ名= 'コンテンツ'> C：<クエリowner='fred@example.com' TRANSID = '1' C：actor='barney@example.com」C ：アクション= 'コア：データの有無：購読' /> C </データコンテンツ> C </データ> 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「俳優」属性は、アクセス権限が照会される（ワイルドカードなし）アドレスを指定します。
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」属性は、この操作に関連するトランザクション識別子を指定します。
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.クエリ要素のactor属性を照合対象者のアクセスエントリは（参照、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.クエリ要素の「アクション」属性の権限のすべての場合は、「許可」要素が発信者に送信され、その後、選択したアクセスエントリに含まれています。
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.
いくつかの所有者/俳優の組み合わせのアクセスエントリを作成または更新する前に、アプリケーションは通常、既存のアクセスエントリを取得する必要があります。これは、サービスに、「取得」の要素を送信することによって、そうします。具体的には、成功応答は、その後の「セット」要素を送信するときに必要である「最終更新日」の値を返します。
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「俳優」属性は、アクセス権限が取得される（可能なワイルドカード付き）アドレスを指定します。そして、
o the "transID" attribute specifies the transaction-identifier associated with this operation.
O「TRANSID」属性は、この操作に関連するトランザクション識別子を指定します。
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.その「俳優」の同一属性「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」属性は、発信者によって送信された「取得」要素で見つかった値と同じです。
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」属性は、この操作に関連するトランザクション識別子を指定します。そして、
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:
「アクセス」要素は「所有者」属性、「俳優」属性は、オプションの「アクション」属性は、オプションの「最終更新日」属性、および無コンテンツがあります。
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「俳優」属性はアクセス権限が指定されている（可能なワイルドカード付き）アドレスを指定します。
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（交換またはエントリを削除するのみ存在）「最終更新日」属性が置き換えられるアクセスエントリの現在のタイムスタンプを指定します。
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.その「俳優」属性サブジェクトのアクセスエントリは、同一の「設定」要素の「俳優」属性が選択されていると一致します。
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、コード555を有する「返信」要素は、発信者に送信されます。
6. If no such entry exists and the "lastUpdate" attribute is absent in the supplied "set" element, then:
6.このようなエントリが存在しないと「最終更新日」属性は、次いで、供給「セット」要素内に存在しない場合：
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.現在の日付と時刻のサービスの概念に設定されているアクセスエントリの「最終更新日」属性。
4. A "set" element corresponding to the newly-created access entry is sent to the subject's address.
新しく作成されたアクセスエントリに対応する4. A「セット」の要素は、対象のアドレスに送信されます。
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、コード555を有する「返信」要素は、発信者に送信されます。
8. If "actions" attribute of the supplied "access" element is not present, then:
8.付属の「アクセス」要素の「アクション」属性はその後、存在しない場合：
3. A "set" element corresponding to the owner/actor combination, but lacking an "actions" attribute is sent to the subject's address.
3. A「セット」の要素は、所有者/俳優の組み合わせに対応するが、対象者のアドレスに送信され、「アクション」属性を欠いています。
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.更新されたアクセスエントリの「最終更新日」属性は、（任意の置き換えのエントリに関連付けられている「最終更新日」の値とは異なるはずです）現在の日付と時刻のサービスの概念に設定されています。
4. A "set" element corresponding to the newly-updated access entry is sent to the subject's address.
新しく更新されたアクセスエントリに対応する4. A「セット」の要素は、対象のアドレスに送信されます。
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.
操作を処理している間、サービスは「返信」要素に応答することができます。相談セクション10.2の6.1.2 [1]を、それぞれ、定義および応答要素の構文の博覧会のために。
Well-Known Endpoint: apex=access
よく知られているエンドポイント：頂点=アクセス
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年6月19日のようAPEXアクセスサービスのためのDTD、
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % APEXACCESS PUBLIC "-//IETF//DTD APEX ACCESS//EN" ""> %APEXACCESS; -->
<！ENTITY％のAPEXACCESS PUBLIC " - // IETF // DTD APEXアクセス// EN" "">％のAPEXACCESS。 - >
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" ""> %APEXCORE;
<！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">
<！ENTITY％の俳優 "CDATA"> <！ENTITY％でアクション "NMTOKENS">
<!-- Synopsis of the APEX access service
<！ - APEXアクセスサービスの概要
service WKE: apex=access
besokサービス：アペックス=アクセス
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クエリEMPTY> <！ATTLISTクエリ所有者％のENDPOINT。 #REQUIRED俳優％のACTOR。 #REQUIREDアクション％行動。 #REQUIRED TRANSID％UNIQID。 #REQUIRED>
<!ELEMENT get EMPTY> <!ATTLIST get owner %ENDPOINT; #REQUIRED actor %ACTOR; #REQUIRED transID %UNIQID; #REQUIRED>
<！ELEMENT EMPTY取得> <！ATTLIST所有者％エンドポイントを取得します。 #REQUIRED俳優％のACTOR。 #REQUIRED TRANSID％UNIQID。 #REQUIRED>
<!ELEMENT set (access)> <!ATTLIST set transID %UNIQID; #REQUIRED>
！％UNIQID TRANSID <！ELEMENTセット（アクセス）> <ATTLISTセット。 #REQUIRED>
<!ELEMENT allow EMPTY> <!ATTLIST allow transID %UNIQID; #REQUIRED>
<！ELEMENT許可EMPTY> <！ATTLISTはTRANSID％UNIQID許します。 #REQUIRED>
<!ELEMENT deny EMPTY> <!ATTLIST deny transID %UNIQID; #REQUIRED>
<！ELEMENT拒否EMPTY> <！ATTLISTはTRANSID％UNIQID拒否します。 #REQUIRED>
<!-- access entries -->
<！ - アクセスエントリ - >
<!ELEMENT access EMPTY> <!ATTLIST access owner %ENDPOINT; #REQUIRED actor %ACTOR; #REQUIRED actions %ACTIONS; #IMPLIED lastUpdate %TIMESTAMP; #IMPLIED>
<！ELEMENTアクセスEMPTY> <！ATTLISTアクセス所有者％のENDPOINT。 #REQUIRED俳優％のACTOR。 #REQUIREDアクション％行動。 #IMPLIED LASTUPDATE％のタイムスタンプ。 #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]ローズ、M.、Klyne、G.、およびD.クロッカー、 "アプリケーション交換コア"、RFC 3340、2002年7月。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
Authors' Addresses
著者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング株式会社POB 255268サクラメント、CA 95865から5268米
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
電話：+1 916 483 8878 Eメール：mrose@dbc.mtview.ca.us
Graham Klyne Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
グラハムKlyneクリアスウィフト株式会社1310水辺アーリントンビジネスパークTheale、読書RG7 4SA英国
Phone: +44 11 8903 8903 EMail: Graham.Klyne@MIMEsweeper.com
電話：+44 11 8903 8903 Eメール：Graham.Klyne@MIMEsweeper.com
David H. Crocker Brandenburg Consulting 675 Spruce Drive Sunnyvale, CA 94086 US
デビッドH.クロッカーブランデンブルクコンサルティング675スプルースドライブサニーベール、CA 94086米国
Phone: +1 408 246 8253 EMail: dcrocker@brandenburg.com URI: http://www.brandenburg.com/
電話：+1 408 246 8253 Eメール：dcrocker@brandenburg.com URI：http://www.brandenburg.com/
Appendix A. Acknowledgements
付録A.謝辞
The authors gratefully acknowledge the contributions of: Neil Cook, Darren New, Chris Newman, Scott Pead, and Bob Wyman.
ニール・クック、ダレン新しい、クリス・ニューマン、スコットPEAD、ボブ・ワイマン：著者は感謝の貢献を認めます。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。