Network Working Group M. Rose
Internet-Draft Invisible Worlds, Inc.
Expires: October 30, 2001 G. Klyne
Baltimore Technologies
D. Crocker
Brandenburg Consulting
May 2001
The APEX Access Service
draft-ietf-apex-access-04.txt
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 October 30, 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 October 30, 2001 [Page 1]
Internet-Draft The APEX Access Service May 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Access Information Entries . . . . . . . . . . . . . . . . . . 3
1.2 Access Information Services . . . . . . . . . . . . . . . . . 4
2. Querying Access Information . . . . . . . . . . . . . . . . . 6
3. Management of Access Information . . . . . . . . . . . . . . . 8
3.1 Retrieval of Access Information . . . . . . . . . . . . . . . 9
3.2 Update of Access Information . . . . . . . . . . . . . . . . . 10
4. Format of Access Entries . . . . . . . . . . . . . . . . . . . 13
5. The Access Service . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 17
5.2 The Query Operation . . . . . . . . . . . . . . . . . . . . . 19
5.3 The Get Operation . . . . . . . . . . . . . . . . . . . . . . 21
5.4 The Set Operation . . . . . . . . . . . . . . . . . . . . . . 22
5.5 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 24
6. Registration: The Access Service . . . . . . . . . . . . . . . 25
7. The Access Service DTD . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
B. Amendment history . . . . . . . . . . . . . . . . . . . . . . 32
B.1 Changes from draft-ietf-apex-access-03 . . . . . . . . . . . . 32
B.2 Changes from draft-ietf-apex-access-02 . . . . . . . . . . . . 32
B.3 Changes from draft-ietf-apex-access-01 . . . . . . . . . . . . 32
B.4 Changes from draft-ietf-apex-access-00 . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
Rose, et. al. Expires October 30, 2001 [Page 2]
Internet-Draft The APEX Access Service May 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]).
1.1 Access Information Entries
Access information is organized around access entries, each of which
is contains:
o an owner: an APEX endpoint with which the entry is associated.
Rose, et. al. Expires October 30, 2001 [Page 3]
Internet-Draft The APEX Access Service May 2001
The destination endpoint of an APEX operation determines the owner
of the access entry used to determine permission to perform the
operation.
o an actor: an APEX endpoint that is granted permission to perform
some operation.
o a list of actions: a list of operations that are permitted for
the designated actor to perform with the owner endpoint.
Each access entry is associated with an owner, which is some entity
that determines access to some facilities accessed by APEX
operations. An access permission owner is identified by an APEX
endpoint address.
The precise relationship between an APEX operation and the owner who
determines access permissions is dependent on the particular
operation being performed. For example:
o when sending data to an APEX endpoint, it is the endpoint to which
the data is addressed who determines the access permissions for
the operation;
o when retrieving access information, the request is sent to
"apex=access@domain.com", but it is the owner named in the request
that determines whether the operation is permitted;
o when requesting presence information, it is the subject of
presence information that determines whether or not the requested
operation will be honoured.
Thus, the content of a request must be understood in order for access
permissions to be determined. This means that APEX services
themselves must operate as access policy enforcement points,
extracting relevant information from a request and passing it to the
access service which operates as an access policy decision point.
The access entry for a single owner may control access to a range of
different APEX services that are performed on its behalf; e.g. data
delivery, access control, presence. Note that there is no defined
way to specify permission for message relaying, which is a matter for
local provisioning within an administrative domain.
1.2 Access Information Services
The access service supports two kinds of activity:
o access query, used by an access policy enforcement point to
Rose, et. al. Expires October 30, 2001 [Page 4]
Internet-Draft The APEX Access Service May 2001
discover whether or not a requested operation is permitted, and
o access information management, used by administration clients that
need a standard way to retrieve and update specific access
entries.
Rose, et. al. Expires October 30, 2001 [Page 5]
Internet-Draft The APEX Access Service May 2001
2. Querying Access Information
When an application wants to discover about access associated with an
endpoint, it sends a "query" element to the service, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C:
S:
No wildcarding is allowed for the owner, actor or actions list in a
operation.
The service immediately responds with an allow or deny operation
indicating whether the indicated access is allowed for the designated
actor, and the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C:
S:
Rose, et. al. Expires October 30, 2001 [Page 6]
Internet-Draft The APEX Access Service May 2001
or
C:
S:
The response indicates that all of the requested actions are
permitted for the designated actor.
Note that access entries held by the access service may include
limited wildcard values for the actor value. In determing the
response to a query, the access service selects a single access entry
that exactly matches the supplied owner, and that matches the
supplied actor using the following selection priorities:
1. exact match (bill@example.com)
2. any service in specified domain (apex=*@example.com)
3. any endpoint in specified domain (*@example.com)
4. specified endpoint in any domain (bill@* or apex=presence@*)
5. any service in any domain (apex=*@*)
6. any endpoint in any domain (*@*)
Rose, et. al. Expires October 30, 2001 [Page 7]
Internet-Draft The APEX Access Service May 2001
3. Management of Access Information
Management of access information falls into two categories:
o applications may retrieve the access entry associated with an
owner/actor endpoint combination; and,
o applications may update (i.e. replace or delete) the access entry
associated with an owner/actor endpoint combination.
Note that for the purpose of retrieving and updating access entries,
no special wildcard processing is performed. The actor value for an
entry may contain limited wildcard characters which have special
significance only when performing a query operation (see Section 2).
For the purposes of retrieving and updating entries, actor values are
treated simply as literal names.
Rose, et. al. Expires October 30, 2001 [Page 8]
Internet-Draft The APEX Access Service May 2001
3.1 Retrieval of Access Information
When an application wants to retrieve the access entry associated
with an owner/actor endpoint combination, it sends a "get" element to
the service, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C:
S:
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:
S:
Rose, et. al. Expires October 30, 2001 [Page 9]
Internet-Draft The APEX Access Service May 2001
3.2 Update of Access Information
When an application wants to add or modify an access entry associated
with an owner/actor endpoint combination, it sends a "set" element to
the service containing the new access entry, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C:
S:
The service immediately responds with a reply operation containing
the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C:
S:
Note that Step 5 of Section 5.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
Rose, et. al. Expires October 30, 2001 [Page 10]
Internet-Draft The APEX Access Service May 2001
entry prior to trying to update that entry.
The service also immediately sends a set operation to the endpoint
associated with the access entry, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | |access |
| | -- ok ---------> | svc. |
+-------+ +-------+
C:
S:
Note that Step 6.2 of Section 5.4 requires that the access service
update the "lastUpdate" attribute of an access entry when it is
updated.
Rose, et. al. Expires October 30, 2001 [Page 11]
Internet-Draft The APEX Access Service May 2001
When an application wants to remove the access entry associated with
an owner/actor endpoint combination, it sends a "set" element to the
service specifying no value for the permitted actions, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C:
S:
The response to this is as described above for modifying an access
entry, except that the notification sent to the associated owner
endpoint does not contain a list of actions.
Rose, et. al. Expires October 30, 2001 [Page 12]
Internet-Draft The APEX Access Service May 2001
4. Format of Access Entries
Each administrative domain is responsible for maintaining a list of
"access entries" for each of its endpoints and every subaddress
(regardless of whether those endpoints 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 7 defines the syntax for access entries. Each access entry
has the following attributes:
o the "owner" attribute specifies the address (endpoint or
subaddress) associated with the access entry;
o the "actor" attribute designates an entity or group of entitites
for whom access permissions are specified, as described below;
o the "actions" attribute specifies permissions as service/operation
pairs, (e.g., "presence:publish" refers to the "publish" operation
of the "presence" service). To refer to all services and/or all
operations, the reserved value "all" is used (e.g., "all:data",
"presence:all", and so on). Note that the service specified as
"core" is reserved for use 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 the "lastUpdate" attribute specifies the date and time that the
service last updated the access entry; and,
An actor is an APEX endpoint 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 endpoint other than an APEX
service.
o The "domain" part is either:
* a FQDN (e.g., "example.com"); or,
* the value "*", specifying all administrative domains.
Rose, et. al. Expires October 30, 2001 [Page 13]
Internet-Draft The APEX Access Service May 2001
In the absence of specific access entries to the contrary, the
following default actor/action permissions are applied for each
endpoint:
actor='local@domain' actions='all:all'
actor='apex=*@domain' actions='all:all'
actor='apex=*@*' actions='core:data'
actor='*@*' actions=''
where "local@domain" specifies the endpoint associated with the
access entry.
Because of wildcarding in actor names, several access entries may be
applicable for any given combination of endpoint and actor. When
deciding the access entry to be used for determining permission for a
request from an actor, more exact matches are preferred over looser
matches; for details, see Section 2.
For example, consider the following access entries:
owner='fred@example.com'
.. actor='wilma@example.com'
actions='all:all'
.. actor='mr.slate@example.com'
actions='core:data'
.. actor='*@example.com'
actions='core:data presence:subscribe presence:watch'
.. actor='*@*'
actions='core:data'
Briefly:
o For endpoints 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; and,
* any other endpoint 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 endpoint outside the "example.com" administrative domain,
the endpoint is allowed access to send data, regardless of whether
Rose, et. al. Expires October 30, 2001 [Page 14]
Internet-Draft The APEX Access Service May 2001
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.
As a second example, consider this access entry:
This access entry, for a subaddress of "fred@example.com", allows
only "barney/appl=wb@example.com" (the actor) to send data through
the relaying mesh (the "core:data' action) to
"fred/appl=wb@example.com" (the owner).
Rose, et. al. Expires October 30, 2001 [Page 15]
Internet-Draft The APEX Access Service May 2001
5. The Access Service
Section 6 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 7 defines the syntax of the operations exchanged with the
service.
o A consumer of the service initiates communications by sending data
containing a query operation.
o An admninistrator of the service initiates communications by
sending data containing either the get or set operation.
o The service replies to these operations, and does not initiate
communications.
o When an access entry is changed, the service sends a notification
to the owner endpoint 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 October 30, 2001 [Page 16]
Internet-Draft The APEX Access Service May 2001
5.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:
where "..." refers to:
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:
C:
C:
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <2@example.com>
C:
C:
C: --boundary--
C: END
Rose, et. al. Expires October 30, 2001 [Page 17]
Internet-Draft The APEX Access Service May 2001
or this:
C: MSG 1 1 . 42 267
C: Content-Type: application/beep+xml
C:
C:
C:
C:
C:
C:
C:
C:
C: END
Rose, et. al. Expires October 30, 2001 [Page 18]
Internet-Draft The APEX Access Service May 2001
5.2 The Query Operation
When an application wants to discover about access permissions
associated with an endpoint address, it sends a "query" element to
the service.
The "query" element has "owner", "actor", "actions" and "transID"
attributes, and no content:
o the "owner" attribute specifies the owner endpoint address
associated with the access entry;
o the "actor" attribute specifies the endpoint address for which
access permissions are to be queried;
o the "actions" attribute specifies one or more actions for which
permission is to be determined; 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 of that 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 endpoint, a "reply"
element having code 550 is sent to the originator.
3. If the subject's access entry matching the originator address
(see Section 2) does not contain an "access:query" token, or
corresponding permission, a "reply" element having code 537 is
sent to the originator.
4. Otherwise, the subject's access entry matching the actor
attribute of the query element is selected (see Section 2) and
compared with the actions attribute from the query element:
* if all of the permissions in the query element are contained
in the access entry then an "allow" element is sent to the
originator.
* if any of the requested permissions is not present in the
access entry, a "deny" element is sent to the originator.
Regardless of whether an "allow", "deny" or "reply" element is sent
Rose, et. al. Expires October 30, 2001 [Page 19]
Internet-Draft The APEX Access Service May 2001
to the originator, the "transID" attribute is identical to the value
found in the "query" element sent by the originator.
Rose, et. al. Expires October 30, 2001 [Page 20]
Internet-Draft The APEX Access Service May 2001
5.3 The Get Operation
When an application wants to retrieve the access entry associated
with an owner/actor endpoint combination, it sends a "get" element to
the service.
The "get" element has an "owner", "actor" and "transID" attributes,
and no content:
o the "owner" attribute specifies the address associated with the
access entry;
o the "actor" attribute specifies the address (with possible limited
wilcarding) of an endpoint 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 endpoint, a "reply"
element having code 550 is sent to the originator.
3. If the subject's access entry for the originator does not contain
a "access:get" token or equivalent permission, a "reply" element
having code 537 is sent to the originator.
4. If the subject has an access entry for the specified actor a
"set" element corresponding to that entry is sent to the
originator.
5. Otherwise, a "set" element containing the supplied "owner" and
"actor" attributes, but containing no "actions" or "lastUpdate"
attributes, 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 October 30, 2001 [Page 21]
Internet-Draft The APEX Access Service May 2001
5.4 The Set Operation
When an application wants to modify (i.e. remove or replace) the
access entry associated with an owner/actor endpoint combination, it
sends a "set" element to the service.
The "set" element has a "transID" attribute, a "timeStamp" attribute,
and contains an "access" element:
o the "transID" attribute specifies the transaction-identifier
associated with this operation;
o the "timeStamp" attribute specifies the application's notion of
the current date and time; and,
o the "access" element contains the access entry to be added,
replaced or removed.
The "access" element has "owner", "actor", optional "actions" and
optional "lastUpdate" attributes, and no content:
o the "owner" attribute specifies the owner endpoint address
associated with the access entry;
o the "actor" attribute specifies the endpoint address (with
possible limited wilcarding) for which access permissions are
specified;
o the "actions" attribute specifies one or more actions for which
permission is to be determined. This attribute is present to add
or replace an access entry, or omitted to remove an existing
entry; and
o the "lastUpdate" attribute, if present, specifies the timestamp of
a current access entry that is to be replaced.
Rose, et. al. Expires October 30, 2001 [Page 22]
Internet-Draft The APEX Access Service May 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 endpoint, a "reply"
element having code 550 is sent to the originator.
3. If the subject's access entry for the originator endpoint does
not contain an "access:set" token or equivalent permission, a
"reply" element having code 537 is sent to the originator.
4. If there exists an access entry for the specified owner/actor
combination, and the "lastUpdate" attribute of the supplied
"access" element is not present or not identical to the
"lastUpdate" attribute of the existing entry, a "reply" element
having code 555 is sent to the originator. (This allows for a
get-modify-set sequence to perform atomic updates.)
5. If there exists no access entry for the specified owner/actor
combination, and the "lastUpdate" attribute is present in the
supplied "access" element, a "reply" element having code 555 is
sent to the originator.
6. If the supplied "access" element contains no "actions" attribute
then any existing access entry held by the service is deleted,
7. Otherwise:
1. The access entry for the indicated 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 new access entry is sent
to the subject endpoint.
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 October 30, 2001 [Page 23]
Internet-Draft The APEX Access Service May 2001
5.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 October 30, 2001 [Page 24]
Internet-Draft The APEX Access Service May 2001
6. Registration: The Access Service
Well-Known Endpoint: apex=access
Syntax of Messages Exchanged: c.f., Section 7
Sequence of Messages Exchanged: c.f., Section 5
Access Control Tokens: access:query, access:get, access:set
Contact Information: c.f., the "Authors' Addresses" section of this
memo
Rose, et. al. Expires October 30, 2001 [Page 25]
Internet-Draft The APEX Access Service May 2001
7. The Access Service DTD
%APEXCORE;
Rose, et. al. Expires October 30, 2001 [Page 28]
Internet-Draft The APEX Access Service May 2001
8. Security Considerations
Consult [1]'s Section 11 for a discussion of security issues.
Rose, et. al. Expires October 30, 2001 [Page 29]
Internet-Draft The APEX Access Service May 2001
References
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", draft-ietf-apex-core-02 (work in progress), May 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 October 30, 2001 [Page 30]
Internet-Draft The APEX Access Service May 2001
Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of: Neil Cook,
Darren New, Chris Newman, and Scott Pead.
Rose, et. al. Expires October 30, 2001 [Page 31]
Internet-Draft The APEX Access Service May 2001
Appendix B. Amendment history
B.1 Changes from draft-ietf-apex-access-03
o Change access service to use an owner/actor entry as its
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.2 Changes from draft-ietf-apex-access-02
o A small number of typos were corrected.
B.3 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.4 Changes from draft-ietf-apex-access-00
o Change "addr-spec" syntax from RFC 822 to APEX's custom ABNF.
Rose, et. al. Expires October 30, 2001 [Page 32]
Internet-Draft The APEX Access Service May 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 October 30, 2001 [Page 33]