1         Participants

-         JADE (TILab)

o       Fabio Bellifemine, Tiziana Trucco, Giovanni Rimassa[1]

-         FIPA-OS (Emorphia)

o       Alan Treadway , Chris Newland

-         ZEUS (BT)

o       Simon Thompson

-         HTTP-MTP (EPFL)

o       Ion Constantinescu

2         Dates

-         Sunday 1^st April, 10:30 – Thursday 5^th April 19:00

3         Location

-         Room 403 (4^th floor) just in front of the plenary room

4         Goals

-         Test the FIPA specifications by proving the interoperability of the platforms.

-         Possibly produce a simple demo for the FIPA membership

-         Write an output document to FIPA with the following content

o       Report of the bake-off activity

o       Suggestions to improve the effectiveness / reduce the ambiguity of the FIPA specs

-         Produce a workplan for a FIPA compliance test

o       Possibly edit a draft document (for the Agent Management specs & others) based on the input document from EPFL & Motorola (Agentcities test suite Discussion Document v. 1.0)

-         Identify/Recommend someone with the responsibility of checking that the proposed modifications are actually done in the FIPA specs, or at least a valid alternative solution is found.

5         Agenda

6         Requirements

-         Noise: not so much

-         room 503 size: 6 persons for the bake-off + audience.

-         The Imperial mini-hub (we can give the CSELT mini-hub to Kaveh)

-         A Computer Projector

7         List of FIPA specs that have been used

-         Agent Management specs

-         Message Transport Service

-         MTP for IIOP

-         MTP for HTTP

-         Agent Communication Language Parameters

-         String ACL Encoding

-         Bit-efficient ACL Encoding

-         FIPA-SLO content language

-         FIPA-Request Interaction Protocol

-         FIPA-Query Interaction Protocol

8         List of FIPA specs that have not been used

-         Content languages: full SL, CCL, KIF, RDF

-         ACL Encodings: XML

-         most of the interaction protocols

-         Human-agent interaction

-         Ontology service

-         Agent-software integration

-         4 informative applications

-         Nomadic support

-         WAP

-         Mobility

-         Abstract architecture

Note: That does not mean that these specs are less useful!

9         Configuration

A LAN has been configured by using a mini-hub kindly provided by Imperial College.

A directory has been shared to exchange provisionally and easily the addresses of the platforms.

An anonymous ftp has been setup on cmddata for the same purpose, alternatively.

10        Conducted tests

-         Using: Sun Jdk1.3, IIOP FIPA2000 MTP, Sun ORB and String encoding of ACL by directly exchanging the IORs

o       Sending a single message

o       Ping-Alive Conversations (fipa-query protocol with no exceptions). The Initiator gets the IOR directly from a file, while the responder gets the address of the initiator directly from the ACL message.

-         AMS Using: Sun Jdk1.3, IIOP FIPA2000 MTP, Sun ORB and String encoding of ACL by directly exchanging the IORs. The Initiator gets the IOR directly from a file, while the responder gets the address of the initiator directly from the ACL message.

o       GetAPDescription

o       Search with the AMS

o       Register

o       Deregister

o       Modify

-         DF Using: Sun Jdk1.3, IIOP FIPA2000 MTP, Sun ORBand String encoding of ACL by directly exchanging the IORs. The Initiator gets the IOR directly from a file, while the responder gets the address of the initiator directly from the ACL message.

o       Search with the DF

o       Register

o       Deregister

o       Modify

o       Federate the DF. The initiator registers its DF with the DF of the responder platform. The responder correctly recognizes this registration as a registered DF.

o       Search with a DF that propagates to another DF. The initiator searches in its DF with a max-depth>1. The DF propagates the search to the federated DFs and correctly collects all the results. The federated DF belong to the responder platform.

-         HTTP MTP Using String encoding of ACL by directly exchanging the URLs

o       Sending a message.

o       Ping conversation. The Initiator gets the address directly from a file, while the responder gets the address of the initiator directly from the ACL message.

-         IIOP MTP Using bit-efficient encoding of ACL by directly exchanging the URLs

o       Sending a message.

o       Ping conversation. The Initiator gets the address directly from a file, while the responder gets the address of the initiator directly from the ACL message.

-         HTTP MTP Using bit-efficient encoding of ACL.

o       NOT TESTED

-         Multicast homogeneous (i.e. one agent from the platform initiator sends 1 message to two agents in the platform responder) by using IIOP, String encoding and AgentCities Ping

-         Multicast heterogeneous (i.e. one agent from the platform initiator sends 1 message to three agents (two in the platform responder and 1 in the initiator)) by using IIOP, String encoding and AgentCities Ping

11   Feedback to FIPA

11.1       case-sensitiveness

All the specifications related to encoding/decoding should clearly specify that parsing is case-insensitive. In particular, the following FIPA specs have been identified:

• MTS for what regard the message envelope, included all the MTP specs: IIOP MTP, HTTP MTP, and WAP MTP;
• ACLEncoding for what regard the name of the ACL slots and their value: String ACLCodec, bit-efficient ACLCodec, XML ACLCodec;
• Content language encoding: SL, RDF, CCL, KIF;
• Ontologies: fipa-agent-management, …

