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

From: [email-masked] (Michael P DiGioia)
Date: Tue, 30 Dec 1997 21:29:32 -0500

Herb,

>>With talk of reverting to BNF-style syntax from which encoder/decoders
>>cannot be automatically generated, I fear we are being pushed back 
>>the stone age. The ability to make use of ASN.1 compilers is to me
>>the primary reason for even thinking of using ASN.1.

I don't believe anyone is making this recommendation. The primary thread
of subject is that application protocols require different tools than low
level/layer protocols. Speed is the name of the game and every instruction
cycle cost is amplified at the lower layers. The primary concern at the 
application layer is complexity and protocol features.

Fixed format protocols have their place but not for the feature full 
future internet apps.; Textual representations are required.

/mpd

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Tue, 30 Dec 1997 21:58:40 -0500

> future internet apps.; Textual representations are required.

Michael,

I think that Herb accurately nailed a couple of points that you 
overlooked. "Speed is the name of the game" at the application
layer, too. But the sense is different than what you described
above for the low levels. For applications, its time to market

  "Having a notation that allows a compiler to generate my 
  data structures as well as complete encoder/decoders makes 
  a world of difference between being able to get portable, 
  reliable and fully interoperable code completed as quickly
  as possible versus my people having to dwell on the details 
  of encoding and decoding. As a District Manager, directing 
  software development, I prefer that my teams spend their time 
  being productive rather than wielding stone axes."

with reliable product. For global markets, that always means 
builtin national language support, extensibility, and multiple
platform support. The intrinsic simplicity of being able to
use printf's for debugging seem to be lost on a lot of the 
folks that have to pay the bills, and loose market share to 
boot. 

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

---

From: Chris Newman <[email-masked]>
Date: Wed, 31 Dec 1997 12:58:10 -0800 (PST)

On Tue, 30 Dec 1997, Phillip H. Griffin wrote:
> ...
>   ...
> platform support.

Time to market is an important issue (although I'd rank it below
interoperability for importance to a standards body).  Interestingly
enough, SMTP/MIME products have demonstrated a much faster time to market
than X.400 products as well as a much higher level of interoperability,
i18n and extensibility (all this despite precision problems with the SMTP
and message format specs and the failure to design any i18n support in
from the start).  To be fair, ASN.1 is only part of the problem with
X.400. But I see no evidence that ASN.1 reduces time to market. 

The marginal time savings of being able to compile a grammar vs. writing a
textual protocol parser (probably a few days at worst) is negligable
compared to the time to market savings of being able to debug a textual
protocol just by looking at it.  If debugging is easier it also increases
reliability, interoperability and customer responsiveness.

ABNF and textual syntaxes hasn't stopped the IETF from developing
sophisticated application protocols like HTTP (167 pages) and IMAP (81
pages).  Since the tools we have are working, I see no reason to trade
them in for ASN.1 with its poor track record in real-world application
protocols.

		- Chris