Subject: Syntax Error handling

From: Harpreet Singh Anand <[email-masked]>
Date: Fri, 11 Feb 2000 12:09:29 +0530

Hello all,

There are certain issues regarding handling of syntax errors which have been
mentioned below:

1. Handling of syntax error in context token / context id.

Consider the following transaction:

Transaction = 123 {
    Context = 567 {...},            ; valid action
    Context = abc  {...}             ; invalid action as the context id is not a
number
}

The entity receiving the message will detect the syntax error in the context id.
What is the reply that should be sent ?
Should it be the following :

Reply = 123 {
    Context = 567 { .... },                                          ; reply for
the valid command
    Context = ??? { Error = 422 {"Error in Context Id"} }          ; error reply
for the erroneous action
}

If yes, then what should be the context id, that gets filled ? Should it be NULL
?

Section 8.2.2 has the following text for such a scenario:

(a)  " If the receiver encounters an error in processing a ContextID, the
requested Action response will consist of the context ID and a single error
descriptor, 422 Syntax Error in Action." (5th paragraph after the
TransactionReply API)

- The invalid context id can not be sent because it is syntactically incorrect
(say abcd) and if sent in the reply,  the receiver of the reply would also get a
syntax error.

- In fact, the above handling (as mentioned in draft) will never get done.
Because if the context id is syntactically correct  but does not exist, then the
error code 411 (The transaction refers to unknown context), 412 (No contextids
available) or 433 (TerminationId is already in Context) would be used.
Therefore, the above mentioned handling should never be done.

(b) " If the receiver encounters an error such that it cannot determine a legal
Action, it will return a TransactionReply consisting of the TransactionID and a
single error descriptor, 422 Syntax Error in Action. " (6th paragraph after the
TransactionReply API)

- If such a thing is done, then it means that the action reply for the valid
action request is not being sent. Which should not happen. If an action is
valid, then the same should get executed.

Similarly, what should happen if the request message is:

(a) Transaction = 123 {
    Context = 567 {...},            ; valid commands in the context
    XYZ     = abc  {...}             ; invalid context token
}

or

(b) Transaction = 123 {
    Context = 567 {...},            ; valid commands in the context
    Context & abc  {...}             ; = token not found
}

The reply for these cases should be the same as the one shown above (except for
the explanatory string).

Reply = 123 {
    Context = 567 { .... },                                          ; reply for
the valid command
    Context = ??? { Error = 422 {} }          ; error reply for the erroneous
action
}

2. Syntax Error in Termination Id.

Consider the following transaction:

Transaction = 123 {
    Context = $ {
                Add = A123 {...},     ; valid add command
                Add = ###   { ... }    ; invalid termination id
    }
}

What should be the response. Should it be:

Reply = 123 {
    Context = 567 {
                Add = A123 {...},     ; valid add command response
                Add = ??? { Error = 442  { "Invalid termination Id" } }   ; what
termination id to be filled in reply ??
    }
}

The relevant text in Sec 8.2.2 states:

(a) "If the terminationID cannot be reliably determined it will send 442 Syntax
Error in Command as the action reply."
(8th paragraph)

If this approach were to be followed, then all the commands prior to the
erroneous command would have to be discarded, even if they have been parsed
successfully. Shouldn't the entity try to execute all the commands that have
been successfully parsed ???

3. Sec 8.2.2: (6th para, last line): " If the receiver encounters an error such
that is cannot determine a legal Transaction, it will return a TransactionReply
with a null TransactionID and a single error descriptor (403 Syntax Error in
Transaction). "

Since Null transaction id is used for error replies, therefore, it should be
specified in Sec 8.1.1, that null transaction id is reserved.

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com

---

From: Harpreet Singh Anand <[email-masked]>
Date: Tue, 15 Feb 2000 10:33:27 +0530

Hello Brian,

> Hmmm, I think you are correct, the reply should never be
> syntactically incorrect.  I think you should get
> Transaction = 123 {
>      Error=xxx

The way ABNF rules are defined, above reply is not valid .

transactionReply     = ReplyToken EQUAL TransactionID LBRKT
                       ( errorDescriptor / actionReplyList ) RBRKT

actionReplyList      = actionReply *(COMMA actionReply )

actionReply          = CtxToken EQUAL ContextID LBRKT
                       ( errorDescriptor / commandReply ) RBRKT

A transaction reply can consist of list of action replies or a SINGLE error
descriptor. Thus there are two ways of indicating "context - level" errors:
a) send a transaction reply having only one error descriptor - this can be sent
say if the parser is not able to parse the first action itself.
b) send an error descriptor within an action reply (as suggested in my mail).

The current ABNF does not allow any mechanism of sending a transaction reply
consisting of action replies and multiple error descriptors ( as suggested by
you).

If the reply as mentioned by you has to be sent, then we need modification in
the ABNF.

Also, what should be the error handling in the case of error in parsing
termination id (point 2 in my mail) ? The problem there is also the same, the
context reply can consist of either a SINGLE error descriptor or multiple
command replies. What we need here is a capability to send multiple error
desciptors along with multiple command replies.

Regards,
Harpreet

>
> We will have to decide what the error should be
>
> Brian
>
> > -----Original Message-----
> > From: Harpreet Singh Anand [mailto:[email-masked]]
> > Sent: Friday, February 11, 2000 1:39 AM
> > To: [email-masked]
> > Subject: Syntax Error handling
> >
> >
> > Hello all,
> >

--

Regards,
Harpreet