ASN.1 vs Text

[Douglas Clowes]

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 at NORTELNETWORKS.COM]
>        Sent:   Wednesday, March 31, 1999 9:17 PM
>        To:     ITU-SG16 at 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 of
>past
>        discussion.
>
>        1) On the Megaco list, we finally agreed that the text vs. binary
>question
>        is something to be resolved by experiment.
>
[SNIP]
>        I'd suggest we start thinking about experimental design.
[SNIP]