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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 26 Aug 2003 08:58:06 -0400

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:[email-masked]]
> 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 <[email-masked]> 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 
> [email-masked], which is a sublist of 
> [email-masked]. Not all messages are passed. Decisions on what 
> to pass are made solely by Raffaele D'Albenzio.
>