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 to a particular address. See ftp://ds.internic.net/internet-drafts/1id-guidelines.txt for instructions. Or check out http://www.apps.ietf.org/apps/procedures.html for descriptions of how to publish an (informational) RFC, or how to get an standard RFC approved (with or without a working group) You can also look at RFC 2026, which formally describes the Internet Standards process. > 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. For what it's worth, I've already informed the IETF Applications Area Directorate about this list, and encouraged interested directorate members to subscribe and contribute to the discussion. Keith Moore ---------------------------------------------------------------------- Date: 21 Feb 1997 17:12:09 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: MailList Specification Headers Proposal 0.0.9 > >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. <<<< Resent-* never has worked very well. Part of the problem is that you really want to be able to separate the original message from the part that was added during resending. Either MIME-style forwarding (i.e. have the forwarded message attach a message/rfc822 body part containing the original message) or RFC 934 encapsulation is much better for most cases. Part of the problem is that the RFC 822 definition is ambiguous -- it's not clear whether it's to be used for automatic forwarding, manual forwarding, list distribution, or what. It turns out that there's only one case where you really want to use Resend. This is where the message was sent to you, but you're the wrong address, and it really needs to be sent somewhere else *with the original headers and message body intact*. Examples are: 1. Someone sends a subscribe message to the list maintainer, instead of to the list robot. The maintainer then "resends" the message to the robot. 2. Someone sends a message to a moderated list. The list notices that it's not approved (by whatever means) and forwards the message to the moderator. The moderator then "resends" the message to the list. >From talking to several of the original RFC 822 developers, cases like the above are pretty much what Resent-* fields were intended for. (a number of old 822-based mailers have resend commands) I belive the DRUMS WG has decided to clarify 822bis to say that Resend is for manual resending only. Keith ---------------------------------------------------------------------- Date: 21 Feb 1997 19:08:39 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: [fwd] headers vs. MIME body part At 1:14 PM -0500 2/21/97, Adam C. Engst wrote: > >> 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. The current proposal would work fine with your setup. I answered his question without really seeing where he was heading with it. In your case, you would have something like: List-Subscribe: List-Unsubscribe: List-Help: ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 21 Feb 1997 20:52:42 -0500 From: "Adam C. Engst" <(suppressed)@tidbits.com> Subject: Re: [fwd] headers vs. MIME body part >> >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. > >The current proposal would work fine with your setup. I answered his >question without really seeing where he was heading with it. > >In your case, you would have something like: > >List-Subscribe: Right - I've been watching this and it dovetails nicely with what I'm doing, and what a number of people are picking up on as well. I just wanted to make sure that the single control address wasn't planned in some way as the only way to do this stuff. 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 21:55:06 -0500 From: Merrill Cook <(suppressed)@unidial.com> Subject: Re: [fwd] headers vs. MIME body part moore+lh@cs.utk.edu wrote: > > 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. What are we trying to do here: 1) give the mua software some way to tell from =any particular note= that the note is from a mailing list that the user has likely subscribed to (hmmmm -- how to handle forwarded mail that resends with all the headers intact instead of encapsulating the forwarded message). 2) give the mua some clue as to how to formulate the usual replies or commands to the mailing list management software. It seems to me the latter is an ideal application for a MIME encapsulated command (with some options for doing it with plain mail for older clients), where the command is going from the MUA (perhaps in response to a button click) to the MLM. It seems to me that the former is a good thing to do with a header, as long as you don't try to teach the MUA the syntax for every command the list knows through the headers. If we were keeping a local database for all the lists the user was interested in or subscribed to from time to time, it might be useful to define a mime-encapsulated information file that could keep the information up to date; but I see lots of problems with that. Simpler to put a clue in each note, and the headers seems to be a good place for that, at least until MIME becomes ubiquitous... ---------------------------------------------------------------------- Date: 21 Feb 1997 23:26:10 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: MailList Specification Headers Proposal 0.0.9 At 2:50 PM -0500 2/21/97, Clarence Wong wrote: >> 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... I could see this maybe as a menu item titled "Announce Mailing List�" or "Add List Info�" which popped up a dialog and let you enter the header info. The headers would be added to the frontmost outgoing message window. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 22 Feb 1997 14:45:51 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: [fwd] headers vs. MIME body part > > > rlanguage command language understood by the robot > > > (majordomo, listserv, listproc, smartlist, etc.... ... > 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. I suggested that sort of approaach for the original draft of this proposal. However, I have become thoroughly convinced that it's not the right way to go. There are two key reasons for this: It would require a lot of knowledge on the part of the client. It would require client software upgrades (which can take a long time to get implemented and deployed) when adding to the syntax. > But I'd hate to encode all of the common commands in the message header. Which is why we've narrowed it down to the 'core' commands. The remainder will be communicated through other transport mechanisms (such as body text, specialized messages, MIME objects, http/ftp retrieval, or whatever). - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 22 Feb 1997 14:47:45 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Variable Expansion > 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). How about: "subscribe somelist [Your First and Last Name]" The point is, by leaving the variables as plain text, you can put any test within to explicitly describe what is required since the user is expected to be presented with that text and asked to replace it. > Also -- will there be any way to split ridiculously long (U|V)RLs into > multiple lines? Clients should treat the URLs as follows: The URL begins after the '<' and ends before the '>'. All whitespace should be ignored, which includes CR, LF, tab, and space. High-ascii and control characters are illegal. So Should either not be handled (error condition), or treated as: http://arpp.carleton.ca/midas/mail/list-header.html - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 22 Feb 1997 15:34:12 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Sender header (was: MailList Specification Headers Proposal 0.0.9) At 11:43 PM -0500 97/2/20, 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. I removed the Sender field from the proposal a few days ago after finding out that it's not what I originally thought it was. It's been tentativly replaced by: List-Address: "" <> We may need a header to identify the list name and address. I'm not satisfied that this is the correct way to do it. Suggestions? What about unique list identifiers than can survive a list moving to a different domain name (or even list name change)? > I'm also wondering whether forwarding messages with list-headers would do > much good since the header information wouldn't be preserved. This is where the body-inclusion or MIME part (or even speciallized message) transports would be at an advantage. However, some clients may get intelligent about reading forwards (since many forwards include the original message headers in the body of the message). > 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? Support for client created headers is up to the client software authors. > We're definitely looking into > supporting this in Eudora 4.0. Great! (You should see the smile on my face...) - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 22 Feb 1997 15:35:20 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: [fwd] headers vs. MIME body part At 9:44 PM -0500 97/2/20, Keith Moore wrote: > Is it reasonable to assume that all "commands" are sent to the same > address, and that all commands are in the message body? No to both. We shouldn't put such arbitrary restrictions in the proposal we're putting together here - preventing a not inconsiderable number of servers from being able to take advantage of it. Why make such limitations when we don't have to? > That way, we > could encode the "robot" address just once, and encode the command > strings separately. ... > 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. But it doesn't have to be a mess if we think it through. Remember, we're not defining the command syntax for list servers, we're defining a syntax for describing command syntaxes - a meta-syntax. (As well as defining transport mechanisms for transmitting the meta-syntax.) - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 22 Feb 1997 16:29:10 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: IETF/RFC (was: [fwd] headers vs. MIME body part) At 11:50 PM -0500 97/2/20, Brad Knowles wrote: > Also, you need to start getting this stuff written down, and > preferably into a draft that could be submitted to the IETF. Work has started on the formalization now. Josh has agreed to put together a quick draft which we can go over on this list and then submit as an IETF Internet-Draft. The questions I have for the IETF experienced people here are: Should we turn this into a formal Working Group, or should we submit this to the IETF without a formal Working Group? If this becomes a Working Group, what would it mean for me to be the chair? Christopher Allen wrote: > 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. When I get the answers to my questions above we can decide how to proceed. I have a draft for a WG charter already put together, but am waiting for the above answers before presenting it here. > 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). That seems to be the plan at this point. I figure the first Internet-Draft/RFC we put together will be just the URL encoded command syntax for the Help, Unsubscribe, and Subscribe headers. with an intent to produce an expanded standard following that (which would cover other commands and other transport methods other than just headers). Keith Moore wrote: > The first step is to publish it as an Internet-Draft. Agreed. That's what Josh is working on right now (I hope ;-). How it gets submitted will depend on whether we formalize a Working Group, I guess. - -- "Thanks for the nose-news, neighbor!" - Ned Flanders gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 23 Feb 1997 03:48:51 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) At 1:26 PM -0800 2/22/97, Grant Neufeld wrote: >The questions I have for the IETF experienced people here are: > >Should we turn this into a formal Working Group, >or should we submit this to the IETF without a formal Working Group? > >If this becomes a Working Group, what would it mean for me to be the chair? Some documentation on this is at . First off, if it is a good proposal (which probably means non-controversial, or a minimalist approach) it can move very fast through the IETF process. But this requires planning. This is the way the fast-track works: * You wrap a nice, minimal internet-draft, and make sure that everyone on the "inside" agrees with it. * You write a two paragraph BOF charter for a WG and pick an chairman and editor. * You talk to the IETF area director applicable for the internet draft, who will approve the BOF charter and quickly make it a Working Group. You make sure that any other Working Group chairs in related areas are not against your proposal. * The proposal is sent to the newly approved "Working Group" list for a "working group last call". This is two weeks. * If there is "rough consensus and working code" the editor submits it to the area director, who then submits it to the list again as well as to a broader distribution list for a "Last Call" which is another two or four weeks. * If there are few or no objections during the "Last Call" the area director will submit it to the IETF architecture board (which is a fairly pro-forma thing, asthey rarely object) and if there are no objections, the document is now a "proposed standard" and issued a real RFC number, and is effectively "official" though there are a few more steps to really finalize it through "draft standard" and "standard". The problem right now is that we are trying to do too much. If it was just a list of 3 or 5 headers with URLs in them, we could do the fast track like the above. However, with the addition of variable replacement, and the more complex complete proposal that I've seen, I think it would be more difficult. My personal recommendation is as follows: We identify the key and easy 3 to 5 headers and do a quick charter and internet-draft. We try to do the fast track and get it to at least an "proposed standard" RFC status. Then we can look at adding a few more if they needed. By that time, we'll have some momentum and probably can get the support we need. Otherwise, if we spin around as a WG with sucessfully completing even the first "proposed standard" we risk being shot down. - ------------------------------------------------------------------------ ..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: 23 Feb 1997 11:23:26 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Fast Track Through IETF At 3:46 AM -0500 97/2/23, Christopher Allen wrote: > * You wrap a nice, minimal internet-draft, and make sure that everyone on > the "inside" agrees with it. Okay, that's in progress now. > * You write a two paragraph BOF charter for a WG and pick an chairman and > editor. I've got that pretty much wrapped up and will submit it to the group soon. > You make > sure that any other Working Group chairs in related areas are not against > your proposal. How do I find out who they are and how to contact them? > The problem right now is that we are trying to do too much. If it was just > a list of 3 or 5 headers with URLs in them, we could do the fast track like > the above. However, with the addition of variable replacement, and the more > complex complete proposal that I've seen, I think it would be more > difficult. Which is why the current plan is to first produce a 'simple' standard consisting of the 3 core headers using the enhanced mailto URLs without a variable syntax (although we may recommend the plaintext [] stuff in the document). Once that's standardized, we can work on the 'enhanced' standard which may contain the various other bits that are in the current discussion document. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 23 Feb 1997 11:24:27 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 1:03 AM -0500 97/2/21, BruceLeban@akimbo.com wrote: > 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: > (make that: ) Good point. Does anyone have any reason to not use the brackets for variables like this? Having thought about it more, I don't think the concern abut conflict with IP address mailing (user@[12.34.56.78]) is needed. The brackets appearing after the question mark will not interfer in any way with interpretation of the brackets in the machine address. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 23 Feb 1997 18:01:50 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > (make that: ) > > Good point. > Does anyone have any reason to not use the brackets for variables like this? Yes. It is a bad mixing of layers. You've got at least three layers here: 3. encoding of variables 2. mailto URL encoding of SMTP/822 information 1. %XX convention for wierd characters in URLs The mailto URL syntax is of dubious value, because these things aren't valid mailto URLs by themselves -- layer 3 has to be decoded first. Having layer 3 decoded after layer 2 is even worse: the recipient's UA has to know how to parse mailto URLs, then substitute the variables, then -- if it's to get any use of the mailto URL notation at all -- it has to generate a mailto URL from the result. You might as well start out with a different notation, because the UA has to decode it specially anyway. Even if you were to use mailto URLs, you don't want layer 3 to have to know about mailto URL syntax just so it knows when to substitute variables. Just make it a simple filter that applies to all List-* header fields. Also, make the strings such that it's a completely invalid mailto URL unless you apply layer 3 decoding first...say by putting delimiter characters around the address part. (we don't want lots of messages sent to list robots with "subscribe your-address your-name" in them) If there's no need to have variable substitutions within variable substitutions (offhand, I don't think there is such a need), there's no need for balanced delimeters. For instance, if you use '&' as a delimiter character, "&foo&" could be used to substitute parameter foo, and "&&" used to substitute the character '&' for the rare occasion where it's needed. Keith ---------------------------------------------------------------------- Date: 23 Feb 1997 19:54:31 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: URLs, List Headers, and VRLs(?) At 5:58 PM -0500 2/23/97, Keith Moore wrote: > Even if you were to use mailto URLs, you don't want layer 3 to have to > know about mailto URL syntax just so it knows when to substitute > variables. Just make it a simple filter that applies to all List-* > header fields. Also, make the strings such that it's a completely > invalid mailto URL unless you apply layer 3 decoding first...say by > putting delimiter characters around the address part. (we don't want > lots of messages sent to list robots with "subscribe your-address > your-name" in them) Two comments. First, this is not very likely. Any robot using these headers has to know what a List-Subscribe header means (or have some concept of it). It's not like Eudora is going to use the List-Help header when you hit "reply". Headers which are unrecognized are almost always ignored. I don't really see how this header could be misinterpreted. Second, we probably DO want to try and design this so that someone cutting and pasting the URL out of the headers will work to some extent. If it's an invalid URL, then nothing happens and the user is still clueless. If it is a valid URL but puts "subscriber your-address your-name" in the body, then what is the result? In almost every case, the list manager replies with correct instructions or pointers to them. That said, I don't disagree with the idea of separating the layers; I more disagreed ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 23 Feb 1997 20:04:49 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: URLs, List Headers, and VRLs(?) Somehow this got sent before I finished... At 7:52 PM -0500 2/23/97, Joshua D. Baer wrote: > At 5:58 PM -0500 2/23/97, Keith Moore wrote: > > > Even if you were to use mailto URLs, you don't want layer 3 to have to > > know about mailto URL syntax just so it knows when to substitute > > variables. Just make it a simple filter that applies to all List-* > > header fields. Also, make the strings such that it's a completely > > invalid mailto URL unless you apply layer 3 decoding first...say by > > putting delimiter characters around the address part. (we don't want > > lots of messages sent to list robots with "subscribe your-address > > your-name" in them) > > Two comments. First, this is not very likely. Any robot using these > headers has to know what a List-Subscribe header means (or have some > concept of it). It's not like Eudora is going to use the List-Help header > when you hit "reply". Headers which are unrecognized are almost always > ignored. I don't really see how this header could be misinterpreted. > > Second, we probably DO want to try and design this so that someone cutting > and pasting the URL out of the headers will work to some extent. If it's > an invalid URL, then nothing happens and the user is still clueless. If it > is a valid URL but puts "subscriber your-address your-name" in the body, > then what is the result? In almost every case, the list manager replies > with correct instructions or pointers to them. > > That said, I don't disagree with the idea of separating the layers; I more > disagreed ... with the examples presented. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 23 Feb 1997 21:12:13 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > Any robot using these > headers has to know what a List-Subscribe header means (or have some > concept of it). "some concept" is closer to the truth. Long experience with 822 and MIME implementations seems to indicate that people very commonly implement features without reading (or fully reading) the specifications. Just to take a convenient example: if List-* fields use mailto URLs, What percentage of implementors of List-* responders will read the URL spec, paying full attention to the particulars of URL syntax, encoding rules, and security considerations? (As opposed to simply doing the "obvious" parse on the mailto string?) Keith ---------------------------------------------------------------------- Date: 23 Feb 1997 23:03:09 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) > This is the way the fast-track works: > I don't want to seem pedantic, but Christopher's description is a bit dated and a bit incorrect. Look at www.apps.ietf.org (under Procedures) for the area directors' advice, or RFC 2026 for the official description of the process. In particular, it's not always necessary to form a working group to approve a document for the standards track. Speaking as one of the applications area directors, I hate to create a working group for something that's so simple. (We have too many groups already, and limited resources with which to manage them.) If you can produce a draft that is obviously of Proposed Standard quality, we can just issue a four week Last Call. The trick is that you have to come up with a spec which is obviously (to pretty much everyone that looks at it) of sufficient quality for Proposed Standard status: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. -- RFC 2026, section 4.4.1 Pay special attention to the requirement that the specification "has resolved known design choices". The people who review this spec are going to need to be convinced that (e.g.): + multiple List-* header fields are better than a signal List-Info field or a MIME type, + mailto URLs are better than parameter lists, + encoding the message sent to the list robot is better than having a standard command language. + internationalization has been adequately addressed, e.g: do you allow command names in other charsets besides ASCII? do you allow user names in other charsets besides ASCII? how does the user agent know what charset to transmit? + security considerations have been adequately addressed. (e.g. how do you prevent the use of list-* fields to trick people into forging usenet votes, requests for spam, or threatening messages to president@whitehouse.gov?) So my recommendation at this point is: Document the problem you're trying to solve, break down the problem into managable pieces, discuss different ways to implement those pieces and the cost vs benefit of each. Then write up a spec that not only clearly documents the protocol, but also makes it clear that most of the relevant issues have been thought about and that the choices made are reasonable. If a small group can accomplish the above, it will get an RFC out the door a lot more quickly than a formal working group. And if it turns out that the problem is more difficult than anticipated and it really is necessary to form a working group, the draft document serves to focus the working group. Keith ---------------------------------------------------------------------- Date: 23 Feb 1997 23:13:31 -0500 From: (suppressed)@akimbo.com Subject: Re: URLs, List Headers, and VRLs(?) >>At 1:03 AM -0500 97/2/21, BruceLeban@akimbo.com wrote: >> >From: gneufeld@ccs.carleton.ca (Grant Neufeld) >(make that: ) > >Having thought about it more, I don't think the concern abut conflict with >IP address mailing (user@[12.34.56.78]) is needed. The brackets appearing >after the question mark will not interfer in any way with interpretation of >the brackets in the machine address. I agree. So let's just state that if anything after the ? uses a literal bracket then it must be escaped as %5B/%5D for the benefit of any future automated use of brackets. We should also suggest (but not require) that list software check for: [1] unremoved brackets around parameters and unreplaced parameters [2] untranslated %XX codes. Both of these are in case a user expands the URL by hand (in a client that doesn't recognize the extended mailto syntax). They might not realize they have to remove the brackets and translate %20 to a space. A reasonable rule of thumb would be to try translating %XX if the command is syntactically incorrect otherwise. --- Bruce Leban Akimbo Systems http://www.akimbo.com/globetrotter Publish on the web without learning HTML! (Really.) ---------------------------------------------------------------------- Date: 23 Feb 1997 23:18:22 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) At 10:59 PM -0500 2/23/97, Keith Moore wrote: > Pay special attention to the requirement that the specification "has > resolved known design choices". The people who review this spec are > going to need to be convinced that (e.g.): > > + multiple List-* header fields are better than a signal List-Info > field or a MIME type, > > + mailto URLs are better than parameter lists, > > + encoding the message sent to the list robot is better than having a > standard command language. > > + internationalization has been adequately addressed, e.g: > do you allow command names in other charsets besides ASCII? > do you allow user names in other charsets besides ASCII? > how does the user agent know what charset to transmit? > > + security considerations have been adequately addressed. > (e.g. how do you prevent the use of list-* fields to > trick people into forging usenet votes, requests for > spam, or threatening messages to president@whitehouse.gov?) > > So my recommendation at this point is: Document the problem you're > trying to solve, break down the problem into managable pieces, discuss > different ways to implement those pieces and the cost vs benefit of > each. Then write up a spec that not only clearly documents the > protocol, but also makes it clear that most of the relevant issues > have been thought about and that the choices made are reasonable. Thanks for the comments, Keith! I'll definitely use that as an outline as I write up the first internet draft. If anyone else has any comments or suggestions, please send them to me or to the list. I'm starting with Grant's web pages and Keith's suggestions, and move forward from there. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 24 Feb 1997 07:54:03 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: The Promise of Push At 3:12 PM -0500 2/23/97, DaveNet email wrote: > Mailing lists are worth the trouble, but they could be much better! A > user interface could organize all the resources in a single > structure of menus and dialogs. With better UIs, mailing lists could > spawn working groups, sub-lists with new charters, entities that > come and go as problems and issues get dealt with and solved. > > A pet peeve of mine, it should be easy to resign from a list with a single > menu command, eliminating misdirected "unsubscribe" messages > from panic-stricken and/or angry people who urgently want to get off > a list. Wouldn't that be a blessing? Funny you should mention that... I'm writing the internet-draft as we speak... Take a look at: http://arpp.carleton.ca/midas/mail/list-header.html http://arpp.carleton.ca/midas/mail/list-header-intro-manager.html Have you been following the discussion on the ListMom-Talk, and List-Headers lists?

