[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-apex-access

Network Working Group                                          M.T. Rose
Internet-Draft                                    Invisible Worlds, Inc.
Expires: June 20, 2001                                          G. Klyne
                                            Content Technologies Limited
                                                            D.H. Crocker
                                                  Brandenburg Consulting
                                                       December 20, 2000


                        The APEX Access Service
                       draft-mrose-apex-access-00

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 June 20, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). 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 June 20, 2001                  [Page 1]


Internet-Draft          The APEX Access Service            December 2000


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Management of Access Information . . . . . . . . . . . . . . .  4
   2.1 Retrieval of Access Information  . . . . . . . . . . . . . . .  5
   2.2 Update of Access Information . . . . . . . . . . . . . . . . .  6
   3.  Format of Access Entries . . . . . . . . . . . . . . . . . . .  7
   4.  The Access Service . . . . . . . . . . . . . . . . . . . . . .  9
   4.1 Use of XML and MIME  . . . . . . . . . . . . . . . . . . . . . 10
   4.2 The Get Operation  . . . . . . . . . . . . . . . . . . . . . . 11
   4.3 The Set Operation  . . . . . . . . . . . . . . . . . . . . . . 12
   4.4 The Reply Operation  . . . . . . . . . . . . . . . . . . . . . 14
   5.  Registration: The Access Service . . . . . . . . . . . . . . . 15
   6.  The Access Service DTD . . . . . . . . . . . . . . . . . . . . 16
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   B.  Changes from IMXP  . . . . . . . . . . . . . . . . . . . . . . 21
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
































Rose, et. al.            Expires June 20, 2001                  [Page 2]


Internet-Draft          The APEX Access Service            December 2000


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. Although
   additional APEX services are co-resident with each relay within an
   administrative domain, 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 June 20, 2001                  [Page 3]


Internet-Draft          The APEX Access Service            December 2000


2. Management of Access Information

   Management of access information falls into two categories:

   o  applications may retrieve the access entry associated with an
      endpoint; and,

   o  applications may modify the access entry associated with an
      endpoint.

   Each is now described in turn.








































Rose, et. al.            Expires June 20, 2001                  [Page 4]


Internet-Draft          The APEX Access Service            December 2000


2.1 Retrieval of Access Information

   When an application wants to retrieve the access entry associated
   with an endpoint, 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 owner='fred@example.com' transID='1' />
            </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 owner='fred@example.com' transID='1'
                    timeStamp='14 May 2000 13:32:00 -0800'>
                    <access owner='fred@example.com'
                            lastUpdate='14 May 2000 13:02:00 -0800'>
                        <entry actor='*@example.com'
                               actions='core:data presence:subscribe' />
                        <entry actor='*@*' actions='core:data' />
                    </access>
                </set>
            </data-content>
        </data>
     S: <ok />






Rose, et. al.            Expires June 20, 2001                  [Page 5]


Internet-Draft          The APEX Access Service            December 2000


2.2 Update of Access Information

   When an application wants to modify the access entry associated with
   an endpoint, it sends a "set" 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'>
                <set owner='fred@example.com' transID='1'
                    timeStamp='14 May 2000 13:32: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='fred@example.com' />
            <data-content Name='Content'>
                <reply code='250' transID='1' />
            </data-content>
        </data>
     S: <ok />

   Note that Step 5 of Section 4.3 requires that the timestamp field of
   an access entry be supplied in order to update that entry;
   accordingly, applications must successfully retrieve an access entry
   prior to trying to update that entry.








Rose, et. al.            Expires June 20, 2001                  [Page 6]


Internet-Draft          The APEX Access Service            December 2000


3. Format of Access Entries

   Each administrative domain is responsible for maintaining an "access
   entry" for each of its endpoints (regardless of whether those
   endpoints are currently attached to the relaying mesh).

   Section 6 defines the syntax for access entries. Each access entry
   has an "owner" attribute, a "lastUpdate" attribute, and contains one
   or more "entry" elements:

   o  the "owner" attribute specifies the endpoint associated with the
      access entry;

   o  the "lastUpdate" attribute specifies the date and time that the
      service last updated the access entry; and,

   o  each "entry" element specifies, with respect to the owner's
      endpoint, an actor and zero or more allowed actions for that
      actor.

   Within an entry, actions are specified 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" action is
   consulted by the relaying mesh (c.f., Step 3.3 of Section 4.4.3.1 of
   [1]).

   An actor is an APEX endpoint and is specified using the "addr-spec"
   syntax specified in Section 3.4.1 of [2], i.e., the familiar
   "local@domain" syntax. 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 June 20, 2001                  [Page 7]


