List-Header Digest Archive: July 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:

-> What's Happening?
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> Re: What's Happening?
     by Grant Neufeld <(suppressed)@achilles.net>
-> Modifications to list-header draft
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: Modifications to list-header draft 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> Re: Modifications to list-header draft
     by Christopher Allen <(suppressed)@consensus.com>
-> Re: Modifications to list-header draft
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: Modifications to list-header draft
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> Re: Modifications to list-header draft 
     by Keith Moore <(suppressed)@cs.utk.edu>
-> More Modifications to list-header draft
     by Grant Neufeld <(suppressed)@achilles.net>
-> Updated list-header docs
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: Modifications to list-header draft
     by Rob Chandhok <(suppressed)@within.com>
-> Re: Modifications to list-header draft
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: Modifications to list-header draft
     by Rob Chandhok <(suppressed)@within.com>
-> Re: Modifications to list-header draft
     by "Joshua D. Baer" <(suppressed)@skyweyr.com>
-> Re: Modifications to list-header draft
     by Rob Chandhok <(suppressed)@within.com>
-> last chance to revise list-header draft version 01
     by Grant Neufeld <(suppressed)@achilles.net>


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

Date: 2 Jul 1997 11:31:19 -0400
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: What's Happening?

I just got the monthly help file, and noticed that I hadn't received anything
from the list since last month's file.

What's happening with our project? What can we now put some effort towards?

Have we reviewed where we are in getting support in mail software?
Do we have more to do to convince software vendors to support our headers?

Is the RFC final? Is there an RFC number we can quote? What enhancements do we
need?

Just trying to jumpstart things!

Kent Larsen

Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work).
Pass the SPAM ban! Ask your Congressperson to support CAUCE
http://www.cauce.org


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

Date: 3 Jul 1997 15:06:39 -0400
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: What's Happening?

At 12:05 PM -0400 7/2/1997, Kent S. Larsen II wrote:
>What's happening with our project?

Not much. I got pulled away by other projects again. Hopefully, we can get
the -01 rev of the draft finished up soon so it can be put on the RFC track
finally.

>What can we now put some effort towards?

review http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-01.txt and
make comments on what still needs to be modified in it.

>Have we reviewed where we are in getting support in mail software?

All the ones I'm aware of are at:
http://arpp.carleton.ca/listspec/#APPLICATION-SUPPORT

>Do we have more to do to convince software vendors to support our headers?

Yep. Best tact at this point would be to get the draft onto the RFC track.

>Is the RFC final?

Nope. It's just the draft, still.

>Just trying to jumpstart things!

Thanks - we need that.

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


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

Date: 16 Jul 1997 12:49:59 -0400
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Modifications to list-header draft

I've made a number of revisions to the draft draft (viewable at
http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-01.txt ). I'd
like the reactions here before submitting this revision to the ietf process.


I've expanded the abstract by adding the following paragraph:

   There are four other header fields described here which, although
   not as widely applicable, will have utility for a sufficient number
   of mailing lists to justify their formalization here. These are
   List-Post, List-Digest, List-Admin and List-Archive.

I'm not entirely happy with the description I've used, so perhaps someone
else can suggest something more appropriate.


Should we add the 'choice of protocols' through comma-separation of URLs to
the draft? E.g., List-Help: <mailto:help@foo.bar>, <http://foo.bar/help>

Should we add the 'stacking of commands' through multiple URLs?
E.g., List-Digest: <mailto:list@foo?body=unsub> <mailto:digest@foo?body=sub>
which would perform the two commands as part of one action. Client
interface design can become awkward when implementing this, especially if
there are more than just a couple commands for the selected action.


Section 3 (The List Header Fields) has been heavily modified and added to:

  ---------------  Begin Excerpt  ---------------

3. The List Header Fields

   This document presents header fields which will provide the
   command syntax description for the 'core' and secondary 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.

3.1. List-Help

   The List-Help field is the most important of the header fields
   described in this document. It would be 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, the
   URL specified would request the help file for the list or a web page
   with list instructions. Of all three 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>