11.2    apDescription

In the Management specs, the APDescription is defined ambiguously. In fact, it is necessary that FIPA specifies the reserved values for all the names of the MTPs currently defined (e.g. “fipa.mtp.iiop”, “fipa.mtp.http”, “fipa.mtp.wap”). Also FIPA should unambiguously define how different addresses for the same MTP must be arranged (e.g. if there are 2 IIOP addresses for the same MTP, should they belong to just 1 MTPDescription or to 2?). Also, FIPA should define for each MTP the format of the valid URLs (i.e. addresses) for that MTP or, at least, it should point to the correct external specs (e.g. OMG for IIOP URLs).

11.3    constants and reserved values

The constants that identify the MTPs, the Interaction Protocols, the content languages, and the ontologies should be published somewhere and simple to browse. In particular, the constants that identify the Interaction Protocols are not defined in any FIPA specs (probably they were defined in the library of IPs, that is now obsolete probably)

11.4    http MTP

HTTP MTP. This MTP is synchronous while the IIOP MTP is asynchronous. That contradicts the MTP abstraction of FIPA.    
A sender agent is blocked forever if a malicious receiver does not send back the HTTP response code or if it does not flush and close the socket. That works for the browser paradigm but it does not apply for the agent communication. Even if at the implementation-level something can be done to avoid the problem.    
However, we suggest FIPA should clarify if the communication model is asynchronous MTP or synchronous MTP. Some options have been identified:

o       remove the oneway attribute of the IIOP IDL interface and make the MTP synchronous ;

o       change the specs of the HTTP MTP such that it becomes asynchronous (not simple to do, given that HTTP is a synchronous protocol)

o       change the specs of the HTTP MTP by adding a timeout to wait for (this is not really an elegant solution)

o       clarify this problem in the HTTP MTP specs and invite implementations to take care of it.

o       In all the cases, it is important that FIPA specifies that the communication must be perceived by agents as asynchronous (i.e. they are not blocked until the message is actually delivered) even if the MTP was synchronous.

11.5    Bootstrapping problem

11.5.1   Proposal to FIPA

-         FIPA Agent Management Specs.

o       clarify what an hap is (i.e. it must be unique and it is exactly the value of the slot :name of the APDescription)

o       clarify that the slot name of the AID of the AMS MUST be composed as AMS@hap and that hap is a unique identifier of the platform

o       the names of the other agents can be searched with the AMS

-         MTS specs

-         IIOP MTP specs

o       a valid address for the AID of the AMS MUST either contain a persistent IOR, or a persistent location (i.e. corbaloc or corbaname)

o       include the syntax for the URI of these MTPs

-         HTTP MTP specs

o       a valid address for the AID of the AMS MUST be a unique URL (i.e. it is restricted just to the HTTP protocol in the protocol part of the URL syntax)

-         WAP MTP specs

o       TC Gateways is invited to propose

-         Recommendation

o       one or more AMS AIDs can be provided when bootstrapping a platform.

11.5.2   Discussion

Definition: How to discover a remote Agent Platform at run-time, i.e. how to exchange AP Descriptions

Requirements:

Proposals:

-         P1: publish the APDescription  onto a URI. The content of the URI should be a String-encoded APDescription

-         P2: have a front-end of the platform  with a persistent address

-         P3: use an MTP-dependent naming system. For IIOP it would be the CORBA Naming Service

-         P4: LDAP-based

-         P5: a-la gnutella solution

Requirements of the solution:

-         start with one solution which scales and goes through firewalls

-         should allow discovering a network of APs

-         should work also in presence of failure of nodes

-         topology must be configurable and manageable

-         should minimize effort

-         use DNS

-         should allow to build a software tool that makes human-browsable the network of APs

-         should work for current FIPA specs

Ion’s issue about a list of remote platforms. An example scenario is the following:

-         platform P1 knows the AID of the AMS of platform P2.

-         P1 (actually any agent of P1) sends a getAPDescription to the AMS of P2.

-         P1 sends a search to the AMS of P2. From the result, it can discover the AID of the DF of P2

-         P1 can then send a search to the DF of P2 and discover in this way all the registered platforms (if any).

11.6    Failures at the transport level

The current FIPA specs no. 67 “MTP Service” states that:

-          […] An ACC is only required to read the message envelope; it is not required to parse the message body. In performing message transfer tasks, the ACC may be required to obtain information from the AMS or DF on its own AP. […]

-          Error and confirmation messages sent to a sending agent by the MTS are in the form of ACL messages over the MTS. These MTS information messages are sent on behalf of the AMS agent responsible (the :sender parameter of the message must be set the local AMS’s AID) of the ACC's AP. How the message is generated (whether by the AMS or by the ACC on behalf of the AMS) is not specified by FIPA. If an error message needs to be returned, the message generated must follow the exception model defined [FIPA00023] such that:

