Subject: RE: [Megaco] Conformance tests question

From: "Steve Cipolli" <[email-masked]>
Date: Wed, 15 Jun 2005 17:34:02 -0400

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]] 
			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

---

From: Christian Groves <[email-masked]>
Date: Thu, 16 Jun 2005 17:26:14 +1000

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:

> 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
>   _____  
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; [email-masked]
> The ContextID parameter must specify a value to pertain to all Responses
> for the action. The ContextID may be specific, all or null.
>  
> --Stephen
> 
> From: Steve Cipolli [mailto:[email-masked]
> <mailto:[email-masked]> ] 
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; [email-masked] 
> 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 
> 
> 
>>[ <mailto:[email-masked]> mailto:[email-masked]] On
> 
> Behalf Of Kevin Boyle 
> 
>>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 
>> 
>>
>>[ <mailto:[email-masked]> mailto:[email-masked]] On
> 
> Behalf Of Frank Reno 
> 
>>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 
>>
>>
>>
>>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...] 
> 
> 
> 
> ------------------------------------------------------------------------
>