RFC3341 日本語訳
3341 The Application Exchange (APEX) Access Service. M. Rose, G.Klyne, D. Crocker. July 2002. (Format: TXT=46675 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
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
The Application Exchange (APEX) Access Service
Status of this Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
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.
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.
Table of Contents
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
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
Rose, et. al. Standards Track [Page 1] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 1] RFC 3341 The Application Exchange (APEX) Access Service July 2002
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
1. Introduction
1. Introduction
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.
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, 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, 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 | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
+----------+ +----------+ +----------+ +---------+ | 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).
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
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 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.
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]).
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]).
Rose, et. al. Standards Track [Page 2] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 2] RFC 3341 The Application Exchange (APEX) Access Service July 2002
2. Use and Management of Access Information
2. Use and Management of Access Information
Access information is organized around access entries, each of which contains:
Access information is organized around access entries, each of which contains:
o an owner: an APEX address with which the entry is associated;
o an owner: an APEX address with which the entry is associated;
o an actor: an APEX address that is granted permission to perform
some action in the context of the owner;
o an actor: an APEX address that is granted permission to perform some action in the context of the owner;
o a list of actions; and,
o a list of actions; and,
o a timestamp indicating when the service last created or modified
the access entry.
o a timestamp indicating when the service last created or modified the access entry.
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.
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.
Management of access information falls into three categories:
Management of access information falls into three categories:
o applications may query the access service to see if one or more
actions are allowed;
o applications may query the access service to see if one or more actions are allowed;
o applications may retrieve access information associated with an
owner/actor combination; and,
o applications may retrieve access information associated with an owner/actor combination; and,
o applications may modify (i.e., create, replace, or delete) access
information associated with an owner/actor combination.
o applications may modify (i.e., create, replace, or delete) access information associated with an owner/actor combination.
Each is now described in turn.
Each is now described in turn.
2.1 Querying Access Information
2.1 Querying Access Information
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.,
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.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- data -------> | | | appl. | | relay | | | <--------- ok -- | | +-------+ +-------+
Rose, et. al. Standards Track [Page 3] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 3] RFC 3341 The Application Exchange (APEX) Access Service July 2002
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: <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.,
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. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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: <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
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 />
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 />
2.2 Retrieval of Access Information
2.2 Retrieval of Access Information
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.,
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.,
Rose, et. al. Standards Track [Page 4] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 4] RFC 3341 The Application Exchange (APEX) Access Service July 2002
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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: <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.,
The service immediately responds with a set operation containing the access entry and the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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: <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 />
2.3 Update of Access Information
2.3 Update of Access Information
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.,
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.,
Rose, et. al. Standards Track [Page 5] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 5] RFC 3341 The Application Exchange (APEX) Access Service July 2002
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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: <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.)
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.)
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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: <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.
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.
Rose, et. al. Standards Track [Page 6] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 6] RFC 3341 The Application Exchange (APEX) Access Service July 2002
The service also immediately sends a set operation to the owner attribute associated with the access entry, e.g.,
The service also immediately sends a set operation to the owner attribute associated with the access entry, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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: <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.,
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 -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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: <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 />
Rose, et. al. Standards Track [Page 7] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 7] RFC 3341 The Application Exchange (APEX) Access Service July 2002
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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: <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.,
The service also immediately sends a set operation to the owner attribute associated with the access entry, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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: <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.
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.
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.
Rose, et. al. Standards Track [Page 8] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 8] RFC 3341 The Application Exchange (APEX) Access Service July 2002
For example, consider these two access entries:
For example, consider these two access entries:
<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='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' />
<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".
Deleting the first access entry will not remove all permissions for for the actor "barney@example.com".
Instead, the first access entry should be modified thusly:
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' />
<access owner='fred@example.com' actor='barney@example.com' actions='all:none' lastUpdate='2000-05-14T13:20:00-08:00' />
3. Format of Access Entries
3. Format of Access Entries
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).
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).
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:
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:
o the "owner" attribute specifies the address (endpoint or
subaddress) associated with the access entry;
o the "owner" attribute specifies the address (endpoint or subaddress) associated with the access entry;
o the "actor" attribute specifies an entity or group of entities for
whom access permissions are specified, as described below;
o the "actor" attribute specifies an entity or group of entities for whom access permissions are specified, as described below;
o the "actions" attribute specifies the permissions granted to the
actor in the context of the owner; and,
o the "actions" attribute specifies the permissions granted to the actor in the context of the owner; and,
o the "lastUpdate" attribute specifies the date and time that the
service last created or modified the access entry.
o the "lastUpdate" attribute specifies the date and time that the service last created or modified the access entry.
Rose, et. al. Standards Track [Page 9] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 9] RFC 3341 The Application Exchange (APEX) Access Service July 2002
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:
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:
o "all" is used to refer to all services, e.g., "all:data"; and,
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 "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]).
Further, two operation values are reserved:
Further, two operation values are reserved:
o "all" is used to refer to all operations, e.g., "presence:all";
and,
o "all" is used to refer to all operations, e.g., "presence:all"; and,
o "none" is used to refer to no operations whatsoever, e.g.,
"all:none".
o "none" is used to refer to no operations whatsoever, e.g., "all:none".
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:
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:
o The "local" part is either:
o The "local" part is either:
* a literal string (e.g., "fred");
* a literal string (e.g., "fred");
* a subaddress wildcard (e.g., "fred/*" or "apex=pubsub/*"); or,
* a subaddress wildcard (e.g., "fred/*" or "apex=pubsub/*"); or,
* the value "apex=*", specifying all APEX services;
* the value "apex=*", specifying all APEX services;
* the value "*", specifying any address other than an APEX
service.
* the value "*", specifying any address other than an APEX service.
o The "domain" part is either:
o The "domain" part is either:
* a FQDN (e.g., "example.com");
* a FQDN (e.g., "example.com");
* a domain wildcard (e.g., "*.example.com"); or,
* a domain wildcard (e.g., "*.example.com"); or,
* the value "*", specifying all administrative domains.
* 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.)
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.)
Rose, et. al. Standards Track [Page 10] RFC 3341 The Application Exchange (APEX) Access Service July 2002
Rose, et. al. Standards Track [Page 10] RFC 3341 The Application Exchange (APEX) Access Service July 2002
The following default entries are provided for each owner, but are overridden by an explicitly supplied entry with the same actor value:
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'
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.
where "local@domain" specifies the owner associated with the access entry.
For example, the explicit entry
For example, the explicit entry
actor='*@*' actions='core:data'
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.
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 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 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.
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.
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 '\'.)
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 '\'.)
3.1 Finding the Appropriate Entry: Matching Owners and Actors
3.1 Finding the Appropriate Entry: Matching Owners and Actors
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:
俳優wildcardingの使用で、いくつかのアクセスエントリーが与えられた所有者/俳優組み合わせに申し込むのが可能になります。 質問操作に応じるとき、どのアクセスエントリーを使用したらよいかを決定するとき、アルゴリズムは以下の通りです。
o Consider only those access entries that are associated with the
given owner.
o それらの与えられた所有者に関連しているアクセスエントリーだけを考えてください。
Rose, et. al. Standards Track [Page 11] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[11ページ]。
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".
「例えば、」 *.foo.example.comのエントリーに対するマッチ俳優のドメインが"bar.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 地方の部分に合うとき、完全な一致は最も良いマッチです。 さもなければ、ワイルドカードマッチが短ければ短いほど、優先度は、より高いです。 これはwildcardingが「副-アドレス」かサービスのためのものであることにかかわらず本当です。 (「副-アドレス」がするワイルドカードがある地方の部分には同じ地方の部分との非空のマッチが「副-アドレス」なしでないことに注意してください。)
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' />
<アクセス所有者=' fred@example.com '俳優=' wilma@example.com '動作='すべて: すべての'lastUpdate='2000-05-14 T13: 20時0分から8時0分'/><アクセス所有者=' fred@example.com '俳優=' mr.slate@example.com '動作='コア: データ'lastUpdateは'2000-05-14 T13: 20時0分から8時0分'/><アクセス所有者='fred/applは wb@example と等しいこと'と等しいです; ''俳優='バニー/appl= wb@example.com '動作='が芯を取るcom: データ'lastUpdateは'2000-05-14T13と等しいです: '/><アクセス所有者=' fred@example.com '俳優=' *@example.com '動作='が芯を取る20時0分から8時0分: データ存在: 存在を申し込んでください: 見てください'lastUpdate='2000-05-14T13: 20時0分から8時0分'/>。
Rose, et. al. Standards Track [Page 12] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[12ページ]。
<access owner='fred@example.com'
actor='*@*'
actions='core:data'
lastUpdate='2000-05-14T13:20:00-08:00' />
'<アクセス所有者=' fred@example.com '俳優=' *@* '動作=コア: データ'lastUpdate='2000-05-14T13: 20時0分から8時0分'/>。
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@example.com "のためのすべての操作へのアクセスは"example.com"管理ドメインの中の"fred"、"wilma"、およびすべてのAPEXサービスに許されています。
* "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」に許されていますが、"fred/ 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".
* アクセスは、データを送って、" fred@example.com "に関してAPEX存在サービスの「申し込んでください」と「腕時計」操作を呼び出すために"example.com"管理ドメインの中のいかなる他のアドレスにも許されています。
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サービスであるかどうかにかかわらず。
Rose, et. al. Standards Track [Page 13] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[13ページ]。
Note that although the four default entries are always available, the explicit entry for actor "*@*" overrides the corresponding default entry.
4つのデフォルトエントリーがいつも利用可能ですが、俳優" *@* "のための明白なエントリーが対応するデフォルトエントリーをくつがえすことに注意してください。
3.2 Creating and Updating Access Entries
3.2 アクセスエントリーを作成して、アップデートすること。
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.
アクセスエントリーへの俳優値は質問操作を実行するときだけ特別な意味を持っている限られたワイルドカードキャラクタを含むかもしれません。(Cf、セクション3.1) エントリーを検索して、アップデートする目的のために、俳優値は単に文字通りの名前として扱われます。
4. The Access Service
4. アクセス・サービス
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に相談してください。
Rose, et. al. Standards Track [Page 14] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[14ページ]。
4.1 Use of XML and MIME
4.1 XMLとMIMEの使用
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>
'<データ内容='…'><創始者のアイデンティティが' fred@example.com '/と等しい、gt;、<受取人のアイデンティティが'頂点= access@example.com '/と等しい、gt;、</データ>、'
where "..." refers to:
「どこ」… 」 言及します:
<query owner='fred@example.com' transID='1'
actor='barney@example.com'
actions='core:data presence:subscribe' />
<質問所有者=' fred@example.com 'transIDは'1つの'俳優=' 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
C: エムエスジー1 2.42 1234C: コンテントタイプ: 複合か関連する。 境界は「境界」と等しいです。 C: 「= "<1@example.com を始動してください、gt;、」、。 C: =「+ アプリケーション/ビープ音xml」Cをタイプしてください: C: --境界C: コンテントタイプ: アプリケーション/ビープ音+xml C: コンテントID: <1@example.com>C: C: <データ内容は'Cid: 2@example.com '>Cと等しいです:、' <創始者のアイデンティティが' fred@example.com '/と等しい、gt;、C: <受取人のアイデンティティが'頂点= access@example.com '/と等しい、gt;、C: </データ>C: --境界C: コンテントタイプ: アプリケーション/ビープ音+xml C: コンテントID: <2@example.com>C: C: <質問所有者=' fred@example.com 'transIDは'1'Cと等しいです: 俳優=' barney@example.com 'C: 動作は'コア: データ存在: 申し込んでください'/>Cと等しいです: --境界--、C: 終わり
Rose, et. al. Standards Track [Page 15] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[15ページ]。
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: エムエスジー1 1.42267C: コンテントタイプ: アプリケーション/ビープ音+xml C: C: '<データ内容は'#内容'>Cと等しいです' <創始者のアイデンティティが' fred@example.com '/と等しい、gt;、C: <受取人のアイデンティティが'頂点= access@example.com '/と等しい、gt;、C: <データ内容名前='内容'>C:、' <質問所有者=' fred@example.com 'transIDは'1'Cと等しいです: 俳優=' barney@example.com 'C: 動作は'コア: データ存在: 申し込んでください'/>Cと等しいです: </データ-内容>C: </データ>C: 終わり
4.2 The Query Operation
4.2 質問操作
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 「俳優」属性はアクセス許容が質問されるアドレス(wildcardingすることのない)を指定します。
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を持っている「回答」要素を創始者に送ります。
Rose, et. al. Standards Track [Page 16] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[16ページ]。
4. The subject's access entry matching the actor attribute of the
query element is selected (cf., Section 3.1).
4. 質問要素の俳優属性に合っている対象のアクセスエントリーが選択されます。(Cf、セクション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"属性は創始者によって送られた「質問」要素で見つけられた値と同じです。
4.3 The Get Operation
4.3、操作を得てください。
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:
「得てください」という要素には、"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 「俳優」属性はアクセス許容が検索されるアドレス(可能なwildcardingと)を指定します。 そして
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. 「俳優」属性が同様に「得てください」という要素の「俳優」属性に合っている対象のアクセスエントリーは選択されます。
Rose, et. al. Standards Track [Page 17] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[17ページ]。
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"属性は「得てください」という創始者によって送られた要素で見つけられた値と同じです。
4.4 The Set Operation
4.4 集合演算
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:
「アクセス」要素には、任意の"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 「俳優」属性はアクセス許容が指定されるアドレス(可能なwildcardingと)を指定します。
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"属性(エントリーを取り替えるか、または削除するためだけに現在の)は取り替えられることになっているアクセスエントリーの現在のタイムスタンプを指定します。
Rose, et. al. Standards Track [Page 18] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[18ページ]。
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. どんなそのようなエントリーも存在していなくて、"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を持っている「回答」要素を創始者に送ります。
Rose, et. al. Standards Track [Page 19] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[19ページ]。
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"属性は創始者によって送られた「セット」要素で見つけられた値と同じです。
4.5 The Reply Operation
4.5 回答操作
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に相談してください。
5. Registration: The Access Service
5. 登録: アクセス・サービス
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.、このメモの「作者のアドレス」セクション
Rose, et. al. Standards Track [Page 20] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[20ページ]。
6. The Access Service DTD
6. アクセス・サービスDTD
<!--
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;
-->
<!実体%APEXACCESS公共の「-//IETF//DTD頂点アクセス//アン」、「「>%APEXACCESS」 -->。
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" ""> %APEXCORE;
<!実体%APEXCORE公共の「-//IETF//DTD頂点コア//アン」、「「>%APEXCORE」
<!--
DTD data types:
<!--DTDデータ型:
entity syntax/reference example
====== ================ =======
access actor
ACTOR an ENDPOINT or a *@example.com
wildcard
実体構文/参照の例====== ================ ======= アクセス俳優ACTORはENDPOINTか *@example.com ワイルドカードです。
permitted actions
ACTIONS a list of access "core:any access:query"
tokens
-->
ACTIONS aが記載するアクセスの受入れられた動作が「: どんなアクセス: 質問の芯を取る」というトークン-->。
<!ENTITY % ACTOR "CDATA"> <!ENTITY % ACTIONS "NMTOKENS">
<!実体%俳優、「CDATA、「><!実体%動作、「NMTOKENS">"
<!--
Synopsis of the APEX access service
<!--APEXアクセス・サービスの構文
service WKE: apex=access
WKEを調整してください: 頂点=アクセス
message exchanges:
交換処理:
consumer initiates service replies
================== ================
query allow, deny, or reply
get set or reply
set reply
消費者開始は回答を修理します。================== ================ 質問が許容する、否定、回答が設定するようになったか、または回答は回答を設定しました。
service initiates consumer replies
================= ================
set (nothing)
サービスは消費者回答を開始します。================= ================ セットします。(何でもない)
Rose, et. al. Standards Track [Page 21] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[21ページ]。
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動作%ACTIONS。 #transID%UNIQIDが必要でした。 #必要な>。
<!ELEMENT get EMPTY>
<!ATTLIST get
owner %ENDPOINT; #REQUIRED
actor %ACTOR; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENTはEMPTY><を手に入れます!ATTLISTは所有者%ENDPOINTを手に入れます。 #REQUIRED俳優%ACTOR。 #transID%UNIQIDが必要でした。 #必要な>。
<!ELEMENT set (access)>
<!ATTLIST set
transID %UNIQID; #REQUIRED>
<!ELEMENTは(アクセス)><を設定します!ATTLISTはtransID%UNIQIDを設定します。 #必要な>。
<!ELEMENT allow EMPTY>
<!ATTLIST allow
transID %UNIQID; #REQUIRED>
<!ELEMENTはEMPTY><を許容します!ATTLISTはtransID%UNIQIDを許容します。 #必要な>。
<!ELEMENT deny EMPTY>
<!ATTLIST deny
transID %UNIQID; #REQUIRED>
<!ELEMENTはEMPTY><を否定します!ATTLISTはtransID%UNIQIDを否定します。 #必要な>。
<!--
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動作%ACTIONS。 #暗示しているlastUpdate%タイムスタンプ。 #暗示している>。
Rose, et. al. Standards Track [Page 22] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[22ページ]。
7. Security Considerations
7. セキュリティ問題
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: 0インチは使用(それに従って、現地時間を変換した後に)にされるかもしれない」。
References
参照
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", RFC 3340, July 2002.
[1] ローズとM.とKlyneとG.とD.クロッカー、「アプリケーション交換コア」、RFC3340、2002年7月。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[2] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
Rose, et. al. Standards Track [Page 23] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[23ページ]。
Authors' Addresses
作者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
Inc.POB255268サクラメント、カリフォルニア95865-5268米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 8878年の916 483メール: mrose@dbc.mtview.ca.us
Graham Klyne Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
グラハムKlyne Clearswift社1310の水辺アーリントンビジネスパークTheale、読書RG7 4SAイギリス
Phone: +44 11 8903 8903 EMail: Graham.Klyne@MIMEsweeper.com
以下に電話をしてください。 +44 11 8903 8903はメールされます: Graham.Klyne@MIMEsweeper.com
David H. Crocker Brandenburg Consulting 675 Spruce Drive Sunnyvale, CA 94086 US
デヴィッドH.医者ブランデンブルクのコンサルティング675は米国でDriveサニーベル、カリフォルニア 94086を小綺麗にします。
Phone: +1 408 246 8253 EMail: dcrocker@brandenburg.com URI: http://www.brandenburg.com/
以下に電話をしてください。 +1 8253年の408 246メール: dcrocker@brandenburg.com ユリ: http://www.brandenburg.com/
Rose, et. al. Standards Track [Page 24] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[24ページ]。
Appendix A. Acknowledgements
付録A.承認
The authors gratefully acknowledge the contributions of: Neil Cook, Darren New, Chris Newman, Scott Pead, and Bob Wyman.
作者は感謝して以下の貢献を承諾します。 ニール・クック、ダーレンNewのクリス・ニューマン、スコットPead、およびボブ・ワイマン。
Rose, et. al. Standards Track [Page 25] RFC 3341 The Application Exchange (APEX) Access Service July 2002
etローズ、アル。 規格はアプリケーション交換(頂点)アクセス・サービス2002年7月にRFC3341を追跡します[25ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rose, et. al. Standards Track [Page 26]
etローズ、アル。 標準化過程[26ページ]
一覧
スポンサーリンク
