[
Lists Home |
Date Index |
Thread Index
]
On Mon, 09 Feb 2004 08:10:30 +1100
Rick Marshall <rjm@zenucom.com> wrote:
> the point of my original post was to ask whether there is an xml
> schema/dtd covering email; whether there is work on it; whether there
> are email clients that support it.
I saw an internet draft announcement, once. I admit that all I did was
laugh. I think it's a remarkably silly idea, personally.
> my point is that if soap and the work on xml security really does work
err. Using XML for asynchronous messaging must sooner or later deal with
the same issues of anonymity and responsibility that SMTP left to the
ARPAnet/internet terms of service (no commercial use, no abuse). This
worked for SMTP when the scale was thousands of sites each with thousands
of users, and so long as everyone had to agree to the backbone's terms of
service. All that changed in the early nineties (tens and hundreds of
thousands of systems, some with millions of users; commercial use
permitted).
WS-Addressing, as an example, repeats all of SMTP's mistakes, permitting
easy forgery, and discarding the addresses that are more or less
verifiable. It has even worse trace features than SMTP (as deployed in
various higher-layer specs that use it). The solution to this (please
pardon my harshness) stupidity is to wave one's hands and proclaim that
the magic PKI pixie dust will solve it. Which, in fact, is feasible for
limited, by-invitation networking, but completely fatuous for anything of
larger scale.
While the writers of the composable architecture for web services are
repeating mistakes made twenty years ago, well-identified ten years ago, I
have little confidence that we'll see these technologies displace
anything. If they want to displace something as ubiquitous as
SMTP+{IMAP|POP}, they have to at least do a *better* job. Doing the same
old nonsense with magic XML pixie dust sprinkled in is just an irritation.
Well-formed spam is not a solution to any problem that I can think of.
> then an xml based mail system using those technologies (or similar)
> could go a long way to fixing the problems we were/are discussing re
> viruses/spam etc and if xml databases are working well then they would
> be a natural for storage and retrieval of email.
I absolutely fail to see how. The problem of spam is related to the
problem of responsibility (this in the material that Len referenced, btw).
Senders are not responsible. "I got this from somewhere, and you're
closer to the place where it ought to be delivered, you take it." SMTP's
emphasis on "deliver the mail, whatever else happens" was appropriate for
the time, but in permitting relays, forgery, and proxies to enable this,
has failed dramatically in an environment that can't spend the energy to
trace abusers.
And XML does nothing, by itself, to ameliorate these problems. It's true
that many of the SMTP repair proposals also make heavy use of magic PKI
pixie dust, but the fact that they're bone-headed doesn't give permission
to mess up email content as well.
Moreover, using XML as a document format for email is really wrong. In
the end, that "get the mail through" attitude has to persist, to some
degree; internet sleet, snow, and dark of night should not stop delivery.
Accidental ill-formedness shouldn't stop delivery either. Note that
precisely *none* of the headers in your email are the "problem" for spam;
the mail transfer agents *don't look at them*. They use the SMTP commands
MAIL FROM and RCPT TO (and then throw those addresses away, so mail users
can't see them (yes, I know how to recover the information, in some
cases, but it isn't easy)). Formatting the ignored parts of the message
(that is, headers and body in current SMTP, presumably some equivalent in
XML) rigidly doesn't even begin to address the problem, 'cause the problem
isn't in the parts that are being ignored. Worse, it makes it harder for
intermediate servers to supply headers (XML is not an ideal format for
prepending to, which is how the trace headers in SMTP work).
A replacement for SMTP ought to start from KISS, which means keeping the
concept of headers and body, and line-by-line messages (provide better
escapes to binary, by all means, but keep it text; that's what email is
about). Doing it as XML provides rigidity in all the wrong places. Let
headers contain UTF-8. Update MIME to default to UTF-8 and give it better
handling of binary content. Change the required minimum maximum line
length (awkward phrase, but the specification requires that if a processor
enforces a maximum length, then it must be *at least* X, where X is 78 or
998, +CRLF, in various contexts).
> as for the rfc's themselves. the system ain't broke, but it could be
> improved. content is a separate issue. if the rfc's were published as
> xml then again they could be part of an intelligently searchable
> database. i think this would be a good use for xml.
*sigh* Many rfcs are written as XML. There are some pretty good reasons
not to provide those as the canonical format for rfcs (although I'm a
little less than completely conviced, honestly). Third party repositories
provide some of the functionality that you're looking for; given the high
load and low budget of the IETF, why should it take on this task?
> it bothers me that we've come all this way, but when we still want
> maximum interoperability we just go straight back to good old ascii .txt
> files.
ASCII or UTF-8, without the strong well-formedness constraints of XML,
simply *are* more robust than XML for things like headers.
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
There's someone in my head, but it's not me.
-- Pink Floyd
|
