Subject: RE: [Megaco] Conformance tests question

From: "Steve Cipolli" <[email-masked]>
Date: Thu, 16 Jun 2005 11:15:21 -0400

Christian,

I agree that avoiding any incompatible change to v1 and v2 is the ideal
solution.  However, I'm not sure I follow your alternative:

First, the problem is not encoding specific.  8.2.2 applies to both
binary and text encoding (the ABNF also allows '$', but 8.2.2 prohibits
its use in replies).  My reading of the ASN.1 does not allow action
replies and an action-level error in the same reply, just as the ABNF
does not.

Second, I think you mean "... Implementors issue C=$ as the first action
in the transaction ", not "... Implementors issue C=? as the first
command in the transaction".

Third, there maybe multiple actions with a context of '$'.  How would an
MGC know which of these actions might fail?  

--Stephen

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]] 
> Sent: Thursday, June 16, 2005 3:26 AM
> To: Steve Cipolli
> Cc: Kevin Boyle; Frank Reno; [email-masked]
> Subject: Re: [Megaco] Conformance tests question
> 
> 
> Hello,
> 
> I'm not really in favour of option 1 or 2. Relaxing 8.2.2 is 
> still a protocol 
> change. You may not be updating the syntax but something 
> different will be sent 
> in the protocol. Also by relaxing 8.2.2 you will also be 
> making a change to the 
> binary protocol.
> 
> I think the only choice is to issue a note for V1 and V2 that 
> for the text 
> encoding that implementors issue the C=? as the first command 
> in a transaction. 
> In v3 update the syntax so that this is fixed properly.
> 
> Regards, Christian
> 
> Steve Cipolli wrote:
> 
> > Kevin,
> >  
> > I assume that v3 will have to support both choice #1 and #2 
> if we choose
> > choice #1 for v1 and v2.   That said, I believe this will 
> mean that most
> > implementations will use the form from choice #1 even for 
> v3.  I'm OK 
> > with that, but it is something to consider.
> >  
> > My preference would be to do choice #1 and choice #2 in all 
> versions. 
> > This way anyone who has to change their implementation because they 
> > currently do not allow $ could as easily use the form from 
> choice #2. 
> > This will make it more likely that choice #2 is used in version 3.
> >  
> > The downside to both choices is that they could create 
> incompatibilies 
> > between new implementations of v1 (or v2) vs old 
> implementations of v1 
> > (or v2), but I see the risk the same for either choice.
> >  
> > --Stephen
> > 
> > -----Original Message-----
> > From: Kevin Boyle [mailto:[email-masked]]
> > Sent: Wednesday, June 15, 2005 9:40 AM
> > To: Steve Cipolli; Frank Reno; [email-masked]
> > Subject: RE: [Megaco] Conformance tests question
> > 
> > 
> > Well, the two choices are: 1) lift this restriction in the text for 
> > the particular case of an error response for a second action in a 
> > transaction; or 2) change the ABNF syntax of the protocol.  
> I believe 
> > the better choice for V1 and V2 is to do the former, since 
> no parsing 
> > changes will be required.  For V3 we should choose the 
> latter, since 
> > this appears to be an oversight in the grammar.
> >  
> > Kevin
> > 
> > 
> >   _____
> > 
> > From: Steve Cipolli [mailto:[email-masked]]
> > Sent: Tuesday, June 14, 2005 5:41 PM
> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; [email-masked]
> > Subject: RE: [Megaco] Conformance tests question
> > 
> > 
> >  
> > As the original poster pointed out, 8.2.2 says:
> >  
> > 8.2.2 TransactionReply
> >  
> > ...
> > The ContextID parameter must specify a value to pertain to all 
> > Responses for the action. The ContextID may be specific, 
> all or null.
> >  
> > --Stephen
> > 
> > -----Original Message-----
> > From: Kevin Boyle [mailto:[email-masked]]
> > Sent: Tuesday, June 14, 2005 4:53 PM
> > To: Steve Cipolli; Frank Reno; [email-masked]
> > Subject: RE: [Megaco] Conformance tests question
> > 
> > 
> > 
> > Where do you see that restriction?
> > 
> > Kevin
> > 
> > -----Original Message-----
> > From: Steve Cipolli [mailto:[email-masked]
> > <mailto:[email-masked]> ] 
> > Sent: Tuesday, June 14, 2005 2:21 PM 
> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; [email-masked] 
> > Subject: RE: [Megaco] Conformance tests question 
> > 
> > Kevin,
> > 
> > Allowing '$' for context in replies also violates v1 and v2, so it 
> > appears there is no solution at all for v1 and v2.  Do you 
> mean that 
> > the IG for v1 and v2 should be updated to allow '$' for context in 
> > replies?
> > 
> > --Stephen
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[ <mailto:[email-masked]> 
> mailto:[email-masked]] On
> > 
> > Behalf Of Kevin Boyle
> > 
> >>Sent: Tuesday, June 14, 2005 12:36 PM
> >>To: Frank Reno; [email-masked] 
> >>Subject: RE: [Megaco] Conformance tests question 
> >>
> >>
> >>This seems like a problem with the syntax of the protocol.
> >>Since we clearly allow error descriptors at the action 
> level, and we 
> >>allow following errors at the transaction and command levels, this 
> >>appears to need fixing.  It appears that the binary 
> encoding allows an
> > 
> > 
> >>error at the action level for the second (or subsequent) action in a
> >>transaction. 
> >>
> >>The fix itself would be straightforward, though non-backwards
> >>compatible. This would mean that it would have to be in V3, and not 
> >>made retroactive to V1 and V2.  The fix would be: 
> >>
> >>transactionReply = ReplyToken EQUAL TransactionID LBRKT 
> >>                   [ImmAckRequiredToken COMMA](errorDescriptor / 
> >>                   actionReplyList [COMMA errorDescriptor]) 
> RBRKT Fix
> >>is here------------------------^^^^^^^^^^^^^^^^^^^^^^^ 
> >>
> >>So, for V1 and V2, it would appear that your solution, though
> >>suboptimal in my view, is the only solution available within the 
> >>syntax as defined. 
> >>
> >>Kevin
> >> 
> >>
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[ <mailto:[email-masked]> 
> mailto:[email-masked]] On
> > 
> > Behalf Of Frank Reno
> > 
> >>Sent: Friday, June 10, 2005 3:49 PM
> >>To: [email-masked] 
> >>Subject: RE: [Megaco] Conformance tests question 
> >>
> >>If an action fails with a context ID of CHOOSE and it is 
> not the first
> > 
> > 
> >>action in the transaction, then the error can't be placed at the
> >>action level, since the grammar does not permit action 
> replies and an 
> >>action level error descriptor in the same transaction reply. 
> >>
> >>So it looks like CHOOSE should be allowed in the reply.
> >>
> >>Given
> >>
> >>T = 1
> >>{ 
> >>    C = 1 { Add = t1 }, 
> >>    C = $ { Add = t2 } 
> >>} 
> >>
> >>This is not legal:
> >>
> >>Reply = 1
> >>{ 
> >>    C = 1 { Add = t1 }, 
> >>    Error = 412 {} 
> >>} 
> >>
> >>So it would have to be:
> >>
> >>Reply = 1
> >>{ 
> >>    C = 1 { Add = t1 }, 
> >>    C = $ { Error = 412 {}} 
> >>} 
> >>
> >>Frank
> >>
> >>
> >>
> >>--- Kevin Boyle <kboyle at nortel.com> wrote:
> >>
> >>In most cases, the MG knows it cannot allocate a context at the time
> >>the request is detected -- that is, once the action is 
> parsed.  If the
> > 
> > 
> >>MG detects a problem, why would it continue to parse?
> >>The error descriptor 
> >>ought to be placed at the action level, so there would not be a 
> >>context indicated of any kind, let alone a CHOOSE wildcard. 
> >>
> >>Remember, error detection occurs at the earliest possible time with
> >>the error descriptor occurring at the level of detection. 
> >>If the MG was not 
> >>able to detect that it was unable to allocate a context until the 
> >>command or descriptor level, then the error descriptor 
> would go at the
> > 
> > 
> >>lower level.
> >>
> >>Kevin
> > 
> >  [SNIP...]
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> 
> 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Fri, 17 Jun 2005 12:53:21 +1000

G'Day Steve,

Yes, it seems I got ahead of myself and read SEQUENCE when in fact the ASN.1 
reads CHOICE... On the 2nd point I'm dsylexic when it comes to the use of ? and $.

On the 3rd point: I was trying to thing laterally. Rather than trying to update 
syntax and causes problems I was thinking that perhaps we could had a warning to 
avoid transactions could cause this problem. Eg. those with optional flags and 
multiple c=$ in them  or the c=$ not being first.

As for returning c=$ (or 0xFFFFFFFE in binary) this is probably OK as it is only 
in the TransactionReply direction and the MGC can't send a reply to a reply.

There's no argument for v3, this can be fixed syntactically.

Regards, Christian