[bfcpbis] RFC4582bis: What is the transaction model behind Error/ErrorAck?

["Horvath, Ernst" <[e-mail]>]

Hi,

I have a problem understanding the use of ErrorAck.

For unreliable transport RFC4582bis describes two transaction types:

1) Client-initiated: A client (chair or participant) sends a request to the server and receives a Status or an Error message back; the client runs T1 and retransmits the request if no response arrives in time, but the server does not run T1 and does not retransmit the response (Status or Error) unless triggered by receipt of a retransmitted request. The client does not send a StatusAck for the response.

2) Server-initiated: The server sends a notification (i.e. a follow-up status message) to the client and receives a StatusAck back. The server runs T1 and retransmits the notification if no StatusAck arrives, but the client does not retransmit the StatusAck unless triggered by a retransmitted notification. 
(Question: Can the client send an Error message instead of StatusAck? Error seems to be reserved for the direction server to client, but the draft is not 100% clear about that.)

Now, how does ErrorAck fit in? Error is the backward message in a two-step (request/reponse) transaction model, and BFCPbis did not introduce a three-step (request/response/ack) model, right? Or can Error be used as a transaction-initiating request, with ErrorAck forming the response? If so, this is currently not described.

Regards,
Ernst Horvath