Subject: RE: [Megaco] Conformance tests question

From: "Steve Cipolli" <[email-masked]>
Date: Wed, 1 Jun 2005 10:54:29 -0400

Two points:
1. ETSI H.248 Conformance Tests assume that any given request will
generate one and only one possible response.  Clearly this is not a
valid approach.  The original posting is a good example of this problem.
There is no specification outlining exactly what kinds of errors
generate errors at what level in a given response. Therefore, the test
must account for all possible legal responses.

2. The H.248.1 spec says responses can not contain '$' in the Context ID
as indicated by the original poster.    Clearly a conformance test can
not violate the standard it tests.  Stating that responses should be
allowed to return '$' in Context ID does not make it so.  Either the
Conformance Test or the standard needs to be amended.

--Stephen

Stephen Cipolli
Product Manager
RADVISION Inc.
1-201-689-6339
[email-masked]
www.radvision.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Kevin Boyle
> Sent: Friday, May 27, 2005 1:49 PM
> To: B Venkat S.R Swamy; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Megaco] Conformance tests question
> 
> 
> 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
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of B Venkat S.R Swamy
> Sent: Thursday, May 26, 2005 8:25 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Megaco] Conformance tests question
> 
> 
> 
> 
> 
> 
> Hi
> 
> IMO it is perfectly valid to specify CHOOSE for contextID in
> response to the test cases you have mentioned below.  As far 
> as the protocol text you have mentioned it applies mostly to 
> those scenario where you a valid context Id(includes wildcard 
> also) or Null context. Where MG has never been able to create 
> a context why should it return any other value.
> 
> Even the ABNF and ASN grammar in Appendix does not put any
> limitation on the set of values that can be used in the Reply 
> messages.
> 
> I however do agree that the relevant text should be modified
> to clarify these scenario and request authors to take this in 
> IG or upcoming V3 document.
> 
> regards
> B Venkat S.R Swamy
> Senior Technical Leader
> Flextronics Software Systems
> Phone:  +91-124-2455555 Extn 3620
> Fax: +91-124-2455345
> web: www.hssworld.com
> 
> 
> 
> 
> 
>                                                               
>              
>              Seraya.Miletzki@e                                
>              
>              citele.com                                       
>              
>              Sent by:                                         
>           To 
>              megaco-bounces@ie         [email-masked]        
>              
>              tf.org                                           
>           cc
>                                                               
>              
>                                                               
>      Subject 
>              05/26/2005 05:17          [Megaco] Conformance 
> tests question 
>              PM                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hello all
> 
> I was performing conformance tests for the MEGACO according
> ETSI TS 101 889-2 v1.1.1 (2002-08). I have a question 
> regarding some of the expected results appeared on this
> tests:
> On error tests (BI type) there are several tests that send 
> request with ContextID set to CHOOSE ($). The expected 
> results on the tests contain action reply with ContextID set 
> to CHOOSE. Here is an example for this tests :
> 
> TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3]
> clause 7.2.1 Selection criteria: ROOT termination implemented 
> Initial condition: any Ensure that the IUT, on receipt of a 
> Transaction Request containing
>       * Action request with
>             o CID set to CHOOSE
>             o ADD Command request wi
> sends a Transaction Reply containing
>       * Action reply with
>             o CID set to CHOOSE
>             o ADD Command reply wi
> RO
> 
> The H.248.1 v1 spec mandate that transaction reply may only
> contain a specific ContextID, ALL (*), or NULL (-).
> 
> Here's the relevant text from the H.248.1 v1 spec:
> 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.
> 
> The following 19 items are the test cases with this requirement.
> 
> 1.    TP/MG/AD/BI-01
> 2.    TP/MG/AC/BI-01
> 3.    TP/MG/AC/BI-02
> 4.    TP/MG/AC/BI-03
> 5.    TP/MG/AC/BI-04
> 6.    TP/MG/AV/BI-01
> 7.    TP/MG/AV/BI-02
> 8.    TP/MG/AV/BI-03
> 9.    TP/MG/AV/BI-04
> 10.   TP/MG/MD/BI-01
> 11.   TP/MG/MD/BI-02
> 12.   TP/MG/MD/BI-03
> 13.   TP/MG/MD/BI-09
> 14.   TP/MG/SU/BI-01
> 15.   TP/MG/SU/BI-02
> 16.   TP/MG/SU/BI-03
> 17.   TP/MG/SU/BI-04
> 18.   TP/MG/MV/BI-01
> 19.   TP/MG/MV/BI-02
> 
> 
> Please help me to clear this issue.
> 
> Thanks
> 
> Seraya_______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> 
> 
> ***********************  FSS-Restricted   ***********************
> "DISCLAIMER: This message is proprietary to Hughes Software
> Systems Limited
> (HSS) and is intended solely for the use of the individual to 
> whom it is addressed. It may contain  privileged or 
> confidential information and should not be circulated or used 
> for any purpose other than for what it is intended. If you 
> have received this message in error, please notify the 
> originator immediately. If you are not the intended 
> recipient, you are notified that you are strictly prohibited 
> from using, copying, altering, or disclosing the contents of 
> this message. HSS accepts no responsibility for loss or 
> damage arising from the use of the information transmitted by 
> this email including damage from virus."
> "DISCLAIMER: This message is proprietary to Flextronics 
> Software Systems Limited (FSS) and is intended solely for the 
> use of the individual to whom it is addressed. It may contain 
>  privileged or confidential information and should not be 
> circulated or used for any purpose other than for what it is 
> intended. If you have received this message in  error, please 
> notify the originator immediately. 
> If you are not the intended recipient, you are notified that 
> you are strictly  prohibited  from  using, copying, altering, 
> or disclosing the contents of this message.  FSS  accepts no  
> responsibility  for loss or damage arising from the use of  
> the information transmitted by this email including damage 
> from virus."
> 
> _______________________________________________
> 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: Frank Reno <[email-masked]>
Date: Fri, 10 Jun 2005 12:49:13 -0700 (PDT)

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 

