ietf
[Top] [All Lists]

RE: ASN.1 (Re: Pretty clear ... SIP)

2003-08-26 07:28:06
Good points, esp. the references to 2234.

May I also point out that many SIP stacks use automatically generated
parsers from the ABNF description.  These have many, but not all, of
the advantages claimed by ASN.1.  It was a goal of the RFC3261
work to make the ABNF grammar complete enough to use a parser generator.
Strict compliance to 2234 is helpful in this regard.

The proof is in the pudding.  Our experience with interoperability testing
is quite good, and contrary to statements on this thread, most current
systems interoperate with very old SIP devices.  This is more true of
old SIP phones than it is of old proxy servers.  If you use a time line
based comparison (age of spec vs interoperability results), I think you
would find SIP beats the pants off of H.323, which in the first several
years was dismal, but of late is pretty good. 

Also note that SIP is quite compressible, c.f. RFC3320, and the wireless
folks, currently one of the applications most concerned with the 
number of bits on the wire, seem quite content with compressed SIP, and
are not beating the doors down for ASN.1 encoding.

This version of the ASN.1 debate at least is focusing on PER.  The
last one I remember was the Megaco debate, which was BER based.  They
lost that one; the work showed BER encoded ASN.1 was both longer and
slower than text encoded.  With Megaco, you have directly comparable
messages.

Brian

-----Original Message-----
From: Harald Tveit Alvestrand [mailto:harald(_at_)alvestrand(_dot_)no]
Sent: Tuesday, August 26, 2003 2:50 AM
To: Karl Auerbach
Cc: IETF
Subject: ASN.1 (Re: Pretty clear ... SIP)


Aah.... an ASN.1 firefight!
It's been a LONG time since we've had one of those, but they 
used to be a 
regularly scheduled event on this list.

I used to have opinions on this debate - for a trip down 
memory lane, check 
out the "canonical X.400 vs SMTP debate" on my website (sorry, typing 
offline at the moment - google will find it).

One note, however:

--On 25. august 2003 15:16 -0400 Dean Anderson <dean(_at_)av8(_dot_)com> 
wrote:

It is certainly true that net telephony and conferencing need
extensibility - but I would suggest that the hooks for 
extensibility
ought to be concisely defined and placed in specific parts of the
protocol structures (such as the SDP part of today's call 
establishment
protocols). I see no need to burden the entire protocol 
representation
under a mutable layer of complexity such as ASN.1 when there is no
reason that can be articulated to require such mutability.

ASN.1 is not automatically extensible.  You have to specify 
where the
protocol can be extended.  If you don't use extensions, it should be
possible to have an ASN.1 runtime that omits the code to 
handle them. (One
of many possible runtime optimatizations that are possible 
but rarely seen
in practice, except with hand-coded encoders/decoders)

One warning to those with long memories and strong opinions:

The way one does extensibility in ASN.1 has changed greatly 
since the first 
(1984) versions of ASN.1. Lots of the hard opinions people 
have here are 
based on ASN.1(1984) experience, which was what SNMP originally used.

I have had people tell me that the post-1988 versions of 
ASN.1 are really 
nice in this department, but haven't used ASN.1 seriously since 
approximately 1992 (when PER was just being stabilized).
So I'm not qualified to say whether they are right or not.

Aside on complexity: The definition of ABNF, the "formal" 
language used to 
define the SIP syntax, RFC 2234, is 14 pages long, and has 
been blasted by 
several people as being a too complex tool for proper 
protocol description.

I haven't checked the pagecount of the ITU recommendations 
defining ASN.1 
recently, but the last time I had one in hand (X.208/88), I'd 
estimate it 
as at least 10 times that number of pages.

                      Harald








_______________________________________________
This message was passed through 
ietf_censored(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, which is a sublist 
of 
ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed. Decisions on 
what 
to pass are made solely by Raffaele D'Albenzio.






<Prev in Thread] Current Thread [Next in Thread>
  • RE: ASN.1 (Re: Pretty clear ... SIP), Rosen, Brian <=