rfc3341.txt

RFC 的详细文档！

   While processing operations, the service may respond with a "reply"
   element.  Consult Sections 10.2 and 6.1.2 of [1], respectively, for
   the definition and an exposition of the syntax of the reply element.

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.               Standards Track                    [Page 20]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


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)




Rose, et. al.               Standards Track                    [Page 21]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


       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>







Rose, et. al.               Standards Track                    [Page 22]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


7. Security Considerations

   Consult [1]'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).

References

   [1]   Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
         Core", RFC 3340, July 2002.

   [2]   Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
         3080, March 2001.



































Rose, et. al.               Standards Track                    [Page 23]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


Authors' Addresses

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   POB 255268
   Sacramento, CA  95865-5268
   US

   Phone: [phone]
   EMail: [e-mail]


   Graham Klyne
   Clearswift Corporation
   1310 Waterside
   Arlington Business Park
   Theale, Reading  RG7 4SA
   UK

   Phone: [phone]
   EMail: [e-mail]


   David H. Crocker
   Brandenburg Consulting
   675 Spruce Drive
   Sunnyvale, CA  94086
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.brandenburg.com/



















Rose, et. al.               Standards Track                    [Page 24]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


Appendix A. Acknowledgements

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















































Rose, et. al.               Standards Track                    [Page 25]

RFC 3341     The Application Exchange (APEX) Access Service    July 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.               Standards Track                    [Page 26]