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