Introduction

An interoperability test has been performed during the FIPA meeting since Sunday 1^st April, 10:30 to Thursday 5^th April 19:00 with the following 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

The main goal was to test the FIPA specifications by proving the interoperability of the platforms. As described in the companion document Minutes and report of the activity the goal has been successfully achieved.

As a result, a list of minor issues have been identified in the FIPA specs, and detailed in the following section, where ambiguity or effectiveness should be improved.

Feedback to FIPA

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, …

apDescription

In the Management specs, the APDescription is defined ambiguously. Infact, 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).

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)

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 to 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 synchronous the MTP;

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.

Bootstrapping problem

-         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.

Failures at the transport level

-         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.

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

Conclusion

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