3.2. List-Unsubscribe

   The List-Unsubscribe field describes the command (preferably
   using mail) to directly unsubscribe the user (removing them from the
   list).

   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 List-Subscribe field describes the command (preferably
   using mail) to directly subscribe the user (request addition to the
   list).

   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?cmd=sub&lst=list>
    List-Subscribe: <mailto:list-on@host.com>

3.4. List-Digest

   The List-Digest field describes the command (preferably using mail)
   to switch, or subscribe, to a digest mode for the list. This field is
   obviously only applicable to lists which have digest versions
   available.

   Examples:

    List-Digest: <mailto:list@host.com?subject=subscribe%20digest>
    List-Digest: <mailto:list-request@host.com?subject=set%20digest>
    List-Digest:
        <mailto:list-manager@host.com?body=set%20digest%20list>
    List-Digest: <http://www.host.com/list.cgi?cmd=digest&lst=list>
    List-Digest: <mailto:list-digest-on@host.com>

3.5. List-Post

   The List-Post field describes the method for posting to the list.
   This is typically the address of the list, but may be a moderator, or
   potentially some other form of submission.

   Examples:

    List-Post: <mailto:list@host.com>
    List-Post: <mailto:moderator@host.com>
    List-Post: <mailto:moderator@host.com?subject=list%20posting>

3.6. List-Admin

   The List-Admin field identifies the path to contact a human
   administrator for the list.

   Examples:

    List-Post: <mailto:listmom@host.com>
    List-Post: <mailto:grant@foo.bar>
    List-Post: <mailto:josh@foo.bar?Subject=list>

3.7. List-Archive

   The List-Archive field describes the method for accessing archives
   for the list.
   Examples:

    List-Archive: <mailto:archive@host.com?subject=index%20list>
    List-Archive: <ftp://ftp.host.com/pub/list/archive/>
    List-Archive: <http://www.host.com/list/archive/>

  ---------------  End Excerpt  ---------------


The label "List-Admin" has the potential to be misleading (some might think
it's the address to send commands to, since it's an 'administrative'
address). One alternative is List-Owner. Opinions?


- --
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>
  "Ambition is a poor excuse for not having sense enough to be lazy."
   -- Charlie McCarthy


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

Date: 16 Jul 1997 19:13:34 -0400
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: Modifications to list-header draft 

>   There are four other header fields described here which, although
>   not as widely applicable, will have utility for a sufficient number
>   of mailing lists to justify their formalization here. These are
>   List-Post, List-Digest, List-Admin and List-Archive.

I'd get rid of List-Digest.  Digest is just one per-recipient
attribute of a list; if you add digest, you may as well add
other attributes.  That's what List-Help is for.  And if you
do List-Digest you should at least have a way to turn it off.
Finally, different lists do digest in different ways, and it's
hard to model them all with a single function.

Let's draw the line at the functions that nearly all lists
share: simple subscribe,unsubscribe,help,post,owner,archive.
For more complicated things, refer to -Help or a web page.
(list-archive presumably points to the web page.)

> Should we add the 'choice of protocols' through comma-separation of URLs to
> the draft? E.g., List-Help: <mailto:help@foo.bar>, <http://foo.bar/help>

Yes, this seems fairly straightforward.  But you need a well-defined
indication of preference: e.g. the sender puts the preferred protocol
on the left and the recipient's UA picks the leftmost one that
it can support.

If you do this, you can encourage everyone to support mailto: URLs
for List-Help etc., without preventing use of http: or other protocols.

> Should we add the 'stacking of commands' through multiple URLs?
> E.g., List-Digest: <mailto:list@foo?body=unsub> <mailto:digest@foo?body=sub>

No.  This is just too complicated. and unlike the basic proposal,
it's really not supported by existing UAs.  It won't be clear
to a user that he/she has to click ALL of the URLs in a header.


> The label "List-Admin" has the potential to be misleading (some might think
> it's the address to send commands to, since it's an 'administrative'
> address). One alternative is List-Owner. Opinions?

List-Owner seems better than List-Admin.  I still prefer List-Human.

