xml-dev - Re: Mailing list DTD?

[Steven Champeon <schampeo@hesketh.com>]

On Wed, 10 May 2000, Jeff Turner wrote:
> Steven Champeon wrote:
> > I have been working on one, off and on, for simple RFC822 messages, but as
> > I don't have the need (or desire) to mark up embedded MIME crud, that's as
> > complex as I'm going to make it.
> 
> You're working on a -DTD- for RFC822 messages? DTDs define syntax;
> isn't that what the RFC already does?

I've only had half a Coke this morning, so bear with me, but "Huh?"
Let me restate that. I have been working on a DTD which provides an
XML tagset that may be used to mark up simple RFC822 messages such
that they may be stored as XML documents. Once they are stored as XML,
metadata may be added to them in order to make it easier to correlate
them with other messages (keywords, for example); to more easily
hide/obscure sensitive information like email addresses, which would
otherwise be visible in a plaintext mail archive such as those
produced by hypermail; GNSOA-compliant .signatures may be tagged as
well, so that viewers can configure their view to hide .sigs; etc. I
can think of many other ways in which an XML DTD for RFC822 messages
can be useful, either on its own or to serve as the substrate for
further custom extensions.

The primary purpose of this DTD is to allow easy and more useful 
/archival/ of email messages, and to allow correlation between the
original message and subsequently added metadata.

Perhaps you were talking about something different. On re-reading, it
sounds like you want to replace RFC822 with some form of XML document,
which sounds interesting but ultimately sort of pointless, don't you
think? Just look at the problems we're having with HTML and richtext
mail sent as multipart/alternative - talk about a waste of bandwidth,
wrapped inside a confusion, surrounded by a security risk.
  
> > > No-one really wants/needs the full capabilities of HTML, yet it would be
> > > nice to have -something- more sophisticated than plain text.
> > 
> > The question I'd ask is "why do you need to mark up a plaintext post as
> > HTML, when you can mark up a plain text post as plain text and then use
> > followup processing to add functionality like links"?
> 
> That's exactly what I'm proposing; leave the MIME type as text/plain
> if you wish, but have the -sender- help the receiver's MUA to do
> "followup processing" by marking up the bits that need it.

I suppose it's obvious what my critique will be by now, but this requires
that the receiver's MUA be modified to support XML. Which, in order to be
effective, would require that /everybody's/ MUA be modified to support XML.
(I know, there are still reasons to use internal-only email, but I'm having
a hard time remembering what they are again...)

> > > I would be happy with two features: an anchor tag <a href=.."></a> for
> > > embedding URLs, and a way of indicating quoted text. Ie:
> > >
> > > <quote sender="joe@foo..com" lang="en">
> > >   blah blah..
> > > </quote>
> > >
> > > "quote" elements can be nested, which makes a nice alternative to
> > > growing sets of '>'s.

Are there any GUI mail clients left that don't support clicking on
URLs to launch them in a browser? Or that deal with it from another
level, such as on the Mac using IceTee? (I'm typing this in pine and
Emacs, on my server, connected via NiftyTelnet, on my Mac, and if I
get mail with a URL, I option-click on the URL and it launches my
browser to that location.)

Don't get me wrong - it sounds like a good idea. Certainly much better
than the current HTML email mess. But for something as commonly used as
email, and for which there are thousands of clients - some of whom can't
even get *RFC822* figured out and supported properly - don't you think
that the XML approach is pretty much doomed to failure? If you read the
RFC, you'll note that the original authors deliberately chose to avoid
markup schemes for several very good reasons. It's hard to argue that
the results of that choice weren't successful, and it's even harder to
argue with the idea that it's too late to go back now.

Have you ever dealt with mass mailings to an audience having several
different kinds of MUAs? If they're on AOL, you need to wrap URLs with
HTML anchors, so that the brain-dead AOL mailer can recognize them as
URLs and do the right thing. This necessarily screws up the display of
the plaintext message for everyone else. This is just *one* example
of the dragons that await your proposal.

Steve

-- 
tired of being an underappreciated functionary in a soulless machine?
hesketh.com is hiring: <http://hesketh.com/careers/>


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************