RFC 
 3341 
 TOC 
Network Working GroupM. Rose
Request for Comments: 3341Dover Beach Consulting, Inc.
Category: Standards TrackG. 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 © 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.


 RFC 
 3341 
 TOC 

Table of Contents

1.  Introduction
2.  Use and Management of Access Information
    2.1.  Querying Access Information
    2.2.  Retrieval of Access Information
    2.3.  Update of Access Information
3.  Format of Access Entries
    3.1.  Finding the Appropriate Entry: Matching Owners and Actors
    3.2.  Creating and Updating Access Entries
4.  The Access Service
    4.1.  Use of XML and MIME
    4.2.  The Query Operation
    4.3.  The Get Operation
    4.4.  The Set Operation
    4.5.  The Reply Operation
5.  Registration: The Access Service
6.  The Access Service DTD
7.  Security Considerations
8.  References
Appendix A.  Acknowledgements
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

This memo describes an access service that is built upon the APEX (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.) [RFC3340] "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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)).



 TOC 

2.  Use and Management of Access Information

Access information is organized around access entries, each of which contains:

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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.) discusses APEX access policies that govern such activities as peer authentication, message relaying, and so on.

Management of access information falls into three categories:

Each is now described in turn.



 TOC 

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 />

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 />


 TOC 

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.,

    +-------+                  +-------+
    |       | -- 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 />


 TOC 

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='2000-05-14T13:02:00-08:00' />
             </set>
         </data-content>
     </data>
  S: <ok />

Note that Step 4 of Section 4.4 (The Set Operation) 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 (The Set Operation) 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 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 />

When an application wants to delete the access entry associated with an owner/actor combination, it sends a "set" element to the service omitting the permitted actions, e.g.,

    +-------+                  +-------+
    |       | -- data -------> |       |
    | appl. |                  | relay |
    |       | <--------- ok -- |       |
    +-------+                  +-------+

  C: <data content='#Content'>
         <originator identity='wilma@example.com' />
         <recipient identity='apex=access@example.com' />
         <data-content Name='Content'>
             <set transID='2'>
                 <access owner='fred@example.com'
                         actor='*@example.com'
                         lastUpdate='2000-05-14T13:02:00-08:00' />
             </set>
         </data-content>
     </data>
  S: <ok />

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 />

The service also immediately sends a set operation to the owner attribute associated with the access entry, e.g.,

                               +-------+                  +-------+
                               |       | <------- data -- |       |
                               | relay |                  |access |
                               |       | -- ok ---------> |  svc. |
                               +-------+                  +-------+

  C: <data content='#Content'>
         <originator identity='apex=access@example.com' />
         <recipient identity='fred@example.com' />
         <data-content Name='Content'>
             <set transID='2'>
                 <access owner='fred@example.com'
                         actor='*@example.com'
                         lastUpdate='2000-05-14T13:02:00-08:00' />
             </set>
         </data-content>
     </data>
  S: <ok />

Because there are no actions associated with this access entry, the owner knows that the entry has been deleted.

Note that because access control supported limited wildcarding of actors, deleting an access entry for a particular owner/actor combination, may modify, rather than remove, permission. Because of this, a special action, "all:none", is used.

For example, consider these two access entries:

    <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' />

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:

    <access owner='fred@example.com'
            actor='barney@example.com'
            actions='all:none'
            lastUpdate='2000-05-14T13:20:00-08:00' />


 TOC 

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 (The Access Service DTD) 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:

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:

Further, two operation values are reserved:

An actor is an APEX address and is specified using the "entity" syntax specified in Section 2.2 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.). However, both the "local" and "domain" parts may contain limited wildcarding:

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'

where "local@domain" specifies the owner associated with the access entry.

For example, the explicit entry

    actor='*@*'           actions='core:data'

allows endpoints from any domain to use the relaying mesh to send data to the owner, but does not override the default entry for "apex=*@domain", which allows all APEX services in the owner's domain access to all actions.

