RE: Removal (Time for XMail?)

<Comment>Actually, standardization is what "we" all want. Only companies
like <Name of large corporation trying to take over the world> desire
complications such that only programmers can understand the "standards" they
advocate. We should be striving for simplicity rather than complexity. This
is the way.</Comment>

<Sincerely>William M. Rawls</Sincerely>

<PS>Keep XML pure</PS>

-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Kurt Cagle
Sent: 28 September, 2000 10:11
To: Michael Brennan
Cc: xml-dist-app@w3.org
Subject: Re: Removal (Time for XMail?)


Michael,

I'm not so sure that its altogether that far off topic. We have two primary
mechanisms for data transport across the web -- HTTP, of course, and SMTP.
I've heard all kinds of interesting strategies for bringing XML to HTTP,
from WebDAV on down, but it would seem to me that work on a similar protocol
for upgrading SMTP to an XML basis could provide some powerful dividends.
None of this need be visible to the user -- the SMTP container would
essentially be something like a SOAP envelope wrapped around the plain text
or HTML content. Among other things, it would make it easier to provide
consistent mechanisms for handling mailing lists, including unsubscribe
information, and it could even make it reasonable to handle such XMail
through HTTP ports as readily as through SMTP ones. Just an addled thought.
Good luck on getting some standardization on mailing lists, though.

-- Kurt Cagle
----- Original Message -----
From: "Michael Brennan" <Michael_Brennan@Allegis.com>
To: <xml-dist-app@w3.org>
Sent: Thursday, September 28, 2000 11:16 PM
Subject: RE: Removal


> I don't mean to start a thread about this, but I felt like making a few
> points.
>
> If you check the mail headers, you'll notice that there are headers that
> tell how to unsubscribe and how to query for help about the list. Of
course,
> most user-friendly mail programs do not by default display these headers.
I
> believe the intent is that email programs could use the headers
> intelligently to provide menus or buttons right within the program for a
> user to unsubscribe or query for help. It would be really nice to see
> Microsoft and other vendors support this functionality in their programs
to
> make this easy. (I'm not trying to single out Microsoft, here, but since
> they have about 80-90% of the email market, anything they do has a much
> bigger impact than anyone else.) If vendors would jump on board with this,
I
> think things would work much better. Almost every email list I subscribe
to
> are providing such headers and are doing so in a consistent manner.
>
> Some of the lists, instead, add standard footers to every message sent to
> list subscribers that includes info on how to unsubscribe. You'd think
that
> would reduce the "unsubscribe" requests to the list, but it doesn't. I've
> seen messages on such lists that have a one-line "unsubscribe" request
> immediately followed by a standard footer that explains how to properly
> unsubscribe (and in some such instances, the user actually followed up the
> initial request with additional ones). Some people are just plain
clueless.
>
> Ideally, list server programs should be configured with filters that
detect
> one-line subscribe and unsubscribe instructions, that block the message
from
> the list and send a friendly message to the sender directing them to a FAQ
> on netiquette and how to properly subscribe/unsubscribe from the list. Of
> course, this filter would have to not only catch "unsubscribe" requests,
but
> also "usubscribe" requests, and "unsucbribe" requests, and... well, you
get
> the idea.
>
> I think the real solution is getting the email vendors to have their
> programs deal intelligently with the appropriate mail headers. And while
> they are at it, it would be nice if they would make their programs
> intelligent enough to not send "Out-of-Office" replies back to email
lists.
> I know I'm going to get about 5-10 such replies in response to this post.
>
> Sorry about the off-topic post. I'll say no more about it.
>
> > -----Original Message-----
> > From: Malcolm Dean [mailto:malcolmdean@earthlink.net]
> > Sent: Thursday, September 28, 2000 12:05 PM
> > To: Igor Bazdyrev; 'Stasko, Sandra A'
> > Cc: xml-dist-app@w3.org
> > Subject: Re: Removal
> >
> >
> > Obviously, joining and leaving mail lists is far more clumsy
> > than it should
> > be. Everyone sees this kind of message frequently, on all
> > kinds of lists.
> >
> > I have the impression that knowing how to join and leave is
> > viewed by our
> > nerd/administrators as a badge of courage. How else to
> > explain how these
> > arcane and backward interfaces appear to be immortal?
> >
> > Why doesn't some bright spark (perhaps someone you know) get
> > to work on
> > propagating a truly easy method of leaving a list?
> >
> > Do the planet a favor. Just think of the time we'd all save ... ;-)
> >
> > Malcolm Dean
> > News Editor, Maximum Linux  (Get a free issue at www.maximumlinux.com)
> > 1015 Gayley Avenue #1229
> > Los Angeles CA 90024-3424
> > 213-401-2197 fax
> > malcolmdean@earthlink.net
> >
> >
> > ----- Original Message -----
> > From: "Igor Bazdyrev" <bigor@infolio.com>
> > To: "'Stasko, Sandra A'" <sandra.a.stasko@lmco.com>
> > Cc: <xml-dist-app@w3.org>
> > Sent: Wednesday, September 27, 2000 8:05 PM
> > Subject: RE: Removal
> >
> >
> > > Hi,
> > > The way to unsubscribe explained at http://www.w3.org/Mail/
> > >
> > > Regards,
> > > Igor Bazdyrev
> > > CTO, infolio, inc.
> > > bigor@infolio.com
> > >
> > > PS: my apology for submitting response to the entire
> > mailing list but I've
> > > got few messages with the same "Removal" subject.
> > >
> > > -----Original Message-----
> > > From: Stasko, Sandra A [mailto:sandra.a.stasko@lmco.com]
> > > Sent: Wednesday, September 27, 2000 2:04 PM
> > > To: xml-dist-app@w3.org
> > > Subject: Removal
> > >
> > >
> > >
> > > Please remove me from this list.
> > >
> > > Thank you.
> > >
> > >
> > >
> > >
> > >
> >
>

Received on Monday, 2 October 2000 07:44:38 UTC