List-Header Digest Archive: March 1997

http://www.nisto.com/list-spec/mail/

X-List-Help: <http://www.nisto.com/listspec/mail/>, <mailto:list-header-request@list.nisto.com?Subject=help>
X-List-Unsubscribe: <mailto:list-header-request@list.nisto.com?Subject=unsubscribe>
X-List-Subscribe: <mailto:list-header-request@list.nisto.com?Subject=subscribe>
X-List-Archive: <http://www.nisto.com/listspec/mail/#Digest>
X-List-Post: <mailto:list-header@list.nisto.com>
X-List-Owner: <mailto:listmom@list.nisto.com?Subject=List-Header%20List>

Contents:

-> Re: Memphis IETF
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: Why URLs for our syntax?
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> Re: Third Try <mailto:testlist-REQUEST@cs.utk.edu?Subject=add2list%20testlist>
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> Re: Third Try...
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: Third Try <mailto:testlist-REQUEST@cs.utk.edu?	
Subject=add2list%20testlist>
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> First try implementation of List Headers
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: Third Try...
     by Stan Ryckman <(suppressed)@sunspot.tiac.net>
-> Re: Third Try...
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: Third Try...
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> Re: Third Try...
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> LetterRip implements some List Header support
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: LetterRip implements some List Header support
     by Will Mayall <(suppressed)@fogcity.com>
-> Re: LetterRip implements some List Header support
     by Mikael Hansen <(suppressed)@dnai.com>
-> Re: LetterRip implements some List Header support
     by Will Mayall <(suppressed)@fogcity.com>
-> Re: LetterRip implements some List Header support
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: LetterRip implements some List Header support
     by Stan Ryckman <(suppressed)@sunspot.tiac.net>
-> Re: LetterRip implements some List Header support
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: LetterRip implements some List Header support
     by Will Mayall <(suppressed)@fogcity.com>
-> Re: Why URLs for our syntax?
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> listhdr BOF request
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: listhdr BOF request
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Internet-Draft ready for review by list
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Guidelines for Client Application Authors
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: listhdr BOF request
     by Christopher Allen <(suppressed)@consensus.com>
-> Re: listhdr BOF request
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: listhdr BOF request
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: listhdr BOF request 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: listhdr BOF request
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Extending the use of URLs in headers
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Defining a comprehensive command meta-syntax
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: listhdr BOF request 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: listhdr BOF request
     by Christopher Allen <(suppressed)@consensus.com>
-> List server command syntax
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> List server command syntax
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> HTML Forms for syntax (was: List server command syntax)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: List server command syntax
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Internet-Draft full text (not yet submitted)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Internet-Draft full text (part 2)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: HTML Forms for syntax (was: List server command syntax)
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> Re: HTML Forms for syntax (was: List server command syntax)
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> Re:Internet-Draft full text (not yet submitted)
     by "a.h.s. boy" <(suppressed)@nothingness.org>
-> Re:  Internet-Draft full text (not yet submitted)
     by "Roger Fajman" <(suppressed)@CU.NIH.GOV>
-> Re:  Internet-Draft full text (not yet submitted)
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: Internet-Draft full text (not yet submitted)
     by Jason L Tibbitts III <(suppressed)@hpc.uh.edu>
-> Re: Internet-Draft full text (not yet submitted)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re:  Internet-Draft full text (not yet submitted)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: Internet-Draft full text (not yet submitted)
     by "Michael Quinlan" <(suppressed)@primenet.com>
-> Re: Internet-Draft full text (not yet submitted) 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: Internet-Draft full text (not yet submitted)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re:  Internet-Draft full text (not yet submitted)
     by "Roger Fajman" <(suppressed)@CU.NIH.GOV>
-> Re:  Internet-Draft full text (not yet submitted)
     by "Roger Fajman" <(suppressed)@CU.NIH.GOV>
-> Re: Internet-Draft full text (not yet submitted) 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: Internet-Draft full text (not yet submitted) 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: Getting off-topic to Web Archives (was: Internet-Draft  full text (not
yet submitted))
     by Bonnie Scott <(suppressed)@staff.prodigy.com>
-> Re:  Internet-Draft full text (not yet submitted)
     by "Roger Fajman" <(suppressed)@CU.NIH.GOV>
-> Re: Getting off-topic to Web Archives (was: Internet-Draft   full text (not
yet submitted))
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: Getting off-topic to Web Archives (was: Internet-Draft full text  (not
yet submitted))
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: Internet-Draft full text (not yet submitted) 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: Getting off-topic to Web Archives (was: Internet-Draft
     by Steve Watt <(suppressed)@newcastle.ac.uk>
-> Re: HTML Forms for syntax (was: List server command syntax)
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> the Internet-Draft has been submitted
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> continuing the work
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: continuing the work
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> Re: continuing the work
     by "Daniel Berlinger" <(suppressed)@circumtech.com>
-> Fwd: QM Support for List Mgmt (was Re: continuing the work)
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> Response form QuickMail
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> List of Email Clients
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> Re: List of Email Clients
     by jud spencer <(suppressed)@claris.com>
-> Form Letter to Client Authors (was: continuing the work)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: HTML Forms for syntax
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> meta-syntax internationalization in custom commands (was: Internet-Draft
full text (not yet submitted))
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: Form Letter to Client Authors (was: continuing the work)
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> multiple commands in a single header (was: Getting off-topic to Web
Archives)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> passing List- header fields (was:  Internet-Draft full text (not yet
submitted))
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> evangelizing the List- headers (was: continuing the work)
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Why List-S ubscribe instead of...? (was:  Internet-Draft full text (not yet
submitted))
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: Form Letter to Client Authors (was: continuing the work)
     by "a.h.s. boy" <(suppressed)@nothingness.org>
-> press release for list headers
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: Form Letter to Client Authors
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re: evangelizing the List- headers (was: continuing the work)
     by (suppressed)@frutiger.staffs.ac.uk (James Berriman)
-> Re: Form Letter to Client Authors (was: continuing the work)
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> List-Header Server Notice
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Re:  Why List-S ubscribe instead of...?  (was:  Internet-Draft         
full
     by "Roger Fajman" <(suppressed)@CU.NIH.GOV>
-> Re:  Why List-S ubscribe instead of...?
     by Grant Neufeld <(suppressed)@ccs.carleton.ca>
-> Small suggestion for the standards document
     by "John Buckman" <(suppressed)@shelby.com>
-> Re:  Why List-S ubscribe instead of...?
     by "Roger Fajman" <(suppressed)@CU.NIH.GOV>
-> Re: Small suggestion for the standards document
     by "Kent S. Larsen II" <(suppressed)@panix.com>


----------------------------------------------------------------------

Date: 1 Mar 1997 19:35:55 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: Memphis IETF

At 12:55 PM -0500 97/2/28, Christopher Allen wrote:
>>If so, can it proceed with an absent chair? If it really needs to happen
>>with me there, I can try to find a way to make it (maybe just fly in for
>>the day, or such).
>
>Even though technically you don't have to be at an IETF meeting, I do think
>is is very important. I subbed for the TLS chairman at the last IETF
>meeting (I'm an editor) and it cause a number of problems that he wasn't
>there.

I guess there's really not much choice - I should be there if there's a
meeting.

Any chance of me finding a sponsor(s) for my attendance at the meeting (not
being employed means my funds are not the most plenitful at the moment)?

(before anyone asks: I'm intentionally unemployed, taking a much needed
extended-vacation. Which is why I've time to work on this project.)


Keith Moore wrote:
>The chair just needs
>to be someone willing to write up an agenda,

Review and discuss the Internet-Draft (which should be tabled by that time).

Determine if there are any notable points of contention with regard to the
direction of the draft (that are not addressed by the intent to expand the
scope through more detailed and comprehensive syntax and transport
mechanisms).

Determine whether there's sufficient community interest. (this should be a
breeze - considering the high level of positive response (only one
nay-sayer so far) to the inititiative (not necessarily to the specific
implementation, though).

Determine whether the draft needs a formal working group before going to
Last Call.

>moderate the discussion,

Since I'll probably be one of the primary speakers on this, should we
arrange for a different moderator? (not that I don't think I can handle it,
just a question of protocol)

>circulate a sign-up sheet,

What's the procedure for that?

>arrange for minutes to be taken,

Okay.

>and write up a one-paragraph summary.

Is that pre or post meeting?

>And the WG chair gets invited to the
>applications area dinner to discuss things with other applications area
>chairs and directorate members.

When is that held? If I do go to the meeting, it will probably be only for
a day or two, so would like to schedule the BOF on the same or an adjacent
day.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 3 Mar 1997 10:36:53 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: Re: Why URLs for our syntax?

At 13:39 28/2/97, Grant Neufeld wrote:

>I think we should include a discussion of that
>for the list managers and server authors, with a recommendation (but not a
>requirement) of using mailto based commands for the subscribe and
>unsubscribe headers, and to consider the needs of their specific audience
>when choosing the protocol for the Help header.

It would be useful to allow inclusion of multiple url protocols in a list
header.

As in:

List-help: <mailto:help@domain>
           <http://www.domain/listname/help.html>

We could require the mailto: url to be listed first, where present, so that
it is easy to implement a basic mail client interface.

( :-])  James


----------------------------------------------------------------------

Date: 3 Mar 1997 10:38:00 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: Re: Third Try <mailto:testlist-REQUEST@cs.utk.edu?	
Subject=add2list%20testlist>

I tried this with my mac LCII running ICeTEe, the Eudora GURL handler and
Eudora Pro 2.

ICeTEe correctly unwrapped the url and passed it to the GURL handler, which
opened a message in Eudora and pasted the whole thing into the To: header

testlist-REQUEST@cs.utk.edu?Subject=add2list%20testlist

One thing is clear here. If a savvy url handler script were written in
AppleScript or Frontier, even old versions of Eudora on the Mac could take
advantage of this syntax now.

( :-])  James


----------------------------------------------------------------------

Date: 4 Mar 1997 00:49:53 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: Third Try...

At 2:13 AM -0500 2/28/97, Keith Moore wrote:

> Aside: I've tried twice to send a test message to the list with
> a mailto in a header field, along with a request that people click
> on it and try to subscribe to a dummy list that way and let me
> know what happens.  On the first try, the list filtered out the
> List-Subscribe header (because it filters out things it doesn't
> understand); On the second try, I put the mailto URL in the
> Subject line; the list saw "subscribe" in there and added me to the list!

Just as a clarification of what's going on here in case anyone is
interested in why I set up those filters...

The list currently strips out all headers except five or so "required"
headers.  This stops return-receipts and the like from making it through to
the list, and also cuts out all of the "received-by" headers which can get
quite large in bulk mail.  I'd be open to other suggestions, but have found
this to work quite well so far.  One thing we should finalize here is
whether an existing List-Subscribe header should be stripped out by the
list software or not.  I think it should, but I'd be interested in hearing
arguments to the contrary.

As to you being subscribed to the list, let me point out that you are in a
very unusual case since you work with two addresses.  Most people sending a
message like that would already be subscribed, and get a more informative
message stating that you could not be subscribed because you already were.
Again, this only comes up on this list because it is a list _about_ mailing
lists.  On other lists, the words subscribe and unsubscribe are very
uncommon.

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login


----------------------------------------------------------------------

Date: 4 Mar 1997 00:50:43 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: Third Try <mailto:testlist-REQUEST@cs.utk.edu?	
Subject=add2list%20testlist>

At 10:33 AM -0500 3/3/97, James Berriman wrote:

> One thing is clear here. If a savvy url handler script were written in
> AppleScript or Frontier, even old versions of Eudora on the Mac could take
> advantage of this syntax now.

Grant and I wrote a FaceSpan floating windoid for Eudora which does exactly
that (except you have buttons to subscribe/unsubscribe/get help).  We will
be releasing it to the public shortly (need to finish the docs).

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login


----------------------------------------------------------------------

Date: 5 Mar 1997 11:20:03 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: First try implementation of List Headers

Grant and I threw together a little applet which works with Eudora on the
Macintosh to demonstrate an implementation of the List Headers proposal.
It appears as a floating windoid above Eudora, which only shows up when an
appropriate message is the front window (a message with a List-* header in
it).

You can download it from
<http://www.skyweyr.com/mailing-lists/list-helper.html>

Please give it a try!  It's not a product, just a prototype, but hopefully
it will generate some good discussion and bring out some of the issues.

~Josh


- -- ----------------------------------------------------------------------
You will come to a place where the streets are not marked. Some windows are
lighted. But mostly they're darked. A place you could sprain both your
elbow and chin! Do you dare to stay out? Do you dare to go in? How much can
you lose? How much can you win?
                                                              - Dr. Seuss


----------------------------------------------------------------------

Date: 5 Mar 1997 22:50:44 -0500
From: Stan Ryckman <(suppressed)@sunspot.tiac.net>
Subject: Re: Third Try...

At 12:35 AM 3/4/97 -0500, Joshua D. Baer wrote:

[snip]

>Just as a clarification of what's going on here in case anyone is
>interested in why I set up those filters...
>
>The list currently strips out all headers except five or so "required"
>headers.  This stops return-receipts and the like from making it through to
>the list, and also cuts out all of the "received-by" headers which can get
>quite large in bulk mail.

I presume you mean "Received:" headerfields.

I think, unless it is a moderated list, it is unwise to strip Received:
(although providing a SHORTHDR or equivalent *user option* is reasonable).
Stripping those makes spam untraceable *except* by the listowner--is he
taking that responsibility?  The same is true of forgery.

Removing "Return-Receipt-To:" is reasonable, though one could make a
case that the list should return a receipt in the process of removing
that headerfield.  Same for its "bretheren" headerfields.

Cheers,
Stan.


----------------------------------------------------------------------

Date: 5 Mar 1997 23:54:00 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: Third Try...

At 10:48 PM -0500 3/5/97, Stan Ryckman wrote:

> I think, unless it is a moderated list, it is unwise to strip Received:
> (although providing a SHORTHDR or equivalent *user option* is reasonable).
> Stripping those makes spam untraceable *except* by the listowner--is he
> taking that responsibility?  The same is true of forgery.

Yes, I'm taking that responsibility.  Don't most list owners?

> Removing "Return-Receipt-To:" is reasonable, though one could make a
> case that the list should return a receipt in the process of removing
> that headerfield.  Same for its "bretheren" headerfields.

I guess it could, but I don't think that's what people want... most users
I've talked to only leave the return receipt because it's a pain to turn
off.  Return receipts don't really make sense for mailing lists...

It definitely shouldn't be passed on to the list... :)

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login


----------------------------------------------------------------------

Date: 6 Mar 1997 06:45:02 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: Re: Third Try...

At 04:41 6/3/97, Joshua D. Baer wrote:
>At 10:48 PM -0500 3/5/97, Stan Ryckman wrote:
>
>> I think, unless it is a moderated list, it is unwise to strip Received:
>> (although providing a SHORTHDR or equivalent *user option* is reasonable).
>> Stripping those makes spam untraceable *except* by the listowner--is he
>> taking that responsibility?  The same is true of forgery.
>
>Yes, I'm taking that responsibility.  Don't most list owners?

How many listowners are on duty 24/365? From experience, I'd say it's a
minority. Leave the headers in, and any savvy member of the list can ring
the warning bells or take action when they see something wrong.

Case in point: recently I posted a message to a mailing list. This was on a
Saturday. On the Sunday I checked my mailbox and discovered that the list
had sent out 40 copies of my message (actually, 40 and counting...). They
all appeared to be from me. Needless to say, I got a couple of irate
messages from other subscribers.

Checking the Received: headers, I was able to see that a broken NTmail
gateway was trying to deliver my message to the address in the To: header
(the list), not the envelope recipient (the new list member). This set up a
loop between the list server and the NTmail gateway.

The list server was unable to distinguish between a genuine message from me
and one of its own messages (with a precedence: list header inserted).
Since I was a subscriber, it just kept redistributing the message.

I had to unsubscribe from the list to force the server to bounce any
further copies of my message, then report the problem to the listowner.

Had those received: headers not been intact, I would have been unable to
establish what was going on (and defend myself from the charge of witless
spamming - my message was an announcement).

Needless to say, I like received: headers

The ironic thing here is that this was the second time the problem had
arisen on the list. The first time, I traced the problem and actually
phoned the company in question to inform them that their mail server was
broken. As soon as they tried to resubscribe, all hell broke loose again.

See what thanks you get for trying to help... ;-)

( :-])  James


----------------------------------------------------------------------

Date: 6 Mar 1997 09:21:17 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: Third Try...

At 6:43 AM -0500 3/6/97, James Berriman wrote:

> At 04:41 6/3/97, Joshua D. Baer wrote:
> >At 10:48 PM -0500 3/5/97, Stan Ryckman wrote:
> >
> >> I think, unless it is a moderated list, it is unwise to strip Received:
> >> (although providing a SHORTHDR or equivalent *user option* is
reasonable).
> >> Stripping those makes spam untraceable *except* by the listowner--is he
> >> taking that responsibility?  The same is true of forgery.
> >
> >Yes, I'm taking that responsibility.  Don't most list owners?
>
> How many listowners are on duty 24/365? From experience, I'd say it's a
> minority. Leave the headers in, and any savvy member of the list can ring
> the warning bells or take action when they see something wrong.

I run a commercial list hosting service.  Someone is watching my servers at
all times.  Automated tools watch as well.  Not 24/7, but something close
to 20/7.  Definitely 365 days a year.

