The problems you are describing with ASN.1 are really the problems
with how it is used inside X.400. It is capable of doing anything XML can
do other then being easily human readable/writeable. I wouldn't dismiss it.
The basic advantages are large when lots of processing is required (like on
a busy mail server). Handling of binary data without encoding will reduce
the bandwidth and processing footprint. Encoding numbers and date/times
prevents the requirement to reparse.
73,
Shawn
-----Original Message-----
From: owner-mail-ng(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-mail-ng(_at_)mail(_dot_)imc(_dot_)org] On
Behalf Of Kai Henningsen
Sent: Sunday, February 01, 2004 3:48 PM
To: mail-ng(_at_)imc(_dot_)org
Subject: Re: What I see as problems to solve ... and a strawman solution
[...]
ASN.1 is pretty far from where we are now (but admittedly it is what
X.400, once the "other" mail format, used), and it seems to be much harder
to compatibly expand - given that's where our problems with 822 came from,
that doesn't sound like a good choice.
XML - while still more complicated than one might wish - certainly has
support for everything we might want to do. It is a text format, just like
822. And it is, by now, very widely deployed - it is hard to imagine
anyone needing to manipulate mail who does not have access to at least one
XML toolkit.
And while XML, again, still seems more complicated as necessary, it is
significantly less complicated than current 822+friends, plus it is fairly
easy to make it even less complicated just by chosing some rules on how to
use it, which as far as I can see we're certainly entitled to do. We don't
*have* to use all the options, so long as what we do use still follows the
rules.
For example, we can say that only one character set is allowed; that only
certain attributes are allowed (for example, those specifying language),
and everything else has to be done with tags and text; that only one date
format is supported; that XML comments are not allowed; and so on. This
should then even make it feasible to write do-it-yourself XML parsing and
generating code - not that I would necessarily recommend that.
MfG Kai
PS. I just remembered one extra detail that seems relevant to my strawman
proposal.
The original Content-Length: was in the middle of the header; even in XML
it would require parsing the header first.
Much better to start every header with a line containing the length of the
entity.
That means every entity would be
digit+ CRLF XMLheader body
where the body starts immediately after the closing XML tag (or one could
insert a CRLF there, too) and the total number of bytes after that first
CRLF is the number encoded before it.
Makes it fairly trivial to seek around in a mail.