>
>
> I don't get error on ack at all. If I receive an
> acknowledgment message, and for whatever reason cannot
> process it (let's say it was mangled in transit)
> then I'll simply resend the original message
> until I get an ack, or until either the message's TTL
> expires or the retries have been exhausted at which
> time I'll notify the application that I have not
> received an acknowledgment confirming the message's
> receipt by the intended recipient.
Acks can now also be used for Non-repudiation of receipt. This means that if
the ds:References are not included or it is not signed and the CPA says it
was suppose to be than this is an ERROR of inconsistent. Waiting for the
retry doesn't solve the error.
>
> As for ack on error, why on earth cannot an error
> be treated with all of the same QoS as a normal
> message?!?!? What if the recipient wants to be sure that
> the original sender is notified that there has been
> a problem in processing the message? Seems perfectly
> reasonable to me to allow this.
I look at this another way, since errors (in general) are generated by the
MSH in response to a message they are not a reliably sent message any more
than we would make "acks" be resent automatically. The error is in response
to a message. If the sending MSH sends the message again, we would error
again, not the other way. This is in contrast to continually sending an
error for a message we received that was in error.
>
> The circularity comes only (IMO) when you error on
> an acknowledgment because this would require that
> the sender of the acknowledgment provide for the
> ability to process the error (as well as for specification
> as to what processing is required which is currently
> not addressed in the specification).
>
> IMO, the only thing that the spec should say is that
> an ack cannot be requested for an acknowledgment message.
>
> Cheers,
>
> Chris
>
>
> Cliff Collins wrote:
>
> > I like Error on Ack (like the 1.0 model) the best.
> >
> > If we allow Ack on Error then it becomes really messy when there is a
> > failure on the Ack message. And when the retries are reached on
> sending an
> > "error" over RM does this generate another error of delivery
> failure? Messy
> > :-)
> >
> >
> >>