NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Pete Resnick <firstname.lastname@example.org>
Ned Freed <email@example.com>
Patrik Faltstrom <firstname.lastname@example.org>
Patrik Faltstrom <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe
The APEX working group shall specify protocols and data formats that define a relaying mesh service for loosely-coupled Internet applications, along with specifying services to provide access control and rendezvous-by-subscription. In addition, the working group shall specify CPIM-compliant application services for text-based instant messaging and for online presence, based on the APEX service.
Instant messaging differs from email primarily by requiring relatively short delivery latency guarantees and, typically, less robust transport service. Presence information was readily accessible on Internet-connected systems years ago; when a user had an open session to a well-known multi-user system, friends and colleagues could easily tell who was online. However there is no standard way to make this information known to peers. Similarly a number of messaging systems have operated over the Internet and continue to do so, although none has focused on assuring very low latency between posting and delivery.
The working group will use APEX (as described in draft-mrose-apex-*) as the basis of the relay mesh, access control and rendezvous specifications. The working group will use draft-klyne-imxp-message-service and draft-klyne-message-rfc822-xml as its starting points for defining the instant messaging and presence conforming to RFC2779 and the interoperability details in the final version of the CPIM specification (draft-ietf-impp-cpim). BCP 41 will be the basis for working group consideration of the transport implications of the APEX designs with respect to network congestion, and the working group will coordinate on this with the BEEP WG.
Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them.
Prepare updated specifications for APEX relay mesh, access and rendezvous, reflecting issues and solutions identified by the working group
Prepare initial draft of CPIM-compliant APEX Text Messaging and Presence specifications
Submit revised APEX specifications to the IESG for consideration as a standards-track publication
Submit revised Text Messaging and Presence specifications to the IESG for consideration as a standards-track publication
Apex Minutes for Minneapolis (IETF 50)
1. Welcome - Pete Resnick
The chair announced that the working group had been formed two weeks earlier, and went over the agenda. Marshall Rose is taking the minutes.
2. "End-point Servers" proposal - Darren New
A presentation was made suggesting an additional facility be layered on top of APEX - the equivalent of a well-known port facility for servers that are provisioned independently of the relaying mesh.
The key technical issue is that the action tokens used by the APEX access service are keywords (not hierarchical entities). The proposal introduced a convention for allowing arbitrary services that use APEX to utilize the access service without working about conflicts. It was noted that it would also be useful if the access service would notify an endpoint when its access entry was updated, in order to facilitate caching.
It was agreed that the presenter would prepare a draft proposal for the mailing list.
In addition, it was noted that International University in Germany has an alternative approach, and might also document that proposal.
3. "Multicast APEX" - Jon Crowcroft
A presentation was made on some design issues for overlaying application-layer multicast on top of APEX, noting that there was a lack of standards-based approaches available.
The work is in it's early stages, although it raises some interesting issues. For example, since introducing multicasting to APEX will require the use of a dynamic unicast routing protocol, should such a facility also be available throughout the relaying mesh. It was noted that since the relaying mesh is option-driven, it's trivial to define an option that makes use of such a dynamic routing facility.
4. "General Issues" - Chris Newman
An informal set of issues was raised:
4a. The use of subaddresses is ambiguous (i.e., the specification doesn't explicitly indicate what signifies a subaddress, thereby leading to the "longest same name" problem). The editor will clarify the text.
4b. The relay-relay mode requires that an APEX relay have an entry in the DNS. This is problematic for single users whose ISP don't run APEX and don't allow dns updates. It was noted that the DNS dependency would go away if Step 2 of Section 4.4.2 (the bind operation) didn't rely on a reverse-lookup. It was suggested that third-party ISPs may offer APEX service (e.g., ISP1 is what you use to get IP connectivity with, and ISP2 runs an APEX service that you subscribe to as an endpoint). The chair invites comment.
4c. seeNoEvil='false' is a double negative. The editor will change this to 'mustUnderstand', so compatibility with SOAP can be claimed.
4d. It was suggested (a) that the 'content=' attribute of the <data> element is sent as a URL, which is not strictly necessary to use when the content is nested XML; and (b) that the internal referencing mechanism appears to disregard the XML ID/IDREF mechanisms. Responses: (a) the design is that 'content=' uses a consistent URI-based mechanism for both internal and external references. The internal reference, in the form of a fragment identifier, uses XPointer URI fragment mechanism which in turn uses XPath, and (b) the 'Name=' attribute of <content-data> is declared in the DTD to have the XML attribute type ID, which is picked up by the XPointer fragment reference. Thus, this proposal is intended to use a form that is compatible with emerging XML developments; in the absence of further discussion, no further change is necessary.
4e. It was noted that supporting per-recipient capabilities would be welcome. It was asked whether the presence service could provide this facility. It was noted that if so, then the presence service probably needs to allow selective retrieval of a presence entry. The chair invites proposals in the form of Internet-Drafts.
5. "Options" - Marshall Rose
It was observed that the relaying mesh is option driven and that the APEX core provides the simplest default mechanisms. Although several parties have privately suggested options for consideration, none of these proposals have circulated publically. The chair invites proposals.
6. Adjourn - Pete Resnick
APEX: An Application Datagram Service
BEEP: Building Blocks for Application Protocols
APEX Client Servers