FW: H.248: Binary Encoding

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Fri Oct 15 21:15:23 EDT 1999


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.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904-I:EXCH]
> Sent: Friday, October 15, 1999 12:10 PM
> To:   megaco at standards.nortelnetworks.com
> Subject:      H.248: Binary Encoding
>
> 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