Internet-Draft          The APEX Access Service            December 2000


   Regardless of the "entry" elements present in an access entry, four
   additional elements are always considered to exist at the end of the
   access entry:

     <entry actor='apex=*@domain' actions='all:all' />
     <entry actor='apex=*@*'      actions='core:data' />
     <entry actor='local@domain'  actions='all:all' />
     <entry actor='*@*'           actions='' />

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

   Ordering of "entry" elements within an access element is
   significant: a process examining an access element selects the first
   "entry" element that matches the actor in question. For example,
   consider this access entry:

       <access owner='fred@example.com'
               lastUpdate='14 May 2000 13:02:00 -0800'>
           <entry actor='wilma@example.com' actions='all:all' />
           <entry actor='mr.slate@example.com' actions='core:data' />
           <entry actor='*@example.com'
                actions='core:data presence:subscribe presence:watch' />
           <entry actor='*@*' actions='core:data' />
       </access>

   Briefly:

   o  For endpoints within the "example.com" administrative domain:

      *  "fred", "wilma", and all APEX services, are allowed access to
         all operations for all APEX services;

      *  "mr.slate" is allowed access only to send data through the
         relaying mesh; and,

      *  any other endpoint is allowed access to send data and invoke
         the "subscribe" and "watch" operations of the APEX presence
         service.

   o  For any endpoint outside the "example.com" administrative domain,
      the endpoint is allowed access to send data, regardless of
      whether it is an APEX service.

   Note that although the four additional elements are always present,
   the ordering semantics cause the final element to be unused.





Rose, et. al.            Expires June 20, 2001                  [Page 8]


Internet-Draft          The APEX Access Service            December 2000


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 either the get or set operation.

   o  The service replies to these operations, and does not initiate
      communications.

   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 June 20, 2001                  [Page 9]


Internet-Draft          The APEX Access Service            December 2000


4.1 Use of XML and MIME

   Section 4.1 of [1] describes how arbitrary MIME content is exchanged
   as a BEEP[3] payload. For example, to transmit:

       <data content='...'>
           <originator identity='fred@example.com' />
           <recipient identity='apex=access@example.com' />
       </data>

   where "..." refers to: <get owner='fred@example.com' transID='1' />

   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-Transfer-Encoding: binary
       C: Content-ID: <2@example.com>
       C:
       C: <get owner='fred@example.com' transID='1' />
       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:         <get owner='fred@example.com' transID='1' />
       C:     </data-content>
       C: </data>
       C: END


Rose, et. al.            Expires June 20, 2001                 [Page 10]


Internet-Draft          The APEX Access Service            December 2000


4.2 The Get Operation

   When an application wants to retrieve the access entry associated
   with an endpoint, it sends a "get" element to the service.

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

   o  the "owner" attribute specifies the endpoint associated with the
      access entry; 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 of that element as the "subject", and the service performs
   these steps:

   1.  If the subject is outside of this administrative domain, a
       "reply" element having code 553 is sent as data to the
       originator.

   2.  If the subject does not refer to a valid endpoint, a "reply"
       element having code 550 is sent as data to the originator.

   3.  If the subject's access entry does not contain a "access:get"
       token for the originator, a "reply" element having code 537 is
       sent as data to the originator.

   4.  Otherwise, a "set" element, corresponding to the subject's
       access entry, is sent as data 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 June 20, 2001                 [Page 11]


Internet-Draft          The APEX Access Service            December 2000


4.3 The Set Operation

   When an application wants to modify the access entry associated with
   an endpoint, it sends a "set" element to the service.

   The "set" element has an "owner" attribute, a "transID" attribute,
   and contains an "access" element:

   o  the "owner" attribute specifies the endpoint to be associated
      with the access entry;

   o  the "transID" attribute specifies the transaction-identifier
      associated with this operation;

   o  the "timeStamp" attribute specifies the current date and time;
      and,

   o  the "access" element contains the desired access entry for the
      endpoint.
































Rose, et. al.            Expires June 20, 2001                 [Page 12]


Internet-Draft          The APEX Access Service            December 2000


   When the service receives a "set" element, we refer to the "owner"
   attribute of that element as the "subject", and the service performs
   these steps:

   1.  If the "owner" attribute of the "set" element doesn't match the
       "owner" attribute of the "access" element contained in the "set"
       element, a "reply" element having code 503 is sent as data to
       the originator.

   2.  If the subject is outside of this administrative domain, a
       "reply" element having code 553 is sent as data to the
       originator.

   3.  If the subject does not refer to a valid endpoint, a "reply"
       element having code 550 is sent as data to the originator.

   4.  If the subject's access entry does not contain a "access:set"
       token for the originator, a "reply" element having code 537 is
       sent as data to the originator.

   5.  If the "lastUpdate" attribute of the "set" element is not
       semantically identical to the last update time of the subject's
       access entry, a "reply" element having code 555 is sent as data
       to the originator. (This allows a basic mechanism for atomic
       updates.)

   6.  Otherwise:

       1.  The subject's access entry is updated from the "set" element.

       2.  The last update time of the access entry is set to the
           current time.

       3.  A "reply" element having code 250 is sent as data to the
           originator.

   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 June 20, 2001                 [Page 13]


