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