> WM> These are just a few of the companies and products that are strongly
> WM> committed to the future of HTML/XML mail and messaging: ABC, AOL, CNN,
> WM> Eudora, IBM, InfoBeat, Lotus Notes, Microsoft, Netscape, The New York
> WM> Times, Pegasus, Red Herring and ZDNet.
>
> And which of these companies have any experience drafting open standards?
> Microsoft? "Microsoft Mail: as far from RFC 821 & RFC 822 as you can get
> and still pretend to care." Lotus? Unlike Microsoft, Lotus has never
> bothered pretending to care, their network software is so badly broken.
> The only one I see is Netscape, and that is only because they have recently
> decided that yes, proprietary Internet standards are a bad idea. The rest
> of them are publishers of one sort or another, not what anyone with a clue
> would consider high credentials for drafting standards.
You are missing the point. Useful standards happen because someone
builds a system that works and does something new without much regard
to the past, and *then* publishes the standard. Thus it is wrong to
complain about any proprietary extensions unless you have reason to
believe that they will be kept proprietary if/when they have proven
usefulness. The real issue that affects mailing lists is whether
the extensions provide new useful capabilities and so far everyone
has managed to avoid any discussion of that. The fact that much of
the HTML content you see in email is there by accident is just an
artifact of the lack of understanding of the possibilities. There are
always many more ways to do something wrong than right and you shouldn't
judge a new technology by the number of wrong ways to use it.
Now, what I'd like to see in a MIME/HTML-aware mailing list is the ability
to receive by email only a digest of subject lines and perhaps the
new text (omitting any quoted context) if it is very short, plus a
link to the full body and any attachments. These would be stored in
the list archives and available via http on demand. This could be
done via IMAP too if you have a client that understands how to deal
with many remote mailboxes, but that is currently much less common than
having an http client.
This doesn't seem like it should be that much more difficult than
normal list hosting if you are already keeping archives and it
would eliminate having to transmit any unwanted content and having
to manage all the messages at all the recipient machines. Plus,
it makes it reasonable to send large attachments since the list
would not automatically broadcast them to people that don't want
them.
Les Mikesell
les@mcs.com
Follow-Ups:
References:
|
|