-----Original Message-----
From: megaco-bounces at ietf.org
[mailto:megaco-bounces at ietf.org] On Behalf Of
B Venkat S.R Swamy
Sent: Thursday, May 26, 2005 8:25 AM
To: Seraya.Miletzki at ecitele.com
Cc: megaco at ietf.org
Subject: Re: [Megaco] Conformance tests question

Hi

IMO it is perfectly valid to specify CHOOSE for
contextID in response to the
test cases you have mentioned below.  As far as the
protocol text you have
mentioned it applies mostly to those scenario where
you a valid context
Id(includes wildcard also) or Null context. Where MG
has never been able to
create a context why should it return any other value.

Even the ABNF and ASN grammar in Appendix does not put
any limitation on the
set of values that can be used in the Reply messages.

I however do agree that the relevant text should be
modified to clarify
these scenario and request authors to take this in IG
or upcoming V3
document.

regards
B Venkat S.R Swamy
Senior Technical Leader

                    
             Seraya.Miletzki at e                     
                       
             citele.com                               
                    
             Sent by:                                 
                 To 
             megaco-bounces at ie         megaco at
ietf.org                     
             tf.org                                   
                 cc 

            Subject 
             05/26/2005 05:17          [Megaco]
Conformance tests question 
             PM                                       

                                                      

Hello all

I was performing conformance tests for the MEGACO
according ETSI TS 101
889-2 v1.1.1 (2002-08).
I have a question regarding some of the expected
results appeared on this
tests:
On error tests (BI type) there are several tests that
send request with
ContextID set to CHOOSE ($).
The expected results on the tests contain action reply
with ContextID set to
CHOOSE.
Here is an example for this tests :

TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1
[3] clause 7.2.1
Selection criteria: ROOT termination implemented
Initial condition: any
Ensure that the IUT, on receipt of a Transaction
Request containing
      * Action request with
            o CID set to CHOOSE
            o ADD Command request wi
sends a Transaction Reply containing
      * Action reply with
            o CID set to CHOOSE
            o ADD Command reply wi
RO

The H.248.1 v1 spec mandate that transaction reply may
only contain a
specific ContextID, ALL (*), or NULL (-).

