I agree. When I see BNF I think of implementing with tools like lex & =
yacc or
JavaCC, but I don't think they would work too well for IPP. I think it=
would
be great to have a machine-readable grammar for IPP. Or, less preferab=
ly, an
ASN.1 definition, naturally machine-readable.
-Carl
---------------------- Forwarded by Carl Kugler/Boulder/IBM on 01/06/98=
10:52
AM ---------------------------
ipp-owner at pwg.org on 12/30/97 01:25:17 PM
Please respond to ipp-owner at pwg.org @ internet
To: ipp at pwg.org @ internet
cc:
Subject: IPP> FW: User Petition on Standards to Netscape and Microsof
This is part of an interesting thread going on regarding
the pros and cons of binary vs. ascii encodings of
application layer protocols...The central theme being
the use of ABNF for specifying text-based application
protocols vs. ASN.1 for specifying binary application
protocols. Apparently, we (the IPP WG) are breaking
new ground in our use of ABNF for essentially a
binary protocol. It doesn't appear that the essence of
ABNF was designed for this...
Randy
> -----Original Message-----
> From: Chris Newman [SMTP:Chris.Newman at innosoft.com]
> Sent: Tuesday, December 30, 1997 4:43 PM
> To: Stephen Kent
> Cc: ietf at ns.ietf.org> Subject: Re: User Petition on Standards to Netscape and Microsoft
>> On Tue, 30 Dec 1997, Stephen Kent wrote:
> > I would not disagree with the characterization of textual
> protocols
> > as easier to debug without the need for more sophisticated tools.
> However,
> > debugging ease is not the only consideration when designing
> protocols. IP,
> > TCP, UDP, PPP, and other widely used Internet protocols are not
> textual,
> > yet we have managed to debug them and deploy interoperable
> implementations
> > for many years. We respectually disagree about the relative merits=
> of
> > using non-textual syntax for protocols, whether it's ASN.1 or
> alternatives.
>> If you read my message carefully, you will note that I said
> "application
> protocols." The four protocols you've listed are not application
> protocols and therefore have different design criteria (which tend to=
> discourage the use of ASN.1 for different reasons).
>> The most successful IETF binary-encoded application protocol is
> Telnet,
> which is generally considered a good example of how not to design a
> protocol (due to the complexity of option negotiation and debugging
> thereof). It took me significantly longer to write and debug a telne=
t
> client than it took me to write and debug clients/servers for textual=
> protocols. I had to build a complex debugging service into the clien=
t
> which I've never needed in textual protocols. I will note that telne=
t
> has
> orders of magnitude more deployment than its ASN.1 based counterpart
> which
> is yet another strike against ASN.1, even when a binary encoding is
> used.
>> As an application protocol developer, I trust the judgement of
> lower-level
> protocol developers to make the right choice in the binary vs. text
> encoding tradeoff. But at the applications level, both IETF history
> and
> my personal experience weigh heavily in favor of textual protocols.
> Let's
> not ignore our successful history.
>> - Chris
=