> Case in point: recently I posted a message to a mailing list. This was on a
> Saturday. On the Sunday I checked my mailbox and discovered that the list
> had sent out 40 copies of my message (actually, 40 and counting...). They
> all appeared to be from me. Needless to say, I got a couple of irate
> messages from other subscribers.
>
> Checking the Received: headers, I was able to see that a broken NTmail
> gateway was trying to deliver my message to the address in the To: header
> (the list), not the envelope recipient (the new list member). This set up a
> loop between the list server and the NTmail gateway.
>
> The list server was unable to distinguish between a genuine message from me
> and one of its own messages (with a precedence: list header inserted).
> Since I was a subscriber, it just kept redistributing the message.
>
> I had to unsubscribe from the list to force the server to bounce any
> further copies of my message, then report the problem to the listowner.
>
> Had those received: headers not been intact, I would have been unable to
> establish what was going on (and defend myself from the charge of witless
> spamming - my message was an announcement).

I disagree.  Had the headers not been intact, it still is obvious that the
correct action (or at least one which most likely to work) was to
unsubscribe yourself.  You can tell that just by the fact that the messages
appear to be from you.  You still need the listowner to do anything more
significant (like possibly search the subscriber lists for an offending
domain).

This is not to say the headers NEVER help, but since just about all you can
do is send an unsubscribe message, it's not like you have the power to
search the address lists for subscribers from a particular domain or
configure the list to ignore mail from that address.  I guess what I'm
getting at is that only the list owner can solve any hard problems which
arise.

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login


----------------------------------------------------------------------

Date: 8 Mar 1997 12:30:54 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: LetterRip implements some List Header support

LetterRip is a Mac based list server that now has (beta) support for the
X-List-Subscribe and X-List-Unsubscribe headers.

I think the software is automatically generating the headers based on the
server's built-in command set. (Will, can you send more details on your
implementation to the list or me, please?)

- --- begin forwarded text

Subject: LetterRip 1.1b1 Is Now Available
Date: Fri, 7 Mar 97 11:30:11 -0800
From: Will Mayall <(suppressed)@fogcity.com>
To: LetterRip Announcement <LetterRip-Announce@lists.fogcity.com>

...[unrelated bits removed -grant]...

- - Messages sent by LetterRip 1.1 include the X-List-Unsubscribe and
X-List-Subscribe headers. These headers allow some email clients (e.g.
Claris Emailer 2.0 with AppleScripts) to automate the task of subscribing
to or unsubscribing from a mailing list.

As with any beta software, you should not use LetterRip 1.1b1 unless you
are comfortable with pre-release software.

You can download LetterRip 1.1b1 via the Fog City Software web site:

<http://www.fogcity.com/lr_download.html>

Will

__________________________________________________________________________
Will Mayall                                         http://www.fogcity.com
President, Fog City Software

- --- end forwarded text


as to why I've been so quiet the past week - I'm just getting over a nasty
flu |^(  Hopefully I can get cracking on this again, as I face my mountain
of neglected email...

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 8 Mar 1997 13:00:42 -0500
From: Will Mayall <(suppressed)@fogcity.com>
Subject: Re: LetterRip implements some List Header support

Grant Neufeld wrote:

>LetterRip is a Mac based list server that now has (beta) support for the
>X-List-Subscribe and X-List-Unsubscribe headers.
>
>I think the software is automatically generating the headers based on the
>server's built-in command set. (Will, can you send more details on your
>implementation to the list or me, please?)

Yes, LetterRip is generating the headers automatically. There is no setup 
required.

Here is an example from the LetterRip-Talk list:

X-List-Software: LetterRip 1.1b1 by Fog City Software, Inc.
X-List-Unsubscribe:  
<mailto:requests@lists.fogcity.com?subject=unsubscribe%20LetterRip-Talk>
X-List-Subscribe:  
<mailto:requests@lists.fogcity.com?subject=subscribe%20LetterRip-Talk>

Additionally, there is an AppleScript for Emailer 2.0 on the Fog City 
Software site that will manage Unsubscribe headers. Emailer 2.0 has an 
AppleScript menu for executing scripts.

Will

__________________________________________________________________________
Will Mayall                                         http://www.fogcity.com
President, Fog City Software


----------------------------------------------------------------------

Date: 8 Mar 1997 13:19:59 -0500
From: Mikael Hansen <(suppressed)@dnai.com>
Subject: Re: LetterRip implements some List Header support

At 09:57 -0800 3/8/97, Will Mayall wrote:

>Yes, LetterRip is generating the headers automatically. There is no setup
>required.

The same goes for the upcoming AutoShare 1.2.

>Here is an example from the LetterRip-Talk list:
>
>X-List-Software: LetterRip 1.1b1 by Fog City Software, Inc.
>X-List-Unsubscribe:
><mailto:requests@lists.fogcity.com?subject=unsubscribe%20LetterRip-Talk>
>X-List-Subscribe:
><mailto:requests@lists.fogcity.com?subject=subscribe%20LetterRip-Talk>

Here is an example from the AutoShare-Talk list:

X-List-Software: AutoShare 1.2fc1 by Mikael Hansen
X-List-Subscribe:
<mailto:autoshare@frutiger.staffs.ac.uk?body=subscribe%20AutoShare-Talk>
X-List-Unsubscribe:
<mailto:autoshare@frutiger.staffs.ac.uk?body=unsubscribe%20AutoShare-Talk>

- --
Mikael Hansen <mailto:meh@dnai.com>


----------------------------------------------------------------------

Date: 8 Mar 1997 13:52:45 -0500
From: Will Mayall <(suppressed)@fogcity.com>
Subject: Re: LetterRip implements some List Header support

Mikael Hansen wrote:

>At 09:57 -0800 3/8/97, Will Mayall wrote:
>
>>Yes, LetterRip is generating the headers automatically. There is no setup
>>required.
>
>The same goes for the upcoming AutoShare 1.2.
>
>>Here is an example from the LetterRip-Talk list:
>>
>>X-List-Software: LetterRip 1.1b1 by Fog City Software, Inc.
>>X-List-Unsubscribe:
>><mailto:requests@lists.fogcity.com?subject=unsubscribe%20LetterRip-Talk>
>>X-List-Subscribe:
>><mailto:requests@lists.fogcity.com?subject=subscribe%20LetterRip-Talk>
>
>Here is an example from the AutoShare-Talk list:
>
>X-List-Software: AutoShare 1.2fc1 by Mikael Hansen
>X-List-Subscribe:
><mailto:autoshare@frutiger.staffs.ac.uk?body=subscribe%20AutoShare-Talk>
>X-List-Unsubscribe:
><mailto:autoshare@frutiger.staffs.ac.uk?body=unsubscribe%20AutoShare-Talk>

Superb. Look's like there is a quickly building consensus.

Will

__________________________________________________________________________
Will Mayall                                         http://www.fogcity.com
President, Fog City Software


----------------------------------------------------------------------

Date: 8 Mar 1997 15:54:31 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: LetterRip implements some List Header support

As if this needed to be said...

The next version of the ListSTAR templates will support these headers by
default.  Existing ListSTAR users can easily add this support now by adding
the headers to the "Mailing List Reflect.rfc" file for your service.

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login


----------------------------------------------------------------------

Date: 8 Mar 1997 20:01:27 -0500
From: Stan Ryckman <(suppressed)@sunspot.tiac.net>
Subject: Re: LetterRip implements some List Header support

At 03:50 PM 3/8/97 -0500, Joshua D. Baer wrote:
>As if this needed to be said...
>
>The next version of the ListSTAR templates will support these headers by
>default.  Existing ListSTAR users can easily add this support now by adding
>the headers to the "Mailing List Reflect.rfc" file for your service.

OK folks, am I just missing something?

It should be *trivial* for mailing lists to implement these headers, however
they end up being formatted, whatever the standard may become; there's nothing
to do but toss out a few constant strings among the headers.

OTOH, the *client MUA software* has to do real work to support them, so I
wouldn't count even minor moral victories until something arises in that area,
especially since the problem being addressed is one that annoys list owners
much more than mail client software writers.  :-)  Seriously, list software
writers can just provide for easily-changed constant strings, and go with
any changes to what happens on the way to an RFC; however, client mail
software won't have life so simple.  Wrong guesses as to what the standard
will be, will be virtually useless to the client software.

Tabulating hens prematurely?  :-)

Cheers,
Stan


----------------------------------------------------------------------

Date: 8 Mar 1997 20:40:08 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: LetterRip implements some List Header support

At 7:58 PM -0500 3/8/97, Stan Ryckman wrote:

> OTOH, the *client MUA software* has to do real work to support them, so I
> wouldn't count even minor moral victories until something arises in that
>area,
> especially since the problem being addressed is one that annoys list owners
> much more than mail client software writers.  :-)

FYI: Two of the leading POP clients for the Macintosh (Eudora and Emailer)
have working implementations available.

<http://www.skyweyr.com/mailing-lists/list-helper.html>
<http://www3.claris.com/emailer_beta/site.html>

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login


----------------------------------------------------------------------

Date: 9 Mar 1997 00:59:49 -0500
From: Will Mayall <(suppressed)@fogcity.com>
Subject: Re: LetterRip implements some List Header support

Stan Ryckman wrote:

>OK folks, am I just missing something?
>
>It should be *trivial* for mailing lists to implement these headers, however
>they end up being formatted, whatever the standard may become; there's 
>nothing to do but toss out a few constant strings among the headers.

Gotta start somewhere.

>OTOH, the *client MUA software* has to do real work to support them, so I
>wouldn't count even minor moral victories until something arises in that 
>area, especially since the problem being addressed is one that annoys list 
>owners much more than mail client software writers.

There is an AppleScript for Emailer 2.0 that works now. It's very easy to 
use since Emailer 2.0 has an AppleScript menu.

>Seriously, list software
>writers can just provide for easily-changed constant strings, and go with
>any changes to what happens on the way to an RFC; however, client mail
>software won't have life so simple.  Wrong guesses as to what the standard
>will be, will be virtually useless to the client software.

Actually, I don't think it is too tough for the clients. The really 
important header is the Unsubscribe header. It looks very likely that it 
will be X-List-Unsubscribe and then List-Unsubscribe. After that, it's 
primarily a matter of dealing with a mailto URL. Both Eudora and Emailer 
deal with the proposed URL format fine.

Of course, it will be terrific if the mail clients add a nice friendly 
interface. I wouldn't be surprised to see that happen pretty quickly.

Will

__________________________________________________________________________
Will Mayall                                         http://www.fogcity.com
President, Fog City Software


----------------------------------------------------------------------

Date: 13 Mar 1997 15:33:16 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: Why URLs for our syntax?

[sorry for the delayed reply - I've been in a very lazy slump, ignoring my
email, and dealing with a flu bug]

At 10:33 AM -0500 97/3/3, James Berriman wrote:
>
>It would be useful to allow inclusion of multiple url protocols in a list
>header.
>
>As in:
>
>List-help: <mailto:help@domain>
>           <http://www.domain/listname/help.html>
>
>We could require the mailto: url to be listed first, where present, so that
>it is easy to implement a basic mail client interface.

I think we'll leave this for the 'future expansion' section. The first
standard document will just allow one url. Future support for things like
you suggest is not limited, though, because the current (not quite ready
for public viewing, but darn close now) draft specifies:

  1) If the content of the header (following any leading whitespace)
     begins with any character other than the opening angle bracket '<',
     the header should be ignored.
  2) Any characters in the header after the first closing angle bracket
     '>' are to be ignored.

Which means we can add extra stuff after the first URL and it won't break
(compliant) mail clients. It also means we can substitute new syntaxes in
place of the url without breaking older clients (they'll just not do
anything, instead of having 'weird' behavior).

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 14 Mar 1997 17:10:41 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: listhdr BOF request

I haven't seen any request for a listhdr BOF at the next IETF.
If you're interested in doing it, you need to send in a BOF request
ASAP.

See http://www.apps.ietf.org/apps/procedures.html
for instructions on how to do so.

Keith


----------------------------------------------------------------------

Date: 16 Mar 1997 15:02:34 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: listhdr BOF request

At 5:07 PM -0500 97/3/14, Keith Moore wrote:
>I haven't seen any request for a listhdr BOF at the next IETF.
>If you're interested in doing it, you need to send in a BOF request
>ASAP.

I'm not going to be able to put together a BOF session for Memphis.

Hopefully, we can still proceed without the session (especially in light of
the growing support from developers).

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 16 Mar 1997 15:03:35 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Internet-Draft ready for review by list

The first go at a formal Internet-Draft is ready for review by the members
of this list.

It has not yet been formally submitted and will not be until we've got a
general consensus on this list.

  http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-00.txt

Joshua D. Baer wrote the first draft of this document based on the
discussion here and my web pages. The version now presented is my
edit/modification of his draft.

Please pass your recommendations and comments to this list or to me.

Thanks!

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 16 Mar 1997 15:20:41 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Guidelines for Client Application Authors

I've written a guidelines document for developers of mail client software
for implementing List Header support.

  http://arpp.carleton.ca/listspec/client-author.html

Please review it and let me know of any changes or additions that should be
made.

Thanks.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 16 Mar 1997 19:04:20 -0500
From: Christopher Allen <(suppressed)@consensus.com>
Subject: Re: listhdr BOF request

At 11:49 AM -0800 3/16/97, Grant Neufeld wrote:
>At 5:07 PM -0500 97/3/14, Keith Moore wrote:
>>I haven't seen any request for a listhdr BOF at the next IETF.
>>If you're interested in doing it, you need to send in a BOF request
>>ASAP.
>
>I'm not going to be able to put together a BOF session for Memphis.
>
>Hopefully, we can still proceed without the session (especially in light of
>the growing support from developers).

I've been a substitute chair before (was the TLS substitute at the last
IETF meeting.)  I'll be glad to host a BOF session as Grant can't make it.

How many people on the list will be there?

We also need to submit internet-draft by the cutoff date, which I think is
the end of this week. Does anyone off hand know what day the cut off is?

- ------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<(suppressed)@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..


----------------------------------------------------------------------

Date: 16 Mar 1997 22:34:59 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: listhdr BOF request

At 7:01 PM -0500 97/3/16, Christopher Allen wrote:
>I've been a substitute chair before (was the TLS substitute at the last
>IETF meeting.)  I'll be glad to host a BOF session as Grant can't make it.

That would be okay with me.

It's too bad I'm not in a position to go at this time (half a year either
way and I could have done it). Oh, well.

Perhaps we can arrange a conference call sometime before people go to
Memphis so I can chat with some of those who will be there.

>We also need to submit internet-draft by the cutoff date, which I think is
>the end of this week. Does anyone off hand know what day the cut off is?

I think you're right about Friday being the cutoff. Hopefully the review
process on this list won't take to long to complete so it can be submitted
by then.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 16 Mar 1997 23:23:12 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: listhdr BOF request

At 10:33 PM -0500 3/16/97, Grant Neufeld wrote:

> >We also need to submit internet-draft by the cutoff date, which I think is
> >the end of this week. Does anyone off hand know what day the cut off is?
>
> I think you're right about Friday being the cutoff. Hopefully the review
> process on this list won't take to long to complete so it can be submitted
> by then.

For some reason I have Monday the 24th written down...

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyWeyr Technologies
http://www.skyweyr.com/


----------------------------------------------------------------------

Date: 17 Mar 1997 13:52:10 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: listhdr BOF request 

> >I haven't seen any request for a listhdr BOF at the next IETF.
> >If you're interested in doing it, you need to send in a BOF request
> >ASAP.
> 
> I'm not going to be able to put together a BOF session for Memphis.

Okay.  For what it's worth, there will probably be a BOF on
standardizing list server command syntax.  I'm going to want that BOF
to discuss the listhdr proposal also, so I can gauge the community's
response to both proposals.

Keith


----------------------------------------------------------------------

Date: 17 Mar 1997 14:17:20 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: listhdr BOF request

At 1:48 PM -0500 97/3/17, Keith Moore wrote:
>For what it's worth, there will probably be a BOF on
>standardizing list server command syntax.

Who's heading up that work? Do you have an URL(s) to relevant
documents/groups?

>  I'm going to want that BOF
>to discuss the listhdr proposal also, so I can gauge the community's
>response to both proposals.

Where will we be able to get the results from that discussion? (minutes?)

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 17 Mar 1997 15:35:47 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Extending the use of URLs in headers

Aside from the lack of support for variables, there are a couple of other
situations that single URLs can't handle.


First, alternate sources. For example, a list may have a listserver command
for retrieving a help file, but it may also have a web page for getting
help. Currently, the list administrator would have to choose just one of
them to put in the List-Help header.

I propose an extension to the List- header syntax allowing for multiple
URLs as follows:

  <URL>[, <URL>]

Where there can be any number of additional comma-separated, angle-bracket
enclosed, URLs in a given List- header field.


Secondly, a single action requiring multiple commands. For example, a list
which has a separate list for digests, requiring unsubscription from the
main list and subscription to the digest list in order to switch to digest
mode.

I propose that 'stacked' URLs be permitted, for such cases, as follows:

  <URL> [<URL>]

Where there can be any number of additional angle-bracket enclosed URLs for
an action. The space separating them can be any or no whitespace.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 17 Mar 1997 15:37:20 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Defining a comprehensive command meta-syntax

Now that the dust appears to be settling on the URL base core List Header
proposal, we should begin looking into defining a comprehensive meta-syntax
for describing list server commands.

Part of the work we need to do is figuring out exactly what commands there
are.

