List-Header Digest Archive: April 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: -> Re: List of Email Clients by Morna Findlay <(suppressed)@newcastle.ac.uk> -> Introduction... by (suppressed)@polyhymnia.pmail.gen.nz -> Re: List of Email Clients by Morna Findlay <(suppressed)@newcastle.ac.uk> -> Re: Introduction... by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> my status by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Introduction... by "Richard Stevenson" <(suppressed)@polyhymnia.pmail.gen.nz> -> Re: Introduction... by Christopher Allen <(suppressed)@consensus.com> -> Draft Letter to server authors by Grant Neufeld <(suppressed)@achilles.net> -> general report by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Christopher Allen <(suppressed)@consensus.com> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> List-Post by (suppressed)@akimbo.com -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> minor revision to draft by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Paul Hoffman <(suppressed)@imc.org> -> Re: minor revision to draft by Christopher Allen <(suppressed)@consensus.com> -> list-address field by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: list-address field by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: list-address field by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Function name in header value by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by Noritoshi Demizu <(suppressed)@csl.sony.co.jp> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by (suppressed)@akimbo.com -> Plain text in header fields (was: List-Post) by Grant Neufeld <(suppressed)@achilles.net> -> How many (which) headers? (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> List Details MIME part (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> s-ubscribe vs. the rest (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> Re: s-ubscribe vs. the rest (was: general report) by Rob Chandhok <(suppressed)@within.com> -> disclosing to the user (was: list-address field) by Grant Neufeld <(suppressed)@achilles.net> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by Marc Horowitz <(suppressed)@cygnus.com> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Marc Horowitz <(suppressed)@cygnus.com> -> Re: Plain text in header fields (was: List-Post) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: Plain text in header fields (was: List-Post) by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by (suppressed)@akimbo.com -> Re: Plain text in header fields (was: List-Post) by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: s-ubscribe vs. the rest (was: general report) by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? (was: general report) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: s-ubscribe vs. the rest (was: general report) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: Plain text in header fields (was: List-Post) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: list-address field by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: Plain text in header fields (was: List-Post) by Christopher Allen <(suppressed)@consensus.com> -> Re: s-ubscribe vs. the rest (was: general report) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields (was: List-Post) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields (was: List-Post) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: disclosing to the user (was: list-address field) by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: s-ubscribe vs. the rest (was: general report) by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: Plain text in header fields (was: List-Post) by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: general report by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: Plain text in header fields (was: List-Post) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: Plain text in header fields (was: List-Post) by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: Plain text in header fields (was: List-Post) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: Plain text in header fields (was: List-Post) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Christopher Allen <(suppressed)@consensus.com> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: general report by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: general report by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> MIME type for List Details object (was: general report) by Grant Neufeld <(suppressed)@achilles.net> -> Re: Plain text in header fields by Grant Neufeld <(suppressed)@achilles.net> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> list spec updates by Grant Neufeld <(suppressed)@achilles.net> -> Re: How many (which) headers? by Grant Neufeld <(suppressed)@achilles.net> -> we're talking about mail - use mailto (was: Plain text in header fields) by Grant Neufeld <(suppressed)@achilles.net> -> Re: s-ubscribe vs. the rest by Grant Neufeld <(suppressed)@achilles.net> -> forbidden commands (was: Plain text in header fields) by Grant Neufeld <(suppressed)@achilles.net> -> Re: disclosing to the user by Grant Neufeld <(suppressed)@achilles.net> -> this list (was: list-address field) by Grant Neufeld <(suppressed)@achilles.net> -> Re: general report by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: MIME type for List Details object (was: general report) by Marc Horowitz <(suppressed)@cygnus.com> -> Re: How many (which) headers? by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: general report by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: list-address field by Grant Neufeld <(suppressed)@achilles.net> -> Re: How many (which) headers? by Grant Neufeld <(suppressed)@achilles.net> -> Re: Plain text in header fields by Grant Neufeld <(suppressed)@achilles.net> -> Re: How many (which) headers? by (suppressed)@polyhymnia.pmail.gen.nz -> Re: How many (which) headers? by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: list-address field by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Plain text in header fields by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by Keith Moore <(suppressed)@cs.utk.edu> -> Re: How many (which) headers? by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Plain text in header fields (was: List-Post) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: list-address field by "Roger Fajman" <(suppressed)@CU.NIH.GOV> -> Re: How many (which) headers? by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: general report by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: list-address field by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: list-address field by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: How many (which) headers? (was: general report) by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Re: How many (which) headers? (was: general report) by "Jack De Winter" <(suppressed)@wildbear.on.ca> -> Nested mailing lists by Jacob Palme <(suppressed)@dsv.su.se> -> Re: How many (which) headers? by "Clarence C. Wong" <(suppressed)@qualcomm.com> -> Re: list-address field by (suppressed)@frutiger.staffs.ac.uk (James Berriman) ---------------------------------------------------------------------- Date: 2 Apr 1997 04:09:23 -0500 From: Morna Findlay <(suppressed)@newcastle.ac.uk> Subject: Re: List of Email Clients >The December 96 issue of Internet World had a product comparison of the >following 12 email clients. I thought the list would be useful for our >evangelizing efforts: [List deleted] > >I know that this leaves out a lot of programs. (Such as Elm and Pine >already mentioned). However, I think this is a good start? Yes it is a good start but I think it's worth remembering programs like elm and pine which are free to the user and so have a heavy user-base and so will be around for a while. Here in the UK academic community a survey of all UK universities showed that ( in those sites which responded) pegasus was by far the most popular user agent. It's free - so it's give to students to use. Commercial UAs trailed in use but I'm sure these will be catching up fast as more staff and students get PCs on their desks. ( Yes, there are still plenty of staff here without email access!) cheers Morna Findlay Mailbase http://www.mailbase.ac.uk/ ( Main UK academic email list service) ---------------------------------------------------------------------- Date: 3 Apr 1997 07:21:57 -0500 From: (suppressed)@polyhymnia.pmail.gen.nz Subject: Introduction... - -----BEGIN PGP SIGNED MESSAGE----- Hi all I work for David Harris, the author of the Pegasus Mail system and Mercury mail transport system. This working group has been brought to our attention recently, and we decided to take a look at what you're doing. David can see the potential benefit in what you're all working to achieve, and is willing to support the headers you propose, both in the Pegasus Mail client and in the Mercury list server. I'm just here to let you know we're watching with great interest - let's face it, anything to make lists easier from the user's point of view is A Good Thing (TM). The proposed standard will go a long way toward the simplification of list use. I look forward to seeing the progress of the proposal. BTW, does this list server support MIME digests? The other kind are dreadful to work with... Cheers Richard - -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 iQCVAwUBM0Of7KRUcYUOWi3VAQFlNAP+KRIUMHVJdJd7N4HEjMuSUClYRxHs/itC oylHVICOi953dnwnaURQMmUH08Q1xKeL5PXNs03/UxTLfLjtdotMx7SFyAft2yQs J2kfNwYJzWSQjVjDJXqNogQrcq0c+9v20icSOEpiYB2DgThyrscWLW2OWU7IVeRS S+i0DFdQebg= =+qC8 - -----END PGP SIGNATURE----- - -- Richard Stevenson richard@polyhymnia.pmail.gen.nz Earth Rotation Protection Society http://home.sol.no/litlaboe/erps PGP Key ID 0x0E5A2DD5 fingerprint = 7B DD 1C 51 76 05 A1 42 44 2E DD 61 78 DB 2D 07 ---------------------------------------------------------------------- Date: 3 Apr 1997 07:59:57 -0500 From: Morna Findlay <(suppressed)@newcastle.ac.uk> Subject: Re: List of Email Clients I let the pegasus developers know about this group. Here's what they said: >> Hello - I wonder if you are aware of the IETF working party >> on list-headers. > >> The group is actively seeking the cooperation of developers >> of UAs to incorporate the proposed standards which will be >> aired at the Memphis IETF next week. >Thanks for the information - we hadn't heard of the proposal until your >message. We've taken a look at what the working group is proposing, and >are very interested. We'll be watching the progress of the standard with >an eye to implementing the changes required. > >Pegasus Mail Technical Support, Dunedin, New Zealand. >tech-support@pmail.gen.nz M Morna Findlay Mailbase Manager http://www.mailbase.ac.uk/ ---------------------------------------------------------------------- Date: 3 Apr 1997 09:58:02 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Introduction... At 7:17 AM -0500 4/3/97, Richard Stevenson wrote: > I work for David Harris, the author of the Pegasus Mail system and Mercury > mail transport system. This working group has been brought to our > attention recently, and we decided to take a look at what you're doing. Welcome! > David can see the potential benefit in what you're all working to achieve, > and is willing to support the headers you propose, both in the Pegasus > Mail client and in the Mercury list server. I'm just here to let you know > we're watching with great interest - let's face it, anything to make lists > easier from the user's point of view is A Good Thing (TM). The proposed > standard will go a long way toward the simplification of list use. I look > forward to seeing the progress of the proposal. Great to hear! Most people have met this proposal with open arms, and we already have some working implementations available for review. What features do you like most? What user-interface elements do you think will be most useful? > BTW, does this list server support MIME digests? The other kind are > dreadful to work with... Reply to this message and change the subject to "subscribe digest". ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 4 Apr 1997 13:21:39 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: my status Sorry I dropped off the face of the earth there - I got hit with a really nasty bug and so have been trying to spend most of my time sleeping, napping or whining ;-) The bug seems to be starting to let up, so I may be able to get to the pr stuff sometime over the next few days. Please bear with me on this. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 4 Apr 1997 17:54:47 -0500 From: "Richard Stevenson" <(suppressed)@polyhymnia.pmail.gen.nz> Subject: Re: Introduction... - -----BEGIN PGP SIGNED MESSAGE----- On 3 Apr 97 at 9:53, Joshua D. Baer wrote: > At 7:17 AM -0500 4/3/97, Richard Stevenson wrote: > > > David can see the potential benefit in what you're all working to achieve, > > and is willing to support the headers you propose, both in the Pegasus > > Mail client and in the Mercury list server. I'm just here to let you know > > we're watching with great interest - let's face it, anything to make lists > > easier from the user's point of view is A Good Thing (TM). The proposed > > standard will go a long way toward the simplification of list use. I look > > forward to seeing the progress of the proposal. > > Great to hear! Most people have met this proposal with open arms, and we > already have some working implementations available for review. What > features do you like most? What user-interface elements do you think will > be most useful? The best part of it is that the list subscriber doesn't have to worry about remembering what the commands are, and whether they should be placed in the subject or the body of the message. I've come into the discussion too late, given that there is already an IETF draft on this... but here's one concern I do have. RFC1738 defines the Mailto: URL as mailto: The ?Subject= and ?Body= extensions, along with any others, are non-standard. Does anybody know if a revision of, or amendment to, RFC1738 is in the pipeline? I can't imagine anything worse than specifying certain URL formats for list headers, and then having the specification for Mailto: URLs use a different format when it eventually specifies extensions of this type. > > BTW, does this list server support MIME digests? The other kind are > > dreadful to work with... > > Reply to this message and change the subject to "subscribe digest". Tried that... it's the other kind of digest Cheers Richard - -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 iQCVAwUBM0WE6KRUcYUOWi3VAQEydgQAkrSouUNBsttmo4Si9TbbQFv+Gvgn924X DI5LyuZhsvqnBk6HuSGjCDHewUas+Hk0LQPMcibmTLe4xg5+eG0ggYG1Ro9vures MBnLn8gDfXAY9hhYIKeAHOn1uCWa2nSPzLO9D8FDSvOBHN3+vpbAScQ+b98Ub7gb C0H7e6tP92g= =pC+K - -----END PGP SIGNATURE----- ---------------------------------------------------------------------- Date: 4 Apr 1997 18:11:59 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Introduction... At 2:47 AM -0800 4/5/97, Richard Stevenson wrote: >I've come into the discussion too late, given that there is already >an IETF draft on this... but here's one concern I do have. RFC1738 >defines the Mailto: URL as > >mailto: > >The ?Subject= and ?Body= extensions, along with any others, are >non-standard. Does anybody know if a revision of, or amendment to, >RFC1738 is in the pipeline? I can't imagine anything worse than >specifying certain URL formats for list headers, and then having the >specification for Mailto: URLs use a different format when it >eventually specifies extensions of this type. There is already a well-recieved Internet-Draft that defines the ?subject=, etc. tags. It is . Mailto:'s in this format have been adopted by most every Mac mail software developer, Netscape, Microsoft, and a number of PC mail software developers. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 12 Apr 1997 13:28:07 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Draft Letter to server authors Please review the following and let me know if it looks good for sending to list server software authors. (the letters for list managers and client authors are nearly identical) Are the spelling, grammar, punctuation, etc. okay? Does it cover everything needed for a cover letter? Is there anything that doesn't need to be in this letter? Is it 'enticing' enough to get them interested? --- Begin DRAFT Letter --- This is a request for you to implement support for the List Header initiative which will make mail list access much easier for users. The newly defined List Header Fields provide you with a standard method by which you can consistently describe electronic mailing list command syntax so that client applications can implement an interface to make list access easier for users. As they are adopted and supported by email software developers, the List header fields will make it easier for users to join and leave email lists. The currently defined fields are List-Subscribe, List-Unsubscribe and List-Help. They describe commands for subscribing, unsubscribing and retrieving help information. An Internet-Draft, which formally describes the header fields and their content, has been submitted to the IETF for consideration to become an RFC. Implementation guidelines for list software authors are available at: Extended details on the List header fields are available from: A mailing list for discussion is available at: or Please let us know if you plan to implement support for the List header fields, and also if/when you ship an implementation, so we can track the progress of this initiative. --- End Letter --- - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 12 Apr 1997 13:56:44 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: general report Well, I seem to be mostly over the bug that had me wiped out for a while there. Just some lingering throat irritation left. So, I'm back in action again, finally. New document: "Guidelines to the List Specification Header Fields for Server Application Authors" Updated documents: I've split up the main document a bit. The technical stuff has been split off into separate documents: with more to come (such as the MIME part). Any news from Memphis, yet? Did the BOF thing happen? We still need people to contact mail software authors. The biggies that we don't have contacts for yet include: AOL, Netscape, ELM, PINE, Listserv, Listproc, SmartMail. Although many of those are represented on lists like List-Managers. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 12 Apr 1997 14:14:08 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: general report At 10:56 AM -0700 4/12/97, Grant Neufeld wrote: >Any news from Memphis, yet? Did the BOF thing happen? Yes, there was a BOF meeting at IETF Memphis. It originally was to be much larger in scope then our internet draft (there were two chairmen of the BOF that had I think a larger agenda in mind) but in the end most of the discussion was about our internet draft. I gave a brief overview of the draft, and tried to respond to questions that people had. The two biggest concerns were that some firewalls and gateways strip out unknown headers (the response to which was that it was a chicken and egg situation, they wouldn't add the headers until the draft was accepted) and the use of List-Subscribe as a priority over List-Archive (which I tried to respond to but didn't have a strong point). Other concerns were raised but I think I adequately covered them based on the results of previous discussions on this list. Most of the discussion was of making List-Header a working group, and we decided that we didn't want to have agenda creep. So instead, we should do a two-week "list last call" and advertise it widely, and then submit the draft to the IESG for a four week "IESG Last Call". If there are no major objections, we could be an RFC without using a Working Group in 6 week! I had to leave the meeting early (it was scheduled at the same time as the S/MIME BOF), so I don't have the minutes for the whole meeting, but I was told later that there was not a whole lot more discussion after I left. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 12 Apr 1997 19:15:58 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 2:11 PM -0400 4/12/97, Christopher Allen wrote: > I gave a brief overview of the draft, and tried to respond to questions > that people had. The two biggest concerns were that some firewalls and > gateways strip out unknown headers (the response to which was that it was a > chicken and egg situation, they wouldn't add the headers until the draft > was accepted) and the use of List-Subscribe as a priority over List-Archive > (which I tried to respond to but didn't have a strong point). Other > concerns were raised but I think I adequately covered them based on the > results of previous discussions on this list. From your comments and those on this list, I'm favorable towards adding List-Archive and even List-Post to the draft. What do others think? ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 12 Apr 1997 20:12:08 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: general report At 07:11 PM 4/12/97 -0400, you wrote: >At 2:11 PM -0400 4/12/97, Christopher Allen wrote: > >> I gave a brief overview of the draft, and tried to respond to questions >> that people had. The two biggest concerns were that some firewalls and >> gateways strip out unknown headers (the response to which was that it was a >> chicken and egg situation, they wouldn't add the headers until the draft >> was accepted) and the use of List-Subscribe as a priority over List-Archive >> (which I tried to respond to but didn't have a strong point). Other >> concerns were raised but I think I adequately covered them based on the >> results of previous discussions on this list. > >From your comments and those on this list, I'm favorable towards adding >List-Archive and even List-Post to the draft. What do others think? From the IETF meeting, I think there was general feeling on keeping the draft at subscribe, unsubscribe, and help. Now, it was also felt that coming out with another doc, after the current one is a standard, that would encompass that doc, plus allow for enhancing mechanisms would be a good thing. i.e. get the current one through with a minimum of fuss and then worry about adding more. regards, Jack p.s. in favour of defining list- headers, and then defining a list of verbs, to keep the draft extensible - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 12 Apr 1997 23:40:00 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > Yes, there was a BOF meeting at IETF Memphis. It originally was to be much > larger in scope then our internet draft (there were two chairmen of the BOF > that had I think a larger agenda in mind) but in the end most of the > discussion was about our internet draft. The "two chairmen of the BOF that I think had a larger agenda in mind" could be read multiple ways, so let me clarify: We had two different requests, from two different parties, for mailing list related BOFs. One BOF request was for the List-* headers; the other was for a BOF to form a working group to standardize mailing list commands. Since we have a limited number of meeting slots, and the two topics were so similar, the Applications area directors (Harald Alvestrand and myself) decided to combine the two into a single BOF covering both topics. Rather than snub either proposal by appointing the other proposal's champion as BOF chair, we appointed Ned Freed and John Klensin as neutral co-chairs. (So yes, the chairs did have a larger agenda in mind, but they were just following the wishes of the area directors.) Given that the List-* proposal had a well-written draft document, and the other BOF topic had no document at all...it's not surprising that the List-* proposal got more attention. It's hard to discuss a proposal that doesn't exist in concrete form. Keith ---------------------------------------------------------------------- Date: 13 Apr 1997 01:14:44 -0400 From: (suppressed)@akimbo.com Subject: List-Post One recent thought I had about the headers is that we should define a format for message text instead of a URL. This is useful for List-Post in particular: List-Post: "You cannot post to this list. It is an announce-only list." Here I'm presuming that "..." is the syntax adopted for message text. The message would of course be directly readable in the headers, and if the user were to hit the "Post" button in a mail program, presumably this message would pop up. I can't see much use for message text in the other headers, although I suppose: List-Subscribe: "Send $99 to Scam & Spam, PO Box 1234, ..." would be useful to someone :-). --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 13 Apr 1997 02:34:19 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 11:36 PM -0400 4/12/97, Keith Moore wrote: > Given that the List-* proposal had a well-written draft document, and > the other BOF topic had no document at all...it's not surprising that > the List-* proposal got more attention. It's hard to discuss a > proposal that doesn't exist in concrete form. If it's not too off topic, could someone provide a concise summary of the other proposal? I think it would be of general interest here... ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 13 Apr 1997 09:56:48 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > If it's not too off topic, could someone provide a concise summary of the > other proposal? I think it would be of general interest here... All I have is a mail message from the person who proposed the BOF, which was basically of the form "wouldn't it be nice if we standardized a command language for mailing lists?" Most people would agree that it would be nice. But the last time we tried to do it, we found it (a) VERY difficult to get anything like consensus on the language to be used, and (b) also difficult to keep the discussion from diverging in to other areas -- such as whether and how lists should mung message headers. Keith ---------------------------------------------------------------------- Date: 13 Apr 1997 10:43:00 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: minor revision to draft In cleaning up the references section, a couple references that are referenced in appendix A were omitted, resulting in 'hanging' references. (how many references to the word reference can I make in one sentance? :-) Specifically, the [2] and [3] in the first paragraph of appendix A, which do not match the actual References in the draft. Should I submit a new version (01) of the draft, or can I just submit this as a minor correction to the standing draft? Here are the pertinant chunks of the current draft: A. Background Discussion This proposal arose from discussions started on the ListMom-Talk Discussion List [2]. When the discussion reached a sufficient level, a separate list was formed for discussing this proposal, the List Headers Mail List [3] for deeper discussion. We have included edited excerpts from that discussion here, in order to show some of the alternatives examined and reasons for our decisions. References [1] David H. Crocker, "Standard for the Format of ARPA Internet Text Messages" RFC 822, August 1982. [2] P. Hoffman and L. Masinter, "The mailto URL scheme" 'work in progress' January 1997. [3] T. Berners-Lee, L. Masinter and M. McCahill, "Uniform Resource Locators (URL)" RFC 1738, December 1994. I would either remove the references ("[2]" and "[3]") from the appendix, or add the two lists to the References section. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 13 Apr 1997 10:50:46 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: general report At 2:11 PM -0400 97/4/12, Christopher Allen wrote: >I gave a brief overview of the draft, and tried to respond to questions >that people had. Thanks for your work on this - it's much appreciated! >The two biggest concerns were that some firewalls and >gateways strip out unknown headers (the response to which was that it was a >chicken and egg situation, they wouldn't add the headers until the draft >was accepted) We're never going to be able to completely cover the wide variety of behaviours (broken or otherwise) exhibited by mail handling systems, but we can still make a significant difference for those systems that don't munge the headers. If we give up on trying to improve things because we can't help everybody, we'll never get anywhere. >and the use of List-Subscribe as a priority over List-Archive >(which I tried to respond to but didn't have a strong point). I stick to my point that it's the most widely used command (more people subscribe than unsubscribe) and as such there will be much to benefit from providing standardized access to it. >Other >concerns were raised but I think I adequately covered them based on the >results of previous discussions on this list. Great! Thanks again. >Most of the discussion was of making List-Header a working group, and we >decided that we didn't want to have agenda creep. So instead, we should do >a two-week "list last call" and advertise it widely, and then submit the >draft to the IESG for a four week "IESG Last Call". If there are no major >objections, we could be an RFC without using a Working Group in 6 week! That would be excellent. How does the IESG last call and vote work? The IETF procedures I read didn't explain these. >I had to leave the meeting early (it was scheduled at the same time as the >S/MIME BOF), so I don't have the minutes for the whole meeting, but I was >told later that there was not a whole lot more discussion after I left. Where can we get ahold of the minutes? Could someone post a copy here if they have them, please? - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 13 Apr 1997 10:51:53 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: general report At 7:11 PM -0400 97/4/12, Joshua D. Baer wrote: >At 2:11 PM -0400 4/12/97, Christopher Allen wrote: ... >> was accepted) and the use of List-Subscribe as a priority over List-Archive ... > >From your comments and those on this list, I'm favorable towards adding >List-Archive and even List-Post to the draft. What do others think? I don't want to push anything else into the current draft. It'll (hopefully) be a lot easier to get other things working once we have the core headers formally standardized. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 13 Apr 1997 20:12:49 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > >The two biggest concerns were that some firewalls and > >gateways strip out unknown headers (the response to which was that it was a > >chicken and egg situation, they wouldn't add the headers until the draft > >was accepted) > > We're never going to be able to completely cover the wide variety of > behaviours (broken or otherwise) exhibited by mail handling systems, but we > can still make a significant difference for those systems that don't munge > the headers. That's exactly right. Furthermore, we don't want to cater too much to broken behavior -- it just encourages it. Things that strip headers without knowing what they are deserve to lose. > If we give up on trying to improve things because we can't help everybody, > we'll never get anywhere. In other words, "the best is the enemy of the good". > >and the use of List-Subscribe as a priority over List-Archive > >(which I tried to respond to but didn't have a strong point). > > I stick to my point that it's the most widely used command (more people > subscribe than unsubscribe) and as such there will be much to benefit from > providing standardized access to it. As I recall, the argument was that List-Unsubscribe (not List-Archive) should be given top billing, because that will be seen to be the most useful feature. (or at least, it will provide the most pain relief.) Personally, I don't think it's a big deal either way, as long as both capabilities are present. > How does the IESG last call and vote work? The IETF procedures I read > didn't explain these. When you get the draft to the point that you think it's ready, (1) publish that document as a revised internet-draft, and (2) send mail to the IESG APPS Area Directors (me and Harald Alvestrand <(suppressed)@uninett.no>) asking that that draft be considered as a Proposed Standard. One of us will ask the Secretariat to send out a Last Call. The Last Call is announced by email to the IETF mailing list. The announcement is basically of the form: The IESG has received a request to consider "title" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by . The IESG will read the draft, along with any comments. Depending on the nature of the comments, the IESG may ask the authors to respond to the comments and/or revise the draft in light of comments. When the Last Call expires, the IESG will vote on the draft. If the IESG approves the draft, the approval will be announced to the IETF mailing list, and the RFC Editor will be asked to publish it as a Proposed Standard RFC. > Where can we get ahold of the minutes? Could someone post a copy here if > they have them, please? WG and BOF chairs have a couple of weeks to submit the minutes. Once the minutes are submitted, they will appear on the IETF web site. I'll try to rememebr to post them here when I get them. Keith ---------------------------------------------------------------------- Date: 13 Apr 1997 22:44:09 -0400 From: Paul Hoffman <(suppressed)@imc.org> Subject: Re: general report At 1:00 PM -0700 4/13/97, Keith Moore wrote: >When you get the draft to the point that you think it's ready, (1) >publish that document as a revised internet-draft... In the appendix to that finalish document, I suggest that you put a mention of this mailing list, and the list archives, so that people don't rehash old arguments. When (er, if) we get past the last call, you can ask the RFC editor to remove that appendix before publishing it as an RFC. Such a reference is, however, very useful to have on a non-WG document. - --Paul Hoffman, Director - --Internet Mail Consortium ---------------------------------------------------------------------- Date: 14 Apr 1997 09:58:59 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: minor revision to draft At 7:41 AM -0700 4/13/97, Grant Neufeld wrote: >Should I submit a new version (01) of the draft, or can I just submit this >as a minor correction to the standing draft? You have to do an 01. > [2] P. Hoffman and L. Masinter, "The mailto URL scheme" > 'work in progress' January 1997. /internet-drafts/draft-hoffman-mailto-url-00.txt> BTW, this has since been revised to 01 itself. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 15 Apr 1997 15:06:08 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: list-address field The new draft (01) suggests the following guideline for user feedback: > For 'mailto' URL based commands, mail client applications should > provide specialized feedback (such as presenting a dialog or alert), > instead of the actual command email message, asking for command > confirmation from the user. The feedback should identify the message > destination and command within a more descriptive explanation. For > example: > > "Do you want to send the unsubscription command 'unsubscribe > somelist' to 'somelist-request@some.host.com'? > Sending the command will result in your removal from the > associated list." Thought we wanted to hide this kind of information from the user. (If the user wants to see it, he reviews the outgoing message.) Some list servers also use the subject field. So then we mention all this detailed information, and pretty soon we have some verbiage that looks very similar to a URL!!! What happened to the list-address field? MUAs could be much more friendly with warnings such as: "Are you sure you want to unsubscribe from the "somelist@some.host.com" mailing list? You will no longer receive any posts to this list." - -Clarence ---------------------------------------------------------------------- Date: 15 Apr 1997 15:31:57 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 2:57 PM -0400 4/15/97, Clarence C. Wong wrote: > What happened to the list-address field? MUAs could be much more friendly > with warnings such as: "Are you sure you want to unsubscribe from the > "somelist@some.host.com" mailing list? You will no longer receive any posts > to this list." This would probably be the same as the List-Post field. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://www.skyweyr.com/skylist/ ---------------------------------------------------------------------- Date: 15 Apr 1997 18:38:34 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: list-address field At 10:57 AM -0800 4/15/97, Clarence C. Wong wrote: >> "Do you want to send the unsubscription command 'unsubscribe >> somelist' to 'somelist-request@some.host.com'? >> Sending the command will result in your removal from the >> associated list." > >Thought we wanted to hide this kind of information from the user. This is a recommendation for a dialogue that could be presented if list-header smart mail-agent app wants to notify the user. This is not text for the subject line. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 15 Apr 1997 19:15:34 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: list-address field >At 10:57 AM -0800 4/15/97, Clarence C. Wong wrote: >>> "Do you want to send the unsubscription command 'unsubscribe >>> somelist' to 'somelist-request@some.host.com'? >>> Sending the command will result in your removal from the >>> associated list." >> >>Thought we wanted to hide this kind of information from the user. > >This is a recommendation for a dialogue that could be presented if >list-header smart mail-agent app wants to notify the user. This is not text >for the subject line. > I know. Maybe I didn't make myself clear. One of my points is that the MUA doesn't know where the command is. It could be in the subject or the body, or even in another header field (I think SmartList looks for a specific header field, though I could be mistaken.) All the MUA knows is what kind of command it is (e.g. subscribe, unsubscribe, help) and where the list server is (e.g. somelist-request@some.host.com). Should the user care where the list server is? Should he care about what text is being sent (in the subject, body, or any other header field)? I thought we were trying to hide these details from the user. I think the user should really only be concerned with the command and the mailing list. The confirmation dialog should present that information in a clear and simple way. - -Clarence ---------------------------------------------------------------------- Date: 15 Apr 1997 19:40:25 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: list-address field > > For 'mailto' URL based commands, mail client applications should > > provide specialized feedback (such as presenting a dialog or alert), > > instead of the actual command email message, asking for command > > confirmation from the user. The feedback should identify the message > > destination and command within a more descriptive explanation. For > > example: > > > > "Do you want to send the unsubscription command 'unsubscribe > > somelist' to 'somelist-request@some.host.com'? > > Sending the command will result in your removal from the > > associated list." > > Thought we wanted to hide this kind of information from the user. (If the > user wants to see it, he reviews the outgoing message.) Some list servers > also use the subject field. So then we mention all this detailed > information, and pretty soon we have some verbiage that looks very similar > to a URL!!! Hiding what's sent from the user leads to a security problem. Suppose the message actually sent does something completely different than the header it appears it suggests? The message might not have come from the list server. It could have been faked. ---------------------------------------------------------------------- Date: 15 Apr 1997 20:35:23 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: list-address field At 7:31 PM -0400 4/15/97, Roger Fajman wrote: >Hiding what's sent from the user leads to a security problem. Suppose >the message actually sent does something completely different than the >header it appears it suggests? The message might not have come from >the list server. It could have been faked. Good point. This is why the URL specification warns against automatically queuing or sending messages. The URL should behave the same way it does now, bringing forth a sendable message. The confirmation dialog should inform the user what the intended action of this message is. Then, it is the user's responsibility to review and send/cancel the message. - -Clarence ---------------------------------------------------------------------- Date: 16 Apr 1997 00:30:19 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Function name in header value One point that I raised at the BOF was the possibility of moving the name of the function into the header value, instead of the name of the header. The advantages of this are twofold. One is that firewalls need look for only one header instead of many. If a new function is added, firewalls that look at headers don't need to be changed unless they look inside the header. The other advantage is that only one header name is defined, which may address the concern of some about defining a large number of headers. The grammar could be something like this: list-header = "List-function" ":" function-name 1*("," url) function-name = "help" / "unsubscribe" / "subscribe" / "archives" ... Or, at the cost of some additional complexity, multiple functions could be allowed in one header: list-header = "List-function" ":" function-spec *(";" function-spec) function-spec = function-name 1*("," url) function-name = "help" / "unsubscribe" / "subscribe" / "archives" ... The additional complexity is not strictly necessary, as multiple headers can be specified for multiple functions. ---------------------------------------------------------------------- Date: 16 Apr 1997 00:40:27 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > From the IETF meeting, I think there was general feeling on keeping the > draft at subscribe, unsubscribe, and help. Now, it was also felt that > coming out with another doc, after the current one is a standard, that would > encompass that doc, plus allow for enhancing mechanisms would be a good thing. > i.e. get the current one through with a minimum of fuss and then worry > about adding more. I was at the BOF and I don't remember it that way. I brought up the issue of archives and the presenter gave the argument in favor of restricting it to the three functions. I don't recall a lot of comment one way or the other from the rest of the people on that issue. No straw poll was taken. The consideration of firewalls that look of headers seems to me to be a point in favor of not dribbling them out or of using a more extensible syntax. Also, we are asking user agent and list server developers to add support for these headers. It's easier for them to do it once instead of several times. Also, user education is easier if there is a standard set of headers that encompasses most functions, as it is less likely that there will be varying levels of support in different list servers and user agents that have been deployed at different times. ---------------------------------------------------------------------- Date: 16 Apr 1997 00:46:03 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > >and the use of List-Subscribe as a priority over List-Archive > >(which I tried to respond to but didn't have a strong point). > > I stick to my point that it's the most widely used command (more people > subscribe than unsubscribe) and as such there will be much to benefit from > providing standardized access to it. But I think it's unlikely that most people will be subscribing through the use of a List-subscribe header. ---------------------------------------------------------------------- Date: 16 Apr 1997 00:52:43 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 12:40 AM -0400 4/16/97, Roger Fajman wrote: > > >and the use of List-Subscribe as a priority over List-Archive > > >(which I tried to respond to but didn't have a strong point). > > > > I stick to my point that it's the most widely used command (more people > > subscribe than unsubscribe) and as such there will be much to benefit from > > providing standardized access to it. > > But I think it's unlikely that most people will be subscribing > through the use of a List-subscribe header. I like both, but if I had to choose at this point I would take List-Post or List-Archive over List-Subscribe. I see the usefulness of them all, but I can visualize a "Post to List" button in my Eudora window or a "View List ArchivesŠ" menu item and would value either more than a "Subscribe" button. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 16 Apr 1997 01:10:51 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > > I stick to my point that it's the most widely used command (more people > > subscribe than unsubscribe) and as such there will be much to benefit from > > providing standardized access to it. > > But I think it's unlikely that most people will be subscribing > through the use of a List-subscribe header. I don't think it's very likely that someone will subscribe to a list using a List-subscribe header from a message from that list distributed to that person. However, if a List-subscribe field were defined, people would know to look there, and that would help distribute information about the list to interested parties (including, alas, spammers). I also think it would be useful to have a text/mailing-list MIME type, that contains one or more List-* fields in the body part. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 01:41:54 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > I like both, but if I had to choose at this point I would take List-Post or > List-Archive over List-Subscribe. I see the usefulness of them all, but I > can visualize a "Post to List" button in my Eudora window or a "View List > Archives" menu item and would value either more than a "Subscribe" button. I don't think there's a strong need to the number of List-* fields defined in the RFC. If some of the fields turn out to be not very useful, people won't use them as often. But as long as a List-* field appears to have reasonable utility, and as long as there's reasonable consensus about how to define a particular field, you might as well include it. IMHO, List-{Post,Subscribe,Unsubscribe,Archive,Maintainer} are all likely to fall in that category. Much beyond that, and it's probably a loss. However, I would like to know if there's interest in one more field: a List-Info field which contains a URL that, when referenced, produces an object of type text/mailing-list-info, where the latter is a complete list of List-* fields for that list. So a message from a list might contain three fields: List-Unsubscribe: List-Maintainer: List-Info: and if you look up the latter URL, you'll get back the complete set of info for that list: content-type: text/mailing-list-info [in the http response header] List-Subscribe: List-Unsubscribe: List-Maintainer: List-Info: List-Archive: List-Post: List-Description: this list discusses foos List-Spam-Policy: let's stamp out spam in our lifetime - -Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 01:49:26 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 1:24 AM -0400 4/16/97, Keith Moore wrote: > > I like both, but if I had to choose at this point I would take List-Post or > > List-Archive over List-Subscribe. I see the usefulness of them all, but I > > can visualize a "Post to List" button in my Eudora window or a "View List > > Archives" menu item and would value either more than a "Subscribe" button. > > I don't think there's a strong need to the number of List-* fields defined > in the RFC. If some of the fields turn out to be not very useful, > people won't use them as often. But as long as a List-* field appears > to have reasonable utility, and as long as there's reasonable consensus > about how to define a particular field, you might as well include it. > > IMHO, List-{Post,Subscribe,Unsubscribe,Archive,Maintainer} are all likely > to fall in that category. Much beyond that, and it's probably a loss. > > However, I would like to know if there's interest in one more field: a > List-Info field which contains a URL that, when referenced, > produces an object of type text/mailing-list-info, where the latter is > a complete list of List-* fields for that list. I like that a lot! It's a very simple meta language itself. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 16 Apr 1997 08:28:35 -0400 From: Noritoshi Demizu <(suppressed)@csl.sony.co.jp> Subject: Re: list-address field > > What happened to the list-address field? MUAs could be much more friendly > > with warnings such as: "Are you sure you want to unsubscribe from the > > "somelist@some.host.com" mailing list? You will no longer receive any posts > > to this list." > > This would probably be the same as the List-Post field. the list-address field and the list-post field seem to have different meaning. Because the list-post field seems to to control users' posting, the values of the list-address field and the list-post field will be different when the mailing list is moderated (I'm not sure this is the case) or the mailing list is only for announcement. So how about to use the list-post field only when the administrator wants to control users' posting? case 1: When the subscribers can post freely, List-Address: list-header@arpp.carleton.ca case 2: When the subscribers are not allowed to post to the list. List-Address: list-header-announce@arpp.carleton.ca List-Post: (I dont' have good idea about the format of this URL...) case 3: When the list is moderated and has another address for the moderator, List-Address: list-header-announce@arpp.carleton.ca List-Post: Of course, we can integrate these two headers by introducing some schemes like . But if the list-address field contains e-mail address only, we can use the field from scan.form of MH easily. :-) By the way, I also would like to have sequence number in list headers in addition to the name of mailing list. There are many mailng lists which modifies subject fields to insert the mailing list name and the sequence number. e.g. Subject: (list-header 200) Re: list-address field Although I think having these information in the output of "MH-scan" is very useful in many cases, modification of subject field is sometimes not convenient. So if we could have the name and the sequence number in standardized separated fields other than subject field, e.g. List-Address: list-header@arpp.carleton.ca List-Seq: 200 we'll be happy by modifying maybe the last line of our scan.form of MH like the following: (%{list-address} %{list-seq}) %{subject}%<{body}<<%{body}%> They also will be very useful when refiling mail automatically and sorting mail according to sequence numbers. Regards, Noritoshi Demizu ---------------------------------------------------------------------- Date: 16 Apr 1997 12:14:59 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 8:24 AM -0400 4/16/97, Noritoshi Demizu wrote: > case 1: When the subscribers can post freely, > List-Address: list-header@arpp.carleton.ca Or List-Post: > case 2: When the subscribers are not allowed to post to the list. > List-Address: list-header-announce@arpp.carleton.ca > List-Post: > (I dont' have good idea about the format of this URL...) In this case you just wouldn't include a List-Post header, because posting is not allowed. > case 3: When the list is moderated and has another address for the >moderator, > List-Address: list-header-announce@arpp.carleton.ca > List-Post: Or List-Post: In each of your examples, I don't see why the extra List-Address field is necessary or useful. What would it be used for? What information is there which isn't in other, more appropriate places? Further, what address should List-Address point to? It's not clear, (posting address, control address, some other?) while the List-Post content is extremely clear. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 16 Apr 1997 12:35:03 -0400 From: (suppressed)@akimbo.com Subject: Re: list-address field >> "Do you want to send the unsubscription command 'unsubscribe >> somelist' to 'somelist-request@some.host.com'? >> Sending the command will result in your removal from the >> associated list." One reason for a message in this form is for security reasons. For example, suppose some evil spammer puts the header List-Unsubscribe: A message like "Do you want to send the unsubscription command 'death threat' to 'someone@hate.mail'? Sending the command will result in your removal from the associated list." We hope the user might realize that the second sentence and the first sentence say very different things and cancel. --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 16 Apr 1997 13:14:03 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Plain text in header fields (was: List-Post) At 1:11 AM -0400 97/4/13, BruceLeban@akimbo.com wrote: >One recent thought I had about the headers is that we should define a >format for message text instead of a URL. This is useful for List-Post in >particular: I've produced an initial description of the inclusion of plain text items in the List- header fields. I've added this to http://arpp.carleton.ca/listspec/header-fields.html#UseOfPlainText Use of Plain Text Header fields could be used to provide a plain text message to users. For example, a list which does not allow posting (announcements only) might use the List-Post header field with a plain text message stating "You cannot post to this list. It is only for announcements." instead of providing a mailto URL for an address to post to. Plain text will be identified in the List- header fields by enclosing it in double-quotes: "plain text". No special encoding is required except that used by the mail transport mechanism (e.g., Quoted Printable). This method presents problems in terms of multi-lingual support and non-standard messages. Formal specification of list attributes may be a more appropriate method of identifying restrictions and features of mailing lists (as currently proposed in the form of the List-Attributes header field and the List Attributes identifier meta-syntax). However, the inclusion of plain text in the List headers provides directly human-readable description without the intervention of the client application. Additionally, the allowance for plain text in the header fields would provide greater flexibility for describing specific conditions of a mailing list that may not be covered through formal list attribute identification. It may also be useful to combine plain text with the use of meta-syntax (currently URLs) in the header fields. A possible example of this could be: List-Post: "Post only through the web form" Client applications may want to display the plain text to the user in the form of a dialog or alert when the user initiates the associated action. For example, a no-posting list might have the header: List-Post: "No posting on this list - announcements only." So that when the user clicks on the "Post to List" button (or whatever), the client application pops up an alert like: Cannot post to this list: "No posting on this list - announcements only." - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:14:20 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: How many (which) headers? (was: general report) At 12:35 AM -0400 97/4/16, Roger Fajman wrote: >The consideration of firewalls that look of headers seems to me to be a >point in favor of not dribbling them out or of using a more extensible >syntax. Also, we are asking user agent and list server developers to >add support for these headers. It's easier for them to do it once >instead of several times. Also, user education is easier if there is a >standard set of headers that encompasses most functions, as it is less >likely that there will be varying levels of support in different list >servers and user agents that have been deployed at different times. At 1:24 AM -0400 97/4/16, Keith Moore wrote: >If some of the fields turn out to be not very useful, >people won't use them as often. But as long as a List-* field appears >to have reasonable utility, and as long as there's reasonable consensus >about how to define a particular field, you might as well include it. Good points. Hmmm, maybe we need to reconsider the decision to restrict the initial effort to just the core functions. The reasons I see for keeping it to just the 3 are as follows: - - Fewer headers means we're less likely to run into "header bloat" objections. Basically, trying to be as inoffensive as possible to improve our chances of making it through the standards process. - - Minimize the use of headers (avoid bloat) and focus further efforts on things like the MIME part, footers, specialized messages, etc. Some people have asked: why not just skip headers altogether and just work on the more comprehensive and flexible alternatives? - - Various headers of this type are already in use (X-URL, X-Unsubscribe, etc.) so let's standardize them so they can be useful to client applications. - - Header support is relativly easy to implement. - - Headers don't pose the problems that things like MIME parts do. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:14:37 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: List Details MIME part (was: general report) At 1:24 AM -0400 97/4/16, Keith Moore wrote: >However, I would like to know if there's interest in one more field: a >List-Info field which contains a URL that, when referenced, >produces an object of type text/mailing-list-info, where the latter is >a complete list of List-* fields for that list. I've written up a description of this (using the example Keith provided) at: http://arpp.carleton.ca/listspec/mime-part.html - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:16:16 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: s-ubscribe vs. the rest (was: general report) At 12:40 AM -0400 4/16/97, Roger Fajman wrote: ... > But I think it's unlikely that most people will be subscribing > through the use of a List-subscribe header. At 12:49 AM -0400 97/4/16, Joshua D. Baer wrote: >I like both, but if I had to choose at this point I would take List-Post or >List-Archive over List-Subscribe. I see the usefulness of them all, but I >can visualize a "Post to List" button in my Eudora window or a "View List >ArchivesŠ" menu item and would value either more than a "Subscribe" button. Does anyone else agree with me about the importance of including subscribe? Or, am I just so enamoured of my own ideas that I'm ignoring reality? I've ranted (note that Grant without the 'g' is rant ;-) many times before about including subscribe. By sheer virtue of it being the most used list command I think the inclusion of subscribe is very valuable. Personally, I would rank the importance/usefulness of the commands as follows: unsubscribe, help, subscribe, switch to digest, access archives, post to the list, switch from digest to individual messages, contact human admin. I'm not sure where identifying the list name and address fits in to this - but including them would be useful. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:23:36 -0400 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: s-ubscribe vs. the rest (was: general report) At 1:15 PM -0400 4/16/97, Rant Neufeld wrote: >Does anyone else agree with me about the importance of including subscribe? >Or, am I just so enamoured of my own ideas that I'm ignoring reality? I agree! People will pass around subscription messages. Invitations using the subscribe header can be sent to your friends. Who says only the list software can make the header? Rob ______________________________________________________ Within Technology, Inc. people process technology Collaborative Technology........Design and Consulting ______________________________________________________ web: http://www.within.com/ phone: +1 412 852-2599 fax: +1 412 852-2435 ______________________________________________________ ---------------------------------------------------------------------- Date: 16 Apr 1997 13:38:07 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: disclosing to the user (was: list-address field) At 2:57 PM -0400 97/4/15, Clarence C. Wong wrote: >The new draft (01) suggests the following guideline for user feedback: > >> For 'mailto' URL based commands, mail client applications should >> provide specialized feedback (such as presenting a dialog or alert), >> instead of the actual command email message, asking for command >> confirmation from the user. The feedback should identify the message >> destination and command within a more descriptive explanation. ... >Thought we wanted to hide this kind of information from the user. (If the >user wants to see it, he reviews the outgoing message.) Some list servers >also use the subject field. So then we mention all this detailed >information, and pretty soon we have some verbiage that looks very similar >to a URL!!! I disagree. If you have the field: List-Unsubscribe: I would recommend an alert message like: Are you sure you want to send a message with the unsubscribe request "unsubscribe somelist" to <(suppressed)@server.com>? It's much more 'human readable', but still discloses the action being taken. It's crucial (for security reasons) that the details be disclosed to the user _every_ time they issue such a command. Imagine if some spam-brained person rigged a message with the header field: List-help: I think it's preferable (although not required) to display a clearly worded alert rather than the mail message because an alert can provide additional context for the user. However, it's important that the user always be able to access the actual message prior to it being sent. At 7:11 PM -0400 97/4/15, Clarence C. Wong wrote: > One of my points is that the MUA >doesn't know where the command is. Yes it does. ^^^^^^^ The whole point of this is to let the MUA know where to send the command (list@foo.bar), what the the command is (help), and where to put the command (Subject). >Should the user care where the list server is? Should he care about what >text is being sent (in the subject, body, or any other header field)? I >thought we were trying to hide these details from the user. Not necessarily. The most important thing we're trying to do is make it so the user can access commands without having to remember or correctly type the details. This doesn't mean we have to hide the details from them. >I think the user should really only be concerned with the command and the >mailing list. The confirmation dialog should present that information in a >clear and simple way. I think they need to see the command address and the actual text of the command, for security reasons. In an ideal and friendly world (spam-free) we'd be able to hide the details and just say "Do you want to unsubscribe from SomeList?" At 8:28 PM -0400 97/4/15, Clarence C. Wong wrote: >The URL should behave the same way it does >now, bringing forth a sendable message. The confirmation dialog should >inform the user what the intended action of this message is. Then, it is >the user's responsibility to review and send/cancel the message. That's a reasonable alternative. Display an alert/dialog describing the intended action "Do you want to subscribe to SomeList <(suppressed)@server.com>? You will begin receiving messages from the list in your email (possibly a large number of messages)." Then, once the user has confirmed it, bring up the actual message constructed from the URL for review. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 13:38:35 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: list-address field At 8:24 AM -0400 97/4/16, Noritoshi Demizu wrote: >the list-address field and the list-post field seem to have different >meaning. Because the list-post field seems to to control users' posting, >the values of the list-address field and the list-post field will be >different when the mailing list is moderated (I'm not sure this is the >case) or the mailing list is only for announcement. That's basically it. >So how about to use the list-post field only when the administrator >wants to control users' posting? I think that only List-Post should describe where postings should be sent. So if a list is moderated, the List-Post may differ from the List-Address. And if the list does not take postings, List-Post may just be a plaintext message stating that it doesn't take posts. List-Address is really just an informational field and should be the address of the list itself (regardless of where posts and commands go) and perhaps the name of the list. E.g., List-Address: somelist@server.com "Some Mailing List" So we have: > case 1: When the subscribers can post freely, List-Address: list-header@arpp.carleton.ca "List Headers Working Group" List-Post: > case 2: When the subscribers are not allowed to post to the list. List-Address: list-header-announce@arpp.carleton.ca List-Post: "This is an announcements only list - no postings." > case 3: When the list is moderated and has another address for the moderator, List-Address: list-header@arpp.carleton.ca List-Post: At 8:24 AM -0400 97/4/16, Noritoshi Demizu wrote: >Of course, we can integrate these two headers by introducing some >schemes like . Nah. Let's keep them separate because they can have different meanings. >But if the >list-address field contains e-mail address only, we can use the field >from scan.form of MH easily. :-) What's MH? >By the way, I also would like to have sequence number in list headers >in addition to the name of mailing list. ... > List-Seq: 200 ... >They also will be very useful when refiling mail automatically and >sorting mail according to sequence numbers. Seems reasonable to standardize that info. I've added it: http://arpp.carleton.ca/listspec/header-fields.html#List-Sequence - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 16 Apr 1997 15:45:16 -0400 From: Marc Horowitz <(suppressed)@cygnus.com> Subject: Re: general report Keith Moore <(suppressed)@cs.utk.edu> writes: >> However, I would like to know if there's interest in one more field: a >> List-Info field which contains a URL that, when referenced, >> produces an object of type text/mailing-list-info, where the latter is >> a complete list of List-* fields for that list. I'm not sure text is an appropriate type. Quoting rfc2046: (1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched". Although the list-* headers are basically human-parsable, I don't think they are within the spirit of this media type. So, which should it be? image, audio, and video are clearly wrong. application also seems wrong (this implies "not directly readable"). I would suggest that additional headers be presented something like this: multipart/separate-list-headers part 1: whatever the body is part 2: message/list-headers, or message/rfc822 The message/list-headers part would contain additional headers (not sure if these "headers" should be in the header or body section of the part). If the complete list is external, use message/external-body to point elsewhere. This scheme is somewhat analagous to multipart/signed and multipart/encrypted. As usual, intelligent mime readers can present this in a more user-friendly fashion. This is a straw-man brainstorm I just came up with, so feel free to rip it to shreds :-) Marc ---------------------------------------------------------------------- Date: 16 Apr 1997 16:46:19 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > I'm not sure text is an appropriate type. Quoting rfc2046: > > Although the list-* headers are basically human-parsable, I don't > think they are within the spirit of this media type. It could either be text/ or application/. Bottom line: If you want user agents that don't "understand" foo/mailing-list-info to display such a file as text, you want it to be a subtype of text. If you don't want them to display the file, you want the content-type to be a subtype of application. > I would suggest > that additional headers be presented something like this: > > multipart/separate-list-headers > part 1: whatever the body is > part 2: message/list-headers, or message/rfc822 It's certainly possible, but I wouldn't want to use this on a regular basis. The whole idea is to provide minimum list information in the message header (where the recipient's UA can easily get to it) along with a simple means of obtaining additional information about the list in a structured form. A URL pointing to a web server that returns the foo/mailing-list-info type seems like a good way to acheive that. You of course could do multipart/whatever and have the second part be a message/external-body that points to a message/list-headers. But that's a lot of baggage with little more functionality than a simple List-Info header and URL. And MUAs are already accustomed to looking in message headers to figure out how to do things like replies. Should they now have to look everywhere in the message body? let's keep it simple. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 17:13:53 -0400 From: Marc Horowitz <(suppressed)@cygnus.com> Subject: Re: general report Keith Moore <(suppressed)@cs.utk.edu> writes: >> > I would suggest >> > that additional headers be presented something like this: >> > >> > multipart/separate-list-headers >> > part 1: whatever the body is >> > part 2: message/list-headers, or message/rfc822 >> >> It's certainly possible, but I wouldn't want to use this on a regular >> basis. The whole idea is to provide minimum list information in the >> message header (where the recipient's UA can easily get to it) along >> with a simple means of obtaining additional information about the list >> in a structured form. A URL pointing to a web server that returns the >> foo/mailing-list-info type seems like a good way to acheive that. >> >> You of course could do multipart/whatever and have the second part be >> a message/external-body that points to a message/list-headers. But >> that's a lot of baggage with little more functionality than a simple >> List-Info header and URL. And MUAs are already accustomed to looking >> in message headers to figure out how to do things like replies. >> Should they now have to look everywhere in the message body? >> >> let's keep it simple. Clarification: I wouldn't suggest that a second body part always be used; that would be complex and inefficient. In the simple case, toss a header or two in the message headers, and be done with it. That's simple. However, when something more complex is desired, MIME already provides a mechanism for telling the MUA to look somewhere else for something. I'd rather not see us define a new standard which uses the rather ad-hoc technique of a url in a header. The generic MIME mechanism is a little bulky, yes, but as readers get more intelligent, and hide this from the user, it won't matter. I guess I have a question of intent here: do you expect that a MUA would follow a list-info url automagically to get the extra headers, or that it would only be done at the request of the user? If the former, I think a MIME structure is preferred; if the latter, a url in a message is ok, since the url could also point to a page with forms, buttons, and other information and structure to help the user along. The argument about MUA's having "to look everywhere in the message body" is a red herring; they only need to look in parts of the appropriate type, which is trivial given what a MIME reader has to do already. Also, procedurally, I don't think any of this (Keith's proposal, mine, or some alternative) should delay the initial draft. It can all be done as follow-up work. Marc ---------------------------------------------------------------------- Date: 16 Apr 1997 17:44:18 -0400 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: Plain text in header fields (was: List-Post) At 6:11 pm 16/4/97, Grant Neufeld wrote: >Plain text will be identified in the List- header fields by enclosing it in >double-quotes: "plain text". No special encoding is required except that >used by the mail transport mechanism (e.g., Quoted Printable). Why reinvent the wheel? rfc822 (p.14) states that text within parentheses () is a comment. So we get: List-Post: (Post only through the web form) List-Post: (No posting on this list - announcements only.) ( :-]) James ---------------------------------------------------------------------- Date: 16 Apr 1997 17:54:39 -0400 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: Plain text in header fields (was: List-Post) >>>>> "JB" == James Berriman <(suppressed)@frutiger.staffs.ac.uk> writes: JB> Why reinvent the wheel? rfc822 (p.14) states that text within JB> parentheses () is a comment. Well, if you want to take that route, everything outside of <> (excepting certain quoting rules) is a comment. JB> List-Post: (Post only through the web form) Just as easily List-Post: Post only through the web form (strict RFC822 compliance requires the route address to come after the comment, though this is kind of a grey area). This reads well, too. - -- Jason L. Tibbitts III - tibbs@uh.edu - 713/743-8684 - 221SR1 System Manager: University of Houston High Performance Computing Center 1994 PC800 "Kuroneko" DoD# 1723 ---------------------------------------------------------------------- Date: 16 Apr 1997 17:59:31 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > Clarification: I wouldn't suggest that a second body part always be > used; that would be complex and inefficient. In the simple case, toss > a header or two in the message headers, and be done with it. That's > simple. However, when something more complex is desired, MIME already > provides a mechanism for telling the MUA to look somewhere else for > something. I'd rather not see us define a new standard which uses the > rather ad-hoc technique of a url in a header. The two aren't mutally exclusive, and to my mind, they have subtly different semantics. The presense of a a List-* header field in a message says something about the message itself -- that it came via a list with certain characteristics. And you can find more information about *the list the message came from* by following the List-Info link. On the other hand, the presense of a foo/mailing-list-info MIME body part in a message doesn't say anything about where the message came from -- it simply provides information about a mailing list. The recipient's UA should never assume that a foo/mailing-list-info attachment means that the message came from a list, or that the attachment refers to the list that the message came from. For example, someone might send mail to the list-managers list, telling them about the list-header list. The message received by subscribers to the list-managers list would contain List-* headers describing the list-managers list. However, the message could also have a foo/mailing-list-info attachment describing the list-header list, to make it easy for people on the list-managers list to subscribe to the list-header list, should they choose to do so. Of course, a single multipart message could contain any number of foo/mailing-list-info body parts. > I guess I have a question of intent here: do you expect that a MUA > would follow a list-info url automagically to get the extra headers, > or that it would only be done at the request of the user? I certainly wouldn't use an MUA that referenced a remote List-Info URL for me every time I read a message from a list. And I think the very common list functions like unsubscribe should always go in the message header rather than being indirected through List-Info. So no, I don't really expect UAs to follow that link automagically. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 19:22:25 -0400 From: (suppressed)@akimbo.com Subject: Re: list-address field >From: josh@skyweyr.com (Joshua D. Baer) >> List-Post: >> (I dont' have good idea about the format of this URL...) > >In this case you just wouldn't include a List-Post header, because posting >is not allowed. I agree with the other comments about why a separate List-Address isn't necessary (given that we've recognized that the Sender header identifies the name of the list). However, the above statement won't work. Right now List-Post isn't even in the proposed core standard so not having a List-Post certainly can't mean posting is not allowed. That's why I previously suggested recognizing List-Post: "message" to mean posting is not allowed. Having syntax in the headers that specifically means a feature is not available is useful and I'm not sure about whether it's a good idea to invent alert: URLs. I suppose alert messages might be useful in other contexts where URLs are normally used, but it is a little weird. --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 16 Apr 1997 20:56:10 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: Plain text in header fields (was: List-Post) At 01:11 PM 4/16/97 -0400, Grant Neufeld wrote: [snip] >Use of Plain Text [snip] >It may also be useful to combine plain text with the use of meta-syntax >(currently URLs) in the header fields. A possible example of this could be: > List-Post: "Post only through the web form" *HORRIBLE* example!!! Please don't encourage this, even by example. Mailing lists are an email medium. WWW is something else. I can download my email, read it at my leisure, reply to it, and then upload. I can't do that with the WWW, which requires tying up my phone line. Maybe you have a second phone line, or even a dedicated T1, but don't assume the rest of the world does. Please don't even suggest that a mailing list should be configured such that posts must go through a web form. YUCKKK!!! In fact, for that reason, I'd suggest that should be the "preferred" header for any of the List-* headers. Please don't lose sight of the fact this is for *email*, not *www*. Those animals function differently, have different connectivity requirements, and generally require different clients. I want to subscribe, post, read, and unsubscribe to a mailing list all from a mail client. I shouldn't need Netscape to do these things, nor should I need to be on-line when preparing any commands to the list server. One other thing I'd suggest for mail clients (while I'm here) is that they be *strongly* encouraged to permit users to add their own headers before sending those "convenient" messages. In particular, I like: Bcc: myself for such messages (and "myself" might be a different account than the one I'm actually un/subscribing from). Cheers, Stan ---------------------------------------------------------------------- Date: 16 Apr 1997 20:56:48 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: s-ubscribe vs. the rest (was: general report) At 01:15 PM 4/16/97 -0400, Grant Neufeld wrote: >At 12:40 AM -0400 4/16/97, Roger Fajman wrote: >... >> But I think it's unlikely that most people will be subscribing >> through the use of a List-subscribe header. > >At 12:49 AM -0400 97/4/16, Joshua D. Baer wrote: >>I like both, but if I had to choose at this point I would take List-Post or >>List-Archive over List-Subscribe. I see the usefulness of them all, but I >>can visualize a "Post to List" button in my Eudora window or a "View List >>ArchivesŠ" menu item and would value either more than a "Subscribe" button. > > >Does anyone else agree with me about the importance of including subscribe? >Or, am I just so enamoured of my own ideas that I'm ignoring reality? I don't want to say that you're ignoring reality, but I do think you are overestimating the utility of a subscribe function. In order to use it, you'll have to be (a) not currently subscribed; and (b) in possession of a message from the list you're not subscribed to, with full headers, and (c) want to subscribe. I don't picture this happening very often. (And I don't see any need based on "gee, I'll unsubscribe this week and re-subscribe next week." -- just keep a copy of your original sub message, or use LISTSERV where you can set yourself to NOMAIL and not actually unsubscribe.) Sure, the number of "subscribes" sent on the internet undoubtedly exceed the number of "unsubscribes" -- because mailing lists still exist. I've never been in a position where I could use a subscribe header, but I've often found myself digging around in folders for the place and syntax to send commands *to lists to which I'm already subscribed* -- and I think these are by far the more important functions. I'm not sure that "Post to List" buys much either, except to override a list owner's choice that default replies should go to the sender rather than the list. Hopefully, MLM software which implements that will allow individual list owners to be able to *not* include it. [snip] >I'm not sure where identifying the list name and address fits in to this - >but including them would be useful. It would be nice to have a "standard" header that one could do mail filtering on to uniquely identify a list...at present, the various types of lists I'm on require various tricks (and I still occasionally wind up with a stray post in the inbox when, say, a list has been Bcc'd.) This would be much more useful to me than any "subscribe" header (though if the "subscribe" header were predictable, I could filter on *that*! ) Cheers, Stan ---------------------------------------------------------------------- Date: 16 Apr 1997 20:58:56 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > However, I would like to know if there's interest in one more field: a > List-Info field which contains a URL that, when referenced, > produces an object of type text/mailing-list-info, where the latter is > a complete list of List-* fields for that list. > > So a message from a list might contain three fields: > > List-Unsubscribe: > List-Maintainer: > List-Info: > > and if you look up the latter URL, you'll get back the complete > set of info for that list: > > content-type: text/mailing-list-info [in the http response header] > > List-Subscribe: > List-Unsubscribe: > List-Maintainer: > List-Info: > List-Archive: > > List-Post: > List-Description: this list discusses foos > List-Spam-Policy: let's stamp out spam in our lifetime > > -Keith Sounds like a reasonable idea to me if the user agent developers don't mind the additional complexity. But then I wonder about why there is a need for both ways of doing it if all can be represented with List-info? We usually prefer having one way of doing something instead of two. P.S. - By analogy with the second part of the multipart/report content type, the MIME type for List-info could be message/mailing-list-info. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:07:29 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: How many (which) headers? (was: general report) > The reasons I see for keeping it to just the 3 are as follows: > > - Fewer headers means we're less likely to run into "header bloat" > objections. Basically, trying to be as inoffensive as possible to improve > our chances of making it through the standards process. I remember the discussion about "header bloat" going on, but I've forgotten what the main objection was. Was it the amount that the List-* headers would increase the size of the header section of the average message to a mailing list? Or was it the number of different headers being defined? The List-info proposal addresses the former objection (size of the headers) and the List-function proposal I made yesterday addresses the latter objection (number of different headers). Also, by being overly concerned about one possible objection (header bloat) you may open yourself to objections about inadequate functionality (also expressed here). > Some people have asked: why not just skip headers altogether and just work > on the more comprehensive and flexible alternatives? > > - Various headers of this type are already in use (X-URL, X-Unsubscribe, > etc.) so let's standardize them so they can be useful to client > applications. > > - Header support is relativly easy to implement. > > - Headers don't pose the problems that things like MIME parts do. I like the header proposal better than the MIME part in every message proposal. It's more straightforward and has much less adverse effect on users whose user agents lack support for the feature. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:11:27 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: s-ubscribe vs. the rest (was: general report) > Does anyone else agree with me about the importance of including subscribe? > Or, am I just so enamoured of my own ideas that I'm ignoring reality? I think subscribe is useful. It's just that I disagree with including it while excluding other functions that, in my opinion, will be more useful to the ordinary user. So I just order the list differently that you do. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:18:07 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > The presense of a a List-* header field in a message says something > about the message itself -- that it came via a list with certain > characteristics. And you can find more information about *the list > the message came from* by following the List-Info link. > > On the other hand, the presense of a foo/mailing-list-info MIME body > part in a message doesn't say anything about where the message came > from -- it simply provides information about a mailing list. The > recipient's UA should never assume that a foo/mailing-list-info > attachment means that the message came from a list, or that the > attachment refers to the list that the message came from. This makes a lot of sense to me. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:18:34 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: Plain text in header fields (was: List-Post) > >Plain text will be identified in the List- header fields by enclosing it in > >double-quotes: "plain text". No special encoding is required except that > >used by the mail transport mechanism (e.g., Quoted Printable). > > Why reinvent the wheel? rfc822 (p.14) states that text within parentheses > () is a comment. Comments are to be discarded without other processing. The point of the quoted string is to provide text that can be displayed to the user. I think it's a good idea. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:22:21 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: list-address field > I agree with the other comments about why a separate List-Address isn't > necessary (given that we've recognized that the Sender header identifies > the name of the list). The Sender header doesn't always identify the name of the list. Some list servers set Sender to the address of the list owner. This is arguably more conformant to the definition of Sender in RFC 822. > Having syntax in the headers that specifically means a feature is not > available is useful and I'm not sure about whether it's a good idea to > invent alert: URLs. I suppose alert messages might be useful in other > contexts where URLs are normally used, but it is a little weird. I do remember seeing a proposal for a URL for constant text. But it's probably just an Internet Draft at this point. ---------------------------------------------------------------------- Date: 16 Apr 1997 21:51:47 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Plain text in header fields (was: List-Post) At 2:40 PM -0700 4/16/97, James Berriman wrote: >Why reinvent the wheel? rfc822 (p.14) states that text within parentheses >() is a comment. > >So we get: > >List-Post: (Post only through the web form) > >List-Post: (No posting on this list - announcements only.) I like this idea -- should work with existing apps as well. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 16 Apr 1997 22:26:04 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: s-ubscribe vs. the rest (was: general report) > People will pass around subscription messages. Invitations using the > subscribe header can be sent to your friends. Who says only the list > software can make the header? no, we don't want to encourage people to send list-subscribe headers to each other in messages that aren't from the list. of course people want to send subscription information to their friends. that's what the foo/mailing-list-info MIME type is for. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 22:35:19 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Plain text in header fields (was: List-Post) > JB> Why reinvent the wheel? rfc822 (p.14) states that text within > JB> parentheses () is a comment. > > Well, if you want to take that route, everything outside of <> (excepting > certain quoting rules) is a comment. Actually, no. The stuff before a bracketed address in a To, From, Cc, whatever field is a 'phrase'. Phrases are part of the message content, and actually have meaning, and can be interpreted by mail reading software. For instance, the phrase preceding an address is supposed to be the name asociated with that address. There are also grammatical constraints on a phrase. Comments, on the other hand, are almost completely arbitrary, and are not intended to be interpreted by mail reading software. It's a subtle distinction, and RFC 822 doesn't explain it very clearly, but that's what's intended. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 22:58:59 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > > I agree with the other comments about why a separate List-Address isn't > > necessary (given that we've recognized that the Sender header identifies > > the name of the list). > > The Sender header doesn't always identify the name of the list. > Some list servers set Sender to the address of the list owner. > This is arguably more conformant to the definition of Sender > in RFC 822. Both practices are also arguably completely against the intent of Sender. Widespread practice to the contrary, it's nearly always inappropriate for lists to supply a Sender field. (The exception that comes to mind is a message digest, and perhaps a moderated list.) Sender is supposed to be the identity of the "AGENT (person, system, or process) that sends the message", as distinct from the From field, which is defined as the "person(s) who wished the message to be sent". The distinction is subtle but important. The examples of Sender in RFC 822 are of messages sent by the Sender *on behalf of* the address(es) in the From field. (one sent by a secretary for his boss, another sent by one member of a group on behalf of the entire group). Another clue to the function of Sender is in the last paragraph of 4.4.2 of RFC 822: Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer pro- gram generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mail- box specification. That is, part of the purpose of Sender is to identify who is *responsible* for sending the message. A third clue is the use of the word "authentic" in the RFC 822 grammar, revealing the intent that the From/Sender fields be "authenticated" to ensure that either the From field correctly identifies the originator, or that the Sender field is present and identifes the originator. For a list that automatically forwards mail to its members, the original submitter of the message, not the list maintainer, bears responsibility for the message. Under most circumstances, the list should NOT discard this information nor hide it from the list recipients. If someone spams a list, they're trespassing on a community, and the list members (the members of the community being spammed) have a right to know who is doing it. Of course, some lists want to support anonymous posting, and those lists will want to hide the Sender field. But unless the list owner is accepting responsibility for material sent to the list (as might be the case in a moderated list), putting the address of the list owner in the Sender field is inconsistent with the purpose of that field. Note that while it's currently easy to forge SMTP messages and thus the Sender field, this can be expected to change. The trend is for SMTP servers to refuse to relay mail that didn't originate locally and isn't for local recipients. There is also increased interest in SMTP authentication and in a special protocol for message submission. All of these will help make the Sender field more reliable. Keith p.s. my suggestion for the list-header effort is: Don't assume any interpretation for Sender or any other part of RFC 822 - that's clearly within the scope of the IETF DRUMS working group, and not within the purview of any other group or document. If you decide you need a header field that identifies the owner or maintainer of a list, define a new field for that purpose. ---------------------------------------------------------------------- Date: 16 Apr 1997 23:06:08 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > Sounds like a reasonable idea to me if the user agent developers don't > mind the additional complexity. But then I wonder about why there is a > need for both ways of doing it if all can be represented with > List-info? We usually prefer having one way of doing something instead > of two. Two things: 1. If the only List-* header field which appears in a message is List-Info, the UA then has to be able to fetch web pages in order to implement an Unsubscribe button. Seems like too much overhead to me. Also, not everyone who reads mail has an on-demand net connection. I'd like for people to be able to compose an unsubscribe message and queue it for later delivery (say from their laptop or their handheld personal organizer), without having to first download a web page. 2. You can think of the List-* message headers as a preloaded cache of the most frequently used fields from the foo/mailing-list-info description of the mailing list. Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 23:19:22 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Plain text in header fields (was: List-Post) > Plain text will be identified in the List- header fields by enclosing it in > double-quotes: "plain text". No special encoding is required except that > used by the mail transport mechanism (e.g., Quoted Printable). 1. Quoted-printable is not, in general, used by the mail transport mechanism. Though it is designed to overcome limitations of mail transports, quoted-printable (and other content-transfer-encodings) are intended to be applied by the sender's user agent, and decoded by the recipient's user agent. 2. Quoted-printable encoding does not apply to message headers, only to the contents of messages and body parts. 3. Any proposal to include human readable text that doesn't support I18N will get soundly trounced. And if you want to include something besides ASCII-only text in a List-* field, you need to use RFC 2047 to do this. As RFC 2047's encoded-words are not valid within quoted-strings, you need some other way than quotes to distinguish human readable text. Given that you can just use comments, I'm not sure it's worth the trouble to define a separate mechanism. Also, for List-Post: I think it would be worthwhile to have a special convention that says "you cannot post to the list" rather than trying to include it in a comment. Perhaps this could be indicated by an empty List-Post: field (with no field-body), or by a special keyword, e.g.: List-Post: forbidden Keith ---------------------------------------------------------------------- Date: 16 Apr 1997 23:51:05 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: disclosing to the user (was: list-address field) At 1:37 PM -0400 4/16/97, Grant Neufeld wrote: >At 7:11 PM -0400 97/4/15, Clarence C. Wong wrote: >> One of my points is that the MUA >>doesn't know where the command is. > >Yes it does. > ^^^^^^^ >The whole point of this is to let the MUA know where to send the command >(list@foo.bar), what the the command is (help), and where to put the >command (Subject). > This is rare, but some MLMs use more than one field: From: cwong To: mail-list-admin Subject: somelist subscribe cwong We use such a syntax at Qualcomm (I don't necessarily think it's elegant, but we started out with it a couple years ago and we're stuck with it.) What would the dialog say in this case? ---------------------------------------------------------------------- Date: 17 Apr 1997 00:05:22 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: s-ubscribe vs. the rest (was: general report) At 8:53 PM -0400 4/16/97, Stan Ryckman wrote: >>I'm not sure where identifying the list name and address fits in to this - >>but including them would be useful. > >It would be nice to have a "standard" header that one could do mail >filtering on to uniquely identify a list...at present, the various >types of lists I'm on require various tricks (and I still occasionally >wind up with a stray post in the inbox when, say, a list has been Bcc'd.) >This would be much more useful to me than any "subscribe" header (though >if the "subscribe" header were predictable, I could filter on *that*! ) > This is a very good point. Whenever I subscribe to a list, I create a new mailbox and filter. If the MUA knew the list address, it could automatically do this for the user. The MUA could offer this option within the subscription dialog box. MUAs could also use the list address field to keep track of what lists the user has subscribed to/unsubscribed from; useful for those who are on many lists and subscribe/unsubscribe from them frequently. - -Clarence ---------------------------------------------------------------------- Date: 17 Apr 1997 00:27:22 -0400 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: Plain text in header fields (was: List-Post) >>>>> "KM" == Keith Moore <(suppressed)@cs.utk.edu> writes: KM> Actually, no. The stuff before a bracketed address in a To, From, Cc, KM> whatever field is a 'phrase'. Yes, of course. (I'm painfully aware of the vagaries of RFC822 address syntax.) Actually, the constraints the grammar places on the phrase (especially on periods) probably make it less useful if one intends to follow the constraints of RFC822 when it comes to the non-URL portion of the header. I suppose this really goes to show that trying to mimic RFC822 isn't really a good idea, unless you try to mimic all of the warts as well. That would be pretty much pointless. Doesn't the URL syntax have provisions for textual comments? Is it necessary to come up with a hybrid of two (confusing) standards for this? - J< ---------------------------------------------------------------------- Date: 17 Apr 1997 01:36:18 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: general report > 2. You can think of the List-* message headers as a preloaded cache of > the most frequently used fields from the foo/mailing-list-info > description of the mailing list. > > Keith But if some UAs can't handle List-info, then there's this possibility of inconsistent behavior that has to be explained to users. That's not a good thing, in my opinion. ---------------------------------------------------------------------- Date: 17 Apr 1997 01:40:14 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: Plain text in header fields (was: List-Post) > 3. Any proposal to include human readable text that doesn't support > I18N will get soundly trounced. And if you want to include something > besides ASCII-only text in a List-* field, you need to use RFC 2047 to > do this. As RFC 2047's encoded-words are not valid within > quoted-strings, you need some other way than quotes to distinguish > human readable text. For those who aren't up on the latest shorthand, I18N stands for "internationalization", meaning making Internet protocols friendly to languages other than English. > Given that you can just use comments, I'm not sure it's worth the > trouble to define a separate mechanism. But in other contexts we've been saying that comments should not be processed in any way except to be passed over. > Also, for List-Post: I think it would be worthwhile to have a special > convention that says "you cannot post to the list" rather than trying > to include it in a comment. Perhaps this could be indicated by an > empty List-Post: field (with no field-body), or by a special keyword, > e.g.: > > List-Post: forbidden > > Keith I like this idea, but had hestitated to suggest it before because it seems to add a little more complexity. A word like "unavailable" might be better because it could be used with other List-* headers. ---------------------------------------------------------------------- Date: 17 Apr 1997 01:52:33 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > But if some UAs can't handle List-info, then there's this possibility > of inconsistent behavior that has to be explained to users. That's > not a good thing, in my opinion. we already have some UAs with built-in web browsers and some without. some UAs recognize embedded URLs in messages, some don't. it's not something we can control. Though I am wary of using mailto: URLs when ordinary email addresses will do. If an email address is the only thing that can reasonably go in a List-* field, it should be an email address, not a mailto: URL. Keith ---------------------------------------------------------------------- Date: 17 Apr 1997 02:13:59 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: list-address field At 10:55 PM 4/16/97 -0400, Keith Moore wrote: >> > I agree with the other comments about why a separate List-Address isn't >> > necessary (given that we've recognized that the Sender header identifies >> > the name of the list). >> >> The Sender header doesn't always identify the name of the list. >> Some list servers set Sender to the address of the list owner. >> This is arguably more conformant to the definition of Sender >> in RFC 822. > >Both practices are also arguably completely against the intent of >Sender. > >Widespread practice to the contrary, it's nearly always inappropriate >for lists to supply a Sender field. (The exception that comes to mind >is a message digest, and perhaps a moderated list.) > >Sender is supposed to be the identity of the "AGENT (person, system, >or process) that sends the message", as distinct from the From field, >which is defined as the "person(s) who wished the message to be sent". >The distinction is subtle but important. The examples of Sender in >RFC 822 are of messages sent by the Sender *on behalf of* the >address(es) in the From field. (one sent by a secretary for his boss, >another sent by one member of a group on behalf of the entire group). I think you're partially correct here. My interpretation is that "Resent-Sender:" is the header that *ought* to be used; one list I'm on does this. It also uses "Resent-Date:", "Resent-Message-Id:", etc. and preserves all the originals. Keep in mind, though, that as I send this, the list *IS* my AGENT in distributing this mail to all of you; it's a system or process indeed distinct from "From:" which does identify me, the person who wished this message to be sent. That program is indeed acting *on behalf of* me when I send this to it. Unfortunately, RFC 822 doesn't stand by itself; some of the examples are broken (e.g., dates); some things it talks about fail in most common implementations (multiple addresses in Reply-To:); some have been replaced by later RFC's (date formats again)... it sure would be nice to have a rewrite of the whole thing, fixed and updated. RFC 822 also seems to have been written in complete ignorance of the concept of mailing lists as we know them today (although maybe such things didn't exist in 1982... I dunno). That's the *real* problem, I think... examples of sending for someone else are of the type of a secretary sending for the boss, and not of a mailing list resending mail to thousands of subscribers. (And I don't even want to get into the problem here of what the heck you're supposed to do with the "Resent-xxxx" headers if mail is resent more than once, but I think the RFC's ought to.) >Another clue to the function of Sender is in the last paragraph of >4.4.2 of RFC 822: > > Since the critical function served by the "Sender" field is > identification of the agent responsible for sending mail and > since computer programs cannot be held accountable for their > behavior, it is strongly recommended that when a computer pro- > gram generates a message, the HUMAN who is responsible for > that program be referenced as part of the "Sender" field mail- > box specification. > >That is, part of the purpose of Sender is to identify who is >*responsible* for sending the message. I think this is OK... what this means to me is that bounces need to wind up in the "correct" place. This does *NOT* mean that the Sender: is responsible for the content, just for the sending action, and needs to be the person to handle errors in the delivery process should they occur. They (bounces) should *NOT* go to the From: address, but rather to the (Resent-)Sender: address. It does not matter if this is called "owner-listname@wherever.com". This does generally identify a human, whose identity may change even though the address remains constant. I read that paragraph as saying basically, "mail loops are bad things... it should go to Sender and stay there." >A third clue is the use of the word "authentic" in the RFC 822 >grammar, revealing the intent that the From/Sender fields be >"authenticated" to ensure that either the From field correctly >identifies the originator, or that the Sender field is present and >identifes the originator. This means little... who "authenticates?" A little loophole now being grossly exploited by spammers. >For a list that automatically forwards mail to its members, the >original submitter of the message, not the list maintainer, bears >responsibility for the message. Under most circumstances, the list >should NOT discard this information nor hide it from the list >recipients. If I had my druthers, I'd replace that "should" with "MUST". Note, LISTSERV offers subscribers the *option* of shorter headers, including the origination information being stripped, which is OK by me, but lists which do it perforce annoy me. *THIS* list is guilty of that; it fudges things so that everything appears to originate from "void.achilles.net". Check the headers. >If someone spams a list, they're trespassing on a >community, and the list members (the members of the community being >spammed) have a right to know who is doing it. Agreed. If someone spams *this* list, I'd like the header information to go after the spammer *without* having to count on the list owner doing it, even if those headers are logged somewhere. Right now, not possible. >Of course, some lists >want to support anonymous posting, and those lists will want to hide >the Sender field. But unless the list owner is accepting >responsibility for material sent to the list (as might be the case in >a moderated list), putting the address of the list owner in the Sender >field is inconsistent with the purpose of that field. I don't read it as "Sender" accepting any responsibility for content, just for collecting bounces. The RFC example of a secretary mailing for the boss would bear that out, I think. However, "Resent-Sender:" would probably be best, at least if a "Sender:" was already present in the headers. Consider: To: all@unlucky.com From: big-boss-man@unlucky.com Sender: poor-secretary@unlucky.com Subject: You're all fired!! Boss wrote content, secretary just did the sending. To whom should you complain about the content? Cheers, Stan ---------------------------------------------------------------------- Date: 17 Apr 1997 02:53:03 -0400 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: Plain text in header fields (was: List-Post) At 01:33 AM 4/17/97 EDT, Roger Fajman wrote: [snip] >> Also, for List-Post: I think it would be worthwhile to have a special >> convention that says "you cannot post to the list" rather than trying >> to include it in a comment. Perhaps this could be indicated by an >> empty List-Post: field (with no field-body), or by a special keyword, >> e.g.: >> >> List-Post: forbidden >> >> Keith > >I like this idea, but had hestitated to suggest it before because >it seems to add a little more complexity. A word like "unavailable" >might be better because it could be used with other List-* headers. Why not just?: List-Post: NO Simplest special keyword I can think of for this! :-) It's probably multipurpose and can be used with other List-* headers as well. It's understandable in reading the headers, and the mail client can translate it to "This list will not accept posts" if desired. Cheers, Stan ---------------------------------------------------------------------- Date: 17 Apr 1997 03:29:42 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > >Widespread practice to the contrary, it's nearly always inappropriate > >for lists to supply a Sender field. (The exception that comes to mind > >is a message digest, and perhaps a moderated list.) > > > >Sender is supposed to be the identity of the "AGENT (person, system, > >or process) that sends the message", as distinct from the From field, > >which is defined as the "person(s) who wished the message to be sent". > >The distinction is subtle but important. The examples of Sender in > >RFC 822 are of messages sent by the Sender *on behalf of* the > >address(es) in the From field. (one sent by a secretary for his boss, > >another sent by one member of a group on behalf of the entire group). > > I think you're partially correct here. My interpretation is that > "Resent-Sender:" is the header that *ought* to be used; one list I'm > on does this. It also uses "Resent-Date:", "Resent-Message-Id:", etc. > and preserves all the originals. 822 really botched the definition of the Resent-* field. I believe that DRUMS has decided that Resent-* is best reserved for *manual* resending for those rare cases where a message needs to be manually forwarded to an alternate recipient with the original message headers intact. (The most common use of resend is probably to forward a misdirected message to some sort of mail robot. Another possible use would be for a moderated list -- the list moderator could approve a new submission by "resend-ing" the message to the list.) > Keep in mind, though, that as I send this, the list *IS* my AGENT > in distributing this mail to all of you; it's a system or process > indeed distinct from "From:" which does identify me, the person > who wished this message to be sent. That program is indeed acting > *on behalf of* me when I send this to it. Yes, but the same argument would apply to every MTA in the signal path. "Sender" is clearly intended to indicate the original sender; someone/something who can accept responsibility for the message being sent; a cause, not an effect. The "AGENT" language makes more sense in the context of a message generated by an automatic process (say a cron job) which generates the message without explicit human direction. > Unfortunately, RFC 822 doesn't stand by itself; some of the examples > are broken (e.g., dates); yes, but the definition is clear > some things it talks about fail in most > common implementations (multiple addresses in Reply-To:); Really? Every Internet UA I've ever used can handle multiple addresses in reply-to. The only things I know of that break here are gateways from the Internet to dysfunctional mail systems. Mailers that can't handle multiple reply-to addresses are simply broken, and that's no fault of RFC 822. > some have > been replaced by later RFC's (date formats again)... it sure would be > nice to have a rewrite of the whole thing, fixed and updated. That's precisely what the DRUMS WG is doing. See http://www.ietf.org/html.charters/drums-charter.html > RFC 822 also seems to have been written in complete ignorance of the > concept of mailing lists as we know them today (although maybe > such things didn't exist in 1982... I dunno). Yes, such things did exist. (Seems like the sf-lovers list started somewhere around 1980.) But they were relatively new, and I agree that RFC 822 doesn't seem to benefit from a mature understanding of lists. > (And I don't even want to get into the problem here of what the heck > you're supposed to do with the "Resent-xxxx" headers if mail is > resent more than once, but I think the RFC's ought to.) Fortunately, resent-* is rarely used at all, and hardly ever is it used multiple times on the same message. > >That is, part of the purpose of Sender is to identify who is > >*responsible* for sending the message. > > I think this is OK... what this means to me is that bounces need to > wind up in the "correct" place. Nope. RFC 822 imples this, and that's one place where 822 got it wrong. Bounces ALWAYS go to the envelope From address (MAIL FROM address in SMTP). Sender is NOT where bounces go, though the two addresses are usually the same. Both RFC 821 and RFC 1123 make this clear. The whole notion of separating envelope (for the mail delivery system, as in SMTP) and contents (for the recipient, as in 822) was still fairly new when RFC 822 was written, and RFC 822 didn't quite get adjusted to the new paradigm. > This does *NOT* mean that the Sender: is responsible for the > content, just for the sending action, and needs to be the person to > handle errors in the delivery process should they occur. They > (bounces) should *NOT* go to the From: address, but rather to the > (Resent-)Sender: address. Nope. See above. > >A third clue is the use of the word "authentic" in the RFC 822 > >grammar, revealing the intent that the From/Sender fields be > >"authenticated" to ensure that either the From field correctly > >identifies the originator, or that the Sender field is present and > >identifes the originator. > > This means little... who "authenticates?" A little loophole > now being grossly exploited by spammers. Agreed that Sender is easily forged these days, but it was intended that Sender be supplied by the *system*, not the *user*. Once we get to a state where senders are once again "authenticated" in some sense, Sender is the right place to put that information. In essence, Sender is a kind of trace field, sort of like Received. > >For a list that automatically forwards mail to its members, the > >original submitter of the message, not the list maintainer, bears > >responsibility for the message. Under most circumstances, the list > >should NOT discard this information nor hide it from the list > >recipients. > > If I had my druthers, I'd replace that "should" with "MUST". Note, > LISTSERV offers subscribers the *option* of shorter headers, including > the origination information being stripped, which is OK by me, but > lists which do it perforce annoy me. *THIS* list is guilty of that; > it fudges things so that everything appears to originate > from "void.achilles.net". Check the headers. (Don't get me started. I've already sent a long list of complaints about this list. In general, lists should make no more changes to a message than necessary to prevent abuse of the list.) > Consider: > > To: all@unlucky.com > From: big-boss-man@unlucky.com > Sender: poor-secretary@unlucky.com > Subject: You're all fired!! > > Boss wrote content, secretary just did the sending. To whom should > you complain about the content? You send the complaint to the boss, of course, along with a copy of the message (with all headers intact). Either he actually wrote the content, in which case he should get the complaint; or the secretary wrote the content, in which case the boss should definitely know about it! Keith ---------------------------------------------------------------------- Date: 17 Apr 1997 07:26:01 -0400 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: list-address field At 3:55 am 17/4/97, Keith Moore wrote: >Don't assume any interpretation for Sender or any other part of RFC >822 - that's clearly within the scope of the IETF DRUMS working group, >and not within the purview of any other group or document. Keith, do you have a pointer for the DRUMS WG? Thanks, ( :-]) James ---------------------------------------------------------------------- Date: 17 Apr 1997 07:26:22 -0400 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: Plain text in header fields (was: List-Post) At 4:15 am 17/4/97, Keith Moore wrote: >Also, for List-Post: I think it would be worthwhile to have a special >convention that says "you cannot post to the list" rather than trying >to include it in a comment. Perhaps this could be indicated by an >empty List-Post: field (with no field-body), or by a special keyword, >e.g.: > >List-Post: forbidden Or by an empty field with optional comment. Allowing the list admin to explain why you can't post. List-Post: or List-Post: (You cannot post to this list because...) I believe it would be very worthwhile to make this a general rule. If a list header is present but empty (or contains only a comment), the related function is explicitly unsupported by the MLM. E.g: List-Digest: (There is no digest available for this list) The UA would then have the option to present that disabled list function, perhaps as a greyed-out menu selection or as a button which presents the comment text when selected. ( :-]) James ---------------------------------------------------------------------- Date: 17 Apr 1997 11:26:02 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Plain text in header fields (was: List-Post) > Or by an empty field with optional comment. Allowing the list admin to > explain why you can't post. > > List-Post: > or > List-Post: (You cannot post to this list because...) > > I believe it would be very worthwhile to make this a general rule. If a > list header is present but empty (or contains only a comment), the related > function is explicitly unsupported by the MLM. I thought of this, but decided it was clearer to have some explicit keyword like "forbidden". Between "forbidden" , "no" , or some other descriptive keyword, I don't really care much which it is. You can add the comment in any case. Keith ---------------------------------------------------------------------- Date: 17 Apr 1997 11:28:04 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > Keith, do you have a pointer for the DRUMS WG? browse www.ietf.org, click on 'working groups', then 'applications area', then 'detailed revision/update of messaging standards (drums)'. Keith ---------------------------------------------------------------------- Date: 17 Apr 1997 13:14:06 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: list-address field At 7:55 PM -0700 4/16/97, Keith Moore wrote: >Don't assume any interpretation for Sender or any other part of RFC >822 - that's clearly within the scope of the IETF DRUMS working group, >and not within the purview of any other group or document. Keith, What of the internet-drafts at best reflects the header stuff we are interested in? - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 17 Apr 1997 14:11:01 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > What of the internet-drafts at > best reflects the > header stuff we are interested in? ftp://ftp.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-01.txt is the successor to RFC 822. (actually, there is already an -02 version, which should soon replace the -01.txt file in that directory). Keith ---------------------------------------------------------------------- Date: 17 Apr 1997 15:13:16 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: list-address field At 11:07 AM -0700 4/17/97, Keith Moore wrote: >> What of the internet-drafts at >> best reflects the >> header stuff we are interested in? > >ftp://ftp.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-01.txt > >is the successor to RFC 822. > >(actually, there is already an -02 version, which should soon replace >the -01.txt file in that directory). I looked at this one, and searched on the word "list", and there were really no list specific recommendations or examples. Are there more in -02? - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 17 Apr 1997 15:21:17 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > I looked at this one, and searched on the word "list", and there were > really no list specific recommendations or examples. Are there more in -02? no significant additions. DRUMS is forbidden to add new functionality -- they're only supposed to be cleaning things up and clarifying ambiguities in the existing specs. Also, experience has shown that discussion of mailing lists is a rathole. however, DRUMS does have clear authority to clarify the meaning of the Sender header field. Keith ---------------------------------------------------------------------- Date: 17 Apr 1997 15:27:11 -0400 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: list-address field At 12:17 PM -0700 4/17/97, Keith Moore wrote: >> I looked at this one, and searched on the word "list", and there were >> really no list specific recommendations or examples. Are there more in -02? > >no significant additions. DRUMS is forbidden to add new functionality -- >they're only supposed to be cleaning things up and clarifying ambiguities >in the existing specs. Also, experience has shown that discussion of >mailing lists is a rathole. Without adding functionality, I do recommend that they give in applicable areas examples of how a list might use the existing headers, as list traffic is probably number two usage. - ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<(suppressed)@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" .. ---------------------------------------------------------------------- Date: 17 Apr 1997 15:30:47 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > Without adding functionality, I do recommend that they give in applicable > areas examples of how a list might use the existing headers, as list > traffic is probably number two usage. We want DRUMS to finish its work in finite time. Experience with many different groups shows that it's nearly impossible for a group to simultaneously clarify old specifications and add new functionality. And lists are definitely new functionality as far as RFC 822 is concerned. Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 10:38:33 -0400 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: general report At 10:55 pm 16/4/97, Keith Moore wrote: >Of course, a single multipart message could contain any number of >foo/mailing-list-info body parts. It could also contain a text/html part which contains a mailto: form. ( :-]) James ---------------------------------------------------------------------- Date: 18 Apr 1997 10:39:20 -0400 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: general report At 10:55 pm 16/4/97, Keith Moore wrote: >Of course, a single multipart message could contain any number of >foo/mailing-list-info body parts. It could also contain a text/html part which contains a mailto: form. ( :-]) James ---------------------------------------------------------------------- Date: 18 Apr 1997 14:21:49 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: MIME type for List Details object (was: general report) At 4:43 PM -0400 97/4/16, Keith Moore wrote: >> I'm not sure text is an appropriate type. Quoting rfc2046: >> >> Although the list-* headers are basically human-parsable, I don't >> think they are within the spirit of this media type. > >It could either be text/ or application/. Bottom line: If you want >user agents that don't "understand" foo/mailing-list-info to display >such a file as text, you want it to be a subtype of text. If you >don't want them to display the file, you want the content-type to be a >subtype of application. I think the MIME object should be treated as text (even though it contains URLs which some argue are not fully human-readable). So, from what Keith said, the MIME type should be of the form "text/?". I (currently) lean toward "text/list-info". >The whole idea is to provide minimum list information in the >message header (where the recipient's UA can easily get to it) along >with a simple means of obtaining additional information about the list >in a structured form. Well put. >A URL pointing to a web server that returns the >foo/mailing-list-info type seems like a good way to acheive that. or pointing to an ftp server, or mailto, or whatever. The transport method used for a particular text/list-info object is not a big issue as long as the structure of the object is well-defined (and adhered to) and the object can be identified for what it is. >You of course could do multipart/whatever and have the second part be >a message/external-body that points to a message/list-headers. But >that's a lot of baggage with little more functionality than a simple >List-Info header and URL. And MUAs are already accustomed to looking >in message headers to figure out how to do things like replies. >Should they now have to look everywhere in the message body? I see three main types of transport for the text/list-info object: 1) "List-Info: " A mail message consisting entirely of the text/list-info object is returned to the requesting email address. 2) "List-Info: " A text/list-info object is retreived by the client. 3) "List-Help: " A multipart message is returned to the requesting email address. The first part is the usual text/plain help message for 'somelist'. The second part is the text/list-info object. Number 3 would also apply to the "Monthly Help Message" that some lists send out. Personally, I might caution against use of non-mail protocols as illustrated in number 2 (http). They pose a problem in getting the list-info into the mail client. For example, when I trigger an http URL in Eudora, it launches an http client which then views the retrieved data. I suppose I could get around that problem by configuring the MIME-type mapping in my http client to use Eudora as the "Viewer" for the text/list-info type. I think I just answered my concern - so maybe using http is safe for this. At 5:09 PM -0400 97/4/16, Marc Horowitz wrote: >However, when something more complex is desired, MIME already >provides a mechanism for telling the MUA to look somewhere else for >something. I'd rather not see us define a new standard which uses the >rather ad-hoc technique of a url in a header. So, you're (Marc) suggesting that instead of a "List-Info" header field, we use another MIME part (text/url or whatever is the proper way to type it) to identify what "List-Info" is being suggested for? Please expand on this. >I guess I have a >question of intent here: do you expect that a MUA would follow a >list-info url automagically to get the extra headers, or that it would >only be done at the request of the user? In general, the list-info object would only be retrieved at user request. However, a particularly clever client application may want to keep its own database of list commands for lists the user has subscribed to. So, it may periodically (but not all the time) request the current list-info object to make sure it's records are up to date. It may also trigger retrieval of the list-info object when the user selects a command that it doesn't have the details for. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:22:00 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: Plain text in header fields At 5:40 PM -0400 97/4/16, James Berriman wrote: >Why reinvent the wheel? rfc822 (p.14) states that text within parentheses >() is a comment. > >So we get: > >List-Post: (Post only through the web form) > >List-Post: (No posting on this list - announcements only.) At 10:31 PM -0400 97/4/16, Keith Moore wrote: >Comments, on the other hand, are almost completely arbitrary, and are >not intended to be interpreted by mail reading software. So, would we be in violation of RFC822 if we used comments in alerts/dialogs when issuing List- field based commands? Are there any other thoughts regarding which character(s) should be used to denote plain text (suitable for alert messages) in the List- headers (list command meta-syntax)? At 5:51 PM -0400 97/4/16, Jason L Tibbitts III wrote: >Well, if you want to take that route, everything outside of <> (excepting >certain quoting rules) is a comment. I would like to try to stick to using special tokens to identify the meaning of stuff in the field contents. It makes it easier (IMHO) to parse the field contents. - - We're using angle brackets <> to denote URLs. - - I expect we'll use () for plain text (alert/dialog messages). - - I still have in my mind the possibility of a more comprehensive meta-syntax for describing mail commands which will support variables - it will need identifier token(s). At 11:15 PM -0400 97/4/16, Keith Moore wrote: >3. Any proposal to include human readable text that doesn't support >I18N will get soundly trounced. And if you want to include something >besides ASCII-only text in a List-* field, you need to use RFC 2047 to >do this. As RFC 2047's encoded-words are not valid within >quoted-strings, you need some other way than quotes to distinguish >human readable text. Thanks for clearing this up. (and thanks for being our human encyclopedia of standards ;-) I had only mentioned Quoted Printable by way of suggesting that some form of encoding may be required for the use of plain text in the List- fields, particularly for internationalization. I'm not familiar with the current standards in that regard, so will defer to your advice. What are I18N & rfc2047 and what do they mean for the encoding of plain text in header fields? >Given that you can just use comments, I'm not sure it's worth the >trouble to define a separate mechanism. Does the specification for comments allow for the encoding of special characters and internationalization? - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:22:47 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: list-address field At 7:18 PM -0400 97/4/16, BruceLeban@akimbo.com wrote: >I agree with the other comments about why a separate List-Address isn't >necessary (given that we've recognized that the Sender header identifies >the name of the list). Previous discussion has identified why my suggestion of using Sender for the list information is invalid. At 8:53 PM -0400 97/4/16, Stan Ryckman wrote: >It would be nice to have a "standard" header that one could do mail >filtering on to uniquely identify a list... I think there's definitly use for a field that specifically identifies the identity of the list. Perhaps "List-Identity" would be a more appropriate label (as opposed to List-Address). - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:22:55 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: list spec updates I've added a section for definitions of terms to help those people who may be unfamiliar with some of the technical terms and acronyms we're using in this disucssion: I've added the List-Digest-Off: field to the list of possible header fields: - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:23:03 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: How many (which) headers? At 9:00 PM -0400 97/4/16, Roger Fajman wrote: >I remember the discussion about "header bloat" going on, but I've >forgotten what the main objection was. Personally, I like having more meta-information (e.g., header fields) included with my mail messages. It makes it easier for me to work with my mail (e.g., filtering). I also have the advantage of a mail client which can selectivly hide header fields I don't normally want to see (with a convenient button in the message window to reveal all headers when I do want to see them). The main concern I've had is the likelihood that there will be hindering objections raised against the proposal becoming a standard if it is perceived as adding too many new header fields. >Also, by being overly concerned about one possible objection (header >bloat) you may open yourself to objections about inadequate functionality I'm now thinking - based on the discussion here - that I've been overly conservative in my estimation of what number of fields would be tolerable (and appropriate) in this regard. Frankly, I now think it may be appropriate to add to the current draft some or all of Post, Archive, Digest-On, Digest-Off, Address, and Human-Admin. The extended details (MIME object or whatever) and corresponding List-Info field (or whatever label is chosen for it) should be a separate proposal. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:23:11 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: we're talking about mail - use mailto (was: Plain text in header fields) At 8:53 PM -0400 97/4/16, Stan Ryckman wrote: >In fact, for that reason, I'd suggest that should be the >"preferred" header for any of the List-* headers. Agreed. The only fields where I think non-mailto protocols may be okay are List-Help and List-Info (or whatever the 'extended data retrieval' field ends up being called). We should probably clarify this for the proposal. >One other thing I'd suggest for mail clients (while I'm here) is that >they be *strongly* encouraged to permit users to add their own headers >before sending those "convenient" messages. In particular, I like: > Bcc: myself That's why I suggested in the implementation section that a "Review Message" option be included when confirming a List-* command. Review Message should allow the user to modify the message as they see fit. Before anyone raises the point that the user may "mess up" the command: for security reasons, the user should always have the final say on what they send out. At 1:49 AM -0400 97/4/17, Keith Moore wrote: >Though I am wary of using mailto: URLs when ordinary email addresses >will do. If an email address is the only thing that can reasonably >go in a List-* field, it should be an email address, not a mailto: URL. I think, however, that most of the fields where an email address is used may also need the benefits of the enhanced mailto URL. As an example, posting might require a special subject (e.g., To: moderator@foo.bar Subject: somelist posting). The only List-* field that I see as not needing the URL format, but could just use the email address, is List-Address. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:23:19 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: s-ubscribe vs. the rest At 8:53 PM -0400 97/4/16, Stan Ryckman wrote: >(And I don't see any need based on "gee, I'll >unsubscribe this week and re-subscribe next week." -- just keep a copy >of your original sub message, or use LISTSERV where you can set yourself >to NOMAIL and not actually unsubscribe.) Part of the problem is that far too many users don't keep their original sub message, or the original info they received about the list, or the help messages they received from the list (or it's server), etc. If they can't keep that info, they're certainly not going to be able to handle the NOMAIL command. To those who would say "If they can't figure it out, or remember the necessary commands, they don't deserve to access mailing lists." remember that the whole point of this proposal is to set things so users don't have to figure out how to access list commands. This includes subscribe. >Sure, the number of "subscribes" sent on the internet undoubtedly exceed >the number of "unsubscribes" -- because mailing lists still exist. I've >never been in a position where I could use a subscribe header, I've already personally made use of the List-Subscribe field (and List-Unsubscribe). My general-use email address is changing from gneufeld@ccs.carleton.ca to grant@achilles.net. I've been unsubscribing my carleton address and subscribing my achilles address on the various lists I'm on. ListMom-Talk which is using the List-* headers was by far the easiest for me to do this on. >I'm not sure that "Post to List" buys much either, except to override >a list owner's choice that default replies should go to the sender >rather than the list. Hopefully, MLM software which implements that >will allow individual list owners to be able to *not* include it. The proposal states that each of the fields may be individually included or not at the discretion of the list manager based on what sort of list they are running. At 10:22 PM -0400 97/4/16, Keith Moore wrote: >> People will pass around subscription messages. Invitations using the >> subscribe header can be sent to your friends. Who says only the list >> software can make the header? > >no, we don't want to encourage people to send list-subscribe headers >to each other in messages that aren't from the list. > >of course people want to send subscription information to their friends. >that's what the foo/mailing-list-info MIME type is for. I think that the List-Subscribe field would be useful for passing in messages not necessarily from a list. In particular, announcements of new lists. I do agree that passing a list-info MIME object is a better way to do it, but we don't have that method available (and probably won't for a while yet). - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:23:27 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: forbidden commands (was: Plain text in header fields) At 11:15 PM -0400 97/4/16, Keith Moore wrote: >Also, for List-Post: I think it would be worthwhile to have a special >convention that says "you cannot post to the list" rather than trying >to include it in a comment. Perhaps this could be indicated by an >empty List-Post: field (with no field-body), or by a special keyword, >e.g.: > >List-Post: forbidden I like this keyword idea. At 1:33 AM -0400 97/4/17, Roger Fajman wrote: >A word like "unavailable" >might be better because it could be used with other List-* headers. At 2:50 AM -0400 97/4/17, Stan Ryckman wrote: >Why not just?: > > List-Post: NO > >Simplest special keyword I can think of for this! :-) It's probably >multipurpose and can be used with other List-* headers as well. So, we have: forbidden unavailable no I like "no" because it's the simplest (hardest to spell incorrectly). Any other suggestions or opinions? At 7:21 AM -0400 97/4/17, James Berriman wrote: >I believe it would be very worthwhile to make this a general rule. If a >list header is present but empty (or contains only a comment), the related >function is explicitly unsupported by the MLM. > >E.g: > >List-Digest: (There is no digest available for this list) I would prefer the keyword form (List-Digest: no) with the option of including a comment: List-Digest: no (There is no digest available for this list) - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:23:35 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: disclosing to the user At 11:38 PM -0400 97/4/16, Clarence C. Wong wrote: >This is rare, but some MLMs use more than one field: > > > From: cwong > To: mail-list-admin > Subject: somelist > > subscribe cwong > >We use such a syntax at Qualcomm (I don't necessarily think it's elegant, >but we started out with it a couple years ago and we're stuck with it.) >What would the dialog say in this case? Maybe something like: Do you want to send the subscribe command: Subject: somelist Command: subscribe cwong to ? - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 14:23:43 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: this list (was: list-address field) At 2:11 AM -0400 97/4/17, Stan Ryckman wrote: >>For a list that automatically forwards mail to its members, the >>original submitter of the message, not the list maintainer, bears >>responsibility for the message. Under most circumstances, the list >>should NOT discard this information nor hide it from the list >>recipients. > >If I had my druthers, I'd replace that "should" with "MUST". Note, >LISTSERV offers subscribers the *option* of shorter headers, including >the origination information being stripped, which is OK by me, but >lists which do it perforce annoy me. *THIS* list is guilty of that; >it fudges things so that everything appears to originate >from "void.achilles.net". Check the headers. I've changed that (I think). All original message headers should now be passing through to the list. The list settings were set to "minimal headers". That results in things like the Received: fields being stripped. Personally, I'd like to be able to specify which fields are stripped (I'd stop things like any List-* or Reply-To: fields, but let the Received: fields get through), but my server software doesn't have that option. - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 15:22:09 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: general report At 1:49 AM -0400 4/17/97, Keith Moore wrote: > Though I am wary of using mailto: URLs when ordinary email addresses > will do. If an email address is the only thing that can reasonably > go in a List-* field, it should be an email address, not a mailto: URL. But when or why should an email address be the only solution? This proposal could be more generic than email lists. It could apply to a web discussion board, or something we haven't thought of yet. This is one place where the List-Info mime part could be VERY useful, as it might be the only way to get instructions. Or maybe my list is authenticated and the only way to do subscribe/unsubscribe is from a web page. The nice thing about using a URL is that has very little overhead over a plain email address, and has lots of other possible uses. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 18 Apr 1997 15:22:33 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: How many (which) headers? At 2:14 PM -0400 4/18/97, Grant Neufeld wrote: > Frankly, I now think it may be appropriate to add to the current draft some > or all of Post, Archive, Digest-On, Digest-Off, Address, and Human-Admin. I like Post, Archive, Digest, Address, and Owner. List-Owner is better than List-Human-Admin because its shorter, easier to read, and is already in use as a term for most MLMs. Do most lists have separate commands for Digest-Off and Subscribe? Most lists I've been on allow you to change from Digest to Normal subscription by resending a subscribe command. If possible on most servers, only having one header would be much simpler/nicer. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 18 Apr 1997 15:34:05 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 1:57 PM -0400 4/18/97, Grant Neufeld wrote: > I think there's definitly use for a field that specifically identifies the > identity of the list. Perhaps "List-Identity" would be a more appropriate > label (as opposed to List-Address). I don't understand what the "identity of the list" means. Why is List-Address different from List-Post? ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 18 Apr 1997 15:34:29 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field At 2:11 AM -0400 4/17/97, Stan Ryckman wrote: > Agreed. If someone spams *this* list, I'd like the header information > to go after the spammer *without* having to count on the list owner > doing it, even if those headers are logged somewhere. Right now, not > possible. I disagree. As a list owner, I don't want people snooping about and trying to be vigallante ListMoms. If the spammer is stupid enough to leave traces in the headers, then I don't anticipate problems catching or stopping him. Otherwise, only the list owner can really do much about it anyway. I don't want any citizen's arrests on my lists. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 18 Apr 1997 15:36:07 -0400 From: Marc Horowitz <(suppressed)@cygnus.com> Subject: Re: MIME type for List Details object (was: general report) Grant Neufeld <(suppressed)@achilles.net> writes: >> So, you're (Marc) suggesting that instead of a "List-Info" header field, we >> use another MIME part (text/url or whatever is the proper way to type it) >> to identify what "List-Info" is being suggested for? Please expand on this. When I suggested this, I thought that MUAs would be expected to follow the list-info link automatically. Since this is not true, I think a header is fine, and there's no requirement for a MIME part. Of course, since we're declaring a type, it could be included, but it doesn't have to be. Marc ---------------------------------------------------------------------- Date: 18 Apr 1997 15:37:58 -0400 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: How many (which) headers? >>>>> "JDB" == Joshua D Baer <(suppressed)@skyweyr.com> writes: JDB> Do most lists have separate commands for Digest-Off and Subscribe? Majordomo 2.0 probably won't. Users can use a separate command to change their subscription class. Majordomo 2.0 will also have more than one digest per list, so this should be considered. (Majordomo's a long way of, though. I'd say I'm about 25% done with what I want to put in it.) Majordomo 1.x requires two commands to change to 'digest mode'; you unsubscribe form the regular list and subscribe to the digest list. These can, however, both go in the same message body. JDB> Most lists I've been on allow you to change from Digest to Normal JDB> subscription by resending a subscribe command. Really? I don't think listproc/listserv/whatever it is allows you to choose digest or non-digest mode when you subscribe. I'm less than properly informed here, though. - J< ---------------------------------------------------------------------- Date: 18 Apr 1997 15:56:52 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: general report > But when or why should an email address be the only solution? Because it's the only interface that is shared by everyone who reads email -- and thus by all of the potential audience for a mailing list. Actually, I would never insist that email be the ONLY way to subscribe to a mailing list. But there's a lot of value in having that be the normal way to subscribe. To ask the question at a different level: Why should all Internet email addresses share the same protocols (DNS and SMTP)? Because it's really useful if everyone on Internet mail can reach everyone else. Similarly, it's really useful if everyone on email can subscribe to any mailing list. > This proposal could be more generic than email lists. Successful proposals solve one problem well. You don't want to be too generic. Trying to over-generalize is a sure sign of second-system effect, and often (perhaps usually) leads to disaster. > The nice thing about using a URL is that has very little overhead over a > plain email address, and has lots of other possible uses. And the annoying thing about a URL is that you need a LOT of support on the client end to be reasonably sure you can use it. Anyway, I didn't say that all List-* fields should be limited to email addresses, just the ones that inherently involve email -- like the address of the list maintainer. Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 16:45:08 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Plain text in header fields > At 10:31 PM -0400 97/4/16, Keith Moore wrote: > >Comments, on the other hand, are almost completely arbitrary, and are > >not intended to be interpreted by mail reading software. > > So, would we be in violation of RFC822 if we used comments in > alerts/dialogs when issuing List- field based commands? User agents can do what they want to with comments, but protocol specifications cannot state that comments are to be used for particular purposes. > What are I18N & rfc2047 and what do they mean for the encoding of plain > text in header fields? I18N == "internationalization" I18N is easier to spell. RFC 2047 is the specification for encoding of non-ASCII text in message headers. If you've ever seen frobs that look like =?iso-8859-1?Q?=4BE=49T=48_=4DOO=52E?= those are defined in RFC 2047. > >Given that you can just use comments, I'm not sure it's worth the > >trouble to define a separate mechanism. > > Does the specification for comments allow for the encoding of special > characters and internationalization? Of the printable ASCII characters, within a comment only "\", "(" and ")" are special. As for I18N, RFC 2047 encoded-words can be used in comments. Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 16:47:53 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: How many (which) headers? > Frankly, I now think it may be appropriate to add to the current draft some > or all of Post, Archive, Digest-On, Digest-Off, Address, and > Human-Admin. Post: agreed Archive: agreed Digest-*: bad idea. too many variant behaviors Address: if you have List-Post, what's the point? it's confusing at best. Human-Admin: agreed Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 16:52:26 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > I disagree. As a list owner, I don't want people snooping about and trying > to be vigallante ListMoms. If the spammer is stupid enough to leave traces > in the headers, then I don't anticipate problems catching or stopping him. > Otherwise, only the list owner can really do much about it anyway. SPAM isn't the only problem. The recipients of your lists need to be able to acertain the authenticity and/or validity of any messages they receive from your lists. If you strip out the trace headers, you're denying them any means of doing that. And regarding SPAM: I disagree that it's the list maintainer's job to be cop. Cops don't scale. The entire community served by the list is harmed when people abuse the list, and the entire community should be able to retaliate. (just as long as they don't all bitch to the list) Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 20:18:57 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: list-address field At 3:28 PM -0400 97/4/18, Joshua D. Baer wrote: >At 1:57 PM -0400 4/18/97, Grant Neufeld wrote: > >> I think there's definitly use for a field that specifically identifies the >> identity of the list. Perhaps "List-Identity" would be a more appropriate >> label (as opposed to List-Address). > >I don't understand what the "identity of the list" means. Some unique identifier that specifies a given list. This list, for example, has two identifing items: 1) its address: list-header@arpp.carleton.ca 2) its name: List Headers Working Group (both of which are not really descriptive of what this project has actually become. If I could go back and change it, I'd call it "List Specification" or something like that) Ultimately, it would be useful to have truly unique list identifiers which are not tied to the address. So, when a list moves, its identifier doesn't have to change - just like my domain name didn't have to change when I moved my server. Having stated that, I take back my suggestion that "List-Identity" would be better than "List-Address" since a mechanism for defining unique identifiers (other than the address) is not available yet. We need to define the content of the List-Address field. Personally, I favor the form used in the From field: "List Name" list@address >Why is >List-Address different from List-Post? Because you don't necessarily post to the list-address. In fact, there may be more complicated requirements for posting (such as a preset subject field). Or you may not be allowed to post at all. - -- "I, for one, welcome our new insect overlords, and would like to remind them that as a trusted tv personality, I can be helpful in rounding up others to toil in their underground sugar caves." - Kent Brockman grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 20:19:07 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: How many (which) headers? At 4:44 PM -0400 97/4/18, Keith Moore wrote: >Digest-*: bad idea. too many variant behaviors How so? Switching to digest mode is one of the more frequently requested options, so it would seem to be a good candidate for inclusion. >Address: if you have List-Post, what's the point? it's confusing at best. List-Post doesn't necessarily identify the address of the list - only the address to post to (and only if posting is allowed). - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 20:19:15 -0400 From: Grant Neufeld <(suppressed)@achilles.net> Subject: Re: Plain text in header fields At 4:41 PM -0400 97/4/18, Keith Moore wrote: >> So, would we be in violation of RFC822 if we used comments in >> alerts/dialogs when issuing List- field based commands? > >User agents can do what they want to with comments, but protocol >specifications cannot state that comments are to be used for >particular purposes. So it would be acceptable for user agents to use the comments in alerts - but we can't tell them that that's what they should do? Should we just leave it at that or try to find some other way to present plain text in the header fields? >RFC 2047 is the specification for encoding of non-ASCII text in >message headers. If you've ever seen frobs that look like What's a "frob"? > =?iso-8859-1?Q?=4BE=49T=48_=4DOO=52E?= Um, does that say something nice or something naughty? ;-) - -- grant@achilles.net grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Apr 1997 21:04:20 -0400 From: (suppressed)@polyhymnia.pmail.gen.nz Subject: Re: How many (which) headers? On 18 Apr 97 at 20:09, Grant Neufeld said this about Re: How many (which) headers?: > At 4:44 PM -0400 97/4/18, Keith Moore wrote: > >Digest-*: bad idea. too many variant behaviors > > How so? > > Switching to digest mode is one of the more frequently requested options, > so it would seem to be a good candidate for inclusion. I know that Listserv currently allows two different digest formats - the list owner sets which is the default - and you may have to tell it which kind of digest you want. This gives you three possibilities for Digest-on: one for MIME digests, one for the older kind (as used on this list), and one for the default, or "I don't care." As more MLMs support MIME digests, this is likely to become more of an issue. Cheers Richard - -- Richard Stevenson richard@polyhymnia.pmail.gen.nz Earth Rotation Protection Society http://home.sol.no/litlaboe/erps PGP Key ID 0x0E5A2DD5 fingerprint = 7B DD 1C 51 76 05 A1 42 44 2E DD 61 78 DB 2D 07 ---------------------------------------------------------------------- Date: 18 Apr 1997 21:19:24 -0400 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: How many (which) headers? >>>>> "RS" == Richard Stevenson <(suppressed)@polyhymnia.pmail.gen.nz> writes: RS> I know that Listserv currently allows two different digest formats - RS> the list owner sets which is the default - and you may have to tell it RS> which kind of digest you want. It is probably a semi-safe assumption that any client that supports these headers will also support MIME. But the problem is still there, and Majordomo 2.0 will have the possibility of more than two digests per list. Some of this can be settled by saying that the list owner can choose which defaults are reasonable. You will not be able to solve the problem entirely, at least not in the space of a single header. - J< ---------------------------------------------------------------------- Date: 18 Apr 1997 21:54:49 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: list-address field > >Why is > >List-Address different from List-Post? > Because you don't necessarily post to the list-address. Then why do we need a List-Address? ---------------------------------------------------------------------- Date: 18 Apr 1997 22:07:50 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Plain text in header fields > >> So, would we be in violation of RFC822 if we used comments in > >> alerts/dialogs when issuing List- field based commands? > > > >User agents can do what they want to with comments, but protocol > >specifications cannot state that comments are to be used for > >particular purposes. > > So it would be acceptable for user agents to use the comments in alerts - > but we can't tell them that that's what they should do? Something like that. > Should we just leave it at that or try to find some other way to present > plain text in the header fields? You should try to define List-* fields for the most common functions that everybody will use or which are very important, not for everything you can think of. Unless there's a common and well-understood need to communicate human-readable text in a List-* header field, I'd say leave it as-is. > >RFC 2047 is the specification for encoding of non-ASCII text in > >message headers. If you've ever seen frobs that look like > > What's a "frob"? canonically speaking, a protrusion. used here in the sense of "something that sticks out" from the hacker's dictionary: frob /frob/ 1. n. [MIT] The TMRC definition was "FROB = a protruding arm or trunnion"; by metaphoric extension, a `frob' is any random small thing; an object that you can comfortably hold in one hand; something you can frob (sense 2). See frobnitz. 2. vt. Abbreviated form of frobnicate. 3. [from the MUD world] A command on some MUDs that changes a player's experience level (this can be used to make wizards); also, to request wizard privileges on the `professional courtesy' grounds that one is a wizard elsewhere. The command is actually `frobnicate' but is universally abbreviated to the shorter form. > > =?iso-8859-1?Q?=4BE=49T=48_=4DOO=52E?= > > Um, does that say something nice or something naughty? ;-) Well, I think the contents are rather nice myself. (but a lot of people have said naughty things about the encoding) Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 22:17:45 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: How many (which) headers? > >Digest-*: bad idea. too many variant behaviors > > How so? > > Switching to digest mode is one of the more frequently requested options, > so it would seem to be a good candidate for inclusion. Most lists don't have a digest mode; some of those that do have digest mode don't offer you the choice of non-digest mode. Some lists have a command that can set/unset digest mode; these would work fine with List-Digest-* Some lists require you to unsubscribe from one list and subscribe to a different list. These aren't easily accomodated by a List-Digest-* field. I think of List-Digest-* as being of marginal value, close to the point of diminishing returns (or perhaps past that point). Sophisticated lists have lots of other per-recipient flags besides "digest", should we define commands for those also? At what point do we give up trying to list all of the commands that someone might want to use, and start trying to define a standard command set? (Then you could just have "List-command-set: RFC2345") > >Address: if you have List-Post, what's the point? it's confusing at best. > > List-Post doesn't necessarily identify the address of the list - only the > address to post to (and only if posting is allowed). So if you don't post to the list address, what do you do with it? Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 22:19:47 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: How many (which) headers? > It is probably a semi-safe assumption that any client that supports these > headers will also support MIME. There are quite popular mail systems for which MIME digest support (i.e. support for nested multiparts) is completely broken. Keith ---------------------------------------------------------------------- Date: 18 Apr 1997 23:52:16 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: How many (which) headers? >So if you don't post to the list address, what do you do with it? > To help manage mailing lists better, the MUA could use the list address for three things: 1- As part of the confirmation dialog, informing the user that the intended action is to subscribe (or unsubscribe) from this list. (e.g. Are you sure you want to subscribe to "some-list@host.com?") 2- When subscribing to lists, the MUA could automatically (as an option) create filters and mailboxes for the user. 3- MUAs could keep track of lists users have subscribed to or unsubscribed from. People who go on vacation often unsubscribe to a bunch of lists and then resubscribe later on. By the way, has there been any talk of a list-confirmation field? (Did my subscription request succeed or fail?) - -Clarence ---------------------------------------------------------------------- Date: 19 Apr 1997 00:37:55 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: How many (which) headers? >So if you don't post to the list address, what do you do with it? > > > To help manage mailing lists better, the MUA could use the list address for > three things: Although none of the things you listed require an email address, *all* of the things you listed work just fine using a List-Post address. Keep it simple! Keith ---------------------------------------------------------------------- Date: 19 Apr 1997 01:03:48 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: How many (which) headers? > > To help manage mailing lists better, the MUA could use the list address for > > three things: > > Although none of the things you listed require an email address, > *all* of the things you listed work just fine using a List-Post address. > > Keep it simple! > > Keith But, as has already been pointed out, many lists are announcement- only and don't allow posting by subscribers. ---------------------------------------------------------------------- Date: 19 Apr 1997 01:08:48 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: How many (which) headers? > But, as has already been pointed out, many lists are announcement- > only and don't allow posting by subscribers. I must have missed that message. Nevertheless, having separate List-Post and List-Address header fields seems like overkill. (And what does it mean for an announcement-only list to have an address?) Keith ---------------------------------------------------------------------- Date: 19 Apr 1997 01:49:04 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: How many (which) headers? > The main concern I've had is the likelihood that there will be hindering > objections raised against the proposal becoming a standard if it is > perceived as adding too many new header fields. The List-function header proposal I made the other day does deal with that by defining only one header, although one that is more complex in structure. ---------------------------------------------------------------------- Date: 19 Apr 1997 01:59:01 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: How many (which) headers? > Do most lists have separate commands for Digest-Off and Subscribe? Most > lists I've been on allow you to change from Digest to Normal subscription > by resending a subscribe command. If possible on most servers, only having > one header would be much simpler/nicer. > > ^Josh With LISTSERV you get the default as determined by the list owner when you subscibe. To change from the default you use a SET command. ---------------------------------------------------------------------- Date: 19 Apr 1997 03:16:03 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: How many (which) headers? > > But, as has already been pointed out, many lists are announcement- > > only and don't allow posting by subscribers. > > I must have missed that message. Nevertheless, having separate > List-Post and List-Address header fields seems like overkill. > (And what does it mean for an announcement-only list to have an > address?) > > Keith Perhaps List-name would be a better choice. ---------------------------------------------------------------------- Date: 19 Apr 1997 11:18:50 -0400 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: How many (which) headers? > Perhaps List-name would be a better choice. perhaps. (but how do you ensure that list-name is unique? append the domain name of the host that runs the list...) Keith ---------------------------------------------------------------------- Date: 19 Apr 1997 21:12:56 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: How many (which) headers? > > Perhaps List-name would be a better choice. > > perhaps. (but how do you ensure that list-name is unique? > append the domain name of the host that runs the list...) > > Keith There could be a text description plus an email address. ---------------------------------------------------------------------- Date: 20 Apr 1997 20:47:53 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: How many (which) headers? At 8:09 PM -0400 4/18/97, Grant Neufeld wrote: > List-Post doesn't necessarily identify the address of the list - only the > address to post to (and only if posting is allowed). I still don't understand what is meant by "the address of the list". If it's not the posting address, what is it used for? ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 20 Apr 1997 20:48:21 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: How many (which) headers? At 1:05 AM -0400 4/19/97, Keith Moore wrote: > > But, as has already been pointed out, many lists are announcement- > > only and don't allow posting by subscribers. > > I must have missed that message. Nevertheless, having separate > List-Post and List-Address header fields seems like overkill. > (And what does it mean for an announcement-only list to have an > address?) Agreed. This whole List-Address thing seems like semantic fluff. A "list" has multiple addresses which identify (in most cases). Such a "list-address" field would only be appropriate to lists like ListMom-Talk with only one address. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://www.skyweyr.com/skylist/ ---------------------------------------------------------------------- Date: 20 Apr 1997 20:48:49 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: How many (which) headers? At 3:12 AM -0400 4/19/97, Roger Fajman wrote: > > > But, as has already been pointed out, many lists are announcement- > > > only and don't allow posting by subscribers. > > > > I must have missed that message. Nevertheless, having separate > > List-Post and List-Address header fields seems like overkill. > > (And what does it mean for an announcement-only list to have an > > address?) > > > > Keith > > Perhaps List-name would be a better choice. This I could see as marginally useful, but definitely better than List-Address. However, I wouldn't put an email address there, I'd put a plain text description. Ex. List-Name: "ListMom Talk Discussion List" ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 20 Apr 1997 20:49:12 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: list-address field > Because you don't necessarily post to the list-address. In fact, there may > be more complicated requirements for posting (such as a preset subject > field). Or you may not be allowed to post at all. So what _would_ you use the list-address/list-identity for? ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 20 Apr 1997 20:49:27 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Plain text in header fields (was: List-Post) At 8:53 PM -0400 4/16/97, Stan Ryckman wrote: > >It may also be useful to combine plain text with the use of meta-syntax > >(currently URLs) in the header fields. A possible example of this could be: > > List-Post: "Post only through the web form" > > *HORRIBLE* example!!! Please don't encourage this, even by example. > > Mailing lists are an email medium. WWW is something else. I can download > my email, read it at my leisure, reply to it, and then upload. I can't > do that with the WWW, which requires tying up my phone line. Maybe you > have a second phone line, or even a dedicated T1, but don't assume the > rest of the world does. While I agree with your comments generally, I can think of specific situations where a web posting form might be the only appropriate alterative. For example, some other verification may have to take place. I'd like to see the proposal be as flexible as possible. ~Josh - -- ---------------------------------- Joshua D. Baer SkyWeyr Technologies http://www.skyweyr.com/ ---------------------------------------------------------------------- Date: 21 Apr 1997 01:22:56 -0400 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: list-address field > > Because you don't necessarily post to the list-address. In fact, there may > > be more complicated requirements for posting (such as a preset subject > > field). Or you may not be allowed to post at all. > > So what _would_ you use the list-address/list-identity for? > > ^Josh A text description of and a unique identifier for the list. They could be used in messages to the user. Also, a unique identifier might be used by an email client that attempts to track list subscriptions. ---------------------------------------------------------------------- Date: 21 Apr 1997 01:45:08 -0400 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: How many (which) headers? At 11:47 PM -0400 4/18/97, Clarence C. Wong wrote: > 1- As part of the confirmation dialog, informing the user that the intended > action is to subscribe (or unsubscribe) from this list. (e.g. Are you sure > you want to subscribe to "some-list@host.com?") > 2- When subscribing to lists, the MUA could automatically (as an option) > create filters and mailboxes for the user. > 3- MUAs could keep track of lists users have subscribed to or unsubscribed > from. People who go on vacation often unsubscribe to a bunch of lists and > then resubscribe later on. I think these are all fantastic ideas. I don't see how they are tied to List-Address field, but I hope mail clients implement stuff like this (either internally or through scripting) once the headers are in use. > By the way, has there been any talk of a list-confirmation field? (Did my > subscription request succeed or fail?) How exactly would this be used? Sounds interesting, but I'm not sure I understand your intention. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://www.skyweyr.com/skylist/ ---------------------------------------------------------------------- Date: 21 Apr 1997 09:53:29 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: general report >I was at the BOF and I don't remember it that way. I brought up the >issue of archives and the presenter gave the argument in favor of >restricting it to the three functions. I don't recall a lot of comment >one way or the other from the rest of the people on that issue. No >straw poll was taken. > >The consideration of firewalls that look of headers seems to me to be a >point in favor of not dribbling them out or of using a more extensible >syntax. Also, we are asking user agent and list server developers to >add support for these headers. It's easier for them to do it once >instead of several times. Also, user education is easier if there is a >standard set of headers that encompasses most functions, as it is less >likely that there will be varying levels of support in different list >servers and user agents that have been deployed at different times. Agreed... I agree with this wholeheartedly... but the point that was brought up at the BOF was that it might be better to pass the base spec with the three functions, and then come out with a more comprehesive spec, using the base as a 'see, here's how it's done and its easy' thing. regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 21 Apr 1997 09:56:12 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: list-address field >> This would probably be the same as the List-Post field. > >the list-address field and the list-post field seem to have different >meaning. Because the list-post field seems to to control users' posting, >the values of the list-address field and the list-post field will be >different when the mailing list is moderated (I'm not sure this is the >case) or the mailing list is only for announcement. > >So how about to use the list-post field only when the administrator >wants to control users' posting? > > case 1: When the subscribers can post freely, > List-Address: list-header@arpp.carleton.ca > > case 2: When the subscribers are not allowed to post to the list. > List-Address: list-header-announce@arpp.carleton.ca > List-Post: > (I dont' have good idea about the format of this URL...) > > case 3: When the list is moderated and has another address for the moderator, > List-Address: list-header-announce@arpp.carleton.ca > List-Post: Ick... three different header combinations? Can't we come up with some metadata for one of the fields that would do it in one? regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 21 Apr 1997 09:56:26 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: list-address field >> This would probably be the same as the List-Post field. > >the list-address field and the list-post field seem to have different >meaning. Because the list-post field seems to to control users' posting, >the values of the list-address field and the list-post field will be >different when the mailing list is moderated (I'm not sure this is the >case) or the mailing list is only for announcement. > >So how about to use the list-post field only when the administrator >wants to control users' posting? > > case 1: When the subscribers can post freely, > List-Address: list-header@arpp.carleton.ca > > case 2: When the subscribers are not allowed to post to the list. > List-Address: list-header-announce@arpp.carleton.ca > List-Post: > (I dont' have good idea about the format of this URL...) > > case 3: When the list is moderated and has another address for the moderator, > List-Address: list-header-announce@arpp.carleton.ca > List-Post: Ick... three different header combinations? Can't we come up with some metadata for one of the fields that would do it in one? regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 21 Apr 1997 10:07:51 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: How many (which) headers? (was: general report) >Good points. Hmmm, maybe we need to reconsider the decision to restrict the >initial effort to just the core functions. > > >The reasons I see for keeping it to just the 3 are as follows: > >- Fewer headers means we're less likely to run into "header bloat" >objections. Basically, trying to be as inoffensive as possible to improve >our chances of making it through the standards process. > >- Minimize the use of headers (avoid bloat) and focus further efforts on >things like the MIME part, footers, specialized messages, etc. Add to this the fact that if we have one to three headers, and may I add headers that only the 'list-subscribe' is questioned right now, we should be able to get a 'base' spec published in short order. Then, we could worry about 'how to do it completely right'... regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 21 Apr 1997 10:08:06 -0400 From: "Jack De Winter" <(suppressed)@wildbear.on.ca> Subject: Re: How many (which) headers? (was: general report) >Good points. Hmmm, maybe we need to reconsider the decision to restrict the >initial effort to just the core functions. > > >The reasons I see for keeping it to just the 3 are as follows: > >- Fewer headers means we're less likely to run into "header bloat" >objections. Basically, trying to be as inoffensive as possible to improve >our chances of making it through the standards process. > >- Minimize the use of headers (avoid bloat) and focus further efforts on >things like the MIME part, footers, specialized messages, etc. Add to this the fact that if we have one to three headers, and may I add headers that only the 'list-subscribe' is questioned right now, we should be able to get a 'base' spec published in short order. Then, we could worry about 'how to do it completely right'... regards, Jack - ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) ---------------------------------------------------------------------- Date: 21 Apr 1997 12:46:45 -0400 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Nested mailing lists I am new to this list, so I may be saying things you have already solved: Have you considered the case of nested mailing lists, i.e. when a list is a member of another list. Usually, this is in hierarchical structure: Top-list ! +---------------+-----------------+ sub-list-a sub-list-b sub-list-c The nesting can be in more than the two levels shown above. In this case, *new postings* must be sent to "Top-list" in order to reach all participants. Theoretically one might allow new postings to a sub-list to reach only part of the participants but this is not very commonly used. *unsubscribe* commands, however, must go to the lowest level in the hierarchy, since this is where you are subscribed. Possibly solutions: (a) "List-Post" is only added to a header which does not have any "List-Post", "List-Unsubscribe" alwas replaces any existing "List-Unsubscribe" in the header. I am not sure about how to handle "List-Help" and "List-Subscribe". (b) All headers are added by each level, but in order (the newest on top, as for the "Received" fields), so that the client will know which "List-Post" and "List-Unsubscribe" to use. In the case of "List-Help" and "List-Subscribe" the client might let the users choose which of several choices to use. Advantage with (a): Simple, keeps headers small. Advantage with (b): Gives more power to the user, but can also be confusing unless the user interface of the client handles this well. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 21 Apr 1997 14:28:01 -0400 From: "Clarence C. Wong" <(suppressed)@qualcomm.com> Subject: Re: How many (which) headers? I dunno how any of this could be done without knowledge of the name/address of the list. At 12:20 AM -0400 4/21/97, Joshua D. Baer wrote: >At 11:47 PM -0400 4/18/97, Clarence C. Wong wrote: > >> 1- As part of the confirmation dialog, informing the user that the intended >> action is to subscribe (or unsubscribe) from this list. (e.g. Are you sure >> you want to subscribe to "some-list@host.com?") Grant and others have argued that this warning message should be a summary of the outgoing message. I'd prefer it to be more user friendly, by explicitly informing the user the NAME of the list they're about to subscribe to. >> 2- When subscribing to lists, the MUA could automatically (as an option) >> create filters and mailboxes for the user. When the user clicks on subscribe button (or selects the menu item), how does the MUA know what information to filter on for the newly subscribed list? There's nothing in the three core headers. And as stated before, list-post and list-address could be different for moderated lists. >> 3- MUAs could keep track of lists users have subscribed to or unsubscribed >> from. People who go on vacation often unsubscribe to a bunch of lists and >> then resubscribe later on. Without the name of the list, I suppose the MUA could just keep track of requests by keeping the list-header messages in a mailbox. I think a lot of people do something like that now, but I'd like to see a more friendly UI-- maybe a scrollable list of the NAMES of mailing lists I'm currently subscribed to. >> By the way, has there been any talk of a list-confirmation field? (Did my >> subscription request succeed or fail?) > >How exactly would this be used? Sounds interesting, but I'm not sure I >understand your intention. One of the problems with 2 and 3 is that the request could fail. So the smart thing for MUAs would be to wait until they receive a confirmation message from the list server. (Dunno how hard it would be to add this to the list servers.) Something like: list-confirmation: subscribed list-confirmation: unsubscribed list-confirmation: digested?? list-confirmation: undigested?? And of course, this information isn't useful to the MUA without the name of the list. :) Sorry to introduce yet another header... ---------------------------------------------------------------------- Date: 24 Apr 1997 11:15:43 -0400 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: list-address field At 08:26 17/4/97, Keith Moore wrote: >822 really botched the definition of the Resent-* field. > >I believe that DRUMS has decided that Resent-* is best reserved for >*manual* resending for those rare cases where a message needs to be >manually forwarded to an alternate recipient with the original message >headers intact. (The most common use of resend is probably to forward >a misdirected message to some sort of mail robot. Another possible use >would be for a moderated list -- the list moderator could approve a >new submission by "resend-ing" the message to the list.) I don't know what MLM w3c are using for the www-html list, but this set of headers is interesting, to say the least: >X-List-URL: http://www.w3.org/pub/WWW/MarkUp/Forums#www-html >X-See-Also: http://www.w3.org/pub/WWW/MarkUp/ >Resent-From: www-html@w3.org >X-Mailing-List: archive/latest/7966 >X-Loop: www-html@w3.org >Sender: www-html-request@w3.org >Resent-Sender: www-html-request@w3.org >Precedence: list Notice they are using BOTH Sender: and Resent-Sender: The X-List-URL header points up an issue discussed a while ago. Presumably, if the draft is adopted it will be necessary to dispense with the X-. >X-List-URL: http://www.w3.org/pub/WWW/MarkUp/Forums#www-html ( :-]) James ---------------------------------------------------------------------- End of Digest