Subject: Re: User Petition on Standards to Netscape and Microsoft

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Dec 1997 12:06:51 -0500 (EST)

As far as I know (and I'd like to be wrong here...), there is exactly one tool
capable of generating PER  parsers, at about 20-30k$ per platform to be supported.Parsing even basic PER as in H.245 is extremely tedious by hand. I thus can only
echo  Christian's remark.

Henning

---

From: Bancroft Scott <[email-masked]>
Date: Tue, 30 Dec 1997 13:25:45 -0500 (EST)

On Tue, 30 Dec 1997, Henning Schulzrinne wrote:

> As far as I know (and I'd like to be wrong here...), there is exactly
> one tool capable of generating PER  parsers, at about 20-30k$ per
> platform to be supported.

That one tool must not be the OSS ASN.1 Tools, which is far less expensive
than 20-30K$ for most platforms.  And after the first platform the cost
for additional runtime platforms range between $2800 - $6250, pre-ported
and fully tested on whatever platform you want at no extra charge, usable
on as many of your development machines as you like, and distributable
free of royalties when embedded in your application.  Not to mention
discounts such as 54% off for academic institutions. 

> Parsing even basic PER as in H.245 is extremely
> tedious by hand. I thus can only echo  Christian's remark.

I'm baffled, for this is PRECISELY the reason why having a fully parsable
syntax such as ASN.1:1994 from which encoder/decoders can be generated is
crucial.  Were it not for such a notation it would not be possible for
video phone products to get to market as quickly as they have.  Had ASN.1
and PER not been used, I am sure that we would still be sitting around
waiting for the dream of the 1964 World's Fair, video telephones in
everyone homes, to become reality instead of its marching into homes as
it is today.

I have yet to see a single alternative that comes close to ASN.1 and its
encoding rules. Do you have an alternative that is proven to be nearly as
good for a wide range of protocols of varying levels of complexity?

BTW, you complain of the difficulty of parsing basic PER.  The objective
behind PER is to provide highly compact encodings that are suitable for
use in audio/video applications, aircraft/ground communications, road
telematics and other applications where the available bandwidth is at a
premium.  It does not matter what solution you arrive at, you are going to
have the same sort of bit compaction solutions that PER employs; use of
ASN.1 simply makes the job a whole lot easier.  Intel, Microsoft,
PictureTel and other main players in audio/video over Internet would not
have chosen ASN.1 and PER and stuck with them had there been a better
solution or if they posed the problems that you allege.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

---

From: Bancroft Scott <[email-masked]>
Date: Tue, 30 Dec 1997 14:32:55 -0500 (EST)

On Tue, 30 Dec 1997, William Allen Simpson wrote:

> ... I'm not sure that I know what those non-backward compatible
> changes to C were.  I've only been using C since 1980 (maybe '79).
> Perhaps you are referring to something before that?

There were many changes introduced that broke existing C compilers, such
as introduction of new keywords like void, const, volatile, enum, signed,
the introduction of function prototypes, trigraph sequences, the
concatenation of adjacent string literals, and assignment of structures,
unions that can be statically initialized.  Shall I go on? 

And there were many changes that used to work in the first version of C
that cannot be compiled by C compilers that conform to the current
version, such as use of the assignment operator =+, the free mixing of
pointers and integers without the use of casts, external declarations
without any specifiers or qualifiers.  Shall I go on? 

> As best as I remember, my C code written for Ron Cain's small c compiler
> on the Z80 (which I personally extended from time to time), all pretty
> strictly K&R, still compiled on Borland's C for the '88 and DJ's GNU C
> for the 386 without any syntactic changes other than header file names.

That is very well possible.  Just as it is very well possible to write
ASN.1 modules using the 1988 version of ASN.1 that is 100% conformant
with ASN.1:1994, and visa versa.  
 
> Unfortunately, I've never liked C++, and use it as little as
> possible....  So, I don't know what the non-backward compatible changes
> were there, either.  I have not noticed any syntactic changes, like
> added colons or semicolons or parenthesis, to anything that I have used.

As I said above, that is quite possible.  It all depends on what features
of early C you used. 
 
> > The essense of ASN.1 was not changed between 1988 and 1994, and ASN.1
> > modules can be written that conform to both 1988 and 1994 ASN.1 so long as
> > they don't use any of the buggy notation corrected by the 1994 version of
> > ASN.1 (e.g., macros), or use any features unique to 1994 ASN.1 (e.g.,
> > BMPString).
> >
> Good, so there will be no problem with our MIBs?

The syntax of MIBs changes slightly, but the essence of the function
they play, how they are used, etc., has not changed.
 
> (And in his response to Christian)
> # Pagh!  More of the "not invented here" nonsense.  Take a look at how
> # rapidly Microsoft was able to develop NetMeeting, or Intel its
> VideoPhone
> # products, or how quickly the many others in the audio/video over
> Internet
> # arena were able to get the products to market, then explain to me how
> they
> # could have arrived at interoperating products in such short time if
> # ASN.1:1994 was anything short of beautiful?
> 
> With whom does NetMeeting interoperate?
> 
> With whom does VideoPhone interoperate?

They interoperate with each other, and with IBM, AT&T, PictureTel,
VideoServer, Compression Labs, and with most of the other International
Multimedia Teleconferencing Consortium members that have products
deployed. 
 
> And more importantly, do they interoperate with sd?

Never heard it.
 
> I'm pretty sure I mentioned in a previous message that all of the ASN.1
> efforts of which I am aware (other than MIBs) were not concerned with
> interoperability -- they were proprietary.

There are indeed proprietary ASN.1 specs used by the likes of FedEx,
Reuters, etc., but the majority that I am aware of are industry standards
or international standards.

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 30 Dec 1997 11:39:59 -0800 (PST)

> premium.

In audio/video, the actual data is usually very highly compressed using
very sophisticated algorithms, often based on sample-to-sample
differences.

ASN.1's encoding's achieve "compression" typically by eliding leading
zeros on a single instance of a datum.

Since for audio/video, the compressed sound spurt or video frame
represents one datum, the only benefit of ASN.1's encoding methods would
be perhaps to compress the other items in the packet, i.e. the header
fields.

This would amount to a savings of, I estimate, on the order of a few
hundredths of a percent to perhaps even a tenth of one percent.

Not a very impressive improvement.

Indeed, because of ASN.1's potential use of explicit tagging and it's
length fields, ASN.1's encoding methods can actually increase the amount
of space required in a packet.

I would suggest that if one might often improve over ASN.1/BER or PER's
use of bandwidth by encoding using text in HTML and applying gzip. 

		--karl--