Notice

Use of the technologies described in this specification may infringe patents, copyrights or other intellectual property rights of FIPA Members and non-members. Nothing in this specification should be construed as granting permission to use any of the technologies described. Anyone planning to make use of technology covered by the intellectual property rights of others should first obtain permission from the holder(s) of the rights. FIPA strongly encourages anyone implementing any part of this specification to determine first whether part(s) sought to be implemented are covered by the intellectual property of others, and, if so, to obtain appropriate licenses or other permission from the holder(s) of such intellectual property prior to implementation. This specification is subject to change without notice. Neither FIPA nor any of its Members accept any responsibility whatsoever for damages or liability, direct or consequential, which may result from the use of this specification.

Summary

The action of accepting a previously submitted proposal to perform an action.

Message Content

A tuple consisting of an action expression denoting the action to be done, and a proposition giving the conditions of the agreement.

Description

accept-proposal is a general-purpose acceptance of a proposal that was previously submitted (typically through a propose act). The agent sending the acceptance informs the receiver that it intends that (at some point in the future) the receiving agent will perform the action, once the given precondition is, or becomes, true.

The proposition given as part of the acceptance indicates the preconditions that the agent is attaching to the acceptance. A typical use of this is to finalize the details of a deal in some protocol. For example, a previous offer to “hold a meeting anytime on Tuesday” might be accepted with an additional condition that the time of the meeting is 11.00.

Note for future extension: an agent may intend that an action become done without necessarily intending the precondition. For example, during negotiation about a given task, the negotiating parties may not unequivocally intend their opening bids: agent a may bid a price p as a precondition, but be prepared to accept price p'.

Formal Model

<i, accept-proposal (j, <j, act>, f))> º

  <i, inform (j, I_i Done (<j, act>, f))>

    FP: B_i a Ù ØBi (Bifj a Ú Uifj a)

    RE: Bj a

Where:

a = Ii Done (<j, act>, f)

Example

Agent i informs j that it accepts an offer from j to stream a given multimedia title to channel 19 when the customer is ready. Agent i will inform j of this fact when appropriate.

(accept-proposal

  :sender (agent-identifier :name i)

  :receiver (set (agent-identifier :name j))

  :in-reply-to bid089

  :content

    "((action (agent-identifier :name j)

      (stream-content movie1234 19))

     (B (agent-identifier :name j)

      (ready customer78)))"

  :language fipa-sl)

Summary

The action of agreeing to perform some action, possibly in the future.

Message Content

A tuple, consisting of an action expression denoting the action to be done, and a proposition giving the conditions of the agreement.

Description

agree is a general-purpose agreement to a previously submitted request to perform some action. The agent sending the agreement informs the receiver that it does intend to perform the action, but not until the given precondition is true.

The proposition given as part of the agree act indicates the qualifiers, if any, that the agent is attaching to the agreement. This might be used, for example, to inform the receiver when the agent will execute the action which it is agreeing to perform.

Pragmatic note: The precondition on the action being agreed to can include the perlocutionary effect of some other CA, such as an inform act. When the recipient of the agreement (for example, a contract manager) wants the agreed action to be performed, it should then bring about the precondition by performing the necessary CA. This mechanism can be used to ensure that the contractor defers performing the action until the manager is ready for the action to be done.

Formal Model

<i, agree (j, <i, act>, f))> º

  <i, inform (j, Ii Done (<i, act>, f))>

    FP: Bi a Ù ØBi (Bifj a Ú Uifj a)

    RE: Bj a

Where:

a = Ii Done(<i, act>, f)

Note that the formal difference between the semantics of agree and the semantics of accept-proposal rests on which agent is performing the action.

Example

Agent i requests j to deliver a box to a certain location; j answers that it agrees to the request but it has low priority.

(request

  :sender (agent-identifier :name i)

  :receiver (set (agent-identifier :name j))

  :content

    "((action (agent-identifier :name j)

     (deliver box017 (loc 12 19))))"

  :protocol fipa-request

  :language fipa-sl

  :reply-with order567)

(agree

  :sender (agent-identifier :name j)

  :receiver (set (agent-identifier :name i))

  :content

    "((action (agent-identifier :name j)

      (deliver box017 (loc 12 19)))

     (priority order567 low))"

  :in-reply-to order567

  :protocol fipa-request

  :language fipa-sl)

Summary

The action of one agent informing another agent that the first agent no longer has the intention that the second agent perform some action.

Message Content

An action expression denoting the action that is no longer intended.

Description

cancel allows an agent i to inform another agent j that i no longer intends that j perform a previously requested action. This is not the same as i informing j that i intends that j not perform the action or stop performing an action. cancel is simply used to let an agent know that another agent no longer has a particular intention. (In order for i to stop j from performing an action, i should request that j stop that action. Of course, nothing in the ACL semantics guarantees that j will actually stop performing the action; j is free to ignore I’s request.) Finally, note that the action that is the object of the act of cancellation should be believed by the sender to be ongoing or to be planned but not yet executed.

Formal Model

<i, cancel (j, a)> º[1]

  <i, disconfirm (j, Ii Done (a))>

    FP: ØIi Done (a) Ù Bi (Bj Ii Done (a) Ú Uj Ii Done (a))

    RE: Bj ØIi Done (a) 

cancel applies to any form of request action. Suppose an agent i has requested an agent j to perform some action a, possibly if some condition holds. This request has the effect of i informing j that i has an intention that j perform the action a. When i comes to drop its intention, it can inform j that it no longer has this intention with a disconfirm.

Example

Agent j asks i to cancel a previous request-whenever act by quoting the action.

(cancel

  :sender (agent-identifier :name j)

  :receiver (set (agent-identifier :name i))

  :content

    "((action (agent-identifier :name j)

     (request-whenever

       :sender (agent-identifier :name j)

       :receiver (set(agent-identifier :name i))

       :content[2]

         \"((action (agent-identifier :name i)

           (inform-ref

             :sender (agent-identifier :name i)

             :receiver (set (agent-identifier :name j))

             :content[3]

               \"((iota ?x

                   (=(price widget) ?x))\")

                   (> (price widget) 50))"

                   …)))"

  :langage fipa-sl

  …)