Here's the relevant text from the H.248.1 v1 spec:
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.

The following 19 items are the test cases with this
requirement.

1.    TP/MG/AD/BI-01
2.    TP/MG/AC/BI-01
3.    TP/MG/AC/BI-02
4.    TP/MG/AC/BI-03
5.    TP/MG/AC/BI-04
6.    TP/MG/AV/BI-01
7.    TP/MG/AV/BI-02
8.    TP/MG/AV/BI-03
9.    TP/MG/AV/BI-04
10.   TP/MG/MD/BI-01
11.   TP/MG/MD/BI-02
12.   TP/MG/MD/BI-03
13.   TP/MG/MD/BI-09
14.   TP/MG/SU/BI-01
15.   TP/MG/SU/BI-02
16.   TP/MG/SU/BI-03
17.   TP/MG/SU/BI-04
18.   TP/MG/MV/BI-01
19.   TP/MG/MV/BI-02

Thanks

Megaco at ietf.org

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 14 Jun 2005 12:35:38 -0400

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

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 

-----Original Message-----
[mailto:megaco-bounces at ietf.org] On Behalf Of B Venkat S.R Swamy

Hi

IMO it is perfectly valid to specify CHOOSE for contextID in response to the
test cases you have mentioned below.  As far as the protocol text you have
mentioned it applies mostly to those scenario where you a valid context
Id(includes wildcard also) or Null context. Where MG has never been able to
create a context why should it return any other value.

Even the ABNF and ASN grammar in Appendix does not put any limitation on the
set of values that can be used in the Reply messages.

I however do agree that the relevant text should be modified to clarify
these scenario and request authors to take this in IG or upcoming V3
document.

regards
B Venkat S.R Swamy
Senior Technical Leader

                    
             Seraya.Miletzki at e                     
                       
             citele.com                               
                    
             Sent by:                                 
                 To 

            Subject 

                                                      

Hello all

I was performing conformance tests for the MEGACO according ETSI TS 101
889-2 v1.1.1 (2002-08).
I have a question regarding some of the expected results appeared on this
tests:
On error tests (BI type) there are several tests that send request with
ContextID set to CHOOSE ($).
The expected results on the tests contain action reply with ContextID set to
CHOOSE.
Here is an example for this tests :

TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause 7.2.1
Selection criteria: ROOT termination implemented Initial condition: any
Ensure that the IUT, on receipt of a Transaction Request containing
      * Action request with
            o CID set to CHOOSE
            o ADD Command request wi
sends a Transaction Reply containing
      * Action reply with
            o CID set to CHOOSE
            o ADD Command reply wi
RO

The H.248.1 v1 spec mandate that transaction reply may only contain a
specific ContextID, ALL (*), or NULL (-).

Here's the relevant text from the H.248.1 v1 spec:
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.

1.    TP/MG/AD/BI-01
2.    TP/MG/AC/BI-01
3.    TP/MG/AC/BI-02
4.    TP/MG/AC/BI-03
5.    TP/MG/AC/BI-04
6.    TP/MG/AV/BI-01
7.    TP/MG/AV/BI-02
8.    TP/MG/AV/BI-03
9.    TP/MG/AV/BI-04
10.   TP/MG/MD/BI-01
11.   TP/MG/MD/BI-02
12.   TP/MG/MD/BI-03
13.   TP/MG/MD/BI-09
14.   TP/MG/SU/BI-01
15.   TP/MG/SU/BI-02
16.   TP/MG/SU/BI-03
17.   TP/MG/SU/BI-04
18.   TP/MG/MV/BI-01
19.   TP/MG/MV/BI-02

Thanks

---

From: "Steve Cipolli" <[email-masked]>
Date: Tue, 14 Jun 2005 14:21:21 -0400

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

> Sent: Tuesday, June 14, 2005 12:36 PM
> To: Frank Reno; [email-masked]
> 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 
> 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:
> 
>                    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]] 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.
> 
> continue to parse? 
> ought to be placed at the action level, so there would not be 
> a context indicated of any kind, let alone a CHOOSE wildcard.
> 
> 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 
> 
> Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> 
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 14 Jun 2005 16:53:05 -0400

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

