[
Lists Home |
Date Index |
Thread Index
]
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 was perhaps flippant in my email subject, but not in my questions or
intent.
my point is that if soap and the work on xml security really does work
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.
perhaps a two part solution - xml mail delivered as a mime type to non
xml mail systems (with xml mailers able to recognise other xml mailers
and do the mime encapsulation if necessary and xml mailers receiving xml
mail inside a mime encoded message can strip it out before processing)
this would then be compatible with existing mail systems. xml mail can
then be verified using all the work of the xml security things and non
xml mail handled as we do now, but obviously with less confidence.
the rfc's would then be easily extended and perhaps we could even have
email servers that can query a central rfc dtd to find out about the
mail headers. making email servers/clients automatically improve their
handling of email headers.
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.
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.
to me it's a bit like vinyl. that was the last sound storage system that
could be replayed mechanically. all you need is a needle and a paper
cone. try that with a cd. well ascii .txt is a bit like that. you don't
need any extra software to read it (cat or type being the equivalent of
a needle and cone). but just like the recording industry i think there
are big gains from using more sophisticated techniques to code our
information and standards, even at the loss of some basic portability.
rick
On Mon, 2004-02-09 at 06:58, Bullard, Claude L (Len) wrote:
> It is of concern to those who field XML technologies
> in environments that are unsafe for some classes of
> applications. The issue is being raised on other
> mail lists. Part of the narrowing of the question
> will be to first determine what technologies or
> technologists can contribute to the solution. One
> pertinent point brought up on another list, not on
> XML-Dev, is to learn to design XML application
> languages so that they are transport-agnostic.
> It would be a best practices topic here once one
> understands the deficiency of the transport and
> the design practices.
>
> If it is not of concern to you, you know how to setup
> a spam filter on a topic. That is a way to mitigate
> an environment not designed to control message traffic
> in accordance with your tastes if not policed by the
> unmoderated list to which you have subscribed, yes?
>
> If your spam filter auto-replies as some do,
> one has to filter that too.
>
> len
>
>
> From: Amelia A Lewis [mailto:amyzing@talsever.com]
>
> On Sun, 8 Feb 2004 12:23:48 -0600
> "Bullard, Claude L (Len)" <clbullar@ingr.com> wrote:
>
> [more on how to fix SMTP, following up Michael Kay in response to me]
>
> In my other life (or lives) this matters to me, but ...
>
> is there anything that XML, as a technology, can contribute toward the
> solution? I don't think so, but I'm willing to be convinced.
>
> if not, is there any particular reason for discussing the redesign of
> TCP/IP and SMTP here? There are places where discussion of such a
> redesign may well be highly productive (IETF mailing lists, mostly,
> although some may prefer more proprietary environments). Here it seems
> simply to contribute to email fatigue (xml-dev always goes through my spam
> filters).
>
> is there something in the discussion that ought to be applied to the
> design of XML technologies? This seems more likely (at least more
> *possible*), but again, I haven't seen those suggestions either.
>
> Not to be rude, but complaining about the problems of email and the
> principles of the redesign of TCP/IP and SMTP to a few hundred people on a
> mailing list devoted to an entirely other topic seems easy to label
> (perhaps unjustly) part-of-the-problem.
>
> Like *this* email, for instance. *sigh*
>
> Amy!
|
