Network Working Group D. New Internet-Draft Invisible Worlds, Inc. Expires: October 30, 2001 May 2001 APEX Endpoint Servers draft-new-apex-server-01 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 a convention for providing an equivalent to a "well-known port" facility for services provisioned independently of the relaying mesh. This provides the ability to contact servers not associated with specific users. New Expires October 30, 2001 [Page 1] Internet-Draft APEX Server May 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Establishing Contact . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 B. Security Considerations . . . . . . . . . . . . . . . . . . . 7 C. History of Significant Changes . . . . . . . . . . . . . . . . 7 C.1 Significant changes since apex-server-00 . . . . . . . . . . . 7 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 New Expires October 30, 2001 [Page 2] Internet-Draft APEX Server May 2001 1. Introduction APEX, at its core, provides a best-effort aplpication-layer datagram service. Each datagram, simply termed "data", is originated and received by APEX "endpoints" -- applications that dynamically attach to the APEX "relaying mesh". Typically, these applications operate on behalf of end-users. However, some endpoints are used to realize APEX services (see Section 6 of [1]), e.g., the APEX access service [2]. These APEX services are ubiquitous throughout the relaying mesh. This memo describes a convention for providing an equivalent to a "well-known port" facility for services provisioned independently of the relaying mesh. This provides the ability to contact servers not associated with specific users. The services are termed APEX "endpoint servers". Typically, APEX Endpoint Servers will maintain state that an individual user would not maintain. For example, in a multi-user game, an APEX Endpoint Server would maintain the state of the world, store the maps, modify the world with respect to user actions, prevent cheating, and so on. It would be inappropriate to have any user's client (or all of them) knowing the complete state of the world and all other user's actions. Another example is that of an information server. In an information server, an APEX Endpoint Server would hold the store of information being served as well as supplying search services. For example, a corporate calendar service might maintain the appointment and meeting schedules for everyone in the corporation. It might also track the times when conference rooms are free. Users could schedule meetings with other users, as well as reserving conference rooms. The calendar information must be centralized, since a user may not be running a calendar client when another user wants to schedule a meeting with him. In addition, the central server would be able to keep track of the conference room schedules, which are not associated with any one user. The calendar service would always be running, sending reminders to individual users of their upcoming meetings. Hence, APEX Endpoint Servers would function like traditional client- server services, accepting messages from users or other servers, changing persistant state and returning answers. All such applications described in this memo are assumed to use APEX as their underlying data transport. In addition, it is assumed that the domain in which the service is running is known. Additional work would be necessary to allow domain-independent location of servers or services. New Expires October 30, 2001 [Page 3] Internet-Draft APEX Server May 2001 There are three primary areas where Endpoint Servers need additional support from APEX: Naming, Presence, and Access. 2. Naming The first problem is finding servers. For APEX services, the endpoint is named by the service and domain. Finding an endpoint for a peer-to-peer application is slightly more work. First, one must know the local@domain for the user to be contacted, such as "fred@example.com". Then one may use APEX's presence service to get the appropriate presence record. Iterating through the returned presence record will allow an application to find a compatible "tupleInfo" value, which in turn is associated with the "destination" attribute naming the appropriate endpoint. When accessing an APEX Endpoint Server, however, all that is known is the domain and the tupleInfo, with no user name to request from the presence service. Therefore, the first step in allowing Endpoint Servers to use APEX in a non-ad-hoc way is to add presence information for these servers in a way that it can be found by clients. This memo specifies that "apex-server" be reserved as a user name representing the "user" running all APEX Endpoing Servers at a particular domain. In this way, a client looking for a particular server can ask the presence service for the records describing what endpoint should be used. As an example, assume that a company known as Yadda Corporation has created two products. One, called FAQserve, serves answers to frequently-asked questions via APEX. Another, called BUGserve, allows for bug reporting and tracking. If both of these applications are run in the example.com domain, a presence record might appear as follows: New Expires October 30, 2001 [Page 4] Internet-Draft APEX Server May 2001 Note in particular the following details of the example: o The publisher is "apex-server". This means that this record can be retrieved by asking apex=presence@example.com for the record associated with apex-server@example.com. o The "tupleInfo" for each of the two services names Yadda Corporation (via "yadda.com") and the application associated with the destination ("FAQserve" or "BUGserve"). o Every "destination" attribute has an "/appl=" subaddress. The subaddresses do not need to match the "tupleInfo" in any way. However, every subaddress must be different, even if the username or domain is different as well. o The FAQ server is being run under the username of "apex-server". The BUG server is being run under the username of "support". This approach allows administrators to control what APEX services may be "officially" run on their APEX domains. Of course, any user can start an endpoint and then tell their friends where it is. However, to be an "official" service of example.com, one must have a presence record listed under apex-server@example.com. This, of course, can be tightly controled by administrators and monitored (via subscribe) by security and audit software. 3. Presence Presence [3] falls right out of the naming scheme. All the mechanisms in the presence service are available to endpoint servers as well. As an important point, endpoint servers can find other endpoint servers, allowing applications that distribute or delegate work to applications running on other domains. 4. Access The access service is defined in [2] to only support APEX services. In other words, only services that are available at every relay are listed in the access service record. This is understandable given the naming scheme used in the 'actions' attribute. However, this memo modifies that restriction. Since the presence record for apex-server is under centralized control by the owners of the domain, it is possible to avoid name clashes in the subaddresses defined for each server. That is, if a domain with "apex-server/appl=FAQ@..." wishes to install a new service called "apex=FAQ", this would naturally lead to a conflict in the APEX access tokens. However, in this case, simply changing the New Expires October 30, 2001 [Page 5] Internet-Draft APEX Server May 2001 endpoint to "apex-server/appl=FAQs@..." in the presence and access records would allow both services to be described without conflict. Hence, endpoint servers are required to have an "/appl=" subaddress as part of their destination endpoint attribute in the presence information. The string after the "/appl=" and up to the next non- alphanumeric character becomes the 'service' part of the 'actions' attribute in the access entry. For example, if only example.com users are allowed to see the bug DB but everyone is allowed to see the FAQ DB, the following access record might be present: Here, the "BUGDB" and "FAQs" come from the presence record described in the previous section. Hence, they match the token in the owner attribute as well. 5. Establishing Contact Both clients of Endpoint Servers and Endpoint Servers themselves must fetch and parse access and presence records. Client code must fetch and parse the presence record for "apex- server" under the appropriate domain. This is the same operation as needed for any other peer-to-peer application, except that the user name of "apex-server" is hard-coded. The Endpoint Server code itself must fetch and parse its own access control record, if access control to the Endpoint Server is goverened by that record. It would be helpful if proactive indications of changes to access control records by a third party were delivered to the owner of the record. New Expires October 30, 2001 [Page 6] Internet-Draft APEX Server May 2001 References [1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange Core", draft-ietf-apex-core-01 (work in progress), May 2001. [2] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service", draft-ietf-apex-access-01 (work in progress), May 2001. [3] Rose, M., Klyne, G. and D. Crocker, "The APEX Presence Service", draft-ietf-apex-presence-01 (work in progress), May 2001. [4] Author's Address Darren New Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rosa, CA 95401 US Phone: +1 707 578 2350 EMail: dnew@invisible.net URI: http://invisible.net/ Appendix A. IANA Considerations None. This is simply a convention, with no need for registration. Appendix B. Security Considerations Consult [1]'s section 11 for a discussion of security issues. In addition, an administrator provisioning APEX Endpoint Servers must ensure that endpoint names are chosen in such a way as to avoid conflicts in the access control record. Control of the presence record for the "apex-server" user (and to access records for subaddresses thereof) should be given only to trusted individuals, since records in this record are relevant to the entire domain rather than an individual user. Appendix C. History of Significant Changes New Expires October 30, 2001 [Page 7] Internet-Draft APEX Server May 2001 C.1 Significant changes since apex-server-00 Changed apex=server to apex-server, since it is not really a service. Adjusted access service records to have one per endpoint. Appendix D. Acknowledgements The author gratefully acknowledges the contributions of Marshall Rose[4]. New Expires October 30, 2001 [Page 8] Internet-Draft APEX Server 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. New Expires October 30, 2001 [Page 9]