Keith


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

Date: 17 Jul 1997 00:16:48 -0400
From: Christopher Allen <(suppressed)@consensus.com>
Subject: Re: Modifications to list-header draft

At 4:08 PM -0700 7/16/97, Keith Moore wrote:>> The label "List-Admin" has
the potential to be misleading (some might think
>> it's the address to send commands to, since it's an 'administrative'
>> address). One alternative is List-Owner. Opinions?
>
>List-Owner seems better than List-Admin.  I still prefer List-Human.

I concur, List-Owner is better.

- ------------------------------------------------------------------------
.. 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: 17 Jul 1997 00:19:14 -0400
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: Modifications to list-header draft

At 7:08 PM -0400 7/16/1997, Keith Moore wrote:
>I'd get rid of List-Digest.

You make a pretty good argument. I'm not 100% in agreement, but unless I
hear a good argument to the contrary, I think we should leave the digest
issue out of this draft.

>> Should we add the 'choice of protocols' through comma-separation of URLs to
>> the draft? E.g., List-Help: <mailto:help@foo.bar>, <http://foo.bar/help>
>
>Yes, this seems fairly straightforward.  But you need a well-defined
>indication of preference: e.g. the sender puts the preferred protocol
>on the left and the recipient's UA picks the leftmost one that
>it can support.

Definitly. So, I guess I should add this in.

>> Should we add the 'stacking of commands' through multiple URLs?
>> E.g., List-Digest: <mailto:list@foo?body=unsub>
<mailto:digest@foo?body=sub>
>
>No.  This is just too complicated. and unlike the basic proposal,
>it's really not supported by existing UAs.  It won't be clear
>to a user that he/she has to click ALL of the URLs in a header.

Point taken. The complication it adds is not worth risking at this point.
Best to leave that to a more comprehensive syntax (as may be covered by the
previously discussed mime-part, or whatever).

>List-Owner seems better than List-Admin.  I still prefer List-Human.

So do I. It very clearly states that a (supposidly) real person is to be
attached to the field and leaves little room for ambiguity.

- --
Tool-wielding ape online
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 17 Jul 1997 11:47:52 -0400
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Re: Modifications to list-header draft

At 7:08 PM -0400 on 7/16/97, Keith Moore wrote:
> 
> I'd get rid of List-Digest.  Digest is just one per-recipient
> attribute of a list; if you add digest, you may as well add
> other attributes.  That's what List-Help is for.  And if you
> do List-Digest you should at least have a way to turn it off.
> Finally, different lists do digest in different ways, and it's
> hard to model them all with a single function.

I agree also. This is particularly complicated with some systems (like
majordomo) where the Digest is actually a separate list, rather than an
attribute.

[snip]

> > Should we add the 'stacking of commands' through multiple URLs?
> > E.g., List-Digest: <mailto:list@foo?body=unsub>
<mailto:digest@foo?body=sub>
> 
> No.  This is just too complicated. and unlike the basic proposal,
> it's really not supported by existing UAs.  It won't be clear
> to a user that he/she has to click ALL of the URLs in a header.

I agree here also. But we do need to addres this eventually. Systems that
require multiple separate actions need some representation. However, this is
too complicated for now.

> 
> 
> > The label "List-Admin" has the potential to be misleading (some might
think
> > it's the address to send commands to, since it's an 'administrative'
> > address). One alternative is List-Owner. Opinions?
> 
> List-Owner seems better than List-Admin.  I still prefer List-Human.
> 
> Keith

List-Owner is clearly better than List-Admin. I think it implies human enough.
The problem with List-Human is it doesn't give you an idea of what role the
Human plays. Is this Human the Moderator? The system Administrator?

List-Owner may imply a number of things, but it is more specific than
List-Human.

Kent


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

Date: 19 Jul 1997 18:08:26 -0400
From: Keith Moore <(suppressed)@cs.utk.edu>
Subject: Re: Modifications to list-header draft 

