Subject: Re: Washington Issue 14 - Errors when parsing

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 24 Nov 1999 13:59:23 -0500

Let's see....

You can send an error at the Transaction level:
message              = MegacopToken SLASH Version SEP mId SEP
                       ( errorDescriptor / transactionList )

The real question is whether we want to create some
explict TransactionError which could get you finer grain
isolation of the error.

I'd say no, this is one of those pretty fatal errors (the
initiator can't really recover from this kind of error
except in some way ignoring it, which has to be wrong).

Brian

> -----Original Message-----
> From: Prashant Jain [mailto:[email-masked]]
> Sent: Wednesday, November 24, 1999 1:35 PM
> To: [email-masked]
> Subject: Re: Washington Issue 14 - Errors when parsing
>
>
>
>
>
>
>
>
>
> Harpreet Singh Anand <[email-masked]> on 11/17/99 06:50:08 PM
>
> Please respond to [email-masked]
>
> To:   [email-masked]
> cc:    (bcc: Prashant Jain/HSS)
>
> Subject:  Re: Washington Issue 14 - Errors when parsing
>
> Even though we add new error codes in the errors list ,  ABNF
> grammar in v12
> does not allow MG or MGC to send error messages to the entity
> who has generated
> the Response,  if it finds error (Syntax or semantics) in a particular
> TransactionReply.
>
> Regards,
>
> Prashant Jain
>
>
>
>
> Hello Brian,
>
> What should be the action on receiving an indication of an error in
> TransactionReply ? Should the receiver continue other transactions or
> "disconnect" ?
>
> We can add one more error code:
>
> 545 - Syntax Error in Transaction Pending
>
> There can be other error conditions like, more command replies in
> TransactionReply then in the corresponding command request.
>
> Regards,
> Harpreet
>
> Brian Rosen wrote:
>
> >  Hello Brian,
> > >
> > > 1. Should the error messages be sent if there is a syntax error in
> > > TransactionReply ?
> > We clearly need new error messages for this
> >
> > > 2. If yes, then what should be the handling on receiving
> > > error message for a
> > > TransactionReply ?
> > These errors are pretty serious.  They indicate a programming
> > error (conceivably could be a provisioning error not caught
> > by someone's code).  It is unlikely that recovery is possible.
> > If you sent a syntax error once, you will do it again.
> >
> > > 3. If there is a semantic error in the TransactionReply, say the
> > > TransactionReply does not have all the command responses
> or say if the
> > > termination Id in the reply does not match the termination id
> > > in the command
> > > (considering the case when termination id is always sent in
> > > the reply), then
> > > what should the receiver of TransactionReply do ?
> > More new error messages
> >
> > > I feel on receiving a erroneous TransactionReply, the
> > > receiver should reject the
> > > reply (without sending any response message) and behave as if
> > > it did not receive
> > > any reply. That is, it would retransmit the Transaction
> after timeout.
> > That would be, IMO, a poor choice.  You have close to 100%
> > probability you would simply get the same reply, or you
> > would get a "illegal duplicate request" (yet another new message)
> >
> > Let' see, we have:
> > 540
>

---

From: Harpreet Singh Anand <[email-masked]>
Date: Thu, 25 Nov 1999 17:21:11 +0530

Hello Brian,

> except in some way ignoring it, which has to be wrong).

(1) I agree with you that error in TransactionReply is a fatal error and it will
be difficult to recover from this kind of error. So what are the various
possibilities of recovery:

a) the entity receiving erroneous TransactionReply sends back an error message.
This as you have pointed out above will not help.

b) an alternative can be that the entity can keep a count of the no. of times
such an error occurs and breaks the association  when the count exceeds a
particular threshold.

Chances of errors in TransactionReply should be rare (coding error or
configuration problem) but we should define some mechanism of dealing with it
when it occurs.

Please give your feedback.

(2) In one of the previous mails on this thread, you had mentioned the following
additional error codes:

540 – Syntax Error in Transaction Reply
541 – TransactionIDs in Reply do not match Request
542 - Missing command in Transaction Reply
543 - Illegal Duplicate Transaction Request
544 - Illegal Duplicate Transaction Reply

I am not sure of the usefulness of error codes 543 and 544.

When we have ALF/UDP, we can have cases of duplicate transaction request and
duplicate transaction reply and those shuld not be treated as errors.

In the first case (543), either a reply is resent or the transaction is ignored
(if ack for the receipt of reply has been recieved - concept of ResponseAck).

In the second case (544), one can not know that it is a duplicate
TransactionReply as the first TransactionReply would have closed the
transaction, at best it can be transaction reply for an unknown transaction id.
I suggest in such a case it would be better to ignore the reply rather than to
send an error message back.

Regards,
Harpreet