H.248: Binary Encoding

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Fri Oct 15 12:10:04 EDT 1999


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: taylor at nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961



More information about the sg16-avd mailing list