The list of command acronyms I have so far is:

 SUB - subscribe to list
 UNS - unsubscribe from list
 DIG - receive digests
 REG - regular messages, not digest format
 ACK - acknowledgements (sender receives messages they've posted)
 NCK - no acknowledgements
 HLP - get help file
 INF - get info file
 PSW - set password
 GET - get a file from the archive of this list
 IND - index, to retrieve back digests
 TOP - topics only
 FUL - full headers
 SHH - short headers
 FAQ - get the FAQ for this list
 WHO - get the list of subscribers for this list

What commands are there that should be added to this list?

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 17 Mar 1997 16:31:43 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: listhdr BOF request 

> >For what it's worth, there will probably be a BOF on
> >standardizing list server command syntax.
> 
> Who's heading up that work? Do you have an URL(s) to relevant 
> documents/groups?

Brian Trenbreath of Microsoft has asked for such a BOF.  He claims
that several of the list server vendors are interested.  I don't know
of any concrete proposals, though.

> >  I'm going to want that BOF
> >to discuss the listhdr proposal also, so I can gauge the community's
> >response to both proposals.
> 
> Where will we be able to get the results from that discussion? (minutes?)

If memory serves, minutes are due to be turned in two weeks after the
meeting.  They are presumably posted on IETF's web site soon
afterward, though I've never checked to see exactly when that happens.

Keith


----------------------------------------------------------------------

Date: 17 Mar 1997 16:49:38 -0500
From: Christopher Allen <(suppressed)@consensus.com>
Subject: Re: listhdr BOF request

At 1:28 PM -0800 3/17/97, Keith Moore wrote:
>> Where will we be able to get the results from that discussion? (minutes?)
>
>If memory serves, minutes are due to be turned in two weeks after the
>meeting.  They are presumably posted on IETF's web site soon
>afterward, though I've never checked to see exactly when that happens.

My experience with this re: my last TLS meeting is that the a brief
abstract should be given to your AD before the end of IETF, and then the
full minutes should be given to the list.

There were some proceedings deadlines a few weeks after the IETF meeting,
but I don't recall sending any minutes to anyone other than the list.

- ------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<(suppressed)@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..


----------------------------------------------------------------------

Date: 18 Mar 1997 06:46:03 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: List server command syntax

Grant asked for feedback on his list of command abbreviations. Personally,
I find the terminology rather implementation-specific and inflexible.

Here's my current help file for AutoShare:

- --

Welcome to the AutoShare help for autoshare@frutiger.staffs.ac.uk.

Available AutoShare commands in the message *body* are as follows:

GENERAL COMMANDS:

  HELP - returns this HELP file.

  RELEASE - listserver software information.


SUBSCRIPTION COMMANDS:

  SUB(SCRIBE) <list> [<name>] - subscribes you to a list.

  UNSUB(SCRIBE) or SIGNOFF <list or ALL> - cancels your list subscription.

  SET <list or ALL> <option> - options are:
  ACK, NOACK, CONCEAL, NOCONCEAL, DIGEST, NODIGEST, MAIL, NOMAIL.

  QUERY <list or ALL> - shows your subscription options.

  WHICH - shows which lists you are on.


LIST COMMANDS:

  LIST - returns information about the lists maintained by this server.

  REV(IEW) or RECIPIENTS or WHO <list or ALL> - the subscribers to a list.

  IND(EX) <list or ALL> - returns an index of archive files.

  GET or SEND <list or ALL> <file> - gets you an archive file.

  SEARCH <list or ALL> <string> - Search the list archives for matching text.

  <list> - gets you information about the specified list.
  (Just put the name of the list on a line by itself).


Addresses for this particular AutoShare listserver:

  Listserver             autoshare@frutiger.staffs.ac.uk
  AutoShare Admin        listmaster@frutiger.staffs.ac.uk
  Lists                  <list>@frutiger.staffs.ac.uk

- --

For those of us who are on the Mac platform, I'll say that this strikes me
as very reminiscent of an Applescript dictionary.

Take a 'core suite' of commands (sub, unsub, help), then allow the
individual developer/listmom to add to this using an unambigous syntax.

If you have fields for command, command description and command syntax then
a mail client should be able to build a list interface tailored exactly to
the list software (e.g. buttons with pop-up descriptions).

Rather than trying to define a standard list of command abbreviations,
let's look for a flexible way to allow precise description of any command
syntax.

Thoughts?

( :-])  James


----------------------------------------------------------------------

Date: 18 Mar 1997 06:47:09 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: List server command syntax

Something that just struck me:

One possibility that crosses my mind is that there is a text-based
mechanism already in place for describing such interactions - HTML forms.
Perhaps we should look at the idea of including listserver metasyntax in an
HTML attachment.

Browsers could actually display such meta information as a form, while
other email clients could build a text or graphical interface based around
the form data.

The interesting thing would be working out how to define the form ACTION.

( :-])  James


----------------------------------------------------------------------

Date: 18 Mar 1997 09:41:01 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: HTML Forms for syntax (was: List server command syntax)

At 6:44 AM -0500 97/3/18, James Berriman wrote:
>One possibility that crosses my mind is that there is a text-based
>mechanism already in place for describing such interactions - HTML forms.
>Perhaps we should look at the idea of including listserver metasyntax in an
>HTML attachment.
>
>Browsers could actually display such meta information as a form, while
>other email clients could build a text or graphical interface based around
>the form data.
>
>The interesting thing would be working out how to define the form ACTION.

mailto: ?

Subscribe:
<FORM ACTION="mailto:request@host.com" METHOD=GET>
<INPUT TYPE="hidden" NAME="Body" VALUE="subscribe">
List:
<SELECT NAME="Body">
<OPTION VALUE="somelist">Some List
<OPTION VALUE="anotherlist">Another List
</SELECT>
Username:
<INPUT TYPE="text" NAME="Body">
</FORM>

An obvious problem being the 'stacking' of form fields into one field. What
we want, in this case, is to add the items sequentially with a space
between each item - which results in:
"mailto:request@host.com?Body=subscribe%20somelist%20User%20Name".

However, that's not what we'll get. At best we'll end up with:
"mailto:request@host.com?Body=subscribe&Body=somelist&Body=User%20Name".
At worst, only one of the items will be included.

Hmmmm.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 18 Mar 1997 10:02:09 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: List server command syntax

At 6:44 AM -0500 97/3/18, James Berriman wrote:
>Grant asked for feedback on his list of command abbreviations. Personally,
>I find the terminology rather implementation-specific and inflexible.
...
>Rather than trying to define a standard list of command abbreviations,
>let's look for a flexible way to allow precise description of any command
>syntax.

The abbreviations don't describe the command syntax (terminology) in that
way. They are a meta-descriptor used to identify a specific type of
command/action. For example, SUB identifies a subscription command (not
it's syntax). We still need to work out how to describe the syntax used for
that command.

To further clarify, you might describe a specfic command syntax in the form:
  SUB<mailto:server@host.com?Body=join%20somelist>
The SUB merely identifies to the interpreter that the URL is a syntax
descriptor for a subscription command "join somelist".

In any case, I think it's important for the client applications to be able
to know what kind of command is being described in order to properly
present it to the user, possibly providing context-sensitive help or
guides. (we don't have to use abbreviations, they're just what I've been
using so far)

As an example: knowing that a given command is a subscribe command, a mail
client could warn the user that they may receive a lot of messages in their
mailbox if they perform the command. If the client also knows the digest
mode command, it might offer the user that option as an alternative.

We will need to come up with a way for services to introduce commands that
do not have a 'known' category.


>Here's my current help file for AutoShare:

Thanks. I'll expand the list of 'known' command types to include those.


>For those of us who are on the Mac platform, I'll say that this strikes me
>as very reminiscent of an Applescript dictionary.
>
>Take a 'core suite' of commands (sub, unsub, help), then allow the
>individual developer/listmom to add to this using an unambigous syntax.

A useful perspective.

>If you have fields for command, command description and command syntax then
>a mail client should be able to build a list interface tailored exactly to
>the list software (e.g. buttons with pop-up descriptions).

Yes. You have a set of 'well known' common commands (sub, unsub, digest,
etc.) which can be individually expanded upon, as well as ways of
describing 'unknown' command types.

Hmmm.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 18 Mar 1997 10:10:35 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Internet-Draft full text (not yet submitted)

This is the not-yet-submitted Internet-Draft for the List Headers.
It's also available at:

  http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-00.txt

Please send in your recommendations and comments. (even if it's just to say
"okay").

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[this draft has not yet been formally submitted]

INTERNET-DRAFT                                          Grant Neufeld
draft-baer-listspec-00.txt                      independent developer
Expires August 1997                                    Joshua D. Baer
                                                 SkyWeyr Technologies
                                                           March 1997


       The Use of URLs as Meta-Syntax for Core Mail List Commands
           and their Transport through Message Header Fields

Status of this Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its
      areas, and its working groups.  Note that other groups may also
      distribute working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as
      ``work in progress.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa),
      nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
      ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   The mailing list command specification header fields are a simple set
   of fields to be added to email messages sent by email distribution
   lists. Each field contains a URL (usually mailto or http) locating
   the relevant information or performing the command directly.  The
   three core header fields described in this document are List-Help,
   List-Subscribe, and List-Unsubscribe.

   By including these header fields, mail clients can provide automated
   tools for performing these functions.  This could take the form of a
   menu item, push button, or other user interface element.  The intent
   is to simplify the user experience, providing a common interface to
   the often cryptic and varied mailing list manager commands.


Baer & Neufeld                                                  [Page 1]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


1. Introduction

   This is a proposal for additional header fields to be added to email
   messages sent by email distribution lists.  The content of each new
   header is a URL (usually mailto or http) locating the relevant
   information or performing the command directly.  The three core
   headers are List-Help, List-Subscribe, and List-Unsubscribe.

   Implementing these headers will be optional.  Significant
   functionality and convenience can be gained by including them,
   however.  Many list managers, especially as the proposal first gains
   acceptance, may only choose to implement one or two of the headers.
   The List-Help header is the most useful individual header since it
   provides an access point to detailed user support information, and
   accommodates almost all existing list managers command sets.  The
   List-Subscribe and List-Unsubscribe headers are also very useful, but
   cannot describe some list manager syntaxes at this time (those which
   require variable substitution).  See the appendix for an explanation.

   The description of command syntax provided by the headers can be used
   by mail client applications to provide simplified and consistent user
   access to email distribution list functions.  This could take the
   form of menu items, push buttons, or other user interface elements.
   The intent is to simplify the user experience, providing a common
   interface to the often cryptic and varied mailing list manager
   commands.

   Consideration has been given to avoiding the creation of too many
   headers, while at the same time avoiding the overloading of
   individual headers and keeping the syntax clear and simple.


2. The Command Syntax

   The contents of the list headers consist of angle-bracket ('<', '>')
   enclosed URLs, with internal whitespace being ignored.

   The use of URLs allows for the use of the syntax with existing URL
   supporting applications.  As the standard for URLs is extended, the
   list headers will gain the benefit of those extensions.
   Additionally, the use of URLs provides access to multiple transport
   protocols (such as ftp and http) although it is expected that the
   "mailto" protocol will be the focus of most use of the list headers.

   Command syntaxes requiring variable fields to be set by the client
   (such as including the user's email address within a command) are not
   supported by this implementation at this time.  However, systems
   using such syntaxes may still take advantage of the List-Help header
   to provide the user with detailed instructions as required or -


Baer & Neufeld                                                  [Page 2]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   perhaps more usefully - provide access to a web based command
   interface.

   The additional complications of supporting variable fields within the
   command syntax was determined to be too difficult to support at this
   stage and would compromise the likelihood of implementation by
   software authors.

   To allow for future extension, client applications must follow the
   following guidelines for handling the contents of the headers
   described in this document:

   1) If the content of the header (following any leading whitespace)
      begins with any character other than the opening angle bracket
      '<', the header should be ignored.
   2) Any characters in the header after the first closing angle
      bracket '>' are to be ignored.


3. The Core Headers

   This document presents three headers which will provide the command
   syntax description for the 'core' functions of most email
   distribution lists.  The headers implemented on a given list should
   be included on all posts to the list, and on other messages where the
   message clearly applies to one distinct list.  Only one header of
   each type should be present in any given message, to avoid any
   confusion on the part of the mail client.

   The headers are presented in order of suggested priority.

3.1. List-Help

   The List-Help header is the most important of the headers being
   proposed.  It would be perfectly acceptable for a list manager to
   include only this header, since by definition it should direct the
   user to complete instructions for all other commands.  Typically,
   this would return the help file for the list or a web page with list
   instructions. Of all four headers, this one is the most likely
   candidate for an http URL rather than a mailto, since a web page can
   be used to provide a lot more information about the list, as well as
   a form interface for command access.

   Examples:

    List-Help: <mailto:list@host.com?subject=help>
    List-Help: <mailto:list-manager@host.com?body=info>
    List-Help: <http://www.host.com/list/>
    List-Help: <mailto:list-info@host.com>
    List-Help: <ftp://ftp.host.com/list.txt>


Baer & Neufeld                                                  [Page 3]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


3.2. List-Unsubscribe

   The URL of the List-Unsubscribe header should generally describe the
   mail message (mailto) to directly unsubscribe the user (removing them
   from the list).  Alternately, the URL may connect the user to some
   other mechanism (such as a web page) which performs this function.

   Examples:

    List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
    List-Unsubscribe:
        <mailto:list-request@host.com?subject=unsubscribe>
    List-Unsubscribe:
        <mailto:list-manager@host.com?body=unsubscribe%20list>
    List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>
    List-Unsubscribe: <mailto:list-off@host.com>

3.3. List-Subscribe

   The URL of the List-Subscribe header should generally describe the
   mail message (mailto) to directly subscribe the user (requesting
   addition to the list).  Alternately, the URL may connect the user to
   some other mechanism (such as a web page ) which performs this
   function.

   Examples:

    List-Subscribe: <mailto:list@host.com?subject=subscribe>
    List-Subscribe: <mailto:list-request@host.com?subject=subscribe>
    List-Subscribe:
        <mailto:list-manager@host.com?body=subscribe%20list>
    List-Subscribe: <http://www.host.com/list.cgi>
    List-Subscribe: <mailto:list-on@host.com>


4. Security Considerations

   There are very few security concerns with this proposal.  Headers are
   an existing standard, designed to easily accommodate new types.
   There may be concern with multiple headers being inserted or headers
   being forged, but these are problems inherent in Internet email, not
   specific to this proposal.  Further, the implications are relatively
   harmless.

   On the client side, there may be some concern with posts or commands
   being sent in error.  It is suggested that the user have a chance to
   confirm any action before it is executed.  In the case of mailto, it
   may be appropriate to create the correctly formatted message without
   sending it, allowing the user to see exactly what is happening and
   giving the user the ability to stop the message before it is sent.


Baer & Neufeld                                                  [Page 4]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


5. Acknowledgements

   The participants of the ListMom-Talk, List-Managers, MIDA-Mail and
   List-Header mailing lists contributed much to the formation and
   structure of this document.

   Keith Moore <(suppressed)@cs.utk.edu> and Christopher Allen
   <(suppressed)@consensus.com> provided guidance on the standards
   process.


Appendix

A. Background Discussion

   This proposal arose from discussions started on the ListMom-Talk
   Discussion List [2].  When the discussion reached a sufficient level,
   a separate list was formed for discussing this proposal, the List
   Headers Mail List [3] for deeper discussion.  We have included edited
   excerpts from that discussion here, in order to show some of the
   alternatives examined and reasons for our decisions.

A.1. Multiple header fields vs. a single header field

   Use of a single header field for transporting command meta-syntax was
   rejected for a number of reasons.

   Such a header would require the creation of a new meta-syntax in
   order to describe the list commands (as opposed to the use of the
   widely deployed URL syntax which was chosen for this implementation).
    Every additional layer of complexity and newness reduces the
   likelihood of actual implementation because it will require
   additional work to support.  Also, by using the existing URL syntax,
   we can profit from the end users' knowledge of that syntax and
   ability to use it even if their client applications do not support
   the list header fields.

   Restricting the transport of meta-syntax to the use of a single
   header field also introduces complications with header size
   limitations.  Most individual commands can easily be described in a
   single line, but describing a multitude of commands can take up many
   lines in the header and runs a greater risk of being modified by an
   existing server on route.

   The client implementation is also easier with multiple headers, since
   each command can be supported and implemented individually,
   completely independent of the others.  Thus, some list managers or
   mail clients can choose to implement a subset of the headers based on
   the specific needs of their individual lists.


Baer & Neufeld                                                  [Page 5]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   Finally, this format is simple and well recognized, which reduces the
   chances of errors in implementation and parsing.

A.2. URLs vs. parameter lists

   URLs are already an established syntax which is flexible,
   well-defined, and in wide spread use.  As it's definition matures and
   expands, the abilities of the list headers will grow as well, without
   requiring modification of this proposal.  URLs are well prepared to
   handle future protocols and developments, and can easily describe the
   different existing access protocols such as mailto, http and ftp.

   Many clients already have functionality for recognizing, parsing, and
   evaluating URLs, either internally or by passing the request to a
   helper application.  This makes implementation easier and more
   realistic.  As an example, this existing support for URL parsing
   allowed us to add prototype list header functionality to existing
   mail clients (Eudora and Emailer for the Macintosh) without modifying
   the source code.

A.3. Why not create a standard command language?

   A standard command language, supported by all email list services,
   would go a long way to reducing the problems of list access that
   currently plague existing services.  It would reduce the amount of
   learning required by end users and allow for a number of common
   support tools to be developed.

   However, such standardization does pose problems in the areas of
   multi-lingual support and the custom needs of individual mailing
   lists. The development of such a standard is also expected to be met
   with a slow adoption rate by software developers and list service
   providers.

   These do not preclude the development of such a standard (in fact, it
   would suggest that we should start sooner rather than later), but we
   do need a solution that can be widely supported by the current list
   services.

   We can support most existing list manager command syntaxes without a
   standard command language.  By using URLs, we allow alternate access
   methods a standard command language probably wouldn't enable, such as
   web based control.

   Finally, client support for a standard command language is not at all
   clear or simple to implement.  The variety and large number of
   commands existing today would require complicated user interfaces
   which could be confusing and difficult to implement.  By restricting
   this proposal to the core functions, the client implementation is
   much simpler, which significantly increases the likelihood of


Baer & Neufeld                                                  [Page 6]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   implementation (as evidenced by the support already announced by some
   client and server application authors) and makes the entire proposal
   more realistic.


