I'd point out that ABNF and ASCII have nothing to do with each other. It
is just fine to define a binary protocol using ABNF. I'd also note that it
is very helpful for the wire protocol to contain some sort of viewable
keywords for those of us that are unfortunate enough to have to view the
protocol. I'm especially fond of the ABNF that Ryan Moats created for the
Tagged Index Object in the Common Indexing Protocol (but of course, I'm
biased). This ABNF specifically allows for the inclusion of binary data,
as well as UTF-8 encoded characters... So, I specifically disagree with
your point 2 below. I can't think of anything that would be better than to
abandon ASN.1. I don't think that there are any advantages to its use
versus ABNF.
At 11:51 AM 8/6/99 -0700, Marc Branchaud wrote:
There are (at least) a couple of issues here:
1. Are ABNF/ASCII protocols enough? Things like SMTP, FTP and HTTP are
fine protocols, but they are based on an ASCII command-response system.
Things like SSL/TLS and IPSec didn't use an ASCII protocol for various
reasons, and so I doubt that ASCII is adequate. BTW, someone sent me a
pointer to draft-cordell-messaging-00.txt which is essentially an ASCII
encoding for ASN.1 (a sort of AER).
2. We already have a lot of ASN.1 in IETF RFCs, and so I don't think
abandoning ASN.1 is a viable solution. We're stuck with ASN.1 notation,
it seems, barring some drastic paradigm shift. My thinking is we might
as well adapt that ASN.1 notation into something that maps (relatively)
easily into bits-on-the-wire.
I wasn't thinking of using this for ASCII-based protocols. I don't
think ASN.1 is a good choice for that.
M.
Phillip M Hallam-Baker wrote:
It is worthwhile to use a formalism to express the
syntax of IETF protocols. It would be much better to
capture both syntax and semantics and this is easy
enough using augmented finite state machines and such.
Using ASN.1 for the task would be futile. It would
be like trying to convert a steam locomotive to run
on roads.
I wrote a synthesizer for most of the IETF protocols
back in '92 which covered SMTP, NNTP, FTP and of course
HTTP. The data structure it used was pretty simple as
I recall - about ten pages in all. If folk are interested
I might be able to find it.
Phill
+------------------------------------------------------------------------+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL
INC.
marcnarc(_at_)xcert(_dot_)com PKI References page:
www.xcert.com
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
==============================================
Bruce Greenblatt
Directory Tools and Application Services, Inc.
http://www.directory-applications.com