Subject: Parsing Question

From: Steven Weisz <[email-masked]>
Date: Mon, 18 Jun 2001 11:06:27 -0400

Hi List,

I am currently looking at what needs to be done when a command is marked as
"optional" but during parsing of the command an error occurs.

As I see it these are the possible scenarios (assuming at least the command
token has been parsed):

(a) A transactionId cannot be reliably determined

(b) An error occurs in one of the command descriptors

(c) there is no closing '}' for the command

Now in case (a) we should fill the "action" reply with error 442 - Syntax
error in command, does this mean that the command cannot be skipped even
though it is optional? However, if it still can be skipped, shouldn't we set
the "command" reply's error descriptor to something, since we may still have
other command to process.

Case (b) seems to be straight forward, that it we set the "command" reply's
error descriptor appropriately.

Case (c) leads me to believe that we would have to stop parsing, since the
question would be what is the next token we could look for? Would we expect
a ',' or a CtxToken or what?

Is my reasoning making sense, do we try to skip optional commands when a
parsing error is encountered?

Thanks,

Steven

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 19 Jun 2001 11:36:04 -0400

I was kind of hoping Tom would field this, but my opinion is that:
(a) If the transactionId is incorrect, you toss the entire
transaction; it doesn't matter what the commands are
(b) I agree that you return an error on the optional command
and continue processing IFF you can reliably determine the end
of the command.  This is problematic, and you should be conservative.
(c) if you can't reliably determine the end of a command, then you
have to stop processing commands in the transaction.  

This kind of problem should not cause your implementation much
grief.  It is a FATAL error to send an ill-formed message; nothing
the recipient can do is likely to make matters better; there is
a bug in the sender, and it has to be fixed.  Therefore, if you
decide that following anything that is a real syntax error you
can't figure out where the next command is -- stop parsing the
transaction, or even the message, and return an error.

Brian

> -----Original Message-----
> From: Steven Weisz [mailto:[email-masked]]
> Sent: Monday, June 18, 2001 11:06 AM
> To: Megaco Mailing List (E-mail)
> Subject: Parsing Question
> 
> 
> Hi List,
>