> > > Should we add the 'stacking of commands' through multiple URLs?
> > > E.g., List-Digest: <mailto:list@foo?body=unsub>
<mailto:digest@foo?body=sub>
> > 
> > No.  This is just too complicated. and unlike the basic proposal,
> > it's really not supported by existing UAs.  It won't be clear
> > to a user that he/she has to click ALL of the URLs in a header.
> 
> I agree here also. But we do need to addres this eventually. Systems that 
> require multiple separate actions need some representation. However, this is

> too complicated for now.

I suspect that such things will be handled by either a standardized
list server command-set, or a HTML form and a cgi script.

> List-Owner is clearly better than List-Admin. I think it implies human 
> enough. The problem with List-Human is it doesn't give you an idea of what
> role the Human plays. Is this Human the Moderator? The system Administrator?
> 
> List-Owner may imply a number of things, but it is more specific than 
> List-Human.

Either one would be fine with me, as long as the RFC clearly states
that List-Owner is a human being.  (I'm not sure it matters whether
the human is the moderator or list administrator, because we expect
that humans will be flexible enough to intelligently route queries.

And the address of the mail system administrator is already known:
take the domain name from the list posting address, and prepend
"postmaster@" to it.  There's no need to specify List-Owner if
it's the same person as the mail system administrator.

Keith


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

Date: 20 Jul 1997 12:52:06 -0400
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: More Modifications to list-header draft

Added a new paragraph after the first paragraph in section 2 "The Command
Syntax":

   A list of multiple, alternate, URLs may be specified by a comma-
   separated list of angle-bracket enclosed URLs. The URLs have
   precedence from left to right. The client application will use the
   leftmost protocol that it supports, or knows how to access by a
   separate application. By this mechanism, protocols like http may be
   specified while still providing the basic mailto support for those
   clients who do not have access to non-mail protocols. It is
   recommended that a mailto URL be provided wherever possible.


Modified List-Admin to:

3.5. List-Owner

   The List-Owner field identifies the path to contact a human
   administrator for the list. The address may be that of a moderator,
   mail system administrator, or any other person who can handle user
   contact for the list. There is no need to specify List-Owner if
   it is the same person as the mail system administrator (postmaster).

   Examples:

    List-Owner: <mailto:listmom@host.com>
    List-Owner: <mailto:grant@foo.bar>
    List-Owner: <mailto:josh@foo.bar?Subject=list>


Removed List-Digest.

- --
"Eat people, not animals"
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 20 Jul 1997 14:00:46 -0400
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Updated list-header docs

I've updated the following documents (all changes noted with the green
[July20] marker):

"Header Fields"
http://arpp.carleton.ca/listspec/header-fields.html

"Guidelines to the List Specification Header Fields for Client Application
Author"
http://arpp.carleton.ca/listspec/client-author.html

"Introduction for List Managers"
http://arpp.carleton.ca/listspec/list-manager-intro.html

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


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

Date: 22 Jul 1997 10:21:42 -0400
From: Rob Chandhok <(suppressed)@within.com>
Subject: Re: Modifications to list-header draft

I like the changes that Grant just made - however, I have a request if you
are making changes.  How about adding the "List-Address" field as something
to identify the mailing list as uniquely as possible?

The reason (again) being that you might want some generic list handling
software to be able to automatically build a filter for list messages.  I
don't think the "To:" field is used consistently enough.  The "From:" field
is out.

One thought would be to use the List-Subscribe header, but that would cause
filters to have to be re-adjusted if that ever changes.

One might argue that if the list moves, it's not the same list anymore.
But you could change the ID then, in that case.

The sticky point would seem to be: who administers the namespace of list
names?  This isn't a new problem.  But is this why no such header exists
already?

I don't think using the actual posting address is the correct solution.

Examples:

For the list <(suppressed)@within.com>:

List-Id: commonspace.within.com (The CommonSpace Mailing List)
List-Id: commonspace-X03759900

Heck, you could even trademark your list name to prevent conflicts.  You
probably want to do that anyway if you have a list whose name is valuable.

List-ID: CommonSpace-List(tm)

Rob


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