APEX 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.

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 '\'.)



 TOC 

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:

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' />
    <access owner='fred@example.com'
            actor='*@*'
            actions='core:data'
            lastUpdate='2000-05-14T13:20:00-08:00' />

Briefly:

Note that although the four default entries are always available, the explicit entry for actor "*@*" overrides the corresponding default entry.



 TOC 

3.2.  Creating and Updating Access Entries

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 (Finding the Appropriate Entry: Matching Owners and Actors)). For the purposes of retrieving and updating entries, actor values are treated simply as literal names.



 TOC 

4.  The Access Service

Section 5 (Registration: The Access Service) contains the APEX service registration for the access service:

An implementation of the service must maintain information about access entries in persistent storage.

Consult Section 6.1.1 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.) for a discussion on the properties of long-lived transaction-identifiers.



 TOC 

4.1.  Use of XML and MIME

Section 4.1 of [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.) describes how arbitrary MIME content is exchanged as a BEEP (Rose, M., “The Blocks Extensible Exchange Protocol Core,” March 2001.) [RFC3080] 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

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


 TOC 

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:

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 (cf., Section 3.1 (Finding the Appropriate Entry: Matching Owners and Actors)).
  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.



 TOC 

4.3.  The Get Operation

Prior to creating or updating an access entry for some owner/actor combination, an application will usually need to retrieve any existing access entry. It does so by sending a "get" element to the service. In particular, a successful response returns a "lastUpdate" value that is necessary when sending a subsequent "set" element.

The "get" element has an "owner" attribute, an "actor" attribute, a "transID" attribute, and no content:

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 551 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.



 TOC 

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:

The "access" element has an "owner" attribute, an "actor" attribute, an optional "actions" attribute, an optional "lastUpdate" attribute, and no content:

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 is present in the supplied "set" element, a "reply" element having code 555 is sent to the originator.
  6. If no such entry exists and the "lastUpdate" attribute is absent in the supplied "set" element, 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 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.
  8. If "actions" attribute of the supplied "access" element is not present, 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 lacking an "actions" attribute is sent to the subject's address.
  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.



 TOC 

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 [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.), respectively, for the definition and an exposition of the syntax of the reply element.



 TOC 

5.  Registration: The Access Service

Well-Known Endpoint:
apex=access
Syntax of Messages Exchanged:
c.f., Section 6 (The Access Service DTD)
Sequence of Messages Exchanged:
c.f., Section 4 (The Access Service)
Access Control Tokens:
access:query, access:get, access:set
Contact Information:
c.f., the "Authors' Addresses" section of this memo


 TOC 

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" "">
    %APEXACCESS;
  -->


<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%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">


















<!--
  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>




<!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>


 TOC 

7.  Security Considerations

Consult [RFC3340] (Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” July 2002.)'s Section 11 for a discussion of security issues.

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).



 TOC 

8. References

[RFC3340] Rose, M., Klyne, G., and D. Crocker, “The Application Exchange Core,” RFC 3340, July 2002.
[RFC3080] Rose, M., “The Blocks Extensible Exchange Protocol Core,” RFC 3080, March 2001 (TXT, HTML, XML).


 TOC 

Appendix A.  Acknowledgements

The authors gratefully acknowledge the contributions of: Neil Cook, Darren New, Chris Newman, Scott Pead, and Bob Wyman.



 TOC 

Authors' Addresses

  Marshall T. Rose
  Dover Beach Consulting, Inc.
  POB 255268
  Sacramento, CA 95865-5268
  US
Phone:  +1 916 483 8878
Email:  mrose@dbc.mtview.ca.us
  
  Graham Klyne
  Clearswift Corporation
  1310 Waterside
  Arlington Business Park
  Theale, Reading RG7 4SA
  UK
Phone:  +44 11 8903 8903
Email:  Graham.Klyne@MIMEsweeper.com
  
  David H. Crocker
  Brandenburg InternetWorking
  675 Spruce Drive
  Sunnyvale, CA 94086
  US
Phone:  +1 408 246 8253
Email:  dcrocker@brandenburg.com
URI:  http://www.brandenburg.com/


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment