id	Spec name	Spec no.	Contact Point	Date	Note (see also minutes of the discussions)
58	SL		Stephan Cranefield	23/7/2002 13/10/2002	Semantics of constructor
59	all	all	Stephan Cranefield	24/7/2002	A4 and Letter format
60	Agent Management		Marian Nodine	31/7/2002	question about AMS spec
61	all		Nicolas Lhiullier	16/9/2002	list the changes needed to a FIPA2000 platform
62	FIPA ACL		Jonathan Dale	17/9/2002	cancel ca
63	Qos		Heikki Helin	30/09/2002
64	SL		Stephan Cranefield	7/10/2002	distinction between IRE and Terms in SL
65	ACL	37	Stephan Cranefield	7/10/2002	proxy and propagate
66	severals		Mariusz Nowostawski	7/10/2002	notion of agent-identifier
67	ACL	37	Stephan Cranefield	7/10/2002	content of cfp
68	Agent Management		Nicolas Lhiullier	7/10/2002	search action
pending from Helsinki
10.4.1	HTTP		Ion Constantinescu	21/1/2002	recommend a well-known port for FIPA HTTP MTP (see also comment of Simon Thompson)
38	SL		David Bonnefoy, Fabio Bellifemine		ambiguity in SL Encoder
56	AMS lease-time	23	Fabio	24/7/2002	kept pending until next meeting
57	AMS federation	23	Fabio	24/7/2002	kept pending until next meeting
53	name space
other input, eventually received during this meeting

3 Pending Issues from Vancouver’s resolutions

- recommend FAB to produce a guideline document for maintenance of the specifications and publish it on the public area of the Web site (see for instance the doc. no. 61 and doc. no. 37 and doc. no. 25). FAB reply: PENDING

- recommend FIPA to produce and approve a document with the list of all the symbols defined by FIPA and a pointer to the specification number where they have been defined and where they have been used. If FIPA approves that, than X2S will consider to produce it in Helsinki (if there will be enough volunteers to do that!). FAB reply: PENDING because of namespace proposal.

4 X2S Agenda for this week

- Monday

o 14:00 – 15:30

§ ACL & ACL Message Structure (62, 65, 67)

o 15:30 – 16:30

§ general (59, 61)

o 16:30 – 18:00

§ agent management & architecture (60, 66, 68, 10.4.1, 56, 57)

- Tuesday 14:00 – 18:00

o Interaction Protocols

o content languages (58, 64, 38)

o Name Space (53)

- Wednesday 9:00 – 12:30

o QoS (63) -> afternoon

o editing session

- Thursday 10:00 – 12:30

o session with FAB and BoD to finalize all the formal aspects, in particular:

§ the formal approval of specs by FAB

§ editing period

§ grouping of specs

o organization of vote and the vote process

- Friday 9:00 – 12:30

o editing session

o approval of X2S resolutions

5 List of participants

Name	Company	Ma	Ta	Wm	Wa	Thm
Fabio Bellifemine	TILAB	X	X	X	X	X
Frank Mc Cabe	Fujitsu	X
Farooq Ahmad	Comtec	X
Heikki Helin	Sonera				X	X
Heimo Laamanen	Sonera				X	X
Hiroki Suguri	Comtec	X	X	X	X	X
Jeremy Pitt	Imperial College of London
Jim Odell	James Odell Associates		X
Jonathan Dale	Fujitsu	X	X	X		X
Makoto Okada	Fujitsu	X
Michael Berger	Siemens
Mike Kerstetter	Boeing
Misty Nodine	Telcordia		X
Monique Calisti	Whitestein		X
Tim Finin	UMBC	X
Bobbin TeeGarden		X
Margaret Lyell	MITRE	X				X
Ingo f. Timm	Technischol Universitat Ilmenau	X
Stefan Poslad	Queen Mary					X

LEGEND:

- Ma - the Monday afternoon session

- Ta is Tuesday afternoon session

- Wm is the Wednesday morning session

- Thm is the Thursday afternoon session

6 Discussion

Monday

62, cancel communicative act

Agreed. The footnote has been slightly modified.

65, proxy and propagate act, self symbol

Defining a standard ‘self’ symbol has not been considered necessary.

The example provided in the comment can be solved by, for instance, the following content:

(PROPAGATE

:sender S

:receiver R1

:content “( (all ?x (friend-of R1 ?x) (MESSAGE) )”

)

However, because the interpretation of the referential expression might change if evaluated by S or by R1, a note has been added in specification 61 about how the message content should be interpreted.

67, content of cfp

Agreed and corrected. It was just an editorial mistake in Helsinki.

59, A4 and letter format

agreed. The PDF files will be generated in a format that is printable both for US letter and A4.

61. list modifications that need to be done to existing implementations

All documents include the summary of changes to the specs, in bold font are the changes that we believe might impact existing implementations. However, explicitly listing the modifications to the implementation is not possible because it depends on the implementation.

60. Question about AID

Added a reference in Agent Management to section 3.3.7 about handling of multiple addresses.

66, notion of AID

Not approved.

Agent Management specs says “This notion of identity is the Agent Identifier (AID) that labels an agent so that it may be distinguished unambiguously within the Agent Universe.” The notion of AID defined in the Agent Management specs maps to the agent-name + transport-addresses of Abstract Architecture. Therefore its usage as a sender/receiver attribute is consistent with FAA.

68, object-description-template

Agreed. Corrected the Agent Management specs.

10.4.1 Defining a single port number for HTTP

It would be nice to have a standard way to identify a platform of a given company (e.g. http://fujitsu.com:80/acc) but that requires FIPA to define a standard URL including both a port number and a target.

The best port number for HTTP is surely 80 that is already open by most firewalls.

What is the best target for FIPA? org.fipa.acc DELAYED THE DISCUSSION AFTER THE NAMESPACE ISSUE. The best target is fipa.mts

Should we define that? Yes because it adds value to FIPA as simplifies dynamic discovery of platforms. Recommending but not mandating, i.e. a platform that is not using the recommended values is still compliant with FIPA specs.

Therefore the default URL for a FIPA platform is http://<company domain name>:80/fipa.mts

56. AMS lease-time

It is not clear how much overhead this feature might introduce in existing agent platforms. It is not clear also which policy should be defined such that an AMS can detect that an agent is died even before the lease-time expires.

Considered that this is an extra-feature and that it has impact on the core of agent platforms and that there is no time to evaluate this impact before going to vote, it has been decided to not add this feature in current specs.

Eventually, version 2 might include this new feature.

57. AMS federation

Same as 56 applies.

Tuesday

Interaction Protocols

Added a section with meta-policy about not-understanding a communicative act and canceling an interaction.

Reviewed all documents.

The following documents are approved to go to standard: 26,27,28,29,30, 33, 34, 35, 36.

Wednesday

58, Semantics of constructors in SL

This comment contains several interesting issues and proposals however it is not fully clear the implications that it might have on, for instance, the consistency of the specifications.

issue 2.1, 2.6

In particular, adding a new grammar rule to encode propositions, i.e.

AtomicFormula = "(" PredicateSymbol Parameter+ ")"

creates an ambiguity in the encoder that needs to decide for each predicate if this new rule should be used (i.e. (Person :name “Stephen”) ) or the existing rule should be used (i.e. (Person “Stephen”))

AtomicFormula = "(" PredicateSymbol Term+ ")"

The proposal does not include a valid algorithm to make this decision in the encoder.

issue 2.2, 2.3, 2.4

A convenient object-oriented form of identifying expression that can be used with the current specs is (iota ?x (= ?x (Person :name “Stephen”) ). A new abbreviated form is not considered necessary.

X2S invites the authors of this proposal to participate to FIPA meetings and present the proposal for an eventual new enhanced version of the standard.

64, Distinction between IRE and Terms

proposal 1. approved

proposal 2. approved.

proposal 3. approved.

38, ambiguity in encoding FunctionalTerms in SL

Fixed the problem by adding a note in section 3.6 of SL specs, and in section 6 of agent-management specs.

Thursday

53, name space

Agreed that ‘fipa’ is the name space to be registered. Secretariat is doing that by using the form prepared by Steve.

3 alternatives:

1. Programmers must use the canonical form for all the symbols, i.e. urn:fipa:acl:performative:inform

2. Programmers can use both the canonical form and the short form, i.e. inform, but because you do not know what the sender is using, that means that the receiver must be able to handle also the canonical form

3. Programmers must use just the short form

Alternative 3 has been agreed. Which means that the name space definition serves just as a glossary of symbols and where they have been defined.

Questions:

What is the form of the new documents that we have to produce with the glossary of symbols?
What changes should we make to the existing documents?
What are the implications for the programmers and the existing implementations?

Answers:

(a)There is a document which contains a name space hierarchy which partitions the symbol space for FIPA. (b)There is a document which contains a name space hierarchy which partitions the technology groundings for FIPA. Probably (a) and (b) will be a single document.
For (a) we need to add all name space definitions to each specification, i.e. we just add the name spaces to the name space field in the specs. The symbols do not change. For (b) we do nothing to the specs.
None because the symbols do not change.

Conclusion:

Because this new document has no pragmatic effect both on the existing document and the existing implementations and because a big number of concerns has been raised during the meeting and no agreement was reached on them, the X2S decides to postpone this document to the next meeting.

Footnote: It was discussed and agreed that there were two namespaces (at least!) in FIPA; the first divided the symbol namespace (urn:fipa:acl:performative:inform) and the second divided the technology component name space (e.g. fipa.acl.rep.xml.std). Pragmatically, platforms are using the symbol namespace idea in the :ontology, :language and :protocol parameters of ACL (idea conformance) and using the technology component namespace idea in the :ap-description parameter (technology/platform conformance). Since it was agreed that X2S should have minimal interference with existing platforms, it was decided that this work should be passed as input to another, such as TC Compliance. The motivation for this is that the conformance point for a parameter such as :ontology is that it could be defined using three options: 1) component name (fipa-agent-management), 2) symbol name (fipa.acl.ontology.agent-management) and 3) technology grounding (fipa.agentmanagement.rep.xml.std). All three of these are namespaces, the first is from FIPA 97 and described a flat namespace, the other two are from FIPA 2000 and describe a hierarchical namespace. It is recommended that in the future, FIPA tries to define one common namespace, perhaps based on URNs or the existing namespace in FIPA00001.

