List-Header Digest Archive: November 1997

http://www.nisto.com/list-spec/mail/

X-List-Help: <http://www.nisto.com/listspec/mail/>, <mailto:list-header-request@list.nisto.com?Subject=help>
X-List-Unsubscribe: <mailto:list-header-request@list.nisto.com?Subject=unsubscribe>
X-List-Subscribe: <mailto:list-header-request@list.nisto.com?Subject=subscribe>
X-List-Archive: <http://www.nisto.com/listspec/mail/#Digest>
X-List-Post: <mailto:list-header@list.nisto.com>
X-List-Owner: <mailto:listmom@list.nisto.com?Subject=List-Header%20List>

Contents:

-> multiple email addresses
     by "John Buckman" <(suppressed)@shelby.com>
-> Re: multiple email addresses
     by "Kent S. Larsen II" <(suppressed)@panix.com>
-> Re: multiple email addresses
     by "John Buckman" <(suppressed)@shelby.com>
-> Command confirmation message format
     by Grant Neufeld <(suppressed)@achilles.net>
-> List-Software field (was: complaints about headers)
     by Grant Neufeld <(suppressed)@achilles.net>
-> structured header fields (was: required changes to the list-header internet draft)
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: structured header fields (was: required changes to the  list-header internet draft)
     by Marc Horowitz <(suppressed)@cygnus.com>
-> Re: Command confirmation message format
     by James Berriman <(suppressed)@frutiger.staffs.ac.uk>
-> Re: structured header fields
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: Command confirmation message format
     by Grant Neufeld <(suppressed)@achilles.net>
-> List Info MIME Part
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: List Info MIME Part
     by Rob Chandhok <(suppressed)@within.com>
-> Re: structured header fields
     by Marc Horowitz <(suppressed)@cygnus.com>
-> Re: structured header fields
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: structured header fields
     by Marc Horowitz <(suppressed)@cygnus.com>
-> Re: structured header fields
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: structured header fields
     by Marc Horowitz <(suppressed)@cygnus.com>
-> Re: structured header fields
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: Command confirmation message format
     by Grant Neufeld <(suppressed)@achilles.net>
-> Re: structured header fields
     by Gerald Oskoboiny <(suppressed)@impressive.net>
-> Re: structured header fields
     by Grant Neufeld <(suppressed)@achilles.net>
-> (fwd) I-D ACTION:draft-hoffman-mailto-url-03.txt
     by Grant Neufeld <(suppressed)@achilles.net>
-> Poll: software supporting the list header fields
     by Grant Neufeld <(suppressed)@achilles.net>
-> "List headers" and nested lists
     by Jacob Palme <(suppressed)@dsv.su.se>
-> account "probe" messages
     by Grant Neufeld <(suppressed)@achilles.net>


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

Date: 2 Nov 1997 17:47:16 -0500
From: "John Buckman" <(suppressed)@shelby.com>
Subject: multiple email addresses

In the draft standard document, it is written:

> If the user has multiple email addresses supported by the mail client,
> the client application should prompt the user for which address to use
> when subscribing or performing some other action where the address to
> use cannot be specifically determined.  When unsubscribing or such, the
> address that is subscribed should be used, unless that is not known by
> the application and cannot be determined from the message headers.

This is an interesting point about subscribers with multiple email
addresses -- it is very common for people to have multiple email
addresses, and not know which email address they are subscribed with.
Unless the mail application has some way of keeping track, this problem
will continue, and poor list admins will continue to respond to unsub
requests with the question "do you happen to use any other email
addresses?".

In our implementation of the standard, I put the subscribee's email 
address in the unsubscribe command URL, like so:

  List-Unsubscribe:
<mailto:unsubscribe-list1@lyris.net?subject=[bob@shelby.com]>

The unsubscribe command-address then reads the [email] address when it
receives the mail, and unsubs that address from the list. If the [email]
address is different from the From: address of the request, an
unsub-confirmation message is generated. In this way, the unsubscribe
command is "failsafe" -- it always works.

Perhaps a more standard way of doing this would make sense. Here's one
possibility, using a "from=" field to make the unsubscribe command come
From: a different address:

  List-Unsubscribe: <mailto:unsubscribe-list1@lyris.net?from=bob@shelby.com>

