Subject: Re: [Megaco] Re: g/sc SigID list

From: Christian Groves <[email-masked]>
Date: Fri, 02 Nov 2001 02:21:19 +1100

G'Day Troy,

I must admit after this long thread I'm a little confused what your
problems with the sublists and signal completion are. I missed the
"sublist" tag in ASN1 so I agree that the change below for sub-list
encoding is not needed.

Therefore I think that the only change we are arguing about is in E.1.2
to the type. I didn't see you arguing against the other changes. I think
SC is an exception because SignalID is 4 octets in Binary and Signal ID
is a textual string in text. So I would have thought that in the Binary
case you want to send back "OCTET STRING" and in the text case send back
"STRING". I don't see what it gives us to reply with the same type in a
parameter when in the rest of the protocol the encoding is different.

Attached is an updated proposal. Is this agreeable? If not can you
propose a change that is agreeable.

Regards, Christian

Troy Cauble wrote:
> 
> Christian Groves wrote:
> >
> > G'Day Troy, all,
> >
> > Attached is a PDF prosing changes to cover the encoding of sub-lists and
> > also how to encode the signal completion parameter. Terry and I sat
> > together to come up with these changes. Your thoughts? We hope that
> > these changes address the problems.
> >
> > Regards, Christian
> 
> Christian,
> 
> I have significant issues with these proposed changes.
> 
> Regarding your changes to section 12.2:
> 
>  I have no problem with the changes here to sub-list.
> 
> Regarding your changes to section E.1.2
> 
>  "String" is a 12.2 type.  "Octet String" is a proposed 12.2
>  type (AVD-2127).  Both of them have text and ASN.1 encodings.
> 
>  "Type: Text (String) Binary (Octet String)"
>  is defining SigID's as different *types* for text and ASN.1.
> 
>  This is bad.  It's analogous to saying it's an Integer in
>  text and a Double in ASN.1.  We need to pick or define a
>  single TYPE for SigID, with encodings for text and ASN.1.
> 
> Regarding your changes to "H.248 Annex A ASN.1 Syntax:"
> 
>  The encoding of lists is already covered by the following.
> 
>    Value ::= SEQUENCE OF OCTET STRING
> 
> Regarding your changes to "H.248 Annex B ABNF Syntax"
> 
>  The encoding of lists is already covered by the following.
> 
>    propertyParm         = pkgdName parmValue
>    parmValue            = (EQUAL alternativeValue/ INEQUAL VALUE)
>    alternativeValue     = ( VALUE
>                           / LSBRKT VALUE *(COMMA VALUE) RSBRKT
>                             ; sublist (i.e. A AND B AND ...)
>                           / LBRKT VALUE *(COMMA VALUE) RBRKT
>                             ; alternatives (i.e. A OR B OR ...)
>                           / LSBRKT VALUE COLON VALUE RSBRKT )
>                             ; range
> 
> Regarding your changes to "H.248 Annex B"
> 
>  I have no problem with striking the "Future types" reference.
> 
> -troy

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Nov 2001 02:21:19 +1100

G'Day Troy,

Regards, Christian

---

From: Troy Cauble <[email-masked]>
Date: Thu, 01 Nov 2001 12:17:44 -0500

Christian Groves wrote:
> to the type. I didn't see you arguing against the other changes. 

Agreed.

> I think
> is a textual string in text. 

Are signalList/signals being dropped?  Lists of SignalList signals
and non-SignalList signals?

	SigID=[pkg1/sig1,SignalList=2,SignalList=3{pkg2/sig2}]

> So I would have thought that in the Binary

You're mixing type terminology with encoding terminology.
All types, Integer, String, Boolean, etc. are wrapped in
an "OCTET STRING" for ASN.1.  All are encoded as strings
for text.

MY MAIN POINT:
I strongly feel that the TYPE should remain independent of the 
encoding.  Every parameter should have a single type, 
regardless of the encoding used.  (Again, it's like saying 
use a Boolean in text or a Double in ASN.1.  It's either 
a Boolean or a Double!)

If your desire is to reuse both text and ASN.1 signal-related 
encodings, then please define a new type, "SigID", in 12.2 and 
define it's ASN.1 and text encodings (a la IG 6.46 and 6.80).

(The above is a terminology argument and doesn't
really change the implementation of your proposal.)

Regardless of whether you call it a new SigID type, or call it
two types based on the encoding (boo, hiss), you need detailed
encoding definitions.  Vague references to Annex A and B aren't
enough.  And the closest existing elements allow parameters that
aren't appropriate for SigID.  If signal lists are still in the 
mix, the definitions would look like this:

   sigID           = signalListSig / signalName

   signalListSig   = SignalListToken EQUALX signalListId [ LBRKTX
                          signalName RBRKTX ]

   ; standard defs allow EOL and COMMENT which are illegal in quotedString
   ; maybe we should just take out the "*(WSP)" portions too
   EQUALX          = *(WSP) %x3D *(WSP) ; "="
   LBRKTX          = *(WSP) %x7B *(WSP) ; "{"
   RBRKTX          = *(WSP) %x7D *(WSP) ; "}"

   SignalListSig ::= Sequence
   {
	id		INTEGER(0..65535),
	signalName	SignalName OPTIONAL
   }

   SigID ::= CHOICE
   {	signalName	SignalName,
	signalListSig	SignalListSig
   }

MY SECONDARY POINT:
Frankly, I think the text parsing is minimal and the pain of 
developing ASN.1 code for the above outweighs the benefit
of saying you're using the same 4-octets that are used 
elsewhere for SignalNames.  

But I could live with this.  The type vs. encoding terminology
is what I really care about.

> propose a change that is agreeable.

Sorry.  I honestly don't have time to write it up.
Feel free to use the encoding definitions above, though.

Hopefully, my reasoning is clear this time.

-troy

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

---

From: Troy Cauble <[email-masked]>
Date: Thu, 01 Nov 2001 12:17:44 -0500

Agreed.

MY MAIN POINT:

   SigID ::= CHOICE
   {	signalName	SignalName,

MY SECONDARY POINT:

-troy

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Nov 2001 04:28:44 +1100

G'Day Troy,

The proposal does remove singalList/signal. Only a single SignalID is in
SC. SignalListID gives the listID in a separate parameter. You then
don't need the complex ASN.1 and ABNF description.

Are you agreeable to this change?

Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Nov 2001 04:28:44 +1100

G'Day Troy,

Christian