7 SUMMARY OF CHANGES IN THE SPECS

23I	Agent Management – Fabio Bellifemine	- Page 13, line 566: Added a reference to section 3.3.6 of FIPA00067. - Page 13, line 576-578: added a note to explain the lease-time behaviour - Page 14, line 633: Added note on how to encode objects in SL. - Page 18, line 691: Added note on how to encode functions in SL.
37I	ACL – Fabio Bellifemine	- Page 6, line 202: Added a footnote about the usage of cancel to terminate the effect of a subscribe and request-whenever communicative act - Page 19, line 629: Modified object-description-template into ams-agent-description/df-agent-description
61F	ACL Message Structure – Fabio Bellifemine	Page 4, line 149 : specified that the content is intended to be interpreted by the receiver
8H	SL – Fabio Bellifemine, Hiroki Suguri	- Entire document : Added new non-terminal symbol TermOrIE and replaced all occurences of Term with TermOrIE - Page 7, line 414,415 : Added note on interpretation of iota identifying expression - Page 8, line 424,425 : Added note on interpretation of iota identifying expression - Page 9, line 508,509 : Added note on interpretation of any identifying expression - Page 9, line 518,530 : Improved the definition of any identifying expression - Page 9, line 534,535 : Improved the definition of any identifying expression - Page 10, line 596,597 : Added note on interpretation of all identifying expression - Page 12, line 668-675 : Added requirement on encoding functional terms. - Page 13, line 741 : Removed ambiguity in representing communicative acts in SL
84E	HTTP MTP, Fabio Bellifemine, Hiroki Suguri	- Page 9, line 330-332: Added note on recommended URL for HTTP-MTP

8 Resolutions

The X2S TC recommends FIPA to approve the following resolutions:

- recommend FIPA to publish the minutes of this X2S meeting and all the modified specifications in the public X2S area of the FIPA Web site for information to the entire community. All membership is invited to carefully consider all the approved changes that, in some cases, break compatibility of the existing implementations.

- recommend FIPA to publish as an output document of X2S the list of symbols defined in the specs

- recommend FIPA to apply IANA for registration of the ‘fipa’ name space

- recommend FAB to produce a guideline document for maintenance of the specifications and publish it on the public area of the Web site (see for instance the doc. no. 61 and doc. no. 37)

