ork. Some of the implications The basic send operation should be unconfirmed i.e. the SAP user expects the CSP service to be reliable, and the remote SAP user to receive the messages uncorrupted in most cases. A confirmed send operation means that the CSP verifies to the sending SAP user that the remote SAP user has received the SDU. Considering possible delays and transmission errors in the CSP, there should exist a choice between a send operation that blocks the SAP user (synchronous operation) and non- blocking send operations (asynchronous operation). When the CSP receives an SDU at a SAP, it can store the SDU, until the SAP user asks for a new received SDU in a receive operation. The CSP delivers SDUs to the SAP user in the order they arrived, and the user must sort them in the order he wants to handle them. As an alternative, some type of selective receive might be used. When the SAP user requests a received SDU from the CSP, there might not be one. The question then is: should the CSP wait until an SDU arrives (which might block the communication between SAP-users), or should the CSP respond immediately to the user with "no new SDU received"? Both alternatives should be covered. Send and receive operations can also be polling or non-polling. For example. a non-polling send operation implies that the sending SAP user requests sending from the CSP, i.e. the sender is the initiating party in the SAP. A polling send 3 Logical Network Modelling operation implies that the CSP offers the SAP user to send an SDU, i.e. the CSP is the initiating party. The distinction between polling and non-polling opera- tions is not made in the operation name, but by the operation class. For example, a non-polling, unconfirmed send is called sendORDER. If it is a confirmed oper- ation it is a sendREQUEST. A polling, unconfirmed send is called sendOFFER. A polling, confirmed send is called sendINVITE. The naming conventions and the AML operation classification system is well suited to distinguishing between most commonly used send