Internet-Draft          The APEX Access Service            December 2000


4.4 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 June 20, 2001                 [Page 14]


Internet-Draft          The APEX Access Service            December 2000


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:get, access:set

   Contact Information: c.f., the "Authors' Addresses" section of this
      memo







































Rose, et. al.            Expires June 20, 2001                 [Page 15]


Internet-Draft          The APEX Access Service            December 2000


6. The Access Service DTD

   <!--
     DTD for the APEX access service, as of 2000-12-12


     Refer to this DTD as:

       <!ENTITY % APEXACCESS PUBLIC "-//Blocks//DTD APEX ACCESS//EN"
                "http://xml.resource.org/profiles/APEX/apex-access.dtd">
       %APEXACCESS;
     -->


   <!ENTITY % APEXCORE PUBLIC "-//Blocks//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
     -->

   <!ENTITY  % ACTOR   "CDATA">





















Rose, et. al.            Expires June 20, 2001                 [Page 16]


Internet-Draft          The APEX Access Service            December 2000


   <!--
     Synopsis of the APEX access service

       service WKE: apex=access

       message exchanges:

           consumer initiates    service replies
           ==================    ================
           get                   set or reply
           set                   reply

       access control:

           token                 target
           ==========            ======
           access:get            for "owner" of "access" element
           access:set            for "owner" of "access" element
     -->


   <!ELEMENT get         EMPTY>
   <!ATTLIST get
             owner       %ENDPOINT;        #REQUIRED
             transID     %UNIQID;          #REQUIRED>


   <!-- owner attributes must match in set and access -->

   <!ELEMENT set         (access)>
   <!ATTLIST set
             owner       %ENDPOINT;        #REQUIRED
             transID     %UNIQID;          #REQUIRED
             timeStamp   %TIMESTAMP;       #REQUIRED>


   <!--
     access entries
     -->

   <!ELEMENT access      (entry+)>
   <!ATTLIST access
             owner       %ENDPOINT;        #REQUIRED
             lastUpdate  %TIMESTAMP;       #REQUIRED>

   <!ELEMENT entry       EMPTY>
   <!ATTLIST entry
             actor       %ACTOR;           #REQUIRED
             actions     NMTOKENS          "">


Rose, et. al.            Expires June 20, 2001                 [Page 17]


Internet-Draft          The APEX Access Service            December 2000





















































Rose, et. al.            Expires June 20, 2001                 [Page 18]


Internet-Draft          The APEX Access Service            December 2000


References

   [1]  Rose, M.T., Klyne, G. and D.H. Crocker, "The Application
        Exchange Framework", draft-mrose-apex-core-00 (work in
        progress), December 2000.

   [2]  Resnick, P., "Internet Message Format", draft-drums-msg-fmt-09
        (work in progress), September 2000.

   [3]  Rose, M.T., "The Blocks Extensible Exchange Protocol
        Framework", draft-ietf-beep-framework-09 (work in progress),
        December 2000.


Authors' Addresses

   Marshall T. Rose
   Invisible Worlds, Inc.
   1179 North McDowell Boulevard
   Petaluma, CA  94954-6559
   US

   Phone: +1 707 789 3700
   EMail: mrose@invisible.net
   URI:   http://invisible.net/


   Graham Klyne
   Content Technologies Limited
   1220 Parkview
   Arlington Business Park
   Theale, Reading  RG7 4SA
   UK

   Phone: +44 118 930 1300
   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 June 20, 2001                 [Page 19]


Internet-Draft          The APEX Access Service            December 2000


Appendix A. Acknowledgements

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















































Rose, et. al.            Expires June 20, 2001                 [Page 20]


Internet-Draft          The APEX Access Service            December 2000


Appendix B. Changes from IMXP

   o  s/IMXP/APEX/g

   o  Indicate that APEX services are co-resident with each APEX relay.

   o  Change data's originator from an attribute to an element.

   o  Change addr-spec reference from RFC 822 to [2].










































Rose, et. al.            Expires June 20, 2001                 [Page 21]


Internet-Draft          The APEX Access Service            December 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000). 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 June 20, 2001                 [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/