Subject: [Megaco] Processing of command, action ...

From: petric john <[email-masked]>
Date: Fri, 4 Apr 2003 00:00:35 +1000 (EST)

Hi,

This is in context of the text mentioned in 8.2.2 as
below.

S1: If the end of an action cannot be reliably
determined but one or more commands can be parsed, it
will process them and then send 422 - Syntax Error in
Action as the last action for the transaction.

S2: If the end of a transaction cannot be reliably
determined and one or more Actions can be parsed, it
will process them and then return 403 - Syntax Error
in Transaction as the last action reply for the
transaction. 

In both the above statemets, it is mentioned about the
unreliable determination of the action, and
transaction respectively. 

As mentioned, does processing of the commands (in S1)
means the execution of the commands, and does
processing of the action (in S2) means the execution
in the context of the MGC/MG application??? 

This apprently shows that even if the parsing
(decoding) of the given component of the protocol
message is partial, the decoded information is still
passed on to the MG/MGC application for further
processing/execution.

So far I am under impression that even a single parse
failure (at any level) of the messgge would prohibit
it from sending it to the application, thus rejecting
it compeletely.

what is the significance of the word "it will process
them"???

regards,

=====
~|~ 
 o 
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 3 Apr 2003 18:05:56 +0200

See [FSRT] within.

Raphael Tryster

-----Original Message-----
From: petric john [mailto:[email-masked]]
Sent: Thursday, 3 April 2003 16:01
To: [email-masked]
Subject: [Megaco] Processing of command, action ...

Hi,

[FSRT] Yes.

[FSRT]  Yes.  In practice, it means your parser has to be able to generate
partial output, as well as an indication that the only processing required
for a specific command or action is to return an error.

[FSRT]  That was my impression once too, but I couldn't find anything in the
standard to support it.

[FSRT]  As if there were no subsequent error.

regards,

=====
~|~ 
 o 
John

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 3 Apr 2003 18:05:56 +0200

See [FSRT] within.

Raphael Tryster

-----Original Message-----
From: petric john [mailto:[email-masked]]
Sent: Thursday, 3 April 2003 16:01
To: [email-masked]
Subject: [Megaco] Processing of command, action ...

Hi,

[FSRT] Yes.

regards,

=====
~|~ 
 o 
John

---

From: petric john <[email-masked]>
Date: Fri, 4 Apr 2003 21:34:40 +1000 (EST)

Sorry, forgot to post it to mailing list.
Repeating the same.

-- john

 --- petric john <[email-masked]> wrote: >
see the comments with [PJJ]
> 
>  --- Raphael Tryster <[email-masked]> wrote: >
> See
> [FSRT] within.
> > 
> > Raphael Tryster
> > 
> [PJJ] I think then there are more issues asociated
> with this. See below.
> 
> > [FSRT]  Yes.  In practice, it means your parser
> has
> > to be able to generate
> [PJJ] 
> 1. Assume that there are four commands in an action.
> Now the parsing of the command 1 and 2 was
> successful,
> and the third one failed. Then according to the
> above,
> we shall send the command 1 and 2 to the
> application.
> What about the command command number 4 in the
> action
> (which could be syntactically correct)? What we
> should
> do to it??
> 
> 2. If we have to still parse for the command 4 in
> the
> action, then it is going to be difficult to know the
> exact start of the command 4 in the action.
> 
> 3. What would be the action on the sender's side in
> this case?? As we shall report the error "422 -
> Syntax
> Error in Action" to the sender, how its going to
> retransmitt the commands 3 and 4??
> 
> 4. Partial decoding is certainly not applicable in
> case of command, as it does make any sense to do so.
> Also the basic unit of the data that has to go to
> the
> application is Command, and it should be complete at
> any point of time. Thus when sender, after receiving
> the 422, shall send the command 3 and 4 with the
> same
> TransactionId (hopefully), in which case it will be
> the re-transmission of the Transaction (which is
> again
> not correct). The resending of the commands 3 and 4
> has to be a new Transaction. Correct me if wrong.
> 
> 5. To make above process more complex, assume if the
> command 1 and 3 were parsed successfully. then
> should
> we send command 1 and 3 to the application?? (even
> otherwise parsing of the alternate commands is
> definitely not easy. Same is the case with Action,
> see
> below.
> 
> 6. I would like to make a point here that as long as
> the parsing of the commands in the action (and so
> actions in the Transaction) is moving successfully,
> the information is useful. But we should stop
> parsing
> as soon as the command decode is failure, and jump
> to
> the next action in the Transaction (if present).
> 
> 7. The parsing logic is certainly going to be
> complex
> to find out the next Action in the Transaction. 
> 
> looking forward for the clarifications. ;-)
> 
> [PJJ] Same here. I guess there is no support in the
> standard too for the some of the doubts raised
> above.
> 
> > - Check & compose your email via SMS on your
> Telstra
> > or Vodafone mobile.

