📄 rfc3341.txt
字号:
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
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
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
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.
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 |
| |
+----------------------------------------------------------------+
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.
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
2. Use and Management of Access Information
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 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 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.
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 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.
Each is now described in turn.
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.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
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 />
The service immediately responds with either an allow or deny
operation containing the same transaction-identifier, where "allow"
means that all of the actions listed in the query are permitted,
e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<allow transID='1' />
</data-content>
</data>
S: <ok />
or
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<deny transID='1' />
</data-content>
</data>
S: <ok />
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.,
Rose, et. al. Standards Track [Page 4]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<get transID='2'
owner='fred@example.com'
actor='*@example.com' />
</data-content>
</data>
S: <ok />
The service immediately responds with a set operation containing the
access entry and the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<set transID='2'>
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
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.,
Rose, et. al. Standards Track [Page 5]
RFC 3341 The Application Exchange (APEX) Access Service July 2002
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<set transID='1'>
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe'
lastUpdate='2000-05-14T13:02:00-08:00' />
</set>
</data-content>
</data>
S: <ok />
Note that Step 4 of Section 4.4 requires that the "lastUpdate"
attribute of an access entry be supplied in order to update that
entry; accordingly, applications must successfully retrieve an access
entry prior to trying to modify that entry. (Naturally,
administrators should ensure that applications authorized to modify
an access entry are also authorized to retrieve that entry.)
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 />
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
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 />
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -