FIPA E-Gents: Agents over Computational E-mail
Venu Vasudevan
Object Services and Consulting Inc.
Email: venu@objs.com
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".
Objective
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:
-
E-mail clients are lightweight and likely to be available on most computational
devices.
-
Unlike applet communication protocols, e-mail is peer-to-peer and symmetric.
Therefore, an e-mail based agent communication channel does not need an
ACL router component.
-
Firewalls are not an issue for e-mail based communication. Agents on either
side of a firewall can communicate more easily with an e-mail based infrastructure
than with a TCP/IP infrastructure.
-
The ISP mailbox acts as a message queueing facility, obviating the need
for a specialized message queueing component.
-
E-mail addresses of mobile users remain constant (even across multiple
machines). E-mail thus offers certain advantages when used as a communications
infrastrcture for mobile users.
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:
-
security for computational e-mail
-
sharing of e-mail channels by groups of agents
-
expressing the ontology used by an agent in RDF (instead of ontolingua
or other)
-
Sessions - groups of performatives sent as a single file (meant for different
agents at the same locations)
-
Bit efficient ACL representation - Bit-efficiency issues could be
examined at the XML-to-ACL mapping level, or the XML transport level (e.g
TokenXML). We believe the latter is more important, and that ACL-over-XML
should focus on completeness first before bit optimization.
-
ACL display primitives - There is a need to investigate the use of XSL
(or stylesheeting) mechanisms to display ACL-over-XML documents
Selected References
-
VisitorBot - http://www.research.att.com/~kautz/papers-ftp/aaai94bots.ps
-
Atomic Mail - http://www.incoma.ru/cdrom4/networking/mail/metamail/CSCW-ATOMICMAIL.txt
-
MIT SodaBot - http://alpha-bits.ai.mit.edu/people/sodabot/
-
Binary
XML Content Format Specification http://www.wapforum.org/docs/technical/wbxml-30-apr-98.pdf
to reduce the transmission size of XML documents.
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"?>
<fipa_performative>
<perfName>request</perfName>
<sender>hisAgent</sender>
<receiver>myAgent</receiver>
<content>an_SL0_Performative</content>
<language>SL0</language>
</fipa_performative>
Appendix B - Computation Mail API
The computation mail infrastructure needs to provide an interface consisting
of three kinds of objects:
-
Mailbox Handler: This object encapsulates the mailbox, and
provides session and transaction support APIs (i.e. bind to mailbox, retrieve
all, selected retrieve, all delete, selective delete, disconnect)at the
Java level. It is desirable for the FIPA e-gents standard to support
both POP3 and IMAP mail protocols. The former is widely deployed, and the
latter is a more powerful, emerging protocol. Sun's JavaMail API supports
IMAP but not POP3. Thus a FIPA-specific subset of the JavaMail API
that makes sense for POP3, needs to be pinned down.
-
MIMEDecoder : The MIMEDecoder decodes MIME-encoded mail that it
retrieves from the Mailbox object. A MIMEdecoder needs to support well
known MIME types (e.g. multipart).
-
MIMEMessage : MimeMessage provides an API to access email header
information (subject, recipients, data and time of sending etc.) and body
information as separate components.