I might be occupied this afternoon so I want to say something beforehand.
Please accept this as my input for today's XMPP session.
Are its encodings too large for DNS? It skirts the maximum DNS UDP packet
size as described in marid-core too often that it's going to exceed it for
any records describing more than two or three senders. Even RMX used
simpler, shorter descriptions and it too became too large for DNS UDP.
Seeing XML also leads to to something Doug brought up some time ago: Even if
XML was useful, why encode it in UTF-8 by default?
Both XML and Unicode are convenient choices for authors whose employers use
those technologies natively in their implementations. These are not as
convenient for anyone else. I think we don't need to concern ourselves with
making life convenient just for one vendor. And even with that, there are
other vendors who develop e-mail for the same vendor's platform that would
not benefit from the same convenience.
As for storing XML documents in other locations and referring to them in DNS:
That solves the DNS packet size problem but it doesn't solve the bandwidth
problem. Again, some time ago someone posted an example XML document that
weighed in at about 450 bytes. The average e-mail in this list is about 3 KB
in size. That's a 12% increase in bandwidth to receive a message on this
list - best case! With smaller messages it gets worse, and I haven't even
included the DNS overhead in fetching the pointers. By comparison, DMP added
a mere 4% increase in its worst case, and 1% and less in best cases.
I remind everyone that e-mail isn't going to die if we don't come up with
something by August. If we rush into this with what's on the table now we're
going to come up with a cure that's definitely worse than the disease.
On the plus side, some very useful things have come out of marid-core and
marid-submitter:
The Resent-From: header is a good thing to check against to allow remailers,
including mailing lists and forwarders. It places accountability on the
remailer. For those who choose to check 2821 instead of 2822,
marid-submitter provides a good compromise to remailers. These could be
adapted to any of the original input proposals.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>