List-Header Digest Archive: January 1997 http://www.nisto.com/list-spec/mail/ X-List-Help: , X-List-Unsubscribe: X-List-Subscribe: X-List-Archive: X-List-Post: X-List-Owner: Contents: -> Fwd: I-D ACTION:draft-hoffman-mailto-url-04.txt by Grant Neufeld <(suppressed)@achilles.net> -> Re: Fwd: I-D ACTION:draft-hoffman-mailto-url-04.txt by Paul Hoffman / IMC <(suppressed)@imc.org> -> [admin-listheader] Server name change by Grant Neufeld <(suppressed)@achilles.net> -> List-* lifetimes by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-* lifetimes by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: List-* lifetimes by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: List-* lifetimes by Rob Chandhok <(suppressed)@within.com> -> Re: List-* lifetimes by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-* lifetimes by James Berriman <(suppressed)@frutiger.staffs.ac.uk> -> Re: List-* lifetimes by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: List-* lifetimes by Chuq Von Rospach <(suppressed)@plaidworks.com> -> Re: List-* lifetimes by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: List-* lifetimes by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-* lifetimes by Jacob Palme <(suppressed)@dsv.su.se> -> Re: multiple email addresses by Grant Neufeld <(suppressed)@nisto.com> -> Re: draft-costales-*ubscribe-00.txt by Grant Neufeld <(suppressed)@nisto.com> -> ABNF for the List- headers by Grant Neufeld <(suppressed)@nisto.com> -> Re: multiple email addresses by Marc Horowitz <(suppressed)@cygnus.com> -> Re: List-* lifetimes by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: draft-costales-*ubscribe-00.txt by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: draft-costales-*ubscribe-00.txt by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-* lifetimes by Chuq Von Rospach <(suppressed)@plaidworks.com> -> Re: Suggested changes to draft-baer-listspec-01.txt by Grant Neufeld <(suppressed)@nisto.com> -> New list-header draft needs review before submission by Grant Neufeld <(suppressed)@nisto.com> -> Re: Suggested changes to draft-baer-listspec-01.txt by Jacob Palme <(suppressed)@dsv.su.se> -> Re: ABNF for the List- headers by Jacob Palme <(suppressed)@dsv.su.se> -> Re: multiple email addresses by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-* lifetimes by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-* lifetimes by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-* lifetimes by Rob Chandhok <(suppressed)@within.com> -> Re: List-* lifetimes by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-* lifetimes by Rob Chandhok <(suppressed)@within.com> -> Re: List-* lifetimes by James Berriman <(suppressed)@frutiger.staffs.ac.uk> -> Re: List-* lifetimes by Chuq Von Rospach <(suppressed)@plaidworks.com> -> Re: List-* lifetimes by Chuq Von Rospach <(suppressed)@plaidworks.com> -> Re: List-* lifetimes by Chuq Von Rospach <(suppressed)@plaidworks.com> -> Re: List-* lifetimes by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-* lifetimes by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Humans - admin and moderators (was: Suggested changes to draft-baer-listspec-01.txt) by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-* lifetimes by Chuq Von Rospach <(suppressed)@plaidworks.com> -> Re: List-* lifetimes by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: List-* lifetimes by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: List-* lifetimes by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: List-* lifetimes by James Berriman <(suppressed)@frutiger.staffs.ac.uk> -> Re: List-* lifetimes by Rob Chandhok <(suppressed)@within.com> -> List confirmations, List-IDs and List Info MIME parts by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-* lifetimes by Grant Neufeld <(suppressed)@nisto.com> -> List footers (was: List-* lifetimes) by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-* lifetimes by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-* lifetimes by Grant Neufeld <(suppressed)@nisto.com> -> Updating List Info (was: List-* lifetimes) by Grant Neufeld <(suppressed)@nisto.com> -> Setting From for List-Un*ubscribe (was: multiple email addresses) by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-* lifetimes by Grant Neufeld <(suppressed)@nisto.com> -> MUA internal command databases (was: List-* lifetimes) by Grant Neufeld <(suppressed)@nisto.com> -> List-ID (was: List-* lifetimes) by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-ID (was: List-* lifetimes) by Rob Chandhok <(suppressed)@within.com> -> Some suggested changes to draft-aber-listspec-02.txt by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List confirmations, List-IDs and List Info MIME parts by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List confirmations, List-IDs and List Info MIME parts by James Berriman <(suppressed)@frutiger.staffs.ac.uk> -> Re: List confirmations, List-IDs and List Info MIME parts by Grant Neufeld <(suppressed)@nisto.com> -> Re: Some suggested changes to draft-aber-listspec-02.txt by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-ID by Grant Neufeld <(suppressed)@nisto.com> -> Re: Some suggested changes to draft-aber-listspec-02.txt by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List confirmations, List-IDs and List Info MIME parts by Jacob Palme <(suppressed)@dsv.su.se> -> List-ID URNs (was: List confirmations, List-IDs and List Info MIME parts) by Grant Neufeld <(suppressed)@nisto.com> -> Command Precedence (was: Some suggested changes to draft-aber-listspec-02.txt) by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-ID URNs by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID URNs by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID URNs by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID URNs by Jacob Palme <(suppressed)@dsv.su.se> -> RDF and command syntax. by James Berriman <(suppressed)@frutiger.staffs.ac.uk> -> Re: Updating List Info (was: List-* lifetimes) by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: Updating List Info (was: List-* lifetimes) by Jacob Palme <(suppressed)@dsv.su.se> -> Re: MUA internal command databases (was: List-* lifetimes) by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List confirmations, List-IDs and List Info MIME parts by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-ID URNs (was: List confirmations, List-IDs and List Info MIME parts) by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: MUA internal command databases (was: List-* lifetimes) by Gerald Oskoboiny <(suppressed)@impressive.net> -> Re: MUA internal command databases (was: List-* lifetimes) by James Berriman <(suppressed)@frutiger.staffs.ac.uk> -> Re: MUA internal command databases (was: List-* lifetimes) by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: MUA internal command databases (was: List-* lifetimes) by Rob Chandhok <(suppressed)@within.com> -> List Command Syntax (was: RDF and command syntax.) by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-ID URNs (was: List confirmations, List-IDs and List Info MIME parts) by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: List-ID URNs (was: List confirmations, List-IDs and List Info MIME parts) by Rob Chandhok <(suppressed)@within.com> -> Re: List Command Syntax (was: RDF and command syntax.) by Rob Chandhok <(suppressed)@within.com> -> Fwd: I-D ACTION:draft-palme-mailext-headers-00.txt by Grant Neufeld <(suppressed)@nisto.com> -> Re: List Command Syntax (was: RDF and command syntax.) by Jacob Palme <(suppressed)@dsv.su.se> -> Fwd: RFC 2276 on Uniform Resource Name Resolution by Grant Neufeld <(suppressed)@nisto.com> -> List confirmation message formats by Grant Neufeld <(suppressed)@nisto.com> -> List-IDs by Grant Neufeld <(suppressed)@nisto.com> -> Re: Fwd: I-D ACTION:draft-palme-mailext-headers-00.txt by Jacob Palme <(suppressed)@dsv.su.se> -> List-ID is crucial (Was: Re: List-IDs) by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID is crucial by Grant Neufeld <(suppressed)@nisto.com> -> List-ID: relation to other groupware domains by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID is crucial (Was: Re: List-IDs) by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID is crucial by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID: relation to other groupware domains by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID is crucial by Jacob Palme <(suppressed)@dsv.su.se> -> List-ID return type (was: List-ID is crucial) by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-IDs by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-ID is crucial by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID is crucial by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-IDs by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID is crucial by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-ID: relation to other groupware domains by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID is crucial by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID is crucial by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID is crucial by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-ID is crucial by "Geoffrey C. Wenger" <(suppressed)@fyi.net> -> Re: List-ID is crucial by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-ID is crucial by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID is crucial by Jacob Palme <(suppressed)@dsv.su.se> ---------------------------------------------------------------------- Date: 5 Jan 1998 13:54:58 -0700 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Fwd: I-D ACTION:draft-hoffman-mailto-url-04.txt Of particular interest to the participants here: - --- begin forwarded text To: IETF-Announce@ns.ietf.org From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The mailto URL scheme Author(s) : L. Masinter, P. Hoffman, J. Zawinski Filename : draft-hoffman-mailto-url-04.txt Pages : 5 Date : 02-Jan-98 This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, ''Uniform Resource Locators'', and RFC 1808, ''Relative Uniform Resource Locators''. The syntax of ''mailto'' URLs from RFC 1738 is extended to allow creation of more RFC 822 messages by allowing the URL to express additional header and body fields. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hoffman-mailto-url-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-hoffman-mailto-url-04.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-hoffman-mailto-url-04.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 ---------------------------------------------------------------------- Date: 5 Jan 1998 17:59:50 -0700 From: Paul Hoffman / IMC <(suppressed)@imc.org> Subject: Re: Fwd: I-D ACTION:draft-hoffman-mailto-url-04.txt This should be the last version of the draft (the previous one should have been too, but one co-author took it on himself to revise the draft without asking the other two...). It's now up to the IESG to move it forwards. - --Paul Hoffman, Director - --Internet Mail Consortium ---------------------------------------------------------------------- Date: 7 Jan 1998 18:10:07 -0700 From: Grant Neufeld <(suppressed)@achilles.net> Subject: [admin-listheader] Server name change I am moving this mailing list to a new server name. nisto.com is my new domain (replacing arpp.carleton.ca) and list.nisto.com is my host for mailing lists. So, please address future list mail to: list-header@list.nisto.com The commands address is: list-header-request@list.nisto.com The website shold be changing tomorrow (January8) to http://www.nisto.com/listspec/ (The old arpp.carleton.ca address should continue to work for both the website and the mailing lists for the next while) If you have any problems with, or questions about, the mailing lists hosted by nisto.com, please contact listmom@nisto.com Thanks. ---------------------------------------------------------------------- Date: 10 Jan 1998 14:43:52 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: List-* lifetimes A programmer adds an ``Unsubscribe'' feature to his MUA. What exactly should that feature do? Here's the List-Unsubscribe answer: If the currently displayed message contains a List-Unsubscribe field with a mailto URL, send mail to that address. But that's clearly wrong. If the user is reviewing old messages, and the unsubscription instructions have changed in the meantime, then he should follow the new instructions, not the old ones. To do a good job, the MUA has to keep track of the user's mailing lists, along with the unsubscription instructions for each list. The obvious implementation is for the MUA to save the subscription confirmation message for each list, and to consult that message for instructions. New instructions mean a new confirmation message. Similar comments apply to List-Archive. The MUA should look for it in confirmation messages, not in postings. Is there some reason that List-* fields have been placed into postings? (Previous discussions here indicate that users of existing MUAs are supposed to be able to click on the List-Unsubscribe URL. That's a nice thought, but most MUAs hide unrecognized fields. A message footer is much more effective in practice.) - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 10 Jan 1998 17:03:53 -0700 From: Gerald Oskoboiny <(suppressed)@impressive.net> Subject: Re: List-* lifetimes On 10 Jan 1998, D. J. Bernstein wrote: > A programmer adds an ``Unsubscribe'' feature to his MUA. What exactly > should that feature do? > > Here's the List-Unsubscribe answer: > > If the currently displayed message contains a List-Unsubscribe field > with a mailto URL, send mail to that address. > > But that's clearly wrong. If the user is reviewing old messages, and the > unsubscription instructions have changed in the meantime, then he should > follow the new instructions, not the old ones. The MUA should keep track of which instructions are most recent. > To do a good job, the MUA has to keep track of the user's mailing lists, > along with the unsubscription instructions for each list. The obvious > implementation is for the MUA to save the subscription confirmation > message for each list, and to consult that message for instructions. New > instructions mean a new confirmation message. I disagree: the confirmation message might not always be available. I might have used a completely different MUA on a completely different system to join a list, in which case my current MUA won't have the information it needs. > Similar comments apply to List-Archive. The MUA should look for it in > confirmation messages, not in postings. > > Is there some reason that List-* fields have been placed into postings? At the least, it's a way to make sure the current info is always available to the MUA being used. Gerald - -- Gerald Oskoboiny <(suppressed)@impressive.net> http://impressive.net/people/gerald/ ---------------------------------------------------------------------- Date: 10 Jan 1998 23:03:07 -0700 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: List-* lifetimes OK, I'll bite and try to post to the new List-Post address. :) At 09:42 PM 1/10/98 -0000, D. J. Bernstein wrote: >A programmer adds an ``Unsubscribe'' feature to his MUA. What exactly >should that feature do? > >Here's the List-Unsubscribe answer: > > If the currently displayed message contains a List-Unsubscribe field > with a mailto URL, send mail to that address. > >But that's clearly wrong. If the user is reviewing old messages, and the >unsubscription instructions have changed in the meantime, then he should >follow the new instructions, not the old ones. If the user is reviewing old mail from Uncle Fred, and Uncle Fred's address has changed in the meantime, should the MUA use Uncle Fred's new address when a reply is made to the old mail? >To do a good job, the MUA has to keep track of the user's mailing lists, >along with the unsubscription instructions for each list. The obvious >implementation is for the MUA to save the subscription confirmation >message for each list, and to consult that message for instructions. New >instructions mean a new confirmation message. How, in fact, would an MUA recognize *this* list as the "same" one as was sent from arpp.carleton.ca last month? It would need to, even if there were an intervening confirmation, in case you review the old posts. In my opinion, such issues are "quality of implementation" issues but don't belong in RFC's. Personally, I don't want to use an MUA that attempts to be too clever about such things. Microsoft is now putting out MUAs that generate "Reply-To: <@domain.com>" without the users being aware that this occurs or is a problem; the thought of how they might botch threading of incoming mail to get the "most recent" address boggles the mind. Cheers, Stan ---------------------------------------------------------------------- Date: 11 Jan 1998 18:29:07 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-* lifetimes At 9:42 PM +0000 1/10/98, D. J. Bernstein wrote: >Similar comments apply to List-Archive. The MUA should look for it in >confirmation messages, not in postings. This is interesting. How does the MUA detect a "confirmation message"? That isn't part of any standard I know of. It seems to me that given the currently proposed standard, the user has to play some role in deciding when to update information stored about a particular mailing list. If there were clearly marked "confirmation messages", or special list-management mime parts, that would be a different story. ---------------------------------------------------------------------- Date: 11 Jan 1998 19:50:17 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-* lifetimes Gerald Oskoboiny writes: > The MUA should keep track of which instructions are most recent. Right. To do this, it needs something to identify the list that a message is from---for example, a List-ID field. It's then a tremendous waste of time (not to mention archive space) to also have instructions in every message. > I disagree: the confirmation message might not always be available. I > might have used a completely different MUA on a completely different > system to join a list, If you threw away your old mail when you switched MUAs, obviously List-* won't help you. - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 11 Jan 1998 20:03:31 -0700 From: James Berriman <(suppressed)@frutiger.staffs.ac.uk> Subject: Re: List-* lifetimes At 01:21 12/01/98, Rob Chandhok wrote: >At 9:42 PM +0000 1/10/98, D. J. Bernstein wrote: >>Similar comments apply to List-Archive. The MUA should look for it in >>confirmation messages, not in postings. > >This is interesting. How does the MUA detect a "confirmation message"? >That isn't part of any standard I know of. > The headers may appear in both list postings and confirmation messages. It really shouldn't be beyond the user or MUA to work out which is the most recent (and therefore most probably correct) message to extract the list-header information from. I believe one of the driving forces behind Grant's original idea (correct me if I'm wrong, Grant!) was the fact that people are all too good at losing confirmation messages. That's why the headers appear in every list post. This becomes particularly important if you don't always check your mail in the same way from the same MUA or machine, and therefore don't have any access to a confirmation message (as someone already pointed out). ( :-]) James ---------------------------------------------------------------------- Date: 11 Jan 1998 21:32:07 -0700 From: Gerald Oskoboiny <(suppressed)@impressive.net> Subject: Re: List-* lifetimes On 12 Jan 1998, D. J. Bernstein wrote: > Gerald Oskoboiny writes: > > The MUA should keep track of which instructions are most recent. > > Right. To do this, it needs something to identify the list that a > message is from---for example, a List-ID field. It's then a tremendous > waste of time (not to mention archive space) to also have instructions > in every message. Disk space is really really cheap. Archive tools can be taught to ignore these headers if they don't find them interesting. I don't understand why it's a waste of time to have instructions in every message -- doing so ensures that the subscribers always have the information when they need it. It's just a few more bytes. And someone implementing these headers could probably choose to just include a minimal set, like List-Unsubscribe and a URL with more info about the list or whatever. > > I disagree: the confirmation message might not always be available. I > > might have used a completely different MUA on a completely different > > system to join a list, > > If you threw away your old mail when you switched MUAs, obviously List-* > won't help you. I never throw away old mail. But I don't lug around hundreds of megs of archived mail everywhere I go, either. Gerald - -- Gerald Oskoboiny <(suppressed)@impressive.net> http://impressive.net/people/gerald/ ---------------------------------------------------------------------- Date: 11 Jan 1998 23:29:57 -0700 From: Chuq Von Rospach <(suppressed)@plaidworks.com> Subject: Re: List-* lifetimes At 8:29 PM -0800 1/11/98, Gerald Oskoboiny wrote: > I don't understand why it's a waste of time to have instructions in > every message -- doing so ensures that the subscribers always have > the information when they need it. It's just a few more bytes. It's not. I've moved my lists to a footer with the info on every message (or iwth digests, as part of the header) -- and the number of user braincramps has gone pretty darn close to zero. The number of cries for help from lost/confused users has gone way down. Error rates are way down. And much to my amazement, I got almost zero gripe from the users on it. Very little. Since I've done away with the twice-a-month "help" file postings as a result, even the ones who complained seem to think this is a nice alternative. The ones who have a clue can always use an edit filter to remove them if it offends their senses... So taking it another step and embedding it in a way that the MUA can make it available but not cluttering up messages seems like a great next step. As long as users know to ask the MUA for it... > I never throw away old mail. You're rare. You should assume that list users don't save anything, and have about a 90 minute memory -- because it's true often enough that you need to design for it. If the information isn't where the user can access it when they want it, they'll thrash around, and you can't expect them to squirrel it away, because the ones who need it most won't. - -- Chuq Von Rospach (chuq@apple.com) Apple IS&T Mail List Gnome Plaidworks Consulting (chuqui@plaidworks.com) ( +-+ The home for Hockey on the net) ---------------------------------------------------------------------- Date: 12 Jan 1998 00:27:37 -0700 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: List-* lifetimes > > I disagree: the confirmation message might not always be available. I > > might have used a completely different MUA on a completely different > > system to join a list, > > If you threw away your old mail when you switched MUAs, obviously List-* > won't help you. > > ---Dan Some people use more than one MUA, say one at the office, one at home, and one on a laptop. They may or may not be the same software product. So, having up to date list subscription always available to the MUA would require use of ACAP (or something like it). ---------------------------------------------------------------------- Date: 12 Jan 1998 13:12:42 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-* lifetimes At 21.42 +0000 98-01-10, D. J. Bernstein wrote: > To do a good job, the MUA has to keep track of the user's mailing lists, > along with the unsubscription instructions for each list. The obvious > implementation is for the MUA to save the subscription confirmation > message for each list, and to consult that message for instructions. New > instructions mean a new confirmation message. I strongly agree. A good MUA should know which mailing lists a user is subscribed to, and which commands to use to subscribe, unsubscribe, get to the archives, etc. Knowing which mailing list a user is subscribed to allows lots of nice user functions: - - Get me a list of all the lists I am subscribed to - - Automatically filter each list to a separate folder without forcing the user to set up filters, which many users find difficult to do - - Automatically access archives if a user wants to find messages written before s/he joined the list, or which have been purged from the user mailbox - - Automatically construct correct "Mail-Followup-To" headers, to get group replies to me only via the list, not as personal mail (if this is what the user wants) Together with directory systems, a good MUA could also provide a user with lists of mailing lists which the user is not subscribed to, but might want to join. This of course requires that the MUA knows which lists you are subscribed to, so that you are not offered subscription to a list you are already subscribed to! Of course, if the same user uses two different MUAs, this service cannot be provided well unless they can communicate this information between them, using standardised or proprietary protocols. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 12 Jan 1998 13:13:14 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-* lifetimes At 20.21 -0500 98-01-11, Rob Chandhok wrote: > At 9:42 PM +0000 1/10/98, D. J. Bernstein wrote: > >Similar comments apply to List-Archive. The MUA should look for it in > >confirmation messages, not in postings. > > This is interesting. How does the MUA detect a "confirmation message"? > That isn't part of any standard I know of. > > It seems to me that given the currently proposed standard, the user has to > play some role in deciding when to update information stored about a > particular mailing list. If there were clearly marked "confirmation > messages", or special list-management mime parts, that would be a different > story. When the list-header group is ready with its list-header standard, perhaps the group could start work on other standards issues related to mailing list, for example confirmation messages. They should probably be formatted similarly to delivery status notifications (RFC 1894). According to RFC 1894, a delivery status notification has three MIME body parts. The first part is a human-friendly message, the second a computer-readable message and the third part return of the message causing the notification. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 12 Jan 1998 15:57:19 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: multiple email addresses At 3:45 PM -0700 1997/11/2, John Buckman wrote: >Perhaps a more standard way of doing this would make sense. Here's one >possibility, using a "from=" field to make the unsubscribe command come >From: a different address: > > List-Unsubscribe: That would have to be taken as only a suggestion to the MUA. So, if the MUA recognizes the suggested From as an address belonging to the current user, then it would pick that as the address to use. Otherwise, it would prompt the user for the address to use (if the user has more than one - otherwise just use the user's single address). That said, I don't favor the idea of including the user's address in the fields. Most users have a single address and leave it at that. Those users who do manage multiple addresses tend to be slightly more clued about handling those addresses. Additionally, I prefer leaving the intelligence in this regard to the client software. I'm using Eudora Pro which keeps track of the 'personality' associated with individual messages, so if I reply to a new message from this list, Eudora automatically picks my grant@nisto.com address (which I can switch with a pop-up menu, if I want). - -- http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 12 Jan 1998 16:34:16 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: draft-costales-*ubscribe-00.txt I'm going through my backlog of unanswered messages - primarily things that involved too much thinking on my part for me to quickly respond to at the time. I don't think we ever fully answered Bryan Costales' concern about being able to use RFC 822 format addresses in the List- header fields. Perhaps we could accommodate this through something along the lines of how the address format is determined in Delivery Status Notifications [RFC1894]. For the List- header fields, the default between <> is an URL. specifies that stuff is an URL. We could add to this where address is an rfc822 format address. Does this help at all? Am I just messing things up here? To recap the previous discussion for those who have forgotten: At 1:40 PM -0700 1997/9/5, Bryan Costales wrote: > +------------ > + From: Grant Neufeld <(suppressed)@achilles.net> > + Subject: Re: draft-costales-subscribe-00.txt > + Date: Wed, Sep 3, 11:52 1997 > +------------ > + At 9:27 AM -0400 1997/9/3, Bryan Costales wrote: > + >The differences between our drafts are fundamental enough to require a > + >counter proposal (and besides, they both appear to have been submitted > + >within days of eachother). You propose several much needed new headers > + >that will make list management easier. Where you and I disagree is > + >in whether such headers must be strictly mailto: URLs. > + ... > + >I only worry about the current headlong rush into stuffing > + >URLs into e-mail headers without giving thought to backwards > + >compatability or to future alternatives to URLs that may be > + >invented. > + > + We have given thought to that, which is why we have made the >requirement of > + URLs being enclosed in <> and that clients currently ignore anything else > + in the field. This allows for future additions (which could include the > + email address, comments, some future command syntax, or whatever) without > + breaking any clients who follow the specification. > >Yes, but these are legal addresses: > > To: <(suppressed)@bcx.com> > To: Bryan Costales <(suppressed)@bcx.com> > >If the only indicator of a URL is angle braces then how do we differentiate >a legal RFC822 address from a URL? Since an unquoted colon is >not legal in the RHS of addresses, but is legal in DECnet addresses, >how do you propose parsing: > > To: <"ftp:mgr"@ftp.site.domain> >or > To: > >Here, "mailto" is the machine name. This is why I would either prefer >a prefix like: > > URL-Subscribe: > >Or some other unambiguous indication that a header's body is a URL, such >as prefixing the < with a URL:, like this: > > List-Subscribe: URL: > > + I don't at all object to the idea of expanding the content of the List- > + fields beyond just the use of URLs. I've tried to keep that possibility > + open all along, knowing that the more rigid a protocol is, the easier >it is > + to break. > + > + As to backward compatibility: Can you clarify what existing structures you > + see this proposal breaking, please? > + > + I suggest that you bring your concerns to the list-header@arpp.carleton.ca > + list so the others involved in this discussion can consider your > + suggestions and concerns. (please consider replying to this message on the > + list - you can quote me there - so these issues will be more public.) > + > + > + >In my proposal > + >the string " + >URL, otherwise the header body is presumed to be a pure RFC822 > + >address. > + > + But, that doesn't address alternate URL syntaxes or future command > + syntaxes. How do you intend to accommodate those? > + > + > + >In recent days I have become concerned about the confusion > + >that will be caused by mixing the two forms or by requiring only one > + >form. What happens when: > + > > + > archive@host.com?subject=index%20list > + > > + >shows up at a user's desktop who's MUA doesn't understand URLs or > + >mailto: extensions? > + > + But that line is invalid. It's not in correct URL format > + () or a correct rfc address. > + If someone has configured their mailer to send out that line, they have > + broken their mailer and will get broken results. > + > + If you have just a plain rfc address for the List- commands, how can you > + specify the various commands that need to be put into the message? > + > + List-Subscribe: list-request@host.com > + > + isn't complete since it doesn't include the command text that goes >into the > + subscribe message to list-request@host.com. This is a big reason why we > + elected to focus on URLs. Following that, another big reason is that most > + people on the net can now recognize an URL as an URL. They may not be able > + to understand the content of the URL, but they know what it is. > + > + > + >Might that user cut and past that literal > + >text into a recipient window? > + > + Sure some users will screw it up - but they're already screwing things up > + by sending "unscribe" messages to the list address, amongst other things. > + The point of this protocol is to reduce the number of errors and generally > + make things easier. There's no way we can completely eliminate the >problems > + for all users as long as there are humans involved. > + > + -- > + grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> > + PGP 5: 4077 8306 9115 94B0 CEA6 F4F4 3B9A 9482 D158 7B9A > + > + > > >-- > | Bryan Costales Technical Writer/Unix Consultant | > | Summer: 505 S. Cedar, Laramie, WY 82072 Location: 105.60W. 41.31N. | > | Winter: 1215 Eliza St, Key West FL 33040 Location: 81.67W. 24.51N. | > | E-mail: bcx@bcx.com URL: | ---------------------------------------------------------------------- Date: 12 Jan 1998 16:51:50 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: ABNF for the List- headers Anybody want to validate / finish-up the ABNF that Chris Newman proposed for the List- headers (otherwise I'll leave it out): At 10:05 AM -0700 1997/9/3, Chris Newman wrote: >Here's a first cut based on the document text, using notation from 822: > >url-list = url-item *("," url-item) > >url-item = url-angle / extension-token > >url-angle = "<" encoded-url ">" > >encoded-url = requirement that the characters "(" and ")" must be encoded > and free insertion of LWSP-chars and folding is permitted > at any point> > >extension-token = phrase > ;; if extension-token is unknown, the rest of the header > ;; field is ignored. - -- "Don't blame me - I'm a parasite." http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 12 Jan 1998 16:55:13 -0700 From: Marc Horowitz <(suppressed)@cygnus.com> Subject: Re: multiple email addresses Grant Neufeld <(suppressed)@nisto.com> writes: >> >Perhaps a more standard way of doing this would make sense. Here's one >> >possibility, using a "from=" field to make the unsubscribe command come >> >From: a different address: >> > >> > List-Unsubscribe: >> >> That would have to be taken as only a suggestion to the MUA. So, if the MUA >> recognizes the suggested From as an address belonging to the current user, >> then it would pick that as the address to use. Otherwise, it would prompt >> the user for the address to use (if the user has more than one - otherwise >> just use the user's single address). Well, the MLM can stick the user's address into the subject or body. I'm not so sure standardization here is in scope for this document, since different MLM's will already be doing this different ways. >> That said, I don't favor the idea of including the user's address in the >> fields. >> >> Most users have a single address and leave it at that. Those users who do >> manage multiple addresses tend to be slightly more clued about handling >> those addresses. I think for the reasons discussed earlier (different MUA's, different hosts, different state, differently-clued users), putting addresses in the fields is a good idea. It makes it more likely that the automated unsubscribe will work, and this is a good thing. >> Additionally, I prefer leaving the intelligence in this regard to the >> client software. I'm using Eudora Pro which keeps track of the >> 'personality' associated with individual messages, so if I reply to a new >> message from this list, Eudora automatically picks my grant@nisto.com >> address (which I can switch with a pop-up menu, if I want). Nothing in the draft prohibits MUA's from being intelligent (I hope!). Marc ---------------------------------------------------------------------- Date: 12 Jan 1998 17:18:28 -0700 From: Gerald Oskoboiny <(suppressed)@impressive.net> Subject: Re: List-* lifetimes On Mon, 12 Jan 1998, Jacob Palme wrote: > At 21.42 +0000 98-01-10, D. J. Bernstein wrote: > > To do a good job, the MUA has to keep track of the user's mailing lists, > > along with the unsubscription instructions for each list. The obvious > > implementation is for the MUA to save the subscription confirmation > > message for each list, and to consult that message for instructions. New > > instructions mean a new confirmation message. > > I strongly agree. A good MUA should know which mailing lists a user is > subscribed to, and which commands to use to subscribe, unsubscribe, > get to the archives, etc. Knowing which mailing list a user is subscribed > to allows lots of nice user functions: : > Of course, if the same user uses two different MUAs, this service > cannot be provided well unless they can communicate this information > between them, using standardised or proprietary protocols. I agree that these are all nice functions and that a decent MUA should be able to provide these functions using the metadata defined by the list-header spec. But I disagree that this information should come from the confirmation message received at the time the user originally subscribed to the list: it is a fundamental error IMO to assume that this message will always be available to the current MUA. I might be on a single list for years and change MUAs five times within those years: I will have archived the original confirmation message on CD by the time I'm using MUA #5 on ISP #7. And I might use a number of different MUAs each week if I access or respond to my e-mail on a number of different systems (workstation with access to local mail file, laptop using IMAP, ...) The way it should work is: Each MUA is responsible for building a database of information for each individual list it has "seen" for that user. This information can be distributed with the original confirmation message that's sent when the user joins a list, but it should be superceded by any information received afterwards. (where "afterwards" could be defined using some kind of list identifier and timestamp, if necessary.) List maintainers would be encouraged to transmit at least a minimal set of these headers with each message sent to the list, to make sure the information is always available to the user no matter what MUA or system they happen to be using. (they should always be able to click an "Unsubscribe" button when viewing a message from a list, for instance, so List-Unsubscribe should be transmitted with each message sent to the list.) If some people are concerned about bandwidth used by these headers, they can choose to transmit a smaller set of them: maybe just List-Unsubscribe and List-Info, where the URL at List-Info: would provide other info like the list owner's address, archive location, how to subscribe, etc. Or List-Info: could point to an autoresponder that sends back a message with a more complete set of headers. Or the list could be configured to transmit a few extra headers once a week or something, and the MUA just updates its database whenever it sees new information for the list. But it would be a mistake to assume the current MUA always has access to the original confirmation message. I know I certainly can't tell you what MUA I'll be using 2 years from now, and my e-mail habits are relatively predictable. Gerald - -- Gerald Oskoboiny <(suppressed)@impressive.net> http://impressive.net/people/gerald/ ---------------------------------------------------------------------- Date: 12 Jan 1998 17:28:12 -0700 From: Gerald Oskoboiny <(suppressed)@impressive.net> Subject: Re: draft-costales-*ubscribe-00.txt On Mon, 12 Jan 1998, Grant Neufeld wrote: > I don't think we ever fully answered Bryan Costales' concern about being > able to use RFC 822 format addresses in the List- header fields. : > For the List- header fields, the default between <> is an URL. > > specifies that stuff is an URL. > > We could add to this where address is an rfc822 format > address. Does this help at all? Am I just messing things up here? Why not ? Gerald - -- Gerald Oskoboiny <(suppressed)@impressive.net> http://impressive.net/people/gerald/ ---------------------------------------------------------------------- Date: 12 Jan 1998 18:04:34 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: draft-costales-*ubscribe-00.txt At 5:25 PM -0700 1998/1/12, Gerald Oskoboiny wrote: >> We could add to this where address is an rfc822 format >> address. Does this help at all? Am I just messing things up here? > >Why not ? Bryan expressed concern about being able to use plain RFC822 format addresses. So, a legal RFC822 address like "some user"@some.server would end up in mailto as , whereas using the RFC822 specifier would allow . I don't particularly like this approach. I don't consider the old plain RFC822 format to have any overriding precedence over mailto for the List- header fields, certainly not enough to justify complicating the matter. URLs are the best choice for this protocol. There is wide deployment of software support for them, and they are flexible and extensible. They provide everything RFC822 addresses do (with the exception of the ability to enter an address without URL encoding it - which is not much of a price to pay considering how few addresses require any URL encoding). - -- http://www.nisto.com/ O- <*> "At first, I was opposed to the so-called satellite mind-control transmissions." ---------------------------------------------------------------------- Date: 12 Jan 1998 18:05:19 -0700 From: Chuq Von Rospach <(suppressed)@plaidworks.com> Subject: Re: List-* lifetimes At 4:15 PM -0800 1/12/98, Gerald Oskoboiny wrote: >I will have archived the >original confirmation message on CD by the time I'm using MUA #5 on >ISP #7. For that matter -- lists move. Servers get upgraded. Addresses change. They aren't static, either. I've got users on some lists that have been on non-stop over at least three sets of server technology over four or five different addresses. What they got when they signed up is meaningless -- if you don't know that what you're presenting them is correct *now*, then you're better off with the MUA shrugging its virtual shoulders than sending it something that'll be wrong and create even more problems. Because if the MUA tells them "this is what to do" and it doesn't work, the user is going to be at best upset (and lost). IMHO, if you want something like this, it ought to be a "here's where to send for the current info" setup, and send off a message to return the data, not something cached locally. God knows, I'm always tweaking my docs to improve them. Caching an old doc locally means the user has no access to it. Silly, when the user is only a Mailto: URL away from a fresh copy. So the trick is to know how to get to the mailbot, not to cache data away. Does the data need to be customized in some way on return? Let's standardize that and build the encoding in so that we can return "who" or "which" data or whatever for the user, but don't store stuff locally unless you know the data is current and accurate, and if you have no way of verifying that, don't store it. Store references and bring a copy over as needed. >If some people are concerned about bandwidth used by these headers, And the bandwidth issue is a non-issue. We're not living in a day of 1200 baud modems any more. Take any mail list you want. Do a comparison: how much bandwidth is 'wasted' by these headers, compared to how much is wasted by mistplaced admin messages. On most lists, the header size is noise compared to the noise. If half of that misplaced bandwidth can be killed by the headers, it's far beyond a break-even. And on most lists, if bandwidth is an issue, then those admins ought to be focusing on tighting up content issues, not worrying about 200 bytes or so worth of headers. Man, they just dropped a nuclear bomb on San Jose, and here I am in dirty underwear... Sometimes you focus on the wrong things and lose perspective. (hint: the dirty underwear is the least of your problems....) >Or the list could be configured to transmit a few extra headers >once a week or something, and the MUA just updates its database >whenever it sees new information for the list. Only works if you have one MUA. >But it would be a mistake to assume the current MUA always has >access to the original confirmation message. or that it should. I'd argue that it shouldn't. The *only* piece of information a confirmation message returns that should be cached indefinitely is the officially subscribed address. The rest can and will change over time, and rather than cache it, cache a reference to it. The subscribed address can (and in many cases will) change on the CLIENT side, causing endless hassles for both ends of the subscription. So we need to track it, so the user can use it for the unsubscribe or whatever later, regardless of MUA changes, job changes, re-orgs or whatever else changes a user's address -- and there should be some way of attempting to regenerate it if the information gets lost. But the rest of the confirmation message? It should be considered obsolete when received and not cached. The only reason list admins recommend caching it now is because it's better to have obsolete versions than no version, and I've had marginal at best success in trying the "bookmark this so you have it when you need it" approach. But loading that info into the mail header, if the MUA accepts it, gets around that for the most part. I can point them to the CURRENT list web docs, and the CURRENT doc mailbot, and that's what they want -- because the server side isn't cast in stone any more than the client side is. ---------------------------------------------------------------------- Date: 12 Jan 1998 18:28:05 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: Suggested changes to draft-baer-listspec-01.txt At 10:17 AM -0700 1997/12/24, Jacob Palme wrote: >3.5 List-Owner > >Comment: List-Owner must be split into List-Owner and List-Moderator, >because these can be different people. The point of List-Owner is to provide a human contact when the user is unable to make use of the other commands to achieve what they want. List-Moderator is an entirely separate function, and is more appropriate as the content of List-Post. That's because the moderator is who you send messages for consideration to be posted. The Owner is the one to whom you take administrivia questions and matters of dispute (they can be the same person, or not, but these are separate functions). - -- http://www.nisto.com/ O- <*> "Ambition is a poor excuse for not having sense enough to be lazy." -- Charlie McCarthy ---------------------------------------------------------------------- Date: 12 Jan 1998 19:25:42 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: New list-header draft needs review before submission I'm finished my draft revisions now, and would like some further feedback on some of the proposed changes. http://www.nisto.com/listspec/ietf/draft-baer-listspec-02.txt I've put change bars ("|") in for most sections that are new or changed. Please review it and let me know if you see any problems with it. Thanks. - -- http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 13 Jan 1998 09:46:44 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: Suggested changes to draft-baer-listspec-01.txt At 18.30 -0700 98-01-12, Grant Neufeld wrote: > At 10:17 AM -0700 1997/12/24, Jacob Palme wrote: > >3.5 List-Owner > > > >Comment: List-Owner must be split into List-Owner and List-Moderator, > >because these can be different people. > > The point of List-Owner is to provide a human contact when the user is > unable to make use of the other commands to achieve what they want. > > List-Moderator is an entirely separate function, and is more appropriate as > the content of List-Post. That's because the moderator is who you send > messages for consideration to be posted. The Owner is the one to whom you > take administrivia questions and matters of dispute (they can be the same > person, or not, but these are separate functions). Exactly! And that is why different addresses must be provided for these two functions. One can discuss whether to default one to the other if only one of them is specified. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 13 Jan 1998 09:47:26 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: ABNF for the List- headers At 16.45 -0700 98-01-12, Grant Neufeld wrote: > Anybody want to validate / finish-up the ABNF that Chris Newman proposed > for the List- headers. Where is linear-white-space allowed? Where is parenthesis-enclosed comments allowed? The new drums syntax has three new ABNF constructs WSP, FWS and CWSP to explicitly specify this in the syntax specifications. Example of use: - -------------- url-list = url-item *("," url-item) url-item = [CFWS] url-angle / extension-token url-angle = "<" encoded-url ">" encoded-url = extension-token = [CFWS] phrase ;; if extension-token is unknown, the rest of the ;; header field is ignored. Basic syntax definitions used: - ----------------------------- quoted-pair = ("\" text) text = %d1-9 / ; Characters excluding CR and LF %d11-12 / %d14-127 WSP = SP / HTAB ; Whitespace characters FWS = ([*WSP CRLF] 1*WSP) ; Folding white-space ctext = NO-WS-CTL / ; Non-white-space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-127 ; ")", or "\" comment = "(" *([FWS] (ctext / quoted-pair / comment)) [FWS] ")" CFWS = *([FWS] comment) (([FWS] comment) / FWS) Would it not be nice if the definitions of WSP, FWS and CFWS could be provided by one standard only, and then used by all other standards which need them? - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 13 Jan 1998 10:34:02 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: multiple email addresses [I'm a list-header subscriber. Please, folks, don't send me extra copies of followups. I realize that most MUAs don't do the right thing by default; see http://pobox.com/~djb/proto/replyto.html for a solution.] Grant Neufeld writes: [ on From lines in mailto ] > That would have to be taken as only a suggestion to the MUA. What you mean to say is ``even if this From line is required by the MLM, some MUAs are incapable of producing it.'' If the mailing list is run by ezmlm, you can send a message to listname-subscribe-God=heaven.af.mil@listhost to subscribe God@heaven.af.mil (after confirmation, of course). Users seem to have a low failure rate with this syntax, perhaps because they already understand that spelling is crucial in addresses. Anyway, this is another example of an instruction that's easy to give in confirmation messages and hard to give in postings. - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 13 Jan 1998 10:43:50 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-* lifetimes Gerald Oskoboiny writes: > I don't understand why it's a waste of time to have instructions in > every message Every time the MUA sees List-* fields it has to look up the current instructions for that list and make sure there aren't any changes. Scanning through a thousand new messages---not to mention downloading them in the first place, for people stuck behind modems---already takes a noticeable amount of time. What exactly are we getting in return for slowing this down even more? - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 13 Jan 1998 10:55:47 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-* lifetimes Chuq Von Rospach writes: > So taking it another step and embedding it in a way that the MUA can > make it available but not cluttering up messages seems like a great > next step. It seems like a great step backwards. Message footers are very effective at giving the information to users, exactly because of the ``clutter''---they are always visible. If you get rid of footers in favor of List-*, most of your users will no longer see the information and will not realize that it's accessible. The reason to put something in a header field is to make it readily accessible _to MUAs_. Does List-* do a good job of supporting any particular MUA functions? - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 13 Jan 1998 11:13:13 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-* lifetimes At 5:42 PM +0000 1/13/98, D. J. Bernstein wrote: >Every time the MUA sees List-* fields it has to look up the current >instructions for that list and make sure there aren't any changes. > >Scanning through a thousand new messages---not to mention downloading >them in the first place, for people stuck behind modems---already takes >a noticeable amount of time. What exactly are we getting in return for >slowing this down even more? You are right in assuming that the MUA might have to continually scan for new information on every message -- and that's pretty unacceptable. Download time isn't really the issue though, the impact on bytes transferred is pretty small given modern compression techniques. IMHO, the problem is that there isn't a good definition in the List-* standard about *when* to update cached information. Until then, the MUA had best leave that decision up to the end user. If you do that, you can implement an MUA that uses the information in a useful fashion without looking at every message. To be really useful (and more idiot proof), the List-* information should be embedded in a standard mime part, like "text/list-header-info" or something. You can use the exact same headers and syntax, but just provide wrap the info in some MIME structure. And don't even tell me that most MUAs can't handle MIME. That's not a reasonable argument anymore. Rob ---------------------------------------------------------------------- Date: 13 Jan 1998 11:17:20 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-* lifetimes Chuq Von Rospach writes: > For that matter -- lists move. Servers get upgraded. Addresses change. Mailing list owners send new confirmation messages to point out the changes. Otherwise users get rather annoyed, for obvious reasons. On this list there seems to be a confirmation message every month. > Do a comparison: how much bandwidth is 'wasted' by these headers, Roughly 10% on this list---and that's for only the basic instructions (help, owner, subscribe, unsubscribe, post, archive). Not the worst bloat in the universe, but what exactly are we getting for it? > compared to how much is wasted by mistplaced admin messages. Under 1%. (Of course, entire wasted messages are often more annoying than wasted space in every message.) > If half of that misplaced bandwidth can be killed by the headers, Nope. Most MUAs don't show unrecognized fields by default. > > But it would be a mistake to assume the current MUA always has > > access to the original confirmation message. > or that it should. I'd argue that it shouldn't. Confirmation messages are normally the sole source of quite a bit of information about the purpose and policy of the list. It's absurd to suggest that this information _shouldn't_ be available to users. - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 13 Jan 1998 11:35:43 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-* lifetimes At 6:15 PM +0000 1/13/98, D. J. Bernstein wrote: >> Do a comparison: how much bandwidth is 'wasted' by these headers, > >Roughly 10% on this list---and that's for only the basic instructions >(help, owner, subscribe, unsubscribe, post, archive). Not the worst >bloat in the universe, but what exactly are we getting for it? 10% ?!?!?!? That's pushing it. There are more bytes in "received" headers than list-* headers by the time I get most mail. And we'll get more from the List-* headers when they are around, available, and used by common MUAs. Never mind the fact that they're pretty useful as is. Give it some time. Rob ---------------------------------------------------------------------- Date: 13 Jan 1998 12:09:50 -0700 From: James Berriman <(suppressed)@frutiger.staffs.ac.uk> Subject: Re: List-* lifetimes At 17:42 13/1/98, D. J. Bernstein wrote: >Every time the MUA sees List-* fields it has to look up the current >instructions for that list and make sure there aren't any changes. That's just one way of implementing it. Another is to parse the list-header fields only when a user selects or opens a message which contains them. Personally, I wouldn't want my MUA to parse every list-header field for every message. ( :-]) James ---------------------------------------------------------------------- Date: 13 Jan 1998 12:28:40 -0700 From: Chuq Von Rospach <(suppressed)@plaidworks.com> Subject: Re: List-* lifetimes At 9:54 AM -0800 1/13/98, D. J. Bernstein wrote: >Message footers are very effective at giving the information to users, >exactly because of the ``clutter''---they are always visible. > >If you get rid of footers in favor of List-*, most of your users will >no longer see the information and will not realize that it's accessible. If it's part of the support of the MUA, I don't see this as a problem. But it's one reason why I *am* using footers now intead of list* headers (although now that the thing's pretty stable, I'll likely add them. Can't hurt). If it's integrated into the client system, the footer becomes clutter again. Until then, though, you're right. ---------------------------------------------------------------------- Date: 13 Jan 1998 12:29:05 -0700 From: Chuq Von Rospach <(suppressed)@plaidworks.com> Subject: Re: List-* lifetimes At 10:15 AM -0800 1/13/98, D. J. Bernstein wrote: >Mailing list owners send new confirmation messages to point out the >changes. Otherwise users get rather annoyed, for obvious reasons. And you'd be amazed at how many of them are ignored. I've just spent a serious chunk of time moving many, many lists to new, improved systems. New addresses, new server software, new everything. Sent out warnings a few days ahead the move was coming. Sent out warnings a day before. Sent out a note when it happened, and a note after it happened -- and then sent out new instructions and other documentation. And there were still a good number of folks who, weeks later, came back and started asking questions about why things suddenly seemed different. Go figure. >It's absurd to >suggest that this information _shouldn't_ be available to users. Where did I say that? I didn't. I said don't cache the old copies. Cache a reference and get a FRESH copy when the user wants it. VERY different. ---------------------------------------------------------------------- Date: 13 Jan 1998 12:29:16 -0700 From: Chuq Von Rospach <(suppressed)@plaidworks.com> Subject: Re: List-* lifetimes At 9:42 AM -0800 1/13/98, D. J. Bernstein wrote: >Scanning through a thousand new messages---not to mention downloading >them in the first place, for people stuck behind modems---already takes >a noticeable amount of time. What exactly are we getting in return for >slowing this down even more? A better user experience. For what is -- at worst -- a negligible increase in overhead. God, I feel like we're arguing about how to pull three machine cycles out of a 200 operand assembler routine. Why bother? The user won't notice the difference. ---------------------------------------------------------------------- Date: 13 Jan 1998 12:42:49 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-* lifetimes [Please don't send me extra copies of your messages, Chuq.] Chuq Von Rospach writes: > If it's part of the support of the MUA, This comes back to my question: what exactly is the MUA supposed to do? Several people seem to agree that the answer is ``Keep track of the latest List-* for each list, using something like List-ID to identify the list for each message.'' But then postings need only one field, namely List-ID. How exactly does the MUA benefit from having all the List-* fields in every message? - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 13 Jan 1998 13:05:57 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-* lifetimes Chuq Von Rospach writes: [ on the useful information contained in confirmation messages ] > Cache a reference and get a FRESH copy when the user wants it. List policy information should be readily available to the user every time he sends a message to the list. In the past year there were about 13000 postings and zero policy changes on one of my lists. Does it really make sense to insist that the policy be downloaded 13000 times? Every time a user wants to send a message, he has to wait---perhaps quite a while, if his network connection is congested---for the latest policy? ``Push'' seems much more sensible than ``pull'' here. Even if there are new confirmation messages fifty times a year for an absurdly unstable policy, that's only 0.4% of the mailing list traffic, and it means that subscribers have the latest information available locally. - ---Dan Put an end to fake mailing list subscriptions. http://pobox.com/~djb/ezmlm.html ---------------------------------------------------------------------- Date: 13 Jan 1998 13:54:13 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Humans - admin and moderators (was: Suggested changes to draft-baer-listspec-01.txt) At 9:42 AM -0700 1998/1/13, Jacob Palme wrote: >At 18.30 -0700 98-01-12, Grant Neufeld wrote: >> The point of List-Owner is to provide a human contact when the user is >> unable to make use of the other commands to achieve what they want. >> >> List-Moderator is an entirely separate function, and is more appropriate as >> the content of List-Post. That's because the moderator is who you send >> messages for consideration to be posted. The Owner is the one to whom you >> take administrivia questions and matters of dispute (they can be the same >> person, or not, but these are separate functions). > >Exactly! And that is why different addresses must be provided for these >two functions. As they are. The moderator address, if there is one, is in the list-post field. The human administrative contact is in the list-owner field. >One can discuss whether to default one to the other >if only one of them is specified. I don't think so. There should always be a human administrative contact, which defaults to postmaster@list.domain if the List-Owner field is not specified. There isn't necessarily always a moderator. If there is, it is specified by the List-Post field. Otherwise, List-Post is the general posting address, or the keyword "NO" if posting is not permitted. - -- http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 13 Jan 1998 13:59:44 -0700 From: Chuq Von Rospach <(suppressed)@plaidworks.com> Subject: Re: List-* lifetimes At 12:04 PM -0800 1/13/98, D. J. Bernstein wrote: >In the past year there were about 13000 postings and zero policy changes >on one of my lists. Lightweight. My going on one hundred lists do 13,000 postings in about six weeks. And if your policy isn't maturing over time, you're ingnoring your lists. Anyway, whatever. Not a fight I feel the need to get into, so have fun. I popped in to this list to see the status of the list header stuff. It's not nearly as ready for prime time as I expected, based on the list content. I'll be back when it gets hashed out for real. > Does it really make sense to insist that the policy >be downloaded 13000 times? Do you read what I said? Evidently not. But never mind. Not my fight. chuq ---------------------------------------------------------------------- Date: 14 Jan 1998 01:44:56 -0700 From: Gerald Oskoboiny <(suppressed)@impressive.net> Subject: Re: List-* lifetimes On 13 Jan 1998, D. J. Bernstein wrote: > Gerald Oskoboiny writes: > > I don't understand why it's a waste of time to have instructions in > > every message > > Every time the MUA sees List-* fields it has to look up the current > instructions for that list and make sure there aren't any changes. No, it just checks the list ID and timestamp. > Scanning through a thousand new messages---not to mention downloading > them in the first place, for people stuck behind modems---already takes > a noticeable amount of time. What exactly are we getting in return for > slowing this down even more? Users get a nicer interface to mailing lists -- an "unsubscribe" button on their MUA instead of having to send confusing commands to a list server. Administrators get less hassle and time wasted from dealing with users who are unable to deal directly with list servers. Gerald - -- Gerald Oskoboiny <(suppressed)@impressive.net> http://impressive.net/people/gerald/ ---------------------------------------------------------------------- Date: 14 Jan 1998 01:50:12 -0700 From: Gerald Oskoboiny <(suppressed)@impressive.net> Subject: Re: List-* lifetimes On 13 Jan 1998, D. J. Bernstein wrote: > Chuq Von Rospach writes: > > For that matter -- lists move. Servers get upgraded. Addresses change. > > Mailing list owners send new confirmation messages to point out the > changes. Otherwise users get rather annoyed, for obvious reasons. > > On this list there seems to be a confirmation message every month. Yes, but that might not help someone who reads their e-mail on many different machines or MUAs. Hence the need to put (at least some of) the info in every message. > > Do a comparison: how much bandwidth is 'wasted' by these headers, > > Roughly 10% on this list---and that's for only the basic instructions > (help, owner, subscribe, unsubscribe, post, archive). Not the worst > bloat in the universe, but what exactly are we getting for it? So don't put all those headers: just put list-unsubscribe, list-help, and list-id with timestamp or whatever. > > compared to how much is wasted by mistplaced admin messages. > > Under 1%. (Of course, entire wasted messages are often more annoying > than wasted space in every message.) Bandwidth and disk space is really cheap, and is rapidly getting cheaper. My time, on the other hand, is quite precious to me. I don't care about a few extra bits if it saves me from wasting time handling user problems which really ought to be handled by a machine. Gerald - -- Gerald Oskoboiny <(suppressed)@impressive.net> http://impressive.net/people/gerald/ ---------------------------------------------------------------------- Date: 14 Jan 1998 02:04:14 -0700 From: Gerald Oskoboiny <(suppressed)@impressive.net> Subject: Re: List-* lifetimes On Mon, 12 Jan 1998, Chuq Von Rospach wrote: > IMHO, if you want something like this, it ought to be a "here's where to > send for the current info" setup, and send off a message to return the > data, not something cached locally. God knows, I'm always tweaking my docs > to improve them. Caching an old doc locally means the user has no access to > it. Silly, when the user is only a Mailto: URL away from a fresh copy. So > the trick is to know how to get to the mailbot, not to cache data away. This makes sense to me, except I think preventing the user from having to go through the extra "request-list-info" / "act-on-list-info" step is worthwhile enough to send (at least) list-unsubscribe with each message, so that function is always available immediately. If they're reading their e-mail in offline mode on a laptop or something, and they get a bunch of messages from some list and want to unsub right away, they should just be able to hit the "Unsubscribe" button and not think about it again -- if they have to request the directions for how to unsub first, some of them will freak out and start sending "GET ME OFF THIS LIST NOW" messages to the entire list. If you're concerned about obsolete info being cached, that could be handled an expiry field somewhere, or by smart MUAs prompting the user if they haven't received up to date info recently enough ("You asked me to unsubscribe, but my instructions for unsubscribing are more than a month old; should I request fresh instructions from the list server?") Gerald - -- Gerald Oskoboiny <(suppressed)@impressive.net> http://impressive.net/people/gerald/ ---------------------------------------------------------------------- Date: 14 Jan 1998 04:32:12 -0700 From: James Berriman <(suppressed)@frutiger.staffs.ac.uk> Subject: Re: List-* lifetimes At 19:42 13/1/98, D. J. Bernstein wrote: >Several people seem to agree that the answer is ``Keep track of the >latest List-* for each list, using something like List-ID to identify >the list for each message.'' > >But then postings need only one field, namely List-ID. How exactly does >the MUA benefit from having all the List-* fields in every message? Some background here. I suggested a similar thing way back when this discussion got started. We discussed the idea of a single list-* header which would be a pointer to some form of standardised machine-readable MLM description document. Most people argued strongly at the time that they wanted the basic information embedded in the headers of every message. That way, the MUA can provide essential subscription management functions from the current message, as the user is reading it - without having to cache information or retrieve a separate document. That's the basis upon which the list-header spec has been developed. The idea of placing the command syntax in a separately retrievable document or a mime attachment was left for future consideration. If someone comes up with a standard format for encapsulating MLM command syntax in a machine-readable form, then of course list administrators would have the option of inserting a single list-info header which points to the relevant document. That, surely, is the ideal subject for a separate rfc. ( :-]) James ---------------------------------------------------------------------- Date: 14 Jan 1998 12:06:17 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-* lifetimes At 7:41 PM +0000 1/13/98, D. J. Bernstein wrote: >Several people seem to agree that the answer is ``Keep track of the >latest List-* for each list, using something like List-ID to identify >the list for each message.'' > >But then postings need only one field, namely List-ID. How exactly does >the MUA benefit from having all the List-* fields in every message? What is this mythical List-ID header? I'd love to see one, but I don't know of any standard or even common practice that uniquely identifies a list (even if it moves around). This has come up on the list before, and to my best recollection there isn't enough consensus on the namespace for List-ID to implement it. Rob ---------------------------------------------------------------------- Date: 14 Jan 1998 13:09:47 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: List confirmations, List-IDs and List Info MIME parts I'm now preparing three drafts for discussion here. In order of my priority: Mail Command Confirmations A consistant format for mail command confirmations, modeled on DSNs [rfc1894]. This will allow for MUAs to automate (or at least make friendlier) the process of confirming commands. Since the point of most confirmation requests is to confirm that the recipient address did intend for the command to be issued, MUAs can keep track of which commands they issue, and automatically respond to confirmation requests for those known commands. List-IDs A flexible method of uniquely identifying lists without necessarily tying the identifier to a given domain name. List Info MIME Part Similar to the DSN format. In particular, the "message/delivery-status" part. Intended to provide a means of describing the features of a List, and the associated command syntax. - -- "Hard work pays off in the future. Laziness pays off now" http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 14 Jan 1998 13:58:31 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: List-* lifetimes At 5:15 PM -0700 1998/1/12, Gerald Oskoboiny wrote: >If some people are concerned about bandwidth used by these headers, >they can choose to transmit a smaller set of them: maybe just >List-Unsubscribe and List-Info, where the URL at List-Info: would ... That's List-Help, not List-Info. Just to make sure we don't get things confused. - -- "Thanks for the nose-news, neighbor!" - Ned Flanders http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 14 Jan 1998 14:33:11 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: List footers (was: List-* lifetimes) At 12:14 PM -0700 1998/1/13, Chuq Von Rospach wrote: >At 9:54 AM -0800 1/13/98, D. J. Bernstein wrote: >>If you get rid of footers in favor of List-*, most of your users will >>no longer see the information and will not realize that it's accessible. > >If it's part of the support of the MUA, I don't see this as a problem. But >it's one reason why I *am* using footers now intead of list* headers There's nothing about using the List- headers that precludes using anything else. Combining the header fields with a good footer message will cover many bases, and should make using the list easier for users. - -- "Have you ever retired a human by mistake?" http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 14 Jan 1998 14:42:14 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: List-* lifetimes At 1:55 PM -0700 1998/1/13, Chuq Von Rospach wrote: >I >popped in to this list to see the status of the list header stuff. It's not >nearly as ready for prime time as I expected, based on the list content. >I'll be back when it gets hashed out for real. But it has been "hashed out for real". We've had consensus on the structure of most of the fields since around the middle of last year. The only reason it hasn't gone to Last Call for RFC is because we're waiting for the mailto draft to RFC. The debate you're seeing is over how MUAs should account for aging information, which in no way inhibits the progress and benefit of implementing the List- header fields now. - -- "Consciousness: that annoying time between naps." http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 14 Jan 1998 14:47:42 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: List-* lifetimes At 2:42 PM -0700 1998/1/10, D. J. Bernstein wrote: >A programmer adds an ``Unsubscribe'' feature to his MUA. What exactly >should that feature do? > >Here's the List-Unsubscribe answer: > > If the currently displayed message contains a List-Unsubscribe field > with a mailto URL, send mail to that address. > >But that's clearly wrong. If the user is reviewing old messages, and the No. It is not "clearly" wrong. For most messages, issuing a List- header field derived command should work just fine. For the case of a list that has changed its commands or address, an error will be returned (unless the server manager is nice and provides a link to the new list address/commands from the old). The error will either clue the user in that they need to find more recent command info, or it won't. For those who it won't, they probably wouldn't find the new info anyway. We can't help everyone - but we must not let that stop us from helping some people (and potentially a lot). MUAs that want to be clever, can keep an internal database of list commands. Then, every time a new message with the list- header fields comes in, they can update their database if the list info has changed. As to the question of the List- header info expiring, MUAs may want to compare the date of the message with the current date and provide a warning to the user if the message "seems old" (the definition of old being left up to the MUA - probably two months is reasonable). As an extension to that, a "List-Info_Expires: " header field could be added for lists that know they are going to move soon (I would definitely NOT want such a field to be used for lists that don't have impending changes - the Date field is enough info for normal use). At 7:48 PM -0700 1998/1/11, D. J. Bernstein wrote: >Gerald Oskoboiny writes: >> The MUA should keep track of which instructions are most recent. > >Right. To do this, it needs something to identify the list that a >message is from---for example, a List-ID field. It's then a tremendous >waste of time (not to mention archive space) to also have instructions >in every message. Remember, the biggest motivation for the list headers is providing a consistent way for people to access list commands given that most messages - - especially instructional messages - are deleted or lost very quickly. This solution makes provides access to the commands even if the user has only one message from the list in their mailbox. It is not a complete solution, but it will (and is already) help a lot of people. I've used the headers a number of times already in my personal use (I've switched primary email addresses twice in the past year or so). They don't save the universe, but they do make some things easier. >If you threw away your old mail when you switched MUAs, obviously List-* >won't help you. Wrong. The next message you receive from the list will let your new MUA know all about the list. One additional plus (with some security considerations) for the List- headers is that users who are spoofed onto 100s of lists could run a script to generate unsubscribes for all the messages in their inbox. The specifics are a little more complicated than that, but there is potential there. At 12:20 AM -0700 1998/1/12, Roger Fajman wrote: >Some people use more than one MUA, say one at the office, one at home, and >one on a laptop. They may or may not be the same software product. So, >having up to date list subscription always available to the MUA would >require use of ACAP (or something like it). Not necessarily. As long as the MUA they are using has recently received a copy of a message from the list (assuming the list uses List- headers), it should be up to date. - -- "When all else fails, read the instructions." http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 14 Jan 1998 14:54:15 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Updating List Info (was: List-* lifetimes) At 6:21 PM -0700 1998/1/11, Rob Chandhok wrote: >It seems to me that given the currently proposed standard, the user has to >play some role in deciding when to update information stored about a >particular mailing list. There is a Date field on every message. If the Date field is more recent than the last message from the list, and there is a difference in the List- header info (or List Info MIME part, or whatever), then the MUA may want to update its internal database of list commands/info (if it maintains one) - or prompt the user to make some decision about handling the change. - -- http://www.nisto.com/ O- <*> A phrase I saw used to describe a massive quantity: "more common than Internet Explorer security bugs" ---------------------------------------------------------------------- Date: 14 Jan 1998 14:54:38 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Setting From for List-Un*ubscribe (was: multiple email addresses) At 4:52 PM -0700 1998/1/12, Marc Horowitz wrote: >I think for the reasons discussed earlier (different MUA's, different >hosts, different state, differently-clued users), putting addresses in >the fields is a good idea. It makes it more likely that the automated >unsubscribe will work, and this is a good thing. I'm not fond of the idea of specifying the From address. It violates the mailto URL specification (based on the current draft, and all previous). However, the current draft doesn't prohibit including the user's address in the subject or body of the mailto command, so MTAs could implement that, if they felt it appropriate. >Nothing in the draft prohibits MUA's from being intelligent (I hope!). The point of the draft is to make it easier for MUAs to be intelligent. At 10:32 AM -0700 1998/1/13, D. J. Bernstein wrote: >Grant Neufeld writes: > [ on From lines in mailto ] >> That would have to be taken as only a suggestion to the MUA. > >What you mean to say is ``even if this From line is required by the MLM, >some MUAs are incapable of producing it.'' Only in part. The main consideration is that specifying From is not permitted in mailto. It is also potentially dangerous, or error prone, to include the from address in the subject or body of a mailto if that mailto may be forwarded to another user or account. >Anyway, this is another example of an instruction that's easy to give in >confirmation messages and hard to give in postings. I favor the addition of intelligence to the MUA rather than complicate the discovery of command syntax. Keep in mind that the List- headers are focused on the clueless who tend to be most prone to losing instructions, or messing them up. Most people managing multiple email accounts are among the clueful and can be generally expected to be able to cope with choosing which of their addresses to use until their client software gets intelligent enough to do it for them (which mine already does). - -- http://www.nisto.com/ O- <*> "The power of accurate observation is called cynicism by those who have not got it." -- G. B. Shaw ---------------------------------------------------------------------- Date: 14 Jan 1998 14:54:51 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: List-* lifetimes At 5:55 PM -0700 1998/1/12, Chuq Von Rospach wrote: >if >you don't know that what you're presenting them is correct *now*, then >you're better off with the MUA shrugging its virtual shoulders than sending >it something that'll be wrong and create even more problems. Because if the >MUA tells them "this is what to do" and it doesn't work, the user is going >to be at best upset (and lost). That's a MUA intelligence issue. I think I'll add a recommendation that MUAs warn the user if a message they are using to get a List- command from is "old" based on the date field. Or, if the MUA maintains a mail list command database, warn the user if the database has not received updated information for X amount of time (probably a month or two). There will always be out of date info floating around (dead web URLs are the biggest testament to that). However, I think the List- headers reduce rather than add to the problem because they provide a continual updating of information for users who are subscribed to lists. >IMHO, if you want something like this, it ought to be a "here's where to >send for the current info" setup, and send off a message to return the >data, not something cached locally. God knows, I'm always tweaking my docs >to improve them. Caching an old doc locally means the user has no access to >it. But each message from your lists should provide an update with the List- headers. Additionally, once we've got the List Info MIME part set to go, you'll be able to send out a new List Info part to update your users when you make changes. If you update your list info and don't push it to the users, they're going to have to explicitly request it if they want to be current. The List- headers (and eventually the MIME part) provide a consistant way for you to update your users - a way that can be made transparent to them by an intelligent MUA. Remeber, also, the many users who read and write their messages offline - so can't dynamically access info about the list that isn't available on their local system. >>Or the list could be configured to transmit a few extra headers >>once a week or something, and the MUA just updates its database >>whenever it sees new information for the list. > >Only works if you have one MUA. Or if each MUA gets a copy of at least one message from the list, if every message is sent with current List- info. >I can >point them to the CURRENT list web docs, and the CURRENT doc mailbot, and >that's what they want -- because the server side isn't cast in stone any >more than the client side is. Welcome to the List-Help header. Chuq, from what you've expressed, it seems to me that your best choice would be to implement the List-Help and List-Unsubscribe header fields, and leave the rest out. As a subscriber to a few of your lists, I'd like to see them added. The draft specifies that the decision regarding which of the fields to implement can be made on a per-list basis, so the choice is yours. - -- "Don't blame me - I'm a parasite." http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 14 Jan 1998 14:55:47 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: MUA internal command databases (was: List-* lifetimes) At 10:42 AM -0700 1998/1/13, D. J. Bernstein wrote: >Every time the MUA sees List-* fields it has to look up the current >instructions for that list and make sure there aren't any changes. > >Scanning through a thousand new messages---not to mention downloading >them in the first place, for people stuck behind modems---already takes >a noticeable amount of time. What exactly are we getting in return for >slowing this down even more? A clever MUA, with a speedy internal database, should not cause any more notable a hit on speed for message processing than the filters many people already use. I currently have 95 filters that my incoming mail gets processed through - processing 70 incoming messages takes about 4 seconds. At that rate, List- header database updating should add under a second to the processing time. What do you get in return? A much more convenient List command interface that should almost always be up to date. Consider, too, how much time is wasted by the clueless who try to send commands to lists. - -- http://www.nisto.com/product/caps.html O- <*> CapsBeep Control Panel for Mac: It can improve your caps lock key ---------------------------------------------------------------------- Date: 14 Jan 1998 14:56:02 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: List-ID (was: List-* lifetimes) At 12:02 PM -0700 1998/1/14, Rob Chandhok wrote: >What is this mythical List-ID header? I'd love to see one, but I don't >know of any standard or even common practice that uniquely identifies a >list (even if it moves around). The biggest problem with providing a unique ID for mailing lists is that, currently, the only insurance of uniqueness is the list's domain name. The problem comes up when the list moves to a new domain name (as this one recently did). What I'm think of is a List-ID field that contains an identifier method token followed by the ID based on the method. List-ID: DNS;list-header@list.nisto.com This leaves things open to other identifier systems, while letting us get the ball rolling now. One possiblity would be to have list ID registries. So, if I started a registry called Nisto, I could have an ID: List-ID: List-Registry; Nisto; list-header Then if you used some form of LDAP or such to do a registry lookup for the list "list-header" at the "Nisto" registry server, you would receive a current pointer to info about the list-header@list.nisto.com mailing list. - -- http://www.nisto.com/ O- <*> "Never ask a man what sort of computer he drives. If it's a Mac, he'll tell you. If not, why embarrass him?" - Tom Clancy ---------------------------------------------------------------------- Date: 14 Jan 1998 17:26:15 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-ID (was: List-* lifetimes) At 2:56 PM -0700 1/14/98, Grant Neufeld wrote: >The biggest problem with providing a unique ID for mailing lists is that, >currently, the only insurance of uniqueness is the list's domain name. The >problem comes up when the list moves to a new domain name (as this one >recently did). >What I'm think of is a List-ID field that contains an identifier method >token followed by the ID based on the method. > > List-ID: DNS;list-header@list.nisto.com > >This leaves things open to other identifier systems, while letting us get >the ball rolling now. If you are going to use DNS, I would use something like: List-ID: DNS; list-header.list.nisto.com or List-ID: DNS; list-header.nisto.com Why? You already own nisto.com, so you can control the names below it. This would work even if some other machine was serving the list, the List-ID doesn't have to correspond to the server machine in any way. We just need a unique name. >One possiblity would be to have list ID registries. So, if I started a >registry called Nisto, I could have an ID: > > List-ID: List-Registry; Nisto; list-header > >Then if you used some form of LDAP or such to do a registry lookup for the >list "list-header" at the "Nisto" registry server, you would receive a >current pointer to info about the list-header@list.nisto.com mailing list. Oh good. Another distributed registry protocol. We don't have to be as formal as the InterNIC (or whatever it's called now), nor should list-moms have to pay to register or serve these IDs. They don't even have to be looked up -- we just want them to be unique! Like ethernet hardware addresses. The namespace problem here is more related to the MIB naming issues in SNMP, no? Or perhaps the naming schemes for mime-parts. In otherwords, we might have a free "registry" that resolves collisions in the name space, but other than that there is no protocol involved. For example, you could have: lists.vendor.nisto.* I could have lists.vendor.within.* or personally lists.personal.ravinder_chandhok.* If I didn't CARE if the id was unique, I could use: lists.x.* the experimental part of the namespace heierarchy. If you want to really want to make relocatable pointers to lists that move, why not use URNs? I just don't want to do something as complicated as you suggest. Rob ---------------------------------------------------------------------- Date: 15 Jan 1998 03:38:57 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Some suggested changes to draft-aber-listspec-02.txt A few suggested changes to the 14 Jan 1998 version of http://www.nisto.com/listspec/ietf/draft-baer-listspec-02.txt > 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 > | field is typically a URL - usually mailto [4] or http - which > | locates the relevant information or performs the command directly. > | mailto URLs SHOULD take precedence. Change: Remove the last line. Reason: It is up to the receiving user to decide which of the methods to chose. One user may instruct his MUA that mailto has precedence over http, another user may instruct this MUA with the reverse. > | 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 SHOULD 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, at minimum, a mailto URL SHOULD be provided > wherever possible. Change: Remove the sentence "The URLs have precedence from left to right." Reason: See reason for my previous suggested change above. > 3. The List Header Fields > > This document presents header fields which will provide the command > syntax description for the 'core' and key secondary functions of most > email distribution lists. The fields 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. There MUST be > | no more than one of each field present in any given message. Change: "all posts to the list" to "all messages distributed by the list". Reason: "posts to the list" gives the impression that these fields should be set by the sender of a message when sending the contribution to the list. Question: Is it permitted for a sender to set this fields already when submitting a message to a mailing list? Or is it only mailing list expanders which may add these fields? > 3.5. List-Owner > > The List-Owner field identifies the path to contact a human > | administrator for the list. The URL MAY contain the address 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). Change: Change "moderator" to "a specific administrator for this specific list". Reason: The use of the word "moderator" may lead people to wrongly assume that this is the right way to reach the moderator, even in changes where moderator and list-administrator are not the same person. > | Dependant on how postings to the list are handled, the sublist MAY > | replace the List-Post field. The appropriateness of whether to > | replace List-Post is left to the determination of the individual list > | managers. Change, add: "If the intention is that postings should be distributed to all members of the primary list, List-Post should not be changed by a sublist in such a way that postings will be distributed only to members of the sublist." Reason: Some dumb implementor may not understand this otherwise. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 15 Jan 1998 03:39:13 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List confirmations, List-IDs and List Info MIME parts At 13.11 -0700 98-01-14, Grant Neufeld wrote: > I'm now preparing three drafts for discussion here. In order of my priority: > > > Mail Command Confirmations > > A consistant format for mail command confirmations, modeled on DSNs > [rfc1894]. This will allow for MUAs to automate (or at least make > friendlier) the process of confirming commands. Very good! > List-IDs > > A flexible method of uniquely identifying lists without necessarily tying > the identifier to a given domain name. Are you aware that the IETF working group on URNs are already working on the general issue of specifying identifiers for web resources, which will not change if the web resource changes its location. It is probably best if the same method is used for list identifiers as they will develop for naming other web resoruces. I suggest you check their latest IETF drafts. > List Info MIME Part > > Similar to the DSN format. In particular, the "message/delivery-status" part. > > Intended to provide a means of describing the features of a List, and the > associated command syntax. Nice! Especially methods which will enable a MUA to automatically retrieve archives of a list are useful. One can of course discuss whether we should use the complex method of letting any list software have their own commands, and describing these, or just standardise on a standard set of commands for retrieving archives. (A list software can of course have its own proprietary methods in addition to the standard ones). I have a feeling that the standard we write may be too complex if it has to describe whatever funny method any list software is using. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 15 Jan 1998 05:43:50 -0700 From: James Berriman <(suppressed)@frutiger.staffs.ac.uk> Subject: Re: List confirmations, List-IDs and List Info MIME parts At 11:35 15/1/98, Jacob Palme wrote: >One can of course discuss whether we should >use the complex method of letting any list software have their own >commands, and describing these, or just standardise on a standard set >of commands for retrieving archives. (A list software can of course >have its own proprietary methods in addition to the standard ones). >I have a feeling that the standard we write may be too complex if it >has to describe whatever funny method any list software is using. But that is by far the most flexible method, and will be far easier for list admins to adopt. Consider that a generalised standard for describing the many existing command syntaxes can theoretically be implemented by any list admin using any MLM (the big benefit is that it will work using existing list software), whereas attempting to define a standard core set of MLM commands will rely on MLM developers to adopt this new standard and list admins to upgrade their software, which may delay widespread adoption or even frustrate the idea completely. Limiting the usefulness of such a standard to a core set of commands may also make it less popular. It occurs to me that XML (this week's buzzword on the net!) might be a useful tool for describing list command syntax. Perhaps it would be a useful exercise to try defining an XML DTD for MLM comand syntax? The XML document could be served up as an email attachment or via a web server. ( :-]) James ---------------------------------------------------------------------- Date: 15 Jan 1998 11:19:27 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: List confirmations, List-IDs and List Info MIME parts At 3:35 AM -0700 1998/1/15, Jacob Palme wrote: >> List-IDs ... >Are you aware that the IETF working group on URNs are already working >on the general issue of specifying identifiers for web resources, Vaguely. >I suggest you check their latest IETF >drafts. Like I don't have a hundred other drafts and RFCs on my reading list already ;-) >> List Info MIME Part ... >One can of course discuss whether we should >use the complex method of letting any list software have their own >commands, and describing these, or just standardise on a standard set >of commands for retrieving archives. ... >I have a feeling that the standard we write may be too complex if it >has to describe whatever funny method any list software is using. There will inevitably be limits to the range of syntax we can describe - the no-variable compromise in the List- header fields being an example. The question you're raising is whether, for the MIME part, we should again go the route of a meta-syntax, or instead start on the immensely frustrating and deeply religious problem of producing a standard core command syntax. Personally, as crazy as it may sound, I favor going after the standard syntax now. However, in order to get something working this side of the year 3000, we should proceed with meta-syntax - probably URL based as that is quite well established now. At 5:39 AM -0700 1998/1/15, James Berriman wrote: >It occurs to me that XML (this week's buzzword on the net!) might be a >useful tool for describing list command syntax. SGML can be used to describe and contain any type of data that can be stored on a computer. It is indeed very useful. However, it is also very easy for people to mess up (one only needs to take a passing glance at the state of most HTML documents to see that). We have to consider how easy or difficult it will be for this to be implemented correctly. >Perhaps it would be a useful exercise to try defining an XML DTD for MLM >comand syntax? If you're interested, please give it a go. - -- "Driving Drunk? Don't wear a seat-belt!" http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 15 Jan 1998 11:20:52 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: Some suggested changes to draft-aber-listspec-02.txt At 3:24 AM -0700 1998/1/15, Jacob Palme wrote: >A few suggested changes to the 14 Jan 1998 version of >http://www.nisto.com/listspec/ietf/draft-baer-listspec-02.txt > >> 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 >> | field is typically a URL - usually mailto [4] or http - which >> | locates the relevant information or performs the command directly. >> | mailto URLs SHOULD take precedence. > >Change: Remove the last line. > >Reason: It is up to the receiving user to decide which of the methods >to chose. One user may instruct his MUA that mailto has precedence >over http, another user may instruct this MUA with the reverse. I see from your comment that my intended meaning is unclear. How about: MTAs generating the header fields SHOULD usually include a mailto based command, in addition to any other protocols used, in order to support users who do not have access to non-mail-based protocols. >> | 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 SHOULD 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, at minimum, a mailto URL SHOULD be provided >> wherever possible. > >Change: Remove the sentence "The URLs have precedence from left to right." > >Reason: See reason for my previous suggested change above. I disagree. The precedence offers the MTA a way of specifying which of the offered protocols is "best". So, if you've got a great web interface for accessing list commands, you can give it priority. The MUA still gets to pick which URL command it supports, but this way it knows what the MTAs recommendations are. >> 3. The List Header Fields ... >>The fields implemented on a given list >> | SHOULD be included on all posts to the list, ... >Change: "all posts to the list" to "all messages distributed by the list". I've made the change. >Question: Is it permitted for a sender to set this fields already when >submitting a message to a mailing list? I think we should say specify that only MTAs should add the List- fields. >> 3.5. List-Owner ... >Change: Change "moderator" to "a specific administrator for this >specific list". > >Reason: The use of the word "moderator" may lead people to wrongly >assume that this is the right way to reach the moderator, even in >changes where moderator and list-administrator are not the same person. Point taken. On sub-lists: >Change, add: "If the intention is that postings should be distributed >to all members of the primary list, List-Post should not be changed >by a sublist in such a way that postings will be distributed only to >members of the sublist." Okay. Thanks for all the suggestions! - -- http://www.nisto.com/ O- <*> my views are too extreme to be those of anyone else. ---------------------------------------------------------------------- Date: 15 Jan 1998 11:21:56 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: List-ID At 5:18 PM -0700 1998/1/14, Rob Chandhok wrote: >If you are going to use DNS, I would use something like: > >List-ID: DNS; list-header.list.nisto.com >or >List-ID: DNS; list-header.nisto.com > >Why? You already own nisto.com, so you can control the names below it. But what about list-admins who don't own their domains? The only reason I suggested DNS is that it provides a distributed way of creating unique identifiers. From what I'm hearing, URNs are probably a better way to go, anyway. >Oh good. Another distributed registry protocol. > >We don't have to be as formal as the InterNIC (or whatever it's called >now), nor should list-moms have to pay to register or serve these IDs. I totally agree - which is why I suggested it use some existing method like LDAP, which anyone can run a server for. However, this may be a moot point if we go with URNs. - -- http://www.nisto.com/ O- <*> Tool-wielding ape online ---------------------------------------------------------------------- Date: 15 Jan 1998 13:18:38 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: Some suggested changes to draft-aber-listspec-02.txt At 11.22 -0700 98-01-15, Grant Neufeld wrote: > >> This is a proposal for additional header fields to be added to email > >> messages sent by email distribution lists. The content of each new > >> | field is typically a URL - usually mailto [4] or http - which > >> | locates the relevant information or performs the command directly. > >> | mailto URLs SHOULD take precedence. > > > >Change: Remove the last line. > > > >Reason: It is up to the receiving user to decide which of the methods > >to chose. One user may instruct his MUA that mailto has precedence > >over http, another user may instruct this MUA with the reverse. > > I see from your comment that my intended meaning is unclear. How about: > > MTAs generating the header fields SHOULD usually include a mailto based > command, in addition to any other protocols used, in order to support users > who do not have access to non-mail-based protocols. Ah! You meant precedence in generation, I thought you meant precedence in receipt. Your new text is good and clear. > > >> | 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 SHOULD 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, at minimum, a mailto URL SHOULD be provided > >> wherever possible. > > > >Change: Remove the sentence "The URLs have precedence from left to right." > > > >Reason: See reason for my previous suggested change above. > > I disagree. The precedence offers the MTA a way of specifying which of the > offered protocols is "best". So, if you've got a great web interface for > accessing list commands, you can give it priority. The MUA still gets to > pick which URL command it supports, but this way it knows what the MTAs > recommendations are. The word "precedence" may not be the right word for what you mean. What you mean is rather a recommendation. What about the following text: A list of multiple, alternate, URls MAY be specified by a comma- separated list of angel-bracket enclosed URLs. The choices should be ordered with more recommended choices before less recommended choices. A client is recommended to use the leftmost protocol that it supports, or knows how to access by a separate application.... > I think we should say specify that only MTAs should add the List- fields. OK! - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 15 Jan 1998 13:19:44 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List confirmations, List-IDs and List Info MIME parts At 11.21 -0700 98-01-15, Grant Neufeld wrote: > At 3:35 AM -0700 1998/1/15, Jacob Palme wrote: > >> List-IDs > ... > >Are you aware that the IETF working group on URNs are already working > >on the general issue of specifying identifiers for web resources, > > Vaguely. I am certainly no expert on URNs, but here is a short summary of my understanding of what they want: They assume that there will be a number of different registries of permanent, indestructible names of resources. Each registry may have its own naming scheme. Some of them may be distributed, others may use a centralised data base. Thus, an URN begins with a specification of which registry it uses, and then comes the name within that registry. Something like this: ISBN: 1-871802-06-7 Marty's-big-list-of-mailing-lists: foo-bar To use an URN, you contact the registry named in the beginning of the URN, and give it the string after the ":". The URN registry will then return the present URL for the object. The List-Headers group could thus, if it so wants, either use one of the registry schemes defined by the URN group, or define one of our own, and put it under the URN umbrella, so that our names may have a format like: List-Header-Group's-Great-Mailing-List-Registry: foo-bar - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 15 Jan 1998 16:40:18 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: List-ID URNs (was: List confirmations, List-IDs and List Info MIME parts) At 1:12 PM -0700 1998/1/15, Jacob Palme wrote: >I am certainly no expert on URNs, but here is a short summary of my >understanding of what they want: Sounds like exactly like I want. URNs it is! So, we'll have a header field "List-ID:" which contains an URN. The URL retrieved from the URN must be the same as would be found in a current List-Help field for the list. Eventually, the list-info MIME part will be part. or all, of what is returned by that URL. Does anyone see a problem with this? Is it missing anything? - -- "Hard work pays off in the future. Laziness pays off now" http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 15 Jan 1998 16:40:53 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Command Precedence (was: Some suggested changes to draft-aber-listspec-02.txt) At 1:05 PM -0700 1998/1/15, Jacob Palme wrote: >> >> | 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 SHOULD use the >> >> leftmost protocol that it supports, or knows how to access by a >> >> separate application. ... >The word "precedence" may not be the right word for what you mean. What >you mean is rather a recommendation. What about the following text: > >A list of multiple, alternate, URls MAY be specified by a comma- >separated list of angel-bracket enclosed URLs. The choices should be >ordered with more recommended choices before less recommended choices. >A client is recommended to use the leftmost protocol that it supports, >or knows how to access by a separate application.... I'm still inclined to go with SHOULD. MUAs can choose otherwise (that's why it's SHOULD instead of MUST), but in general following the given precedence is the right thing to do. >> I think we should say specify that only MTAs should add the List- fields. > >OK! I've added the line: "These fields MUST only be generated by mailing lists, not end users." to the introduction to section 3. I don't specify MTAs or server software, because there are lists "run by hand" which would benefit from the presence of the headers. - -- "The trouble with being punctual is that nobody's there to appreciate it." http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 16 Jan 1998 09:15:02 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-ID URNs At 4:42 PM -0700 1/15/98, Grant Neufeld wrote: >URNs it is! > >So, we'll have a header field "List-ID:" which contains an URN. The URL >retrieved from the URN must be the same as would be found in a current >List-Help field for the list. Eventually, the list-info MIME part will be >part. or all, of what is returned by that URL. > >Does anyone see a problem with this? Is it missing anything? I spent some time looking at the URN documents. It seems like we need to agree on the following: 1) A URN namespace specification string (or NSS) for mailing lists. I propose "listid". See for an example document proposing a URN namespace. See also for the proposal around NSS issues. Thus, List-IDs start to look like: List-ID: urn:listid: Qustion: until IANA is set up to register NSS identifiers, should we use the experimental prefix to the NSS "x-"? I.e.: List-ID: urn:x-listid: 2) A syntax for the list-id that comes after the NSS. I propose use a hierarchical namespace similiar to MIBs so that 90% of the people won't have namespace conflicts by default. Thus, a full list ID for the list-headers mailing list MIGHT be: List-ID: urn:x-listid:nisto.list-header One might argue that since we are always putting a URN in the List-ID header, we should just strip the "URN:x-listid:" out. Or at least leave as optional - like slack URL handling. I think there are good reasons to do that. Then, you can still use the full URN name to reference a mailing list from elsewhere. Thus we have the header: List-ID: nisto.list-header and the corresponding URN: urn:x-listid:nisto.list-header Finally, please note. Once the list is created, any change in the List-ID identifier implies that the old list died, and a new one has been made. At least that is how any automated system should handle it. Rob ---------------------------------------------------------------------- Date: 16 Jan 1998 12:58:05 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID URNs At 11.09 -0500 98-01-16, Rob Chandhok wrote: > I spent some time looking at the URN documents. It seems like we need to > agree on the following: > > 1) A URN namespace specification string (or NSS) for mailing lists. I > propose "listid". See > for an example > document proposing a URN namespace. See also > for the > proposal around NSS issues. You are assuming that we define our own URN name space, specifically for mailing lists. Another choice might be that we allow any URN name space, which so wants, to include mailing lists in their name space. In that case, we just say that List-ID is a URN, and nothing more. If we define our own name space, I believe we also have to set up reliable servers to look up List-ID-s in this name space. If we allow any URN name space, different providers can compete in providing different kinds of URN name spaces (which may be good or bad). Of course, defining our own name space and setting up our own servers might be a safer way to get reliable service. The goal should be to make it as easy to find a mailing list on a particular topic as it is to find a newsgroup on that topic. We might negotiate with one of the big net info providers, like Yahoo or Cnet, to run such a service for us. The two options above do not exclude each other. We can say that List-ID can contain any URN which resolves to a mailing list help info service, and still define our own name space and establish servers for that name space. Note: If a mailing list can be found through more than one URN name space, then there will be more than one ID for the same list. We will not, then, be able to compare two List-ID-s and know that if they are identical, it is the same list, if they are not identical, it is not the same list. If we set up our own name space, we can specify it so that List-ID will be unique in this way. Not an easy decision. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 16 Jan 1998 13:27:40 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-ID URNs At 8:54 PM +0100 1/16/98, Jacob Palme wrote: >If we define our own name space, I believe we also have to set up >reliable servers to look up List-ID-s in this name space. If we >allow any URN name space, different providers can compete in providing >different kinds of URN name spaces (which may be good or bad). I believe you are incorrect. We might have to set up a registry to verify uniqueness, but I don't think you have an on-line resolver service. If List-ID has to wait for a fully functional resolver service to be used, then call me in a few years when that is done. Until then, I'll use the urn:x-listid: namespace. > >Not an easy decision. Actually, I think it is a pretty straightforward decision. Having a single collision-free name space for mailing lists is *essential* to List-ID being useful at all. URNs give us a good solution in both the short and long term. Rob ---------------------------------------------------------------------- Date: 17 Jan 1998 20:01:37 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID URNs At 15.23 -0500 98-01-16, Rob Chandhok wrote: > I believe you are incorrect. We might have to set up a registry to verify > uniqueness, but I don't think you have an on-line resolver service. > > If List-ID has to wait for a fully functional resolver service to be used, > then call me in a few years when that is done. Until then, I'll use the > urn:x-listid: namespace. > > > > >Not an easy decision. > > Actually, I think it is a pretty straightforward decision. Having a single > collision-free name space for mailing lists is *essential* to List-ID being > useful at all. URNs give us a good solution in both the short and long > term. Even if you are right, we need not set up our own name space, we could use some URN name space which already has been defined, and which probably has a wider usage, applying not only to list-ids. One advantage with our own name space would be that you can see from the id that it is a list-id and not some other kind of resource. By the way, if we restrict the list-id URN name space to only apply to mailing lists, we need to define what we mean by a mailing list. The Internet usage of the term "mailing list" is an object which has an RFC 822 mailbox address, and which is connected with an expander software, so that any message sent to that address is forwarded to a list of members of the list. But are the following also mailing lists according to our definition? (1) A Lotus Notes application (and similar objects in other Groupwares). (2) A mailing list, which is read by the sender MUA and used to construct the list of recipients before initial submisson of a message. (3) A Usenet News conference, addressed via e-mail to a mail-to-news gateway. Other news-to-mail gateways may take the messages out of news again, so this combination in fact acts as a somewhat complex mailing list, as seen from the e-mail side. Many mailing lists do not have any List-Post or List-Subscribe or other headers, and could not use them. Many lists do not honor the custom that messages to list-request go to the administrator. Are those "lists" according to our definition, can they be included in or List-ID name space? My conclusion is yes in all cases. All these non-standard mailing lists can be included in our name space. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 18 Jan 1998 10:10:21 -0700 From: James Berriman <(suppressed)@frutiger.staffs.ac.uk> Subject: RDF and command syntax. RDF sounds like a possible solution for describing MLM command syntax. See (extract) "RDF will allow different application communities to define the metadata property set that best serves the needs of each community. RDF will provide a uniform and interoperable means to exchange the metadata between programs and across the Web. Furthermore, RDF will provide a means for publishing both a human-readable and a machine-understandable definition of the property set itself." ( :-]) James ---------------------------------------------------------------------- Date: 19 Jan 1998 16:43:38 -0700 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: Updating List Info (was: List-* lifetimes) At 02:54 PM 1/14/98 -0700, Grant Neufeld wrote: >At 6:21 PM -0700 1998/1/11, Rob Chandhok wrote: >>It seems to me that given the currently proposed standard, the user has to >>play some role in deciding when to update information stored about a >>particular mailing list. > >There is a Date field on every message. >If the Date field is more recent than the last message from the list, and >there is a difference in the List- header info (or List Info MIME part, or >whatever), then the MUA may want to update its internal database of list >commands/info (if it maintains one) - or prompt the user to make some >decision about handling the change. True. Another approach would be to combine the List-ID approach with the List-* approach. Simply have a field that was List-ID, that gives a plaintext name for the list, a brief description, and an optional versioning number. For example: List-Id: list-header; "List Headers Discussion List"; 1.15 Then, you have some reasonable information to provide the user of the MUA with, a way of tracking if any administrative changes have been made (as long as the list server software upgrades its versioning number when a change is made), and as a neat side effect, a method of determining if the list has changed location. The problem I see with this is the possibility of having two lists with the same plaintext name. Unless of course, we dispence with the name for the list and introduce a new field that would be "was formerly"... i.e. List-Id: "List Headers Discussion List"; 1.15; list-header@me.com just a couple of thoughts for everyone to munch on regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ ---------------------------------------------------------------------- Date: 20 Jan 1998 03:19:31 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: Updating List Info (was: List-* lifetimes) At 14.31 -0500 98-01-19, Jack De Winter wrote: > The problem I see with this is the possibility of having two lists > with the same plaintext name. Unless of course, we dispence with > the name for the list and introduce a new field that would be > "was formerly"... i.e. List-ID should surely be a globally unique identifier for the list, so that you can use the List-ID and go into a directory system to get the current URL(s) for this list. Since globally unique identifiers cannot be as human-friendly as plain-text names, a common method is to have two names of an object, one plain-text and one globally unique, like in an e-mail address: "List header standardization group"