RE: What I see as problems to solve ... and a strawman solution

	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: [email protected] [mailto:[email protected]] On
> Behalf Of Kai Henningsen
> Sent: Sunday, February 01, 2004 3:48 PM
> To: [email protected]
> 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.