FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

 

 

                              Fabio Bellifemine                            Giovanni Rimassa

                          <bellifemine@cselt.it>                     <rimassa@ce.unipr.it>

 

This work plan has the objective of overcoming the limitations of the fipa.mts.mtp.iiop.std Message Transport Service, as currently defined by FIPA. It includes the description of the problem, a proposed solution, and a description of the expected milestones. Because of its simplicity, the plan is very narrowed in time and it is expected to conclude very fast.

 

Problem Statement:

1.       The FIPA specification of the fipa.mts.mtp.iiop.std MTP, as already declared in the specifications (see [FIPA00075]), does not allow the transmission of an ACL message that contains binary data. This is particularly unsuitable for wireless to non-wireless communication because the bit-efficient representation (see [FIPA00069]) cannot be transmitted over the IDL interface currently defined by FIPA. And, more in general, that makes unrealistic the usage of the FIPA MTP for industrial applications.

2.       The FIPA specification of the fipa.mts.mtp.iiop.std MTP also does not provide any support for multilingual characters, for instance Japanese.

        

The reason for these limitations is that, according to CORBA specs [CORBA 2.3, Sect. 3.2 page 3-3]: "OMG IDL uses the ASCII character set, except for string literals and character literals, which use the ISO Latin-1 (8859.1) character set." Therefore the CORBA specifications, and its implementations too, does not allow a string to contain characters outside the ISO Latin-1 set.

 

While the newer wstrings should address this issue, they are still not supported by various ORBs: from the omniORB mailing list, 10 March 2000: "omniORB does not yet support wstring. No version ever has." Furthermore, the wstrings type encodes char over 16 bytes, and it would double the size of every FIPA message, even those messages that use just the ASCII character set.

 

3.       Furthermore, by using the current fipa.mts.mtp.iiop.std specifications, a kind of mismatch problem results when the message content has a different encoding from the ACL encoding and the message becomes un-parsable.

 

In fact, in the fipa.acl.rep.string.std message encoding (see [FIPA00070]), for example, the message content should be delimited by matching parentheses. If the message content needs to be expressed by using an Unicode 16-bit character string, for instance, or a binary encoding, the ACL parser has no way to match the bounding parentheses and it cannot also parse the value of all those ACL parameters that follow the content.

 

Scope:

         The scope of the plan is limited to the specifications of a new FIPA Message Transport Protocol. In particular it is limited to the specifications of an improved IDL interface for the transport protocol already defined by FIPA, i.e. IIOP. The influence on the existing implementations is very limited in nature because it is constrained to just the IDL files.

 

Objective and generated specifications:

         The objective of this work plan is to remove the limitations of the current specifications.

Regarding the generated specifications, two options/solutions are available to FIPA:

1.             The first one, also preferred by the authors, is to replace the current fipa.mts.mtp.iiop.std specification with a new one able to overcome the reported problems, for instance the solution here proposed.

2.             The second option, technically worst, is to define a new MTP that is able to overcome the reported problems and leave agents, and their implementers, the freedom to choice the preferred MTP (even if one is worst than the other and both use the same transport protocol, i.e. IIOP).

 

         The final solution will be the result of the technical discussion in FIPA, but it is already expected and welcome input from the FAB. It must be noticed, however, that the work plan is necessary independently of the solution that will be selected.

 

Proposed technical solution:

Our proposal aims at sending any message encoding and any content encoding over fipa.mts.mtp.iiop.std MTP, fully exploiting IIOP structured data handling. So, we use a binary sequence<octet> as the ACL message body and a suitable IDL struct as the message envelope.

 

module FIPA {

 

  // No need for an URL struct, since it's only put in the

  // message envelope for informational purposes.

  typedef string URL;

 

  typedef sequence<string> strings;

 

  // From FIPA PC00023B spec. Sect. 6.1.1 page 12

  struct AgentID {

    string name;

    sequence<AgentID> addresses;

    sequence<AgentID> resolvers;

  };

 

  typedef sequence<AgentID> AgentIDs;

 

 

  // IDL struct to represent time.

  // Use ISO 8601. To check better ...

  struct DateTime {

    long dummy;

  };

 

 

  // From FIPA PC00024 spec. Sect. 5.1.2.3 page 7

  struct ReceivedObject {

    URL by;

    URL from;

    DateTime date;

    string id;

    string via;

  };

 

  // This supports the optional 'received' field of Envelope frame.

  // The sequence can be either empty (0 items) or full (1 item).

  typedef sequence<ReceivedObject, 1> ReceivedObjectOpt;

 

 

  // From FIPA PC00024 spec. Sect. 5.1.2.2 page 6

  struct Envelope {

    AgentIDs to;

    AgentID from;

    string comments;

    string aclRepresentation;

    string contentLength;

    string contentEncoding;

    DateTime aDate;

    strings encrypted;

    AgentIDs intendedReceiver;

