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