=====
~|~ 
 o 
John

---

From: petric john <[email-masked]>
Date: Fri, 4 Apr 2003 21:34:40 +1000 (EST)

-- john

=====
~|~ 
 o 
John

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 6 Apr 2003 11:23:38 +0200

I think most of your questions can be answered by recalling the following:

   A TransactionRequest has been processed 
    
   ¸    when all actions in that TransactionRequest have been 
        processed, or 
    
   ¸    when an error is encountered in processing that 
        TransactionRequest except when the error is in an optional 
        command. 

Thus, you will never process a command following the one in which an error
occurred unless the failed command was optional.  I think that the quote you
called S1 in your original posting implies that if the error was in parsing,
then you send error 422 which terminates both the action and the transaction
processing, even if the erroneous command was optional.  Therefore, the only
thing you have to worry about is processing the commands before the one in
which you found the error, and everything after it goes in the garbage.

Regarding your questions about sender recovery, I would be surprised to
learn about the existence of implementations that rephrase their requests
when the recipient doesn't like the syntax.  Perhaps the Megaco gurus would
like to comment.  I think errors like 422 and 403 are more likely to be
found during interoperability tests, and hopefully not after deployment.

Raphael Tryster

-----Original Message-----
From: petric john [mailto:[email-masked]]
Sent: Friday, 4 April 2003 13:35
To: [email-masked]; petric john; Raphael Tryster
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] Processing of command, action ...

-- john

=====
~|~ 
 o 
John

---

From: Raphael Tryster <[email-masked]>
Date: Sun, 6 Apr 2003 11:23:38 +0200

Raphael Tryster

-----Original Message-----
From: petric john [mailto:[email-masked]]
Sent: Friday, 4 April 2003 13:35
To: [email-masked]; petric john; Raphael Tryster
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] Processing of command, action ...

-- john

=====
~|~ 
 o 
John

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 7 Apr 2003 14:33:26 -0400

Raphael is correct.  As for syntax errors, an MGC could be smart enough to
figure out which command contained the error, and then resend anything after
the error.  However, generally speaking, commands grouped in the same action
or transaction tend to be related, so a failure of one will make the others
difficult/impossible to execute, or they will become irrelevant.
 
I will echo Raphael's sentiment that syntax errors that make it to the field
indicate bigger problems than needing to resend unexecuted commands.
 
Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]] 
Sent: Sunday, April 06, 2003 5:24 AM
To: 'petric john'; [email-masked]
Subject: RE: [Megaco] Processing of command, action ...

    

Raphael Tryster 

-----Original Message----- 
From: petric john [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, 4 April 2003 13:35 
To: [email-masked]; petric john; Raphael Tryster 
Cc: [email-masked]; [email-masked] 
Subject: RE: [Megaco] Processing of command, action .... 

-- john 

> > From: petric john 
> [mailto:[email-masked] <mailto:[email-masked]> ] 
> > http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile

> > - Check & compose your email via SMS on your 
<https://www1.ietf.org/mailman/listinfo/megaco>  
> >  
> 
> ===== 
> ~|~ 
>  o 
> John 
> 
> http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile 

===== 
~|~ 
 o 
John 

http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile 
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 7 Apr 2003 14:33:26 -0400

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]] 
Sent: Sunday, April 06, 2003 5:24 AM
To: 'petric john'; [email-masked]
Subject: RE: [Megaco] Processing of command, action ...

    

Raphael Tryster 

-----Original Message----- 

-- john 

===== 
~|~ 
 o 
John