· The communicative act is a failure,

· The predicate symbol is internal-error, and,

· The argument parameter is a string describing the error, which occurred (the form and content of which is not defined here).

The problem:

• The MTS must work at the ACL level of abstraction in order to convey failure messages, OR the AMS must be involved in generation of message delivery failure messages
• The MTS/ACC must look at contents of ACL message to determine if it is a failure message (failure messages will probably need to be treated as a special case of message by the MTS & the sending agent e.g. - we don't want an endless chain of "failure" message occurring just because one message fails and the sender is no longer reachable!) - this involves introducing unnecessary parsing/intelligence into the MTS/ACC 
• How does an Agent distinguish between a "failure" message during a conversation with a given AMS and a "failure" of a message delivered to that AMS which appears to be from that AMS, given that the AMS could send a failure message that complies with FIPA00023 with the same error message during a normal conversation?

Proposed solutions:

1. Introduce a "failure reason/status" field in the envelope of messages, which if present indicates that the message associated with the envelope was undeliverable.  The ACL part of the message would be identical to the ACL message sent by the sending Agent.  The ACC / MTS that determines the message is undeliverable simply has to set the intended-receiver field of the envelope to the sender of the message in order to back-propagate the delivery-failure information.
2. Introduce an error flag in the envelope of the message but its content remains a failure like FIPA already specified. This error flag prevents infinite loops (e.g. replying with a failure if that was a failure already).

Final agreed solution:

-         Add an error-reason slot in the Envelope. The type of this slot is a String which indicates the error type. The slot must only be used for failure messages.

-         All MTSs should send an Envelope with error-reason when they detect a failure to deliver the message. The payload of the Envelope is the sent message. The intended-receiver of the Envelope must be set to the original sender of the message.

-         All MTSs that receive an Envelope with the error-reason slot set, and the intended-receiver is a local agent, will notify that agent that the message delivery has failed. This notification must be done by sending a FAILURE ACL message, as already specified by FIPA. How this is done (i.e. via the AMS, or directly by the MTP, …) is implementation-dependent. This FAILURE message should have set the conversation-id and in-reply-to in the right way.

-         Platforms can provide explicit APIs that prevent local agents from receiving these FAILURE messages.

-         Furthermore, agents would benefit from the MTP description defined by FIPA being extended with QoS parameters.

11.7    Interaction Protocols & timeout handling

We suggest FIPA to improve its specs by clarifying the following issues:

-         all ACLMessages in an Interaction Protocol should have a non-null conversation-id

-         all responses to that message in the scope of that IP should have the same conversation-id value

-         recommend (but not mandate) to use unique values for this conversation-id for instance by using the slot name of the sender AID

-         the timeout value in the reply-by slot of an ACLMessage within the scope of an Interaction Protocol refers to when the next message in the protocol flow should be received and not to when the IP should terminate

-         a Frame representing Interaction Protocols and their attributes (e.g. deadlines to terminate the protocol, …) should be defined by FIPA

12   General conclusions

-         the FIPA specs that have been tested in these 5 days are mature and allow commercial exploitation of multi-agent systems

-         the Agent Platforms that have participated are also mature

-         Bugs have been found, and in most cases, fixed on the agent platforms 

-         Bugs have been found, and solutions have been proposed, on the FIPA specs

o       they are minor bugs, easy to fix both from the FIPA specs point of view and from the implementation point of view

-         These tests have proved that FIPA specs enables interoperability between agent platforms but, in no way, they have proved compliance of the platforms to FIPA specs!

-         As an output of these tests, the following four Input documents to FIPA have been produced:

o       this report of the activity

o       the plain text log of the exchanged messages

o       a document with the list of identified problems in the FIPA specs and the proposed solutions

o       a Workplan for a FIPA-compliance test

§         in 2 meetings (8 days of work) we believe that we can bring to preliminary the tests on most of the FIPA specs (Agent Management, MTS, IIOP MTP, HTTP MTP, SL, ACLCodecs, Interaction Protocols, …) but serious commitment is needed from participants

-         A final demonstration have been given to FIPA members

o       Thursday at 16:00 in room 403 (4^th floor) just in front of the plenary room

-         General issues

o       a lot of effort has been devoted to this bake-off

§         Thanks to all the participants and all the people who participated at the discussions

o       all the platforms went very well

§         some platforms have a more strict view on the standard, others are more lenient

§         some platforms had support for these tests already integrated in their management tools, others needed some manual support

o       more interoperability tests are welcome but

§         the spirit of the FIPA interoperability tests should continue to be that of verifying and improving the FIPA specs and not fixing the bugs of the platforms!

We finally propose to FIPA to consider bringing the following specifications to the Standard status:

-         Agent Management specs

-         Message Transport Service

-         MTP for IIOP

-         MTP for HTTP

-         Agent Communication Language Parameters

-         String ACL Encoding

-         Bit-efficient ACL Encoding

-         FIPA-SLO content language

-         FIPA-Request Interaction Protocol

-         FIPA-Query Interaction Protocol