FIPA E-Gents: Agents over Computational E-mail

Venu Vasudevan
Object Services and Consulting Inc.

Significance of Problem

Despite the proliferation of the internet, e-mail remains the dominant mode of interaction for both commercial and non-commercial purposes.  With over 100 million users, e-mail  provides a large customer base, and consequently a compelling platform for agent deployment. A number of virtual enterprise applications that do not have hard real-time constraints are perfectly viable candidates to be implemented over an e-mail infrastructure. Simple but important examples include virtual office automation tasks such as meeting scheduling, timesheet collection, software license cataloging, and remote administration. Free-mail (i.e. e-mail services that provide email accounts without any associated fees) based e-commerce is a major current thrust for free-mail providers, and one in which e-mail based agents can play an important role. The FIPA agent platform as specified does not provide standards for agents to communicate over email, but could be augmented with e-mail based agent channel abstractions that allow it to operate over e-mail, thus providing an "agent system for the masses".


We propose that FIPA adopt a family of (at least) two specifications aimed at supporting an e-mail based agent infrastructure.  The first  standard governs the translation of ACL strings to XML documents and their reassembly as ACL strings or java objects on the receiving end. The other standard covers a programmatic API for encoding ACL-as-XML documents into emails, and the decoding of MIME-encoded ACL-as-XML documents back into either ACL strings or as Java objects that represent the ACL command. The two standards combine to implement an e-mail based agent communication channel, while also using an XML-based encoding scheme that can be reused in web agents.

Relevant sections in the FIPA CFP: 4.4.3 (Agents on the Web)

Specification Details

In this initial proposal, we cover a   base specification which assumes that agents have unique e-mail addresses.  It identifies but does not yet specify a position on  a number of issues. These issues would be the subject of an augmented specification for e-mail based agents.

The base specification  consists of an e-mail based ACL interchange format (subsequently referred to as interchange format), and the messaging API to send and receive ACL messages over e-mail. We propose the interchange format to be based on XML, as this will allow the same format to be reused by other web protocols (notably HTTP).  The interchange format should specify a DTD (document type definition) (see Appendix A) that allows a FIPA ACL performative (and perhaps the contained FIPA SLx content) to be expressed as an XML document.

The messaging API (see Appendix B) has a send and a receive component. The send component allows a programming language ACL object to be convertable to an email-able messaging document, and to be dispatched using SMTP. The send component also has an API for convert a (performative, receiving agent) pair to an (e-mail message, e-mail address) pair.  The recieve messaging API allows:

  • API to access a mailbox (POP3 or IMAP) and return the set of available e-gent messages
  • Selection and downloading of specific messages
  • Extraction of subject, date and content of e-gent messages
  • Sorting and filtering of e-gent messages based on the above criteria
  • MIME decoding of the content and assembly of the performative object (e.g as a Java object) on the receiving side
  • Reference Implementation

    OBJS has a reference implementation of an e-mail based agent communication channel that is based on the JavaMail API (1.0b), IBM's AlphaBeans (POP3 suite of 3 beans for message reception and MIME decoding), and IBM's XML parser. We have defined a DTD that allows single FIPA ACL performatives to be externalized as XML documents. We have also written an  ACL unstreamer that uses the AlphaBean and IBM's XML parser to assemble ACL-as-XML documents into java objects representing the performative.

    Related Work

    Our idea is similar in spirit to JATLite, which provides an agent communication channel for Java applet agents over TCP/IP connection. However, our use of e-mail as a computation infrastructure provides a simpler and more general infrastructure for the following reasons: Other projects, such as AT&T's VisitorBot provide a good real-life application for which e-mail is a suitable computational infrastructure. MIT"s SodaBot provides a more complete architecture for an e-mail based agent system.

    Issues to be addressed

    A caveat about our submission.  While we have prototyped e-mail agent ideas in a reference implementation, we do not have extensive experience using a running implementation so believe some improvements are likely.  Some issues we believe are important that we have not addressed here are:

    Selected References

    Appendix A

    Simple ACL-XML DTD

    Below is an XML DTD for FIPA ACL messages that serves as a simple ACL transport between e-mail agents, and is used by the reference implementation discussed above. The advantage of this DTD is simplicity and coverage of the basic transport function. Further optimizations can be made to it, both to make it more strongly typed and to reduce the consumed bandwidth.

    <?xml encoding="US-ASCII"?>

    <!ELEMENT fipa_performative (perfName, sender, receiver, content, ontology, language)>

    <!ELEMENT perfName (#PCDATA)>
    <!ELEMENT sender (#PCDATA)>
    <!ELEMENT receiver (#PCDATA)>
    <!ELEMENT content (#PCDATA)>
    <!ELEMENT ontology (#PCDATA)>
    <!ELEMENT language (#PCDATA)>

    Sample ACL-over-XML performative

    <?xml version="1.0"?>

    Appendix B - Computation Mail API

    The computation mail infrastructure needs to provide an interface consisting of three kinds of objects: