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: List-ID review
     by "Claus_AndrŽ_FŠrber" <(suppressed)@faerber.muc.de>
-> Re: List-ID review
     by Jacob Palme <(suppressed)@dsv.su.se>
-> Re: List-ID review
     by Rob Chandhok <(suppressed)@within.com>
-> Fwd: I-D ACTION:draft-baer-listspec-02.txt
     by Grant Neufeld <(suppressed)@nisto.com>


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

Date: 1 Mar 1998 00:00:21 -0700
From: "Claus_AndrŽ_FŠrber" <(suppressed)@faerber.muc.de>
Subject: Re: List-ID review

Jacob Palme <(suppressed)@dsv.su.se> schrieb:
> So, for that usage, what you want is a unique ID for a *set of messages*,
> not fo a *subscription service*. One conclusion of this is that sublists
> in nested lists should normally not have any List-ID.
>
> What should a mailing list server do if it gets a message which already
> has a List-ID? Of the server handles a sublist, it should not change
> or add any List-ID, since the set of messages is defined by the top
> mailing list in the nested structure.

Right, the list ID would identify the list. The sublist is just an  
implementation detail of that list, so it does not have an own List-ID.

The sublist processor would have to be configured not to add its own
List-ID. It even should not process the message itsself but send it to  
its parent list if the message does not have a List-ID header and/or did  
not come from the parent list.

> If, however, a user gets a
> message from list A and manually resends it to list B, then in that
> case the handler of list B should perhaps replace the List-ID?

Yes. In this case the message is sent by another user to another list.  
The message sent to the list should not have the original List-ID  
header, but *completly new* headers (or be encapsulated in a message/ 
rfc822 body part).

- --
Claus "3247" Andre Faerber <http://www.muc.de/~cfaerber/> fax: +49-8061-3361
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C9 DC


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

Date: 2 Mar 1998 07:37:05 -0700
From: Jacob Palme <(suppressed)@dsv.su.se>
Subject: Re: List-ID review

At 20.42 +0100 98-02-28, Claus AndrŽ FŠrber wrote:
> Yes. In this case the message is sent by another user to another list.
> The message sent to the list should not have the original List-ID
> header, but *completly new* headers (or be encapsulated in a message/
> rfc822 body part).

It might be difficult to enforce this rule, since many mail clients
have commands for resending messages without change, or possibly with
addition of Resent-headers only.

It is probably easier to say that a mailing list which receives a
message which already has List-headers should replace those with
its own, if the message was forwarded to the list by some person.

But the list-header spec should also specify what you say, that people
are recommended not to resend messages with list-headers with intact
headers, or only adding Resent-headers. It is much better, if you
want to forward a message with list-headers, to encapsulate it in
a new message.

- ------------------------------------------------------------------------
Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme


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

Date: 2 Mar 1998 07:40:52 -0700
From: Rob Chandhok <(suppressed)@within.com>
Subject: Re: List-ID review

At 2:59 AM +0100 2/28/98, Jacob Palme wrote:
>So, for that usage, what you want is a unique ID for a *set of messages*,
>not fo a *subscription service*. One conclusion of this is that sublists
>in nested lists should normally not have any List-ID.

It really depends on how you want to think about it.  If you run a local
exploder for a list, it's really up to you and your local subscribers how
you describe the list.

>What should a mailing list server do if it gets a message which already
>has a List-ID? Of the server handles a sublist, it should not change
>or add any List-ID, since the set of messages is defined by the top
>mailing list in the nested structure. If, however, a user gets a
>message from list A and manually resends it to list B, then in that
>case the handler of list B should perhaps replace the List-ID?

List-ID should not be present in the headers of messages generated by
normal MUAs.  They should only be in messages from the list server itself.

In other words, list server software will FORCE the correct List-ID when
the message is exploded/reflected/sent to the list members.

Rob


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

Date: 2 Mar 1998 12:45:22 -0700
From: Grant Neufeld <(suppressed)@nisto.com>
Subject: Fwd: I-D ACTION:draft-baer-listspec-02.txt

Revision 02 of the List- header draft is now with the IETF.

It should be available from the official servers shortly. In the mean time,
you can get it from:
http://www.nisto.com/listspec/ietf/draft-baer-listspec-02.txt

This will hopefully go to last call, and then RFC, fairly quickly.

- --- begin forwarded text

To: IETF-Announce@ns.ietf.org
From: (suppressed)@ns.ietf.org
Subject: I-D ACTION:draft-baer-listspec-02.txt
Date: Mon, 02 Mar 1998 12:19:26 -0500

A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.


Note: This revision reflects comments received during the last call period.

	Title		: The Use of URLs as Meta-Syntax for
                          Core Mail List Commands and their Transport
                          through Message Header Fields
	Author(s)	: J. Baer, G. Neufeld
	Filename	: draft-baer-listspec-02.txt
	Pages		: 13
	Date		: 27-Feb-98

   The mailing list command specification header fields are a set of
   structured fields to be added to email messages sent by email
   distribution lists. Each field typically contains a URL (usually
   mailto [mailto]) 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.

   There are three 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-Owner and List-Archive.

   By including these header fields, list servers can make it possible
   for mail clients to provide automated tools for users to perform list
   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.

   The key words ''MUST'', ''MUST NOT'', ''REQUIRED'', ''SHALL'', ''SHALL
NOT'',
   ''SHOULD'', ''SHOULD NOT'', ''RECOMMENDED'',  ''MAY'', and ''OPTIONAL'' in
   this document are to be interpreted as described in RFC 2119.


Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-baer-listspec-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-baer-listspec-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za

	Europe: ftp.nordu.net
		ftp.nis.garr.it

	Pacific Rim: munnari.oz.au

	US East Coast: ds.internic.net

	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-baer-listspec-02.txt".

NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

- --- end forwarded text

- --
http://www.nisto.com/  O-  <*>


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

End of Digest