> 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.
> 
> compatible. This would mean that it would have to be in V3, and not 
> made retroactive to V1 and V2.  The fix would be:
> 
>                    actionReplyList [COMMA errorDescriptor]) RBRKT Fix 
> is here------------------------^^^^^^^^^^^^^^^^^^^^^^^
> 
> suboptimal in my view, is the only solution available within the 
> syntax as defined.
> 
> Kevin
>  
> 
> 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.
> 
> 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
> 
> IMO it is perfectly valid to specify CHOOSE for contextID in response 
> to the test cases you have mentioned below.  As far as the protocol 
> text you have mentioned it applies mostly to those scenario where you 
> a valid context Id(includes wildcard
> also) or Null context. Where MG has never been able to create a 
> context why should it return any other value.
> 
> Even the ABNF and ASN grammar in Appendix does not put any limitation 
> on the set of values that can be used in the Reply messages.
> 
> I however do agree that the relevant text should be modified to 
> clarify these scenario and request authors to take this in IG or 
> upcoming V3 document.
> 
> regards
> B Venkat S.R Swamy
> Senior Technical Leader
> I was performing conformance tests for the MEGACO according ETSI TS 
> 101 889-2 v1.1.1 (2002-08). I have a question regarding some of the 
> expected results appeared on this
> tests:
> On error tests (BI type) there are several tests that send request 
> with ContextID set to CHOOSE ($). The expected results on the tests 
> contain action reply with ContextID set to CHOOSE. Here is an example 
> for this tests :
> 
> TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3] clause 
> 7.2.1 Selection criteria: ROOT termination implemented Initial 
> condition: any Ensure that the IUT, on receipt of a Transaction 
> Request containing
>       * Action request with
>             o CID set to CHOOSE
>             o ADD Command request wi
> The ContextID parameter must specify a value to pertain to all 
> Responses for the action. The ContextID may be specific, all or null.
>

---

From: "Steve Cipolli" <[email-masked]>
Date: Tue, 14 Jun 2005 17:40:44 -0400

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

	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 

	> Since we clearly allow error descriptors at the action level,
and we 
	> compatible. This would mean that it would have to be in V3,
and not 
	>                    actionReplyList [COMMA errorDescriptor])
RBRKT Fix 
	> suboptimal in my view, is the only solution available within
the 
	> If an action fails with a context ID of CHOOSE and it is not
the first 
	> In most cases, the MG knows it cannot allocate a context at
the time 
	> ought to be placed at the action level, so there would not be
a 
	> able to detect that it was unable to allocate a context until
the 
	> IMO it is perfectly valid to specify CHOOSE for contextID in
response 
	> also) or Null context. Where MG has never been able to create
a 
	> Even the ABNF and ASN grammar in Appendix does not put any
limitation 
	> I however do agree that the relevant text should be modified
to 
	> I was performing conformance tests for the MEGACO according
ETSI TS 
	> On error tests (BI type) there are several tests that send
request 
	> TP/MG/AD/BI-01 Reference: ITU-T Recommendation H.248.1 [3]
clause 

	> The H.248.1 v1 spec mandate that transaction reply may only
contain a 

requirement. 
around

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 15 Jun 2005 09:39:33 -0400

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

 
8.2.2 TransactionReply
 
...
 
--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

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, 

--Stephen 

> [mailto:[email-masked] <mailto:[email-masked]> ] On
Behalf Of Kevin Boyle 
> [mailto:[email-masked] <mailto:[email-masked]> ] On
Behalf Of Frank Reno 
> [mailto:megaco-bounces <mailto:megaco-bounces>  at ietf.org] On Behalf Of
B Venkat S.R Swamy 
> Megaco at ietf.org https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
> http://mail.yahoo.com <http://mail.yahoo.com>  
> 
<https://www1.ietf.org/mailman/listinfo/megaco>  
<https://www1.ietf.org/mailman/listinfo/megaco>

---

