Re: Use of XML as a basis for e-mail

On 2/3/2004 3:21 AM, Paul Crowley wrote:

> I think it's still *way* too early to be discussing this sort of
> detail, but for what it's worth... I understand the temptation to say
> that the world should settle on ONE generalised tree format and use it
> for everything, to bring some control to file format hell.  I have a
> lot of sympathy, but a big point of disagreement.
> 
> The world needs TWO generalised tree formats.  It needs one very rich,
> expressive one that's good at handling text and whose fundamental unit
> is the character, and one very simple, sparse one based on octets that
> easily and efficiently handles arbitarary binary content and which is
> incredibly easy to parse.

My feeling is that we're blurring the human-to-human vs general transport
lines again.

The overall transport doesn't need a specific body-type; it should be
content-neutral, since there are many potential usages, and MIME can
pretty much handle those variances without much additional effort on our
part. Applications that want/need to exchange automata shouldn't be forced
into using a body format that doesn't suit them. If we agree on that, then
we're pretty much left to agree that mime-type and CTE declarations for
the message body are the major concerns, while the content-types are for
the applications to worry about.

Talking about the characteristics of the preferred human-to-human format
does make sense, but in the context of that specific application. Some of
the features I'd personally like to see supported in an H2H format:

   eliminate hard line-wrapping; flowed by default

   eliminate the '>' metaphor; in-band references and annotations

   allow sender- and recipient-side display formatting alike

All of that stuff (and more) could be folded into a new MIME type along
with the various rules and such, and XML or some other markup language
could be used for that.

At the same time, the system should also allow the transport of legacy
text/plain, or a futuristic application/sql-response, and anything else
that might be transported between the disconnected processes.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/