[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Mailing list DTD?
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@f..." 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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|