Subject: H.248: Binary Encoding

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 15 Oct 1999 11:10:04 -0500

Next week in Redbank promises to be very heavy.  One of the more difficult
issues will be the status of the binary encoding sections.  To make sure we
don't waste time on non-issues, I would like to see if we can agree on some
principles in advance of the discussion.

First point: all our detailed work so far has been on the ABNF expression of
the protocol.  I would therefore hope that we can agree that the ABNF is the
definitive statement of the protocol content for H.248v1.  This could change
in future versions.

Corollary 1: This means that any additions or changes we agree to in Redbank
should be expressed in terms of changes to the ABNF first, before
propagating them to any other form of specification.

Second point: Any other form of specification must demonstrate its
conformance to the content of the ABNF, but this is not a requirement for it
to conform to the exact expression of that content.  In other words, if
APC-1711, for instance, demonstrates that the original ASN.1 specifies every
field in its right place and with its right type, the fact that Pete's tool
adds extra tags and brackets is irrelevant.

Third point, more controversial: The purpose of an alternative form of
protocol specification should be carefully considered.  The particular form
of specification should meet that purpose.  Concretely speaking, what I have
in mind is that Pete's ASN.1 modifications could be a valuable tool to
confirm conformance of an ASN.1 specification to the ABNF content, but they
also introduce a source of potential error in actual creation of binary
code.  In my personal opinion, it would be better for H.248 to contain
either vanilla ASN.1 or a clause by clause mapping of the ABNF into a
hand-coded TLV representation within H.248.

Final point: If work on the chosen binary-friendly representation seems to
be too rushed, I would strongly urge that we determine the related annex(es)
separately from the main document.  That way we could come into the February
meeting with a high degree of confidence in the overall product.
Determining the binary-friendly specification at the February meeting would
have the same practical effect as deciding it, since there would be no way
to change it before decision in the fall WTSA meeting.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: Pete Cordell <[email-masked]>
Date: Fri, 15 Oct 1999 19:08:37 +0100

Tom,

On this point....
>hand-coded TLV representation within H.248.

We've come up with the idea (actually I had little to do with it :( ), of
putting the additional syntax needed in a special type of comment,
i.e. --& --.  So you can do:
    parameter1  --& AS ? -- INTEGER, etc

This means that a standard ASN.1 compiler does not see all the additional
stuff, but the converter knows to read into it.  The result is that you get
one piece of syntax that can be parsed both by a standard 'vanilla' ASN.1
compiler, and by the converter.

This feature hasn't been used in the definition yet, partly due to time
(this was a late addition to the converter) and I was worried the extra
seemingly weird characters (if you don't understand what's going on) may
unnecessarily confuse people.

I hope this goes some way to settling your worries about two forms of ASN.1.
John will be able to explain more next week.

Pete

=============================================
Pete Cordell
[email-masked]
=============================================

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 15 Oct 1999 13:19:18 -0500

> -----Original Message-----
> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Friday, October 15, 1999 1:16 PM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH];
> [email-masked]
> Subject:      RE: H.248: Binary Encoding
>
> I would NOT agree with your second point.
>
> The protocol definition is decided.  We can make some edits
> to it to resolve problems that may be identified, but it's
> essential character has been debated, argued, and decided,
> formally and informally.  Several groups are already building
> parsers for it as evidenced by the level of comments received.
> I am strongly opposed to retreating from the agreement which
> was recorded by Nancy Greene:
        [[TomT]]
        No problem with anything before the last sentence.  The last
sentence is problematic because the "agreement" has no power beyond the good
faith of those who made it and their acceptance that Nancy recorded it
correctly.

> Agreements: ABNF remains normative. ASN.1 and compiler to compile
> into the ABNF already written,  will also be added as normative
> when they are available. Sentence added: " This compiler is a
> living tool that will likely be enhanced over time. To start,
> this tool should be tested to verify that syntax can be compiled
> to the ABNF defined below."
>
> If the compiler points out some kind of inconsistency in coding
> that should be resolved, we should make those edits.  If there
> are truly minor differences that are resolvable with a couple of
> simple edits to the ABNF and no significant increase in message
> size, I'm not going to object.  However, if the compiler can't
> reproduce the ABNF semantics and syntax as currently conceived,
> the agreement is not met, which means the ABNF represents the
> normative encoding, and there is no ASN.1 definition,
> nor binary encoding in this version of the protocol.
        [[TomT]]
        You're confusing encoding with specification here.  The ABNF by my
first point provides the definitive specification of message content.

> A deal is a deal.
>
> Further:
>
> Creating a vanilla ASN.1 description would have to be informative, since
> there would be no way to be sure it aligned
> to the normative ABNF
        [[TomT]]
        And that's where I'm saying Pete's tool could help to verify the
mapping.

> Similarly, a clause by clause mapping to a TLV could introduce
> semantic differences between a binary and text representation.
> Besides, TLV encodings were suggested (by me, among others)
> and rejected.
>
> Brian
>
> ------------
> Brian Rosen, Principal Engineer
> FORE Systems, 1000 FORE Drive, Warrendale, PA 15086
> (724) 742-6826  mailto:[email-masked]
>
>
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Friday, October 15, 1999 12:10 PM
> > To: [email-masked]
> > Subject: H.248: Binary Encoding
> >
> >

---

From: Brian Rosen <[email-masked]>
Date: Fri, 15 Oct 1999 13:15:43 -0400

A deal is a deal.

Further:

Brian

------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 15 Oct 1999 20:15:23 -0500

I should add something that was so obvious to me that I didn't think to
state it: I trust everyone agrees that the ABNF is the definitive
specification of the text encoding for H.248v1.

> From: Taylor, Tom-PT [CAR:B904-I:EXCH]
> To:   [email-masked]

---

From: Pete Cordell <[email-masked]>
Date: Sun, 17 Oct 1999 12:43:06 +0100

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 }

---

From: Brian Rosen <[email-masked]>
Date: Mon, 18 Oct 1999 11:30:39 -0400

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

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Sunday, October 17, 1999 7:43 AM
> To: [email-masked]
> Subject: Re: H.248: Binary Encoding
>
>
> Hi All,
>