Network Working Group D. New
Internet-Draft Invisible Worlds, Inc.
Expires: February 15, 2002 August 17, 2001
APEX Endpoint Servers
draft-new-apex-server-02
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 February 15, 2002.
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 February 15, 2002 [Page 1]
Internet-Draft APEX Server August 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Establishing Contact . . . . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
B. Security Considerations . . . . . . . . . . . . . . . . . . . 8
C. History of Significant Changes . . . . . . . . . . . . . . . . 8
C.1 Significant changes since apex-server-01 . . . . . . . . . . . 9
C.2 Significant changes since apex-server-00 . . . . . . . . . . . 9
D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
New Expires February 15, 2002 [Page 2]
Internet-Draft APEX Server August 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 February 15, 2002 [Page 3]
Internet-Draft APEX Server August 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:
<presence
publisher='apex-server@example.com'
lastUpdate='....'>
<tuple
destination='apex:apex-server/appl=FAQs@example.com'
availableUntil='...'
tupleInfo='http://yadda.com/apex/FAQserve'/>
<tuple
destination='apex:support/appl=BUGDB@example.com'
availableUntil='...'
tupleInfo='http://yadda.com/apex/BUGserve'/>
</presence>
New Expires February 15, 2002 [Page 4]
Internet-Draft APEX Server August 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 February 15, 2002 [Page 5]
Internet-Draft APEX Server August 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:
<access owner='apex-server/appl=FAQs@example.com'
actor='root@example.com' actions='all:all'
lastUpdate='...'/>
<access owner='apex-server/appl=FAQs@example.com'
actor='*@example.com'
actions='FAQs:read FAQs:write'
lastUpdate='...'/>
<access owner='apex-server/appl=FAQs@example.com'
actor='*@*' actions='FAQs:read'
lastUpdate='...'/>
<access owner='support/appl=BUGDB@example.com'
actor='root@example.com' actions='all:all'
lastUpdate='...'/>
<access owner='support/appl=BUGDB@example.com'
actor='*@example.com'
actions='BUGDB:all'
lastUpdate='...'/>
<access owner='support/appl=BUGDB@example.com'
actor='*@*' actions='BUGDB:none'
lastUpdate='...'/>
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.
New Expires February 15, 2002 [Page 6]
Internet-Draft APEX Server August 2001
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 February 15, 2002 [Page 7]
Internet-Draft APEX Server August 2001
References
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", draft-ietf-apex-core-05 (work in progress), February
2001.
[2] Rose, M., Klyne, G. and D. Crocker, "The APEX Access Service",
draft-ietf-apex-access-07 (work in progress), August 2001.
[3] Rose, M., Klyne, G. and D. Crocker, "The APEX Presence Service",
draft-ietf-apex-presence-05 (work in progress), August 2001.
[4] <mailto:mrose@dbc.mtview.ca.us>
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
Note to RFC editor: Please remove this appendix and the table-of-
contents entries for it before publication.
New Expires February 15, 2002 [Page 8]
Internet-Draft APEX Server August 2001
C.1 Significant changes since apex-server-01
Updated to account for changes in other APEX drafts.
C.2 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 February 15, 2002 [Page 9]
Internet-Draft APEX Server August 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 February 15, 2002 [Page 10]
