Network Working Group M. Rose
Internet-Draft Invisible Worlds, Inc.
Expires: December 26, 2001 G. Klyne
Baltimore Technologies
D. Crocker
Brandenburg Consulting
June 27, 2001
The APEX Access Service
draft-ietf-apex-access-05
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo describes the 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.
Rose, et. al. Expires December 26, 2001 [Page 1]
Internet-Draft The APEX Access Service June 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Management of Access Information . . . . . . . . . . . . . . . 4
2.1 Querying Access Information . . . . . . . . . . . . . . . . . 5
2.2 Retrieval of Access Information . . . . . . . . . . . . . . . 7
2.3 Update of Access Information . . . . . . . . . . . . . . . . . 8
3. Format of Access Entries . . . . . . . . . . . . . . . . . . . 12
3.1 Finding the Appropriate Entry: Matching Owners and Actors . . 14
4. The Access Service . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 17
4.2 The Query Operation . . . . . . . . . . . . . . . . . . . . . 19
4.3 The Get Operation . . . . . . . . . . . . . . . . . . . . . . 20
4.4 The Set Operation . . . . . . . . . . . . . . . . . . . . . . 21
4.5 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 24
5. Registration: The Access Service . . . . . . . . . . . . . . . 25
6. The Access Service DTD . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 32
B.1 Changes from draft-ietf-apex-access-04 . . . . . . . . . . . . 32
B.2 Changes from draft-ietf-apex-access-03 . . . . . . . . . . . . 32
B.3 Changes from draft-ietf-apex-access-02 . . . . . . . . . . . . 32
B.4 Changes from draft-ietf-apex-access-01 . . . . . . . . . . . . 32
B.5 Changes from draft-ietf-apex-access-00 . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
Rose, et. al. Expires December 26, 2001 [Page 2]
Internet-Draft The APEX Access Service June 2001
1. Introduction
This memo describes a 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. Expires December 26, 2001 [Page 3]
Internet-Draft The APEX Access Service June 2001
2. 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.
Rose, et. al. Expires December 26, 2001 [Page 4]
Internet-Draft The APEX Access Service June 2001
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 -- | |
+-------+ +-------+
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 />
Rose, et. al. Expires December 26, 2001 [Page 5]
Internet-Draft The APEX Access Service June 2001
The service immediately responds with either an allow or deny
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='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 />
Rose, et. al. Expires December 26, 2001 [Page 6]
Internet-Draft The APEX Access Service June 2001
2.2 Retrieval of Access Information
When an application wants to retrieve the access entry associated
with an owner/actor combination, it sends a "get" element to the
service, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=access@example.com' />
<data-content Name='Content'>
<get transID='2'
owner='fred@example.com'
actor='*@example.com' />
</data-content>
</data>
S: <ok />
The service immediately responds with a set operation containing the
access entry and the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=access@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<set transID='2'>
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe'
lastUpdate='14 May 2000 13:02:00 -0800' />
</set>
</data-content>
</data>
S: <ok />
Rose, et. al. Expires December 26, 2001 [Page 7]
Internet-Draft The APEX Access Service June 2001
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.,
+-------+ +-------+
| | -- 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='14 May 2000 13:02:00 -0800' />
</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.
Rose, et. al. Expires December 26, 2001 [Page 8]
Internet-Draft The APEX Access Service June 2001
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.
The service also immediately sends a set operation to the address
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='14 May 2000 23:02:00 -0800' />
</set>
</data-content>
</data>
S: <ok />
Rose, et. al. Expires December 26, 2001 [Page 9]
Internet-Draft The APEX Access Service June 2001
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='14 May 2000 13:02:00 -0800' />
</set>
</data-content>
</data>
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 />
Rose, et. al. Expires December 26, 2001 [Page 10]
Internet-Draft The APEX Access Service June 2001
The service also immediately sends a set operation to the address
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='14 May 2000 13:02:00 -0800' />
</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.
Rose, et. al. Expires December 26, 2001 [Page 11]
Internet-Draft The APEX Access Service June 2001
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).
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 "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 "lastUpdate" attribute specifies the date and time that the
service last created or modified the access entry.
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 values are reserved:
o "all" is used to refer to all services and/or operations, e.g.,
"all:data", "presence:all"; 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]).
Rose, et. al. Expires December 26, 2001 [Page 12]
Internet-Draft The APEX Access Service June 2001
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:
* a literal string (e.g., "fred"); or,
* the value "apex=*", specifying all APEX services; or,
* the value "*", specifying any address other than an APEX
service.
o The "domain" part is either:
* a FQDN (e.g., "example.com"); or,
* the value "*", specifying all administrative domains.
In the absence of specific access entries to the contrary, the
following default actor/action permissions are applied for each
owner:
actor='local@domain' actions='all:all'
actor='apex=*@domain' actions='all:all'
actor='apex=*@*' actions='core:data'
actor='*@*' actions=''
where "local@domain" specifies the owner associated with the access
entry.
Rose, et. al. Expires December 26, 2001 [Page 13]
Internet-Draft The APEX Access Service June 2001
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, the following selection
priorities, from highest to lowest, are applied in this order:
1. An exact match (e.g., "fred@example.com")
2. Any service in the specified domain (e.g., "apex=*@example.com")
3. Any local-part in the specified domain (e.g., "*@example.com")
4. The specified local-part in any domain (e.g., "fred@*" or
"apex=presence@*")
5. Any service in any domain (i.e., "apex=*@*")
6. Any local-part in any domain (i.e., "*@*")
For example, consider these access entries:
<access owner='fred@example.com'
actor='wilma@example.com'
actions='all:all'
lastUpdate='14 May 2000 13:20:00 -0800' />
<access owner='fred@example.com'
actor='mr.slate@example.com'
actions='core:data'
lastUpdate='14 May 2000 13:20:00 -0800' />
<access owner='fred/appl=wb@example.com'
actor='barney/appl=wb@example.com'
actions='core:data'
lastUpdate='14 May 2000 13:20:00 -0800' />
<access owner='fred@example.com'
actor='*@example.com'
actions='core:data presence:subscribe presence:watch'
lastUpdate='14 May 2000 13:20:00 -0800' />
<access owner='fred@example.com'
actor='*@*'
actions='core:data'
lastUpdate='14 May 2000 13:20:00 -0800' />
Rose, et. al. Expires December 26, 2001 [Page 14]
Internet-Draft The APEX Access Service June 2001
Briefly:
o For addresses within the "example.com" administrative domain:
* "fred", "wilma", and all APEX services within the "example.com"
administrative domain are allowed access to all operations for
"fred@example.com";
* "mr.slate" is allowed access only to send data through the
relaying mesh to "fred@example.com";
* "barney/appl=wb" is allowed access only to send data to
"fred/appl=wb", a subaddress of "fred@example.com"; and,
* 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".
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.
Note that although the four default entries are always available, the
explicit entry for actor "*@*" overrides the corresponding default
entry.
Rose, et. al. Expires December 26, 2001 [Page 15]
Internet-Draft The APEX Access Service June 2001
4. The Access Service
Section 5 contains the APEX service registration for the access
service:
o Within an administrative domain, the service is addressed using
the well-known endpoint of "apex=access".
o Section 6 defines the syntax of the operations exchanged with the
service.
o A consumer of the service initiates communications by sending data
containing a query, get, or set operation.
o The service replies to these operations.
o When an access entry is changed, the service sends a notification
to the owner associated with the changed entry.
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.
Rose, et. al. Expires December 26, 2001 [Page 16]
Internet-Draft The APEX Access Service June 2001
4.1 Use of XML and MIME
Section 4.1 of [1] describes how arbitrary MIME content is exchanged
as a BEEP [2] payload. For example, to transmit:
<data content='...'>
<originator identity='fred@example.com' />
<recipient identity='apex=access@example.com' />
</data>
where "..." refers to:
<query owner='fred@example.com' transID='1'
actor='barney@example.com'
actions='core:data presence:subscribe' />
then the corresponding BEEP message might look like this:
C: MSG 1 2 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C: start="<1@example.com>";
C: type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C: <originator identity='fred@example.com' />
C: <recipient identity='apex=access@example.com' />
C: </data>
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <2@example.com>
C:
C: <query owner='fred@example.com' transID='1'
C: actor='barney@example.com'
C: actions='core:data presence:subscribe' />
C: --boundary--
C: END
Rose, et. al. Expires December 26, 2001 [Page 17]
Internet-Draft The APEX Access Service June 2001
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
Rose, et. al. Expires December 26, 2001 [Page 18]
Internet-Draft The APEX Access Service June 2001
4.2 The Query Operation
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:
o the "owner" attribute specifies the address associated with the
access entry;
o the "actor" attribute specifies the address (without wildcarding)
for which access permissions are queried;
o the "actions" attribute specifies one or more actions for which
permission is queried; and,
o the "transID" attribute specifies the transaction-identifier
associated with this operation.
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.
2. If the subject does not refer to a valid address, a "reply"
element having code 550 is sent to the originator.
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.
4. The subject's access entry matching the actor attribute of the
query element is selected.
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.
6. Otherwise, a "deny" element is sent to the originator.
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.
Rose, et. al. Expires December 26, 2001 [Page 19]
Internet-Draft The APEX Access Service June 2001
4.3 The Get Operation
When an application wants to retrieve the access entry associated
with an owner/actor combination, it sends a "get" element to the
service.
The "get" element has an "owner" attribute, an "actor" attribute, a
"transID" attribute, and no content:
o the "owner" attribute specifies the address associated with the
access entry;
o the "actor" attribute specifies the address (with possible
wilcarding) for which access permissions are retrieved; and,
o the "transID" attribute specifies the transaction-identifier
associated with this operation.
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.
2. If the subject does not refer to a valid address, a "reply"
element having code 550 is sent to the originator.
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.
4. The subject's access entry whose "actor" attribute identically
matches the "actor" attribute of the "get" element is selected.
5. If no such entry exists, a "reply" element having code 550 is
sent to the originator.
6. Otherwise, a "set" element corresponding to the selected access
entry is sent to the originator.
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.
Rose, et. al. Expires December 26, 2001 [Page 20]
Internet-Draft The APEX Access Service June 2001
4.4 The Set Operation
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:
o the "transID" attribute specifies the transaction-identifier
associated with this operation; and,
o the "access" element contains the access entry to be created,
replaced, or deleted.
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 the "actor" attribute specifies the address (with possible
wilcarding) for which access permissions are specified;
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 the "lastUpdate" attribute (presently only to replace an entry)
specifies the current timestamp of the access entry that is to be
replaced.
Rose, et. al. Expires December 26, 2001 [Page 21]
Internet-Draft The APEX Access Service June 2001
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.
2. If the subject does not refer to a valid address, a "reply"
element having code 550 is sent to the originator.
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.
4. The subject's access entry whose "actor" attribute identically
matches the "actor" attribute of the "set" element is selected.
5. If no such entry exists and the "lastUpdate" attribute of the
supplied element is present, a "reply" element having code 555 is
sent to the originator.
6. If no such entry exists, then:
1. The access entry for the owner/actor combination is created
from the supplied "access" element.
2. The "lastUpdate" attribute of that access entry set to the
service's notion of the current date and time.
3. A "reply" element having code 250 is sent to the originator.
4. A "set" element corresponding to the newly-created access
entry is sent to the subject's address.
7. If the selected entry's "lastUpdate" attribute is not identical
to the "lastUpdate" attribute of the supplied "access" element, a
"reply" element having code 555 is sent to the originator.
8. If "actions" attribute of the supplied "access" element is empty,
then:
1. The selected entry is deleted.
2. A "reply" element having code 250 is sent to the originator.
3. A "set" element corresponding to the owner/actor combination,
but containing an empty "actions" attribute is sent to the
subject's address.
Rose, et. al. Expires December 26, 2001 [Page 22]
Internet-Draft The APEX Access Service June 2001
9. Otherwise:
1. The access entry for the owner/actor combination is updated
from the supplied "access" element.
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).
3. A "reply" element having code 250 is sent to the originator.
4. A "set" element corresponding to the newly-updated access
entry is sent to the subject's address.
When sending the "reply" element, the "transID" attribute is
identical to the value found in the "set" element sent by the
originator.
Rose, et. al. Expires December 26, 2001 [Page 23]
Internet-Draft The APEX Access Service June 2001
4.5 The Reply Operation
While processing operations, the service may respond with a "reply"
element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for
the syntax and semantics of the reply operation.
Rose, et. al. Expires December 26, 2001 [Page 24]
Internet-Draft The APEX Access Service June 2001
5. Registration: The Access Service
Well-Known Endpoint: apex=access
Syntax of Messages Exchanged: c.f., Section 6
Sequence of Messages Exchanged: c.f., Section 4
Access Control Tokens: access:query, access:get, access:set
Contact Information: c.f., the "Authors' Addresses" section of this
memo
Rose, et. al. Expires December 26, 2001 [Page 25]
Internet-Draft The APEX Access Service June 2001
6. The Access Service DTD
<!--
DTD for the APEX access service, as of 2001-06-19
Refer to this DTD as:
<!ENTITY % APEXACCESS PUBLIC "-//IETF//DTD APEX ACCESS//EN"
"http://xml.resource.org/profiles/APEX/apex-access.dtd">
%APEXACCESS;
-->
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN"
"http://xml.resource.org/profiles/APEX/apex-core.dtd">
%APEXCORE;
<!--
DTD data types:
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">
Rose, et. al. Expires December 26, 2001 [Page 26]
Internet-Draft The APEX Access Service June 2001
<!--
Synopsis of the APEX access service
service WKE: apex=access
message exchanges:
consumer initiates service replies
================== ================
query allow, deny, or reply
get set or reply
set reply
service initiates consumer replies
================= ================
set (nothing)
access control:
token target
========== ======
access:query for "owner" of "access" element
access:get for "owner" of "access" element
access:set for "owner" of "access" element
-->
<!ELEMENT query EMPTY>
<!ATTLIST query
owner %ENDPOINT; #REQUIRED
actor %ACTOR; #REQUIRED
actions %ACTIONS; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT get EMPTY>
<!ATTLIST get
owner %ENDPOINT; #REQUIRED
actor %ACTOR; #REQUIRED
transID %UNIQID; #REQUIRED>
<!ELEMENT set (access)>
<!ATTLIST set
transID %UNIQID; #REQUIRED>
Rose, et. al. Expires December 26, 2001 [Page 27]
Internet-Draft The APEX Access Service June 2001
<!ELEMENT allow EMPTY>
<!ATTLIST allow
transID %UNIQID; #REQUIRED>
<!ELEMENT deny EMPTY>
<!ATTLIST deny
transID %UNIQID; #REQUIRED>
<!--
access entries
-->
<!ELEMENT access EMPTY>
<!ATTLIST access
owner %ENDPOINT; #REQUIRED
actor %ACTOR; #REQUIRED
actions %ACTIONS; #IMPLIED
lastUpdate %TIMESTAMP; #IMPLIED>
Rose, et. al. Expires December 26, 2001 [Page 28]
Internet-Draft The APEX Access Service June 2001
7. Security Considerations
Consult [1]'s Section 11 for a discussion of security issues.
Rose, et. al. Expires December 26, 2001 [Page 29]
Internet-Draft The APEX Access Service June 2001
References
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", draft-ietf-apex-core-03 (work in progress), June 2001.
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
Authors' Addresses
Marshall T. Rose
Invisible Worlds, Inc.
131 Stony Circle
Suite 500
Santa Rosa, CA 95401
US
Phone: +1 707 578 2350
EMail: mrose@invisible.net
URI: http://invisible.net/
Graham Klyne
Baltimore Technologies
1310 Waterside
Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 118 903 8000
EMail: gk@acm.org
David H. Crocker
Brandenburg Consulting
675 Spruce Drive
Sunnyvale, CA 94086
US
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/
Rose, et. al. Expires December 26, 2001 [Page 30]
Internet-Draft The APEX Access Service June 2001
Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of: Neil Cook,
Darren New, Chris Newman, and Scott Pead.
Rose, et. al. Expires December 26, 2001 [Page 31]
Internet-Draft The APEX Access Service June 2001
Appendix B. Revision History
B.1 Changes from draft-ietf-apex-access-04
o Re-organization previous version for consistency.
B.2 Changes from draft-ietf-apex-access-03
o Change access service to use an owner/actor combination as the
fundamental unit of access information.
o Separate access query function from access information management
functions.
o Remove redundant "owner" attribute from "set" element.
o Merge "access" and "entry" elements into just "access". Multiple
"access" elements are now needed for a single subject.
o Change framework for applying defaults: default entries are
applied in the absence of any overriding access entry.
o Add some introductory text about the relationship between access
permision owners and APEX operations.
B.3 Changes from draft-ietf-apex-access-02
o A small number of typos were corrected.
B.4 Changes from draft-ietf-apex-access-01
o It is made more clear that each subaddress has its own access
entry.
o A successful set operation results in the new access entry being
sent to the endpoint associated with the entry.
o A small number of typos were corrected.
B.5 Changes from draft-ietf-apex-access-00
o Change "addr-spec" syntax from RFC 822 to APEX's custom ABNF.
Rose, et. al. Expires December 26, 2001 [Page 32]
Internet-Draft The APEX Access Service June 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
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.
Rose, et. al. Expires December 26, 2001 [Page 33]
