I don't accept this case.
The priciple problem with ASN.1 is that there are enough people
who violently detest it that the syntax issue is continually
being revisited. We get this in PKIX about twice a year.
I certainly don't suggest rewriting ASN.1 protocols in ABNF
or any other formalism for that matter, just as I do not propose
to revisit the ABNF decision for HTTP.
Once a system is deployed it is a legacy system. It is futile
to revisit core design decisions. For the ABNF parser I wrote
I developed the formalism to match the practice and not vice-versa.
If one has the luxury of starting from scratch with no legacy
BOTH approaches (ABNF, ASN.1) strike me as defective. The designers
of SSL took the right decision in my view in choosing a formalism
which was very simple and had a direct mapping to a well supported
programming language.
Development of a formalism requires expertise but so does
programming. It is not as time consuming as some would suggest.
Certainly my experience suggests that attempting to re-use
ASN.1 is more time consuming than starting from scratch with
a less baroque approach.
Attempts to rewrite ASN.1 systems in ABNF and vice versa strike
me as equally pointless and profitless exercises.
The correct comparison to make in my view is with a defunct
programming language. I would not advise anyone to code a
new system in COBOL or FORTRAN (ASN.1) nor would I suggest
existing systems be rewritten in Java.
And of course there will always be people who claim COBOL
and FORTRAN are not defunct.
Phill
-----Original Message-----
From: owner-ietf-smime(_at_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)imc(_dot_)org]On
Behalf Of Marc Branchaud
Sent: Friday, August 06, 1999 2:51 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: ASN.1 for the Internet (was Re: Compressed data type for
S/MIME)
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