H.248: Binary Encoding

[Pete Cordell]

Brian,

There's no muddling.  The line would be:

Add{<termID> blah, blah, blah}

And before you tell me that there's no separator between <termID> and blah,
you'll have to first convince me how it's impossible to read this sentence
and how a C compiler can not parse the statement "unsigned int param1;" !

I think the change is minor.  The syntax has changed a lot over the previous
months.  Relatively speaking I think the sweat is minor, and let's face, who
said they could stop sweating!!!  (And spilling a bit of sweat is preferable
to spilling lots of blood if we go back to a text vs. binary war!!!)

Pete

=============================================
Pete Cordell
pete at tech-know-ware.com
=============================================

-----Original Message-----
From: Brian Rosen <brosen at ENG.FORE.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: 18 October 1999 16:39
Subject: Re: H.248: Binary Encoding


>The reason why the ABNF is usually
>token=id LBRKT param *(COMMA param) RBRKT
>is because the id is what the command operates ON,
>whereas the parameters are what the operation DOES.
>
>Add=<termiD>{blah, blah, blah}
>or
>Stream=<streamID>{...
>or
>Context=<ContextID{
>
>The bracketed items are the parameters to the command.
>All parameters (uniformly now, I believe) are descriptors.
>
>Making the command
>Add{<termID>, blah, blah, blah}
>Muddies the id and the parameters.
>
>I don't feel all that strongly about this change other than
>it's way too late to make it.  It was suggested any time in
>the last 4 months we have been dealing with syntax issues,
>it could have been examined, weighed, and a judgment call
>made on it.  Now, it seems to me that it breaks too many
>things we are trying to not change.  People's parsers for
>example, the current ABNF (which has a lot of sweat in
>reviewers time) for another.
>
>It seems more reasonable to fix the compiler at this late date.
>
>Brian
>
>> -----Original Message-----
>> From: Pete Cordell [mailto:pete at tech-know-ware.com]
>> Sent: Sunday, October 17, 1999 7:43 AM
>> To: ITU-SG16 at mailbag.cps.intel.com
>> Subject: Re: H.248: Binary Encoding
>>
>>
>> Hi All,
>>
>> I'd like to propose a few things for discussion that might
>> make the ABNF248
>> and ABNF1711 more aligned.  In particular, one difference
>> between the two is
>> the number of brackets.
>>
>> ABNF248 has a lot of constructs of the following:
>>
>>     token EQUAL id LBRKT param *( COMMA param ) RBRKT
>>     token LBRKT param *( COMMA param ) RBRKT
>>
>> and also does (which I suppose is the general case):
>>     token [ EQUAL id ] LBRKT param *( COMMA param ) RBRKT
>>
>> ABNF1711 naturally has the following structure:
>>
>>     message = *( parameter )
>>     parameter = *( tag EQUAL ) value-field *( COMMA value-field )
>>     value-field = value / tag / "{" *( parameter ) "}"
>>
>> This is close to what is in ABNF248 if we move the position
>> of LBRKT around
>> in the first case:
>>
>>     token EQUAL LBRKT id param *( COMMA param ) RBRKT
>>
>> and add an EQUAL in the second case:
>>
>>     token EQUAL LBRKT param *( COMMA param ) RBRKT
>>
>> Unfortunately an optional untagged item at the beginning of a
>> construct is a
>> problem for ABNF1711.  This is because in general (although
>> not necessarily
>> in the megaco case) it would make the identification of parameters
>> ambiguous.  This means that the third variant ideally needs to be:
>>
>>     token EQUAL LBRKT ( id / "-" ) param *( COMMA param ) RBRKT
>>
>> This doesn't seem a radical change to ABNF248, and even if
>> the code is hand
>> crafted ought to be fairly easy to accommodate.  Naturally,
>> any use of tools
>> should make this even easier.  In my opinion it also looks
>> more intuitive,
>> although I guess it's a bit boring and lacks a bit of
>> designer flair!!!
>>
>> Is it possible to discuss such changes?
>>
>> Pete
>>
>> P.S. The corresponding ASN.1 for the above are:
>>
>> token ::= SEQUENCE { id AS ? id, param AS ? SEQUENCE OF param }
>> token ::= SEQUENCE { param AS ? SEQUENCE OF param }
>> token ::= SEQUENCE { id AS ? CHOICE { present AS ? INTEGER, none AS -
>> NULL },
>>         param AS ? SEQUENCE OF param }
>>
>> =============================================
>> Pete Cordell
>> pete at tech-know-ware.com
>> =============================================
>>
>