Anyway, this seemed like an interesting idea, so I thought I'd bring it up
this list.

John

John Buckman <(suppressed)@shelby.com>
Shelby Group Ltd. http://www.shelby.com
Developers of Lyris Email List Server


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

Date: 2 Nov 1997 19:18:42 -0500
From: "Kent S. Larsen II" <(suppressed)@panix.com>
Subject: Re: multiple email addresses

At 2:45 PM -0800 11/2/97, John Buckman wrote:
>
>In our implementation of the standard, I put the subscribee's email
>address in the unsubscribe command URL, like so:
>
>  List-Unsubscribe:
><mailto:unsubscribe-list1@lyris.net?subject=[bob@shelby.com]>
>
>The unsubscribe command-address then reads the [email] address when it
>receives the mail, and unsubs that address from the list. If the [email]
>address is different from the From: address of the request, an
>unsub-confirmation message is generated. In this way, the unsubscribe
>command is "failsafe" -- it always works.
>
>Perhaps a more standard way of doing this would make sense. Here's one
>possibility, using a "from=" field to make the unsubscribe command come
>From: a different address:
>
>  List-Unsubscribe: <mailto:unsubscribe-list1@lyris.net?from=bob@shelby.com>
>
>Anyway, this seemed like an interesting idea, so I thought I'd bring it up
>this list.
>
>John
>
>John Buckman <(suppressed)@shelby.com>
>Shelby Group Ltd. http://www.shelby.com
>Developers of Lyris Email List Server


I think we need to review this carefully. Wouldn't it be possible for the
subscriber to forward the message with the header (something we have talked
about, I think) and in doing so end up getting unsubscribed by someone else?

I realize that headers are not always passed in forwarded messages, but
since the mailto standard works regardless of whether it is in a header or
not, it seems possible.

Kent


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

Date: 2 Nov 1997 20:38:28 -0500
From: "John Buckman" <(suppressed)@shelby.com>
Subject: Re: multiple email addresses

> I think we need to review this carefully. Wouldn't it be possible for the
> subscriber to forward the message with the header (something we have talked
> about, I think) and in doing so end up getting unsubscribed by someone else?

Yes, you're right, if we did the "from=" technique, that could be a side 
effect. With the technique I used, the From: is not changed, but the 
recipient's address is given in the subject line. The list server then 
compares the From: line with the address on the subject line, and if they 
are different, issues a unsubscribe confirmation message.  

That way, if the message was forwarded around to other people, and 
someone unsubbed from a forwarded copy, the list server sees that the 
From: and unsub addresses are different, issues a unsub confirmation 
message which keeps the person from being inadvertedly unsubbed.

Perhaps this issue should be left as a implementation-specific decision. 
In my case, I put the unsubbee in the subject line like so:

  <mailto:unsubscribe-list1@lyris.net?subject=[bob@shelby.com]>

the following command would work equally well, and perhaps is clearer:

  <mailto:lyris@lyris.net?subject=unsub%20list1%20bob@shelby.com>

and perhaps this last alternative is clearer still:

  <mailto:list1-request@lyris.net?subject=unsub%20bob@shelby.com>

All these suffer from the dread "forwarding might cause incorrect unsub"
problem that you point out.  

However, in the draft list-header standard, it is noted that client
implementations should not take immediate action, but instead should
show the action about to happen, and ask for confirmation. Pegasus mail
does this, and the unsubbee's email address is displayed in the 
confirmation message.  

So, one would hope that the wrong unsubscriber would notice that their
email address is not in the subject line, but that someone else's is, 
and not send the same unsubscribe command.

A better solution: if this problem were discussed in the draft standard,
we could ask client implementations to post a warning if the email
address being unsubbed is not the person's own email address. That is one
concrete advantage to discussing this problem now, before the standard is
set.  The tricky thing  here is defining a way in which the email client
can determine, from reading the List-Header, which email address is being
requested to unsub.

John

John Buckman <(suppressed)@shelby.com>
Shelby Group Ltd. http://www.shelby.com
Developers of Lyris Email List Server


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

Date: 15 Nov 1997 16:33:01 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Command confirmation message format