A.4. Internationalization

   All of this is up to the URL standard.  If URLs support it, our
   proposal supports it.  This is another advantage of using URLs as the
   building blocks of the headers.

A.5. Variable Substitution

   Variables would allow this proposal to accommodate pretty much every
   existing list manager.  However, it would immeasurably increase the
   complexity of the entire proposal, and possibly involve redefining
   the URL standard.

   Parameters would either have to be mandatory (i.e. the user agent
   doesn't submit the message if it doesn't know what text to
   substitute) or you need a way to say "if you know this parameter, add
   its text here; otherwise, do this" where "this" is either: (a)
   substitute a constant string, or (b) fail.

   The reason you need a facility like this is because some list robots
   insist on having certain parameters like users' names, which the user
   agent might or might not know.  e.g. listserv insists on having a
   first name and a last name if you supply either one.

   Which would lead to something like the UNIX shell syntax, where
   ${foo-bar} means substitute the value of parameter "foo" if "foo" is
   defined, else substitute the string "bar".  Perhaps $foo would mean
   "substitute the value of parameter foo if it is defined, else
   substitute the empty string"

   This all seems far too complicated for the gains involved, especially
   since the variables can often be avoided.

   The use of variables in the command syntaxes of list services appears
   to be lessening and does not, in any case, apply to all commands.
   While the unsubscribe and subscribe command header fields may not be
   usable by those systems which require the use of variables, the help
   field will still provide end users with a consistent point of access
   through which they can get support for their use of the list.

A.6. Why not use a specialized MIME part?

   Because most mail clients currently either don't support MIME or are
   not equipped to handle such specialized parts - resulting in problems


Baer & Neufeld                                                  [Page 7]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   for end users.  It is also not as easy for many list servers to
   implement MIME as it is to implement new headers.

   However, we are looking at how to implement MIME support in the
   future when the software is able to handle it.

A.7. Why include a Subscribe command?

   Because users who have unsubscribed (before going on vacation, or for
   whatever other reason) may want to resubscribe to a list.  Or, a
   message may be forwarded/bounced from a subscriber to a
   non-subscriber.  Or, the user may change addresses and want to
   subscribe from their new address.

   The three most commonly supported and used commands for email list
   access are those described by the header fields in this proposal.

A.8. The Dangers of Header Bloat

   At what point are there just too many headers?  It really varies on a
   list by list basis.  On some lists, the majority of users will never
   be aware of a header unless the client software provides some
   alternative user interface to it (akin to the Reply-To header).  On
   others, the users will often see the headers of messages and would
   immediately recognize the URLs contained within.

   We feel the flexibility afforded by this proposal (in that the
   headers may be individually implemented as deemed appropriate)
   provides list administrators with sufficient 'room to maneuver' to
   meet their individual needs.


B. Client Implementation

B.1. Guidelines

   For 'mailto' URL based commands, it is recommended that mail client
   applications give specialized feedback (such as presenting a dialog
   or alert), instead of the actual command email message, asking for
   command confirmation from the user.  The feedback should identify the
   message destination and command within a more descriptive
   explanation.  For example:

     "Do you want to send the unsubscription command 'unsubscribe
      somelist' to 'somelist-request@some.host.com'?
      Sending the command will result in your removal from the
      associated list."


Baer & Neufeld                                                  [Page 8]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   If the user has multiple email addresses supported by the mail
   client, the client application should prompt the user for which
   address to use when subscribing or performing some other action where
   the address to use cannot be specifically determined.  When
   unsubscribing or such, the address tha command can be supported and
implemented individually,
   completely independent of the others.  Thus, some list managers or
   mail clients can choose to implement a subset of the headers based on
   the specific needs of their individual lists.


Baer & Neufeld                                                  [Page 5]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   Finally, this format is simple and well recognized, which reduces the
   chances of errors in implementation and parsing.

A.2. URLs vs. parameter lists

   URLs are already an established syntax which is flexible,
   well-defined, and in wide spread use.  As it's definition matures and
   expands, the abilities of the list headers will grow as well, without
   requiring modification of this proposal.  URLs are well prepared to
   handle future protocols and developments, and can easily describe the
   different existing access protocols such as mailto, http and ftp.

   Many clients already have functionality for recognizing, parsing, and
   evaluating URLs, either internally or by passing the request to a
   helper application.  This makes implementation easier and more
   realistic.  As an example, this existing support for URL parsing
   allowed us to add prototype list header functionality to existing
   mail clients (Eudora and Emailer for the Macintosh) without modifying
   the source code.

A.3. Why not create a standard command language?

   A standard command language, supported by all email list services,
   would go a long way to reducing the problems of list access that
   currently plague existing services.  It would reduce the amount of
   learning required by end users and allow for a number of common
   support tools to be developed.

   However, such standardization does pose problems in the areas of
   multi-lingual support and the custom needs of individual mailing
   lists. The development of such a standard is also expected to be met
   with a slow adoption rate by software developers and list service
   providers.

   These do not preclude the development of such a standard (in fact, it
   would suggest that we should start sooner rather than later), but we
   do need a solution that can be widely supported by the current list
   services.

   We can support most existing list manager command syntaxes without a
   standard command language.  By using URLs, we allow alternate access
   methods a standard command language probably wouldn't enable, such as
   web based control.

   Finally, client support for a standard command language is not at all
   clear or simple to implement.  The variety and large number of
   commands existing today would require complicated user interfaces
   which could be confusing and difficult to implement.  By restricting
   this proposal to the core functions, the client implementation is
   much simpler, which significantly increases the likelihood of


Baer & Neufeld                                                  [Page 6]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   implementation (as evidenced by the support already announced by some
   client and server application authors) and makes the entire proposal
   mo


----------------------------------------------------------------------

Date: 18 Mar 1997 10:20:23 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Internet-Draft full text (part 2)

It's also available at:

  http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-00.txt

Looks like my mailer cut the document off after page 6 :-(

Here's the rest of the draft:

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   implementation (as evidenced by the support already announced by some
   client and server application authors) and makes the entire proposal
   more realistic.


A.4. Internationalization

   All of this is up to the URL standard.  If URLs support it, our
   proposal supports it.  This is another advantage of using URLs as the
   building blocks of the headers.

A.5. Variable Substitution

   Variables would allow this proposal to accommodate pretty much every
   existing list manager.  However, it would immeasurably increase the
   complexity of the entire proposal, and possibly involve redefining
   the URL standard.

   Parameters would either have to be mandatory (i.e. the user agent
   doesn't submit the message if it doesn't know what text to
   substitute) or you need a way to say "if you know this parameter, add
   its text here; otherwise, do this" where "this" is either: (a)
   substitute a constant string, or (b) fail.

   The reason you need a facility like this is because some list robots
   insist on having certain parameters like users' names, which the user
   agent might or might not know.  e.g. listserv insists on having a
   first name and a last name if you supply either one.

   Which would lead to something like the UNIX shell syntax, where
   ${foo-bar} means substitute the value of parameter "foo" if "foo" is
   defined, else substitute the string "bar".  Perhaps $foo would mean
   "substitute the value of parameter foo if it is defined, else
   substitute the empty string"

   This all seems far too complicated for the gains involved, especially
   since the variables can often be avoided.

   The use of variables in the command syntaxes of list services appears
   to be lessening and does not, in any case, apply to all commands.
   While the unsubscribe and subscribe command header fields may not be
   usable by those systems which require the use of variables, the help
   field will still provide end users with a consistent point of access
   through which they can get support for their use of the list.

A.6. Why not use a specialized MIME part?

   Because most mail clients currently either don't support MIME or are
   not equipped to handle such specialized parts - resulting in problems


Baer & Neufeld                                                  [Page 7]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   for end users.  It is also not as easy for many list servers to
   implement MIME as it is to implement new headers.

   However, we are looking at how to implement MIME support in the
   future when the software is able to handle it.

A.7. Why include a Subscribe command?

   Because users who have unsubscribed (before going on vacation, or for
   whatever other reason) may want to resubscribe to a list.  Or, a
   message may be forwarded/bounced from a subscriber to a
   non-subscriber.  Or, the user may change addresses and want to
   subscribe from their new address.

   The three most commonly supported and used commands for email list
   access are those described by the header fields in this proposal.

A.8. The Dangers of Header Bloat

   At what point are there just too many headers?  It really varies on a
   list by list basis.  On some lists, the majority of users will never
   be aware of a header unless the client software provides some
   alternative user interface to it (akin to the Reply-To header).  On
   others, the users will often see the headers of messages and would
   immediately recognize the URLs contained within.

   We feel the flexibility afforded by this proposal (in that the
   headers may be individually implemented as deemed appropriate)
   provides list administrators with sufficient 'room to maneuver' to
   meet their individual needs.


B. Client Implementation

B.1. Guidelines

   For 'mailto' URL based commands, it is recommended that mail client
   applications give specialized feedback (such as presenting a dialog
   or alert), instead of the actual command email message, asking for
   command confirmation from the user.  The feedback should identify the
   message destination and command within a more descriptive
   explanation.  For example:

     "Do you want to send the unsubscription command 'unsubscribe
      somelist' to 'somelist-request@some.host.com'?
      Sending the command will result in your removal from the
      associated list."


Baer & Neufeld                                                  [Page 8]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997


   If the user has multiple email addresses supported by the mail
   client, the client application should prompt the user for which
   address to use when subscribing or performing some other action where
   the address to use cannot be specifically determined.  When
   unsubscribing or such, the address that is subscribed should be used,
   unless that is not known by the application and cannot be determined
   from the message headers.

B.2. Implementation Options

   The following implementation possibilities are suggested here to give
   some idea why these new headers will be useful, and how they could be
   supported.  Prototype menu items and floating pallettes have already
   been implemented in more than one mail client.

   In most cases, it may be helpful to disable the commands when not
   applicable to the currently selected message.

B.2.1. Key combinations and command lines

   On text based systems which utilize command lines or key
   combinations, each header could be implemented as a separate command.
    Thus one combination would subscribe the user, another would
   unsubscribe, a third request help, etc.  The commands would only be
   available on messages containing the List headers.

B.2.2. Menu items

   On graphical systems which have menus, these commands could take the
   form of a menu or sub-menu of items.  For example, a "Lists" menu
   might appear when viewing messages containing the headers, with items
   named "Subscribe", "Unsubscribe" and "Get Help".  This menu could be
   disabled when not applicable to the current message or disappear
   entirely.

B.2.3. Push Buttons and Pallettes

   On graphical window systems, buttons could be placed in the window of
   the message, a toolbar, or in a floating pallette of their own.  Each
   button could correspond to a header, with names "Subscribe",
   "Unsubscribe" and "Get Help".  These buttons or pallettes could be
   disabled when not applicable to the current message or disappear
   entirely.


Baer & Neufeld                                                  [Page 9]

INTERNET-DRAFT            draft-baer-listspec-00              March 1997

B.2.4 Feedback to the User

   When putting up a dialog (or other feedback element) the client
   application may find it useful to include an option for the user to
   review (and possibly modify) the message before it is sent. The
   application may also find it useful to provide a link to more
   detailed context-sensitive assistance about mail list access in
   general.


References

  [1] RFC 822 <URL:ftp://ftp.internic.net/rfc/rfc822.txt>

  [2] ListMom-Talk@skyweyr.com
      <URL:http://cgi.skyweyr.com/ListMom.Home>

  [3] List-Header@arpp.carleton.ca
      <URL:http://arpp.carleton.ca/listspec/mail/>

  [4] <URL:http://arpp.carleton.ca/listspec/>

  [5] K. Moore, "Re: MailList Specification Headers Proposal 0.0.9",
      List Header Mail List.  21 February 1997.
      <URL:http://arpp.carleton.ca/listspec/mail/#Digest>

  [6] P. Hoffman and L. Masinter, "The mailto URL scheme"
      'work in progress' <URL:ftp://ftp.internic.net/
      /internet-drafts/draft-hoffman-mailto-url-00.txt>


Editors' addresses

Joshua D. Baer
Box 273
4902 Forbes Avenue
Pittsburgh, PA 15213-3799
USA

Email: josh@skyweyr.com


Grant Neufeld
Ottawa, Ontario
Canada

Email: grant@acm.org


Baer & Neufeld                                                 [Page 10]

[EOF]

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 18 Mar 1997 13:05:51 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: Re: HTML Forms for syntax (was: List server command syntax)

At 14:36 18/3/97, Grant Neufeld wrote:
>At 6:44 AM -0500 97/3/18, James Berriman wrote:

>>The interesting thing would be working out how to define the form ACTION.
>
>mailto: ?

[snip]

>An obvious problem being the 'stacking' of form fields into one field. What
>we want, in this case, is to add the items sequentially with a space
>between each item - which results in:
>"mailto:request@host.com?Body=subscribe%20somelist%20User%20Name".
>
>However, that's not what we'll get. At best we'll end up with:
>"mailto:request@host.com?Body=subscribe&Body=somelist&Body=User%20Name".
>At worst, only one of the items will be included.
>
>Hmmmm.

Yes, that's why I said it would be interesting. ;-)

Since you don't have a web server to process the form data, it has to be
done at the client end. I wonder if this has been addressed in other areas?

Is there a mechanism for extending actions?

What's required is some way to tell the client "process all this yourself,
then send the result as email". Perhaps by adding a new METHOD to the
mailto: ACTION.

<FORM ACTION="mailto:request@host.com" METHOD=MLM>

Presumably, a non-savvy browser would ignore this method, while a savvy
browser or email client could use this as a key to say 'process the form,
then mail the result to this address'.

On the face of it, it looks like a potentially workable solution. And
elegant, since you only have to define a new METHOD.

( :-])  James


----------------------------------------------------------------------

Date: 18 Mar 1997 15:10:30 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: Re: HTML Forms for syntax (was: List server command syntax)

I have a feeling that the model followed in the extended mailto: draft would
be an excellent guide for the possible implementation of a MAIL method for
HTML forms.

The idea would be to create a form whose fields/checkboxes etc mapped to mail
headers, with multiple instances of the name 'body' allowing a
multiple-command message to be created.

Then you could _literally_ mail someone a subscription form for your list :-)

( :-])  James


----------------------------------------------------------------------

Date: 18 Mar 1997 22:31:06 -0500
From: "a.h.s. boy" <(suppressed)@nothingness.org>
Subject: Re:Internet-Draft full text (not yet submitted)

On the subject of "Internet-Draft full text (not yet submitted)" hath
scrawled Grant Neufeld:
> This is the not-yet-submitted Internet-Draft for the List Headers.
> It's also available at:
>
>   http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-00.txt
>
> Please send in your recommendations and comments. (even if it's just to say
> "okay").