I'm sure your comments would be valuable, especially in the macro/variable area. Most of the other aspects seem to have reached consensus, but that area is still a bit unclear... The intention is to enable the mail clients to provide UI support for these functions. It's not a final solution, more like a first step to something better. Grant and I wrote a FaceSpan floating windoid for Eudora with buttons to subscribe, unsubscribe, etc which works today. The Eudora and Emailer folks are involved as well, so the prospects are good for support in the next versions. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 24 Feb 1997 09:02:16 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 5:58 PM -0500 97/2/23, Keith Moore wrote: > > ... > It is a bad mixing of layers. > > You've got at least three layers here: > > 3. encoding of variables > 2. mailto URL encoding of SMTP/822 information > 1. %XX convention for wierd characters in URLs Sorry, I should have made my intent more clear. I don't want to formally declare variables with the URLs (too complicated and requires modifications to the URL standard). What I want to know is if including square brackets (as [] instead of hex encoding them) in the plain text of an url (after the address specification) is okay. This way client implementers won't have to worry about handling the variables any different than the rest of the plain text (they can just dump it in along with the rest of the command text). However, if clients want to get clever, they can 'recognize' that the brackets mean they should get some info from the user before sending the message. The reason for not wanting to hex-encode the brackets is it makes it easier for human readers. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 24 Feb 1997 09:11:04 -0500 From: William Cox <(suppressed)@gramercy.ios.com> Subject: Re: URLs, List Headers, and VRLs(?) >Having thought about it more, I don't think the concern abut conflict with >IP address mailing (user@[12.34.56.78]) is needed. The brackets appearing >after the question mark will not interfer in any way with interpretation of >the brackets in the machine address. Assuming gateways and MTAs comply, but otherwise correct. Thanks for pointing this out. However, I've learned, rather painfully, not to be surprised at how loosely compliance can be interpreted, and what items are open to revision by the MTA or gateway. Obviously the gateway will tend to be less understanding than an MTA, since it has to shoehorn the standard into a proprietary format. But as long as they don't play fast and loose with right-hand tokens that happen to also be to the right of a question mark, we should be fine. I'm not yet experienced enough that I can break a sendmail.cf to mutilate these headers intentionally, and then be able to provide a reliable fix. Is anyone here? William Cox cwcjr@gramercy.ios.com It is the odious nature of the question, that it can be settled only at the cannon's mouth. - --John Quincy Adams, 1831 letter to Henry Clay ---------------------------------------------------------------------- Date: 24 Feb 1997 09:25:26 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: URLs, List Headers, and VRLs(?) At 8:00 PM -0500 2/23/97, Grant Neufeld wrote: > I don't want to formally declare variables with the URLs (too complicated > and requires modifications to the URL standard). What I want to know is if > including square brackets (as [] instead of hex encoding them) in the plain > text of an url (after the address specification) is okay. > > This way client implementers won't have to worry about handling the > variables any different than the rest of the plain text (they can just dump > it in along with the rest of the command text). However, if clients want to > get clever, they can 'recognize' that the brackets mean they should get > some info from the user before sending the message. I like this idea since it leaves the mailto as it is currently defined. The simpler the better... and the more realistic to implement. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 24 Feb 1997 10:33:35 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Are URLs human readable? User Testing At 4:19 PM -0500 97/2/21, Keith Moore wrote: > 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. Perhaps an informal user study is in order to guage how users will respond to URLs like we're suggesting. Would someone like to draft up a questionnaire which can be presented to various sample groups? Please submit it to this list for review before deploying it. It would be good to have the questionnaire used by at least a few different people on this list (to test people in their localities) to get a wider (and hopefully more descriptive) variety of responses. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 24 Feb 1997 10:34:41 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Are URLs human readable? (was: [fwd] headers vs. MIME body part) At 4:19 PM -0500 97/2/21, Keith Moore wrote: > Funny, I would argue the opposite -- that most mailers do not have > routines for parsing URLs. Maybe it's a Macintosh thing - I think virtually all Mac email clients are working on, or already have, enhanced mailto URL support (as well as support for launching URLs they don't handle, such as http). > Of course, most mailers don't parse List-Info headers either. ... Yet. ;-) > 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. I think URLs are sufficiently human readable for our purposes. But, am willing to be convinced otherwise if they really aren't (see my next post "Are URLs human readable? User Testing"). Our goal is to make it easier for users to correctly control their list access. In meeting this goal we have to balance human readability (which we're hoping will not even be required for the majority of users as client software adopts interfaces for what we're producing here) with ease of software implementation. We need to remember that neither human readability or ease of implementation are the goal - they are just tools we are considering in reaching the goal. Either of these tools can be set aside if a better approach is found. (emphasis on "if" and "better".) By relying on URLs, which are an existing and widely deployed syntax, we make the implementation that much easier since there already exists a code base (and an understanding by most, if not all, of the client authors) for handling URLs. Some, if not many, clients have already implemented URL support. So, for example, when I receive a message with a mailto URL like we're describing, I just have to double-click it in my copy of Eudora to get a properly formatted command message. In effect, basic support for the use of URL syntax we're proposing is already implemented in some clients. What remains for those applications is to add a further layer separating the user from the command syntax by presenting the user with named buttons or menu items to select, and showing descriptive dialogs/alerts instead of the 'raw' command message. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 24 Feb 1997 17:32:16 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Are URLs human readable? (was: [fwd] headers vs. MIME body part) At 7:26 AM -0800 2/24/97, Grant Neufeld wrote: >Maybe it's a Macintosh thing - I think virtually all Mac email clients are >working on, or already have, enhanced mailto URL support (as well as >support for launching URLs they don't handle, such as http). Yes, and it works great. I've tried it in the Eudora beta, tried it with Netscape (all but ?body= works), and have heard commitments from Internet Explorer team, the TCP/Connect team, the Claris Emailer team, and the BBEdit/Bluto team. All of the above were on the Macintosh, but most of this folks also are cross-platform. So my assumption is that 80% to 90% of the mailers in use on the Mac today will work with these new headers by summer if users upgrade their products. - ------------------------------------------------------------------------ ..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: 24 Feb 1997 18:21:57 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > I don't want to formally declare variables with the URLs (too complicated > and requires modifications to the URL standard). What I want to know is if > including square brackets (as [] instead of hex encoding them) in the plain > text of an url (after the address specification) is okay. I don't think it's okay at all. The problem is that it will be mistaken for a real URL, when in reality, it's not usable until the [foo] subsitutions take place. > This way client implementers won't have to worry about handling the > variables any different than the rest of the plain text (they can just dump > it in along with the rest of the command text). However, if clients want to > get clever, they can 'recognize' that the brackets mean they should get > some info from the user before sending the message. No. In order for mailto URLs in List-* header fields to operate correctly, the user agent ABSOLUTELY MUST know that mailto URLs in List-* fields with brackets in them have to be treated differently than mailto URLs in other contexts. URLs are supposed to have uniform interpretation -- not different interpretation in different contexts. (Yes, I know about relative URLs in HTML documents, but those aren't generally visible to users.) > The reason for not wanting to hex-encode the brackets is it makes it > easier for human readers. I agree with not having the brackets hex-encoded, but for a different reason: the layer that handles the parameter subsitution needs to happen before the layer that handles hex-encoding. (otherwise, there's no way to tell whether %5Bfoo%5D means "substitute the value of parameter foo" or "transmit '[foo]' to the server".) Keith ---------------------------------------------------------------------- Date: 24 Feb 1997 18:52:38 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: URLs, List Headers, and VRLs(?) At 6:19 PM -0500 2/24/97, Keith Moore wrote: > > I don't want to formally declare variables with the URLs (too complicated > > and requires modifications to the URL standard). What I want to know is if > > including square brackets (as [] instead of hex encoding them) in the plain > > text of an url (after the address specification) is okay. > > I don't think it's okay at all. The problem is that it will be > mistaken for a real URL, when in reality, it's not usable until the > [foo] subsitutions take place. I disagree. In these cases, it is usable without the substitutions. In most all cases, the person will be subscribed successfully or else a help file will be returned with detailed instructions. Seems like something is better than nothing here... > > This way client implementers won't have to worry about handling the > > variables any different than the rest of the plain text (they can just dump > > it in along with the rest of the command text). However, if clients want to > > get clever, they can 'recognize' that the brackets mean they should get > > some info from the user before sending the message. > > No. In order for mailto URLs in List-* header fields to operate > correctly, the user agent ABSOLUTELY MUST know that mailto URLs in > List-* fields with brackets in them have to be treated differently > than mailto URLs in other contexts. In many cases it will be treated exactly the same. Not all URLs will need the variable substitution. In the cases where it should be treated differently, the consequences are still acceptable when the MUA doesn't perform the substitution. > URLs are supposed to have uniform interpretation -- not different > interpretation in different contexts. (Yes, I know about relative > URLs in HTML documents, but those aren't generally visible to users.) Why doesn't your argument apply to the existing URL extension which allows us to specify the body and subject? Most MUA's mangle the crap out of them, usually inserting a To address such as "list-headers@arpp.carleton.ca?subject=subscribe". Yet the extension is still very good IMHO, and provides useful functionality. In the variable substitution case, the results are more benign... ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 24 Feb 1997 19:06:41 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > > > I don't want to formally declare variables with the URLs (too > > > complicated and requires modifications to the URL > > > standard). What I want to know is if including square brackets > > > (as [] instead of hex encoding them) in the plain text of an url > > > (after the address specification) is okay. > > > > I don't think it's okay at all. The problem is that it will be > > mistaken for a real URL, when in reality, it's not usable until the > > [foo] subsitutions take place. > > I disagree. In these cases, it is usable without the substitutions. In > most all cases, the person will be subscribed successfully or else a help > file will be returned with detailed instructions. Seems like something is > better than nothing here... Not at all clear. I thought the point of encoding command-strings was to be compatible with existing list robots. How many existing list robots are going to recognize the strings [user-address] and [user-name] and do the right thing? If we have to change the list robots, we might as well get them to adopt a standard minimal command syntax... I'm also concerned with keeping usage of URLs consistent across the board. Any proposal that attempts to change the meaning of a URL according to context is going to meet with stiff resistance from me. (and probably from the web folks also) > > No. In order for mailto URLs in List-* header fields to operate > > correctly, the user agent ABSOLUTELY MUST know that mailto URLs in > > List-* fields with brackets in them have to be treated differently > > than mailto URLs in other contexts. > > In many cases it will be treated exactly the same. Not all URLs will need > the variable substitution. Perhaps some of the List-* functions (e.g. "help") will not need the variable substitution, but most of the time (e.g. "unsubscribe" on most list robots) the substitution will be needed. And it's completely unacceptable for a mail user agent to perform [] substitutions for every URL they encounter, whether in a List-* field or not. > > URLs are supposed to have uniform interpretation -- not different > > interpretation in different contexts. (Yes, I know about relative > > URLs in HTML documents, but those aren't generally visible to users.) > > Why doesn't your argument apply to the existing URL extension which allows > us to specify the body and subject? It does. The URL RFC is being revised, and these things are being fixed. > Most MUA's mangle the crap out of > them, usually inserting a To address such as > "list-headers@arpp.carleton.ca?subject=subscribe". Yet the extension is > still very good IMHO, and provides useful functionality. It might be useful, but it's not of sufficient technical quality to be on the Internet standards track. Keith ---------------------------------------------------------------------- Date: 25 Feb 1997 00:46:38 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) Earlier this evening, I wrote: > > > No. In order for mailto URLs in List-* header fields to operate > > > correctly, the user agent ABSOLUTELY MUST know that mailto URLs in > > > List-* fields with brackets in them have to be treated differently > > > than mailto URLs in other contexts. > > > > In many cases it will be treated exactly the same. Not all URLs will need > > the variable substitution. > > Perhaps some of the List-* functions (e.g. "help") will not need the > variable substitution, but most of the time (e.g. "unsubscribe" on > most list robots) the substitution will be needed. About an hour later, I realized I was wrong about that last statement. Most list robots can of course deal with "unsubscribe listname" where "listname" is hard-coded into the List-whatever field, as long as the user agent that interprets the List-whatever field and issues the request knows to put *the address that the user used to subscribe to the list* in the From header field and SMTP MAIL FROM command. (I *always* subscribe to a list using a sub-address.) I was confusing this proposal with a different proposal that would have required a [listname] parameter. So I can finally see why you want to use mailto URLs in headers, and I have to admit that it would provide a useful degree of compatibility with a number of existing UAs. However, I still think it's worth considering having mailto URLs that really need parameter substitution, be unusable until that substitution has been performed. E.g. for the NA-NET, which requires that the message body contain lines of the form Firstname: (user first name) Lastname: (user last name) Email-address: (user email address) [no, I didn't design this interface...I was stuck with it by the time I rewrote all the code. fortunately, we have a web front-end to this now.] the header might need to look like: List-foo: &mailto:na.join@na-net.ornl.gov?body=Firstname:&first&%0D%0ALastname: &last&%OD%OAEmail-address:&addr&%0D0A& where &first& is the user's first name, &last& is the user's last name, and &addr& is the user's subscription address. Note that the entire URL is also enclosed in &s. (and as this example indicates, you might need to deal with very long URLs and the possibility of line-breaking / wrapping.) Keith ---------------------------------------------------------------------- Date: 25 Feb 1997 02:28:20 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Are URLs human readable? (was: [fwd] headers vs. MIME body part) > >Maybe it's a Macintosh thing - I think virtually all Mac email clients are > >working on, or already have, enhanced mailto URL support (as well as > >support for launching URLs they don't handle, such as http). > > Yes, and it works great. I take it by "enhanced mailto", you mean the ability to grok things like '?Subject=' ? > So my assumption is that 80% to 90% of the mailers in use on the Mac today > will work with these new headers by summer if users upgrade their products. I don't know about Mac users, but as far as I can tell, typical users don't upgrade their mail readers that often... a huge number of email users out there don't even have MIME support yet, much less web support, and the first MIME spec came out in 1993. 80 to 90 percent of new user agents is a tiny fraction of the installed base. Of course, support for any new List-* field or notation would take even longer to deploy than one based on mailto. Keith ---------------------------------------------------------------------- Date: 25 Feb 1997 08:25:40 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: URLs, List Headers, and VRLs(?) At 12:43 AM -0500 2/25/97, Keith Moore wrote: > Earlier this evening, I wrote: > > > > > No. In order for mailto URLs in List-* header fields to operate > > > > correctly, the user agent ABSOLUTELY MUST know that mailto URLs in > > > > List-* fields with brackets in them have to be treated differently > > > > than mailto URLs in other contexts. > > > > > > In many cases it will be treated exactly the same. Not all URLs will >need > > > the variable substitution. > > > > Perhaps some of the List-* functions (e.g. "help") will not need the > > variable substitution, but most of the time (e.g. "unsubscribe" on > > most list robots) the substitution will be needed. > > About an hour later, I realized I was wrong about that last statement. > Most list robots can of course deal with "unsubscribe listname" where > "listname" is hard-coded into the List-whatever field, as long as the > user agent that interprets the List-whatever field and issues the > request knows to put *the address that the user used to subscribe to > the list* in the From header field and SMTP MAIL FROM command. > (I *always* subscribe to a list using a sub-address.) How would the MUA determine this? Especially in the case of a message forwarded to another person so that the new person could subscribe? > So I can finally see why you want to use mailto URLs in headers, and I > have to admit that it would provide a useful degree of compatibility > with a number of existing UAs. However, I still think it's worth > considering having mailto URLs that really need parameter > substitution, be unusable until that substitution has been performed. I still don't see why we should make this more convoluted than necessary in order to purposefully _break_ it in certain environments where the results will still be useful. > E.g. for the NA-NET, which requires that the message body contain > lines of the form > > Firstname: (user first name) > Lastname: (user last name) > Email-address: (user email address) > > the header might need to look like: > > List-foo: >&mailto:na.join@na-net.ornl.gov?body=Firstname:&first&%0D%0ALastname: > &last&%OD%OAEmail-address:&addr&%0D0A& > > where &first& is the user's first name, &last& is the user's last > name, and &addr& is the user's subscription address. Note that the > entire URL is also enclosed in &s. > > (and as this example indicates, you might need to deal with very long > URLs and the possibility of line-breaking / wrapping.) I think this is pushing the limits of compatibility. While we should strive to be compatible with as many existing servers as possible, I think multi-line commands are the extreme minority. The added complexity just doesn't seem worth it... Grant's current proposal is great for it's simplicity, yet is still applicable to the wide majority of servers. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 25 Feb 1997 08:39:26 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: URLs, List Headers, and VRLs(?) At 7:03 PM -0500 2/24/97, Keith Moore wrote: > Not at all clear. I thought the point of encoding command-strings was > to be compatible with existing list robots. How many existing list > robots are going to recognize the strings [user-address] and > [user-name] and do the right thing? If we have to change the list > robots, we might as well get them to adopt a standard minimal command > syntax... Most I know of won't accept that. Any that don't accept it will send a response with the correct instructions. This is still better than nothing, and very useful. > I'm also concerned with keeping usage of URLs consistent across the > board. Any proposal that attempts to change the meaning of a URL > according to context is going to meet with stiff resistance from me. > (and probably from the web folks also) Agreed. That's why we should make it valid as a normal URL, but have bonus properties if interpreted in-context. > > In many cases it will be treated exactly the same. Not all URLs will need > > the variable substitution. > > Perhaps some of the List-* functions (e.g. "help") will not need the > variable substitution, but most of the time (e.g. "unsubscribe" on > most list robots) the substitution will be needed. Well, the "help" command is the most important, by far. If we could only have one, that would be it. > And it's completely unacceptable for a mail user agent to perform [] > substitutions for every URL they encounter, whether in a List-* field > or not. Agreed. This should ONLY be done when taken from a List-* header or appropriate MIME part. > > > URLs are supposed to have uniform interpretation -- not different > > > interpretation in different contexts. (Yes, I know about relative > > > URLs in HTML documents, but those aren't generally visible to users.) > > > > Why doesn't your argument apply to the existing URL extension which allows > > us to specify the body and subject? > > It does. The URL RFC is being revised, and these things are being fixed. Interesting... I wasn't aware of that. What kind of options are being considered? ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 25 Feb 1997 10:27:37 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > > About an hour later, I realized I was wrong about that last statement. > > Most list robots can of course deal with "unsubscribe listname" where > > "listname" is hard-coded into the List-whatever field, as long as the > > user agent that interprets the List-whatever field and issues the > > request knows to put *the address that the user used to subscribe to > > the list* in the From header field and SMTP MAIL FROM command. > > (I *always* subscribe to a list using a sub-address.) > > How would the MUA determine this? Especially in the case of a message > forwarded to another person so that the new person could subscribe? For a subscribe message, the MUA sending the request could ask the user -- give him a blank to type into and default it to his normal From address. (of course, that's an invitation to subscribe other people...) > I still don't see why we should make this more convoluted than necessary in > order to purposefully _break_ it in certain environments where the results > will still be useful. A URL with parameters is broken either way. It's a question of how it breaks. I'd rather things break in a way that they're immediately visible to the user, than to send a known bogus request off to a remote server and have some error message (which might or might not be meaningful) returned. And I'd rather not have yet another frob (parameter syntax) creep into URLs. (Though if nearly every listserver were to support "subscribe listname" "unsubscribe listname" and "help", parameters will neither be widely implemented nor widely used...and we might be better off without them!) > > List-foo: > >&mailto:na.join@na-net.ornl.gov?body=Firstname:&first&%0D%0ALastname: > > &last&%OD%OAEmail-address:&addr&%0D0A& [...] > > (and as this example indicates, you might need to deal with very long > > URLs and the possibility of line-breaking / wrapping.) > > I think this is pushing the limits of compatibility. While we should > strive to be compatible with as many existing servers as possible, I think > multi-line commands are the extreme minority. The added complexity just > doesn't seem worth it... I won't worry if na-net isn't supported; as I said, I'm willing to write a majordomo/listserv/listproc/whatever like interface for it. But it seems to me that "mailto:" + list address + "?Subject=" + "subscribe listname" is already pushing the ~80 character limit at which some things like to wrap lines. If the list address or the list name is even moderately long, there's a good chance it will wrap. (Note that I didn't count the List-foo header name, since you can always wrap immediately after the colon) > Grant's current proposal is great for it's simplicity, yet is still > applicable to the wide majority of servers. Simplicity is indeed a good thing, as long as it's not too simple. If too many things break, it's too simple. Of course this is a judgement call. Right now it seems to break with + list addresses / list names long enough to make the URL wrap (perhaps a lot of them...one could check the PAML or the raw HTML of some of the list-o'-lists web pages to get a reasonable sample.) + lists that otherwise require very long requests (probably a small minority) + lists that require parameter substitution (at least to the degree that it's compatible with some existing UAs) Keith ---------------------------------------------------------------------- Date: 25 Feb 1997 12:35:32 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Using URLs I think that any use we make of URLs should not be context-sensitive. If I can make an URL with variable identifiers, I want to be able to use that URL most anywhere that I can use other URLs (web pages, mail message bodies, tv ads...) I'm sure that if we start using URLs in a unique way in list headers (or MIME parts, or whatever) that people will use the same URLs in other contexts, too, regardless of whether that is officially accepted. So, what I suggest we do is to build our proposal around URL syntax (especially the 'enhanced mailto URL'). This means that we will not initially have variable support in our proposal. More importantly, it means that we will have to work with the URL people to define a consistent way for identifying variables in mailto (and possibly other) urls. This compromise means we will be (hopefully only temporarily) excluding command syntaxes which require variable data (e.g., "subscribe list [user name]"). I feel that at this time it is a reasonable compromise to make in order to be able to move forward in the near term. In the long term, it defines a path for upgrading the standard to accommodate variables (by enhancing the URL standards), which will take a relatively long time to work out, regardless of our path. By building on a widely deployed standard that is continuing to grow, we greatly increase the likelihood of adoption without limiting our adaptability to future developments. As an aside: I know of no list server which requires variables for help/instruction file/message retrieval, so all servers should benefit from at least the proposed List-Help header. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 12:49:31 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: plaintext variables and servers What about servers receiving invalid messages like "subscribe list [username]"? Well, servers that implement the command URLs for their services should at the same time implement support for handling invalid responses where the variable hasn't been substituted but instead has been included as plaintext. If the server software can't handle that sort of invalid response, they shouldn't produce the command URLs that can generate it. Otherwise, they're just asking for trouble, IMHO. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 13:00:45 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 9:09 PM -0500 97/2/23, Keith Moore wrote: > Long experience with 822 and > MIME implementations seems to indicate that people very commonly > implement features without reading (or fully reading) the specifications. ... > What percentage of implementors of List-* responders will read the URL spec, > paying full attention to the particulars of URL syntax, encoding > rules, and security considerations? This is a very good point. Having a well thought out standard is pointless if it's not well implemented. We need to provide ways to encourage correct adoption. Primary among these is keeping it simple. Other methods we should use are to work with list server authors to help them implement automation tools so that individual list-managers aren't responsible for coding the headers. It would also be useful to have validation tools. We won't be able prevent every possible mess, but we can try to minimize them. I think half the battle will be to get AOL to properly implement this ;-) - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 13:36:17 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) At 10:59 PM -0500 97/2/23, Keith Moore wrote: > Speaking as one of the > applications area directors, I hate to create a working group for > something that's so simple. ... > If you can produce a > draft that is obviously of Proposed Standard quality, we can just > issue a four week Last Call. Well, considering your position, I guess that would be the best route for us to take for formalization. > Pay special attention to the requirement that the specification "has > resolved known design choices". The people who review this spec are > going to need to be convinced that (e.g.): > > + multiple List-* header fields are better than a signal List-Info > field or a MIME type, My reasons for favoring multiple header fields: - more easily interpreted by humans - less complicated on a per-command basis, meaning easier to implement (and easier to implement correctly) > + mailto URLs are better than parameter lists, My reasons: - URLs are an established syntax - URLs can accommodate future developments - URLs can easily describe different access protocols (mailto, http, ftp...) - Using URLs will provide immediate access to some existing clients > + encoding the message sent to the list robot is better than having a > standard command language. My reasons: - A standard command language will take years to define and implement (if it is ever successfully implemented, which is not a point of great optimism) - Can be implemented to support most (if not all) existing command syntaxes - Is flexible enough to support other access protocols such as http. > + internationalization has been adequately addressed, e.g: > do you allow command names in other charsets besides ASCII? > do you allow user names in other charsets besides ASCII? > how does the user agent know what charset to transmit? All of this is up to the URL standard. If URLs support it, our proposal supports it. > + security considerations have been adequately addressed. > (e.g. how do you prevent the use of list-* fields to > trick people into forging usenet votes, requests for > spam, or threatening messages to president@whitehouse.gov?) This depends entirely on client implementation. Our guidelines for developers will specify that any 'posting' action (sending a mail message, submitting http form data, etc.) will require user confirmation. > So my recommendation at this point is: Document the problem you're > trying to solve, break down the problem into managable pieces, discuss > different ways to implement those pieces and the cost vs benefit of > each. Then write up a spec that not only clearly documents the > protocol, but also makes it clear that most of the relevant issues > have been thought about and that the choices made are reasonable. So, are you saying that we should include discussion of why headers were chosen over other transport mechanisms, including what those other mechanisms were? (and the same for URLs over other syntaxes?) Should we be including a comparative analysis? I would have thought those things would not go into a final standard, but would rather be in the archived discussion documents associated with the standard. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 13:43:58 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 11:10 PM -0500 97/2/23, BruceLeban@akimbo.com wrote: > let's just state that if anything after the ? uses a literal > bracket then it must be escaped as %5B/%5D for the benefit of any future > automated use of brackets. Hex encoding square brackets is the URL standard now, isn't it? > We should also suggest (but not require) that list software check for: > [1] unremoved brackets around parameters and unreplaced parameters If they're going to supply command URLs with variables, they better support command messages with unresolved variables. > [2] untranslated %XX codes. Good point. Definitly something to recommend. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 14:21:48 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Are URLs human readable? (was: [fwd] headers vs. MIME body part) At 2:25 AM -0500 97/2/25, Keith Moore wrote: > I take it by "enhanced mailto", you mean the ability to grok things > like '?Subject=' ? Yes, as per: ftp://ftp.internic.net//internet-drafts/draft-hoffman-mailto-url-00.txt > but as far as I can tell, typical users > don't upgrade their mail readers that often... a huge number of email > users out there don't even have MIME support yet, much less web > support, ... > Of course, support for any new List-* field or notation would take > even longer to deploy than one based on mailto. Which is why we should start as soon as possible so that it reaches general use as soon as possible. My earlier joke about AOL may not be quite so silly - if AOL adopts this protocol in their client software, that will mean a significant number of users upgrading fairly quickly. Since AOL users are disproportionately problem users for list managers, this could result in a notable reduction of list-manager headaches. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 14:23:12 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 6:19 PM -0500 97/2/24, Keith Moore wrote: > > I don't want to formally declare variables with the URLs (too complicated > > and requires modifications to the URL standard). What I want to know is if > > including square brackets (as [] instead of hex encoding them) in the plain > > text of an url (after the address specification) is okay. > > I don't think it's okay at all. The problem is that it will be > mistaken for a real URL, when in reality, it's not usable until the > [foo] subsitutions take place. I disagree. It will be usable since the bracketed variable will be included as plaintext. If the user reviews the message by hand (as is the general practice with existing mailto supporting clients) they will see the variable field in the message, which will lead many of them to replace the variable with some information. As I finally noted today, if server software hasn't been upgraded to somehow handle variable fields that haven't been properly substituted for, they should not put out the URLs that can generate those messages. > URLs are supposed to have uniform interpretation -- not different > interpretation in different contexts. I adamantly agree with you on that, which is why I'm suggesting we move the discussion of supporting variables in URLs from this small application of URLs to the broader scope of all URL (or at least mailto URL) usage. In the short term - no variable support. In the long term, I certainly hope we can work something out. > I agree with not having the brackets hex-encoded, but for a different > reason: the layer that handles the parameter subsitution needs to > happen before the layer that handles hex-encoding. Good point. I've added that comment to the proposal. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 14:25:09 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 12:43 AM -0500 97/2/25, Keith Moore wrote: > Most list robots can of course deal with "unsubscribe listname" where > "listname" is hard-coded into the List-whatever field, as long as the > user agent that interprets the List-whatever field and issues the > request knows to put *the address that the user used to subscribe to > the list* in the From header field and SMTP MAIL FROM command. Since most mail lists do not include individual subscriber addresses in outgoing header fields, this could be a problem for people who subscribe from multiple addresses. I think somewhere in the proposal I mention something about client applications prompting users to choose which address to use for command messages when the user has multiple addresses. (the current Eudora Beta I'm using has a little popup menu for just that in outgoing message windows). > So I can finally see why you want to use mailto URLs in headers, and I > have to admit that it would provide a useful degree of compatibility > with a number of existing UAs. However, I still think it's worth > considering having mailto URLs that really need parameter > substitution, be unusable until that substitution has been performed. I'd say we move that discussion to the more general discussion of mailto URLs overall, and not just in the context of List- headers. > where &first& is the user's first name, &last& is the user's last > name, and &addr& is the user's subscription address. Note that the > entire URL is also enclosed in &s. Is there a reason(s) you chose & as a delimiter? What advantages does it have over other characters? - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 14:26:16 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 7:03 PM -0500 97/2/24, Keith Moore wrote: > How many existing list > robots are going to recognize the strings [user-address] and > [user-name] and do the right thing? If we have to change the list > robots, we might as well get them to adopt a standard minimal command > syntax... I think it would be easier to get variable-dependant server software to add a check for bracketed command parameters than to get them to adopt a whole new syntax - it's a lot less coding. > I'm also concerned with keeping usage of URLs consistent across the > board. Any proposal that attempts to change the meaning of a URL > according to context is going to meet with stiff resistance from me. "Me too." (sorry, couldn't resist an excuse to throw in a 'me too' message :-) - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 14:38:50 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 8:09 AM -0500 97/2/25, Joshua D. Baer wrote: > I think this is pushing the limits of compatibility. While we should > strive to be compatible with as many existing servers as possible, I think > multi-line commands are the extreme minority. The added complexity just > doesn't seem worth it... I disagree. It's just a matter of throwing in %0D%0A to indicate a new line. Where's the complexity in that? Yes hex-encoding is not exactly easy to read - but we're already using hex-encoding elsewhere so it doesn't add complexity to what we're proposing. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 14:58:47 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Multiple Addresses, lines too long (was: URLs, List Headers, and VRLs(?)) At 10:24 AM -0500 97/2/25, Keith Moore wrote: > > > as long as the > > > user agent that interprets the List-whatever field and issues the > > > request knows to put *the address that the user used to subscribe to > > > the list* in the From header field and SMTP MAIL FROM command. ... > For a subscribe message, the MUA sending the request could ask the user -- > give him a blank to type into and default it to his normal From address. > > (of course, that's an invitation to subscribe other people...) Which is why the client should probably only offer addresses the user has properly registered with it (as in the personalities in Eudora). This will be an issue for clients that don't support multiple addresses, though. They may have to provide a blank for the user. Some kind of client-side authentication would be a big help to prevent mist-typed addresses. > (Though if nearly every listserver were to support "subscribe listname" > "unsubscribe listname" and "help", parameters will neither be widely > implemented nor widely used...and we might be better off without them!) Agreed. > But it seems to me that "mailto:" + list address + "?Subject=" > + "subscribe listname" is already pushing the ~80 character limit at > which some things like to wrap lines. If the list address or the > list name is even moderately long, there's a good chance it will wrap. Whitespace is illegal in urls. For message header fields, which have line-length limits, the client should ignore (strip out) all the spaces, tabs and line breaks in an angle bracket enclosed URL. So that: List-Help: Is treated by the client as . > Right now it seems to break with ... > + lists that require parameter substitution (at least to the > degree that it's compatible with some existing UAs) I'm willing to leave that issue as unresolved for the first standard produced from this proposal, since we can bypass many of those situations, or at least accommodate them through List-Help. - -- "Thanks for the nose-news, neighbor!" - Ned Flanders gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 25 Feb 1997 15:05:05 -0500 From: (suppressed)@frutiger.staffs.ac.uk Subject: Re: URLs, List Headers, and VRLs(?) Grant Neufeld wrote: > > I agree with not having the brackets hex-encoded, but for a different > > reason: the layer that handles the parameter subsitution needs to > > happen before the layer that handles hex-encoding. > > Good point. I've added that comment to the proposal. Well, this has been mentioned here several times and I'm none the wiser ;-). Surely the whole point of url encoding is that raw characters like "[" and "]" should not appear in a URL? What exactly is wrong with decoding a %-encoded url, then processing any necessary substitutions? Please enlighten me, because I really don't understand this at all! ( :-]) James ---------------------------------------------------------------------- Date: 25 Feb 1997 16:34:12 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: plaintext variables and servers At 12:41 PM -0500 2/25/97, Grant Neufeld wrote: > What about servers receiving invalid messages like "subscribe list >[username]"? > > Well, servers that implement the command URLs for their services should at > the same time implement support for handling invalid responses where the > variable hasn't been substituted but instead has been included as plaintext. > > If the server software can't handle that sort of invalid response, they > shouldn't produce the command URLs that can generate it. Otherwise, they're > just asking for trouble, IMHO. This is a good point. In most cases, headers will only be produced for servers ready to accept them. So there shouldn't be any headers pointing to servers which don't understand them. As long as we include this recommendation for handling unresolved variables, we should be OK. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 25 Feb 1997 18:19:09 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > I disagree. It's just a matter of throwing in %0D%0A to indicate a new > line. Where's the complexity in that? Yes hex-encoding is not exactly easy > to read - but we're already using hex-encoding elsewhere so it doesn't add > complexity to what we're proposing. My suggestion (perhaps not sufficiently articulated) was that perhaps this format should define how to break up a long URL into chunks so that it could survive header wrapping and folding by MTAs that do such things. But I'm curious as to how many existing UAs support mailto with %XX encoding. Using exmh, I clicked on the example mailto URL that I sent in an earlier message. It did pop up a window with the right To address, but it didn't decode either the ?body= or the the %0D%0A notation. Just for grins, try clicking on the list-subscribe header in this message to subscribe to a fake list. If it doesn't work, let me know that as well, and why it doesn't work. After a few days, I'll summarize the results to the list. Keith ---------------------------------------------------------------------- Date: 25 Feb 1997 23:46:25 -0500 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: URLs, List Headers, and VRLs(?) At 23:15 25/02/97, Keith Moore wrote: >But I'm curious as to how many existing UAs support mailto with %XX >encoding. Keith, As I understand it, the use of %-encoding is defined in the extended mailto: draft. It's not yet an rfc, so I wouldn't expect widespread adoption in existing MUAs ;-) ( :-]) James ---------------------------------------------------------------------- Date: 26 Feb 1997 00:07:18 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Using URLs > So, what I suggest we do is to build our proposal around URL syntax > (especially the 'enhanced mailto URL'). This means that we will not > initially have variable support in our proposal. > > More importantly, it means that we will have to work with the URL people to > define a consistent way for identifying variables in mailto (and possibly > other) urls. I doubt that this will fly. If URLs are to be independent of context, they can't be sensitive to the values of certain context-specific parameters any more than they can be sensitive to where they are placed. I suggest that the List-* protocol limit its scope and say that the List-* stuff only works with robots that can derive everything they need to grok a command from: a constant ASCII-only string in the Subject field, a constant ASCII-only string in the message body, and the normal submitter information (return address and perhaps name) in the header From field. Keith p.s. just in case I haven't already made it clear -- I think it will help a great deal if the internet-draft outlines the rationale behind the design decisions, and perhaps even compares that decision with alternatives. ---------------------------------------------------------------------- Date: 26 Feb 1997 00:27:52 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) > > Speaking as one of the > > applications area directors, I hate to create a working group for > > something that's so simple. > ... > > If you can produce a > > draft that is obviously of Proposed Standard quality, we can just > > issue a four week Last Call. > > Well, considering your position, I guess that would be the best route for > us to take for formalization. After talking about this with my co-Director, Harald Alvestrand, I think it would be a good idea if people could publish an internet-draft well in advance of the Memphis IETF (April 7-11), and schedule a 1-hour BOF session there (probably on Wednesday) to discuss it. (yes, it's only an hour, but that's a good way to introduce things...and discussions tend to continue in the hallways or in the hotel bar...) If the proposal can be smoothed out by then, and the draft contains both the protocol itself and the design rationale (perhaps in separate drafts or put the design rationale in an appendix), the BOF should help us determine whether there's community interest and how difficult it will be to get community consensus. If we have interest and near-consensus on this draft, we'll use the session to get feedback and suggestions, let the authors respond to comments and/or make appropriate changes, and if all goes well we will fast-track it for Last Call (i.e. without forming a working group) for Proposed Standard. If we have little or no interest (seems unlikely), we might decide to just make this Informational or Experimental. If we have interest but a lack of consensus, we might need to form a working group after all. To apply for a BOF, you need: a) a chairperson b) an acronym c) a stated purpose and agenda To register for a BOF, send a note including the above, along with an indication of how many people you think there will be, to agenda@ietf.org. Copy me <(suppressed)@cs.utk.edu> and Harald Alvestrand <(suppressed)@uninett.no> on that note. Slots are filling up, so you need to do this in the next day or three. > So, are you saying that we should include discussion of why headers were > chosen over other transport mechanisms, including what those other > mechanisms were? (and the same for URLs over other syntaxes?) Should we be > including a comparative analysis? > > I would have thought those things would not go into a final standard, but > would rather be in the archived discussion documents associated with the > standard. Yep, that's what I think also. But I think if you include design rationale, it will head off some potential knee-jerk reactions that people might have, that would make them unnecessarily hostile to the proposal. That way, they can read your rationale before they criticize it. While a number of people in IETF will be willing to read the Internet-Draft (at least at Last Call time), few of them will bother to poke through the list archives. So I guess I'd include the design rationale in an appendix, where it can easily be deleted later if need be. Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 00:42:30 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > > where &first& is the user's first name, &last& is the user's last > > name, and &addr& is the user's subscription address. Note that the > > entire URL is also enclosed in &s. > > Is there a reason(s) you chose & as a delimiter? What advantages does it > have over other characters? No particular reason. Though I suspect it's less likely to appear in an email address than [ and ] . Basically I looked across the top row of my keyboard for a character that didn't seem likely to appear in an email address. !@#%_+-[] are fairly common, () are comments, which sort of leaves ~^&*{}|`' (now that I think of it, some UNIX-based list robots freak out when they see wierd characters in an address and start screaming "SECURITY HOLE". & is probably one of those characters) Actually, while replying to an earlier message, I started to include a strawman proposal for how to do parameters...and immediately realized that you either have to make them mandantory (i.e. the user agent doesn't submit the message if it doesn't know what text to substitute) or you need a way to say "if you know this parameter, add its text here; otherwise, do this" where "this" is either: (a) substitute a constant string, or (b) fail. [the reason you need a facility like this is because some list robots insist on having certain parameters like users' names, which the user agent might or might not know. e.g. listserv insists on having a first name and a last name if you supply either one] Which would lead to something like the UNIX shell syntax, where ${foo-bar} means substitute the value of parameter "foo" if "foo" is defined, else substitute the string "bar". Perhaps $foo would mean "substitute the value of parameter foo if it is defined, else substitute the empty string" ...all of which makes me suggest that we leave out parameters. Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 00:48:58 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Multiple Addresses, lines too long (was: URLs, List Headers, and VRLs(?)) > > But it seems to me that "mailto:" + list address + "?Subject=" > > + "subscribe listname" is already pushing the ~80 character limit at > > which some things like to wrap lines. If the list address or the > > list name is even moderately long, there's a good chance it will wrap. > > Whitespace is illegal in urls. For message header fields, which have > line-length limits, the client should ignore (strip out) all the spaces, > tabs and line breaks in an angle bracket enclosed URL. So that: > > List-Help: Subject=help> > > Is treated by the client as . A good idea, but it's almost certainly not compatible with existing UAs, and that's the big reason for using mailto. If enough lists required long List-foo headers that were likely to be wrapped, it might argue for using some other syntax. Given that large lists of lists are available, it should be fairly easy to estimate what percentage of existing lists this will work with. Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 00:54:18 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > What exactly is wrong with decoding a %-encoded url, then processing > any necessary substitutions? try an example: mailto:moore@%5C128.169.201.1%5D?Subject=subscribe%20listname%20%5Cusername%5D becomes mailto:moore@[128.169.201.1]?Subject=subscribe listname [username] Now, which brackets are parameters and which ones are literals? True, you can parse the URL to find out, but that's just adding cruft that's specific to both list-foo and certain fields of mailto. Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 01:11:25 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > As I understand it, the use of %-encoding is defined in the extended mailto: > draft. It's not yet an rfc, so I wouldn't expect widespread adoption in > existing MUAs :-) True. But if the reason for using mailto: is backward compatibility with existing UAs, and %XX is necessary, and mailto: doesn't work with existing UAs, there's a little bit less reason to use mailto. Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 01:52:38 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) At 9:24 PM -0800 2/25/97, Keith Moore wrote: >After talking about this with my co-Director, Harald Alvestrand, I really appreciate that you two are taking an active role in this!! >I >think it would be a good idea if people could publish an >internet-draft well in advance of the Memphis IETF (April 7-11), For those who are writing this draft, there is a *strict* cutoff of submissions of internet-drafts two weeks before the conference, so the real deadline is then. >and >schedule a 1-hour BOF session there (probably on Wednesday) to discuss >it. (yes, it's only an hour, but that's a good way to introduce >things...and discussions tend to continue in the hallways or in the >hotel bar...) > >If the proposal can be smoothed out by then, and the draft contains >both the protocol itself and the design rationale (perhaps in separate >drafts or put the design rationale in an appendix), the BOF should >help us determine whether there's community interest and how difficult >it will be to get community consensus. > >If we have interest and near-consensus on this draft, we'll use the >session to get feedback and suggestions, let the authors respond to >comments and/or make appropriate changes, and if all goes well we will >fast-track it for Last Call (i.e. without forming a working group) for >Proposed Standard. Yeah! >If we have little or no interest (seems unlikely), we might decide to >just make this Informational or Experimental. > >If we have interest but a lack of consensus, we might need to form a >working group after all. > >To apply for a BOF, you need: > >a) a chairperson >b) an acronym How about IETF-LMH for List Management Headers. >c) a stated purpose and agenda > >To register for a BOF, send a note including the above, along with an >indication of how many people you think there will be, to >agenda@ietf.org. Copy me <(suppressed)@cs.utk.edu> and Harald Alvestrand ><(suppressed)@uninett.no> on that note. Slots are filling up, so you need to >do this in the next day or three. > >> So, are you saying that we should include discussion of why headers were >> chosen over other transport mechanisms, including what those other >> mechanisms were? (and the same for URLs over other syntaxes?) Should we be >> including a comparative analysis? >> >> I would have thought those things would not go into a final standard, but >> would rather be in the archived discussion documents associated with the >> standard. > >Yep, that's what I think also. But I think if you include design >rationale, it will head off some potential knee-jerk reactions that >people might have, that would make them unnecessarily hostile to the >proposal. That way, they can read your rationale before they >criticize it. While a number of people in IETF will be willing to >read the Internet-Draft (at least at Last Call time), few of them will >bother to poke through the list archives. > >So I guess I'd include the design rationale in an appendix, where it >can easily be deleted later if need be. - ------------------------------------------------------------------------ ..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: 26 Feb 1997 02:02:44 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Fast Track Through IETF (was: [fwd] headers vs. MIME body part) > >After talking about this with my co-Director, Harald Alvestrand, > > I really appreciate that you two are taking an active role in this!! well, you're not the only ones who get annoyed when people send unsubscribe messages to lists! (and I was already trying to find someone to take this on...) > For those who are writing this draft, there is a *strict* cutoff of > submissions of internet-drafts two weeks before the conference, so the real > deadline is then. yes indeed. I should have said that. > >To apply for a BOF, you need: > > > >a) a chairperson > >b) an acronym > > How about IETF-LMH for List Management Headers. IETF is redundant for an IETF BOF. I suggest LISTHDRS. That will make it easy to recognize on the calendar. (they'll add a -BOF suffix) Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 05:48:53 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: URLs, List Headers, and VRLs(?) At 12:39 AM -0500 2/26/97, Keith Moore wrote: > ...all of which makes me suggest that we leave out parameters. I agree. This is so simple without them, yet exceedingly complicated with them. It seems (just a general observation) that lists are moving away from this requirement anyway. list-on@..., list-off@... addresses, and addresses which accept simple commands are becoming more and more popular. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 26 Feb 1997 05:49:58 -0500 From: "Joshua D. Baer" <(suppressed)@skyweyr.com> Subject: Re: Using URLs At 12:03 AM -0500 2/26/97, Keith Moore wrote: > p.s. just in case I haven't already made it clear -- I think it will > help a great deal if the internet-draft outlines the rationale behind > the design decisions, and perhaps even compares that decision with > alternatives. Couldn't agree more... this is great dialogue. I'm saving all of this discussion and summarizing it in the first rev of the internet-draft. ~Josh - -- ---------------------------------- Joshua D. Baer SkyList Mailing List Hosting Service http://cgi.skyweyr.com/Guest.Login ---------------------------------------------------------------------- Date: 26 Feb 1997 07:22:12 -0500 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: URLs, List Headers, and VRLs(?) At 06:08 26/2/97, Keith Moore wrote: >> As I understand it, the use of %-encoding is defined in the extended mailto: >> draft. It's not yet an rfc, so I wouldn't expect widespread adoption in >> existing MUAs :-) > >True. But if the reason for using mailto: is backward compatibility with >existing UAs, and %XX is necessary, and mailto: doesn't work with existing >UAs, there's a little bit less reason to use mailto. > >Keith I believe that much of the excitement about this proposal came out of Christopher's announcement that Eudora would be supporting the extended mailto: syntax. I quote: >Date: Tue, 11 Feb 1997 00:08:52 -0800 >From: Christopher Allen <(suppressed)@consensus.com> >Subject: Re: Enhanced Mailto Support in Next Eudora Mac [snip] >Yeah! It look's like the Mac is on target with mailto! We have support it >now in Eudora/Mac, Emailer, TCP/Connect, and Netscape, and I believe that >BBEdit/Bluto is committed. Anyone know an address for the Internet >Explorer/Mac team? So we've been generally proceeding on the assumption that support for extended mailto: will be deployed alongside the list headers. I don't think backwards compatibility was the main driving force here ;-) Perhaps more thought should be given to backwards-compatibility, though. Eventually, there will be several kinds of client. 1. Doesn't support mailto: 2. Supports basic mailto:, but doesn't understand extended mailto: syntax 3. Supports extended mailto: Oh, I forgot: 4. Broken - thinks it understands mailto:, but doesn't ;-) Looking at the above, though, I'm confirmed in my opinion that the last thing we need to add here is yet another modification of mailto: syntax which lies outside the current internet draft. Since the main aim of the proposal is to get future clients to automate the list management process on behalf of the user, I don't think it's unreasonable to expect conforming clients to implement the extended mailto: support alongside the list headers. What needs to be taken into account is what kind of messages (if any) are likely to be generated by broken / dumb UAs. I gather, though, that the main thrust of your argument is that we have to justify the use of mailto: in itself, rather than some other method such as a header with a straight list of parameters. Am I right? ( :-]) James ---------------------------------------------------------------------- Date: 26 Feb 1997 07:23:13 -0500 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: URLs, List Headers, and VRLs(?) >> What exactly is wrong with decoding a %-encoded url, then processing >> any necessary substitutions? > >try an example: > >mailto:moore@%5C128.169.201.1%5D?Subject=subscribe%20listname%20%5Cusername%5D > >becomes > >mailto:moore@[128.169.201.1]?Subject=subscribe listname [username] > >Now, which brackets are parameters and which ones are literals? True, >you can parse the URL to find out, but that's just adding cruft that's >specific to both list-foo and certain fields of mailto. Everything left of the "?" is an email address (no substitution). Everything after the Subject= is header text. Clients already have to parse this much. A dumb UA will send: Subject: subscribe listname [username] An intelligent one will send: Subject: subscribe listname Firstname Lastname - - or whatever is finally decided ;-). The proposal already states that servers that include variable substitution in the headers should catch the first case and handle it gracefully (otherwise they have no business using variable substitution in the first place). Where's the "added cruft" of which you speak? (Sounds like one of those ads for dog food - "PAL, with added marrowbone"). I am, though, firmly in the camp that says variable substitution in urls should be a part of the ongoing url standards process. From looking at the latest update on the web page (and from Grant's comments on the list), I gather that the discussion about variable substitution in urls is now outside the scope of the initial list-header proposal. BTW, is there a mailing list for discussion of the mailto: draft? ( :-]) James ---------------------------------------------------------------------- Date: 26 Feb 1997 09:19:15 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > I gather, though, that the main thrust of your argument is that we have to > justify the use of mailto: in itself, rather than some other method such as > a header with a straight list of parameters. Am I right? It's not like I'm making you do this... it's just that putting a URL in a message header, rather than just an email address, might look a little strange to some long-time email types. So it might help to document the reasons for doing this. (It might also be that I'm the only one who thinks it's strange. :) Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 09:22:44 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: URLs, List Headers, and VRLs(?) > Everything left of the "?" is an email address (no substitution). > Everything after the Subject= is header text. Clients already have to parse > this much. actually, no. they could hand the whole thing off to a web browser and say "you deal with it". and for all I know there may be some list robot that wants to use brackets. inserting a new processing step (the [] substitution) *between* existing layers (URL parsing and URL dispatching) is just bad design. Keith ---------------------------------------------------------------------- Date: 26 Feb 1997 12:15:02 -0500 From: (suppressed)@frutiger.staffs.ac.uk (James Berriman) Subject: Re: URLs, List Headers, and VRLs(?) At 14:19 26/2/97, Keith Moore wrote: >inserting a new processing step (the [] substitution) *between* >existing layers (URL parsing and URL dispatching) is just bad design. > >Keith In my view, the substitution should be an integral part of the URL parsing step. Which is why I see the substitution of variables as an issue which needs to be addressed in some future version of the url specs, rather than tacked-on elsewhere. So, in essence I think we actually agree ;-) ( :-]) James ---------------------------------------------------------------------- Date: 26 Feb 1997 13:21:13 -0500 From: "Adam C. Engst" <(suppressed)@tidbits.com> Subject: Re: URLs, List Headers, and VRLs(?) >> I gather, though, that the main thrust of your argument is that we have to >> justify the use of mailto: in itself, rather than some other method such as >> a header with a straight list of parameters. Am I right? > >It's not like I'm making you do this... it's just that putting a URL in >a message header, rather than just an email address, might look a little >strange to some long-time email types. So it might help to document >the reasons for doing this. > >(It might also be that I'm the only one who thinks it's strange. :) I'm not reading carefully enough to comment on the pros and cons (although I tend to agree with Josh that the mailto URL with variable substitution is WAY more complex than the rest and should be left for a later day). The only comment I will make is that as a user, the mailto URL with all the escaped characters is really ugly. I understand that headers aren't meant to be particularly human readable, but in general I think it's best to keep things human readable whenever possible. Otherwise, the sense that email is hard and mysterious just gets more emphasis. 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: 26 Feb 1997 13:54:37 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: URLs, List Headers, and VRLs(?) At 10:18 AM -0800 2/26/97, Adam C. Engst wrote: >I'm not reading carefully enough to comment on the pros and cons (although >I tend to agree with Josh that the mailto URL with variable substitution is >WAY more complex than the rest and should be left for a later day). I agree -- if it is to be done, it should be defined as a new capability for URLs in general. >The only comment I will make is that as a user, the mailto URL with all the >escaped characters is really ugly. I understand that headers aren't meant >to be particularly human readable, but in general I think it's best to keep >things human readable whenever possible. Otherwise, the sense that email is >hard and mysterious just gets more emphasis. I agree that it is ugly, but disagree that it should be changed. It is my hope that if there is a mailer out there that really needs all this extra junk, that they'll consider simplifying if they think it looks ugly. Kind of like there used to be lots of web servers like when the web first took off, until the terminology of www-* and the use of of an empty / to mean "use index.html" simplified things. - ------------------------------------------------------------------------ ..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: 28 Feb 1997 00:02:29 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Forgetting about variables (was: Using URLs) At 12:03 AM -0500 97/2/26, Keith Moore wrote: > I suggest that the List-* protocol limit its scope and say that the > List-* stuff only works with robots that can derive everything they > need to grok a command from: a constant ASCII-only string in the > Subject field, a constant ASCII-only string in the message body, and > the normal submitter information (return address and perhaps name) in > the header From field. Here's the way I figure it. We forget about the issue of variables and, as you say, only support command syntaxes without variables. If the URL working group ever figures out variable inclusion in URLs - great. If not, we've still made a serious improvement to the situation, potentially helping a lot of people. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 00:15:03 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Multiple Addresses, lines too long I wrote: > > Whitespace is illegal in urls. For message header fields, which have > > line-length limits, the client should ignore (strip out) all the spaces, > > tabs and line breaks in an angle bracket enclosed URL. So that: > > > > List-Help: > Subject=help> > > > > Is treated by the client as . At 12:45 AM -0500 97/2/26, Keith Moore replied: > A good idea, but it's almost certainly not compatible with existing > UAs, The MUA I'm using supports URLs broken accross lines exactly as I described. It even properly ignores the whitespace in the example below: which is treated the same as Without the angle brackets, it's treated as mailto:address@server If we provide the angle brackets to properly delimit the begining and end of the URL, clients should not need much effort to read the URL, leaving out the whitespace. > and that's the big reason for using mailto. If enough lists > required long List-foo headers that were likely to be wrapped, it > might argue for using some other syntax. I disagree. I think the MUAs can readily implement the kind of whitespace in URL handling that's in the one I'm using. It's a very minor detail in comparison to the actual mailto URL handling. - -- "If God had meant computers to be easy, She'd have made them all Macs." gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 00:45:35 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Why URLs for our syntax? (was: URLs, List Headers, and VRLs(?)) At 1:08 AM -0500 97/2/26, Keith Moore wrote: > > As I understand it, the use of %-encoding is defined in the extended >mailto: > > draft. It's not yet an rfc, so I wouldn't expect widespread adoption in > > existing MUAs :-) > > True. But if the reason for using mailto: is backward compatibility with > existing UAs, and %XX is necessary, and mailto: doesn't work with existing > UAs, there's a little bit less reason to use mailto. We're not prescribing mailto (although it will probably be the most commonly used protocol in what we're proposing). One very important benefit of using URLs to describe command syntax is that it doesn't restrict us to just using mail based commands. We can access any protocol that can be described in an URL - key among the alternative protocols are web front-ends for mail lists. In the same vein, we get a clear path for supporting future protocols as they are 'URLized'. For me, another key advantage of URLs is that they are a well defined and scalable syntax already in wide use. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 01:07:25 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 7:20 AM -0500 97/2/26, James Berriman wrote: > I believe that much of the excitement about this proposal came out of > Christopher's announcement that Eudora would be supporting the extended > mailto: syntax. I wrote the first draft of the proposal at the end of last year because of the discussion on ListMom-Talk. There was so much talk about the problems with different command syntaxes in use, and user screwups, that I figured somebody had to just put their foot down and say "Hey! Here's a way I think we can alleviate this problem, what do you all think?" rather than just continuing to wish for a solution. Then, because my vacation ended (and thus the bulk of my spare time), I let the proposal slide for a while until discussion heated up again at the begining of Februrary (as per the enhanced mailto support being introduced in many Mac MUAs). Since I entered (intentionally and happily) the ranks of the gainfully unemployed this month, I've had more time to work on my (non job-related) projects like this one. > So we've been generally proceeding on the assumption that support for > extended mailto: will be deployed alongside the list headers. I don't think > backwards compatibility was the main driving force here ;-) Correct. The hope is to produce something so that MUAs can start supporting it, with the hope that through upgrading people will start to have the advantage of (I'm starting to drift off, tired, so excuse my rambling) better tools. There's nothing we could implement which would provide a lot of backwards compatibility. We should, however, continue to try to figure out ways to make it easier for users of older clients. > Eventually, there will be several kinds of client. > > 1. Doesn't support mailto: > 2. Supports basic mailto:, but doesn't understand extended mailto: syntax > 3. Supports extended mailto: > > Oh, I forgot: > > 4. Broken - thinks it understands mailto:, but doesn't ;-) 3.5 Supports List- headers and enhanced mailto > Since the main aim of the proposal is to get future clients to automate the > list management process on behalf of the user, I don't think it's > unreasonable to expect conforming clients to implement the extended mailto: > support alongside the list headers. Absolutely. The proposal depends on both the meta-syntax (URLs, including enhanced mailto) and the transport (the core List- headers). > What needs to be taken into account is > what kind of messages (if any) are likely to be generated by broken / dumb > UAs. Some user testing is in order. Anyone want to head up the testing? - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 01:17:22 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 1:18 PM -0500 97/2/26, Adam C. Engst wrote: > The only comment I will make is that as a user, the mailto URL with all the > escaped characters is really ugly. I understand that headers aren't meant > to be particularly human readable, but in general I think it's best to keep > things human readable whenever possible. Otherwise, the sense that email is > hard and mysterious just gets more emphasis. Yes URLs are not exactly the most human readable of syntaxes. However, they are fast becoming one of the most computer readable identifiers. Because of the ICeTEe extension on my Mac, I can command-click in most of the software I use to launch URLs I encounter. URLs are, for most people who use the net, human _identifiable_ as being URLs. Most people now know that they can copy an URL (or type it in) to their web (and possibly other) clients. They don't have to know the syntax of it, just what it is and where to put it. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 01:24:02 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: URLs, List Headers, and VRLs(?) At 9:16 AM -0500 97/2/26, Keith Moore wrote: > it's just that putting a URL in > a message header, rather than just an email address, might look a little > strange to some long-time email types. So it might help to document > the reasons for doing this. I guess we should document every decision made for the proposal. That's reasonable, especially for something which is being done as a first standard, with the intention of enhanced version(s) being produced. > (It might also be that I'm the only one who thinks it's strange. :) I'm thinking that must be it :-) - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 01:28:43 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Memphis IETF (was: Fast Track Through IETF) At 12:24 AM -0500 97/2/26, Keith Moore wrote: > After talking about this with my co-Director, Harald Alvestrand, I > think it would be a good idea if people could publish an > internet-draft well in advance of the Memphis IETF (April 7-11), and > schedule a 1-hour BOF session there (probably on Wednesday) to discuss > it. It may be difficult for me to get to Memphis for the meeting. Is it an IETF requirement to have such a session in order for a standard to go through? If so, can it proceed with an absent chair? If it really needs to happen with me there, I can try to find a way to make it (maybe just fly in for the day, or such). Perhaps a combined face-face and conference call if there are facilities for a good speaker phone at the session? > To apply for a BOF, you need: > > a) a chairperson I guess that would be me - unless the chair is not supposed to be the person leading the development of the proposal. > b) an acronym Christoper Allen suggested: > IETF-LMH for List Management Headers. Keith Moore suggested: > IETF is redundant for an IETF BOF. I suggest LISTHDRS. That may be okay, although I'm trying to get away from "Headers" being the exclusive focus of our discussions. I think of headers now as one of many transport mechanisms we can use. Maybe LISTCMND, LISTCTRL, or LISTSPEC? > c) a stated purpose and agenda Here's my first run at a working group "statement of purpose": To define a unified, scalable, meta-syntax for specifying client command access to electronic mail lists. The meta-syntax is to describe the highly variant command syntaxes in use by the diverse mail list servers presently in use. By defining such a common meta-syntax, it is expected that client and server application developers will be able to implement standardized interfaces to the non-standard command syntaxes, thus easing the problems experienced by both end users and system administrators. To define the usage and structure of various transport mechanisms for the meta-syntax. The transport mechanisms will require specification in order that software applications may know how to access the meta-syntax. Now, that's more than what the proposed BOF session would cover. I would scale it down to just discussing the use of an URL based syntax (and alternatives if URLs are found to be innapropriate) for the 3 core commands (and asking the question of whether those are the core commands) through message headers (if message headers are the appropriate choice for the first phase of the larger proposal). The tentative title I have for the first Internet-Draft we're working on is: "A Meta-Syntax for Core Mail List Commands and its Transport through Message Headers" As to agenda, review and discuss the Internet-Draft (which should be tabled by that time), determining if there are any notable points of contention that are not addressed by the intent to expand the scope through more detailed and comprehensive syntax and transport mechanisms. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 01:39:30 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Multiple Addresses, lines too long At 9:13 PM -0800 2/27/97, Grant Neufeld wrote: >The MUA I'm using supports URLs broken accross lines exactly as I >described. It even properly ignores the whitespace in the example below: > > .com? > Sub > ject=he lp > > >which is treated the same as > >Without the angle brackets, it's treated as mailto:address@server The above worked for me in the public beta of Eudora/Mac 3.1 - ------------------------------------------------------------------------ ..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: 28 Feb 1997 01:52:55 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Multiple Addresses, lines too long > > > .com? > > Sub > > ject=he lp > > > > >which is treated the same as > > > >Without the angle brackets, it's treated as mailto:address@server > > The above worked for me in the public beta of Eudora/Mac 3.1 I think we're using the same app (Eudora Pro 3.1b23-3.97) - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 02:16:37 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Third Try > If we provide the angle brackets to properly delimit the begining and end > of the URL, clients should not need much effort to read the URL, leaving > out the whitespace. Okay, you need to explicitly state if/when the angle brackets are required. (the latest draft on URL syntax : draft-fielding-url-syntax-03.txt, doesn't require angle brackets, though it does suggest that if angle brackets are used to delimit a URL, that white space within those angle brackets be removed before evaluating the URL) > > and that's the big reason for using mailto. If enough lists > > required long List-foo headers that were likely to be wrapped, it > > might argue for using some other syntax. > > I disagree. I think the MUAs can readily implement the kind of whitespace > in URL handling that's in the one I'm using. It's a very minor detail in > comparison to the actual mailto URL handling. Agreed, but it still might not work with most existing UAs, even those that look for mailto: URLs. Aside: I've tried twice to send a test message to the list with a mailto in a header field, along with a request that people click on it and try to subscribe to a dummy list that way and let me know what happens. On the first try, the list filtered out the List-Subscribe header (because it filters out things it doesn't understand); On the second try, I put the mailto URL in the Subject line; the list saw "subscribe" in there and added me to the list! This is the third try. This time the request is in the Subject field, but doesn't contain the word "subscribe". It is wrapped, with brackets around it, so we can see how well that works. Try clicking on it and sending the resulting mail and see if you get added to the list. (Don't worry, you won't get any mail from the dummy list, though I will acknowledge your request.) If it doesn't work, let me know that also, and how it failed. I'll summarize results to the list. Thanks! Keith ---------------------------------------------------------------------- Date: 28 Feb 1997 02:23:45 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Why URLs for our syntax? (was: URLs, List Headers, and VRLs(?)) > We're not prescribing mailto (although it will probably be the most > commonly used protocol in what we're proposing). > > One very important benefit of using URLs to describe command syntax is that > it doesn't restrict us to just using mail based commands. We can access any > protocol that can be described in an URL - key among the alternative > protocols are web front-ends for mail lists. Sigh. Not that it's not occasionally useful to fill in a form when subscribing to a list, but... I hate to see any email-based service (like a mailing list) saddled with the web in its critical path. It just makes that service a lot more complex, failure prone, and device dependent. (you can send and receive email from a palmtop, but there aren't many palmtop web browsers...) Keith ---------------------------------------------------------------------- Date: 28 Feb 1997 02:34:35 -0500 From: Keith Moore <(suppressed)@cs.utk.edu> Subject: Re: Memphis IETF (was: Fast Track Through IETF) > At 12:24 AM -0500 97/2/26, Keith Moore wrote: > > After talking about this with my co-Director, Harald Alvestrand, I > > think it would be a good idea if people could publish an > > internet-draft well in advance of the Memphis IETF (April 7-11), and > > schedule a 1-hour BOF session there (probably on Wednesday) to discuss > > it. > > It may be difficult for me to get to Memphis for the meeting. Is it an IETF > requirement to have such a session in order for a standard to go through? No, but it will help us determine how best to proceed -- for instance, whether we need a working group or not. > If so, can it proceed with an absent chair? If it really needs to happen > with me there, I can try to find a way to make it (maybe just fly in for > the day, or such). The BOF has to have a chair, but that chair doesn't have to be the chair of the eventual working group, if formed. The chair just needs to be someone willing to write up an agenda, moderate the discussion, circulate a sign-up sheet, arrange for minutes to be taken, and write up a one-paragraph summary . And the WG chair gets invited to the applications area dinner to discuss things with other applications area chairs and directorate members...(sorry, it's not a free meal). In a pinch, the ADs could appoint a surrogate chair. But it would be better if the role were handled by someone who is already active in this discussion. > > b) an acronym > > Christoper Allen suggested: > > IETF-LMH for List Management Headers. > > Keith Moore suggested: > > IETF is redundant for an IETF BOF. I suggest LISTHDRS. > > That may be okay, although I'm trying to get away from "Headers" being the > exclusive focus of our discussions. I think of headers now as one of many > transport mechanisms we can use. > > Maybe LISTCMND, LISTCTRL, or LISTSPEC? It's not worth a lengthy discussion. Pick anything you think is reasonable. (If the ADs hate it, they will change it anyway :) > As to agenda, review and discuss the Internet-Draft (which should be tabled > by that time), determining if there are any notable points of contention > that are not addressed by the intent to expand the scope through more > detailed and comprehensive syntax and transport mechanisms. That's fine. Also keep in mind that the usual purpose of an IETF BOF is to determine whether there's sufficient community interest (and also whether there's sufficient agreement on direction) to proceed. In particular, you want to get a sense of the community as to whether the draft needs a real working group before going to Last Call. Keith ---------------------------------------------------------------------- Date: 28 Feb 1997 08:41:17 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Why URLs for our syntax? At 2:20 AM -0500 97/2/28, Keith Moore wrote: > I hate to see any email-based service (like a mailing list) saddled with > the web in its critical path. It just makes that service a lot more > complex, failure prone, and device dependent. (you can send and receive > email from a palmtop, but there aren't many palmtop web browsers...) I think the Newton has at least one web browser available (if not more), but you're right in that lists which depend on web access will be excluding a number of users. It's a compromise. The core headers approach does not include a complete description of a given server's command syntax - so pointing to a web page can give the user a (hopefully) easy point of access to online help and command interface. It's also a way for lists requiring variables in commands to still provide a 'friendly' front end (as in a web page designed to get those variables from the user). Part of using URLs is that we can make it pretty flexible so that individual lists can determine their own needs for providing command access. In this way, we're hopefully not placing much in the way of limitations in describing list command access. It does though, as you point out, compromise comprehensive support for all possible mail client situations (such as those which don't have other protocol access like http). I think we should include a discussion of that for the list managers and server authors, with a recommendation (but not a requirement) of using mailto based commands for the subscribe and unsubscribe headers, and to consider the needs of their specific audience when choosing the protocol for the Help header. Describing the full mail based command syntax is something for the work subsequent to the first 'core' proposal. When other transport methods are used (MIME, footer, special file, or whatever we decide on), more details should be definable (hopefully including variables). At 2:13 AM -0500 97/2/28, Keith Moore wrote: > > If we provide the angle brackets to properly delimit the begining and end > > of the URL, clients should not need much effort to read the URL, leaving > > out the whitespace. > > Okay, you need to explicitly state if/when the angle brackets are required. I hear you on that. Paragraph 2 in the Syntax:Headers section: "URLs must be enclosed in angle brackets <>." > > I disagree. I think the MUAs can readily implement the kind of whitespace > > in URL handling that's in the one I'm using. It's a very minor detail in > > comparison to the actual mailto URL handling. > > Agreed, but it still might not work with most existing UAs, even > those that look for mailto: URLs. But we can require that it work for those that implement List- header support. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 09:04:26 -0500 From: Grant Neufeld <(suppressed)@ccs.carleton.ca> Subject: Re: Memphis IETF At 2:31 AM -0500 97/2/28, Keith Moore wrote: > The BOF has to have a chair, but that chair doesn't have to be the > chair of the eventual working group, if formed. The chair just needs > to be someone willing to write up an agenda, moderate the discussion, > circulate a sign-up sheet, arrange for minutes to be taken, and > write up a one-paragraph summary . And the WG chair gets invited to the > applications area dinner to discuss things with other applications area > chairs and directorate members...(sorry, it's not a free meal). Okay - we need a volunteer from the list who can take on the responsibility of doing this. Does anyone here want to chair a BOF session on this proposal at the IETF meeting in Memphis > > > b) an acronym ... > It's not worth a lengthy discussion. Pick anything you think is > reasonable. (If the ADs hate it, they will change it anyway :) I like LISTSPEC. - -- gneufeld@ccs.carleton.ca grant@kagi.com http://arpp.carleton.ca/ O- <*> ---------------------------------------------------------------------- Date: 28 Feb 1997 13:06:51 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Memphis IETF (was: Fast Track Through IETF) At 10:26 PM -0800 2/27/97, Grant Neufeld wrote: >It may be difficult for me to get to Memphis for the meeting. Is it an IETF >requirement to have such a session in order for a standard to go through? Technically no -- in fact, you can't put through a standard at an IETF meeting, it must be finalized online. It is primarily to allow for high-bandwidth face-to-face. >If so, can it proceed with an absent chair? If it really needs to happen >with me there, I can try to find a way to make it (maybe just fly in for >the day, or such). Even though technically you don't have to be at an IETF meeting, I do think is is very important. I subbed for the TLS chairman at the last IETF meeting (I'm an editor) and it cause a number of problems that he wasn't there. >Perhaps a combined face-face and conference call if there are facilities >for a good speaker phone at the session? I've not seen a conference call used at an IETF meeting. >> To apply for a BOF, you need: >> >> a) a chairperson > >I guess that would be me - unless the chair is not supposed to be the >person leading the development of the proposal. The chair leads, defines agenda, and is boss on certain types of things -- but normally is not the working group editor (too incestuous). In fact, the chair and editor shouldn't even be from the same company. Of course, all of the above applies to a BOF/WG -- the approach the AD recommended was to do it without a BOF/WG. >That may be okay, although I'm trying to get away from "Headers" being the >exclusive focus of our discussions. I think of headers now as one of many >transport mechanisms we can use. > >Maybe LISTCMND, LISTCTRL, or LISTSPEC? I think LISTHDRS is more obvious, but LISTCTRL is ok. >Here's my first run at a working group "statement of purpose": > > To define a unified, scalable, meta-syntax for specifying client > command access to electronic mail lists. The meta-syntax is to > describe the highly variant command syntaxes in use by the diverse > mail list servers presently in use. > > By defining such a common meta-syntax, it is expected that client > and server application developers will be able to implement > standardized interfaces to the non-standard command syntaxes, thus > easing the problems experienced by both end users and system > administrators. > > To define the usage and structure of various transport mechanisms > for the meta-syntax. > > The transport mechanisms will require specification in order that > software applications may know how to access the meta-syntax. I think there should be something in there that we will as much as possible try to keep things simple, and to take advantage of existing standards. >Now, that's more than what the proposed BOF session would cover. I would >scale it down to just discussing the use of an URL based syntax (and >alternatives if URLs are found to be innapropriate) for the 3 core commands >(and asking the question of whether those are the core commands) through >message headers (if message headers are the appropriate choice for the >first phase of the larger proposal). > >The tentative title I have for the first Internet-Draft we're working on is: > > "A Meta-Syntax for Core Mail List Commands and its Transport through > Message Headers" > >As to agenda, review and discuss the Internet-Draft (which should be tabled >by that time), determining if there are any notable points of contention >that are not addressed by the intent to expand the scope through more >detailed and comprehensive syntax and transport mechanisms. Sounds good. - ------------------------------------------------------------------------ ..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: 28 Feb 1997 13:09:07 -0500 From: Christopher Allen <(suppressed)@consensus.com> Subject: Re: Memphis IETF (was: Fast Track Through IETF) At 10:26 PM -0800 2/27/97, Grant Neufeld wrote: >It may be difficult for me to get to Memphis for the meeting. Is it an IETF >requirement to have such a session in order for a standard to go through? Technically no -- in fact, you can't put through a standard at an IETF meeting, it must be finalized online. It is primarily to allow for high-bandwidth face-to-face. >If so, can it proceed with an absent chair? If it really needs to happen >with me there, I can try to find a way to make it (maybe just fly in for >the day, or such). Even though technically you don't have to be at an IETF meeting, I do think is is very important. I subbed for the TLS chairman at the last IETF meeting (I'm an editor) and it cause a number of problems that he wasn't there. >Perhaps a combined face-face and conference call if there are facilities >for a good speaker phone at the session? I've not seen a conference call used at an IETF meeting. >> To apply for a BOF, you need: >> >> a) a chairperson > >I guess that would be me - unless the chair is not supposed to be the >person leading the development of the proposal. The chair leads, defines agenda, and is boss on certain types of things -- but normally is not the working group editor (too incestuous). In fact, the chair and editor shouldn't even be from the same company. Of course, all of the above applies to a BOF/WG -- the approach the AD recommended was to do it without a BOF/WG. >That may be okay, although I'm trying to get away from "Headers" being the >exclusive focus of our discussions. I think of headers now as one of many >transport mechanisms we can use. > >Maybe LISTCMND, LISTCTRL, or LISTSPEC? I think LISTHDRS is more obvious, but LISTCTRL is ok. >Here's my first run at a working group "statement of purpose": > > To define a unified, scalable, meta-syntax for specifying client > command access to electronic mail lists. The meta-syntax is to > describe the highly variant command syntaxes in use by the diverse > mail list servers presently in use. > > By defining such a common meta-syntax, it is expected that client > and server application developers will be able to implement > standardized interfaces to the non-standard command syntaxes, thus > easing the problems experienced by both end users and system > administrators. > > To define the usage and structure of various transport mechanisms > for the meta-syntax. > > The transport mechanisms will require specification in order that > software applications may know how to access the meta-syntax. I think there should be something in there that we will as much as possible try to keep things simple, and to take advantage of existing standards. >Now, that's more than what the proposed BOF session would cover. I would >scale it down to just discussing the use of an URL based syntax (and >alternatives if URLs are found to be innapropriate) for the 3 core commands >(and asking the question of whether those are the core commands) through >message headers (if message headers are the appropriate choice for the >first phase of the larger proposal). > >The tentative title I have for the first Internet-Draft we're working on is: > > "A Meta-Syntax for Core Mail List Commands and its Transport through > Message Headers" > >As to agenda, review and discuss the Internet-Draft (which should be tabled >by that time), determining if there are any notable points of contention >that are not addressed by the intent to expand the scope through more >detailed and comprehensive syntax and transport mechanisms. Sounds good. - ------------------------------------------------------------------------ ..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: 28 Feb 1997 13:47:30 -0500 From: "Adam C. Engst" <(suppressed)@tidbits.com> Subject: Re: Why URLs for our syntax? >> I hate to see any email-based service (like a mailing list) saddled with >> the web in its critical path. It just makes that service a lot more >> complex, failure prone, and device dependent. (you can send and receive >> email from a palmtop, but there aren't many palmtop web browsers...) > >I think the Newton has at least one web browser available (if not more), >but you're right in that lists which depend on web access will be excluding >a number of users. There's no reason to exclude anything. TidBITS is highly email-based and has been for almost seven years. However, when we moved the list over to our Macs from LISTSERV and put the -on and -off addresses into service, we saw a signficiant reduction in user confusion. Then, when we added a subscription form (which actually just sends a dummy confirmation message that users must return to tidbits-on@tidbits.com) to our home page, subscriptions jumped radically. One of the rules of electronic publishing is that you do everything you can for your readers or potential readers to access your stuff however they wish. 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: 28 Feb 1997 19:17:07 -0500 From: "Roger Fajman" <(suppressed)@CU.NIH.GOV> Subject: Re: Memphis IETF (was: Fast Track Through IETF) > >Perhaps a combined face-face and conference call if there are facilities > >for a good speaker phone at the session? > > I've not seen a conference call used at an IETF meeting. The PIER WG did it in Montreal. It worked, except for the trouble with the phone line and one long distance carrier's major fiber cut. :-( We actually didn't connect until the end of the seesion, but the speaker was able to say his piece. ---------------------------------------------------------------------- End of Digest