Rationale for New Messages
-
JATLite intended as a standard infrastructure
- Agent Message Router (AMR) needs standards for connecting
- Part of the standards are based on JATLite
Assumptions
- Other standards are adminstrative semantics
- These should be standard KQML messages
- Content standardization should be minimized
in favor of message standardization
These ideas are under discussion.
Proposed New Messages
(in outline only)
REGISTER-AGENT
sender: <agent> receiver: <ANS/AMR>
<agent-name> [<password>]
<contact-information>
The contact information would include subfields:
<TCP/IP address> <UDP address>
<URL> <local ANS/AMR IP address>
<owner email address>
Used after a connection has been made
to the ANS or AMR to establish the agent
as one publically available on this ANS/AMR.
An alternative is to omit the contact information here
but have the ANS/AMR use IDENTIFY-SELF and WHOIAM
to get this information.
LIST-AGENTS
sender: <agent> receiver: <ANS/AMR>
No fields
Request for all agents listed with the ANS/AMR.
REGISTERED-AGENTS
sender: <ANS/AMR> receiver: <agent>
List-of <agent-name> <TCP/IP address> <connection-status>
Response to request LIST-AGENT - a list of
all currently registered agents.
IDENTIFY-SELF
sender: <agent-1> receiver: <agent-2>
No fields
Request to know something about the agent-2.
WHOIAM
sender: <agent-2> receiver: <agent-1>
<agent-name> <contact-information>
<Message-method> <KQML-extensions>
<description>
The message-method is undefined,
as in my email about this.
And the KQML-extensions can just be a URL.
The description is also undefined. Possibly KIF.
The intent is captured in the CAPABILITIES
section of my email. Possibly description should
have subfields:
<text> <KIF><Advertisements>
REQUEST-ADDRESS
sender: <agent> receiver: <ANS/AMR>
<agent-name>
Request to know the TCP/IP address of the agent named.
Needed for an ANS only connection mode.
AGENT-ADDRESS
sender: <ANS/AMR> receiver: <agent>
<agent-name> <TCP/IP address>
Reply to the request for address.
DISCONNECT-AGENT
sender: <agent> receiver: <ANS/AMR>
No fields
Notify of temporary unavailability.
(Timeout has the effect of this message.)
RECONNECT-AGENT
sender: <agent> receiver: <ANS/AMR>
[<password>] [<new-TCP/IP address>]
Notify restored availability. An AMR
will then forward all stored messages.
This is also one way to change an IP.
The password is used here to insure
the identity of the agent, as an option.
UNREGISTER-AGENT
sender: <agent> receiver: <ANS/AMR>
[<password>]
This agent is no longer available
and messages may be discarded.
Some of these should have a content and language
fields and perhaps more - this is the gist of
the new administrative performatives.