| Document title: | FAB Open Plenary Discussion, Sendai 2001 | ||
| Document number: | f-out-00095 | Document source: | FIPA Architecture Board |
| Document status: | Input | Date of this status: | 2001/07/26 |
| Change history: | |||
| 2001/07/26 | Initial draft | ||
This is an official document of FIPA, the Foundation for Intelligent Physical Agents. Information about FIPA and FIPA documents, including copyright notices, may be found on the world-wide web at http://www.fipa.org/.
This document summarises the open discussion that the FIPA Architecture Board help at the Sendai, 2001 meeting to address a number of issues raised since the London meeting in April, 2001. These issues can be summarised as:
The FAB invites comments and improvements to the contents of this document.
Most standards are moving to UNICODE 3.1 and ISO 2022 and the case mappings are specific to the encoding; case mapping tables are required to make the specifications case insensitive. Therefore, it seems that this proposal should be rejected, as the to-lower function might need a large set of case mapping tables to be realized in some representations.
FAB Summary
Disapprove with comments: state in the necessary specifications that the defined terminals and constants are case-specific.
Multiple addresses should belong to the same MTP Description.
FAB Summary
Approve.
Should be publicized and accessible through agents. In particular there should be a hierarchy of name spaces. FAB agrees, but goes not have a process to do it. Is fine if the Bake-off group takes care of it?
FAB Summary
Approve with comments: but invite an email discussion on how this could be achieved.
Use the close-connection attribute of HTTP to force the receiver to close the connection after communication. These recommendations might have severe performance implications. This is a point-wise solution for aligning the HTTP and IIOP MTPs. Why should be trying to normalise each of the MTPs if they have their own attributes, QoS…?
FAB Summary
Approve with comments: this can be fixed in the HTTP specs, but the FAB asks the Bake-off Group if it recommending that all MTPs are asynchronous?
The name of an agent was unique in FIPA97, but name could be split along the '@' boundary to find out the real name and the HAP. In FIPA2000, the name slot should be unique as well but it cannot be split, that it, it is an atomic entity.
FAB Summary
Disapprove with comments: suggest in an informative annex (or Developer's Guide) on how to generate a unique name for an agent (fixed, stochastic, ...).
IIOP MTP; HTTP MTP; WAP MTP: need to point to the construction of an address IAD.
FAB Summary
Approve.
The platform is not a physical entity within the specifications, so it does not make sense to 'start' it with an AID of an AMS.
FAB Summary
Disapprove with comments: platform-level bootstrapping is an implementation issues since each platform has a different mechanism.
How the MTS delivers a failure to an agent is implementation-specific and should not be specified at the ACL level.
FAB Summary
Disapprove.
Should FIPA define QoS parameters?
FAB Summary
Approve with comments: FIPA00014 defines some QoS parameters for wireless devices and the FAB invites the Bake-off Group to investigate if this is sufficient.
Conversation IDs should identify the scope of a conversation.
FAB Summary
Approve.
A timeout specified in an ACL message should refer to the next message.
FAB Summary
Approve.
FAB Summary
Disapprove with comments: The point of this was not clear - can the Bake-off Group illustrate this with an example?
Does experimental status needs conformance tests? The Bake-off Group identified the following specifications to be proposed as standard:
FIPA00008 SL Content Language (only the SL0 part of this specification)
FIPA00023 Agent Management
FIPA00026 Request Interaction Protocol
FIPA00027 Query Interaction Protocol
FIPA00061 ACL Message Structure
FIPA00067 Message Transport Service
FIPA00069 Bit-efficient ACL Encoding
FIPA00070 String ACL Encoding
FIPA00075 MTP for IIOP
FIPA00084 MTP for HTTP
TC gateways proposes to amend the FIPA00067 before it is proposed to be promoted to Standard.
Promotion to Standard level does not require a compliance test; it requires at least two implementations, as stated in the FIPA procedures. The FAB or TC chairs can propose a specification to become a Standard and this is then submitted to the membership.
Should we require test kits for FIPA as part of the specifications? It could be useful to define the precise terms in the specifications for compliance (MUST, SHALL, COULD, ...) and this should be linked with formal verification mechanisms.
FAB Summary
These specifications are not ready to propose to Standard status until the outstanding issues raised by the Bake-off Group have been addressed.
The goal is to assess changes and allow updates and modifications between versions of the specifications. Once a specification moves beyond become Experimental, it becomes the responsibilities of the FAB and the FAB controls access to it.
FAB Summary
The discussion in the plenary session agreed that this was a suitable way to address minor changes to the specifications; larger and more complex changes might require a different mechanism. The FAB would like to remain open in how it addresses this issue but asks for this procedure to be used to propose changes in Experimental and Standard status specifications.
The procedure is summarised as follows:
1. Proposed changes submitted to the FAB
- Changes on a line-by-line basis, for example:
Page 13, Line 24: Change df-agent-desc to df-agent-description
Page 24, Line 2: Added section 4.2.1. on Name Resolution
- Changes must be analysed with regard to impact on other specifications
- Changes must be accompanied by a brief motivation
2. Changes are discussed
- Proposed changes are collated and emailed to announce@fipa.org one month before the next meeting
- An open FAB plenary session is held at the next meeting to discuss the changes
- Each change is either Approved, Approved with Comments or Disapproved with Comments
3. For approved changes
- The FAB appoints an editor and sends the appropriate Word documents to the editor
- The editor makes changes using ‘Track Changes’ feature of Word and submits the modified Word documents back to the FAB when the changes have been made
- The FAB ensures only the approved modifications have been made
4. Changes are made available by the FAB
- ChangeLog details are added as an annex to the specification, for example:
Annex A - ChangeLog
A.1 2001/07/22 version A, by FIPA Agreements Management TC
Page 1: Changed all references of df-agent-desc to df-agent-description
Page 36, Line 45: Changed the registration protocol of the DF to AMS request protocol
A.2 2001/07/27 version B by FIPA Gateways TC
Page 32, Line 5: Rewrote this paragraph to be clearer
- FAB generates new versions of the changed specifications and uploads them to the FIPA Web site
- New versions are announced on announce@fipa.org and chat@fipa.org