Firstly, I don't think that "ASN.1" and "Text" are the only choices, nor are they mutually exclusive, as ASN.1 structures can be encoded in text. Non-ASN binary is an alternative.
Secondly, I would ask what the MG and MGC need to know about the protocols with which they deal. A SIP/POTS GW does not need to know any ASN.1, but I think that most GWs do - H.323/H.320, SIP/H.320, SIP/H.324 and even SIP/ISDN. I don't know if SIP/SS7 MG needs to.
The arguments against ASN.1 usually boil down to the complexity of the encoding. This is principally from people who do not understand it well enough to encode/decode it without the proper tools. Or the size of encoded booleans in the case of BER.
Conversely, the argument for text is that it is easy to encode/decode, and lends itself to "tricks" that speed up parsing - frequently at the expense of the stability of the "codec" and its ability to cope with changes. These "tricks" include the use of strstr() to find parameters ("X="), which fails when new parameters are added ("X-BOX="), and testing for a command as a single character ("S"), which fails when new commands ("SA") are added.
The point being that such a "tricky" parser is often faster than a rigorous and deterministic one, and a test with such a parser would not be a "fair" one. That might be a yacc/lex (or bison/flex) based parser. Input on what would be fair is solicited.
If the protocol is required to carry binary structures, such as H.245 media descriptions, then a mechanism should be defined for doing so (e.g. MIME/BASE64), and tested.
While we know that ASN.1 described protocols are extensible in clearly defined ways, the ability of a text-based protocol, and associated parser, to cope with extensions of the type described above, should be explored and tested too - not just raw speed. It seems that a large part of the "SIP bakeoff" testing is directed at determining if the SIP parsers can cope with what is expected. For upward compatibility, it would be good to test with possible extensions too, and see if they break.
My $0.02
Douglas
At 08:13 1999-04-07 -0700, Paul Long wrote:
The experiment should implement the entire protocol and include a large
set of
messages. The syntax should then be extended in various ways. Text
encoding is
seductive. At first, text looks easier than ASN.1, but as more complex structures are needed and the syntax grows, it becomes cumbersome and error-prone.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] Sent: Wednesday, March 31, 1999 9:17 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: ASN.1 vs Text Since the other responses seem to have gone off into a discussion of firewalls, let me respond to this more directly by recalling a bit ofpast discussion.
1) On the Megaco list, we finally agreed that the text vs. binaryquestion is something to be resolved by experiment.
[SNIP]
I'd suggest we start thinking about experimental design.
[SNIP]