    ReceivedObjectOpt received;

    // What is 'transport behaviour' ?

  };

 

 

  // This is needed to comply with PC 00024 spec. Sect. 5.1.3 page 7.

  // The above states that an ACC cannot overwrite message envelopes.

  typedef sequence<Envelope> Envelopes;

 

  // A binary message body can represent any of 'fipa-string-std',

  // 'fipa-bitefficient-std' and 'fipa-xml-std'

  typedef sequence<octet> Payload;

 

  interface MTS {

    oneway void message(in Envelopes messageEnvelopes, in Payload

messageBody);

  };

 

};

 

A problem to address, in order to map the abstract envelope syntax in [FIPA00067] onto an IDL struct, is the handling of optional slots. Looking at the frames 'envelope', 'received-object' and 'agent-identifier' we found the following cases:

1.       The optional slot is a String: then, the IDL struct will have a string member. If the slot is not present, an empty string will be used ("").

2.       The optional slot is a sequence of something; then, the IDL struct will have a sequence <something> member. If the slot is not present, the sequence will be empty.

3.       The optional slot is a sub-frame of type T; then, the IDL struct will have a sequence <T,1> member. If the slot is not present, the bounded sequence will be empty.

 

Notice that point 3 happens in just a single case: envelope -> received-object.

 

We think that our proposal can completely solve all problems associated with transmitting binary data over IIOP and will result in complete orthogonality of MTP and message encoding.

 

To solve the problem with, e.g, Japanese encoded content within a fipa.acl.rep.string.std encoded ACL, we propose to mandate the usage of the ByteLengthEncoded content whenever the content encoding is different from plain ASCII and the message encoding is fipa.acl.rep.string.std. This is necessary in order to make completely opaque the message encoding to the MTP as well as the content encoding to the ACL parser.

 

The following modifications needed to [FIPA00067]. Due to the separation between abstract and concrete syntax, only small modifications will be required. These are detailed below:

 

1.       Removal of comments and footnotes about fipa.mts.mtp.iiop.std and fipa.acl.rep.string.std incompatibility.

2.       Replacement of the old IDL interface with the newer one.

3.       Addition of "for fipa.mts.mtp.iiop.std MTP" at the end of section 7.1.2.

4.       Replacement of "Normative Annex A: Concrete Message Envelope Syntax" with "Normative Annex B: Concrete Message Envelope Syntax for fipa.mts.mtp.wap.std MTP".

5.       Moving Section 10 to Section 11 with the title: "Normative Annex B: Concrete Message Envelope Syntax for fipa.mts.mtp.wap.std MTP".

6.       Addition of a new Section 10 with the title: "Normative Annex A: Concrete Message Envelope Syntax for fipa.mts.mtp.iiop.std MTP". In the new Section 10, the IDL data structure used to represent an ACL message envelope will be described and the actual IDL for them will be given. So, with our proposal, the message envelope will have a different concrete syntax for every MTP and we're keeping the current one for fipa-wap-std.

 

Moreover, a synchronization with TC-E will be needed. [FIPA00066] uses an extended IDL interface with both message()(fipa.acl.rep.string.std) and bin_message()(fipa.acl.rep.bitefficient.std). With the new IDL interface, this won't be needed anymore. The content-encoding issue should be addressed also in the fipa.acl.rep.bitefficient.std case (maybe it's already supported, I don't know).

 

 

Plan for Work and Milestones:

·         Between now and Baltimore meeting: discussion about the problem on the FIPA management reflector.

·         2000/07, Baltimore meeting: One day meeting to analyse the proposed technical solution. If the solution it is accepted, the specifications will be submitted to FAB for experimental at the end of the Baltimore meeting. Otherwise, other technical solutions will be evaluated via e-mail discussion and the final agreed solution will be submitted to FAB at the end of August.

·         One month after the submission to FAB: FAB should decide if this solution should replace and make obsolete the current fipa.mts.mtp.iiop.std specification or be an alternative to it.

·         2000/09 Experimental  specifications.

 

The project plan will be reviewed and revised, if and when necessary.

 

Future Work:

 

Dependencies:

·   [FIPA00066] FIPA Nomadic Application Support Overview Specification. There is a minor dependency this specification because they should remove an interface that was defined ad-hoc to partially overcome the reported problems.

·   [FIPA00075] FIPA Agent Message Transport Protocol for IIOP. There is a clear dependency with the existing fipa.mts.mtp.iiop.std specification.

·   [FIPA00070] FIPA ACL Message Representation in String Specification. There is also a minor dependency this specification because it should mandate the usage of the ByteLengthEncodedString when the content is encoded with a different encoding.

 

Support:

·         Fabio Bellifemine, CSELT

·         Giovanni Rimassa, University of Parma

·         Phil Buckle, Nortel Networks

 

FAB Comments:

This work plan has been approved and has been assigned to the Transport Working Group.