Wow, guys, looks good. Covers the situation well, and it reads well
(that, or I'm getting too accustomed to technical writing).

My only concerns, from a sort of bureaucratic standpoint, are the parts
about the limitations of the implementation, or the things we _didn't_
do. Sections like

  >  The additional complications of supporting variable fields within the
  >  command syntax was determined to be too difficult to support at this
  >  stage and would compromise the likelihood of implementation by
  >  software authors.

This strikes me as a bit odd, as if it draws too much attention to the
"problems" encountered in drawing up the proposal, rather than focusing
on the positive and productive goals that were actually achieved. I
don't think this is a major shortcoming of the proposal, I'm just
noting that there's no good reason to state what _didn't_ come out of
the proposal in such a forthright manner.

I know that, if someone comes to me and says "Look what my project
does!", it comes across much better than if someone says "Look, my
project doesn't do everything I want it to, but it does some stuff."

Just picking a few nits. But like I said, certainly not a show-stopper.
And at least it provides a segue into the discussion of how
implementation needs to provide for future revisions...

That aside, fine work to the both of you!

spud.


 -------------------------------------------------------------------------
  a.h.s. boy ---------------------- manifesto overlord, dada typographics
       spud@nothingness.org ------- http://www.nothingness.org/
Now featuring Social Anarchism and the Situationist International archives

        "J'suis l'enfant de l'etat, et je me bats contre ca"


----------------------------------------------------------------------

Date: 18 Mar 1997 23:27:30 -0500
From: "Roger Fajman" <(suppressed)@CU.NIH.GOV>
Subject: Re:  Internet-Draft full text (not yet submitted)

The draft seems to be well written and, in my opinion, provides useful
functionality.  I know that a goal is to keep it simple, but I think
that a List-archives header giving a URL for the archived postings to
the list would be an extremely useful facility for list subscribers.


----------------------------------------------------------------------

Date: 19 Mar 1997 02:44:36 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re:  Internet-Draft full text (not yet submitted)

At 11:17 PM -0500 3/18/97, Roger Fajman wrote:


> The draft seems to be well written and, in my opinion, provides useful
> functionality.  I know that a goal is to keep it simple, but I think
> that a List-archives header giving a URL for the archived postings to
> the list would be an extremely useful facility for list subscribers.

I had List-Archive, List-Post, and List-Digest in the first draft of the
proposal.  We took them out because we were afraid that if there were too
many headers, none would get accepted... how does everyone else feel about
this issue?

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyWeyr Technologies
http://www.skyweyr.com/


----------------------------------------------------------------------

Date: 19 Mar 1997 02:50:12 -0500
From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu>
Subject: Re: Internet-Draft full text (not yet submitted)

>>>>> "JDB" == Joshua D Baer <(suppressed)@skyweyr.com> writes:

JDB> [...] We took them out because we were afraid that if there were too
JDB> many headers, none would get accepted... how does everyone else feel
JDB> about this issue?

Start simple.  I fear that archive retrieval is so much more varied than
subscription that a discussion could easily bog down.  Unsubscription is
relatively simple and yet look at the discussion it has taken to get this
far.
- -- 
      Jason L. Tibbitts III - tibbs@uh.edu - 713/743-8684 - 221SR1
System Manager:  University of Houston High Performance Computing Center
                1994 PC800 "Kuroneko"      DoD# 1723


----------------------------------------------------------------------

Date: 19 Mar 1997 04:44:10 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: Internet-Draft full text (not yet submitted)

At 10:26 PM -0500 97/3/18, a.h.s. boy wrote:
>Wow, guys, looks good. Covers the situation well, and it reads well
>(that, or I'm getting too accustomed to technical writing).

I'll take that as a compliment (I think ;-)

>My only concerns, from a sort of bureaucratic standpoint, are the parts
>about the limitations of the implementation, or the things we _didn't_
>do. Sections like
>
>  >  The additional complications of supporting variable fields within the
>  >  command syntax was determined to be too difficult to support at this
>  >  stage and would compromise the likelihood of implementation by
>  >  software authors.
>
>This strikes me as a bit odd, as if it draws too much attention to the
>"problems" encountered in drawing up the proposal, rather than focusing
>on the positive and productive goals that were actually achieved. I
>don't think this is a major shortcoming of the proposal, I'm just
>noting that there's no good reason to state what _didn't_ come out of
>the proposal in such a forthright manner.

Except that, as was suggested to us (I think by Keith but it's late and my
memory could be faulty), to better weather the storm of standardization we
should try to minimize the arguments that could arise against the proposal.
We can do this by clearly showing what alternatives have already been
considered, why we chose this solution over those alternatives, and
identifying the limitations our solution presents.

By doing that, we'll hopefully prevent unnecessary rehashing of the debates
we've already had, and show that we're not blazing ahead with one solution
without consideration for the alternatives, and to future developments.

With standards processes, the less room you give for people to complain,
the better your chance of actually getting a proposal approved - and in a
reasonable time.

We've had what I consider to be a very well-rounded group of people
considering and commenting on this proposal (software developers - both
client & server, list administrators & users, and 'standards' people). I
think we're on pretty solid ground for proceeding with this, but we don't
want to leave any dangling threads for the nitpickers to tug at.

Phew, I think I'm dragging on a bit here - way past sleep time...

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 19 Mar 1997 04:54:08 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re:  Internet-Draft full text (not yet submitted)

At 11:17 PM -0500 97/3/18, Roger Fajman wrote:
>The draft seems to be well written and, in my opinion, provides useful
>functionality.  I know that a goal is to keep it simple, but I think
>that a List-archives header giving a URL for the archived postings to
>the list would be an extremely useful facility for list subscribers.

Frankly, there are a bunch of things that would be useful to implement.
However, I don't think we can safely push more that the "core 3" at this
time without compromising the standards process.


However, that doesn't prevent us from looking at additional header fields
like Digest, Archives, Post, and Software outside the current standards
push. Digest and Archive would, in my view, fit the same syntax as the core
3, containing just an URL. The others may require different methods.

However, (I use "However" a lot, it seems) rather than looking to more
individual command headers, I think it would be best to look now to
defining a comprehensive list command meta-syntax and also examine other
methods of transporting that meta-syntax (such as message footers or a
header like the under-discussion 'List-Commands').

I'd say more now, but I'm drifting off while typing here.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 19 Mar 1997 09:00:41 -0500
From: "Michael Quinlan" <(suppressed)@primenet.com>
Subject: Re: Internet-Draft full text (not yet submitted)

> From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
> 
> However, (I use "However" a lot, it seems) rather than looking to more
> individual command headers, I think it would be best to look now to
> defining a comprehensive list command meta-syntax and also examine other
> methods of transporting that meta-syntax (such as message footers or a
> header like the under-discussion 'List-Commands').

How do you deal with internationalization issues in the meta-syntax? The
mail client should display the commands in the reader's native language.
This is true even, I think, when the list itself is in English -- examples
are the ietf list or this list-header list which are in English but the
readership is international. That is easy if the commands are fixed because
the words can be translated in advance (the mail client can have a table or
file with the word "Unsubscribe" translated into different languages, for
example). If you have dynamic commands with a meta-syntax, how does the
mail client convert the command description into the reader's native
language?


----------------------------------------------------------------------

Date: 19 Mar 1997 11:38:49 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: Internet-Draft full text (not yet submitted) 

> Except that, as was suggested to us (I think by Keith but it's late and my
> memory could be faulty), to better weather the storm of standardization we
> should try to minimize the arguments that could arise against the proposal.
> We can do this by clearly showing what alternatives have already been
> considered, why we chose this solution over those alternatives, and
> identifying the limitations our solution presents.

If you want, you can put in a section that says list-archive, etc. are
"to be defined" or "for future study".  If people like the draft,
they'll probably want to include at least a couple of these.

(I'd personally like to standardize a lot more about list archives
than just a header pointing to them...for example, most web archives
are hideous.  I'd *really* like to see list archives accessible by
IMAP..., or at least NNTP, so we'd have good tools for browsing them)

Keith


----------------------------------------------------------------------

Date: 19 Mar 1997 16:54:17 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: Internet-Draft full text (not yet submitted)

At 11:35 AM -0500 97/3/19, Keith Moore wrote:
>If you want, you can put in a section that says list-archive, etc. are
>"to be defined" or "for future study".  If people like the draft,
>they'll probably want to include at least a couple of these.

How about:

A.9. Additional header fields for future consideration

   Some of the other headers fields which have been considered, but
   which have been set aside for further study, are as follows:

     List-Digest: a command URL to switch to digest mode.
     List-Post: email address to post to as a mailto URL.
     List-Admin: contact URL for list administrator (usually a human).
     List-Archive: access URL for list archives (old messages).
     List-Software: list processing software name and version information


BTW, I've added List-Archive to the listspec discussion page:

  List-Archive:
       <<command URL (e.g., <ftp://host.com/list/archive/>)>>
  Access to archive of past list messages. Often an ftp or http site,
  although some servers may support the mailto "Get Index" type commands.


>(I'd personally like to standardize a lot more about list archives
>than just a header pointing to them...for example, most web archives
>are hideous.  I'd *really* like to see list archives accessible by
>IMAP..., or at least NNTP, so we'd have good tools for browsing them)

Why is the phrase "Pandora's Box" flashing through my brain as I think
about the consequences of making this proposal in the first place...
There seems to be no end to the things needing to be dealt with when it
comes to mail lists.

I think maybe we should all just take more naps.

- --
"If God had meant computers to be easy, She'd have made them all Macs."
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 19 Mar 1997 20:24:47 -0500
From: "Roger Fajman" <(suppressed)@CU.NIH.GOV>
Subject: Re:  Internet-Draft full text (not yet submitted)

>    Some of the other headers fields which have been considered, but
>    which have been set aside for further study, are as follows:
>
>      List-Digest: a command URL to switch to digest mode.
>      List-Post: email address to post to as a mailto URL.
>      List-Admin: contact URL for list administrator (usually a human).
>      List-Archive: access URL for list archives (old messages).

If the idea is to restrict the document to a minimal core set of
headers, it seems like the ones with the most utility ought to be
picked.  I think everyone agrees that Unsubscribe is critical and Help
is the escape hatch for everything that's not included, but by what
stretch of the imagination is Subscribe more useful than Archives or
Admin?  The justification for Subscribe in the draft seems pretty thin
to me.


----------------------------------------------------------------------

Date: 19 Mar 1997 20:30:33 -0500
From: "Roger Fajman" <(suppressed)@CU.NIH.GOV>
Subject: Re:  Internet-Draft full text (not yet submitted)

> (I'd personally like to standardize a lot more about list archives
> than just a header pointing to them...for example, most web archives
> are hideous.  I'd *really* like to see list archives accessible by
> IMAP..., or at least NNTP, so we'd have good tools for browsing them)

I don't see why web archives necessarily have to be hideous.  Isn't
that just poor implementation?  I have no objection to making list
archives available via IMAP and/or NNTP, but I think that web access
is what most ordinary users would like to have.  And why is this a
good subject for stnadardization?  Let's see what people can do.


----------------------------------------------------------------------

Date: 19 Mar 1997 20:47:05 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: Internet-Draft full text (not yet submitted) 

> How about:
> 
> A.9. Additional header fields for future consideration
> 
>    Some of the other headers fields which have been considered, but
>    which have been set aside for further study, are as follows:
> 
>      List-Digest: a command URL to switch to digest mode.
>      List-Post: email address to post to as a mailto URL.
>      List-Admin: contact URL for list administrator (usually a human).
>      List-Archive: access URL for list archives (old messages).
>      List-Software: list processing software name and version information

looks good enough to start with.

> >(I'd personally like to standardize a lot more about list archives
> >than just a header pointing to them...for example, most web archives
> >are hideous.  I'd *really* like to see list archives accessible by
> >IMAP..., or at least NNTP, so we'd have good tools for browsing them)
> 
> Why is the phrase "Pandora's Box" flashing through my brain as I think
> about the consequences of making this proposal in the first place...
> There seems to be no end to the things needing to be dealt with when it
> comes to mail lists.

For what it's worth, IETF tried several years ago to form a working
group to standardize list server behavior.  It died in vicious flame
wars because there were too many different but well-established ways
of doing things.

Nowadays, the most popular list servers are more alike than different,
so we might actually get somewhere with a standards effort.  

Keith


----------------------------------------------------------------------

Date: 19 Mar 1997 22:37:25 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: Internet-Draft full text (not yet submitted) 

> > (I'd personally like to standardize a lot more about list archives
> > than just a header pointing to them...for example, most web archives
> > are hideous.  I'd *really* like to see list archives accessible by
> > IMAP..., or at least NNTP, so we'd have good tools for browsing them)
> 
> I don't see why web archives necessarily have to be hideous.  Isn't
> that just poor implementation?  

It's like trying to use a knife blade as a screwdriver....sure it
might do in a pinch, but the knife blade is not a good tool for the
job.

Mail readers are very good tools for reading mail.  News readers are
very good tools for reading news.  Web browsers are neither.  (This
applies even to the built-in mail and news reading capabilities in all
of the browsers I've seen that have such capabilities, though I'm sure
they'll get better.)

> I have no objection to making list archives available via IMAP
> and/or NNTP, but I think that web access is what most ordinary users
> would like to have.

Actually, given a choice between a familiar user interface that the
user can choose (the user's mail or news reader), and an unfamiliar
user interface that differs from one site to another (a web-based mail
archive), it seems like most users would prefer the former.

> And why is this a
> good subject for stnadardization?  Let's see what people can do.

The standard wouldn't preclude having a web interface to a mail
archive, nor discourage implementation of such things.  But it would
allow the perusal of mail archives using existing tools which are
better at the job than web browsers.

Keith


----------------------------------------------------------------------

Date: 20 Mar 1997 00:47:05 -0500
From: Bonnie Scott <(suppressed)@staff.prodigy.com>
Subject: Re: Getting off-topic to Web Archives (was: Internet-Draft  full text
(not yet submitted))

since we digressed into Web archives...

(I'll get back to list headers at the end ... I promise.)

>> > (I'd personally like to standardize a lot more about list archives
>> > than just a header pointing to them...for example, most web archives
>> > are hideous.  I'd *really* like to see list archives accessible by
>> > IMAP..., or at least NNTP, so we'd have good tools for browsing them)
>> 
>> I don't see why web archives necessarily have to be hideous.  Isn't
>> that just poor implementation?  

At 10:33 PM 3/19/97 -0500, Keith Moore wrote:
>It's like trying to use a knife blade as a screwdriver....sure it
>might do in a pinch, but the knife blade is not a good tool for the
>job.
>
>Mail readers are very good tools for reading mail.  News readers are
>very good tools for reading news.  Web browsers are neither. 

We currently archive our 150+ mailing lists using Hypermail, a program
available from www.eit.org, but no longer maintained by them. HM was
originally written by Kevin Hughes, more info at
http://web.eit.com/goodies/software/hypermail/ 
It's impressive for the lower-volume lists.  After I posted about it
elsewhere, Paul Du Bois wrote to me...

>I've collected some patches to hypermail that eliminate some of the hangs
>and crashes.  These are available at:
>
>	http://www.primate.wisc.edu/software/web-tools/
>
...
>Paul DuBois
>dubois@primate.wisc.edu
>Home page: http://www.primate.wisc.edu/people/dubois
> Software: http://www.primate.wisc.edu/software

(more about HM way at the bottom)

Mailing List mail is no longer just text... and the threading structure
lends itself to hypertextification as easily as newsgroup-style browsing.
(especially for people who don't WANT to memorize one-letter commands)

Mailing lists are becoming the way to let (voluntarily-subscribed) people
learn about and get reminded about Web sites, in addition to all the other
roles lists play.  So that you don't have to keep every message in your
mailbox, the archives SHOULD be a click or two away from where you're
reading the current issue, whether it's done in the headers or as an active
URL in the  message footer.

Now, to tie this back into list headers...  :)

I've been thinking about what headers I will *really* need.  For a long
time, I thought the only one I'd be using would be 

List-Help: <http://goodstuff.prodigy.com/Mailing_Lists/listname.html>
(which I could just as happily call For-More-Info:)

I've now realized that 
List-Unsubscribe:
<mailto:listname-request@listserv.prodigy.com?body=unsubscribe>

should go in ours too, even though I'd *like* to keep the entire interface
consistent -- and on the Web.  On the Web, I can present info about the
list, archives, and subscription form all on the same page. I can say, "do
you really, really want to unsubscribe--we'll miss you!"  If you're paranoid
about subscription forgeries from the Web, you should be requiring confirms
or running closed lists: a Web form is maybe 2% easier than forging e-mail
well enough to trick most MLMs.

What I'd rather do for the unsubscribe is 
List-Unsubscribe:
<http://goodstuff.prodigy.com/cgi-bin/mailto?body=unsubscribe&to=listname-re
quest@listserv.prodigy.com&from=fill-in-my-id&nexturl=byebye.htm>

which is my current script used in the Web forms.  How *would* the ID get
filled in by the client, in this case? I read the section on variables and
also

>   If the user has multiple email addresses supported by the mail
>   client, the client application should prompt the user for which
>   address to use when subscribing or performing some other action where
>   the address to use cannot be specifically determined.  When
>   unsubscribing or such, the address that is subscribed should be used,
>   unless that is not known by the application and cannot be determined
>   from the message headers.

I wouldn't assume that prompting the user is going to get you more reliable
information. ;-> You're right about NOT being able to assume an address from
the headers, although I think a "received for" on the top line, or a To:
matching a known alias for the user should take precedence over the primary
(or current) user-supplied address in the client. 

Q: If I put both versions of the unsub command on the line, as suggested
earlier on the list, I'd want to put
List-Unsubscribe: <mailto:for-lower-capability-clients>
<http://for-higher-capability-ones>

And I'd want the http one to be given higher precedence if supported... how
to specify that?  (The mailto would have to be first, I think, for the
lower-capability clients to work.)

Anyway, I'm enjoying this list and think that the spec looks great--as I
said, I'll just be using two of the headers, and maybe List-Archives: too,
if it's implemented. :) 

Bonnie Scott
Prodigy Services Corp.

more digressions about Web Archives and Hypermail...


If you still doubt that HTML is appropriate for mailing list archives, take
a look at 

moderated:
http://www.goodstuff.prodigy.com/Lists/livedigi/
http://www.goodstuff.prodigy.com/Lists/virushelp/
http://www.goodstuff.prodigy.com/Lists/your-biz/

unmoderated:
http://www.goodstuff.prodigy.com/Lists/parenting/  (warning: out of date)
http://www.goodstuff.prodigy.com/Lists/singles/

 (Of course, they should be searchable and kept up to date... mea culpa.)  

I think the value of the archives is augmented by an HTML format for many
types of lists. 

Having said all that... if anyone would like to investigate starting up a
group to maintain and add a few features to Hypermail, please write to me at
bonnie@staff.prodigy.com  <--- that would be hyperlinked with Hypermail <VBG>

I don't have a lot of time, but I'd be willing to start up a Hypermail
mailing list to discuss adding changes to Paul's patches, and I have some
cosmetic changes I'd be willing to code in. (a "header" or "body" parameter
distinct from the "label").

returning to lurk mode now... hope to hear from you


----------------------------------------------------------------------

Date: 20 Mar 1997 01:32:38 -0500
From: "Roger Fajman" <(suppressed)@CU.NIH.GOV>
Subject: Re:  Internet-Draft full text (not yet submitted)

> Actually, given a choice between a familiar user interface that the
> user can choose (the user's mail or news reader), and an unfamiliar
> user interface that differs from one site to another (a web-based mail
> archive), it seems like most users would prefer the former.

I suppose it depends on your user community.  A rather small portion
of ours uses NNTP and, today at least, an even smaller portion uses
IMAP.  Everyone has a web browser though.

> The standard wouldn't preclude having a web interface to a mail
> archive, nor discourage implementation of such things.  But it would
> allow the perusal of mail archives using existing tools which are
> better at the job than web browsers.
>
> Keith

The availablity of multiple ways to access archives is an argument
for allowing the specification of multiple URLs, allowing the client
to choose the ones it can handle.  That could be done by having
multiple URLs in one header or multiple List-Archive headers.

By the way, what should be done with List-xxx headers when one list
is subscribed to another?  I don't recall that problem being dealt with
in the draft.


----------------------------------------------------------------------

Date: 20 Mar 1997 02:10:02 -0500
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: Getting off-topic to Web Archives (was: Internet-Draft   full
text (not yet submitted))

At 12:43 AM -0500 3/20/97, Bonnie Scott wrote:

> Anyway, I'm enjoying this list and think that the spec looks great--as I
> said, I'll just be using two of the headers, and maybe List-Archives: too,
> if it's implemented. :)

Keep in mind that you can put whatever headers you want in the message.  I
think they are still useful in the case where only power users see headers.

~Josh


- -- ----------------------------------
Joshua D. Baer

SkyWeyr Technologies
http://www.skyweyr.com/


----------------------------------------------------------------------

Date: 20 Mar 1997 02:38:40 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: Getting off-topic to Web Archives (was: Internet-Draft full text 
(not yet submitted))

> since we digressed into Web archives...
> 
> We currently archive our 150+ mailing lists using Hypermail, a program
> available from www.eit.org, but no longer maintained by them. HM was
> originally written by Kevin Hughes, more info at
> http://web.eit.com/goodies/software/hypermail/ 
> It's impressive for the lower-volume lists.  

Yes, hypermail is nice for people who don't need to do lots of
perusing of mail archives, and have high-bandwidth connections, and
whose mail readers don't do threading.  But it's no substitute for a
real mail reader:

+ the web archive interface is slow and unreliable
+ the web archive interface  varies from one archive to another
+ I've yet to see one of these things that has flexible searching
  capabilities.  (e.g.: find every message that is from joe or
  bob, has arrived in the last 180 days, and which contains the word kumquat) 
+ I can't easily reply to a message on a web archive. Even if 
  the recipient's address is a mailto URL link, it's not the 
  same as a reply: the subject isn't set correctly; there's no 
  in-reply-to field (for future threading); mailto URLs don't 
  let me reply to sender and all recipients of the subject message 
  (which is usually the correct thing to do); as for composing
  the reply - web forms and the mail composers built into web 
  browsers are uniformly lousy. 
+ The web browser doesn't let me pgp-sign my replies, nor does it 
  let me verify the pgp signatures of archived messages.
+ *All* of the commands on a web mail archive take up precious screen
  space, which makes it more difficult to read the message.  This is
  unlike that of normal email readers which can use keyboard
  characters, popup menus, and pulldown menus; and mouse clicks
  can do something besides "go here".
+ I get tired of scrolling to the top or bottom of a message just
  to click on the 'next' button.  I get tired of being constrained
  to a heavily modal, menu-driven interface.
+ I can't easily move messages from a web-based mail archive into
  my own personal message store; the web browser typically doesn't
  recognize the stuff in the archive as a mail message, and even if
  it did, it's not integrated with the message store that my mail
  reader uses.
+ I can't do searching across multiple folders.
+ The web server doesn't keep track of which messages I've read,
  deleted, or replied-to.  My mail reader keeps track of
  read/deleted/replied-to/annotations, and my news reader keeps 
  track of which articles I've read/killed/marked.
+ The web archive server doesn't know about my kill file.
+ The web archive server can't automatically classify 
  messages according to criteria that I define.
+ The web server makes arbitrary and capricious decisions about what 
  parts of the archived message I need to be able to see.  Sometimes 
  I really do need to see the received headers.
+ I can't perform operations on multiple messages in a web archive.
  (delete, refile to a local folder, mark as read, forward
  en masse to somewhere else)

and so on.

And lest it seem like I'm making things up -- with one exception, all
of the features of news or mail readers that I mention above are
things that I use every day.  (I only use PGP once or twice a week)

Saying that the web is sufficient for mail archives is like saying we
don't need a directory access protocol -- instead of LDAP, can't we
just use the web?  No, because the web doesn't present a uniform
interface that clients can use to do queries across servers.  Or
instead of sending mail with SMTP, why don't we all just have our own
web forms with cgi scripts that people visit and fill out and which
deliver the message to us?  Because it's slow and tedious and
incredibly painful to send the same message to multiple recipients.

> Mailing List mail is no longer just text... and the threading structure
> lends itself to hypertextification as easily as newsgroup-style browsing.
> (especially for people who don't WANT to memorize one-letter commands)

Threads are nice.  Some mail readers, and nearly all news readers,
support them.  (I don't know what you mean by newsgroup-style
browsing, since news readers do support threads, and command syntax
varies from one product to another.)  There are people (like myself)
who don't WANT to have to scroll a document looking for a clickable
link or button just to do a very common operation...and for whom single
character commands or multi-character typed-in commands or pull-down 
menus with commands like "reply (all)" or "pgp sign" are pretty nice.

> Mailing lists are becoming the way to let (voluntarily-subscribed) people
> learn about and get reminded about Web sites, in addition to all the other
> roles lists play.  So that you don't have to keep every message in your
> mailbox, the archives SHOULD be a click or two away from where you're
> reading the current issue, whether it's done in the headers or as an active
> URL in the  message footer.

Ideally this would be done by my mail reader, with recent messages
being kept in my message store and automatically deleted after a
certain age; the archive would be used to access older messages.  That
way, if I did a search of all messages on a list, my mail reader would
send that search to the mail archive for the older messages, perform
the search locally for the ones stored on-hand, and combine the
results in a single view.

With the web archives, when I really need to do lots of searching, I
typically download ALL of the stored messages and put them in a mail
folder...*if* they're still available in something resembling vanilla
rfc822 format.  (By the time they're web-ified, too much information
has been lost to allow my mail reader to deal with them.)

> What I'd rather do for the unsubscribe is 
> List-Unsubscribe:
> <http://goodstuff.prodigy.com/cgi-bin/mailto?body=unsubscribe&to=listname-re
> quest@listserv.prodigy.com&from=fill-in-my-id&nexturl=byebye.htm>
> 
> which is my current script used in the Web forms.  

So you'd prefer to limit access to your lists to people who have
on-demand internet access and forms-capable web browsers?

This is why I am/was resistant to using URLs at all in email headers.
All email readers can send replies; only a very few of them are
forms-capable web browsers.  (and the ones that do are either lousy
email readers, lousy web browsers, or both)

> Q: If I put both versions of the unsub command on the line, as suggested
> earlier on the list, I'd want to put
> List-Unsubscribe: <mailto:for-lower-capability-clients>
> <http://for-higher-capability-ones>
> 
> And I'd want the http one to be given higher precedence if supported... how
> to specify that?  (The mailto would have to be first, I think, for the
> lower-capability clients to work.)

Yes, but the *user* might well prefer the email interface...

If you want him to fill out a form when he leaves, you can always mail
it to him as a MIME text/html object..

> If you still doubt that HTML is appropriate for mailing list archives, take
> a look at 
> 
> moderated:
> http://www.goodstuff.prodigy.com/Lists/livedigi/
> http://www.goodstuff.prodigy.com/Lists/virushelp/
> http://www.goodstuff.prodigy.com/Lists/your-biz/

I looked at them.  This would be fine for occasional browsing.  But if
I had to use this interface to find something I needed to know (say,
to review an old discussion on one of the lists), I'd find the
hypermail interface so useless that I wouldn't even bother.

Keith


----------------------------------------------------------------------

Date: 20 Mar 1997 02:44:12 -0500
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: Internet-Draft full text (not yet submitted) 

> > Actually, given a choice between a familiar user interface that the
> > user can choose (the user's mail or news reader), and an unfamiliar
> > user interface that differs from one site to another (a web-based mail
> > archive), it seems like most users would prefer the former.
> 
> I suppose it depends on your user community.  A rather small portion
> of ours uses NNTP and, today at least, an even smaller portion uses
> IMAP.  Everyone has a web browser though.

Yep, there's the rub.  But if we had a standard client-server
interface to mail archives, mail and news readers would probably 
support it. Especially if it were an interface they already 
supported anyway.

> The availablity of multiple ways to access archives is an argument
> for allowing the specification of multiple URLs, allowing the client
> to choose the ones it can handle.  That could be done by having
> multiple URLs in one header or multiple List-Archive headers.

Yep.

> By the way, what should be done with List-xxx headers when one list
> is subscribed to another?  I don't recall that problem being dealt with
> in the draft.

the Right Thing might depend on the header.  A List-Archive, List-Info, etc
header field should probably remain unchanged, while a List-Unsubscribe field
should probably point to the innermost list server.

Keith


----------------------------------------------------------------------

Date: 20 Mar 1997 14:26:36 -0500
From: Steve Watt <(suppressed)@newcastle.ac.uk>
Subject: Re: Getting off-topic to Web Archives (was: Internet-Draft

Bonnie,

I've copied this to the list, I hope it isn't too far off topic to upset 
anybody - if you're not interested in hypermail go no further.

Bizzare as it may sound, my hypermail developers list has just been set 
up at Mailbase (the email discussion list service for the UK HE academic 
community).

I'm the Webmaster for Mailbase; we have 1146 lists open for web access and 
use hypermail to generate 12 month archives eg :

http://www.mailbase.ac.uk/lists/mailbase-news/archive.html

We think it's great software, and a lot of people use it, but the lack of 
current support and development is a problem.
I'd like the list to provide a focus for discussion and development on 
hypermail, bug fixes, ideas, new software  etc.

If you're interested in joining, mail to:
 
        mailbase@mailbase.ac.uk
 
a message containing only the following text (substituting appropriately):
 
        join hypermail-developers firstname(s) lastname
 
For further information relating to this new list, contact its owner at
 
        hypermail-developers-request@mailbase.ac.uk

Steve

> 
> since we digressed into Web archives...

> Having said all that... if anyone would like to investigate starting up a
> group to maintain and add a few features to Hypermail, please write to me at
> bonnie@staff.prodigy.com  <--- that would be hyperlinked with Hypermail
<VBG>
> 
> I don't have a lot of time, but I'd be willing to start up a Hypermail
> mailing list to discuss adding changes to Paul's patches, and I have some
> cosmetic changes I'd be willing to code in. (a "header" or "body" parameter
> distinct from the "label").
> 
> returning to lurk mode now... hope to hear from you
> 
> 
> 

Stephen Watt,           Webmaster, Programmer and Database Administrator
Mailbase,
Newcastle University,                   http://www.mailbase.ac.uk/
Newcastle upon Tyne,                    Tel: 0191 222 5003
UK, NE1 7RU                             Fax. 0191 222 8580


----------------------------------------------------------------------

Date: 20 Mar 1997 18:56:54 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: Re: HTML Forms for syntax (was: List server command syntax)

I did a bit of research.

>From rfc 1867:

5.6 Allow form ACTION to be "mailto:"

   Independent of this proposal, it would be very useful for HTML
   interpreting user agents to allow a ACTION in a form to be a
   "mailto:" URL. This seems like a good idea, with or without this
   proposal. Similarly, the ACTION for a HTML form which is received via
   mail should probably default to the "reply-to:" of the message.
   These two proposals would allow HTML forms to be served via HTTP
   servers but sent back via mail, or, alternatively, allow HTML forms
   to be sent by mail, filled out by HTML-aware mail recipients, and the
   results mailed back.

Does anyone know whether this idea got any further?

Alongside the extended mailto: draft and the listheader draft, HTML forms by
mail would neatly complete the picture.

Suppose that you use the list-help: header to retrieve an auto-response and
the returned help file contains an HTML form, with reply-to: set to your
list's management address.

This gives you the same functionality as a web form interface, but via mail.

I understand the current Eudora beta handles HTML formatting. Have they
implemented any kind of form support?

( :-])  James


----------------------------------------------------------------------

Date: 25 Mar 1997 09:12:49 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: the Internet-Draft has been submitted

The list header proposal has now been formally submitted to the internet
standards track as an Internet-Draft, and will hopefully show up in the
drafts directory by the end of this week.

http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-00.txt

[there is a Mac BBEdit copy with the sections marked for easier reference:
  http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-00.txt.sit  ]

We made a few revisions yesterday (mostly grammatical) and a couple
additions. In particular, the security section was expanded based on
discussion here (lists passing List- fields that they didn't create), and a
potential problem that occurred to me yesterday morning (accessing local
URLs):

4. Security Considerations

   There are very few new security concerns generated with this
   proposal.  Headers are an existing standard, designed to easily
   accommodate new types. There may be concern with multiple headers
   being inserted or headers being forged, but these are problems
   inherent in Internet email, not specific to this proposal.  Further,
   the implications are relatively harmless.

   Mail list processors should not allow any user-originated list header
   fields to pass through to their lists, lest they confuse the user and
   have the potential to create security problems.

   On the client side, there may be some concern with posts or commands
   being sent in error.  It is suggested that the user have a chance to
   confirm any action before it is executed.  In the case of mailto, it
   may be appropriate to create the correctly formatted message without
   sending it, allowing the user to see exactly what is happening and
   giving the user the ability to stop the message before it is sent.

   Mail client applications should not support list header field URLs
   which could compromise the security of the user's system. This
   includes the "file://" URL type which could potentially be used to
   trigger the execution of a local application on some user systems.


I don't think I'll ever be 100% satisfied with the draft (or any draft, for
that matter), but we've reached the point of diminishing returns for doing
further editing. Most further work would just be clarification and
grammatical cleaning of what's already said in the draft.

I think the document says everything it needs to in order to succeed at the
goal we've set for it (although somebody will no doubt point out some
gaping hole now that it's submitted - it's inevitable ;-)

Thanks to everyone for your interest, support, questions, doubts and
contributions. (I'd like to thank my family, the film's producers,... :-)

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 25 Mar 1997 09:17:15 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: continuing the work

First off, my apologies for my absence the past little while. I have read
all the stuff posted here and intend to reply, over the next few days, to a
number of messages I have backlogged.

Now that the draft has been submitted, there is a lot of other work to be
done.

We'll need to work to get it passed as an RFC. (Any advice Keith,
Christopher?)

We also need to evangelize this to get it implemented. I think our "prime
target" :-) should be AOL. If we get them to properly support the List-
headers in their mail client, we'll have helped a massive amount of people.
We've been told that the Eudora (supposidly the most widely used GUI email
client) people are already working on it, so we could have siginificant
coverage pretty soon.

It would be great if we could get PINE and ELM teams on this as well.
Anyone here know people there?

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 25 Mar 1997 14:36:26 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Re: continuing the work

At 9:13 AM -0500 on 3/25/97, Grant Neufeld wrote:
>
> We also need to evangelize this to get it implemented. I think our "prime
> target" :-) should be AOL. If we get them to properly support the List-
> headers in their mail client, we'll have helped a massive amount of people.
> We've been told that the Eudora (supposidly the most widely used GUI email
> client) people are already working on it, so we could have siginificant
> coverage pretty soon.

I've posted a note about the draft on QM-L, a discussion list for CE
Software's QuickMail. CE now has a pop client version of QuickMail, called
QuickMail Pro, which is a direct competitor of Eudora (but not with the
penetration). The older product requires a proprietary server, and would
therefore have a much tougher time supporting this draft (headers getting
to the client depend on proprietary third-party gateways).

Another major vendor in Mac messaging is FirstClass, a BBS system. Does
anyone know much about their system? I know a little, and I could post a
query to one list of FirstClass users I know about, but unlike QM-L I don't
know that the manufacturer is listening!

Kent Larsen

P.S., shouldn't a notice about this be passed on to Listmom-talk and
list-managers? Is someone on majordomo-users who could post a notice that
the draft is complete there?


Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work).


----------------------------------------------------------------------

Date: 25 Mar 1997 22:47:17 -0500
From: "Daniel Berlinger" <(suppressed)@circumtech.com>
Subject: Re: continuing the work


> It would be great if we could get PINE and ELM teams on this as well. 
> Anyone here know people there? 

Grant,

DO you have a form letter type of deal put together the relevant urls?

If so, I'd like to hit a couple of companies (namely Intercon and BareBones) 
with this info...

Daniel


Daniel Berlinger                      Circumstance Technology
http://www.circumtech.com/                     Digital Shaman
    Linkwright  Data Poet  Systems Anarchist  Idiosyncrat  
Interactivist    Herder of Cats    Zero Tolerance For Silence


----------------------------------------------------------------------

Date: 26 Mar 1997 10:52:14 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Fwd: QM Support for List Mgmt (was Re: continuing the work)

Here's the information I posted to QM-L, a QuickMail list. I think a good
strategy for publicizing the draft is to post information like this to
appropriate newsgroups, mailing lists, etc., as well as approaching email
client software vendors.


- --- begin forwarded text

Recently, a draft RFC has been submitted that email clients like QuickMail
should support (at least QuickMail Pro should support this - QuickMail LAN
would have a more difficult time).

If adopted and supported by email software vendors, this draft would make it
easier for the users to join and leave email lists.

The draft calls for new message headers to be included in each message
coming from a list. These headers, List-Subscribe, List-Unsubscribe and
List-Help, would contain URLs that allow easily joining, leaving and getting
help on email lists.

The URLs could be in any accepted URL format, which might include the http:
URLs that web surfers are familiar with, but also might include the mailto:
URL that email software could support.

For example, a List-Unsubscribe header might read something like:

List-Unsubscribe: <http://www.dom.ain/listname/unsubscribe.pl>

or it might be:

List-Unsubscribe: <mailto:majordomo@dom.ain?body=unsubscribe%20list>

For these headers to be useful, email clients need to support them. Support
can be very simple, however. In the case of http or other URLs, the email
software (QuickMail Pro, for example), rather than become a browser, can
pass the URL to a browser, which would then show the appropriate page.

In the case of a mailto: URL, however, the email software can go a step
further - it can actually compose a message for the user's approval, given
the information in the URL.

Email client software might even recognize the presence of these headers and
put a button on the screen, or enable a command that would allow the user to
simply click on a button or choose a command from a menu to subscribe,
unsubscribe or get help on a list.

I feel this idea has a lot of merit. Given the number of different email
list management packages available, the confusing array of commands and
terminology is not likely to diminish soon. Users need help too often just
getting on and off of a list.

This is a simple and straightforward way of making it easier for users to
participate in lists.

I'm posting this basically to let those on QM-L know, and to ask CE Software
to support this effort. The details of this draft RFC can be found at:

http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-oo.txt

An ongoing discussion of putting list headers in email messages, and efforts
to improve on this specification is occuring on the list-header email list:

X-List-Subscribe: <mailto:list-header@arpp.carleton.ca?Subject=subscribe>
X-List-Help: <http://arpp.carleton.ca/listspec/mail/>

CE Software should be especially interested in the guidelines for mail
client software authors at:

<http://arpp.carleton.ca/listspec/client-author.html>

I should note for those interested that Qualcomm has limited support for
this RFC in its current beta version of Eudora because it supports clicking
on URLs (URL is passed to browser specified in ICeTEe) and because it
interprets
the mailto: URL. I'm told that Claris Emailer's latest beta also has support
for this.

Can anyone at CE tell us what will happen with QuickMail Pro?

I assume that QuickMail LAN  will have difficulty with this because of the
coordination needed with a gateway?

Kent


- ----------------------------------------------------------------------
Kent Larsen                        North-South Books, Inc.
<(suppressed)@NorthSouth.com>           <(suppressed)@NorthSouth.com>
Director of Finance                1123 Broadway, Suite 800
and Operations                     New York, NY 10010
Voice: (212) 463-9736              Fax: (212) 633-1004
- ----------------------------------------------------------------------


- ----------------------------------------------------------------------
Kent Larsen                        North-South Books, Inc.
<(suppressed)@NorthSouth.com>           <(suppressed)@NorthSouth.com>
Director of Finance                1123 Broadway, Suite 800
and Operations                     New York, NY 10010
Voice: (212) 463-9736              Fax: (212) 633-1004
- ----------------------------------------------------------------------

- --- end forwarded text


Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work).


----------------------------------------------------------------------

Date: 26 Mar 1997 11:08:10 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Response form QuickMail

Here's a copy of the response that QM-L received from CE Software regarding
the draft. They seem to support the idea, but aren't saying exactly what
will happen and when. Its also only happening in QM-PRO, not in QM-LAN
because it uses a proprietary server.


- --- begin forwarded text

Date:    Tue, 25 Mar 1997 13:46:15 -0600
From:    "Christian F. Gurney" <(suppressed)@CESOFT.COM>
Subject: Re: QM Support for List Mgmt

Kent Larsen wrote:
>Recently, a draft RFC has been submitted that email clients like QuickMail
>should support (at least QuickMail Pro should support this - QuickMail LAN
>would have a more difficult time).
>
>If adopted and supported by email software vendors, this draft would make it
>easier for the users to join and leave email lists.
>
>The draft calls for new message headers to be included in each message
>coming from a list. These headers, List-Subscribe, List-Unsubscribe and
>List-Help, would contain URLs that allow easily joining, leaving and
getting
>help on email lists.

<snip>

And he also wrote:
>I should note for those interested that Qualcomm has limited support
>for this RFC in its current beta version of Eudora because it
>supports clicking on URLs (URL is passed to browser specified
>in ICeTEe) and because it interprets the mailto: URL. I'm told
>that Claris Emailer's latest beta also has support for this.
>
>Can anyone at CE tell us what will happen with QuickMail Pro?

Kent, thanks for posting this message. This is an important issue and
actually a big problem for users. Many times we've seen the situation where
people new to the listservers subscribe and then struggle to unsubscribe.
Clearly, something needs to be done to make it easier.

I can see no reason why CE wouldn't support this in our QuickMail Pro
line. In fact, you noted above that other products support URL and mailto
functions in the clients. QM Pro does this as well and that support could be
enhanced or adjusted, if needed, to support the functions you mention. The
foundation already exists in our products.

I'm not committing to a date in this message because we need to further
research the problem and the proposed solution, but we do intend to strive
to provide the best products and we will look at this very seriously.

Christian F. Gurney
Vice President of Product Lines
CE Software, Inc.

=================================================================
christian_gurney@cesoft.com
http://www.cesoft.com
- --> Check out CE's newest Internet E-mail Product, QuickMail Pro
=================================================================

- --- end forwarded text


Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work).


----------------------------------------------------------------------

Date: 26 Mar 1997 11:14:54 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: List of Email Clients

The December 96 issue of Internet World had a product comparison of the
following 12 email clients. I thought the list would be useful for our
evangelizing efforts:

BeyondMail 3.0          http://www.coordinate.com/             Mac, Win
Claris Em@iler 1.2      http://www.claris.com/                 Mac
E-Mail Connection 3.0   http://www.connectsoft.com/            Win
Eudora Pro 3.0          http://www.eudora.com/                 Mac, Win
Graphic E-mail 1.1c     http://www.clever.net/ge               Win
Mail Explorer 1.24      http://www.city-net.~mbt/csmail.html   Win95
Microsoft Exchange 95   http://www.microsoft.com/              Win95
MS Internet Mail & News http://www.microsoft.com/              Win95
Netscape Navigator Mail http://www.netscape.com/               Mac, Win, Unix
Pegasus Mail            http://www.pegasus.usa.com/            Dos, Mac, Win,
                                                                 Unix
Pronto Mail for Win95   http://www.commtouch.com/              Win95, WinNT
ZMail Pro               http://www.netmanage.com/              Mac, Win, Unix

I know that this leaves out a lot of programs. (Such as Elm and Pine
already mentioned). However, I think this is a good start?

Who knows what organizations and can pass the information on to the right
people?

Kent

Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work).


----------------------------------------------------------------------

Date: 26 Mar 1997 14:12:31 -0500
From: jud spencer <(suppressed)@claris.com>
Subject: Re: List of Email Clients

On 3/26/97 8:09 AM, Kent S. Larsen II wrote:

>Claris Em@iler 1.2      http://www.claris.com/                 Mac

There is no need to try and lobby Claris, we have been tracking the list 
all along.

- --
jud spencer                    <mailto:jud_spencer@claris.com>
Claris Corp.                           <http://www.claris.com>
                                      <http://www.fogcity.com>


----------------------------------------------------------------------

Date: 26 Mar 1997 14:43:20 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Form Letter to Client Authors (was: continuing the work)

At 10:42 PM -0500 97/3/25, Daniel Berlinger wrote:
>DO you have a form letter type of deal put together the relevant urls?

I've put a draft of one together (it's later in this message). I'd like
people here to review it before we start sending it out.


At 10:44 AM -0500 97/3/26, Kent S. Larsen II wrote:
>I think a good
>strategy for publicizing the draft is to post information like this to
>appropriate newsgroups, mailing lists, etc., as well as approaching email
>client software vendors.

Definitly. I'm compiling a list of authors/companies to contact directly
(using the form letter below, once it's finalized).

We need a few other form letters, too. Direct to list processor authors,
direct to list-owners, general to authors (as in newsgroups where both
client and server authors may be reading), general to client author mail
lists, and general to server authors & managers mail lists. I'll try to get
those done over the next few days.

We should start sending these out next week. This week is difficult for me
since I'm in the process of moving my server and setting up a new lan,
which also means there will be some (hopefully short) interruptions of
service.


Does the following draft letter seem reasonable? Anyone see any problems,
or think there's stuff that should be added?

 --- Begin DRAFT Form Letter to Client Authors ---

[THIS IS A DRAFT - DO NOT USE!]

This is a request for you to implement support for the List Header
initiative which will make mail list access much easier for users.

The newly defined List Header Fields provide you with a standard method by
which you can consistently determine electronic mailing list command syntax
and implement an interface to make list access easier for your
users.

An Internet-Draft (draft-baer-listspec-00.txt), which formally describes
the header fields and their content, has been submitted to the IETF for
consideration to become an RFC.

As they are adopted and supported by email software developers, the List
header fields will make it easier for users to join and leave email lists.

The currently defined fields are List-Subscribe, List-Unsubscribe and
List-Help. They describe commands for subscribing, unsubscribing and
retrieving help information.

Implementation guidelines for email client authors are available at:

  <http://arpp.carleton.ca/listspec/client-author.html>

Extended details on the List header fields (including the current
Internet-Draft) are available from:

  <http://arpp.carleton.ca/listspec/>

A mailing list for discussion is available at:

  <http://arpp.carleton.ca/listspec/mail>
or
  <mailto:list-header@arpp.carleton.ca?Subject=help>


Please let us know if you plan to implement support for the List header
fields, and also if/when you ship an implementation, so we can track the
progress of this initiative. <mailto:grant@acm.org>

 --- End DRAFT Form Letter ---

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 14:57:21 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: HTML Forms for syntax

At 1:04 PM -0500 97/3/18, James Berriman wrote:
>Since you don't have a web server to process the form data, it has to be
>done at the client end. I wonder if this has been addressed in other areas?
>
>Is there a mechanism for extending actions?
>
>What's required is some way to tell the client "process all this yourself,
>then send the result as email". Perhaps by adding a new METHOD to the
>mailto: ACTION.
>
><FORM ACTION="mailto:request@host.com" METHOD=MLM>
>
>Presumably, a non-savvy browser would ignore this method, while a savvy
>browser or email client could use this as a key to say 'process the form,
>then mail the result to this address'.

Perhaps the following methods would make sense?

BODY        Single command line in the body of a message
BODY-MULTI  Multiple command lines in the body of a message
SUBJECT     Single command line in the subject of a message

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 15:14:46 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: meta-syntax internationalization in custom commands (was:
Internet-Draft full text (not yet submitted))

At 8:59 AM -0500 97/3/19, Michael Quinlan wrote:
>How do you deal with internationalization issues in the meta-syntax? The
>mail client should display the commands in the reader's native language.
>This is true even, I think, when the list itself is in English -- examples
>are the ietf list or this list-header list which are in English but the
>readership is international. That is easy if the commands are fixed because
>the words can be translated in advance (the mail client can have a table or
>file with the word "Unsubscribe" translated into different languages, for
>example). If you have dynamic commands with a meta-syntax, how does the
>mail client convert the command description into the reader's native
>language?

I don't see a reasonable way to do that, unless custom commands have a
mechanism for inclusion of multi-lingual descriptions.

Keep in mind that hopefully the majority of possible list commands will be
defined by the meta-syntax. The reason for including the flexibility for
lists to define custom command types outside those defined by the
meta-syntax is to allow for unforseen needs of lists. Hopefully such
circumstance will be quite rare, if occuring at all.

Such custom commands should will likely be defined in the language(s) used
on the list they are defined for. So, if I have a list
alien-food@invasion.mars which has a unique setting command available to
its users, it would be expected that the description of the custom command
"Zarvox Mode: messages transported with psi-thermal wrappings" would be in
the language used on the alien-food list.

If the same command starts appearing on other list services, it should be
identified as a candidate for standardization and thence
internationalization.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 15:22:48 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Re: Form Letter to Client Authors (was: continuing the work)

At 2:42 PM -0500 on 3/26/97, Grant Neufeld wrote:
>
> We need a few other form letters, too. Direct to list processor authors,
> direct to list-owners, general to authors (as in newsgroups where both
> client and server authors may be reading), general to client author mail
> lists, and general to server authors & managers mail lists. I'll try to get
> those done over the next few days.
>

I think it would be useful to contact the folks that run Liszt
(http://www.liszt.com/) and other mailing list directory owners. I'm not
sure if they could allow use of them, but they have the addresses of 70,000
or more listowners, as well as site managers, etc.

Lyris has information on the site managers that use Listserv, doesn't it?
Would it be within reason for them to notify their site owners?

Has anyone contacted these people yet or have contacts with them? Comments
on whether they could ethically use their lists to support us (maybe we'd
end up spamming all list onwers?)

Kent


>From Kent Larsen <(suppressed)@panix.com>, owner of Mormon-index, a weekly
message containing announcements of Mormon internet resources.

To subscribe, send an email message to majordomo@lists.panix.com, with
"subscribe mormon-index" in the body of the message or visit our
subscription page at
http://www.panix.com/~klarsen/mormon-index/MIsubscribe.html

Announcements should be sent to mormon-index@lists.panix.com


----------------------------------------------------------------------

Date: 26 Mar 1997 16:12:08 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: multiple commands in a single header (was: Getting off-topic to Web
Archives)

At 12:43 AM -0500 97/3/20, Bonnie Scott wrote:
>Q: If I put both versions of the unsub command on the line, as suggested
>earlier on the list, I'd want to put
>List-Unsubscribe: <mailto:for-lower-capability-clients>
><http://for-higher-capability-ones>
>
>And I'd want the http one to be given higher precedence if supported... how
>to specify that?  (The mailto would have to be first, I think, for the
>lower-capability clients to work.)

I think precedence should be determined by order of the options in the
header field. So, in your example above, the mailto would be the first
choice. As to handling lower-capablity clients, all client applications
implementing support for the List header fields are supposed to be able to
somehow handle varying URL protocols. This will most commonly be done by
passing the URL to another application (e.g., a web browser).

The reasons I see for offering multiple command options are to allow the
user to choose or to provide fallback options if the client doesn't support
the preferred protocol (so if they don't support your http preference, they
can still use the mailto command).

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 16:16:07 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: passing List- header fields (was:  Internet-Draft full text (not yet
submitted))

At 1:20 AM -0500 97/3/20, Roger Fajman wrote:
>By the way, what should be done with List-xxx headers when one list
>is subscribed to another?  I don't recall that problem being dealt with
>in the draft.

I added it to the draft (thanks for reminding me of this issue).

Basically, List- header fields should not be passed on to list messages -
they should be filtered out by the list processor (or perhaps prepended
with the "Resent-" prefix).

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 16:30:57 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: evangelizing the List- headers (was: continuing the work)

At 2:12 PM -0500 97/3/25, Kent S. Larsen II wrote:
>I've posted a note about the draft on QM-L, a discussion list for CE
>Software's QuickMail.

>Here's a copy of the response that QM-L received from CE Software regarding
>the draft. They seem to support the idea, but aren't saying exactly what
>will happen and when.

Thanks for contacting them. Sounds promising.

>P.S., shouldn't a notice about this be passed on to Listmom-talk and
>list-managers?

That's on my ever-growing todo list. I'll wait until next week when the
form letters are ready.

>Is someone on majordomo-users who could post a notice that
>the draft is complete there?

I'm compiling a list of whose contacting whom.

If anyone wants to sign up for particular vendors and/or mailing lists
please contact me privatly so I can keep track of the contacts made and
make sure there's no overlap.

Those already covered are:

CLIENTS:
 Emailer   - Claris
 Eudora    - Qualcomm
 QuickMail - CE

SERVERS:
 AutoShare - (who's the author?)
 LetterRip - Fog City
 ListSTAR  - Starnine

MAIL-LISTS
 List-Managers
 ListMom-Talk
 MIDA-Mail
 QM-L

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 16:44:55 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Why List-S ubscribe instead of...? (was:  Internet-Draft full text
(not yet submitted))

At 8:19 PM -0500 97/3/19, Roger Fajman wrote:
>If the idea is to restrict the document to a minimal core set of
>headers, it seems like the ones with the most utility ought to be
>picked.  I think everyone agrees that Unsubscribe is critical and Help
>is the escape hatch for everything that's not included, but by what
>stretch of the imagination is Subscribe more useful than Archives or
>Admin?  The justification for Subscribe in the draft seems pretty thin
>to me.

The thing is to consider which commands are applicable to the largest
number of lists (the core three) and are most frequently used/needed (the
core three).

In any case, the current Internet-Draft's focus on the core three in no way
precludes the development of support for other commands. Josh's
ListMom-Talk list uses:

X-List-Subscribe: <mailto:listmom-talk@skyweyr.com?subject=subscribe>
X-List-Unsubscribe: <mailto:listmom-talk@skyweyr.com?subject=unsubscribe>
X-List-Digest: <mailto:listmom-talk@skyweyr.com?subject=subscribe%20digest>
X-List-Post: <mailto:listmom-talk@skyweyr.com>
X-List-Help: <http://cgi.skyweyr.com/ListMom.Home>
X-List-Software: ListSTAR v1.1 by StarNine Technologies, a Quarterdeck Company
X-List-Host: SkyList by SkyWeyr Technologies,
<http://www.skyweyr.com/skylist/>

There's also the work on a more comprehensive meta-syntax for list
commands, and other transport mechanisms (footers, MIME parts, specialized
messages/files, etc.)

With the Internet-Draft what we're trying to do is get this method of
command description approved so that it then becomes a matter of enhancing
an existing standard. If we were to include all the things we want it's
chances of approval would be greatly lessened. From what I've read and been
told over the years, the standardization process is heavily ladden with
politicking and may require 'devious maneuvering' to actually get things
done.

If we attempt too much at once, we will leave too many openings to be
knocked down. If we instead make a small, but very solid, proposal it can
stand a good chance of succeeding. Once we have that in place, we can use
it to build larger structures to do more of what we want.

Besides, when have developers ever limited themselves to what the standards
say? There's nothing stopping people from implementing List- Digest, Post,
Admin, Archive, Software, Address or any of the other headers discussed on
the listspec page <http://arpp.carleton.ca/listspec/>.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 18:02:37 -0500
From: "a.h.s. boy" <(suppressed)@nothingness.org>
Subject: Re: Form Letter to Client Authors (was: continuing the work)

On the subject of "Re: Form Letter to Client Authors (was: continuing
the wor" hath scrawled Kent S. Larsen II:
> At 2:42 PM -0500 on 3/26/97, Grant Neufeld wrote:
> >
> > We need a few other form letters, too. Direct to list processor authors,
> > direct to list-owners, general to authors (as in newsgroups where both
> > client and server authors may be reading), general to client author mail
> > lists, and general to server authors & managers mail lists. I'll try to
get
> > those done over the next few days.
> >
>
> I think it would be useful to contact the folks that run Liszt
> (http://www.liszt.com/) and other mailing list directory owners. I'm not
> sure if they could allow use of them, but they have the addresses of 70,000
> or more listowners, as well as site managers, etc.

I can take care of that angle -- Scott Southwick, who wrote the Liszt
spider, is an old friend of mine. He just moved, however, and is
incommunicado for about 2 weeks...but I'll get a hold of him as soon as
I can -- I'm sure the headers would do Liszt some good, too, as it can
parse the headers for more significant service information than is
normally retrieved.

What exactly do we want from Liszt?

spud.

 -------------------------------------------------------------------------
  a.h.s. boy ---------------------- manifesto overlord, dada typographics
       spud@nothingness.org ------- http://www.nothingness.org/
Now featuring Social Anarchism and the Situationist International archives

        "J'suis l'enfant de l'etat, et je me bats contre ca"


----------------------------------------------------------------------

Date: 26 Mar 1997 18:35:45 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: press release for list headers

In addition to announcements on the mail lists and contacting the software
authors, I'm also working on a press release.

Please send me press contacts (especially email addresses) for publications
that should be included:
  <mailto:grant@acm.org?Subject=List-Header%20press%20contacts>.

Vendors interested in participating in the press release should contact me
for details:
  <mailto:grant@acm.org?Subject=List-Header%20press%20release>.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 18:37:39 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re: Form Letter to Client Authors

At 5:58 PM -0500 97/3/26, a.h.s. boy wrote:
>On the subject of "Re: Form Letter to Client Authors (was: continuing
>the wor" hath scrawled Kent S. Larsen II:
>> I think it would be useful to contact the folks that run Liszt
>> (http://www.liszt.com/) and other mailing list directory owners. I'm not
>> sure if they could allow use of them, but they have the addresses of 70,000
>> or more listowners, as well as site managers, etc.
...
>What exactly do we want from Liszt?

Mention on their web site (perhaps in the Good Deed section?).

I'm reluctant to ask for a direct mailing to known listserver admins - it
has the potential to be spam, as was mentioned already.

I think our approach should be to directly lobby software authors, and
announce it on a few applicable mail lists and newsgroups. That should
provide sufficient coverage that, from there, individual forwards of the
announcement can cover most of those we might miss.

I'm going to be contacting the listmoms of a few of the lists I'm on to
inform them of this (especially the ones that are currently using headers
like X-URL, X-Unsubscribe-URL, X-Help-URL, etc.). Once the announcements
are sent out, we can expect that others will be doing the same.

I expect that the typical internet replication factor will carry the
information where it needs to go.

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 26 Mar 1997 18:51:55 -0500
From: (suppressed)@frutiger.staffs.ac.uk (James Berriman)
Subject: Re: evangelizing the List- headers (was: continuing the work)

At 21:29 26/03/97, Grant Neufeld wrote:

> AutoShare - (who's the author?)

Mikael Hansen <(suppressed)@dnai.com>

The following list headers are included in the current version (1.2)

X-List-Software: AutoShare 1.2 by Mikael Hansen
X-List-Admin: listmaster@frutiger.staffs.ac.uk (James Berriman)
X-List-Subscribe:
<mailto:autoshare@frutiger.staffs.ac.uk?body=subscribe%20AutoShare-Talk>
X-List-Unsubscribe:
<mailto:autoshare@frutiger.staffs.ac.uk?body=unsubscribe%20AutoShare-Talk>
X-List-Help: http://www.dnai.com/~meh/autoshare/


----------------------------------------------------------------------

Date: 26 Mar 1997 19:01:57 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Re: Form Letter to Client Authors (was: continuing the work)

At 5:58 PM -0500 on 3/26/97, a.h.s. boy wrote:
> > I think it would be useful to contact the folks that run Liszt
> > (http://www.liszt.com/) and other mailing list directory owners. I'm not
> > sure if they could allow use of them, but they have the addresses of
70,000
> > or more listowners, as well as site managers, etc.
>
> I can take care of that angle -- Scott Southwick, who wrote the Liszt
> spider, is an old friend of mine. He just moved, however, and is
> incommunicado for about 2 weeks...but I'll get a hold of him as soon as
> I can -- I'm sure the headers would do Liszt some good, too, as it can
> parse the headers for more significant service information than is
> normally retrieved.
>
> What exactly do we want from Liszt?
>
> spud.

Help in contacting the various site administrators and list owners to get
them to implement the basic headers on their lists.

We'll need to be careful & see if there is an appropriate way to do this,
but the more lists that have these headers already in place, the more
incentive client software authors will have to change their programs, and
the more incentive the ietf will have to adopt the draft. [After all, what
stronger argument is there than that a standard should be adopted because
it is already in use successfully? :-) ]

Kent


>From Kent Larsen <(suppressed)@panix.com>, owner of Mormon-index, a weekly
message containing announcements of Mormon internet resources.

To subscribe, send an email message to majordomo@lists.panix.com, with
"subscribe mormon-index" in the body of the message or visit our
subscription page at
http://www.panix.com/~klarsen/mormon-index/MIsubscribe.html

Announcements should be sent to mormon-index@lists.panix.com


----------------------------------------------------------------------

Date: 27 Mar 1997 12:45:56 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: List-Header Server Notice

The server supporting the List-Header mail list (arpp.carleton.ca), is
being relocated this week. There may be temporary service outages while
this takes place, although measures are being taken to minimize downtime.


While I've got your attention, a reminder that Tuesday is April fools day
and as such is subject to numerous spoofs on the internet. You may want to
doublecheck any 'strange' messages you receive on the first (and for a few
days following). Don't let yourself be tricked by the pranksters.

List-managers may be well-advised to put their lists into moderated mode
for this 'special' day.

(The server move has nothing to do with April fools)

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 27 Mar 1997 21:39:39 -0500
From: "Roger Fajman" <(suppressed)@CU.NIH.GOV>
Subject: Re:  Why List-S ubscribe instead of...?  (was:  Internet-Draft       
  full

> At 8:19 PM -0500 97/3/19, Roger Fajman wrote:
> >If the idea is to restrict the document to a minimal core set of
> >headers, it seems like the ones with the most utility ought to be
> >picked.  I think everyone agrees that Unsubscribe is critical and Help
> >is the escape hatch for everything that's not included, but by what
> >stretch of the imagination is Subscribe more useful than Archives or
> >Admin?  The justification for Subscribe in the draft seems pretty thin
> >to me.
>
> The thing is to consider which commands are applicable to the largest
> number of lists (the core three) and are most frequently used/needed (the
> core three).

Well, I disagree that usage of List-subscribe is likely to be heavy.
I suppose you are correct today that the number of lists with WWW archives
is relatively small, but I think that is likely to be changing fairly
quickly.

> In any case, the current Internet-Draft's focus on the core three in no way
> precludes the development of support for other commands. Josh's
> ListMom-Talk list uses:
>
> X-List-Subscribe: <mailto:listmom-talk@skyweyr.com?subject=subscribe>
> X-List-Unsubscribe: <mailto:listmom-talk@skyweyr.com?subject=unsubscribe>
> X-List-Digest: <mailto:listmom-talk@skyweyr.com?subject=subscribe%20digest>
> X-List-Post: <mailto:listmom-talk@skyweyr.com>
> X-List-Help: <http://cgi.skyweyr.com/ListMom.Home>
> X-List-Software: ListSTAR v1.1 by StarNine Technologies, a Quarterdeck
Company
> X-List-Host: SkyList by SkyWeyr Technologies,
<http://www.skyweyr.com/skylist/>

Of course it can be extended, at the cost of a much longer wait for
the functionality.  It's difficult for me to imagine many client
vendors wanting to support non-standard headers.

> There's also the work on a more comprehensive meta-syntax for list
> commands, and other transport mechanisms (footers, MIME parts, specialized
> messages/files, etc.)

If we wait for that to happen, we will all be gone.  It was bloody the
last time someone tried to do that.  Many people are very set in their
opinions, many of which contradict other people's opinions.

> With the Internet-Draft what we're trying to do is get this method of
> command description approved so that it then becomes a matter of enhancing
> an existing standard. If we were to include all the things we want it's
> chances of approval would be greatly lessened. From what I've read and been
> told over the years, the standardization process is heavily ladden with
> politicking and may require 'devious maneuvering' to actually get things
> done.

Nobody's going to be fooled by limiting the initial proposal to three
headers.  Anyone who's opposed because of the number of headers will
easily see how the initial proposal would be extended.

> If we attempt too much at once, we will leave too many openings to be
> knocked down. If we instead make a small, but very solid, proposal it can
> stand a good chance of succeeding. Once we have that in place, we can use
> it to build larger structures to do more of what we want.
>
> Besides, when have developers ever limited themselves to what the standards
> say? There's nothing stopping people from implementing List- Digest, Post,
> Admin, Archive, Software, Address or any of the other headers discussed on
> the listspec page <http://arpp.carleton.ca/listspec/>.
>
> --
> gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>

Of course they can be implemented, but to be really useful they require
support from both the list management software and the mail clients.
This is much less likely to happen for non-standard headers.


----------------------------------------------------------------------

Date: 28 Mar 1997 11:09:05 -0500
From: Grant Neufeld <(suppressed)@ccs.carleton.ca>
Subject: Re:  Why List-S ubscribe instead of...?

At 9:35 PM -0500 97/3/27, Roger Fajman wrote:
>Well, I disagree that usage of List-subscribe is likely to be heavy.

Frankly, I expect to see some suprising uses of this header. Imagine if
announcements of lists went out with this header attached? You read about a
list, then all you have to do to join is click "subscribe" in your mail
client (or select it from a menu, or whatever).

The subscribe command is used more than unsubscribe. I think it's safe to
say that it's used more than the help command, too. As such, we would be
remiss if we left it out.

Even though it may not seem at first glance to have as much function as
part of mailing list messages, the List-Subscribe header field has a lot of
value. To invite someone else to join the list, you can just bounce a list
message to them. To rejoin a list you unsubscribed (vacation or whatever),
just turn to an archived message from the list. ... and so on.


>> There's also the work on a more comprehensive meta-syntax for list
>> commands, and other transport mechanisms (footers, MIME parts, specialized
>> messages/files, etc.)
>
>If we wait for that to happen, we will all be gone.  It was bloody the
>last time someone tried to do that.  Many people are very set in their
>opinions, many of which contradict other people's opinions.

You're speaking about the efforts to get list servers to standardize on a
common _syntax_. I'm talking about defining a _meta-syntax_ which can be
used to describe any of the syntaxes already in use by list servers.

A meta-syntax could be utilized by any of the existing list servers without
having to modify or add to the command syntaxes already in use.

I think this is why it's been comparativly painless to get people to accept
the List- header proposal - it avoids most of the religious issues
(different syntaxes, body vs. subject, etc.).


>> With the Internet-Draft what we're trying to do is get this method of
>> command description approved so that it then becomes a matter of enhancing
>> an existing standard. If we were to include all the things we want it's
>> chances of approval would be greatly lessened. From what I've read and been
>> told over the years, the standardization process is heavily ladden with
>> politicking and may require 'devious maneuvering' to actually get things
>> done.
>
>Nobody's going to be fooled by limiting the initial proposal to three
>headers.  Anyone who's opposed because of the number of headers will
>easily see how the initial proposal would be extended.

_could_ be extended.

Personally, I favor focusing on other transport mechanisms rather than
further expansion of header fields. In the near term, footers and specially
structured 'syntax description' messages are the way to go. In the long
term, MIME parts could make a lot of sense.

Headers are limiting, but they are simple, efficient, and can provide a
point of entry for more detailed information (such as pointing to a
comprehensive web-interface or retrieving a comprehensive syntax
description document).


>> Besides, when have developers ever limited themselves to what the standards
>> say? There's nothing stopping people from implementing List- Digest, Post,
>> Admin, Archive, Software, Address or any of the other headers discussed on
>> the listspec page <http://arpp.carleton.ca/listspec/>.
...
>Of course they can be implemented, but to be really useful they require
>support from both the list management software and the mail clients.
>This is much less likely to happen for non-standard headers.

Agreed. Frankly, though, I think we should be moving on from the basic
header approach - which will hopefully reduce the problems with list access
in the near term - to explore more comprehensive solutions.

There are three things we can be working on:

1) Comprehensive meta-syntax for describing list commands
2) Transport mechanisms for the meta-syntax (footers, MIME parts,...)
3) Common list command syntax (religious wars ahead...)

For the third, I think we should wait to see what comes out of the Memphis
IETF BOF session. (other than Keith and Christopher, is anyone else going?)

- --
gneufeld@ccs.carleton.ca  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


----------------------------------------------------------------------

Date: 28 Mar 1997 13:54:55 -0500
From: "John Buckman" <(suppressed)@shelby.com>
Subject: Small suggestion for the standards document

As I was reading through the list header standards document, I saw 
that there are a several levels of implementation that could be done:

* just the "primary headers"
* the secondary headers
* the list attributes
* the list settings
* other sub-categories, such as Help, Unsub, but not Sub...

At the bottom of the docuement, I noticed that Grant's trying to
describe what portion of the list-header specification is being
implmented by each program.  

Thus, it would be helpful if there were "official terminology" to
specify how much of the standard has been implemented. For example,
the description for Lyris might say:

> Lyris list server implements the primary list headers and
> list-attributes header (on by default), and the secondary list
> headers are optional (off by default) on a per-list basis.  

One thing I thought was interesting was the "list attributes" header.
I wonder if this spec could be reused for the "review" command (or
"info listname") so that there exists a standard way to identify list
attributes.  Specifically, I'm hoping to provide information to
list-directory sites like www.liszt.com and tile.net that would be
helpful in aggregating list information.

John

John Buckman <(suppressed)@shelby.com>
Shelby Group Ltd., http://www.shelby.com/
Developers of Lyris Email List Server


----------------------------------------------------------------------

Date: 29 Mar 1997 01:09:58 -0500
From: "Roger Fajman" <(suppressed)@CU.NIH.GOV>
Subject: Re:  Why List-S ubscribe instead of...?

> Frankly, I expect to see some suprising uses of this header. Imagine if
> announcements of lists went out with this header attached? You read about a
> list, then all you have to do to join is click "subscribe" in your mail
> client (or select it from a menu, or whatever).

How would this be better than simply including a URL for subscribing
in the body of an email message?  Most UAs these days are adding the
capability to click on a URL in a message.  It seems to me that most
ordinary users would have difficulty getting the List-subscribe
header into the headers of a message they send.

> The subscribe command is used more than unsubscribe. I think it's safe to
> say that it's used more than the help command, too. As such, we would be
> remiss if we left it out.

The subscribe command is only used more than unsubscribe to the
extent that the total number of list subscriptions in the world
is increasing and list owners have to unsubscribe people who
forgot how to do it themselves (which is what List-unsubscribe
is inteneded to help deal with).

> Even though it may not seem at first glance to have as much function as
> part of mailing list messages, the List-Subscribe header field has a lot of
> value. To invite someone else to join the list, you can just bounce a list
> message to them. To rejoin a list you unsubscribed (vacation or whatever),
> just turn to an archived message from the list. ... and so on.

"Bounce" is a function that many UAs don't have.  The DRUMS WG
is including text in RFC 822bis that discourages that form of
forwarding by users.  And it would only be a useful thing to do if
you know that the other person has a UA that supports List-subscribe.

> >> There's also the work on a more comprehensive meta-syntax for list
> >> commands, and other transport mechanisms (footers, MIME parts,
specialized
> >> messages/files, etc.)
> >
> >If we wait for that to happen, we will all be gone.  It was bloody the
> >last time someone tried to do that.  Many people are very set in their
> >opinions, many of which contradict other people's opinions.
>
> You're speaking about the efforts to get list servers to standardize on a
> common _syntax_. I'm talking about defining a _meta-syntax_ which can be
> used to describe any of the syntaxes already in use by list servers.
>
> A meta-syntax could be utilized by any of the existing list servers without
> having to modify or add to the command syntaxes already in use.

Are you refering to the discussion about parameters in mailto URLs,
or something else?  I see the value of the parameters for extending
the List-* headers, but I agree with postponing that.

> I think this is why it's been comparativly painless to get people to accept
> the List- header proposal - it avoids most of the religious issues
> (different syntaxes, body vs. subject, etc.).

True.

> >> With the Internet-Draft what we're trying to do is get this method of
> >> command description approved so that it then becomes a matter of
enhancing
> >> an existing standard. If we were to include all the things we want it's
> >> chances of approval would be greatly lessened. From what I've read and
been
> >> told over the years, the standardization process is heavily ladden with
> >> politicking and may require 'devious maneuvering' to actually get things
> >> done.
> >
> >Nobody's going to be fooled by limiting the initial proposal to three
> >headers.  Anyone who's opposed because of the number of headers will
> >easily see how the initial proposal would be extended.
>
> _could_ be extended.

You can't have it both ways, saying people will extend things beyond
the standard headers as well as saying that people shouldn't think
it will happen.

> Personally, I favor focusing on other transport mechanisms rather than
> further expansion of header fields. In the near term, footers and specially
> structured 'syntax description' messages are the way to go. In the long
> term, MIME parts could make a lot of sense.
>
> Headers are limiting, but they are simple, efficient, and can provide a
> point of entry for more detailed information (such as pointing to a
> comprehensive web-interface or retrieving a comprehensive syntax
> description document).
>
(snip)
>
> There are three things we can be working on:
>
> 1) Comprehensive meta-syntax for describing list commands
> 2) Transport mechanisms for the meta-syntax (footers, MIME parts,...)

Footers don't go well with MIME messages.

> 3) Common list command syntax (religious wars ahead...)

Yes, that's why it's probably a waste of time.

> For the third, I think we should wait to see what comes out of the Memphis
> IETF BOF session. (other than Keith and Christopher, is anyone else going?)

I will be there unless the BOF conflicts with some other session
important to me.


----------------------------------------------------------------------

Date: 29 Mar 1997 08:35:25 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Re: Small suggestion for the standards document

At 10:51 AM +0007 on 3/28/97, John Buckman wrote:
>
> One thing I thought was interesting was the "list attributes" header.
> I wonder if this spec could be reused for the "review" command (or
> "info listname") so that there exists a standard way to identify list
> attributes.  Specifically, I'm hoping to provide information to
> list-directory sites like www.liszt.com and tile.net that would be
> helpful in aggregating list information.
>
> John
>

Great idea! I find liszt extremely useful - one of the best sites on the
list (the only reason tile is less useful is its limitation to listerv!)

Anything that can help these resources and others like them would be great
for the net :-)

Kent

Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work).


----------------------------------------------------------------------

End of Digest