Date: 22 Jul 1997 10:56:34 -0400
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: Modifications to list-header draft

At 10:16 AM -0400 7/22/1997, Rob Chandhok wrote:
>I like the changes that Grant just made - however, I have a request if you
>are making changes.  How about adding the "List-Address" field as something
>to identify the mailing list as uniquely as possible?

List-Address has bee pretty controversial here. I do favor eventually
coming up with some sort of List-ID.

>This isn't a new problem.  But is this why no such header exists
>already?

I agree that we need a permanent unique identifier for lists, independent
of their addresses or command systems.

I feel, though, that finding a solution for that is outside the scope of
the current proposal, and that the various proposed methods for it are
sufficiently 'debatable' at this time to warrant leaving it out.

However, it does warrant its own proposal and I certainly welcome
discussion and suggestions on it.

- --
"Don't blaim me - I'm a parasite."
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 22 Jul 1997 11:46:24 -0400
From: Rob Chandhok <(suppressed)@within.com>
Subject: Re: Modifications to list-header draft

At 10:55 AM -0400 7/22/97, Grant Neufeld wrote:
>I feel, though, that finding a solution for that is outside the scope of
>the current proposal, and that the various proposed methods for it are
>sufficiently 'debatable' at this time to warrant leaving it out.

That's too bad.  While I understand that the namespace of the ID might be
an issue, the List-ID header itself could be left to be free form for now.

Just out of curiosity, how would you suggest building filters
automatically?  What would you use in lieu of a a real list identifier?

Rob


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

Date: 22 Jul 1997 12:43:56 -0400
From: "Joshua D. Baer" <(suppressed)@skyweyr.com>
Subject: Re: Modifications to list-header draft

At 10:16 AM -0400 7/22/97, Rob Chandhok wrote:


> I like the changes that Grant just made - however, I have a request if you
> are making changes.  How about adding the "List-Address" field as something
> to identify the mailing list as uniquely as possible?

> I don't think using the actual posting address is the correct solution.

Why? Isn't it a unique identifier, as you describe above?

At 11:41 AM -0400 7/22/97, Rob Chandhok wrote:

> At 10:55 AM -0400 7/22/97, Grant Neufeld wrote:
> >I feel, though, that finding a solution for that is outside the scope of
> >the current proposal, and that the various proposed methods for it are
> >sufficiently 'debatable' at this time to warrant leaving it out.
>
> That's too bad.  While I understand that the namespace of the ID might be
> an issue, the List-ID header itself could be left to be free form for now.

Everything we add to the proposal reduces its chance of acceptance (both
officially and practically). Simple things are easy to pass and easy to
implement. I think we should take small steps here and keep the proposal as
it currently stands. This may just be one more header, but it has big
implications.

> Just out of curiosity, how would you suggest building filters
> automatically?  What would you use in lieu of a a real list identifier?

For lists which modify the reply-to header, I just use that. It will always
be the list address on reflected mail (and will not be present on admin
mail from the list).

For lists which don't, I look to the Sender or some other field.

~Josh


- -- ----------------------------------
Joshua D. Baer
<mailto:josh@skylist.net>

SkyList Mailing List Hosting Service
<http://www.skylist.net/>


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

Date: 22 Jul 1997 14:13:07 -0400
From: Rob Chandhok <(suppressed)@within.com>
Subject: Re: Modifications to list-header draft

I wrote:
>> I don't think using the actual posting address is the correct solution.

At 12:39 PM -0400 7/22/97, Joshua D. Baer wrote:
>Why? Isn't it a unique identifier, as you describe above?

No, because if the list moves to another host, then the posting address
changes.    As I mentioned before, this may be acceptable since one could
argue that it's a different list now.

Rob


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

Date: 25 Jul 1997 09:56:45 -0400
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: last chance to revise list-header draft version 01

Unless further changes are suggested before Monday, I'm going to submit
http://arpp.carleton.ca/listspec/ietf/draft-baer-listspec-01.txt on Monday,
and then ask for the last call procedure to begin.

So, speak up now.

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


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

End of Digest