List-Header Digest Archive: February 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: -> Announce: List-Header Working Group List by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Announce: List-Header Working Group List by Rob Chandhok <(suppressed)@within.com> -> Re: MailList Specification Headers Proposal 0.0.9 by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> mailto handling (was: Announce: List-Header Working Group List) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by Rob Chandhok <(suppressed)@within.com> -> Re: Variable Expansion by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Variable Expansion by Michele Fuortes <(suppressed)@med.cornell.edu> -> Re: Variable Expansion by Mikael Hansen <(suppressed)@dnai.com> -> Re: Variable Expansion by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: Variable Expansion by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Variable Expansion by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Variable Expansion by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: MailList Specification Headers Proposal 0.0.9 by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: Variable Expansion by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: MailList Specification Headers Proposal 0.0.9 by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: MailList Specification Headers Proposal 0.0.9 by Brad Knowles <(suppressed)@his.com> -> Re: Variable Expansion by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: MailList Specification Headers Proposal 0.0.9 by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: MailList Specification Headers Proposal 0.0.9 by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: MailList Specification Headers Proposal 0.0.9 by (suppressed)@frutiger.staffs.ac.uk -> Re: MailList Specification Headers Proposal 0.0.9 by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: MailList Specification Headers Proposal 0.0.9 by Jason L Tibbitts III <(suppressed)@hpc.uh.edu> -> Re: Variable Expansion by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Headers vs. MIME vs. ? (was: MailList Specification...) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Headers vs. MIME vs. ? (was: MailList Specification...) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> URLs, List Headers, and VRLs(?) by Christopher Allen <(suppressed)@consensus.com> -> Re: MailList Specification Headers Proposal 0.0.9 by Brad Knowles <(suppressed)@his.com> -> Re: Variable Expansion by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> [fwd] headers vs. MIME body part by (suppressed)@cs.utk.edu -> Re: Variable Expansion by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Headers vs. MIME vs. ? (was: MailList Specification...) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Changes in direction (a momentary reflection) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Headers vs. MIME vs. ? (was: MailList Specification...) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Headers & Gateways - how to transport syntax (was: MailList Specification Headers Proposal 0.0.9) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Headers vs. MIME vs. ? (was: MailList Specification...) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: [fwd] headers vs. MIME body part by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> MIME parts? Not yet (re: MailList Specification Headers Proposal) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re:Headers vs.MIMEvs. ? +Soc factor. by Paul Kayak <(suppressed)@bloomington.in.us> -> Re: [fwd] headers vs. MIME body part by Keith Moore (sigh...) <(suppressed)@cs.utk.edu> -> Re: [fwd] headers vs. MIME body part by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: [fwd] headers vs. MIME body part by Keith Moore (I hate having to type in my From address each time I send mail to this list) <(suppressed)@cs.utk.edu> -> Re: [fwd] headers vs. MIME body part by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: MailList Specification Headers Proposal 0.0.9 by Clarence Wong <(suppressed)@qualcomm.com> -> Re: [fwd] headers vs. MIME body part by Brad Knowles <(suppressed)@his.com> -> Re: MailList Specification Headers Proposal 0.0.9 by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: [fwd] headers vs. MIME body part by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: [fwd] headers vs. MIME body part by Brad Knowles <(suppressed)@his.com> -> Re: URLs, List Headers, and VRLs(?) by (suppressed)@akimbo.com -> Re: [fwd] headers vs. MIME body part by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: [fwd] headers vs. MIME body part by Christopher Allen <(suppressed)@consensus.com> -> Re: [fwd] headers vs. MIME body part by (suppressed)@earthchannel.com -> Re: [fwd] headers vs. MIME body part by "Adam C. Engst" <(suppressed)@tidbits.com> -> Re: MailList Specification Headers Proposal 0.0.9 by Clarence Wong <(suppressed)@qualcomm.com> -> Re: [fwd] headers vs. MIME body part by Keith Moore <(suppressed)@cs.utk.edu> -> Re: MailList Specification Headers Proposal 0.0.9 by Keith Moore <(suppressed)@cs.utk.edu> -> Re: [fwd] headers vs. MIME body part by Keith Moore <(suppressed)@cs.utk.edu> -> How to get this published as an RFC by Keith Moore <(suppressed)@cs.utk.edu> -> Re: MailList Specification Headers Proposal 0.0.9 by Keith Moore <(suppressed)@cs.utk.edu> -> Re: [fwd] headers vs. MIME body part by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: [fwd] headers vs. MIME body part by "Adam C. Engst" <(suppressed)@tidbits.com> -> Re: [fwd] headers vs. MIME body part by Merrill Cook <(suppressed)@unidial.com> -> Re: MailList Specification Headers Proposal 0.0.9 by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: [fwd] headers vs. MIME body part by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Variable Expansion by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Sender header (was: MailList Specification Headers Proposal 0.0.9) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: [fwd] headers vs. MIME body part by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> IETF/RFC (was: [fwd] headers vs. MIME body part) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Fast Track Through IETF (was: [fwd] headers vs. MIME body part) by Christopher Allen <(suppressed)@consensus.com> -> Re: Fast Track Through IETF by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by (suppressed)@akimbo.com -> Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: The Promise of Push by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by William Cox <(suppressed)@gramercy.ios.com> -> Re: URLs, List Headers, and VRLs(?) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Are URLs human readable? User Testing by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Are URLs human readable? (was: [fwd] headers vs. MIME body part) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Are URLs human readable? (was: [fwd] headers vs. MIME body part) by Christopher Allen <(suppressed)@consensus.com> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Are URLs human readable? (was: [fwd] headers vs. MIME body part) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Using URLs by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> plaintext variables and servers by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Are URLs human readable? (was: [fwd] headers vs. MIME body part) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Multiple Addresses, lines too long (was: URLs, List Headers, and VRLs(?)) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by (suppressed)@frutiger.staffs.ac.uk -> Re: plaintext variables and servers by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: Using URLs by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Multiple Addresses, lines too long (was: URLs, List Headers, and VRLs(?)) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) by Christopher Allen <(suppressed)@consensus.com> -> Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: Using URLs by "Joshua D. Baer" <(suppressed)@skyweyr.com> -> Re: URLs, List Headers, and VRLs(?) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: URLs, List Headers, and VRLs(?) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: URLs, List Headers, and VRLs(?) by (suppressed)@frutiger.staffs.ac.uk (James Berriman) -> Re: URLs, List Headers, and VRLs(?) by "Adam C. Engst" <(suppressed)@tidbits.com> -> Re: URLs, List Headers, and VRLs(?) by Christopher Allen <(suppressed)@consensus.com> -> Forgetting about variables (was: Using URLs) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Multiple Addresses, lines too long by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Why URLs for our syntax? (was: URLs, List Headers, and VRLs(?)) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: URLs, List Headers, and VRLs(?) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Memphis IETF (was: Fast Track Through IETF) by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Multiple Addresses, lines too long by Christopher Allen <(suppressed)@consensus.com> -> Re: Multiple Addresses, lines too long by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Third Try by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Why URLs for our syntax? (was: URLs, List Headers, and VRLs(?)) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Memphis IETF (was: Fast Track Through IETF) by Keith Moore <(suppressed)@cs.utk.edu> -> Re: Why URLs for our syntax? by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Memphis IETF by Grant Neufeld <(suppressed)@ccs.carleton.ca> -> Re: Memphis IETF (was: Fast Track Through IETF) by Christopher Allen <(suppressed)@consensus.com> -> Re: Memphis IETF (was: Fast Track Through IETF) by Christopher Allen <(suppressed)@consensus.com> -> Re: Why URLs for our syntax? by "Adam C. Engst" <(suppressed)@tidbits.com> -> Re: Memphis IETF (was: Fast Track Through IETF) by "Roger Fajman" <(suppressed)@CU.NIH.GOV> ---------------------------------------------------------------------- Date: 17 Feb 1997 09:13:00 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Announce: List-Header Working Group List There's enough traffic in multiple lists to warrant a list dedicated to work on the Mail List Specification Headers. This effort requires a coalition between listmoms, client software developers, listserver developers, and the mailto url specifiers - so we need a place where all can participate. The new list will be open to everyone who has an interest in the development of the specification (listmoms, client software developers, listserver developers, mailto url specifiers, etc.). To: list-header@arpp.carleton.ca Subject: subscribe For the first few days, please try to Cc to the listmom-talk list to help keep everyone up to date. For the current discussion document see: http://arpp.carleton.ca/midas/mail/list-header.html Please forward this to anyone you think should be aware of this. Thanks. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 17 Feb 1997 10:47:13 -0500 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: Announce: List-Header Working Group List At 9:12 AM -0500 2/17/97, Grant Neufeld wrote: >The new list will be open to everyone who has an interest in the >development of the specification (listmoms, client software developers, >listserver developers, mailto url specifiers, etc.). > > > > To: list-header@arpp.carleton.ca > Subject: subscribe I find it very interesting to see that Grant used the new syntax in the message announcing the list - a perfect application IMHO. So it seems like we should allow for the URL syntax in places other than the header of a message? Would it have been legal for him to write this: Click here to subscribe to the list header mailing list Is the context merely that of a mail client? Does that make it easier to think about variable substitution? Can't you just leave it to the client to allow var substitution or not? Interestingly enough, if you DON'T allow for variable substitution in all contexts, then list management software that requires the user name or email name WON'T be able to have single click subscribe buttons in other contexts, while other systems like SmartList will have that advantage. In other words, if you are going to exploit the "mailto" URL, then do it generally. If clients don't handle the variable substitution, then they will be viewed as missing a nice feature. But they could at least put "your-user-name-here" into the email message and show it to the user. 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: 17 Feb 1997 11:11:42 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: MailList Specification Headers Proposal 0.0.9 Joshua D. Baer wrote: > At 04:10 PM -0500 2/16/97, Grant Neufeld wrote: ... > > We seem to have narrowed it down to {}, ^^, and ** . Does anyone know of > > any uses of these within the context of valid URLs or email addresses? > > Did I miss something? I never saw the *this* before, and still like double > square brackets best [[like this]]. The concern with this is the use of the square brackets in ip-based email addresses (E.g., user@[123.456.789.012]). So, presently it seems like the curly brackets {} are going to be the right choice. Other options are: ``, ^^, or **. BruceLeban@akimbo.com wrote: > Also if > there's really a need to distinguish optional from required parameters, > I'd prefer just writing ``optional-name'' rather than using a different > syntax because this would be more human readable (I used a dash there > rather than a space because I didn't want to to worry about quoting the > space or not). The "optional-" tag makes sense to me. However, I would make it a suffix instead of prefix {{username-optional}}. This makes it easier to leaves things open for future expansion. Client behaviour would then be as follows. example: {{keyword-modifier}} If don't understand {{}} form, just include it as plain text (most clients should already be doing this) If don't understand the keyword, prompt user for value or treat it as plain text (at the client application's discretion) If don't understand the modifier, ignore it (leave it out) Currently, the only modifier we're considering is "optional" which defines the client behaviour such that the client application can choose (or prompt the user to choose) whether or not to include the specified parameter. This can be taken by the client application to modify the above behaviour such that if the client doesn't understand the keyword when the "optional" modifier is present, it can choose to just leave out that parameter. BruceLeban@akimbo.com wrote: > I think we make sure the syntax of the variables is such that it won't > get mangled if it appears unsubstituted, and we should specify that lists > should check for these special values and reject it, Let's say "recommend" that list servers should check for these values and give them special handling (rejection, ignore parameter, etc.). > Perhaps > it should treat [[Joe]] differently from [[name]], realizing that perhaps > a person substituted their name in not realizing they were supposed to > remove the delimiters. Another good suggestion. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 17 Feb 1997 11:14:11 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Variable Expansion At 10:36 AM -0500 2/17/97, Rob Chandhok wrote: > I find it very interesting to see that Grant used the new syntax in the > message announcing the list - a perfect application IMHO. So it seems like > we should allow for the URL syntax in places other than the header of a > message? Would it have been legal for him to write this: > > Click here > to subscribe to the list header mailing list > > Is the context merely that of a mail client? Does that make it easier to > think about variable substitution? Can't you just leave it to the client > to allow var substitution or not? > > Interestingly enough, if you DON'T allow for variable substitution in all > contexts, then list management software that requires the user name or > email name WON'T be able to have single click subscribe buttons in other > contexts, while other systems like SmartList will have that advantage. I think we should keep in mind that the "main" thing we are defining here (as far as I understand it) is the headers... List-Subscribe, List-Unsubscribe, etc. The variables added to the mailto tag are just to accomodate systems such as Listserv and Listproc which require these variables. The mailto URL is already defined... nothing is stopping anyone from using the URL you mention above, in fact, that is exactly what it is for. It's already defined, and in use in many places. Your example is 100% appropriate. However, it really doesn't have anything to do with the List-Headers proposal. What we are discussing is how we can use existing tools like the mailto tag, with minimal modification, in our List-Headers. The purpose is enable automated tools to subscribe and unsubscribe people from mailing lists, without them having to figure out the exact syntax. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 17 Feb 1997 11:46:55 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: mailto handling (was: Announce: List-Header Working Group List) Rob Chandhok wrote: > I find it very interesting to see that Grant used the new syntax in the > message announcing the list - a perfect application IMHO. ... >Would it have been legal for him to write this: > > Click here > to subscribe to the list header mailing list Yes that's legal. Apparently most Mac based mail clients are adopting the new ?Field= mailto syntax (the Eudora Pro beta I'm using supports it). However, older URL clients (like the previous version of Eudora) have 'undefined' behaviour (Eudora would put the whole URL in the To field). > Is the context merely that of a mail client? Yes and no. Only mail aware clients (this includes monolith-type apps like Netscape) will parse the url, but all URL supporting applications should be able to trigger the expanded mailto URLs (if they have a pointer to a mailto supporting application). > Does that make it easier to > think about variable substitution? Can't you just leave it to the client > to allow var substitution or not? That's the direction I'm leaning. > In other words, if you are going to exploit the "mailto" URL, then do it > generally. I agree. It's strictly a matter of the level of parsing understanding the mailto handling clients implement, with fallbacks to support the user filling in the missing details. As I suggested in an earlier message, the client parsing should operate as in: example: {{keyword-modifier}} If don't understand {{}} form, just include it as plain text (most clients should already be doing this) If don't understand the keyword, prompt user for value or treat it as plain text (at the client application's discretion) If don't understand the modifier, ignore it (leave it out) - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 17 Feb 1997 12:10:03 -0500 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: Variable Expansion At 11:09 AM -0500 2/17/97, Joshua D. Baer wrote: >What we are discussing is how we can use existing tools like the mailto >tag, with minimal modification, in our List-Headers. The purpose is enable >automated tools to subscribe and unsubscribe people from mailing lists, >without them having to figure out the exact syntax. Yup, and "subscribe" is an operation that often implies you aren't already on the list. So my point was to be careful to be general enough in your variable substitution syntax (or whatever you are calling it) that it works in the more general case. Like in the body of an email message, or the body of some HTML content. I understand the difference between the "List-Subscribe" header issues and the syntax of the mailto: URL. The hard part is over - most people seem to agree on the names of the headers. So all that's left is the extension of the mailto: syntax to accomodate variable substitution, as far as I can see. What if Grant had sent out a message announcing "list-header" to many people, with this HEADER: List-Subscribe: Can you have more than one of these headers in a message? If not, you darn well better allow for them in the message body. Is there some binding or association between the From: header and the List-Subscribe: header? I think so, which again leads to the conclusion that the same syntax should be supported in message bodies, etc.. >From the user experience perspective, these are important issues. 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: 17 Feb 1997 12:42:14 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Variable Expansion At 12:06 PM -0500 2/17/97, Rob Chandhok wrote: > At 11:09 AM -0500 2/17/97, Joshua D. Baer wrote: > >What we are discussing is how we can use existing tools like the mailto > >tag, with minimal modification, in our List-Headers. The purpose is enable > >automated tools to subscribe and unsubscribe people from mailing lists, > >without them having to figure out the exact syntax. > > Yup, and "subscribe" is an operation that often implies you aren't already > on the list. So my point was to be careful to be general enough in your > variable substitution syntax (or whatever you are calling it) that it works > in the more general case. Like in the body of an email message, or the > body of some HTML content. The thing is, that we're defining a very specific use for these variables. I don't think that anything we come up with will be sufficiently generic to work in the general case. We're taking advantage of the fact that we know what context we are in and who will be decoding these URLs. To do that, we'd need to redefine the mailto URL itself in the global case, which just doesn't seem appropriate for our very specific needs. > I understand the difference between the "List-Subscribe" header issues and > the syntax of the mailto: URL. The hard part is over - most people seem to > agree on the names of the headers. So all that's left is the extension of > the mailto: syntax to accomodate variable substitution, as far as I can see. Agreed. Even that is almost a non-issue at this point... > What if Grant had sent out a message announcing "list-header" to many > people, with this HEADER: > > List-Subscribe: It wouldn't make any sense. However, it would have made just as little sense if he had sent out an announcement with: The format Grant used to announce this list was not made up by us... it's already well defined an in use. He didn't use any of the variables, which was why it was appropriate. > Can you have more than one of these headers in a message? Not with predictable results. Just like multiple "From" headers. > If not, you darn well better allow for them in the message body. Why? It's taken in context. The header refers to that particular message. Extend the analogy to the From or Subject line... it's not like you need some way of specifying THEM in the body, because there is only one per message... > Is there some binding or > association between the From: header and the List-Subscribe: header? I > think so, which again leads to the conclusion that the same syntax should > be supported in message bodies, etc.. I don't see why there is any binding here. The From header is usually (like on this list) the original sender, such as josh@skyweyr.com. The List-Subscribe header is independent of all other headers. It can be an entirely different address or even server than the From, To, or even List-Unsubscribe header. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 17 Feb 1997 14:31:48 -0500 From: Michele Fuortes <(suppressed)@med.cornell.edu> Subject: Re: Variable Expansion Hi, >> What if Grant had sent out a message announcing "list-header" to many >> people, with this HEADER: >> >> List-Subscribe: This format does NOT seem to work in Eudora 3.0. The result is a message with a header like this: To: list-header@arpp.carleton.ca?Subject=subscribe From:Michele Fuortes <(suppressed)@med.cornell.edu> Subject: Does anybody know why? Michele - -- Michele Fuortes, MD/PhD Assistant Professor Cornell University Medical College mailto:mfuortes@med.cornell.edu ---------------------------------------------------------------------- Date: 17 Feb 1997 15:26:35 -0500 From: Mikael Hansen <(suppressed)@dnai.com> Subject: Re: Variable Expansion At 13:53 -0500 2/17/97, Michele Fuortes wrote: >>> List-Subscribe: > >This format does NOT seem to work in Eudora 3.0. >The result is a message with a header like this: > >To: list-header@arpp.carleton.ca?Subject=subscribe >From:Michele Fuortes <(suppressed)@med.cornell.edu> >Subject: > >Does anybody know why? Use a 3.1 beta. - -- Mikael Hansen ---------------------------------------------------------------------- Date: 17 Feb 1997 16:04:26 -0500 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: Variable Expansion >>>>> "MF" == Michele Fuortes <(suppressed)@med.cornell.edu> writes: >>> List-Subscribe: MF> This format does NOT seem to work in Eudora 3.0. Actually, I don't see this syntax standardized anywhere. The W3C refers to RFC1738 for mailto: URLs, and RFC1738 says little more than the following: A mailto URL takes the form: mailto: where is (the encoding of an) addr-spec, as specified in RFC 822 [6]. Within mailto URLs, there are no reserved characters. I would suggest that something which reasonably attempts to become standard not require usage of nonstandard schemes. - -- 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: 17 Feb 1997 16:15:57 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Variable Expansion At 04:01 PM -0500 2/17/97, Jason L Tibbitts III wrote: > >>>>> "MF" == Michele Fuortes <(suppressed)@med.cornell.edu> writes: > > >>> List-Subscribe: > > MF> This format does NOT seem to work in Eudora 3.0. > > Actually, I don't see this syntax standardized anywhere. The W3C refers to > RFC1738 for mailto: URLs, and RFC1738 says little more than the following: See ftp://ftp.internic.net//internet-drafts/draft-hoffman-mailto-url-00.txt ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 17 Feb 1997 17:30:35 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Variable Expansion Rob Chandhok wrote: > The hard part is over - most people seem to > agree on the names of the headers. So all that's left is the extension of > the mailto: syntax to accomodate variable substitution, as far as I can see. Famous last words ;-) > What if Grant had sent out a message announcing "list-header" to many > people, with this HEADER: > > List-Subscribe: Good point - list server software should prevent the transmission of client-originated List- headers to lists. Hmmm, that could be a problem if people start 'faking' list header commands in messages to lists. Does anyone know of list server software that would have problems blocking client submitted List- headers? (I only know ListSTAR, which can.) > Can you have more than one of these headers in a message? I think that should be allowable, with client behaviour being one of: - -pick the first one they come across - -pick the one they understand best (e.g., mailto vs. http) - -offer the user a choice ("would you like the web page or the mail help file?") > Is there some binding or > association between the From: header and the List-Subscribe: header? Only inasmuch as the From address is the list which the Subscribe command applies to. (however, we can't rely on From to be the actual list, so no real 'binding' is to be used). > So my point was to be careful to be general enough in your > variable substitution syntax (or whatever you are calling it) that it works > in the more general case. Like in the body of an email message, or the > body of some HTML content. The command URLs can stand entirely on their own - independent of the list header scheme - and can be used in many different contexts. What the list headers do is provide metadata for the command urls so that clients can identify the purpose of the url (List-Unsubscribe means the url is for issuing the unsubscribe command, etc.). - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 17 Feb 1997 17:32:37 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Variable Expansion Jason L. Tibbitts III wrote: > Actually, I don't see this syntax standardized anywhere. The W3C refers to > RFC1738 for mailto: URLs, and RFC1738 says little more than the following: > > A mailto URL takes the form: ... > I would suggest that something which reasonably attempts to become standard > not require usage of nonstandard schemes. The enhanced mailto URL internet draft by Paul Hoffman and Larry Masinter. ftp://ftp.internic.net//internet-drafts/draft-hoffman-mailto-url-00.txt - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 17 Feb 1997 18:01:40 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Variable Expansion At 05:27 PM -0500 2/17/97, Grant Neufeld wrote: > Rob Chandhok wrote: > > The hard part is over - most people seem to > > agree on the names of the headers. So all that's left is the extension of > > the mailto: syntax to accomodate variable substitution, as far as I can >see. > > Famous last words ;-) > > > What if Grant had sent out a message announcing "list-header" to many > > people, with this HEADER: > > > > List-Subscribe: > > Good point - list server software should prevent the transmission of > client-originated List- headers to lists. Hmmm, that could be a problem if > people start 'faking' list header commands in messages to lists. This will always be a concern with almost any RFC header. Headers are not supposed to be mangled by people... this is really an issue for the mail clients to deal with (and they already do... none that I know of allow you to modify headers on a per-message basis). > > Can you have more than one of these headers in a message? > > I think that should be allowable, with client behaviour being one of: > -pick the first one they come across > -pick the one they understand best (e.g., mailto vs. http) > -offer the user a choice ("would you like the web page or the mail help >file?") The way most other RFC headers are defined is that only one header should present and that the results in other cases are undefined (read - left up to the mail client). Let's not make this more complicated than it needs to be... that seems to have happened with the first try at this... > > So my point was to be careful to be general enough in your > > variable substitution syntax (or whatever you are calling it) that it works > > in the more general case. Like in the body of an email message, or the > > body of some HTML content. > > The command URLs can stand entirely on their own - independent of the list > header scheme - and can be used in many different contexts. > > What the list headers do is provide metadata for the command urls so that > clients can identify the purpose of the url (List-Unsubscribe means the url > is for issuing the unsubscribe command, etc.). I think that in practice this will become a mute point. As I see it, more and more lists are moving to formats which don't require extraneous info in the command. Since all of the information for our variables can be found in the From line, and it's often more reliable than what people type, more and more lists seem to be opting for "simple" commands, or no commands at all in the case of the list-on/list-off addresses. What list software uses these variables besides Listserv? ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 17 Feb 1997 23:06:28 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Variable Expansion Josh wrote: > The thing is, that we're defining a very specific use for these variables. > I don't think that anything we come up with will be sufficiently generic to > work in the general case. We're taking advantage of the fact that we know > what context we are in and who will be decoding these URLs. Yes and no. I think we are specifying special tokens for general use with mailto URLs. We have to be careful about this because if we define and start using these tokens they will be applied generically - on web pages and anywhere else urls are used. The question becomes whether or not the mail clients will accept such urls from non-header sources. I think they should. As ObiWan said: "We must be careful." - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 17 Feb 1997 23:07:45 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: MailList Specification Headers Proposal 0.0.9 Ken Dykes wrote: > >From: Grant Neufeld <(suppressed)@ccs.carleton.ca> ... > >For systems requiring mailback authentication to confirm subscriptions > >(and/or other commands), it would be useful to standardize the mailback > >message format - or at least provide a header which gives instructions > >the client application can use to provide a confirmation interface to > >the user (E.g., Dialog saying: "Confirmation request received for > >subscription to MAIL-LIST. Do you wish to accept the subscription?"). (note that the above paragraph was in the discussion section of the proposal, not in the actual implementation or syntax - it was just a point for consideration) > this would be a gross misfeature. > > the whole point (of my lists) using a confirmation is to show that > a) the recipient actually read the instructions, rented 1 or 2 clues > during their lifetime, and demonstrate they can operate their own email > competently enough to create and send a message to a specified address. In that case, you would choose to not implement support for such a feature on your lists. However, for me the reason for using mail-back confirmation is to confirm that the subscription request was for a valid email address and that the user actually intended to subscribe. Using a system as suggested above would in no way compromise my purposes, and would make things easier for my end users. The list specification headers proposal provides a number of individual tools which can be individually deployed by list hosts (at their discretion) to make things easier for their end users who may use the client software which is being enhanced to support the proposal. > b) the confirmation also, in my mind, gives some marginal legal >protection in > that they read and understood the disclaimers and copyright notices, >etc. > the automation approach would certainly (again in my mind) remove any > legal value of the confirmation. Again, in such a case you would choose to not implement a protocol as suggested above. However, since the paragraph you quote above from the discussion document was just a note about an idea, there remains a lot of room to shape it to meet needs such as some of those you describe. The disclaimers and copyright (etc.) notices could be required to be presented to the user in a dialogue which gives them the options of either accepting or not the requirements for use (much like many installer programs now present the license agreement with an Accept/Decline choice before installing the software). > this whole feature smacks of the 'bulking up' that is claimed to want to > be avoided. Actually, the "standardize the [confirmation] mailback message" section is not really part of the proposal - which is why it's in the 'discussion' section instead of the Syntax or Implementation. It's just an idea that is somewhat related to the proposal, so mentioned there so it won't be forgotten in the consideration of the structuring of the list specification headers. > a general point about the whole approach of using HEADERS. how are forgeries > and spoofing avoided? do HEADERS get PGP or other authentication in most > mail systems? Nope. Spoofing is an issue we're discssing now on the list-header list. A formal resolution has not been reached, but when it has, it will be included in the specification. Do you have any security implementation suggestions (I'm not even remotely an encryption/signature expert)? > the whole automation thing smells. Like a rose to me ;-) (sorry, couldn't resist) > if a person joining an *EMAIL* forum isnt expected to have token competence > at using *EMAIL* then we are about to embrace another round of 'the dumbing > of the internet' This isn't about 'dumbing' the internet. It's about making it smarter so that humans can spend more time using it as a useful tool than worrying about getting their command syntax straight. This is part of making computing accessible and easier for everyone, including the "elite" and "idiots" and all the rest. > if providers want to give trivial interfaces, that's what web-publishing > is for. (don't get me started on how broken the web is...) Just because the web can be applied as a useful tool doesn't mean that we should leave email in its archaic form. Would you have unix constrained to a text only interface so that only the 'really tough' could use it? Personally, I like the convenience of X, it shields me from having to issue commandlines all the time when I'd rather be working (not that I don't get a thrill from a good commandline... ) > trying to *directly* make email and other tools have the look and feel of > the web is wasted energy, and will ultimately attract the same audience > quality. The tools are evolving, as they always have. The secret ways of 'the elite' are transformed into (hopefully) useful tools for 'the masses'. (sorry, I should have put a cheeze warning before that last sentence ;-) > yes, i'm an elitist. I'm an anti-elitist, but I hope you won't let that prevent you from continuing to contribute your thoughts on this proposal. > i believe people should be forced to rub two neurons > together for *some* tools. email is one of them. I adamantly disagree. As my roommate just put it, by that reasoning, people using telephones should have to do the switching manually. Tools are supposed to make things easier, not harder. Email is a tool not a test of technical skill. > just imagine, people not having to read their email to use email. Sounds good to me - I'd love to be able to escape my daily burden of trudging through the piles of email :-S (a problem which I foolishly continue to contribute to by doing things like this proposal which stimulate more piles of mail in response...) > if you insist on this route, make the headers secure and verifiable. giving > spammers and pranksters more automation will just create listmanagers more > work in the long run. That depends on how we list managers secure our systems. If you don't want to secure your lists against misuse of the headers, don't use them. If your users don't want to use them, they can still read the instructions and issue commands manually. This proposal won't take away any of your existing "tools for elitism", but if you choose to use some or all of the headers, they should make it easier for some of your users to use your lists - giving them more time to focus on producing content for the list (or doing other productive things). - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 17 Feb 1997 23:42:49 -0500 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: Variable Expansion (note crosspost) At 05:27 PM 2/17/97 -0500, Grant Neufeld wrote: [major snip] >Does anyone know of list server software that would have problems blocking >client submitted List- headers? (I only know ListSTAR, which can.) LISTSERV blocks client-supplied headers. In fact, to my annoyance, it won't even allow the list *OWNER* to add headers. (I wanted to add "Precedence: List" to my list's headers to shut up some vacation responders.) Cheers, Stan ---------------------------------------------------------------------- Date: 18 Feb 1997 01:15:13 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Variable Expansion Joshua D. Baer wrote: > > > Can you have more than one of these headers in a message? ... > The way most other RFC headers are defined is that only one header should > present and that the results in other cases are undefined (read - left up > to the mail client). Let's not make this more complicated than it needs to > be... that seems to have happened with the first try at this... Okay, so we'll make the multiple header thing illegal with client behaviour undefined. > > What the list headers do is provide metadata for the command urls so that > > clients can identify the purpose of the url (List-Unsubscribe means the url > > is for issuing the unsubscribe command, etc.). > > As I see it, more > and more lists are moving to formats which don't require extraneous info in > the command. Since all of the information for our variables can be found > in the From line, and it's often more reliable than what people type, more > and more lists seem to be opting for "simple" commands, or no commands at > all in the case of the list-on/list-off addresses. A good point, but I think we still need to try to figure out how to support commands containing variables that need to be determined by the client. For a lot of lists, though, the 3 core list headers and the enhanced mailto URLs cover what is needed. While we continue to explore the issue of variable declarations with URLs, we should look at implementing the core headers and give this thing a whirl. must sleep now... - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Feb 1997 01:16:23 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: MailList Specification Headers Proposal 0.0.9 Ken Dykes wrote: > more i think about the more the friendly letters MIME pop infront of my eyes. Very interesting idea - I like it. However, I don't think the client software is sufficiently equipped to handle MIME objects like that yet (soon I hope). Consider the negative reaction to the deployment of the PGP MIME objects (a good idea in my opinion, unfortunately the software isn't equipped to handle it) > this ill conceived (imho) proposal will only be made even more ill if > implemented as simple headers in the mail message. Well, I won't take that personally - especially since you are adding some useful points like this MIME suggestion (which has a LOT of potential in the future when MIME is properly supported). > a) body parts are much more amenable to authentication and perhaps even > encryption (hey, why rule out the concept of a 'secure' MLM?) Hmmm, sounds good to me. But, again, we're not there yet in terms of MIME support. > b) body parts are much more likely to pass unscathed through legacy-code > (and vendor-obstinate) mail gateways But not through mail clients which either don't understand MIME, or end up dumping unrecognized mime types into files somewhere in the user's file system (which can lead to a lot of meaningless files as in the PGP MIME case). > c) presentation control information and rich text stuff does not belong > in the general headers. > this proposal is nothing more than a richtext language specific > to mailing list administration functions. I disagree. It's about communicating command structures to client software in a clear and specific syntax. It is also being designed to be at least partially human readable (in as much as URLs are human readable) for users who do not have list header aware clients (everybody at the moment, but hopefully soon a lot fewer people). > d) while claiming to try an not do so, this proposal is simply BULKING UP > the headers. "An important consideration in this discussion is avoiding adding a tonne of new headers..." The proposal does add some headers, but we're trying to minimize the number added. You may keep it down to zero on your lists, if that's what you think is appropriate. > and no matter how 'unbulky' you start with, this stuff is bound to > be extended in the future. keep bulk in the body. Not a usable option at this time. When it is we can implement it. As to future extensions, (as I've said too many times already in this message) they will hopefully lead to MIME (or whatever is the most useful choice at the time) when that becomes usable. > keep it out of the headers. Nope. At least not my headers. > encapsulate it. > make the encapsulation the last MIME body part for friendliness to > older email client programs. (or rather, dont insist it be the first part). Makes sense to me. I look forward to being able to actually implement it. Oh, yeah. The other big reason for using headers is that they're easy for the majority of list managers to implement where as something like MIME objects will require changes to the list server applications. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Feb 1997 01:42:28 -0500 From: Brad Knowles <(suppressed)@his.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 At 12:48 AM -0500 2/18/1997, Grant Neufeld wrote: >> a) body parts are much more amenable to authentication and perhaps even >> encryption (hey, why rule out the concept of a 'secure' MLM?) > >Hmmm, sounds good to me. But, again, we're not there yet in terms of MIME >support. There is a fundamental problem here -- MUAs that don't support new MIME bodypart types are *precisely* the same ones that are least likely to support different user-added headers. With them, you're screwed either way. Given that, you're better off not hobbling all MUA and MTA implementations world-wide with a backwards-looking solution that will be, at very best, only partially successful. Instead, you're better off pointing to a forward-looking solution that may have some problems in the short term, but which will give you infinitely more flexibility in the future. And there's nothing stopping you from implementing a new type of message (either manual or machine-generated) using the same syntax as is used in the new MIME bodypart type, but which is left all by itself without MIME encapsulation/encoding. In fact, you're better of specifying this first, and then saying "okay, you take a message of type Slarty Bartfast and you encapsulate it in MIME by making the Content-type "application/SMMP, etc...". - -- Brad Knowles, MIME/PGP: brad@his.com comp.mail.sendmail FAQ Maintainer finger brad@his.com for my PGP Public Keys and Geek Code The comp.mail.sendmail FAQ is at ---------------------------------------------------------------------- Date: 18 Feb 1997 01:43:56 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Variable Expansion At 12:09 AM -0500 2/18/97, Grant Neufeld wrote: > > As I see it, more > > and more lists are moving to formats which don't require extraneous info in > > the command. Since all of the information for our variables can be found > > in the From line, and it's often more reliable than what people type, more > > and more lists seem to be opting for "simple" commands, or no commands at > > all in the case of the list-on/list-off addresses. > > A good point, but I think we still need to try to figure out how to support > commands containing variables that need to be determined by the client. I agree. Just pointing out the obvious... :) > While we continue to explore the issue of variable declarations with URLs, > we should look at implementing the core headers and give this thing a whirl. Agree again! I already implemented this on ListMom-Talk, and will move it to all of the other lists I sponsor/host in the near future. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 18 Feb 1997 01:45:36 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 At 12:48 AM -0500 2/18/97, Grant Neufeld wrote: > Oh, yeah. The other big reason for using headers is that they're easy for > the majority of list managers to implement where as something like MIME > objects will require changes to the list server applications. One of the biggest reasons, IMHO. This is actually implementable in the short term. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 18 Feb 1997 02:00:02 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 At 01:39 AM -0500 2/18/97, Brad Knowles wrote: > At 12:48 AM -0500 2/18/1997, Grant Neufeld wrote: > > >> a) body parts are much more amenable to authentication and perhaps even > >> encryption (hey, why rule out the concept of a 'secure' MLM?) > > > >Hmmm, sounds good to me. But, again, we're not there yet in terms of MIME > >support. > > There is a fundamental problem here -- MUAs that don't support > new MIME bodypart types are *precisely* the same ones that are least > likely to support different user-added headers. With them, you're > screwed either way. Except the list headers are also easily human-parsable. > Given that, you're better off not hobbling all MUA and MTA > implementations world-wide with a backwards-looking solution that > will be, at very best, only partially successful. Instead, you're > better off pointing to a forward-looking solution that may have some > problems in the short term, but which will give you infinitely more > flexibility in the future. An interesting point. I'm starting to agree that a MIME implementation is just too nice to put off for later. If only mail clients supported MIME better; we could do such cool stuff! > And there's nothing stopping you from implementing a new type of > message (either manual or machine-generated) using the same syntax as > is used in the new MIME bodypart type, but which is left all by > itself without MIME encapsulation/encoding. Where would this go? On every message, or only on some? Are you suggesting that we move this info to a standard footer added to the body? That might not be such a bad idea, since mail clients could parse it or it could be left for people to read. It's a less restricted text area, as well. However don't many people find footers on mailing list mail offensive/annoying? They never bothered me much, but I've heard others complain. > In fact, you're better of specifying this first, and then saying > "okay, you take a message of type Slarty Bartfast and you encapsulate > it in MIME by making the Content-type "application/SMMP, etc...". I see. If we could implement this soon, I'd much rather see it in this format as well. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 18 Feb 1997 05:35:50 -0500 From: (suppressed)@frutiger.staffs.ac.uk Subject: Re: MailList Specification Headers Proposal 0.0.9 On Tue, 18 Feb 1997 01:39:50 -0500 Josh wrote: >At 12:48 AM -0500 2/18/97, Grant Neufeld wrote: > >> Oh, yeah. The other big reason for using headers is that they're easy for >> the majority of list managers to implement where as something like MIME >> objects will require changes to the list server applications. > >One of the biggest reasons, IMHO. This is actually implementable in the >short term. > >~Josh Unless, as Stan (I believe) pointed out, you are using listserv. Actually, I suspect the number of list admins who can easily add custom headers is in a minority. On the other hand, some will find it easy to add a mime attachment (perhaps simply as a message footer - a common feature on lists I subscribe to). ( :-]) James ---------------------------------------------------------------------- Date: 18 Feb 1997 06:28:03 -0500 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: MailList Specification Headers Proposal 0.0.9 Brad Knowles <(suppressed)@his.com> wrote: > And there's nothing stopping you from implementing a new type of >message (either manual or machine-generated) using the same syntax as >is used in the new MIME bodypart type, but which is left all by >itself without MIME encapsulation/encoding. > > In fact, you're better of specifying this first, and then saying >"okay, you take a message of type Slarty Bartfast and you encapsulate >it in MIME by making the Content-type "application/SMMP, etc...". Yes, that's almost exactly what I had in mind when I suggested that we come up with a separate syntax description file which could be retrieved via a url in the list header or included as an attachment. I suspect that the most flexible long-term approach is a minimal set of standard list headers, combined with a new MIME type. BTW, shouldn't that be Slartibartfast? If the answer is "42", perhaps the Ultimate Question to Life, the Universe and Everything is: "How many headers were included in God's final message to his creation?". Just for those who did not see the discussion on listmom-talk (apologies for the bandwidth if you did): >Date: Fri, 10 Jan 1997 01:54:20 +0000 >From: james@frutiger.staffs.ac.uk (James Berriman) >Subject: Re: MailList Specification Headers Proposal >To: listmom-talk@skyweyr.com >Mime-Version: 1.0 >Precedence: Bulk >Reply-To: listmom-talk@skyweyr.com > >I like the idea that Grant Neufeld put forward, but I feel personally that >the specification of list syntax would be better removed to a separate >document. Provided that the list header allows such a document to be >automatically retrieved by the mail client, this should be more efficient. > >A few thoughts: > >To handle a mailing list the MTA needs to know: > >1. The canonical name or unique ID for the list. > (i.e. a unique string that does not change, even if the list address does). >2. How to retrieve the admin address and command syntax by mail. > (e.g. mailto:listserver@my.domain?subject=commands) >3. The date (UTC) that the above information last changed. >4. A TTL value (seconds). > >All clients would need to understand 1 & 2 (a minimal implementation could >get by with just this). So two X-headers would suffice. Something like: > >X-List: AutoShare-Talk, >X-TTL: Thu, 9 Jan 97 16:09:05 -0000, 1209600 > >The document returned should specify all the admin. information required >to perform basic list management, in a standardised format (Grant has made >a good start here with the syntax definitions). For the sake of argument, >call it a Listserver Definition Document (LDD). > >This would make life very easy. If you change hosts or rename the server, >upgrade or change your software, savvy client software can detect this >from the last modification date in the X-header and automatically retrieve >the new LDD. > >In most cases the client software will only have to retrieve a new copy of >the file when the ttl expires (thus saving considerable bandwidth). > >For security reasons, I believe it would be necessary for the mailto: >domain in the X-header to match the domain of the admin address(es) >specified in the LDD. > >What do people think? > >( :-]) James >Date: Fri, 10 Jan 1997 10:11:54 +0000 >From: james@frutiger.staffs.ac.uk (James Berriman) >Subject: Re: MailList Specification Headers Proposal >To: listmom-talk@skyweyr.com >Mime-Version: 1.0 >Precedence: Bulk >Reply-To: listmom-talk@skyweyr.com > [snip] > >One of the advantages of having a separate Listserver Syntax Description is >that you would have the flexibility to deploy it in several ways (after >all, it's only a string of text!). > >There would be nothing to stop you including this information as an >attachment when you send out subscription confirmations (so the client can >immediately act on it). > >Does this answer your need? > >If not, it would still be possible for you to include this information with >every outgoing message, while leaving other admins with the *option* to >save the bandwidth. > >Likewise, with a stand-alone text format you could include the LDD as meta >information in a web page, allowing the browser to automatically handle >list management with no need to build web forms. > >Or how about a browser plug-in that just archives LDD files for you as you >surf the web and presents a unified interface to all your lists? LDDs could >be unobtrusively updated in the background while you are browsing. > >Whatever the outcome of this discussion, I think it would be immensely >useful to have a standardised machine-and-human readable syntax description >standard for listservers. > >As long as you have a syntax description that the client can unambiguously >understand, you're most of the way there :-) > >( :-]) James ---------------------------------------------------------------------- Date: 18 Feb 1997 11:33:01 -0500 From: Jason L Tibbitts III <(suppressed)@hpc.uh.edu> Subject: Re: MailList Specification Headers Proposal 0.0.9 >>>>> "JDB" == Joshua D Baer <(suppressed)@skyweyr.com> writes: JDB> One of the biggest reasons, IMHO. But not _the_ biggest, IMHO. That would be reserved for the extreme bogosity of having to make every message a MIME multipart thing and incur all of the baggage that goes along with that. A message that was plain text with no MIME crud should stay that way unless a gateway has to encode it. A message that is a single part should stay a single part if at all possible. - J< ---------------------------------------------------------------------- Date: 18 Feb 1997 15:13:06 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Variable Expansion Something just occurred to me. Lists requiring variable substitution in control messages could do the following: mailto:control@server.com?Body=subscribe%20somelist%20%5BYour%20Name%20Here%5D which would produce a message: To: control@server.com Body: subscribe somelist [Your Name Here] In cases where the square brackets were used like this, client software would be expected to bring up the message window for the user to modify, perhaps presenting a dialog explaining that some user intervention is required. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 18 Feb 1997 15:13:41 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Headers vs. MIME vs. ? (was: MailList Specification...) [I reply to a bunch of different people in this message] I think this is important to make clear: Implementing the headers does not mean we can't also use the MIME idea. (or any other idea that might come up) Brad Knowles <(suppressed)@his.com>wrote > Ken does have one inescapable point -- all this automation and > improvement of interaction with MLMs should be done through a new > MIME bodypart type, and not through headers As I said in some other messages, MIME is not a deployable solution at this time. Far too few clients support MIME at all - and those that do would require upgrading to properly recognize and handle a specialized MIME object. Not to mention the difficulties in upgrading listservers to generate the new MIME parts. > I recommend you get the Internet Mail Consortium involved in > these efforts, since Paul Hoffman and Dave Crocker have been down a > lot of the same roads in the past on other projects, I've already been corresponding with Paul who has been providing me with some useful recommendations. Hopefully I can talk him into adding this list to his no-doubt overflowing in box... > MUAs that don't support > new MIME bodypart types are *precisely* the same ones that are least > likely to support different user-added headers. But headers don't cause the problems for those clients that specialized MIME parts do. Headers also don't wind up as an unwanted clutter of separate files in download folders (which is what happens with some of the MIME enabled clients). > Given that, you're better off not hobbling all MUA and MTA > implementations world-wide with a backwards-looking solution that > will be, at very best, only partially successful. Instead, you're > better off pointing to a forward-looking solution that may have some > problems in the short term, but which will give you infinitely more > flexibility in the future. The point of this proposal is to reduce existing problems - not create new ones. Using MIME parts now will add problems. Certainly we need to be designing for the future, but we also need to solve the problems that we have today. The headers will reduce the problems we have today. As software improves, MIME objects (or whatever else emerges) may be able to eliminate these problems in the future. > And there's nothing stopping you from implementing a new type of > message (either manual or machine-generated) using the same syntax as > is used in the new MIME bodypart type, but which is left all by > itself without MIME encapsulation/encoding. That is something we should definitly be looking at. What we define in the more advanced syntax should not be defined by it's transport mechanism (MIME encapsulation, ASCII message, etc.) but should instead be structured so that it can be deployed through multiple mechanisms depending on the circumstance. It may make sense to have the protocol communicated through a MIME object, or a plaintext message, or a web page, or even a telephathic uplink (who knows what the future brings... ;-) The URLs we're presently using can be deployed anywhere. All the headers do is provide meta-data about what the specific function of the URL is. A MIME part could take the same URLs and present them as: Help: Unsubscribe: etc... > In fact, you're better of specifying this first, and then saying > "okay, you take a message of type Slarty Bartfast and you encapsulate > it in MIME by making the Content-type "application/SMMP, etc...". Personally, I'd like to see the mime-type be something like "meta/list-control" since it's metadata we're presenting. But that's jumping ahead a bit... Joshua D. Baer wrote: > Are you suggesting that we move this info to a standard footer added to the > body? That might not be such a bad idea, since mail clients could parse it > or it could be left for people to read. It's a less restricted text area, > as well. Not a bad spot for initial deployment. As MIME gets adopted, the protocol data could then be MIME deployed. > However don't many people find footers on mailing list mail > offensive/annoying? They never bothered me much, but I've heard others > complain. People will complain no matter what is done. If you have the extra protocol info in your list messages, they'll complain about the 'extra' info. If you don't, they'll complain about not being able to find the unsubscribe command (or use the wrong syntax which gets posted to the list resulting in complaints from other subscribers). With this whole protocol being prescribed as optional, we can use the key statement of the internet: "If you don't like what I'm offering, give me useful suggestions or try somewhere else (or roll your own!)" James Berriman wrote: > >One of the biggest reasons, IMHO. This is actually implementable in the > >short term. ... > Unless, as Stan (I believe) pointed out, you are using listserv. Actually, I > suspect the number of list admins who can easily add custom headers is in a > minority. Perhaps, but if list software authors come on board (as some already are), things may become very easy for admins to implement the headers. > On the other hand, some will find it easy to add a mime attachment (perhaps > simply as a message footer - a common feature on lists I subscribe to). Again, it will be up to the individual list admins - but I recommend deployment of such MIME objects at this time. They will generate new problems for end users who we're trying to make things easier for. Since the core headers are pretty much resolved (there doesn't seem to remain any debate on the syntax - just whether headers are a good idea or not), I think we can move on to working on defining the more comprehensive syntax as well as deployment mechanisms. Currently, I see the following deployment mechanisms: MIME object (whether as part of a mail message or retrieved via http, etc. maybe a header could point to the http retrieval?) ASCII footer (on mail messages) ASCII message (requested by the client when needed, or delivered by the list server at subscribe time or when updated) James Berriman wrote: > I suspect that the > most flexible long-term approach is a minimal set of standard list headers, > combined with a new MIME type. Bang on. I think this is what we need to do. > perhaps the > Ultimate Question to Life, the Universe and Everything is: "How many > headers were included in God's final message to his creation?". !!! We can all die fulfilled now. The universe has figured itself out :-) Jason L Tibbitts III wrote: > That would be reserved for the extreme > bogosity of having to make every message a MIME multipart thing and incur > all of the baggage that goes along with that. A message that was plain > text with no MIME crud should stay that way unless a gateway has to encode > it. A message that is a single part should stay a single part if at all > possible. To me, this is all leading to the need for more intelligence on the part of server and client apps. List servers should be able to determine, on an individual basis, whether users accept certain mail features (MIME, UUencode, HQX encode, PGP MIME, etc.), and send mail with the best set of features for that user. Of course, that raises issues of no longer sending identical messages to all members of a list, costing more bandwidth. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> "I'm an extremist for tolerance." - jms (creator/producer/writer of Babylon 5) ---------------------------------------------------------------------- Date: 18 Feb 1997 15:54:47 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Variable Expansion At 02:56 PM -0500 2/18/97, Grant Neufeld wrote: > Something just occurred to me. > > Lists requiring variable substitution in control messages could do the > following: > > >mailto:control@server.com?Body=subscribe%20somelist%20%5BYour%20Name%20Here%5D > > > which would produce a message: > > To: control@server.com > Body: subscribe somelist [Your Name Here] This seems much simpler and cleaner than what we were discussing before. I like it... ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 18 Feb 1997 15:55:58 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Headers vs. MIME vs. ? (was: MailList Specification...) At 03:11 PM -0500 2/18/97, Grant Neufeld wrote: > But headers don't cause the problems for those clients that specialized > MIME parts do. Headers also don't wind up as an unwanted clutter of > separate files in download folders (which is what happens with some of the > MIME enabled clients). However, I'm leaning more and more toward body footers. These have the added advantage of being somewhere a clueless person has a slight chance of seeing them. > James Berriman wrote: > > I suspect that the > > most flexible long-term approach is a minimal set of standard list headers, > > combined with a new MIME type. Agreed. And a body interpretation of the MIME data. > List servers should be able to determine, on an individual basis, whether > users accept certain mail features (MIME, UUencode, HQX encode, PGP MIME, > etc.), and send mail with the best set of features for that user. How would that be done? Is there any way to get this info into the messages sent out by clients, so that the listserver could determine this automatically, _without_ the user having to set a bunch of configuration options? > Of course, that raises issues of no longer sending identical messages to > all members of a list, costing more bandwidth. And about 5 more configuration possibilities to confuse users, if it's not done carefully. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 18 Feb 1997 20:52:31 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: URLs, List Headers, and VRLs(?) I talked with the people that proposed the new mailto: syntax, and in general they were against it for URL purposes, but thought it was fine for purposes of another header. Personally, I'm still uncomfortable with it. I also think that if we are to do variable substitution in URL/VRLs, it should be done with some regular-expression-like syntax rather than inventing our own. - --- begin forwarded text Sender: masinter@parc.xerox.com Date: Tue, 18 Feb 1997 12:23:44 PST From: Larry Masinter <(suppressed)@parc.xerox.com> Organization: Xerox PARC MIME-Version: 1.0 To: Christopher Allen <(suppressed)@consensus.com> CC: "Paul E. Hoffman" <(suppressed)@imc.org> Subject: Re: X-List Header specifications Let me propose suggesting a different proposition: Let us suppose you had something you called "URL with variable substitution". Then the variable substitution should apply to all kinds of URLs, not just the ones with "mailto:" in the front of them. And maybe you shouldn't call it a "URL" any more, since variable substitution itself means that the RL (Resource Locator) is no longer Uniform, since -- just because you're defining variables to be substituted, different people will get different resource locators at different times. So call this a VRL (Variable Resource Locator), and you might even wind up with vrl: where you can do all the variable substitution you want. You might even convince browser makers that inside their HTML documents that a "HREF" really contains a VRL and not a URL. - --- end forwarded text - ------------------------------------------------------------------------ ..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: 19 Feb 1997 01:12:58 -0500 From: Brad Knowles <(suppressed)@his.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 At 1:55 AM -0500 2/18/1997, Joshua D. Baer wrote: >> There is a fundamental problem here -- MUAs that don't support >> new MIME bodypart types are *precisely* the same ones that are least >> likely to support different user-added headers. With them, you're >> screwed either way. > >Except the list headers are also easily human-parsable. Unfortunately, human parsability is not the primary issue here -- what will survive most SMTP gateways is, and within that set of limitations, making things as easily machine and human parsable as possible. >An interesting point. I'm starting to agree that a MIME implementation is >just too nice to put off for later. If only mail clients supported MIME >better; we could do such cool stuff! Do it now, and they will come. Especially ones like exmh that can be easily extended without having to go get a whole new version. >> And there's nothing stopping you from implementing a new type of >> message (either manual or machine-generated) using the same syntax as >> is used in the new MIME bodypart type, but which is left all by >> itself without MIME encapsulation/encoding. > >Where would this go? On every message, or only on some? Only on those messages that need it -- you'd create a new type of message automatically generated by the MUA that has the same sorts of things in the "body" that you've been proposing to put into headers. The MUA also understands the automated responses, and deals with them appropriately. At this stage, you might want to get some folks involved that are actually implementing MUAs, especially ones that represent a large community. Me, I'd start with the guys at Qualcomm doing Eudora. Guys like Paul Hoffman and Dave Crocker from the IMC plus some knowledgable types from Qualcomm should have the experience necessary to help you avoid the "standard" pitfalls, and move towards a real workable standard sooner rather than later. - -- Brad Knowles, MIME/PGP: brad@his.com comp.mail.sendmail FAQ Maintainer finger brad@his.com for my PGP Public Keys and Geek Code The comp.mail.sendmail FAQ is at ---------------------------------------------------------------------- Date: 19 Feb 1997 07:00:40 -0500 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: Variable Expansion At 19:56 18/2/97, Grant Neufeld wrote: >mailto:control@server.com?Body=subscribe%20somelist%20%5BYour%20Name%20Here%5D > >which would produce a message: > > To: control@server.com >Body: subscribe somelist [Your Name Here] Now that's a nice idea. Looks so obvious when you point it out :-) ( :-]) James ---------------------------------------------------------------------- Date: 20 Feb 1997 00:32:19 -0500 From: (suppressed)@cs.utk.edu Subject: [fwd] headers vs. MIME body part [sigh...I subscribe to lists using a subaddress so that list traffic will automagically go to the right folder. Unfortunately this list won't accept mail from my normal address!] - ------- Forwarded Message From: Keith Moore <(suppressed)@cs.utk.edu> To: list-header@arpp.carleton.ca cc: moore@cs.utk.edu Subject: headers vs. MIME body part In-reply-to: Your message of "Wed, 19 Feb 1997 00:28:47 EST." Date: Wed, 19 Feb 1997 16:03:02 -0500 I strongly support defining a new header field or two to convey minimal mailing list information. A new MIME body part would also be useful for more detailed information. In my mind, each message from a list would include a small amount of header information, describing only the bare essentials of the list -- how to get unsubscribed, how to send mail to a human maintainer, etc. It should be in very compact form so as to have minimal overhead; yet it should be easy to parse to encourage implementation. That would almost give user agents enough information to implement an "unsubscribe" command which would automagically Do The Right Thing. The UA would still need to know what address the user used to subscribe to that list, which is a much harder problem to solve in general. I once proposed a List-Info header field with the following syntax: list-info-field = "List-Info" ":" parameter-list parameter-list = parameter *( ";" parameter ) parameter = name "=" value name = token value = token token = atom / quoted-string where names are things like: robot address of the list server robot (could also be a human) rlanguage command language understood by the robot (majordomo, listserv, listproc, smartlist, etc.... the idea being to document a subset of existing list server languages, and standardize a new language with its own name) human address of the human list maintainer url URL of the list web page (if any) archive URL of the mailing list archive e.g. List-Info: robot="info-mime-request@cs.utk.edu"; human="postmaster@cs.utk.edu"; rlanguage="majordomo" (I'm not hugely attached to having a single header field, but I do think there's a useful psychological effect with doing so. There's a long-observed tendency to include more header fields than necessary -- a sort of creeping featurism. On the other hand, a single long header field looks ugly, so implementors resist putting things in there that aren't necessary.) Re the MIME body part: I'd hate to see a MIME body part attached to every message from a list. On the other hand, I could imagine an application/mailing-list-info type that listed everything you would ever want to know about a list. It wouldn't be attached to every message, but it could be included as an attachment to "congratulations, you're now on the FOO list" messages or help response messages, it could be downloadable from web servers when you click on a list name, etc. > Unfortunately, human parsability is not the primary issue here -- > what will survive most SMTP gateways is, and within that set of > limitations, making things as easily machine and human parsable as > possible. The Internet mail architecture has always been that new header fields can be added at any time. Mail transports aren't supposed to mung headers, especially not fields that they don't understand. If in adding this extension you have to penalize some components, it's better to penalize broken mail transports that strip header fields, than to penalize correctly functioning UAs. A related issue: many UAs barely support MIME and are particularly bad about effectively replying to MIME messages -- they don't know which parts of the old message to quote, they don't undo quoted-printable or base64'ed text before composition, they leave 8bit characters in a message labeled as 7bit, etc. So if lists start adding MIME body parts to each message, the list members are going to see a lot of cruft in the replies to those messages. Such a feature, despite the best intentions, would be very unpopular. For me, the primary issues are ease of implementation in existing mailing list software and UAs, and making it have minimal overhead. If this thing turns out to be easy to implement and it has low overhead, the "free" user agents and mailing lists will start supporting it almost immediately. The commercial ones will support it in one or two release cycles. Finally, from several years' experience with the Internet standards process, I encourage making the proposal as simple as it can be, so long as it solves the basic problem. A simple proposal that cleanly solves one or two well-defined problems (while still leaving room for extensibility) won't require nearly as much discussion to reach consensus, as a complex proposal that tries to solve a wide range of problems. Keith Moore - ------- End of Forwarded Message ---------------------------------------------------------------------- Date: 20 Feb 1997 10:02:40 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Variable Expansion At 3:50 PM -0500 97/2/18, Joshua D. Baer wrote about my suggestion for variable fields in URLs: mailto:control@server.com?Body=subscribe%20somelist%20%5BYour%20Name%20Here%5D > This seems much simpler and cleaner than what we were discussing before. I > like it... And for those client authors who want to be clever, the hex encoded square brackets (%5B, %5D) can be parsed and the user presented with a dialog prompting them to 'fill in the blank'. For example, the above URL might produce a dialog like: Command message to <(suppressed)@server.com> requires your input. Please enter a value for the field "Your Name Here": ___________________________ | Your Name Here | (<-- text entry field) |Cancel| |OK| - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 10:18:40 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Headers vs. MIME vs. ? (was: MailList Specification...) At 3:49 PM -0500 97/2/18, Joshua D. Baer wrote: > However, I'm leaning more and more toward body footers. These have the > added advantage of being somewhere a clueless person has a slight chance of > seeing them. What I'm thinking now is: First we get the client authors to start supporting the core headers. While that's going on, figure out the expanded command specification syntax. While that's going on, figure out the MIME structure we're going to use. And while all that's going on, figure out the message footer structure to use. Then, when the above 3 are done, we get the client authors to support them. The way I see it, we need to provide multiple ways of presenting/transporting the syntax (which should be uniform) to meet the needs of different lists. > > List servers should be able to determine, on an individual basis, whether > > users accept certain mail features (MIME, UUencode, HQX encode, PGP MIME, > > etc.), and send mail with the best set of features for that user. > > How would that be done? Is there any way to get this info into the > messages sent out by clients, so that the listserver could determine this > automatically, _without_ the user having to set a bunch of configuration > options? We could take a cue from http clients which provide the Accepts: header. An expanded subscribe syntax might see the mail client including the Accepts: info to the subscription control address. There could also be user configurable settings through commands to the server. Which would complicate matters further, so should be very well thought out before being implemented. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 10:23:45 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Changes in direction (a momentary reflection) You know, the current syntax and structure of this proposal looks almost nothing like what I originally put forward - which is the way it should be. As one of my professors frequently said: "Always throw out your prototypes." My intent/purpose is still the same, but my understanding of how it needs to be done has been seriously changed thanks to the discussion everyone (even the detractors) has put forward. I just wanted to stop and say thanks to all of you for the good work. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 10:58:22 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Headers vs. MIME vs. ? (was: MailList Specification...) At 10:09 AM -0500 2/20/97, Grant Neufeld wrote: > First we get the client authors to start supporting the core headers. Is there anything left to hammer out here? If not, we should try to get this somewhere on it's own page so we have something simple to point client developers at. A page which just lists the core header implementation. Did we agree on the simpler method of variable substitution? ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 20 Feb 1997 11:00:23 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 8:48 PM -0500 97/2/18, Christopher Allen wrote: > Personally, I'm still uncomfortable with it. I also think that if we are to > do variable substitution in URL/VRLs, it should be done with some > regular-expression-like syntax rather than inventing our own. As I recently suggested, it might be best to not provide a specialized variable syntax at all, but instead just use hex encoded square brackets (%5B, %5D) to enclose human readable descriptions of fields to be filled in. This leaves things open for the client applications to specially interpret the square brackets or not (leaving them as human readable content in a message) - and doesn't prevent enhancement of the content of the variable since any valid URL characters can be put in there. The simple solution is often the best solution. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 11:01:28 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Headers & Gateways - how to transport syntax (was: MailList Specification Headers Proposal 0.0.9) At 12:28 AM -0500 97/2/19, Brad Knowles wrote: > Unfortunately, human parsability is not the primary issue here -- > what will survive most SMTP gateways is, and within that set of > limitations, making things as easily machine and human parsable as > possible. So the headers won't survive some gateways. That doesn't mean we shouldn't implement them. People behind those gateways won't be any worse off if we use the headers, and those whose gateways work will be better off. Nothing is lost, something is gained. > >I'm starting to agree that a MIME implementation is > >just too nice to put off for later. ... > Do it now, and they will come. Especially ones like exmh that > can be easily extended without having to go get a whole new version. I agree that we should be designing the MIME structure now. There may even be a few lists out there which can safely implement it without annoying a bunch of their users. I personally won't be implementing MIME on my lists for some time to come since many of my users are not equipped to handle it. > >> And there's nothing stopping you from implementing a new type of > >> message (either manual or machine-generated) using the same syntax as > >> is used in the new MIME bodypart type, but which is left all by > >> itself without MIME encapsulation/encoding. > > > >Where would this go? On every message, or only on some? > > Only on those messages that need it -- you'd create a new type of > message automatically generated by the MUA that has the same sorts of > things in the "body" that you've been proposing to put into headers. > The MUA also understands the automated responses, and deals with them > appropriately. The most obvious to me are the command acknowledgement messages. Additionally, the monthly help file mail out that some lists are using now would be a great place to include this, especially since they can be used to update the client if the syntax changes. > At this stage, you might want to get some folks involved that are > actually implementing MUAs, especially ones that represent a large > community. Me, I'd start with the guys at Qualcomm doing Eudora. Unofficially, there are some client authors and some list server software authors reading this list - I'll let them introduce themselves if they want to. > Guys like Paul Hoffman and Dave Crocker from the IMC plus some > knowledgable types from Qualcomm should have the experience necessary > to help you avoid the "standard" pitfalls, and move towards a real > workable standard sooner rather than later. If anyone on this list has worked with people like Brad suggests, please invite them to join this list. Thanks. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 11:14:23 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Headers vs. MIME vs. ? (was: MailList Specification...) At 10:51 AM -0500 97/2/20, Joshua D. Baer wrote: > At 10:09 AM -0500 2/20/97, Grant Neufeld wrote: > > > First we get the client authors to start supporting the core headers. > > Is there anything left to hammer out here? If not, we should try to get > this somewhere on it's own page so we have something simple to point client > developers at. A page which just lists the core header implementation. I'll try to get that up today. There are a bunch of items that I haven't gotten around to adding to the proposal document (okay, so I've been slack the past day or two...) > Did we agree on the simpler method of variable substitution? (%5B, %5D encoded square bracket enclosed human readable text) I haven't heard any arguments against it or stating that some other solution would be better. As far as I'm concerned, it's the simplest, most compatible, and gets the job done. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 11:23:27 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: [fwd] headers vs. MIME body part At 12:29 AM -0500 97/2/20, Keith Moore <(suppressed)@cs.utk.edu> wrote: > In my mind, each message from a list would include a small amount of > header information, describing only the bare essentials of the list -- > how to get unsubscribed, how to send mail to a human maintainer, etc. > It should be in very compact form so as to have minimal overhead; yet > it should be easy to parse to encourage implementation. That's pretty much it in a nutshell. > The UA would still need to know what address the user used to > subscribe to that list, which is a much harder problem to solve in > general. I think this is best left as an exercise for the author ;-) (of the client software that is). > I once proposed a List-Info header field with the following syntax: ... > rlanguage command language understood by the robot > (majordomo, listserv, listproc, smartlist, etc.... > the idea being to document a subset of existing list server > languages, and standardize a new language with its own name) That's along the lines of what I originally proposed. However, it makes for a lot of things the client application has to be aware of and keep track of. It also means that anytime a new command or server is introduced, all the clients have to be upgraded in order to support it :-( > A simple proposal that cleanly > solves one or two well-defined problems (while still leaving room for > extensibility) won't require nearly as much discussion to reach > consensus, as a complex proposal that tries to solve a wide range of > problems. Sound advice. We should try to stick to it. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 12:17:52 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: MIME parts? Not yet (re: MailList Specification Headers Proposal) Just a cautionary note (from a private discussion, reprinted with permission) to urge restraint before leaping into MIME Paul E. Hoffman wrote: > MIME objects are bad for mail list members who don't have intelligently > MIME-enhanced MUAs, which I think is still the vast majority of people > (such as AOL users...). I'd say, don't even go down that path. To which I replied: >As you may have seen, there have been some who have been touting MIME as >the end-all be-all solution for today, despite the lack of current tools to >handle it. > >I think that down the road it may be usable, so we should prepare for that >too. But it won't solve the problem today - rather it will add more >problems. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 20 Feb 1997 12:39:40 -0500 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: Variable Expansion At 09:56 AM 2/20/97 -0500, Grant Neufeld wrote: >At 3:50 PM -0500 97/2/18, Joshua D. Baer wrote about my suggestion for >variable fields in URLs: >mailto:control@server.com?Body=subscribe%20somelist%20%5BYour%20Name%20Here%5D > >> This seems much simpler and cleaner than what we were discussing before. I >> like it... > >And for those client authors who want to be clever, the hex encoded square >brackets (%5B, %5D) can be parsed and the user presented with a dialog >prompting them to 'fill in the blank'. For example, the above URL might >produce a dialog like: > > Command message to <(suppressed)@server.com> requires your input. > Please enter a value for the field "Your Name Here": > ___________________________ > | Your Name Here | (<-- text entry field) > > |Cancel| |OK| Pardon a dumb question -- how do you get clients to have the information as to what's legal -- for example, LISTSERV *requires* at least two names in a sub request (but will accept none, and use the name in From:); one is illegal, so SUB LISTNAME FRED will fail (allegedly -- haven't tested it, actually). In theory you could use (getting bloated already): mailto:control@server.com?Body=subscribe%20somelist%20%5BYour%20First %20Name%20Here%5D%20%5BYour%20Last%20Name%20Here%5D But this still rules out the legal Sub listname J. P. Morgan Also -- will there be any way to split ridiculously long (U|V)RLs into multiple lines? I believe that's syntactically equivalent to inserting whitespace in a header. Maybe define the syntax such that clients are to remove whitespace before interpreting? (Should work in a header; not so sure about in a MIME section (is that the right term?)) Or, maybe use %5C (for "\") to mean skip to the next non-white character (whether or not on the same line)? For example: mailto:control@server.com?Body=subscribe%20somelist%20%5BYour%20Fi%5C rst%20Name%20Here%5D%20%5BYour%20Last%20Name%20Here%5D could work with headers or MIME. (Use %5C%5C for a literal "\" if needed.) Just thinking out loud, Stan ---------------------------------------------------------------------- Date: 20 Feb 1997 13:15:31 -0500 From: Paul Kayak <(suppressed)@bloomington.in.us> Subject: Re:Headers vs.MIMEvs. ? +Soc factor. To G Neufeld's Thursday noon post Are you'all making it easier to sign onto and off of lists? Last year I began *reading* lists, and went through headaches learning how. It is initiation. To make the sub/unsub process smoother will move lists closer to newsgroups. Or will it? :-) - Paul - --- "To have doubted one's first principles is the mark of a civilized man." - Oliver Wendell Holmes ---------------------------------------------------------------------- Date: 20 Feb 1997 17:18:12 -0500 From: Keith Moore (sigh...) <(suppressed)@cs.utk.edu> Subject: Re: [fwd] headers vs. MIME body part > > I once proposed a List-Info header field with the following syntax: > ... > > rlanguage command language understood by the robot > > (majordomo, listserv, listproc, smartlist, etc.... > > the idea being to document a subset of existing list server > > languages, and standardize a new language with its own name) > > That's along the lines of what I originally proposed. However, it makes for > a lot of things the client application has to be aware of and keep track > of. It also means that anytime a new command or server is introduced, all > the clients have to be upgraded in order to support it :-( If we were to take the "rlanguage" approach, we'd definitely want to standardize a minimal command-set and try to get everyone to support it. But I'd hate to encode all of the common commands in the message header. Keith ---------------------------------------------------------------------- Date: 20 Feb 1997 17:32:26 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: [fwd] headers vs. MIME body part At 5:15 PM -0500 2/20/97, Keith Moore (sigh...) wrote: > If we were to take the "rlanguage" approach, we'd definitely want to > standardize a minimal command-set and try to get everyone to support it. > > But I'd hate to encode all of the common commands in the message header. Fortunately, we don't need all of the common commands. This is not meant to be an all inclusive solution for power users. This is aimed at newbies who wouldn't know "short headers" from midget soccer players. As long as we have subscribe, unsubscribe, and help, I'm happy. We should avoid bloating this with more than necessary. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 20 Feb 1997 21:47:30 -0500 From: Keith Moore (I hate having to type in my From address each time I send mail to this list) <(suppressed)@cs.utk.edu> Subject: Re: [fwd] headers vs. MIME body part - ------- Forwarded Message X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore <(suppressed)@cs.utk.edu> To: list-header@arpp.carleton.ca cc: moore@cs.utk.edu Subject: Re: [fwd] headers vs. MIME body part In-reply-to: Your message of "Thu, 20 Feb 1997 17:28:41 EST." Date: Thu, 20 Feb 1997 20:54:07 -0500 > As long as we have subscribe, unsubscribe, and help, I'm happy. We should > avoid bloating this with more than necessary. Is it reasonable to assume that all "commands" are sent to the same address, and that all commands are in the message body? That way, we could encode the "robot" address just once, and encode the command strings separately. so List-Info: robot="foolist-REQUEST@cs.utk.edu"; listname="foolist"; subscribe="subscribe {listname} {addr} {firstname} {lastname}"; unsubscribe="unsubscribe {listname} {addr} {firstname} {lastname}"; help="help"; where {foo} substitutes the value of parameter foo I know this doesn't work for all lists, but does it work for enough lists? If we have to accomodate everything that currently exists, this could get to be a real mess. Keith (It doesn't even work for NA-NET, the latest version of which I wrote. NA-NET uses separate addresses for each "command": na.join, na.remove, na.help, etc. But I'd be willing to fix NA-NET to add a majordomo-like interface.) - ------- End of Forwarded Message ---------------------------------------------------------------------- Date: 20 Feb 1997 22:07:47 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: [fwd] headers vs. MIME body part > > As long as we have subscribe, unsubscribe, and help, I'm happy. We should > > avoid bloating this with more than necessary. > > Is it reasonable to assume that all "commands" are sent to the same > address, and that all commands are in the message body? That way, we > could encode the "robot" address just once, and encode the command > strings separately. I think that is pretty safe. Every list manager (besides yours :) which I've seen with separate addresses (like list-on@... list-off@...), also supported a single control address. > List-Info: robot="foolist-REQUEST@cs.utk.edu"; > listname="foolist"; > subscribe="subscribe {listname} {addr} {firstname} {lastname}"; > unsubscribe="unsubscribe {listname} {addr} {firstname} {lastname}"; > help="help"; > > where {foo} substitutes the value of parameter foo One of the nice things about using URL's is that there are already lots of tools available for handling them. For example, many mail clients allow you to click on a URL with a modifier key to have the URL opened. All of us already have routines written for parsing and constructing them... > I know this doesn't work for all lists, but does it work for enough > lists? If we have to accomodate everything that currently exists, > this could get to be a real mess. Good point. You can make some of the people happy all the time, or all of the people happy some of the time, but you can't... ;) > (It doesn't even work for NA-NET, the latest version of which I wrote. > NA-NET uses separate addresses for each "command": na.join, na.remove, > na.help, etc. But I'd be willing to fix NA-NET to add a > majordomo-like interface.) If everyone is as cooperative, this will go very smoothly! :) ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 20 Feb 1997 23:46:14 -0500 From: Clarence Wong <(suppressed)@qualcomm.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 >Headers > >Note that the already defined 'Sender' header should still be used to >identify the list name and address. Is this an existing standard or proposed? Half of the lists I'm subscribed to (including list-header and list-mom) don't include this field. In order to bring up the proposed dialogs that reference the list name (e.g. "Do you want to subscribe to the mail list ""?"), clients will need this field. I suppose if we don't have it, we just reword the alert and omit the list name. I'm also wondering whether forwarding messages with list-headers would do much good since the header information wouldn't be preserved. Another consideration for email clients is whether users would want to specify List-headers on a per message basis (for announcing new lists). Any comments? - -Clarence BTW, great discussion going on here. We're definitely looking into supporting this in Eudora 4.0. ---------------------------------------------------------------------- Date: 20 Feb 1997 23:55:58 -0500 From: Brad Knowles <(suppressed)@his.com> Subject: Re: [fwd] headers vs. MIME body part At 5:28 PM -0500 2/20/1997, Joshua D. Baer wrote: >As long as we have subscribe, unsubscribe, and help, I'm happy. We should >avoid bloating this with more than necessary. Lemme ask a stupid question -- why do you need subscribe? If a user is already on the list, why do you need to provide how to get subscribed on the list in the "minimal" headers you send out, which would supposedly then be parsed by some clients? I think you could cut the "minimal" headers down to just unsubscribe and help. Also, you need to start getting this stuff written down, and preferably into a draft that could be submitted to the IETF. The sooner there's some sort of RFC-like thing that can be inspected by client authors, the sooner it could be handed to people like, say the MUA developers for AOL, and as soon as that rolled out, you'd have an immediate large audience. - -- Brad Knowles, MIME/PGP: brad@his.com comp.mail.sendmail FAQ Maintainer finger brad@his.com for my PGP Public Keys and Geek Code The comp.mail.sendmail FAQ is at ---------------------------------------------------------------------- Date: 21 Feb 1997 00:13:08 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 At 11:43 PM -0500 2/20/97, Clarence Wong wrote: > >Note that the already defined 'Sender' header should still be used to > >identify the list name and address. > > Is this an existing standard or proposed? Half of the lists I'm subscribed > to (including list-header and list-mom) don't include this field. In order > to bring up the proposed dialogs that reference the list name (e.g. "Do you > want to subscribe to the mail list ""?"), clients will need this > field. I suppose if we don't have it, we just reword the alert and omit the > list name. I have no problem with adding it to ListSTAR's default setup for the next release of the templates. I believe most lists use it, and I've don't think it will be a very controversial issue for those that don't... > I'm also wondering whether forwarding messages with list-headers would do > much good since the header information wouldn't be preserved. I've been wondering how this will work myself. I guess one solution is to get mail clients to preserve these headers when forwarding. Would that violate a ton of RFCs? > Another consideration for email clients is whether users would want to > specify List-headers on a per message basis (for announcing new lists). Any > comments? Since it will only be list managers doing this, I would leave it to their resources. There already exist plugins for Eudora which allow you to modify the headers... > BTW, great discussion going on here. We're definitely looking into > supporting this in Eudora 4.0. I'm very glad to hear that. For a while I was worried that we were just blowing hot air... none of this matters a toot if mail clients don't complete the other half of the equation. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 21 Feb 1997 00:22:42 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: [fwd] headers vs. MIME body part At 11:50 PM -0500 2/20/97, Brad Knowles wrote: > At 5:28 PM -0500 2/20/1997, Joshua D. Baer wrote: > > >As long as we have subscribe, unsubscribe, and help, I'm happy. We should > >avoid bloating this with more than necessary. > > Lemme ask a stupid question -- why do you need subscribe? If a > user is already on the list, why do you need to provide how to get > subscribed on the list in the "minimal" headers you send out, which > would supposedly then be parsed by some clients? The hope is that we find some way for mail clients to find them in forwarded messages. This hasn't been explored too much, so we should definitely try to hash it out. It supposed to work something like this... Joe is on the Banana List. His friend Bill wants to join. So Joe forwards a list message to Bill, and he just hits subscribe. The only way I see for this to be implemented currently would be if the List headers were preserved on forwarded messages. > I think you could cut the "minimal" headers down to just > unsubscribe and help. If we can't find some way to make the above scenario work, then I definitely agree. This came up before but we never worked out the details. > Also, you need to start getting this stuff written down, and > preferably into a draft that could be submitted to the IETF. The > sooner there's some sort of RFC-like thing that can be inspected by > client authors, the sooner it could be handed to people like, say the > MUA developers for AOL, and as soon as that rolled out, you'd have an > immediate large audience. Beyond what Grant has at his site? http://arpp.carleton.ca/midas/mail/list-header.html ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 21 Feb 1997 01:04:47 -0500 From: Brad Knowles <(suppressed)@his.com> Subject: Re: [fwd] headers vs. MIME body part At 12:18 AM -0500 2/21/1997, Joshua D. Baer wrote: >> Also, you need to start getting this stuff written down, and >> preferably into a draft that could be submitted to the IETF. The >> sooner there's some sort of RFC-like thing that can be inspected by >> client authors, the sooner it could be handed to people like, say the >> MUA developers for AOL, and as soon as that rolled out, you'd have an >> immediate large audience. > >Beyond what Grant has at his site? > >http://arpp.carleton.ca/midas/mail/list-header.html If it's not an RFC or in an RFC-like format on it's way down that road, yes, more than what he's got on his site is needed. Some places will have enough developer resources that they can afford to have people on the appropriate mailing lists *very* early in the genesis of the rules, other places can't. If nothing else, if you've got a draft RFC in progress, you can point to it by short name (or by URL), and perhaps show prospective developers who has already apparently signed on to supporting those changes. That then provides incentive for them to jump on the bandwagon. It also makes it a lot easier for people like me to take to VPs of development and convince them that this is something we need to support (and why), and then have them be able to pass that on down the chain to the developer who ends up doing the real work. - -- Brad Knowles, MIME/PGP: brad@his.com comp.mail.sendmail FAQ Maintainer finger brad@his.com for my PGP Public Keys and Geek Code The comp.mail.sendmail FAQ is at ---------------------------------------------------------------------- Date: 21 Feb 1997 01:06:01 -0500 From: (suppressed)@akimbo.com Subject: Re: URLs, List Headers, and VRLs(?) >From: gneufeld@ccs.carleton.ca (Grant Neufeld) >As I recently suggested, it might be best to not provide a specialized >variable syntax at all, but instead just use hex encoded square brackets >(%5B, %5D) to enclose human readable descriptions of fields to be filled in. Actually, this is backwards. The convention in URLs is that if you attach some special meaning to a character that you use the hex encoding to indicate that it has no special meaning. This would also have the advantage of making the URL more readable in a mail client. Thus we would write: Just like if you want a literal ? you write %3F. --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 21 Feb 1997 01:19:24 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: [fwd] headers vs. MIME body part At 1:01 AM -0500 2/21/97, Brad Knowles wrote: > If nothing else, if you've got a draft RFC in progress, you can > point to it by short name (or by URL), and perhaps show prospective > developers who has already apparently signed on to supporting those > changes. That then provides incentive for them to jump on the > bandwagon. > > It also makes it a lot easier for people like me to take to VPs > of development and convince them that this is something we need to > support (and why), and then have them be able to pass that on down > the chain to the developer who ends up doing the real work. All good points. Grant, I'm willing to help with this process if you're feeling swamped. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 21 Feb 1997 02:32:19 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: [fwd] headers vs. MIME body part At 10:14 PM -0800 2/20/97, Joshua D. Baer wrote: >> If nothing else, if you've got a draft RFC in progress, you can >> point to it by short name (or by URL), and perhaps show prospective >> developers who has already apparently signed on to supporting those >> changes. That then provides incentive for them to jump on the >> bandwagon. >> >> It also makes it a lot easier for people like me to take to VPs >> of development and convince them that this is something we need to >> support (and why), and then have them be able to pass that on down >> the chain to the developer who ends up doing the real work. > >All good points. Grant, I'm willing to help with this process if you're >feeling swamped. I too am willing to help in this process -- I'm already an editor in the TLS working group, so I know the process and go to all the conferences. I will say I think we need to trim down the list of headers, or at least prioritize them, and make use of as much prior art as we can (i.e. URLs). Also, K.I.S.S. is a good architectural practice ;-) - ------------------------------------------------------------------------ ..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: 21 Feb 1997 06:07:05 -0500 From: (suppressed)@earthchannel.com Subject: Re: [fwd] headers vs. MIME body part On 20 Feb 97 at 23:50, Brad Knowles wrote: > I think you could cut the "minimal" headers down to just > unsubscribe and help. > To make it more "minimal", all you need really is "HELP". Now the response to HELP can have bloated headers for the client to parse and present a menu of most frequently used commands or just "UNSUB". Gess ---------------------------------------------------------------------- Date: 21 Feb 1997 14:01:19 -0500 From: "Adam C. Engst" <(suppressed)@tidbits.com> Subject: Re: [fwd] headers vs. MIME body part >> Is it reasonable to assume that all "commands" are sent to the same >> address, and that all commands are in the message body? That way, we >> could encode the "robot" address just once, and encode the command >> strings separately. > >I think that is pretty safe. Every list manager (besides yours :) which >I've seen with separate addresses (like list-on@... list-off@...), also >supported a single control address. Well, yes and no. Over time, my listserv@tidbits.com address has taken maybe 100 messages total. In comparison, tidbits-on@tidbits.com and tidbits-off@tidbits.com have taken a combined total of about 20,000 messages. In other words, as I add new forms of the TidBITS list, I probably won't go to the effort of duplicating the commands at listserv, but I'll make sure that that address kicks back an auto-reply about proper subscription techniques. cheers... -Adam - -- Adam C. Engst, TidBITS Editor -- ace@tidbits.com -- info@tidbits.com ----------------------------------- Answers to some common questions via email at faq-adam@tidbits.com or via the Web at Internet Starter Kit for Macintosh, 4th Edition now available ---------------------------------------------------------------------- Date: 21 Feb 1997 14:53:12 -0500 From: Clarence Wong <(suppressed)@qualcomm.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 At 12:00 AM -0500 2/21/97, Joshua D. Baer wrote: >At 11:43 PM -0500 2/20/97, Clarence Wong wrote: >> I'm also wondering whether forwarding messages with list-headers would do >> much good since the header information wouldn't be preserved. > >I've been wondering how this will work myself. I guess one solution is to >get mail clients to preserve these headers when forwarding. Would that >violate a ton of RFCs? Hmmmm. This is what 822 says: >>>> Some systems permit mail recipients to forward a message, retaining the original headers, by adding some new fields. This standard supports such a service, through the "Resent-" prefix to field names. <<<<<<<< I'm looking into why we don't conform to the RFC. >> Another consideration for email clients is whether users would want to >> specify List-headers on a per message basis (for announcing new lists). Any >> comments? > >Since it will only be list managers doing this, I would leave it to their >resources. There already exist plugins for Eudora which allow you to >modify the headers... The ones I'm familiar with only allow a global change to the settings file. I guess for the most part, this will be a power user thing. I'm just thinking about our situation at Qualcomm where we let any employee create an internal mailing list... >> BTW, great discussion going on here. We're definitely looking into >> supporting this in Eudora 4.0. > >I'm very glad to hear that. For a while I was worried that we were just >blowing hot air... none of this matters a toot if mail clients don't >complete the other half of the equation. We're all in the same boat. - -Clarence ---------------------------------------------------------------------- Date: 21 Feb 1997 16:22:59 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: [fwd] headers vs. MIME body part > One of the nice things about using URL's is that there are already > lots of tools available for handling them. For example, many mail > clients allow you to click on a URL with a modifier key to have the > URL opened. All of us already have routines written for parsing and > constructing them... Funny, I would argue the opposite -- that most mailers do not have routines for parsing URLs. Even those that do may not handle mailto: URLs very well. (popping up a web browser is NOT my idea of a good way for a mail user agent to handle them!) Of course, most mailers don't parse List-Info headers either. It might help if ordinary human beings can read these things and guess how to use them, for the cases where the UAs don't support it. That would encourage us to use a simple, human readable format. While people are familiar with both "conventional" URLs and email addresses, I somehow doubt they would easily adapt to mailto URLs with %-encoded characters that have to be decoded before use as ordinary addresses, multiple URL parameters (subject, body), and variable substitutions. Keith ---------------------------------------------------------------------- Date: 21 Feb 1997 16:40:24 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: MailList Specification Headers Proposal 0.0.9 > >Note that the already defined 'Sender' header should still be used to > >identify the list name and address. > > Is this an existing standard or proposed? The Sender field is an existing standard, having been defined in RFC 822. However, while Sender is widely (and inconsnstently) used to contain some address of a mailing list, this use is inappropriate and contrary to the intent of the standard. Sender should contain the address of the original submitter of the message, if that address differs from the From field. The two examples in 822 where Sender differs from From are: 1. Message sent by one person on behalf of another person. (e.g. a secretary sends message for his boss) 2. Message sent by one person, on behalf of multiple people. (multiple addresses in From field, acutal submitter's address in Sender field) Traditionally, there's a third and related use of Sender -- to supply the submitter's "real" (RFC 822 says "authentic") address (say, the email address derived from the username on the sending system) if the submitter supplies a different address in the From field. While this doesn't provide any real authentication (since it's so easy to forge SMTP mail), it is still useful to have this field. And even though many users these days send mail from PC clients via SMTP server (and thus don't necessarily have the concept of "login"), there is considerable interest in defining a "submit" variant of SMTP which could provide real authentication -- thus the original use of the Sender field might become more prevalent. The problem with the use of Sender by mailing lists is that it usurps the original purpose of the field. The IETF DRUMS (detailed revision/update of messaging standards) working group, which is in the process of updating/clarifying the mail standard RFCs, has decided not to deprecate the originally intended use of Sender, nor to define a new field to serve that purpose. The obvious alternative is to define a new field for use by mailing lists. Keith ---------------------------------------------------------------------- Date: 21 Feb 1997 16:51:11 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: [fwd] headers vs. MIME body part > > Lemme ask a stupid question -- why do you need subscribe? If a > > user is already on the list, why do you need to provide how to get > > subscribed on the list in the "minimal" headers you send out, which > > would supposedly then be parsed by some clients? > > The hope is that we find some way for mail clients to find them in > forwarded messages. This hasn't been explored too much, so we should > definitely try to hash it out. > > It supposed to work something like this... Joe is on the Banana List. His > friend Bill wants to join. So Joe forwards a list message to Bill, and he > just hits subscribe. Easy! Recommend that every UA that supports the List header implement at least these three functions: 1. unsubscribe 2. request help from the list 3. forward list info to someone else The last one can easily be implemented by having the UA send a message to the "someone else", that includes the same List header. - -Keith ---------------------------------------------------------------------- Date: 21 Feb 1997 16:59:51 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: How to get this published as an RFC > If it's not an RFC or in an RFC-like format on it's way down that > road, yes, more than what he's got on his site is needed. The first step is to publish it as an Internet-Draft. This is easy, it just needs to be in a particular format (they're not too strict about formatting, but it does have to have some boilerplate prose), and then you mail it t