From: "Steve Cipolli" <[email-masked]>
Date: Fri, 17 Jun 2005 14:37:22 -0400

Christian/Kevin,

I think we all agree that allowing $ for context in replies is the right
thing to do in v1 and v2, and by compatibility rules also in v3. I think
we all also agree that both action replies and action-level errors in a
reply should be allowed in v3.  

My argument is that if we are going to make what amounts to an
incompatible change in v1 and v2 to allow $ to be specified for context
in replies, then we may as well make the change to allow action replies
and action-level errors in a single transaction reply as well.  Both
changes run the same risk and have the same ramifications when an
incompatibility occurs.  

The only difference between the two solutions is that the $ change is
likely to be far easier to implement, since the parser should already
allow it.  If not for this difference I would argue that we should only
support (in all versions) the change to allow action replies and
action-level errors in the same transaction reply.

--Stephen

> From: Christian Groves [mailto:[email-masked]] 
> Sent: Thursday, June 16, 2005 10:53 PM
> To: Steve Cipolli
> Cc: Kevin Boyle; Frank Reno; [email-masked]
> 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
> 
> Steve Cipolli wrote:
> 
> > 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
> > 
> > 
> >>From: Christian Groves [mailto:[email-masked]]
> >>Sent: Thursday, June 16, 2005 3:26 AM
> >>To: Steve Cipolli
> >>Cc: Kevin Boyle; Frank Reno; [email-masked]
> >>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
> >>>
> >>>Sent: Wednesday, June 15, 2005 9:40 AM
> >>>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
> >>>
> >>>
> >>>  _____
> >>>
> >>>Responses for the action. The ContextID may be specific, 
> >>
> >>all or null.
> >>
> >>> 
> >>>--Stephen
> >>>
> >>>appears there is no solution at all for v1 and v2.  Do you 
> >>
> >>mean that
> >>
> >>>>[ <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
> >>
> >>>>appears to need fixing.  It appears that the binary 
> >>
> >>encoding allows an
> >>
> >>>
> >>>>[ <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 level, since the grammar does not permit action
> >>
> >>replies and an
> >>
> >>>>the request is detected -- that is, once the action is
> >>
> >>parsed.  If the
> >>
> >>>
> time with 
> 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...]
> >>>
> >>>
> >>>
> >>>
> >>
> >>------------------------------------------------------------
> ----------
> >>
> >>>--
> >>>
> >>>[email-masked] https://www1.ietf.org/mailman/listinfo/megaco
> >>
> >>
> > 
> 
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 17 Jun 2005 19:02:52 -0400

I think we are all agree on the correction, too.  Ideally, we would make the
syntax change to allow a second CHOOSE action in a transaction return an
action-level error.  However, given that this requires a syntax change, it
is only something that we can consider for V3.  I am editing that into the
document as a fix this weekend.

As an informational note, we try not to change syntax definitions unless
there is a critical need for a fix.  A good example of this was the
EnergencyOff flag to allow removal of the emergency designation from a
context. If we can get around a syntax problem by altering the semantics and
procedures of the protocol, that is more acceptable because it doesn't break
everybody's parser.

Kevin

-----Original Message-----
From: Steve Cipolli [mailto:[email-masked]] 
Sent: Friday, June 17, 2005 2:37 PM
To: Christian Groves
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Frank Reno; [email-masked]
Subject: RE: [Megaco] Conformance tests question

Christian/Kevin,

I think we all agree that allowing $ for context in replies is the right
thing to do in v1 and v2, and by compatibility rules also in v3. I think we
all also agree that both action replies and action-level errors in a reply
should be allowed in v3.  

My argument is that if we are going to make what amounts to an incompatible
change in v1 and v2 to allow $ to be specified for context in replies, then
we may as well make the change to allow action replies and action-level
errors in a single transaction reply as well.  Both changes run the same
risk and have the same ramifications when an incompatibility occurs.  

The only difference between the two solutions is that the $ change is likely
to be far easier to implement, since the parser should already allow it.  If
not for this difference I would argue that we should only support (in all
versions) the change to allow action replies and action-level errors in the
same transaction reply.

--Stephen

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