2.1.20 IMXP BOF (imxpbof)

Current Meeting Report

Minutes of the IMXP BOF at the 49th Meeting of the IETF

Pete Resnick chaired the meeting.

The meeting was held under "Resnick's Rules of Order", to wit, the speakers were asked to present their remarks in the context of an audience who was familiar with the documents. The goal of this is to limit the prepared presentations to 20 minutes, so that the remaining 40 minutes could be devoted to discussion.

Agenda Bashing:

Pete Resnick stated that he viewed this as a traditional BOF -- the goal is to solicit comments on a particular problem and solution and gauge both interest and criticism of both areas. Accordingly, the charter will be discussed and modified after the presentations and the discussion.

Introduction to Problem Space:

Pete Resnick presented a rationale for an extensible mesh for application layer relaying. Refer to the introduction of draft-mrose-imxp-core for the details. Briefly, the basic building blocks are beep to provide hop-by-hop communications, overwhich the relaying mesh is provisioned.

IMXP Framework and Services:

Dave Crocker presented a summary of the IMXP framework and core services. Many of the IMXP concepts are derived from existing IETF architecture and technologies, e.g., the local@domain syntax for addressing. In addition to the relaying mesh, IMXP provides, at a minimum, reporting, access and, presence service, to report errors, and manage authorization and subscriber policies.

The default service model for the relaying mesh is that it is lightweight, message-oriented, stateless, asynchronous, push, and best-effort. The use of options allows endpoints to request additional, "heavier" services, e.g., end-to-end acknowledgements.

Options in IMXP are extensible, in the sense that they may be bilaterally, but uniquely, defined, along with various flags to indicate where the option should be processed and whether encountering an unimplemented option should be ignored or result in an error.

Instant Messaging:

Graham Klyne presented a summary of how to implement Instant Messaging using IMXP. A text-based, CPIM-compliant IM service over IMXP is proposed. IMessages are comprised of headers and bodies, encoded using XML. A new specification describes how to encode RFC822 headers as elements, preserving the existing semantics of those headers (e.g., "Reply-To:").

Although IMXP is optimized for exchanging XML-based content, IMXP also supports other kinds of payload, e.g., those containing images, pointers, et&c. The use of XML for Instant Messaging is controversial in the sense that it has both strengths (internationalization, regularized structuring, and extension without registration), and weaknesses (newness, lack of compactness).

As IMXP provides configurable security mechanism, the proposal recommends default levels of security for the endpoint-relay and relay-relay modes when exchanging Instant Messages.


How long should a hop wait until it gives up on trying to relaying a message? In the absence of processing options, the duration should be as fast as existing IM systems (e.g., sub-second).

Can messages be routed directly between endpoints? Message routing is based on SRV records, in a fashion similar to email MX routing. The architecture requires a relay to be used, but an implementation might co-locate a relay with an endpoint, possibly achieving a similar effect.

Do things like the presence service sit on top of relaying mesh? From the architectural perspective, the answer is yes. From an implementation perspective, a presence service could be co-located with a relay server.

Could the presence server be used to announce resource servers? Interesting idea.

In addition to DNS SRV RRs, the SLP could be used to locate local relays. Agreed.

So, why this approach for Instant Messaging? c.f., Section 3.2 of draft-rosenberg-impp-differences-00.txt

Hums were asked for two questions: interest in IMXP with Instant Messaging, and interest in IMXP independent of Instant Messaging. There was substantial humming to both questions, although, to the note-takers ear, the latter question had somewhat louder response.

A dozen folks in the room indicated that they would be interested in implementing IMXP in their products.

What are the implications of this on rescap? This is a heavy protocol for the kinds of things that rescap is intended for. However, rescap might be used by IMXP user agents for (e.g.) determining receiver capabilities before sending a message.

What other kinds of applications could be hosted on top of IMXP? SNMP (just kidding). Any applications requiring coordination. User notification of new email.


A mailing list was announced: imxpwg-request@invisible.net

A draft charter was presented.

There was agreement that the milestones should be structured to separate items dependent on CPIM.

BOF adjourned.


None received.