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@tech-know-ware.com =============================================
-----Original Message----- From: Brian Rosen brosen@ENG.FORE.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@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@tech-know-ware.com] Sent: Sunday, October 17, 1999 7:43 AM To: ITU-SG16@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 ) RBRKTand 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 ) RBRKTand add an EQUAL in the second case:
token EQUAL LBRKT param *( COMMA param ) RBRKTUnfortunately 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 ) RBRKTThis 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@tech-know-ware.com =============================================