- recommend FIPA to publish the PDF files of all the specification documents in a format that is easy to print both on US Letter and A4 format.

- X2S has been through 3 iterations of accepting comments from the membership and improving the specifications. X2S now feels that the specifications are stable and ready for release. FAB has approved the specifications and therefore, X2S now asks the membership to approve these specifications for standard. X2S appoints Jonathanl Dale to finalize the documents (editorial changes and final ChangeLog table) by the 4^th November 2002 for release as the FIPA standards for 2002. The full list of specifications is the following:

Identifier	Title	Go to Standard
XC00001	FIPA Abstract Architecture Specification	Y
XC00007	FIPA Content Languages Specification	N => deprecated
XC00008	FIPA SL Content Language Specification	Y
XC00009	FIPA CCL Content Language Specification	keep in X, need more analysis
XC00010	FIPA KIF Content Language Specification	keep in X, need more analysis
XC00011	FIPA RDF Content Language Specification	keep in X, need more analysis
XC00014	FIPA Nomadic Application Support Specification	go to Informative output document
XC00023	FIPA Agent Management Specification	Y
XC00025	FIPA Interaction Protocol Library Specification	N => deprecated
XC00026	FIPA Request Interaction Protocol Specification	Y
XC00027	FIPA Query Interaction Protocol Specification	Y
XC00028	FIPA Request When Interaction Protocol Specification	Y
XC00029	FIPA Contract Net Interaction Protocol Specification	Y
XC00030	FIPA Iterated Contract Net Interaction Protocol Specification	Y
XC00031	FIPA English Auction Interaction Protocol Specification	keep in X, need more analysis
XC00032	FIPA Dutch Auction Interaction Protocol Specification	keep in X, need more analysis
XC00033	FIPA Brokering Interaction Protocol Specification	Y
XC00034	FIPA Recruiting Interaction Protocol Specification	Y
XC00035	FIPA Subscribe Interaction Protocol Specification	Y
XC00036	FIPA Propose Interaction Protocol Specification	Y
XC00037	FIPA Communicative Act Library Specification	Y
XC00061	FIPA ACL Message Structure Specification	Y
XC00067	FIPA Agent Message Transport Service Specification	Y
XC00069	FIPA ACL Message Representation in Bit-Efficient Specification	Y
XC00070	FIPA ACL Message Representation in String Specification	Y
XC00071	FIPA ACL Message Representation in XML Specification	Y
XC00075	FIPA Agent Message Transport Protocol for IIOP Specification	Y
XC00076	FIPA Agent Message Transport Protocol for WAP Specification	N => deprecated
XC00079	FIPA Agent Software Integration Specification	go to Informative output document
XC00080	FIPA Personal Travel Assistance Specification	go to Informative output document
XC00081	FIPA Audio-Visual Entertainment and Broadcasting Specification	go to Informative output document
XC00082	FIPA Network Management and Provisioning Specification	go to Informative output document
XC00083	FIPA Personal Assistant Specification	go to Informative output document
XC00084	FIPA Agent Message Transport Protocol for HTTP Specification	Y
XC00085	FIPA Agent Message Transport Envelope Representation in XML Specification	Y
XC00086	FIPA Ontology Service Specification	keep in X, need more analysis
XC00088	FIPA Agent Message Transport Envelope Representation in Bit Efficient Specification	Y
XC00091	FIPA Device Ontology Specification	go to Informative output document
XC00092	FIPA Message Buffering Service Specification	keep in X, need more analysis
XC00093	FIPA Messaging Interoperability Service Specification	keep in X, need more analysis
XC00094	FIPA QoS Specification	Y

Statistics:

Status	Number of Specs	Percentage / Total
I	7	17.07%
X	8	19.51%
D	3	7.32%
S	23	56.10%
S+I	30	73.17%
S+I+D	33	80.49%
ALL	41	100.00%

- thank all those people who have contributed to the meeting by sending comments or by actively participating to the discussion and, in particular, the editors of the documents: Jonathan Dale, Jim Odell, Misty Nodine, Heikki Helin, Hiroki Suguri.

- the X2S has concluded its mandate and met all the milestones of the workplan approved by FAB, therefore X2S asks the FAB and the BoD to dissolve this X2S TC.