As command confirmations become more and more common for mailing lists
(thank you :-( spammers and mail-bombers), it would be useful to define
some standard 'attributes' for confirmation messages to help in automating
them.

To get the discussion started, I offer the following new header field:

Command-Confirm:
<mailto:list-request@foo.bar?Subject=Confirm%20Subscribe%20X123&Body=OK>

It serves 2 functions. The first is to identify that the message is for
confirming a command. The second is to provide the syntax for performing
the confirmation.

The body can then be whatever it is now for those clients not supporting
the Command-Confirm field.


I'm not entirely happy with this solution. There needs to be a way to
explain to the user the nature of the command being confirmed ("Confirm
subscription to 'list@foo.bar'?"). One way around that is to have the MUA
track what commands the user has sent out and automatically perform
confirms on the commands it knows about, only bringing up confirm requests
that it doesn't recognize.

Perhaps what is needed is a standard confirmation response format.

Given the need to: "Confirm subscription to list@foo.bar using code X123",
a reply would be formatted as:

To: list-request@foo.bar
Subject: Confirm Subscription X123
Body: OK

Then we could make the confirm header field like:

Command-Confirm: SUB; list@foo.bar; X123


Okay, have at it!

[note that I've dropped the Reply-To: field from this list's header. "No
applause necessary, just throw money." ;-) ]

- --
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>
A phrase I saw used to describe a massive quantity:
  "more common than Internet Explorer security bugs"


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

Date: 17 Nov 1997 00:40:00 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: List-Software field (was: complaints about headers)

At 6:33 PM -0700 1997/10/21, Will Mayall wrote:
>The end users generally will gain little from the List-Software header,
>but it can be useful when tracking down server issues.
>
>We include the version number in the header. This can help us and the
>list administrator when tracking down problems.

At 10:41 PM -0700 1997/10/26, Joshua D. Baer wrote:
>I wouldn't call it useless. I think there is some value to the user (I have
>found myself looking for it to find out what software a list is running)
>and other non-standard headers already in use that it could standardize
>(X-ListProcessor, X-Listserver, etc.).

I see your points. Now someone should take up the "List-Software" header
field and prepare an internet-draft to formalize it. I don't want to make
it part of the list-header spec because it isn't about describing commands
and will add controversy to the draft.

I suggest that it be described along the lines of:

  List-Software: <software name>/<version> [ \<url\>]

I reluctantly include the url because people will want to put it in,
regardless.

An alternate, perhaps more meaningful field might be:

  List-Server: <software name>/<version>
      \<<list command address>@<server.domain.name>\>

Which might be something like:

  List-Server: FooLister/0.0.0 <foo-me@list.bar>

- --
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>
Computer Nerds Full Employment Act: MS Windows and IS Departments


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

Date: 17 Nov 1997 02:04:34 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: structured header fields (was: required changes to the list-header
internet draft)

Talking about defining the list header fields as structured:

At 1:44 PM -0700 1997/9/25, Keith Moore wrote:
>> Clear definition as a "structured header field". "That permits free
>> insertion of linear-white-space between tokens."
>
>It also permits free insertion of comments between tokens.

That complicates matters. Is there a way to specify that there can be the
"free insertion of linear-white-space between tokens" without having that
whitespace include comments? I'm concerned the clients will choke on header
fields like:

  List-Help: <mailto:list-requests (that's the command address)@
      foo.bar (that's the server) ?Body=help (that's the help command) >

Although, we should probably specify that MUAs should treat comments as
whitespace, I also want to discourage their use in list software.

- --
"Have you ever retired a human by mistake?"
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 17 Nov 1997 12:43:49 -0700
From: Marc Horowitz <(suppressed)@cygnus.com>
Subject: Re: structured header fields (was: required changes to the 
list-header internet draft)

Grant Neufeld <(suppressed)@achilles.net> writes:

>> That complicates matters. Is there a way to specify that there can be the
>> "free insertion of linear-white-space between tokens" without having that
>> whitespace include comments? I'm concerned the clients will choke on header
>> fields like:
>> 
>>   List-Help: <mailto:list-requests (that's the command address)@
>>       foo.bar (that's the server) ?Body=help (that's the help command) >
>> 
>> Although, we should probably specify that MUAs should treat comments as
>> whitespace, I also want to discourage their use in list software.

I can't find the message of Keith's to which this was a reply, but
here goes.

It's not clear to me that the url part of the command should have
syntactic structure.  In fact, it's clear they shouldn't have any as
far as the list-header document is concerned.  Consider the case of an
http url: I'm unaware of any standard which allows comments to be
inserted.  And we don't want to rule out any future url types which
may exist in the future.  Of course, this should be allowed, even if
it is a bit verbose:

List-Help: (this represents the mail command to get list help)
	<mailto:list-request@example.com?body=help>,
	(this represents the web page with list help)
	<http://www.example.com/list-help.html>

If we do decide that the commands have structure, comments can be
discouraged (on readability and header size grounds, at least), but
probably not disallowed.  These are intended to be program input, and
any MUA will already have comment-removal code in it already, so it
shouldn't be hard to make it work, in any case.

		Marc

>> "Have you ever retired a human by mistake?"

No, but I've wanted to :-)


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

Date: 17 Nov 1997 15:42:28 -0700
From: James Berriman <(suppressed)@frutiger.staffs.ac.uk>
Subject: Re: Command confirmation message format

At 23:33 15/11/97, Grant Neufeld wrote:
>As command confirmations become more and more common for mailing lists
>(thank you :-( spammers and mail-bombers), it would be useful to define
>some standard 'attributes' for confirmation messages to help in automating
>them.

Is this really necessary?

In most cases you simply reply to the self-explanatory confirmation message
and the MLM does all the work for you.

Adding a new header may well complicate the issue without making life any
easier for the end-user.

Playing Devil's advocate here ;-)

( :-])  James


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

Date: 17 Nov 1997 17:19:05 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: structured header fields

At 12:41 PM -0700 1997/11/17, Marc Horowitz wrote:
>It's not clear to me that the url part of the command should have
>syntactic structure.  In fact, it's clear they shouldn't have any as
>far as the list-header document is concerned.

I agree. What I want is to define the structure so that the following is
valid:

  List-Help: <http://foo.bar/some/really/long/url/that/
      needs/to/be/wrapped/onto/multiple/lines>

and gets interpreted as a single line with no spaces:
<http://foo.bar/some/really/long/url/that/needs/to/be/wrapped/onto/multiple/line
s>

>Of course, this should be allowed, even if
>it is a bit verbose:
>
>List-Help: (this represents the mail command to get list help)
>	<mailto:list-request@example.com?body=help>,
>	(this represents the web page with list help)
>	<http://www.example.com/list-help.html>

I agree. I'll try to note that in -02 of the draft. I guess we need to
specify that the entire <url> chunk is one token that, while it make
contain whitespace characters which will be removed by the processor, it
cannot contain comments. The header fields may contain comments, though.

- --
Tool-wielding ape online
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 17 Nov 1997 17:19:18 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: Command confirmation message format

At 3:41 PM -0700 1997/11/17, James Berriman wrote:
>At 23:33 15/11/97, Grant Neufeld wrote:
>>As command confirmations become more and more common for mailing lists
>>(thank you :-( spammers and mail-bombers), it would be useful to define
>>some standard 'attributes' for confirmation messages to help in automating
>>them.
>
>Is this really necessary?
>
>In most cases you simply reply to the self-explanatory confirmation message
>and the MLM does all the work for you.

But wouldn't it be nice if you never had to see the confirmation message or
even be aware that it occurred?

With a standard confirmation identifier like I proposed, email clients can
keep track of commands issued by the user and automatically process
confirmations for those commands. Any confirmation that is not recognized
is still passed on to the user (although it can be specially presented
given the extra information the confirmation header provides).

>Adding a new header may well complicate the issue without making life any
>easier for the end-user.

How does it complicate things (other than servers need to add it)? It
doesn't in any way affect the message subject or body.

- --
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>
"The truth is a variable." - the Washington Rules


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

Date: 17 Nov 1997 17:19:31 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: List Info MIME Part

Earlier this year, we talked about the possibility of using a MIME part to
convey the information about a mailing list. I'd like to get the discussion
of this going in earnest now.

I see a couple of ways of producing the content. One would use label-based
identifiers as in:

  List-Command-Address: list-requests@foo.bar
  List-Name: The Example Mailing List
  List-Address: list@foo.bar
  List-ID: <unique identifier for list - another point of discussion>
...

Another would be to define a SGML DTD for the list info block:

<LIST>
<ID>UniqueIDForExampleList</ID>
<NAME>The Example Mailing List</NAME>
<INFO>This is an example mailing list for illustrating how
  to describe a list and its features in a structured form.</INFO>
<COMMANDADDRESS>list-request@foo.bar</COMMANDADDRESS>
<COMMANDS>
  <SUBSCRIBE TYPE=body>subscribe &userfirstname; &userlastname;</SUBSCRIBE>
  <UNSUBSCRIBE TYPE=address>list-off@foo.bar</UNSUBSCRIBE>
  <HELP TYPE=url>http://www.foo.bar/list/</HELP>
  <HELP TYPE=subject>help</HELP>
</COMMANDS>
</LIST>

Where the TYPE attribute determines the use of the content of the command
element (body means put command in body of message to COMMANDADDRESS;
address means send empty message to address; url means access the url...).
It might make more sense to instead define a COMMAND element with an ACTION
attribute as in:
  <COMMAND ACTION="subscribe"
TYPE=url>mailto:list-request@foo.bar?Body=subscribe</COMMAND>

Personally, I lean toward a SGML format since it's more readily extensible.


We also need a type for the mime part. Someone more knowledgeable than me
can make a valid suggestion (maybe something like text/list-info).

- --
"Eat people, not animals"
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 17 Nov 1997 21:00:02 -0700
From: Rob Chandhok <(suppressed)@within.com>
Subject: Re: List Info MIME Part

At 4:03 PM -0700 11/17/97, Grant Neufeld wrote:
>Personally, I lean toward a SGML format since it's more readily extensible.
>
>
>We also need a type for the mime part. Someone more knowledgeable than me
>can make a valid suggestion (maybe something like text/list-info).

Hmm.  I lean towards the "label based identifiers", or as I would refer to
it: the stuff that looks like headers that most mail UA's know how to parse
already.  That's why URLs work so nicely for the List-Subscribe: headers -
it's something that is already well defined.

V-Cards already use this kind of syntax.  I think SGML would be overkill.

The other nice part about the header-like format is that you can just pull
the headers that we've already agreed upon into the mime part!

Something like text/x.list-info would be a good start for the type.

Rob


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

Date: 18 Nov 1997 18:57:51 -0700
From: Marc Horowitz <(suppressed)@cygnus.com>
Subject: Re: structured header fields

Grant Neufeld <(suppressed)@achilles.net> writes:

>> I agree. What I want is to define the structure so that the following is
valid:
>> 
>>   List-Help: <http://foo.bar/some/really/long/url/that/
>>       needs/to/be/wrapped/onto/multiple/lines>
>> 
>> and gets interpreted as a single line with no spaces:
>>
<http://foo.bar/some/really/long/url/that/needs/to/be/wrapped/onto/multiple/lines>

Why do you want to do this?  I'm wary of playing around with a URL
like this.  Practically speaking, do you really expect to see many
80-character list-* url's?

		Marc


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

Date: 18 Nov 1997 19:31:02 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: structured header fields

At 6:55 PM -0700 1997/11/18, Marc Horowitz wrote:
>>>   List-Help: <http://foo.bar/some/really/long/url/that/
>>>       needs/to/be/wrapped/onto/multiple/lines>
>>>
>>> and gets interpreted as a single line with no spaces:
>>>
>>><http://foo.bar/some/really/long/url/that/needs/to/be/wrapped/onto/multiple/line
>>>s>
>
>Why do you want to do this?  I'm wary of playing around with a URL
>like this.  Practically speaking, do you really expect to see many
>80-character list-* url's?

List-Unsubscribe:
<mailto:long-named-list-request@someserver.witha.reallylongname.bar?Subject=unsu
bscribe>

Consider, also, what happens when some of the command characters need %
encoding (3 characters for the price of 1).

Does it really harm anything to specify that long urls may be broken up
with whitespace (CR LF tab space)? The rule I want is that any whitespace
within the <> is to be ignored (removed) by the client application. Of
course the URLs should be unbroken if possible, but that isn't always
possible.

- --
"Never eat more than you can lift." - Miss Piggy
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 18 Nov 1997 20:22:17 -0700
From: Marc Horowitz <(suppressed)@cygnus.com>
Subject: Re: structured header fields

Grant Neufeld <(suppressed)@achilles.net> writes:

>> List-Unsubscribe:
>>
<mailto:long-named-list-request@someserver.witha.reallylongname.bar?Subject=unsubscribe>

I'm talking about *real* instances.  I can make stuff up, too.  In my
experience, mail admins keep this sort of stuff short because
otherwise it's inconvenient for users.

>> Consider, also, what happens when some of the command characters need %
>> encoding (3 characters for the price of 1).
>> 
>> Does it really harm anything to specify that long urls may be broken up
>> with whitespace (CR LF tab space)? The rule I want is that any whitespace
>> within the <> is to be ignored (removed) by the client application. Of
>> course the URLs should be unbroken if possible, but that isn't always
>> possible.

Well, these headers will be be hidden from the user once
implementations happen, right?  So what does it matter if it's long?

These whitespace rules are different than those from other headers and
even from other places in the same header.  This seems like a good
place for implementors to get confused.

I'm having a hard time thinking of a justification for adding
complexity to a header which is intended for programmatic use where
that complexity is essentially for humans' benefit.

		Marc


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

Date: 18 Nov 1997 20:44:08 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: structured header fields

At 8:20 PM -0700 1997/11/18, Marc Horowitz wrote:
>Well, these headers will be be hidden from the user once
>implementations happen, right?  So what does it matter if it's long?

What about gateways that break lines that extend beyond 80 chars (although,
these are hopefully going away).

I do see your points (I think). Perhaps we need to make it a requirement
that no whitespace be put between the <> for the URL, but that client
software be 'clever' about handling munged URLs.

Does that make sense?

- --
"All technology should be assumed guilty until proven innocent"-David Brower
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 19 Nov 1997 12:05:48 -0700
From: Marc Horowitz <(suppressed)@cygnus.com>
Subject: Re: structured header fields

Grant Neufeld <(suppressed)@achilles.net> writes:

>> At 8:20 PM -0700 1997/11/18, Marc Horowitz wrote:
>> >Well, these headers will be be hidden from the user once
>> >implementations happen, right?  So what does it matter if it's long?
>> 
>> What about gateways that break lines that extend beyond 80 chars (although,
>> these are hopefully going away).

Unless you *require* that MUA's break urls (which I think is an even
worse idea), this won't help.

>> I do see your points (I think). Perhaps we need to make it a requirement
>> that no whitespace be put between the <> for the URL, but that client
>> software be 'clever' about handling munged URLs.
>> 
>> Does that make sense?

It's not clear what it means to specify in a standard that software be
"clever" :-) The rfc1122 Robustness Principle would certainly support
an implementation which accepted technically invalid input and made it
work, as long as it didn't go too far with trying to use that invalid
input.  I could certainly live with "urls MUST NOT be split", but a
note that clients MAY remove whitespace if they happen to find some in
the middle of a URL.  This makes the simple implementation conformant
without forbidding the "clever" one.

		Marc


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

Date: 19 Nov 1997 12:23:15 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: structured header fields

At 12:03 PM -0700 1997/11/19, Marc Horowitz wrote:
>I could certainly live with "urls MUST NOT be split", but a
>note that clients MAY remove whitespace if they happen to find some in
>the middle of a URL.  This makes the simple implementation conformant
>without forbidding the "clever" one.

Unless I hear otherwise in the near future, I'll consider this issue to be
resolved and will try to update the draft accordingly.

Thanks for your input!

- --
"Thanks for the nose-news, neighbor!" - Ned Flanders
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 19 Nov 1997 15:52:56 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: Command confirmation message format

Another issue comes to mind with automating command confirmations.

In some cases, the list manager will want the list confirmation to also
serve as a formalization of agreement of some sort.

As an example, they might want to have the user read a disclaimer and
limitation of liability statement and then confirm their agreement.

With that in mind, an additional parameter for the Command-Confirm header
field is needed. I suggest "User-Must-Read".

  Command-Confirm: SUB; list@foo.bar; "I Agree X123"; User-Must-Read

The MUA could then provide some sort of custom display for the confirmation
message before prompting the user to confirm or dismiss it.

- --
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>
"Teenagers can't sing the blues. Adults sing the blues. Blues adulthood
 means old enough to get the electric chair if you shoot a man in Memphis."


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

Date: 19 Nov 1997 17:21:25 -0700
From: Gerald Oskoboiny <(suppressed)@impressive.net>
Subject: Re: structured header fields

On Mon, 17 Nov 1997, Grant Neufeld wrote:

> What I want is to define the structure so that the following is valid:
> 
>   List-Help: <http://foo.bar/some/really/long/url/that/
>       needs/to/be/wrapped/onto/multiple/lines>
> 
> and gets interpreted as a single line with no spaces:
>
<http://foo.bar/some/really/long/url/that/needs/to/be/wrapped/onto/multiple/lines>

This has been specified elsewhere, in RFC 1738:

    http://ds.internic.net/rfc/rfc1738.txt

It recommends using <URL: ... > wrappers, and ignoring whitespace
when extracting the URL.

As far as I know this hasn't yet been superceded by other work.

Gerald

Berners-Lee, Masinter & McCahill                               [Page 21]

RFC 1738            Uniform Resource Locators (URL)        December 1994


APPENDIX: Recommendations for URLs in Context

   URIs, including URLs, are intended to be transmitted through
   protocols which provide a context for their interpretation.

   In some cases, it will be necessary to distinguish URLs from other
   possible data structures in a syntactic structure. In this case, is
   recommended that URLs be preceeded with a prefix consisting of the
   characters "URL:". For example, this prefix may be used to
   distinguish URLs from other kinds of URIs.

   In addition, there are many occasions when URLs are included in other
   kinds of text; examples include electronic mail, USENET news
   messages, or printed on paper. In such cases, it is convenient to
   have a separate syntactic wrapper that delimits the URL and separates
   it from the rest of the text, and in particular from punctuation
   marks that might be mistaken for part of the URL. For this purpose,
   is recommended that angle brackets ("<" and ">"), along with the
   prefix "URL:", be used to delimit the boundaries of the URL.  This
   wrapper does not form part of the URL and should not be used in
   contexts in which delimiters are already specified.

   In the case where a fragment/anchor identifier is associated with a
   URL (following a "#"), the identifier would be placed within the
   brackets as well.

   In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
   need to be added to break long URLs across lines.  The whitespace
   should be ignored when extracting the URL.

   No whitespace should be introduced after a hyphen ("-") character.
   Because some typesetters and printers may (erroneously) introduce a
   hyphen at the end of line when breaking a line, the interpreter of a
   URL containing a line break immediately after a hyphen should ignore
   all unencoded whitespace around the line break, and should be aware
   that the hyphen may or may not actually be part of the URL.

   Examples:

      Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
      type=d> but you can probably pick it up from <URL:ftp://ds.in
      ternic.net/rfc>.  Note the warning in <URL:http://ds.internic.
      net/instructions/overview.html#WARNING>.


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

Date: 19 Nov 1997 17:51:31 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Re: structured header fields

At 5:19 PM -0700 1997/11/19, Gerald Oskoboiny wrote:
>This has been specified elsewhere, in RFC 1738:
...
>It recommends using <URL: ... > wrappers, and ignoring whitespace
>when extracting the URL.

That's pretty much what I was looking for.

I guess we should add support for the URL: token as RFC 1738 specifies it.
I'd like to specify that it is an optional token, and that MUAs should be
able to handle it properly.

Anyone see any problems with that?

- --
"All technology should be assumed guilty until proven innocent"-David Brower
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 20 Nov 1997 12:14:16 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: (fwd) I-D ACTION:draft-hoffman-mailto-url-03.txt

Update of the enhanced mailto URL draft:

- --- begin forwarded text

To: IETF-Announce@ns.ietf.org
From: Internet-Drafts@ns.ietf.org
Reply-to: Internet-Drafts@ns.ietf.org
Subject: I-D ACTION:draft-hoffman-mailto-url-03.txt
Date: Thu, 20 Nov 1997 10:09:25 -0500

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


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

	Title		: The mailto URL scheme
	Author(s)	: L. Masinter, P. Hoffman, J. Zawinski
	Filename	: draft-hoffman-mailto-url-03.txt
	Pages		: 4
	Date		: 19-Nov-97

This document defines the format of Uniform Resource Locators (URL) for
designating electronic mail addresses. It is one of a suite of documents
which replace RFC 1738, ''Uniform Resource Locators'', and RFC 1808,
''Relative Uniform Resource Locators''. The syntax of ''mailto'' URLs from RFC
1738 is extended to allow creation of more RFC 822 messages by allowing the
URL to express additional header and body fields.


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

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za

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

	Pacific Rim: munnari.oz.au

	US East Coast: ds.internic.net

	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	mailserv@ds.internic.net.  In the body type:
	"FILE /internet-drafts/draft-hoffman-mailto-url-03.txt".

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


- --- end forwarded text

- --
grant@acm.org  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 22 Nov 1997 01:05:34 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: Poll: software supporting the list header fields

I think my list of software supporting the list header fields is getting a
fair bit behind. I would appreciate it if the authors present here could
send me the following info:

Type of software: email client / list server
Program Name:
Company or Developer:
Support for List- Headers as of version:
Which Fields Supported: List-Help, List-Subscribe, List-Unsubscribe,
List-Post, List-Owner, List-Archive.
Description of the support: (E.g., interface details such as: command menu,
buttons,...)

I'll try to update the list at
<http://arpp.carleton.ca/listspec/#APPLICATION-SUPPORT> some time next week.

Thanks.

- --
"All technology should be assumed guilty until proven innocent"-David Brower
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>


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

Date: 23 Nov 1997 18:43:34 -0700
From: Jacob Palme <(suppressed)@dsv.su.se>
Subject: "List headers" and nested lists

Some mailing list are nested, usually in a tree structure like this:

top of the list:    +--------A--------+
                    !        !        !
sublists:       +---B---+    C---+   +D--+
                !   !   !    !   !   !   !
members:        E   F   G    H   I   J   K

But more levels than two can sometimes occur.

When a user receives a message from a mailing list,
List-Subscribe and List-Unsubscribe should refer to the nearest sublist
to the user, while List-Submit should refer to the top of the nested
tree. The users E, F and G in the example above need to know that it is
B they should unsubscribe from, not A. But they need also to know that
new submissions should be sent to A, not to B, otherwise all readers
will not be reached.

This mean that a mailing list expander should not add List-Submit
to a message which already has this header, but should replace
"List-Subscribe" or "List-Unsubscribe" for messages which already
have them, or keep both the old and the new "List-Subscribe"
and "List-Unsubscribe" if they are given in a specific order.

Does the List headers proposal specify this? If not, it should be
modified to do it!


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


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

Date: 27 Nov 1997 11:39:59 -0700
From: Grant Neufeld <(suppressed)@achilles.net>
Subject: account "probe" messages

Another message that would be useful to standardize a format for is the
"probe" messages employed by some lists to validate their subscribers
accounts.

Basically, these messages are meant to be immediately deleted (or bounced,
if the account is invalid). They contain specific information about the
individual account being "probed" so that if there is a bounce, the list
can identify the problem account (difficult to do with regular grouped list
mailings).

I think a simple header field that just specifies that this is a message to
be deleted upon receipt of the end user should suffice. It's very important
that MTAs ignore this field - it is only to be handled by the end client
MUA.

So, I propose:

  Message-Probe: DELETE

(better suggestions are more than welcome). I used just a plain Message
prefix because probes might have use beyond lists. You're welcome to point
out why I'm wrong.

One security issue I can think of is that it could possibly be used by
spammers to "clean" their lists. However, this would require that they
perform individual (instead of group) mailings, and that they use an
operational and traceable source MTA in order to receive the bounces.

- --
grant@achilles.net  grant@kagi.com  http://arpp.carleton.ca/  O-  <*>
"If at first you don't succeed, kill all the evidence that you ever tried."


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

End of Digest