Subject: Re: Origins of message modification
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Charles Lindsey <[email-masked]>
Date: Thu, 30 Dec 2004 21:27:17 -0500
List-Id: <ietf-822.imc.org>

> Didn't address fields need to be modified by email gateways in the 
> eighties?

yes.  there's a reason sendmail has the extensive address rewriting 
facilities that it does - it was written at a time when it was useful 
to try to cope with lots of relatively simple messaging systems each of 
which had its own addressing conventions.  but I was talking about 
ARPAnet/Internet mail architecture, not about gateways between mail 
systems.

gateways have to rewrite things regardless.  we just don't see this as 
much today because Internet mail has been selected (in the Darwanian 
sense) over other mail systems.

Date: Fri, 31 Dec 2004 02:42:04 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Origins of message modification
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

Tony Finch writes:
> On Thu, 30 Dec 2004, Arnt Gulbrandsen wrote:
>>  Didn't address fields need to be modified by email gateways in the 
>>  eighties?
>
> Gateways aren't the problem we're discussing, which is that Internet 
> email by itself uses the message header for both user-level and 
> transport-level information, which implies a lot of fiddling with the 
> message data as it is transported.

My bad. Please accept my apologies for not wiping out the references 
field when I changed the subject field.

Arnt

Date: Thu, 30 Dec 2004 23:38:55 +0000
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Origins of message modification
Sender: [email-masked]

On Thu, 30 Dec 2004, Arnt Gulbrandsen wrote:
>
> Didn't address fields need to be modified by email gateways in the eighties?

Gateways aren't the problem we're discussing, which is that Internet email
by itself uses the message header for both user-level and transport-level
information, which implies a lot of fiddling with the message data as it
is transported.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SELSEY BILL TO LYME REGIS: SOUTHWEST VEERING NORTHWEST 4 OR 5, INCREASING 6
FOR A TIME. RAIN OR DRIZZLE. MODERATE OCCASIONALLY POOR. SLIGHT OR MODERATE.

Date: Thu, 30 Dec 2004 21:48:25 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Origins of message modification
Cc: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>
Sender: [email-masked]

Keith Moore writes:
> as I understand it, ARPAnet mail grew out of a practice of sending 
> messages by using FTP to append to a file on the recipient's 
> computer.  the entire message (both header and body) was created by 
> the author, there were no intermediaries that were aware enough of 
> the message content to be able to modify the header.  SMTP came along 
> and added Received fields and Return-Path.  whether the original 
> practice was "intention" or just the way it happened to work is not 
> something I can comment on, since I wasn't there at the time.  but I 
> have heard complaints since at least the mid-1980s that there was too 
> little separation between envelope and transport in Internet mail , 
> even though Received and Return-Path were the only layering 
> violations in the design.

Didn't address fields need to be modified by email gateways in the 
eighties? I only got internet access in 1989, so this is hearsay, but 
wasn't there separate worlds called, uh, csnet, decnet, janet and 
arpanet? (I think those were the names I saw in my first sendmail.cf.) 
Such address rewriting would be a major layering violation.

Arnt

PS:

> for various reasons, the situation is much worse now than it was then.

Isn't it always ;)

Date: Mon, 27 Dec 2004 12:10:52 +0100
To: Hari Krishna Pammi pammi <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: MHTML: cid href to message/rfc822 in multipart/related
Cc: [email-masked]
Sender: [email-masked]

At 16.45 +0530 04-12-23, Hari Krishna Pammi pammi wrote:
>In any case, my requirement is that when I click on the link (  a
>href= "cid:<content-id of a message/rfc822>") I want the attachment
>mail message with the same content-id to be show as another email
>message itself in the MUA itself.

That sounds reasonable, but getting the major email vendors
to do what you think they should do is not so easy.
Sometimes, if you succeed in persuading one major vendor,
like Microsoft or Mozilla, other vendors will follow up. In
the case of Mozilla mail, you will have to implement the
added functionality and get it accepted as an augmentation
of the public source code for Mozilla.

Have you tried with multipart/digest? It might work and do
what you want to do. But probably not.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 23 Dec 2004 16:45:16 +0530
From: Hari Krishna Pammi pammi <[email-masked]>
Reply-To: Hari Krishna Pammi pammi <[email-masked]>
To: [email-masked]
Subject: Re: MHTML: cid href to message/rfc822 in multipart/related
Sender: [email-masked]

On Thu, 23 Dec 2004 11:36:15 +0100, Jacob Palme <[email-masked]> wrote:
> At 11.29 +0530 04-12-23, Hari Krishna Pammi pammi wrote:
> >Hi,
> >
> >I have gone through RFCs RFC 2387, 2392 and 2557.
> >I want to create a multipart/related message where the HTML part has a
> >cid url with Content-ID of a message/rfc822 part. The idea is when I
> >click on the link, the mail client should show me the message/rfc822
> >attachment in a separate MAIL window.
> >
> >However, this doesn't seem to work any of the popular mail clients. I
> >have tried with Mozilla 1.7.3, Thunderbird 1.0. and Outlook Express 6,
> >but none of the clients seem to support this.
> >
> >The RFCs only have examples with images (IMG). but not with href links
> >to a message/rfc822.
> >
> >I have also gone through [email-masked] archives, but could'nt find
> >anything related to this topic. So , can anyone please help me:
> >
> >Q. Is it possible to have a mechanism where I can click on a link in a
> >HTML mail message (MHTML) and the client shows a message/rfc822 mail
> >part in another email window. If so , what should be the format of the
> >message. what should the href link contain ?
> 
> It is permitted by the MHTML standard, but not supported by
> major vendor. This means that you can only use it when you
> control both the MUA for sending and the MUA for receipt.
> 
> In general, major vendors have chosen to support only
> links to objects visible in the base page, not links to
> objects you can click on. The latter would allow sending
> a whole website in a single mail message, but is thus
> just supported by major vendors.
> 
That is correct,  but my attachment here is just another mail
(message/rfc822), and not a web page.

> >Note: Mozilla/thunderbird shows the attachment in a browser window and
> >does not recongnize the MIME structure of the attachment. Hence it
> >shows as plain text.
> 
> Content-Disposition should control whether a body part
> is shown inline or as an attachment. I believe, however,
> that some receiving MUAs show some body parts inline
> and not as attachments, even though Content-Disposition
> says attachment and not line.
> --
Yes, but Content-Disposition takes effect only if the MUA does not
recognize multipart/related. However, all the modern MUAs (mozilla,
outlook) do seem to understand multipart/related (but probably
broken).
In any case, my requirement is that when I click on the link (  a
href= "cid:<content-id of a message/rfc822>") I want the attachment
mail message with the same content-id to be show as another email
message itself in the MUA itself.

> Jacob Palme <[email-masked]> (Stockholm University and KTH)
> for more info see URL: http://www.dsv.su.se/jpalme/
>

Date: Thu, 23 Dec 2004 11:36:15 +0100
To: Hari Krishna Pammi pammi <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: MHTML: cid href to message/rfc822 in multipart/related
Cc: [email-masked]
Sender: [email-masked]

At 11.29 +0530 04-12-23, Hari Krishna Pammi pammi wrote:
>Hi,
>
>I have gone through RFCs RFC 2387, 2392 and 2557.
>I want to create a multipart/related message where the HTML part has a
>cid url with Content-ID of a message/rfc822 part. The idea is when I
>click on the link, the mail client should show me the message/rfc822
>attachment in a separate MAIL window.
>
>However, this doesn't seem to work any of the popular mail clients. I
>have tried with Mozilla 1.7.3, Thunderbird 1.0. and Outlook Express 6,
>but none of the clients seem to support this.
>
>The RFCs only have examples with images (IMG). but not with href links
>to a message/rfc822.
>
>I have also gone through [email-masked] archives, but could'nt find
>anything related to this topic. So , can anyone please help me:
>
>Q. Is it possible to have a mechanism where I can click on a link in a
>HTML mail message (MHTML) and the client shows a message/rfc822 mail
>part in another email window. If so , what should be the format of the
>message. what should the href link contain ?

It is permitted by the MHTML standard, but not supported by
major vendor. This means that you can only use it when you
control both the MUA for sending and the MUA for receipt.

In general, major vendors have chosen to support only
links to objects visible in the base page, not links to
objects you can click on. The latter would allow sending
a whole website in a single mail message, but is thus
just supported by major vendors.

>Note: Mozilla/thunderbird shows the attachment in a browser window and
>does not recongnize the MIME structure of the attachment. Hence it
>shows as plain text.

Content-Disposition should control whether a body part
is shown inline or as an attachment. I believe, however,
that some receiving MUAs show some body parts inline
and not as attachments, even though Content-Disposition
says attachment and not line.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 23 Dec 2004 11:29:18 +0530
From: Hari Krishna Pammi pammi <[email-masked]>
Reply-To: Hari Krishna Pammi pammi <[email-masked]>
To: [email-masked]
Subject: MHTML: cid href to message/rfc822 in multipart/related
Sender: [email-masked]

Hi,

I have gone through RFCs RFC 2387, 2392 and 2557.
I want to create a multipart/related message where the HTML part has a
cid url with Content-ID of a message/rfc822 part. The idea is when I
click on the link, the mail client should show me the message/rfc822
attachment in a separate MAIL window.

However, this doesn't seem to work any of the popular mail clients. I
have tried with Mozilla 1.7.3, Thunderbird 1.0. and Outlook Express 6,
but none of the clients seem to support this.

The RFCs only have examples with images (IMG). but not with href links
to a message/rfc822.

I have also gone through [email-masked] archives, but could'nt find
anything related to this topic. So , can anyone please help me:

Q. Is it possible to have a mechanism where I can click on a link in a
HTML mail message (MHTML) and the client shows a message/rfc822 mail
part in another email window. If so , what should be the format of the
message. what should the href link contain ?

Note: Mozilla/thunderbird shows the attachment in a browser window and
does not recongnize the MIME structure of the attachment. Hence it
shows as plain text.

Thanks a lot.
-Hari

Date: Mon, 20 Dec 2004 12:51:48 +1000
From: Laird Breyer <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Reply-To: [email-masked]
Mail-Followup-To: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Sender: [email-masked]

On Dec 17 2004, Keith Moore wrote:
> 
> since you don't want the copy of annotations to be implicit in copying 
> the message, I conclude that annotations should not be stored as part 
> of that self-contained object.
> 
> (yes, you could require that every MUA edit out annotations from the 
> message header before forwarding them, but this isn't backward 
> compatible. it's also optimizing for the uncommon case)
> 

There really needs to be some common idea of what annotations represent.
I'll discuss your listed features a little more to see what kind
of questions they suggest.

> The important features are (a) that they're associated with the
> message but not inherently part of the message and (b) that they can
> be manipulated in useful ways independently from the message.

If we take (a) literally, then virtually any type of derived information
qualify as annotations. For example, decoded images, or even the whole
display rendered message can be seen as derived from the literal contents of 
the message. Such a display can certainly be manipulated in useful ways
(e.g. change fonts on the fly, etc.)

But that seems too general. The displayed message is ephemeral, it is
never stored separately. It seems to me there at least needs to be
property (c) annotations are persistent. Of course this means that the
question of how and where they are stored is fundamental. But it also
means that easily (re)generated information does not and should not
constitute an annotation.

There is also the question of how long such information is valid. 
If annotations are stored separately, then their natural lifetime
must be short or medium at most. Certainly, a typical message archive 
would not be an appropriate place for them.

Another question: who or what are they for? Are they only for the human,
are they for both human and machine, or can they be solely for the machine?
I don't think annotations should be solely or principally for the machine.

> [assume annotations stored with message headers] 
> so if the user decides that he's going to forward some message from the 
> webmail client, should the webmail client send annotations along with 
> that forwarded message or not?  if the annotations are stored in the 
> message header, the webmail client will include them in the forwarded 
> message (assuming it forwards as an attachment, which everybody should 
> be doing these days), because it doesn't know any better.  if the 
> annotations are stored out-of-band, the webmail client will not forward 
> them, because it is not aware of them.  OTOH the fancy IMAP client can 
> give the user the option of forwarding the annotations because it's 
> explicitly aware of them.  for that matter it can let the user select 
> which annotations to forward and which ones to keep private.

I think in this example, you implicitly take annotations to be by and
for the human message recipient. Forwarding a message breaks this 
paradigm as the forwardee obtains a message containing annotations by
somebody else. This is true even for annotations that are not private.

I don't think the forwarding problem is in itself sufficient to rule
out storage inside the message, as it's always possible to, say,
encrypt annotations solely for the originating user. In your example,
the IMAP client would know how to encryt/decrypt the annotation, while
the webmail client would not. The forwardee would have a fully annotated
message without the ability to read the private annotations.

-- 
Laird Breyer.

Date: Sat, 18 Dec 2004 13:53:58 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: E-mail and group communication
Sender: [email-masked]

At 23.53 -0400 04-10-18, Keith Moore wrote:
>If anything, it seems like a really effective medium for group conversation would need to be a lot more functional than anything we can expect to implement via a user interface for interpersonal email.  

Actually, almost all successful group communication systems
I have tried in recent years have e-mail integration. This
e-mail integration can include one or more of the following
functionalities:

(a) All new messages to groups, in which I am a member, can
    be sent to me by e-mail, too.

(b) When I get this e-mial, I can reply, either using the
    mail reply command and send the mail to the group, or by
    clicking on a URL in the e-mail to get to a page in the
    groupware where I can write the reply.

(c) An alternative to sending full group messages by e-mail
    to members, is to send summaries, for example lists of
    titles, which the e-mail user can click on to get this
    message in the groupware. These messages may be sent only
    for example once a day.

Why do so many group communication systems have one of the
commands above? The reason is that e-mail works as a kind
of "news reporting service" (Not "news" in the "netnews"
sense). A news reporting system is a system which tells me
what is new and of interest to me. Examples of such news:

(1) New e-mail, both personal and via mailing lists
(2) Messages in groups in which you are a member
(3) New contributions to blogs
(4) Changes to web pages of importance to you

To make (3) and (4) available via e-mail, people subscribe
to services which check web pages for changes, and send
notifications by e-mail when certain web pages have changed.

Group communication is today mainly done using one of the
following technologies:

(A) E-mail mailing lists handled by software like Listserv
    or Mailman

(B) Netnews newsgroups

(C) Special groupware software like Lotus Notes and
    First Class

I have for many years thought that a really successful
group communication system should combine all these three
functionalities, so that people can choose to interface to
them via either of these three user interfaces.

I have tried to persuade the developers of First Class, to
develop First Class in this direction, but not succeeded
yet in getting them to see the market potential for such a
system. First Class is a very good groupware, when using
its own client software, but does not have a very good
e-mail interface at present.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 18 Dec 2004 11:14:32 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Message Attributes (considered harmful?)
Sender: [email-masked]

At 22.34 -0500 04-12-17, Keith Moore wrote:
>annotations seem like they belong outside the message container rather than inside.

Attributes added to a message will often not reach all
recipients. For example, "List-"-attributes will only reach
those who get a message through a mailing list which adds
such header, some recipients may get the message other
ways. Resent-headers will only be available to the resender
and those the message was resent-to. Spam-control headers
will only reach those who get the message through the
spam-control filter.

This also means that a person may receive a message more
than once, and with different attributes for the different
versions.

How should this be handled by a receiving MUA? An MUA
handling of such attributes can be:

(1) Do not show them to the final recipient. Most MUAs do
    this for received headers.

(2) There is sometimes a special command for the user to
    tell the MUA to show all such otehrwise suppressed
    headers.

(3) Show them to the final recipient, but not do any
    particular action.

(4) Do some action on the header, such as deleting
    spam-marked messages or putting them in a special folder
    named "Probably spam".

(5) Modify some user action on the message, for example
    "List-" headers may modify the functionality of the
    "Reply-to-all" command.

What should a receiving MUA do if it receives multiple
copies of the same message via different routes, and having
difference in such added attributes? In case (1) above,
there is no problem. In case (2), it may be most useful for
the final recipient to be told of all the attributes. THis
means that the MUA must be able to in some way couple
together different versions of a message received different
ways. Such coupling together is probably also useful in
case (4) and (5) above. For example, if a recipient gets a
message via two mailing lists, then "Reply-to-all" should
allow the recipient to reply to both lists.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 17 Dec 2004 19:58:36 -0800
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> Another, better way of implementing this is to use the "In-Reply-To" and
> "References" headers. They already contain the information necessary to
> see if a message is a reply to what you have written yourself, so why
> not use them?

Yup, this is what I do.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Date: Fri, 17 Dec 2004 22:34:29 -0500
To: [email-masked]
Sender: [email-masked]

>> it depends on what you mean by transferable.  surely a mail client
>> could use IMAP to move a message+annotations from one server to 
>> another
>> (as long as both source and destination servers supported that
>> feature), or from one folder to another.
>>
>
> That's certainly easy to do. But what bothers me with this is the 
> prospect
> of having message (meta) data which can't be accessed for a variety of
> reasons. Perhaps the following is too simplistic or abstract:
>
> Currently the RFC 2822 format is flexible enough that a message can be
> considered a self-contained object. This is a very powerful property
> because messages can be moved around the world in many ways, not just
> the mail system.

yes.  this is a useful notion.  but it has its limits. clearly not 
everything belongs inside that container.    as the mail system becomes 
more sophisticated and supports more features, eventually a single 
container becomes too limited.

annotations seem like they belong outside the message container rather 
than inside.  there are cases where you want to copy them along with 
the message (say, when you're moving the message to another folder, or 
moving all of your mail to another server) but in the most common cases 
(forwarding, resending) it seems that you either don't want to include 
them at all, or you want them to end up in a different form on the 
destination end than on the source end (edited and/or stored 
differently to distinguish the original recipient's annotations from 
the forwarded recipient's annotations).

since you don't want the copy of annotations to be implicit in copying 
the message, I conclude that annotations should not be stored as part 
of that self-contained object.

(yes, you could require that every MUA edit out annotations from the 
message header before forwarding them, but this isn't backward 
compatible. it's also optimizing for the uncommon case)

> They can be moved by protocols such as SMTP, IMAP, POP3, they can be
> cut and pasted into applications, they can be imported/exported to and
> from servers, they can be stored or archived in mbox or maildir
> format in any filesystem. All of this is possible because a message is
> only a stream of bytes with some structure, and programs need not fully
> understand the structure to be able to do some useful things.
>
> Enter annotations, which would be meta information about a message,
> accessible via particular protocol extensions. Such information, if
> not embedded into the message, would be lost by the kinds of operations
> mentioned above. So the annotations would be second class information,
> stuck inside a given server, and only extracted with some effort.
>
> Perhaps that's what annotations ought to be? The last paragraph above
> is nearly beginning to look like a definition.

I don't think it's a definition, but I do think it approximately 
describes how they ought to work.  It's not that they inherently 
require more effort to access, because IMAP or POP commands to fetch 
both annotations and message might certainly be useful. The important 
features are (a) that they're associated with the message but not 
inherently part of the message and (b) that they can be manipulated in 
useful ways independently from the message.   For instance, you might 
want to allow a client to append an annotation, or to edit or delete a 
previous annotation.   The message wouldn't  change (say, for caching 
purposes) just because the annotation changed.

>> OTOH, it's not at all clear that annotations should be forwarded along
>> with a forwarded message.  certainly there are cases where this is not
>> appropriate.
>
> As I said above, I like the self-containedness of RFC 2822
> messages. It's well documented, both simple (if the MIME structure is
> ignored) and complex. Separate annotations would break this, unless
> annotations were considered value-less to most other software, as
> there would be some extra effort required to access them.

Actually I think that annotations have more value if they're not 
implicitly associated with a message than if they are implicitly 
associated with the message.

> But who's to say what has value in the long term?

we never know for sure.  but we make such judgments routinely when 
defining protocols.

(for that matter, who is to say what is long term?)

> Conversely, having annotations travel with the message (i.e. embedded
> somehow in the RFC 2822 format) will certainly encourage third party
> use of such information in the long run. So it will tend to add
> cruft.
>
> I don't know what I think of these options yet. I guess one way to 
> think
> of the question is this: if annotations exist as part of the message,
> then they do not impose new requirements on the existing transport
> infrastructure. While if annotations are intrinsically separate from
> the message, then the transport infrastructure must be aware of them,
> e.g IMAP needs an extension to access them, POP3 will need another
> extension, etc.

well, the client needs to be aware of them anyway.  otherwise they 
won't be visible, they'll get forwarded when you don't want them to get 
forwarded, etc.

imagine the case where a user uses two different MUAs to access a 
single message store, say one at home (a fancy IMAP client) and one at 
work (a webmail client, because the work firewall won't allow IMAP 
traffic to pass).  the fancy client supports annotations, the webmail 
client doesn't.  so the user annotates messages at home, but those 
annotations don't show up when he reads his mail from work - the 
webmail client is completely unaware of them.  the user doesn't know 
anything about the underlying protocol for how annotations work.  but 
since he only sees the annotations at home, he feels free to store 
private or sensitive information about messages as annotations.

so if the user decides that he's going to forward some message from the 
webmail client, should the webmail client send annotations along with 
that forwarded message or not?  if the annotations are stored in the 
message header, the webmail client will include them in the forwarded 
message (assuming it forwards as an attachment, which everybody should 
be doing these days), because it doesn't know any better.  if the 
annotations are stored out-of-band, the webmail client will not forward 
them, because it is not aware of them.  OTOH the fancy IMAP client can 
give the user the option of forwarding the annotations because it's 
explicitly aware of them.  for that matter it can let the user select 
which annotations to forward and which ones to keep private.

Keith

Date: Sat, 18 Dec 2004 12:45:23 +1000
From: Laird Breyer <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Reply-To: [email-masked]
Mail-Followup-To: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Sender: [email-masked]

On Dec 17 2004, Keith Moore wrote:
> 
> it depends on what you mean by transferable.  surely a mail client 
> could use IMAP to move a message+annotations from one server to another 
> (as long as both source and destination servers supported that 
> feature), or from one folder to another.
> 

That's certainly easy to do. But what bothers me with this is the prospect 
of having message (meta) data which can't be accessed for a variety of 
reasons. Perhaps the following is too simplistic or abstract:

Currently the RFC 2822 format is flexible enough that a message can be
considered a self-contained object. This is a very powerful property
because messages can be moved around the world in many ways, not just
the mail system.

They can be moved by protocols such as SMTP, IMAP, POP3, they can be
cut and pasted into applications, they can be imported/exported to and
from servers, they can be stored or archived in mbox or maildir
format in any filesystem. All of this is possible because a message is
only a stream of bytes with some structure, and programs need not fully
understand the structure to be able to do some useful things.

Enter annotations, which would be meta information about a message, 
accessible via particular protocol extensions. Such information, if
not embedded into the message, would be lost by the kinds of operations
mentioned above. So the annotations would be second class information,
stuck inside a given server, and only extracted with some effort. 

Perhaps that's what annotations ought to be? The last paragraph above
is nearly beginning to look like a definition.

> OTOH, it's not at all clear that annotations should be forwarded along 
> with a forwarded message.  certainly there are cases where this is not 
> appropriate.  

As I said above, I like the self-containedness of RFC 2822
messages. It's well documented, both simple (if the MIME structure is
ignored) and complex. Separate annotations would break this, unless
annotations were considered value-less to most other software, as
there would be some extra effort required to access them. But who's to
say what has value in the long term?

Conversely, having annotations travel with the message (i.e. embedded
somehow in the RFC 2822 format) will certainly encourage third party
use of such information in the long run. So it will tend to add 
cruft. 

I don't know what I think of these options yet. I guess one way to think
of the question is this: if annotations exist as part of the message,
then they do not impose new requirements on the existing transport
infrastructure. While if annotations are intrinsically separate from
the message, then the transport infrastructure must be aware of them,
e.g IMAP needs an extension to access them, POP3 will need another
extension, etc.

-- 
Laird Breyer.

Date: Sat, 18 Dec 2004 02:23:59 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Sender: [email-masked]

At 11.01 -0800 04-12-09, Russ Allbery wrote:
> > A related issue is if a message arrives in two copies, one with the
>> recipient as personal recipient, the other via a mailing list. When this
>> happens, the cause is almost always faulty handling by the sender's MUA,
>> and the intention is that the message should only be sent to/via the
>> list. So in this case, the best receiving MUA behaviour is probably to
>> completely suppress the personal copy of the message.
>
>This is the way that I feel about it too, but as other people have
>commented in this discussion, not everyone feels that way and some people
>really want to get those personal copies.

It is certainly nice to be able to separate replies to what
you have written yourself from everything else in a mailing
list. This could be either only direct replies or also
recursively for replies to replies, etc.

However, achieving this by adding all authors in the chain
into the CC or To header is not the best idea:

(1) Because CC and To was not invented for this
(2) Because not all mailers sets the author in the To or CC
    header when replying to a list message
(3) Or some senders might manually edit out those To or CC
    headers

For this reason, relying on your own name in To and CC
messages to tell you that this message was a reply
tosomething you wrote yourself is very inreliable.

Another, better way of implementing this is to use the
"In-Reply-To" and "References" headers. They already
contain the information necessary to see if a message is a
reply to what you have written yourself, so why not use
them?

One things which surprises med is that so few MUAs give 
the kind of support which can be done by cleverly using
information in the "Message-ID", "In-Reply-To" and
"References" headers. They also allow useful features
like "Show me the message, which this message is a
reply to" or "Show me all the messages in this reply
tree.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Date: Fri, 17 Dec 2004 20:23:50 -0500
To: [email-masked]
Sender: [email-masked]

>> however message headers were originally intended for use by the author
>> or his user agent.  a couple of exceptions were made for MTAs
>> (Received) and delivery agents (Return-Path).  now things have gotten
>> out of hand, and we have everybody and his brother scribbling on the
>> message, so much that it's hard for the recipient (or his user agent)
>> to make sense of it.
>
> Very interesting. Incidentally, I had been under the impression that
> the exceptions you mention were actally part of the original
> intention, ie that the header area was supposed to be a catchall for
> anything that isn't body content.

as I understand it, ARPAnet mail grew out of a practice of sending 
messages by using FTP to append to a file on the recipient's computer.  
the entire message (both header and body) was created by the author, 
there were no intermediaries that were aware enough of the message 
content to be able to modify the header.  SMTP came along and added 
Received fields and Return-Path.  whether the original practice was 
"intention" or just the way it happened to work is not something I can 
comment on, since I wasn't there at the time.  but I have heard 
complaints since at least the mid-1980s that there was too little 
separation between envelope and transport in Internet mail , even 
though Received and Return-Path were the only layering violations in 
the design.  for various reasons, the situation is much worse now than 
it was then.

>> what we need IMHO is something akin to an annotation facility in IMAP
>> and/or POP, that stores the annotations separately from the actual
>> message.
>
> A few thoughts (or one single thought anyway) which come to mind:
>
> Such an external facility won't make the annotations readily
> transferable, or rather it leaves the door wide open for ad-hoc
> transfer mechanisms. Full messages are easily transferred by
> copying.

it depends on what you mean by transferable.  surely a mail client 
could use IMAP to move a message+annotations from one server to another 
(as long as both source and destination servers supported that 
feature), or from one folder to another.

OTOH, it's not at all clear that annotations should be forwarded along 
with a forwarded message.  certainly there are cases where this is not 
appropriate.  IMHO if you want to forward your annotations along with a 
message, you should forward the annotations as a separate MIME body 
part, along with the message/rfc822 body part of the forwarded message. 
  and you should probably have the opportunity to edit those annotations 
before you forward the message.  because while you might want to be 
able to expose (some of) your annotations to a recipient, your 
annotations should not become the recipient's annotations.

> Whether in fact annotations should be transferable in sync
> with a message is a separate question perhaps worth debating?

it makes sense to discuss what behavior would be desirable.

Date: Sat, 18 Dec 2004 02:03:32 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Sender: [email-masked]

At 22.22 -0500 04-12-16, Keith Moore wrote:
>so that it becomes difficult to separate the original message from the cruft added to it at various places and times.

It may be a nice model to say that nothing should be added to
the message-headers (except "Received:") after submission.
However, there are lots of headers which are added in this
way, all the "List-" headers, all the "Resent-"-headers,
spam-control-headers, etc.

"List-" and "Resent-" headers are already standards, spam-
control-headers will probably soon become standard.

If one wants to separate the originally sent header from
such added "cruft" maybe the best principle would be
to order the headers. There seems to already be a de-facto
standard that "List-" and spam-control headers are added
below the headers existing at submission.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 18 Dec 2004 10:44:49 +1000
From: Laird Breyer <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Reply-To: [email-masked]
Mail-Followup-To: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Sender: [email-masked]

On Dec 17 2004, Keith Moore wrote:
> 
> however message headers were originally intended for use by the author 
> or his user agent.  a couple of exceptions were made for MTAs 
> (Received) and delivery agents (Return-Path).  now things have gotten 
> out of hand, and we have everybody and his brother scribbling on the 
> message, so much that it's hard for the recipient (or his user agent) 
> to make sense of it.
> 

Very interesting. Incidentally, I had been under the impression that
the exceptions you mention were actally part of the original
intention, ie that the header area was supposed to be a catchall for
anything that isn't body content.

> what we need IMHO is something akin to an annotation facility in IMAP 
> and/or POP, that stores the annotations separately from the actual 
> message.

A few thoughts (or one single thought anyway) which come to mind:

Such an external facility won't make the annotations readily
transferable, or rather it leaves the door wide open for ad-hoc
transfer mechanisms. Full messages are easily transferred by
copying. 

Whether in fact annotations should be transferable in sync
with a message is a separate question perhaps worth debating?

-- 
Laird Breyer.

To: LIST: [email-masked];
Xref: clerew local.mime:4306
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Message Attributes
Date: Fri, 17 Dec 2004 12:29:18 GMT
Lines: 35
Sender: [email-masked]

In <AycG7eXF/[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>Charles Lindsey writes:
>> Therefore, I would suggest using something based on the MIME 
>> parameters, such as
>>
>>    Annotations: classification=top_secret;
>>         archived-at="http://foo.example/123456";
>>         x-spamassassin-score=5

>Note that this scheme is fundamentally incompatible with IMAP. In IMAP, 
>message headers are invariant. Once a client has downloaded a 
>particular field, it can cache that forever, so that field can never 
>change. (Search for msg-att-static in the IMAP RFC.)

There was no intention that this header would change once final delivery
had taken place (whether via POP3 or IMAP or anything else).

It would be generated by the sender of the message (or at the latest by
his submission agent). The 'x-spamassasin-score' was perhaps an
unfortunate example, as Keith has pointed out, because it implies that
additional parameters might be added in transit. But the ability for the
sender to add x-parameters is an important part of the idea, just as it is
for MIME parameters.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Fri, 17 Dec 2004 10:59:28 -0500
From: Cyrus Daboo <[email-masked]>
To: Keith Moore <[email-masked]>, [email-masked]
cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Sender: [email-masked]

Hi Keith,

--On December 17, 2004 8:56:03 AM -0500 Keith Moore <[email-masked]> 
wrote:

> what we need IMHO is something akin to an annotation facility in IMAP
> and/or POP, that stores the annotations separately from the actual
> message.

One proposed solution for IMAP:

    <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-11.txt>

-- 
Cyrus Daboo

Date: Fri, 17 Dec 2004 16:16:24 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Message Attributes (considered harmful)
Cc: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>
Sender: [email-masked]

Keith Moore writes:
> what we need IMHO is something akin to an annotation facility in IMAP 
> and/or POP, that stores the annotations separately from the actual 
> message.

Strongly agree.

IMAP has such a facility as a draft (with implementation experience). 
POP has nothing AFAIK. Webmail services have whatever they want to 
implement.

So, any mail server which offers multiple access vectors can provide 
access to the same annotations via each protocol.

Arnt

Cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Date: Fri, 17 Dec 2004 08:56:03 -0500
To: [email-masked]
Sender: [email-masked]

>> and I'm inclined to think that annotations added to a message after
>> delivery really don't belong in the message header.  we want to put
>> things there because it's easy to do so, not because it makes good
>> sense.
>
> From a practical point of view, I think this is debatable.
>
> It's certainly possible to create a new MIME type for each envisaged
> piece of information, but practically message headers have a privileged
> role.
>
> 1) They are easy to find without parsing a complex MIME structure.
>
> 2) They are often available in cases where the actual body isn't
> directly available.
>
> 3) They are intended for meta information about the message rather
> than message content per se, so it could be argued that they are the 
> only
> correct place to add annotations which describe aspects of the message
> rather than new content.

yes, yes, and yes.  these are all reasons why it's easy to use message 
headers.  and MIME types are an even worse place to put such 
annotations.

however message headers were originally intended for use by the author 
or his user agent.  a couple of exceptions were made for MTAs 
(Received) and delivery agents (Return-Path).  now things have gotten 
out of hand, and we have everybody and his brother scribbling on the 
message, so much that it's hard for the recipient (or his user agent) 
to make sense of it.

what we need IMHO is something akin to an annotation facility in IMAP 
and/or POP, that stores the annotations separately from the actual 
message.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Message Attributes
Date: Fri, 17 Dec 2004 02:03:27 -0500
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message -----
From: "Arnt Gulbrandsen" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 16, 2004 7:35 AM
Subject: Re: Message Attributes

> You probably don't want any mail system extension to be fundamentally
> incompatible with IMAP...
>

I viewing this is a possible extension to an open standard 2822 message
format which any frontend, gateway and backend system can use, gateway or
interchange with.

For example. our system supports 5 different mail networks.

    - Internet
    - Fidonet
    - UTI  (Universal Text Interface)
    - QWK/OPX

With the exception for a few items in internet RFC x822 format,  all have
minimum common mail header format attributes

    From:
    To:
    Subject:
    Date:
    MessageID:
    ReturnReceipt:
    Private:

Independent of any specific frontend and compatible backend,  I believe, a
few attributes have been missing in the internet for a long time.  I think
there are a small set of very common attributes that could useful in today's
environment and into the future.

Historically, Internet email was a private mail system between two people.
Internet News was public postings.   But more and more systems are offering
conferences with public/private ideas.  You can have a support forum for
example that allows both public and private mail.  In networks like Fidonet
or Internet News, the gating of this was optional.  For example, private
postings would remain local, not get exported.  The gating of a private
message would not be guaranteed to remain private at the receiver downlink.

I believe if such attributes were available, MUA will evolve to use them.

Thanks

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
Internet Interview: http://www.geeknewscentral.com/archives/003505.html

Date: Fri, 17 Dec 2004 15:36:17 +1000
From: Laird Breyer <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Reply-To: [email-masked]
Mail-Followup-To: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>, ietf-822 list <[email-masked]>
Sender: [email-masked]

On Dec 16 2004, Keith Moore wrote:
> 
> and I'm inclined to think that annotations added to a message after 
> delivery really don't belong in the message header.  we want to put 
> things there because it's easy to do so, not because it makes good 
> sense.

>From a practical point of view, I think this is debatable. 

It's certainly possible to create a new MIME type for each envisaged
piece of information, but practically message headers have a privileged 
role. 

1) They are easy to find without parsing a complex MIME structure.

2) They are often available in cases where the actual body isn't
directly available.

3) They are intended for meta information about the message rather
than message content per se, so it could be argued that they are the only 
correct place to add annotations which describe aspects of the message
rather than new content.

-- 
Laird Breyer.

Date: Fri, 17 Dec 2004 15:25:30 +1000
From: Laird Breyer <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Message Attributes
Reply-To: [email-masked]
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Dec 16 2004, Simon Josefsson wrote:
> 
> I'm not saying I think Annotations: is a good idea, though.  I think
> it is better to use one header for each purpose, than to create a
> generic purpose kitchen sink.
> 

I disagree. Having a plethora of single purpose headers is certainly
possible, but for annotations which might be intended for non human 
readers, it's a bad idea.

The problem is that each new header somebody devises will in practice
have a new syntax, which leads to new specialized RFCs and specialized
code to decipher each supported header individually, for each piece of
software which might want to extract information from such a
header. Then over time as new informational headers are added, more
specialized parsers have to be written or updated, for each relevant
piece of software.

If the goal is to communicate information to possibly a piece of software,
then I believe a generic syntax for such headers would help greatly, if
this information is in fact to be conveyed in a header. 

Moreover, encoding information into headers has common practical
limitations such as character set issues (already dealt with in RFC 2047). A
common informational header format can deal with such practical issues once
and for all, whereas having a proliferation of headers forces each
author to reinvent encodings etc.

There is also the issue of actually ignoring uninteresting headers.
Consider a piece of software which obtains as input an RFC 2822 message.
It has two simple ways of dealing with headers. 

One is the "whitelist" approach, namely ignore all headers, but
parse those headers which the software can recognize.

The other approach is the "blacklist", namely read all headers except those
which it specifically refuses to read.

The "blacklist" approach to reading headers is hampered by a proliferation
of headers with arbitrary formats, while the "whitelist" approach is 
mostly unaffected. However, if informational headers destined for machine
reading do follow a common syntax, then the "blacklist" approach isn't as
strongly penalized.

-- 
Laird Breyer.

Cc: ietf-822 list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Message Attributes (considered harmful)
Date: Thu, 16 Dec 2004 22:22:05 -0500
To: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

> Therefore, I would suggest using something based on the MIME 
> parameters,
> such as
>
>    Annotations: classification=top_secret;
>         archived-at="http://foo.example/123456";
>         x-spamassassin-score=5

it's strikes me that there's a serious problem with message headers.  
it's _far_ to easy to define new header fields for half-baked ideas.

the last thing we need are more message headers for which the source of 
the information is unspecified or ambiguous, so that it becomes 
difficult to separate the original message from the cruft added to it 
at various places and times.

and I'm inclined to think that annotations added to a message after 
delivery really don't belong in the message header.  we want to put 
things there because it's easy to do so, not because it makes good 
sense.

To: [email-masked]
Subject: Re: Message Attributes
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 16 Dec 2004 14:04:59 -0800
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

> In IMAP, you can download the message, add or modify Charles' header,
> upload the message again, and delete the old message.  I believe
> superseding in news would work in a similar fashion.  That solution
> isn't incompatible with IMAP.

This is incompatible with how Supersedes works in news.  Apart from the
fact that Supersedes is frequently disabled, meaning that in practice this
would result in duplicate copies, it would also cause everyone who had
read the original to see it again each time a new annotation was added.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Message Attributes
Date: Thu, 16 Dec 2004 17:21:23 +0100
Lines: 33
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:BGqHF4wcBBZcwT0eoN9Y3STe5b0=
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Charles Lindsey writes:
>> Therefore, I would suggest using something based on the MIME
>> parameters, such as
>>
>>    Annotations: classification=top_secret;
>>         archived-at="http://foo.example/123456";
>>         x-spamassassin-score=5
>
> Note that this scheme is fundamentally incompatible with IMAP. In IMAP, 
> message headers are invariant. Once a client has downloaded a 
> particular field, it can cache that forever, so that field can never 
> change. (Search for msg-att-static in the IMAP RFC.)
>
> You probably don't want any mail system extension to be fundamentally 
> incompatible with IMAP...

In IMAP, you can download the message, add or modify Charles' header,
upload the message again, and delete the old message.  I believe
superseding in news would work in a similar fashion.  That solution
isn't incompatible with IMAP.

The fact that this operation may be inefficient is a problem with
IMAP, not with the header.  The sometimes obnoxious design of IMAP can
be incompatible with, otherwise reasonable, solutions, in some cases.

I'm not saying I think Annotations: is a good idea, though.  I think
it is better to use one header for each purpose, than to create a
generic purpose kitchen sink.

Regards,
Simon

Date: Thu, 16 Dec 2004 13:35:55 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Message Attributes
Sender: [email-masked]

Charles Lindsey writes:
> Therefore, I would suggest using something based on the MIME 
> parameters, such as
>
>    Annotations: classification=top_secret;
>         archived-at="http://foo.example/123456";
>         x-spamassassin-score=5

Note that this scheme is fundamentally incompatible with IMAP. In IMAP, 
message headers are invariant. Once a client has downloaded a 
particular field, it can cache that forever, so that field can never 
change. (Search for msg-att-static in the IMAP RFC.)

You probably don't want any mail system extension to be fundamentally 
incompatible with IMAP...

Arnt

To: LIST: [email-masked];
Xref: clerew local.mime:4301
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Message Attributes
Date: Thu, 16 Dec 2004 10:54:22 GMT
Lines: 42
Sender: [email-masked]

In <007201c4e2a8$5a7840f0$6401a8c0@hdev1> "Hector Santos" <[email-masked]> writes:

>Right now, our nntp server will expose the message with a header:

>    X-WcMsg-Attr: Pvt Rcvd

>showing the message was private and received.

>It would be nice to have MUA begin to learn more about such common message
>attributes

One can envisage a whole set of "attributes" that might become associated
with a message (though perhaps calling them "annotations" might be better,
if that fits better with the IMAP facility).

If these things are (somtimes) to be recognized and acted upon by
software, then putting them in an unstructured header is not the way to do
it (and, for sure, we do not want in any way to encourage yet more Tags in
the Subject header).

Then, the facility needs to have built-in extensibility, because we do not
want to invent a new header each time someone thinks of a new annotation.

Therefore, I would suggest using something based on the MIME parameters,
such as

   Annotations: classification=top_secret;
        archived-at="http://foo.example/123456";
        x-spamassassin-score=5

(and yes, it is a possible alternative to Martin's Archived-At header).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: "Hector Santos" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>, <[email-masked]>
Subject: Re: Message Attributes
Date: Wed, 15 Dec 2004 10:16:47 -0500
Organization: Santronics Software, Inc
Sender: [email-masked]

Thanks Arnt.

----- Original Message -----
From: "Arnt Gulbrandsen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 15, 2004 9:53 AM
Subject: Re: Message Attributes

>
> Have a look at the IMAP ANNOTATE extension, it goes in the direction you
want.
>
> Arnt
>
>

Date: Wed, 15 Dec 2004 15:53:26 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Message Attributes
Sender: [email-masked]

Have a look at the IMAP ANNOTATE extension, it goes in the direction you want.

Arnt

From: "Hector Santos" <[email-masked]>
To: "IETF-822" <[email-masked]>
Subject: Message Attributes
Date: Wed, 15 Dec 2004 08:16:55 -0500
Organization: Santronics Software, Inc
Sender: [email-masked]

I know (I hope not) this is probably not going anywhere once a certain set
of people get involved, but I have I question about any effort to offer MUAs
ways to set the Message Attributes at the server storage.

For example.  We have a server-side message forum that is available online
via;

 - Telnet (ANSI/Console Text Mode),
 - Web Mail (Browser)
 - GUI frontend (client side Exes using mail API), and
 - exposed as a Local Newsgroup for Newsgroups readers.

For the more traditional first 3 methods above, the message forum may offer
message attributes as so:

    From:
    To:
    [_] Private

Of course, for a  newsgroup, the idea of a "Private Message" and similar
attributes are not typical or inherently part of the 822 format design.

Right now, our nntp server will expose the message with a header:

    X-WcMsg-Attr: Pvt Rcvd

showing the message was private and received.

It would be nice to have MUA begin to learn more about such common message
attributes

Similarity,

At a minimum, for responses,  our NNTP Server is designed the "Follow the
Attribute" of the original message. So if a poster created a private
message, the newsreader base response will automatically inherent this
attribute.

The same is true with the traditional ways, but only by setting the default
value for the private bit.

The question is, has there been any discussions along these lines in maybe
looking at some "method" via either some SUBJECT line attribute tag,
"Subject: [PVT] ....."  or the first line of the body:  Private: Yes, etc,
to kludge such an idea?

What other similar system available offer such ideas?  I would like to see
if its possible to standardize some of this stuff.

Comments?

Thanks

Hector Santos, Santronics Software, Inc.
Wildcat! Interactive Net Serve
http://www.winserver.com

To: [email-masked]
Subject: Re: Best MUA handling of duplicate messages from mailing lists
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 14 Dec 2004 11:30:14 -0800
Sender: [email-masked]

Keld Jørn Simonsen <[email-masked]> writes:
> On Tue, Dec 14, 2004 at 08:52:31AM -0800, Russ Allbery wrote:
>> Charles Lindsey <[email-masked]> writes:

>>> Since then, it has actually been implemented in some email systems
>>> (notably those written by Dan Bernstein).

>> Also mutt and Gnus.

> What are the recommended things to do in mutt and gnus to remove
> duplicate messages?

I meant that mutt and Gnus implement Mail-Followup-To.  Basically, you can
inform them of what mailing lists you subscribe to, and they will then
generate an appropriate Mail-Followup-To header in messages that you send
(and honor the header when responding to messages).

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Date: Tue, 14 Dec 2004 19:12:09 +0100
Lines: 15
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:soZQHUVepuo0cwdDVyt6buft+68=
Sender: [email-masked]

Keld Jørn Simonsen <[email-masked]> writes:

> On Tue, Dec 14, 2004 at 08:52:31AM -0800, Russ Allbery wrote:
>> 
>> Charles Lindsey <[email-masked]> writes:
>> 
>> > Since then, it has actually been implemented in some email systems
>> > (notably those written by Dan Bernstein).
>> 
>> Also mutt and Gnus.
>
> What are the recommended things to do in mutt and gnus to remove
> duplicate messages?

`Mail-Copies-To: nobody' is used by some Gnus users.

Date: Tue, 14 Dec 2004 18:45:17 +0100
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked]
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Sender: [email-masked]

On Tue, Dec 14, 2004 at 08:52:31AM -0800, Russ Allbery wrote:
> 
> Charles Lindsey <[email-masked]> writes:
> 
> > Since then, it has actually been implemented in some email systems
> > (notably those written by Dan Bernstein).
> 
> Also mutt and Gnus.

What are the recommended things to do in mutt and gnus to remove
duplicate messages?

Best regards
keld

To: [email-masked]
Subject: Re: Best MUA handling of duplicate messages from mailing lists
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 14 Dec 2004 08:52:31 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> Since then, it has actually been implemented in some email systems
> (notably those written by Dan Bernstein).

Also mutt and Gnus.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: LIST: [email-masked];
Xref: clerew local.mime:4293
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Date: Tue, 14 Dec 2004 11:07:23 GMT
Lines: 40
Sender: [email-masked]

In <p0611040abde39f4b7a73@[192.168.0.182]> Jacob Palme <[email-masked]> writes:

>At 12.07 +0000 04-12-13, Charles Lindsey wrote:
>>Since Jacob Palme, who is the author of the only extant draft for the MFT
>>header, has now joined us, perhaps it would be useful for him to dust down
>>that draft and bring it up to date. The list of issues that Bruce lists
>>would have to be taken into consideration, and indeed many of them are
>>already addressed in Jacob's original draft.

>I have now put up the latest version I have of this draft 
>at the web address
>http://dsv.su.se/jpalme/ietf/draft-drums-mfwupto-01.txt.
>I could also submit it again as an IETF draft if this is
>wanted.

I would suggest removing any reference to Netnews before doing so.
Ultimately, if this scheme is acceptable to the email community, then
there might be extensions into the Usenet community, but let us agree on
how it would work within email first. But the functionality you proposed
for email seems about right to me.

>The way I remember it, this document was, at that time, so
>extremely controversial, with so many strong opinions
>requiring incompatible functionality, that I decided at
>that time not to do any more work on it.

Since then, it has actually been implemented in some email systems
(notably those written by Dan Bernstein). If you are going to produce a
new draft, then some preliminary discussion with Dan might be fruitful.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 13 Dec 2004 18:55:30 -0800
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> Keeping a data base of Message-Ids to recognize duplicates is rather
> easy, if you do it the way I once did it. I kept the data base to a
> fixed rather low limit. This means that my software would not recognize
> duplicates if they arrived at widely different times, but this does not
> happen in reality. The fact that all duplicates typically arrive the
> same day or at least the same week makes the implementation of such a
> data base much easier.

Detecting duplicates is relatively straightforward; my mail client does
that out of the box.  The hard part is then choosing *which* duplicate to
suppress, while still not showing the mail message to the user twice or in
the wrong location in their mailbox sorting.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 13 Dec 2004 20:50:58 +0100
To: IETF mailing list on MIME and e-mail <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Sender: [email-masked]

At 11.53 -0500 04-12-09, Bruce Lilly wrote:
>O can indicate a suggestion for where to send responses
>via the Reply-To message header field (as described in
>RFCs 2822, 822, 733; it is particularly applicable to
>messages sent to mailing lists ("text message
>teleconference") as described in those RFCs).

My belief is that we will never get a consensus with the
main developers on how to use "Reply-To". Because of that,
I feel that this is a header which you should not use, and
if you get it in incoming mail, should ignore, because your
mailer cannot be sure what its intention is. I know that
people in this mailing list mostly agree that only the
sender should specify "Reply-To" and that it should not be
set by mailing list expanders to refer to the list. But I
do not think you will ever get all mailing list expander
developers to agree with that view.

This is similar to the "Newsgroups" header in e-mail,
which also is so controversial with several very
incompatible meanings in widespread usage that the only
reasonable choice is to ignore it.

My original message only discussed how a receiving mailer
should handle incoming duplicate messages. Certainly, if
you can get sending and receiving mailer to co-operate in a
useful way, you could produce something even better, but
that is very difficult to achieve with the large number
of different mail clients used.

At 11.01 -0800 04-12-09, Russ Allbery wrote:
> > A related issue is if a message arrives in two copies, one with the
>> recipient as personal recipient, the other via a mailing list. When this
>> happens, the cause is almost always faulty handling by the sender's MUA,
>> and the intention is that the message should only be sent to/via the
>> list. So in this case, the best receiving MUA behaviour is probably to
>> completely suppress the personal copy of the message.
>
>This is the way that I feel about it too, but as other people have
>commented in this discussion, not everyone feels that way and some people
>really want to get those personal copies.

Yes, some advanced users may want special handling of this,
I was mainly discussing the best default behaviour.

Keeping a data base of Message-Ids to recognize duplicates
is rather easy, if you do it the way I once did it. I kept
the data base to a fixed rather low limit. This means that
my software would not recognize duplicates if they arrived
at widely different times, but this does not happen in
reality. The fact that all duplicates typically arrive the
same day or at least the same week makes the implementation
of such a data base much easier.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Mon, 13 Dec 2004 20:47:03 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Sender: [email-masked]

At 12.07 +0000 04-12-13, Charles Lindsey wrote:
>Since Jacob Palme, who is the author of the only extant draft for the MFT
>header, has now joined us, perhaps it would be useful for him to dust down
>that draft and bring it up to date. The list of issues that Bruce lists
>would have to be taken into consideration, and indeed many of them are
>already addressed in Jacob's original draft.

I have now put up the latest version I have of this draft 
at the web address
http://dsv.su.se/jpalme/ietf/draft-drums-mfwupto-01.txt.
I could also submit it again as an IETF draft if this is
wanted.

The way I remember it, this document was, at that time, so
extremely controversial, with so many strong opinions
requiring incompatible functionality, that I decided at
that time not to do any more work on it.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: LIST: [email-masked];
Xref: clerew local.mime:4287
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Date: Mon, 13 Dec 2004 12:07:34 GMT
Lines: 43
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>On Thu December 9 2004 14:33, Keld Jørn Simonsen wrote:

>> My new idea is that the preference could be noted by one or more headers
>> from the originator, and the responder and the mailing list exploder
>> could then behave accordingly. I think this has not been proposed before
>> here, but then I have not read all mail...

>This needs a great deal more explanation before I can comment:
>  whose preference?
>  for what?
>  communicated to whom and/or to what?
>  by who or by what?
>  used how?
>  for what purpose?
>  in what manner?
>  is it scalable (multiple authors, multiple recipients, multiple lists)?
>  is yet another header field appropriate (vs. some other configuration setting, etc.)?
>  how would it interact with existing fields?
>  what about users of web interfaces to lists?

In the earlier discussions we had, many people considered that the
Mail-Followups-To header, if carefully used, could provide a reasonable
solution to these problems (though two people notably dissented from that
view).

Since Jacob Palme, who is the author of the only extant draft for the MFT
header, has now joined us, perhaps it would be useful for him to dust down
that draft and bring it up to date. The list of issues that Bruce lists
would have to be taken into consideration, and indeed many of them are
already addressed in Jacob's original draft.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>, "ietf-822" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Charset name length(s)
Date: Sun, 12 Dec 2004 23:16:55 -0800
Sender: [email-masked]

Hi -

> From: "Bruce Lilly" <[email-masked]>
> To: "ietf-822" <[email-masked]>; <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Sunday, December 12, 2004 9:39 PM
> Subject: Re: Charset name length(s)
>

> On Sun December 12 2004 22:52, Randy Presuhn wrote:
> >
> > Hi -
> >
> > Could explain the connection Bruce sees between the limit on
> > the length on descriptors used in writing MIB modules and
> > the tags used for identifying character sets?  I thought I
> > understood MIB compiler issuess fairly well, but I seem
> > to be missing something here, as I just can't see how the
> > MIB compiler constraints are relevant.
> >
> > Randy
>
> Briefly, charsets are specified by printer MIBs (RFC 3805,
> formerly 1759).  Those charsets have names beginning with
> "cs". More information is at the top of the IANA charsets
> registry
> http://www.iana.org/assignments/character-sets

I think the expression "putting the cart before the horse" applies.

Since there is already an aliasing mechanism in use in the
file you cite, it's a stretch to think that the character set name would
prevent the definition of a "cs*" alias that would fit within the
limits of what MIB compilers are permitted to support, or the
(shorter!) limit given in the IANA file.  A more fundamental
question would be why there would be any point to creating
a charset name to go with one of these imaginary long names.

Randy

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Charset name length(s)
Date: Mon, 13 Dec 2004 00:39:09 -0500
Cc: "Randy Presuhn" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Sun December 12 2004 22:52, Randy Presuhn wrote:
> 
> Hi -
> 
> Could explain the connection Bruce sees between the limit on
> the length on descriptors used in writing MIB modules and
> the tags used for identifying character sets?  I thought I
> understood MIB compiler issuess fairly well, but I seem
> to be missing something here, as I just can't see how the
> MIB compiler constraints are relevant.
> 
> Randy

Briefly, charsets are specified by printer MIBs (RFC 3805,
formerly 1759).  Those charsets have names beginning with
"cs". More information is at the top of the IANA charsets
registry
http://www.iana.org/assignments/character-sets

From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Charset name length(s)
Date: Sun, 12 Dec 2004 19:52:50 -0800
Sender: [email-masked]

Hi -

Could explain the connection Bruce sees between the limit on
the length on descriptors used in writing MIB modules and
the tags used for identifying character sets?  I thought I
understood MIB compiler issuess fairly well, but I seem
to be missing something here, as I just can't see how the
MIB compiler constraints are relevant.

Randy

> From: "Bruce Lilly" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Sunday, December 12, 2004 2:10 PM
> Subject: Charset name length(s)
>

> On Sun December 5 2004 13:36, McDonald Ira wrote:
> > Hi,
> >
> > Relative to Bruce's suggestion that the 40 character restriction
> > in names applies only to MIBs:
> >
> > (1) MIBs in both SMIv1 and SMIv2 have always supported the ASN.1
> >     standard maximum of 63 characters for identifiers
> >
> > (2) But, due to underlying linker restrictions, _many_ MIB compilers
> >     truncate identifiers at 31 characters (or arbitrarily rewrite
> > them after about 25 characters)
> >
> > (3) So 40 characters isn't a helpful restriction for MIB names.
>
> [I'm copying the ietf-822 list as the issue(s) discussed
> affect MIME and the Internet Message Format; responses
> to the charset-specific part should remain on ietf-charsets.
> I'm also copying the ietf and ietf-languages lists where
> a related discussion about language tags is taking place.]
>
> To date, I have merely pointed out that the registration
> for MIME names imposes no upper bound, but that the MIB
> requirements do indicate a limit for the cs* aliases.  I
> have not stated whether I thought that there should be an
> explicit limit in general. It is now time to speak up on
> that matter.
>
> I am prompted to do so by considerations arising from a
> proposal to replace RFC 3066, which defines language tags
> and their registration procedure.  Charset names and
> language tags are connected by way of RFC 2231, which
> amended RFC 2047's definition of "encoded-word" to include
> provision for a language tag.  An encoded-word has the
> form (my representation, not the official one; for the
> latter consult RFC 2231 and errata):
>
>   =?<charset>*<language-tag>?<encoding>?<text>?=
>
> The text part must be at least 4 octets in order to accommodate
> B encoding restrictions. Encodings are currently represented
> by a single octet, and as encodings are intended to be limited
> in number, let's assume that that will suffice indefinitely.
> That leaves a maximum of 63 octets for the total length of the
> charset name and the language-tag.  RFC 2978 (charset name
> registration) provides a procedure for review, so while the
> charset name could theoretically be infinite in length, the
> review process is expected to catch cases which would prove
> problematical for encoded-words -- in fact, so far as I can
> determine, the longest charset name suitable for use in an
> encoded-word (i.e. charsets suitable for text/plain, considering
> the preferred MIME name where specified, otherwise the primary
> name) has a length of 45 octets.
>
> RFC 2231 also provides for charset specification in extended
> parameters used with Content-Type and Content-Disposition
> fields; these are not required to be charsets suitable for
> text/plain, and the combined length of charset and language
> tag length is much greater than that in an encoded-word
> (but still finite).
>
> Under RFC 3066, there is a similar registration and review
> procedure, and while again there is the theoretical
> possibility of a very long language tag, the longest such
> registered tag has a length of 11 octets.
>
> Combined, the longest charset and longest language tag
> total 56 octets, which is less than the 63 octet limit
> imposed by encoded-word syntax.
>
> Unregistered, private-use charset and/or language-tags
> could of course be longer; that does not concern me.
> Private-use requires coordination between communicating
> parties, and it is a matter for those parties to agree
> on private-use tags that fit within the relevant limits.
>
> There is a draft proposal for a replacement of RFC 3066
> which would decouple non-private-use language tag use
> from the review/registration procedure and which would
> provide for infinite length non-private-use language
> tags.  That not only represents a problem for encoded-
> word use, but it is a problem for Internet Message
> Format header (message- and MIME-part) fields which use
> language tags, such as RFC 3282's Content-Language and
> Accept-Language.  A "New Last Call" has been issued
> for the draft proposal on the ietf-announce list:
> http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00755.html
>
> RFC 2047 gives rationale for the encoded-word limit,
> and the Message Format limit can be found in RFCs 2821
> and 2822.  Given the large deployed base of software
> implementing those core Internet protocols, I do not
> forsee an opportunity to increase the encoded-word
> length limit at this time. Consequently, the maximum
> total for registered charset and language tags remains
> at no more than 63 octets (and it is conceivable that
> future encodings might require a longer text portion).
> I suggest that charset names and aliases be limited to
> the current maximum of 45 octets, and that language-tags
> for use in encoded-words and extended parameters be
> limited to 16 octets (an increase of 45% over the
> longest registered language tag).  That leaves but 2
> octets of expansion room for encoding tags and/or
> encoding-driven restrictions on the encoded text.
>
> Ideally, a lower limit for MIME charset names would
> be used; aside from a couple of pathological cases, most
> MIME-compatible charsets names registered are 17 octets
> or less in length; many have shorter aliases.  However,
> establishing a limit lower than the longest currently-
> registered name would require extraordinary action. It
> might be possible to assign MIME-preferred-name aliases
> to the excessively-long registered charset names, for
> example.  However, the overall maximum (regardless of
> whether the charset is compatible with MIME text/plain)
> should probably be held at 45 octets.  As for the MIB-
> specific aliases, I'll leave specific recommendations up
> to others, but 45 octets is certainly capable of
> accommodating the current MIB-specific limit of 40 octets.
> _______________________________________________
> Ietf-languages mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/ietf-languages

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], [email-masked]
Subject: Charset name length(s)
Date: Sun, 12 Dec 2004 17:10:25 -0500
Cc: McDonald Ira <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Sun December 5 2004 13:36, McDonald Ira wrote:
> Hi,
> 
> Relative to Bruce's suggestion that the 40 character restriction
> in names applies only to MIBs:
> 
> (1) MIBs in both SMIv1 and SMIv2 have always supported the ASN.1
>     standard maximum of 63 characters for identifiers
> 
> (2) But, due to underlying linker restrictions, _many_ MIB compilers
>     truncate identifiers at 31 characters (or arbitrarily rewrite
> 	them after about 25 characters)
> 
> (3) So 40 characters isn't a helpful restriction for MIB names.

[I'm copying the ietf-822 list as the issue(s) discussed
affect MIME and the Internet Message Format; responses
to the charset-specific part should remain on ietf-charsets.
I'm also copying the ietf and ietf-languages lists where
a related discussion about language tags is taking place.]

To date, I have merely pointed out that the registration
for MIME names imposes no upper bound, but that the MIB
requirements do indicate a limit for the cs* aliases.  I
have not stated whether I thought that there should be an
explicit limit in general. It is now time to speak up on
that matter.

I am prompted to do so by considerations arising from a
proposal to replace RFC 3066, which defines language tags
and their registration procedure.  Charset names and
language tags are connected by way of RFC 2231, which
amended RFC 2047's definition of "encoded-word" to include
provision for a language tag.  An encoded-word has the
form (my representation, not the official one; for the
latter consult RFC 2231 and errata):

  =?<charset>*<language-tag>?<encoding>?<text>?=

The text part must be at least 4 octets in order to accommodate
B encoding restrictions. Encodings are currently represented
by a single octet, and as encodings are intended to be limited
in number, let's assume that that will suffice indefinitely.
That leaves a maximum of 63 octets for the total length of the
charset name and the language-tag.  RFC 2978 (charset name
registration) provides a procedure for review, so while the
charset name could theoretically be infinite in length, the
review process is expected to catch cases which would prove
problematical for encoded-words -- in fact, so far as I can
determine, the longest charset name suitable for use in an
encoded-word (i.e. charsets suitable for text/plain, considering
the preferred MIME name where specified, otherwise the primary
name) has a length of 45 octets.

RFC 2231 also provides for charset specification in extended
parameters used with Content-Type and Content-Disposition
fields; these are not required to be charsets suitable for
text/plain, and the combined length of charset and language
tag length is much greater than that in an encoded-word
(but still finite).

Under RFC 3066, there is a similar registration and review
procedure, and while again there is the theoretical
possibility of a very long language tag, the longest such
registered tag has a length of 11 octets.

Combined, the longest charset and longest language tag
total 56 octets, which is less than the 63 octet limit
imposed by encoded-word syntax.

Unregistered, private-use charset and/or language-tags
could of course be longer; that does not concern me.
Private-use requires coordination between communicating
parties, and it is a matter for those parties to agree
on private-use tags that fit within the relevant limits.

There is a draft proposal for a replacement of RFC 3066
which would decouple non-private-use language tag use
from the review/registration procedure and which would
provide for infinite length non-private-use language
tags.  That not only represents a problem for encoded-
word use, but it is a problem for Internet Message
Format header (message- and MIME-part) fields which use
language tags, such as RFC 3282's Content-Language and
Accept-Language.  A "New Last Call" has been issued
for the draft proposal on the ietf-announce list:
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg00755.html

RFC 2047 gives rationale for the encoded-word limit,
and the Message Format limit can be found in RFCs 2821
and 2822.  Given the large deployed base of software
implementing those core Internet protocols, I do not
forsee an opportunity to increase the encoded-word
length limit at this time. Consequently, the maximum
total for registered charset and language tags remains
at no more than 63 octets (and it is conceivable that
future encodings might require a longer text portion).
I suggest that charset names and aliases be limited to
the current maximum of 45 octets, and that language-tags
for use in encoded-words and extended parameters be
limited to 16 octets (an increase of 45% over the
longest registered language tag).  That leaves but 2
octets of expansion room for encoding tags and/or
encoding-driven restrictions on the encoded text.

Ideally, a lower limit for MIME charset names would
be used; aside from a couple of pathological cases, most
MIME-compatible charsets names registered are 17 octets
or less in length; many have shorter aliases.  However,
establishing a limit lower than the longest currently-
registered name would require extraordinary action. It
might be possible to assign MIME-preferred-name aliases
to the excessively-long registered charset names, for
example.  However, the overall maximum (regardless of
whether the charset is compatible with MIME text/plain)
should probably be held at 45 octets.  As for the MIB-
specific aliases, I'll leave specific recommendations up
to others, but 45 octets is certainly capable of
accommodating the current MIB-specific limit of 40 octets.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Date: Fri, 10 Dec 2004 08:46:27 -0500
Cc: Keld =?iso-8859-1?q?J=F8rn_Simonsen?= <[email-masked]>, Russ Allbery <[email-masked]>
Sender: [email-masked]

On Thu December 9 2004 14:33, Keld Jørn Simonsen wrote:
> 
> On Thu, Dec 09, 2004 at 11:01:26AM -0800, Russ Allbery wrote:
> > 
> > Jacob Palme <[email-masked]> writes:
> > 
> > > A related issue is if a message arrives in two copies, one with the
> > > recipient as personal recipient, the other via a mailing list. When this
> > > happens, the cause is almost always faulty handling by the sender's MUA,
> > > and the intention is that the message should only be sent to/via the
> > > list. So in this case, the best receiving MUA behaviour is probably to
> > > completely suppress the personal copy of the message.
> > 
> > This is the way that I feel about it too, but as other people have
> > commented in this discussion, not everyone feels that way and some people
> > really want to get those personal copies.

> yes, I actually am mostly interested, for some lists, on messages that
> are direct responses to me or followups on things I have written, - and
> where it is likely that I am in noted in the cc-field. [...]
> Thus the direct mail is the most important for me in these cases,
> and it should not be hidden or delayed.

> My new idea is that the preference could be noted by one or more headers
> from the originator, and the responder and the mailing list exploder
> could then behave accordingly. I think this has not been proposed before
> here, but then I have not read all mail...

This needs a great deal more explanation before I can comment:
  whose preference?
  for what?
  communicated to whom and/or to what?
  by who or by what?
  used how?
  for what purpose?
  in what manner?
  is it scalable (multiple authors, multiple recipients, multiple lists)?
  is yet another header field appropriate (vs. some other configuration setting, etc.)?
  how would it interact with existing fields?
  what about users of web interfaces to lists?

The answers to those questions don't seem clear, even in the
context of the preceding discussion (and I have retained those parts
that seem relevant above).

Date: Fri, 10 Dec 2004 07:20:27 -0500
From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Sender: [email-masked]

On Thu, 9 Dec 2004 15:03:11 +0100
Jacob Palme <[email-masked]> wrote:

> A related issue is if a message arrives in two copies, one
> with the recipient as personal recipient, the other via a
> mailing list. When this happens, the cause is almost always
> faulty handling by the sender's MUA, and the intention is
> that the message should only be sent to/via the list.

not so.  the sender's MUA doesn't know whether the personal 
recipient is a member of that list or not, nor does it know
the personal recipient's preferences - so it doesn't know whether 
a separate copy is required.

>  So in
> this case, the best receiving MUA behaviour is probably to
> completely suppress the personal copy of the message.

again, it depends on the personal recipient's preference, but this
would be a useful option.

> All described above is easy to implement if the mailer
> keeps a data base of message-ids and which messages they
> refer to. A problem is that a few messages do not have
> message-id, and a worse problem is that some very
> unfriendly mailing list software will change the message-id
> when expanding a message to a list.

another problem is that list and personal messages may arrive
in any order, which could mean that (as it looks to the recipient)
a message disappears from one folder and appears in another.

Date: Thu, 9 Dec 2004 20:33:03 +0100
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Sender: [email-masked]

On Thu, Dec 09, 2004 at 11:01:26AM -0800, Russ Allbery wrote:
> 
> Jacob Palme <[email-masked]> writes:
> 
> > A related issue is if a message arrives in two copies, one with the
> > recipient as personal recipient, the other via a mailing list. When this
> > happens, the cause is almost always faulty handling by the sender's MUA,
> > and the intention is that the message should only be sent to/via the
> > list. So in this case, the best receiving MUA behaviour is probably to
> > completely suppress the personal copy of the message.
> 
> This is the way that I feel about it too, but as other people have
> commented in this discussion, not everyone feels that way and some people
> really want to get those personal copies.
> 
> > All described above is easy to implement if the mailer keeps a data base
> > of message-ids and which messages they refer to.
> 
> It's not as easy as it sounds, since the message that should be
> supppressed (in most of our opinions) is the personal copy, and that's the
> copy that will almost certainly arrive first.  You have to not show that
> message to the user for some period of time while waiting for the list
> copy to do this properly, which adds considerable complexity.

yes, I actually am mostly interested, for some lists, on messages that
are direct responses to me or followups on things I have written, - and
where it is likely that I am in noted in the cc-field. Most of the other
messages on the list may for some lists be considered a kind of noise. 
Thus the direct mail is the most important for me in these cases,
and it should not be hidden or delayed.

So the desired behaviour differs, as also previously mentioned on this
list.

My new idea is that the preference could be noted by one or more headers
from the originator, and the responder and the mailing list exploder
could then behave accordingly. I think this has not been proposed before
here, but then I have not read all mail...

best regards
Keld

To: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 09 Dec 2004 11:01:26 -0800
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:
> At 16.39 -0700 04-09-17, Russ Allbery wrote:

>> "please try to suppress duplicates in mail sent to me and to the list."

> Suppose a person subscribes to two mailing lists A and B, and has
> his/her MUA sort their messages to two folders A and B. And suppose
> there is a message sent via both lists.  What is then the best
> behaviour?

> (a) Show each list-message as a separate message in the
>     folder for that list, and mark each of them as unread, so
>     that reading one copy will not set the other copy marked as
>     read.

> (b) As (a) but some kind of link between the two messages.

> (c) As (a), but reading the message in one folder marks it
>     as read also in the other folder.

> I think most users would prefer (c), some might prefer (b).

For me personally, the ideal behavior would be (c) -- an emulation of
Usenet crossposting, in other words.  However, that's something that I'd
want to be configurable on a per-list basis, since at times there may be
some reason why I want to see the messages from different lists separately
(the previously mentioned example of being in digest mode on one list, for
instance).

> A related issue is if a message arrives in two copies, one with the
> recipient as personal recipient, the other via a mailing list. When this
> happens, the cause is almost always faulty handling by the sender's MUA,
> and the intention is that the message should only be sent to/via the
> list. So in this case, the best receiving MUA behaviour is probably to
> completely suppress the personal copy of the message.

This is the way that I feel about it too, but as other people have
commented in this discussion, not everyone feels that way and some people
really want to get those personal copies.

> All described above is easy to implement if the mailer keeps a data base
> of message-ids and which messages they refer to.

It's not as easy as it sounds, since the message that should be
supppressed (in most of our opinions) is the personal copy, and that's the
copy that will almost certainly arrive first.  You have to not show that
message to the user for some period of time while waiting for the list
copy to do this properly, which adds considerable complexity.

> A problem is that a few messages do not have message-id, and a worse
> problem is that some very unfriendly mailing list software will change
> the message-id when expanding a message to a list.

If those were the worst problems we had to deal with, I would be very
happy, since then the problem would reduce to yelling at people who use
broken software.  Always an enjoyable and necessary pasttime.  :)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Thu, 09 Dec 2004 18:18:30 +0100
From: Eliot Lear <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [Old-standards] Re: standards spring cleaning
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1102612652.318225"; x:"432200"; a:"rsa-sha1"; b:"nofws:294"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"FQi4g8vl342x4Spms4fnZxPAByki94LT51JtYsWRPynZX0cP/7BxpaUrCC44X" "Rw8BfwI+DgIjXot8UztFUsdH/dIjmtRlUVbdXCvCTOBSsoannaypZpaS2wSgb" "u/bQSZ21WxyKepKLN48ziV2nGfHrMapgmWpf6/PB4HTlEaJlw="; c:"Date: Thu, 09 Dec 2004 18:18:30 +0100"; c:"From: Eliot Lear <[email-masked]>"; c:"Subject: Re: [Old-standards] Re: standards spring cleaning"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; "
Sender: [email-masked]

Dave Crocker wrote:
> On Mon, 06 Dec 2004 19:13:04 -0800 (PST), [email-masked] wrote:
> 
>>  > RFC1767       MIME Encapsulation of EDI Objects

> My impression is that this MIME type is still used and maybe extensively.
> 

I'll update the web site accordingly.

Eliot

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Best MUA handling of duplicate messages from mailing lists
Date: Thu, 9 Dec 2004 11:53:23 -0500
Cc: Jacob Palme <[email-masked]>
Sender: [email-masked]

On Thu December 9 2004 09:03, Jacob Palme wrote:

> A related issue is if a message arrives in two copies, one
> with the recipient as personal recipient, the other via a
> mailing list. When this happens, the cause is almost always
> faulty handling by the sender's MUA, and the intention is
> that the message should only be sent to/via the list. So in
> this case, the best receiving MUA behaviour is probably to
> completely suppress the personal copy of the message.

We've had this discussion recently; check the archives
for September and October.  There are several actors
involved (in particular, it's not exactly clear who you
mean by "sender"):
  O: a message originator
  MA: mailing list expander for list A
  MB: mailing list expander for list B
  R: respondent to a mailing list message
  D: a recipient of the response (directly, via a list
       expander, or both)

O can indicate a suggestion for where to send responses
via the Reply-To message header field (as described in
RFCs 2822, 822, 733; it is particularly applicable to
messages sent to mailing lists ("text message
teleconference") as described in those RFCs).

Some mailing list expanders inappropriately alter or
insert an author's Reply-To field, causing problems.
The field is clearly defined as an originator field, and
should not be touched by list expanders -- expanders
have a variety of List- fields for their use (RFCs 2369,
2919).  Let's assume that MA and MB are well-behaved
and do not affect originator fields.

A message sent by O duly arrives at list subscribers'
mailboxes and may be visible via mailing list archives
or web interfaces (etc.).  A respondent R elects to
send a message regarding some topic in a message
sent by O.  R presumably knows whether his
response is intended for O alone or for the entire
mailing list(s), or for O as well as mailing list subscriber/
viewers (O might not be a mailing list subscriber).  In
general R cannot know whether or not O is a
mailing list subscriber, nor can he tell what O's
preferences are.  Only if O clearly indicates these
items can R make an informed decision.  If O, as
the author (possibly also sender) of the original
message did not include any such indication or a
Reply-To field suggesting a set of addresses for
responses, R must guess.  Invariably some guess
will turn out to be inconsistent with some O's
preferences.  Who is to blame: the hapless R who
has been forced into guessing, or O who failed to
provide any information?  It is unreasonable to
blame any MUA, since the MUA is only an agent
for a human -- the human must decide (or guess)
where to send a message (response or otherwise),
and what suggestion to include (if any) for response
destinations for that message.  I certainly don't want
UAs second-guessing.  Just as R in general has no
way of knowing whether or not O is a subscriber to
any given mailing list, R's MUA certainly has no way
of making such a determination.

Some mailing list expanders have an option for list
subscriber to suppress list copies of messages in
which the list subscriber's exact mailbox appears in
a list message's recipient address fields.  That of
course can't help those who are not list subscribers,
list subscribers who, for whatever reason, have a
different list mailbox from any other mailbox which
might result in delivery to the same person, nor is
it able to take into account the fact that recipient
message header fields have nothing whatsoever to
do with actual message recipients (other than by
convention).

Some MDAs have the capability of suppressing
duplicate messages.  As do some rMUAs.  But a
respondent should not rely on that ability of *some*
MDAs and *some* MUAs -- if an original message's
author has suggested a specific set of addresses, a
respondent shouldn't send a scattergun response
under the assumption that duplicate suppression
will occur.

> All described above is easy to implement if the mailer
> keeps a data base of message-ids and which messages they
> refer to.

It's unclear what you mean by "mailer": the author?
the sender (if different from the author)? the author's
MUA?  some MSA or MTA or MDA?  some recipient's
rMUA?...    It's also unclear how that would help those
who choose to interact with mailing lists via a web
interface.

From: Dave Crocker <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 9 Dec 2004 08:30:37 -0800
Subject: Re: standards spring cleaning
Sender: [email-masked]

On Mon, 06 Dec 2004 19:13:04 -0800 (PST), [email-masked] wrote:
>  > RFC1767       MIME Encapsulation of EDI Objects
>
>  I'll defer to those with substantive EDI experience.

I haven't tracked that work for some years, so I forwarded the note to the ediint working group chair and copied the mailing list.

My impression is that this MIME type is still used and maybe extensively.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
www.brandenburg.com

Date: Thu, 9 Dec 2004 15:03:11 +0100
To: IETF mailing list on MIME and e-mail <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Best MUA handling of duplicate messages from mailing lists
Sender: [email-masked]

At 16.39 -0700 04-09-17, Russ Allbery wrote:
>"please try to suppress duplicates in mail sent to me and to the
>list."

Suppose a person subscribes to two mailing lists A and B,
and has his/her MUA sort their messages to two folders A
and B. And suppose there is a message sent via both lists.
What is then the best behaviour?

(a) Show each list-message as a separate message in the
    folder for that list, and mark each of them as unread, so
    that reading one copy will not set the other copy marked as
    read.

(b) As (a) but some kind of link between the two messages.

(c) As (a), but reading the message in one folder marks it
    as read also in the other folder.

I think most users would prefer (c), some might prefer (b).

===

A related issue is if a message arrives in two copies, one
with the recipient as personal recipient, the other via a
mailing list. When this happens, the cause is almost always
faulty handling by the sender's MUA, and the intention is
that the message should only be sent to/via the list. So in
this case, the best receiving MUA behaviour is probably to
completely suppress the personal copy of the message.

===

All described above is easy to implement if the mailer
keeps a data base of message-ids and which messages they
refer to. A problem is that a few messages do not have
message-id, and a worse problem is that some very
unfriendly mailing list software will change the message-id
when expanding a message to a list.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>, [email-masked]
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: standards spring cleaning
Date: Tue, 7 Dec 2004 14:12:42 -0500
Cc: Nathaniel Borenstein <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue December 7 2004 12:29, Nathaniel Borenstein wrote:
> In both cases, I would be happier if we had 
> said something in the security considerations about the necessity to 
> reassemble message/partials into their "parent" message before applying 
> any security-related content scans.

Yes, but it's not solely a security matter.  Any scan of content
(for potential privacy violations or other leakage of information,
spam scanners, etc.) should take message fragmentation
(and external-body, embedded executable content, etc.) into
account.  Ultimately, it may be an intractable problem, since
"executable content" can take many forms due to the variety
of programming/scripting/macro languages available.

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: standards spring cleaning
Date: Tue, 7 Dec 2004 12:29:26 -0500
To: ietf-822 <[email-masked]>, [email-masked]
Sender: [email-masked]

>> Don't forget Informational RFCs.  For example, RFC 1344 has
>> some very important advice for gateway implementors (and
>> that includes software which acts as a gateway, such as
>> message scanners).   Unfortunately some such implementors
>> have ignored 1344, resulting in problems:
>> http://www.kb.cert.org/vuls/id/836088

Actually, neither RFC 1344 nor RFC 2046, in my opinion, draw sufficient 
attention to this problem.  In both cases, I would be happier if we had 
said something in the security considerations about the necessity to 
reassemble message/partials into their "parent" message before applying 
any security-related content scans.

Date: Mon, 06 Dec 2004 19:13:04 -0800 (PST)
From: [email-masked]
Subject: Re: standards spring cleaning
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> I am currently involved in an experimental process to see what it would
> take to hold to the notion that Proposed and Draft Standards shouldn't
> stay in that state forever.  There are a number of mail related
> standards that fall into this category, and I wonder if people can tell
> me whether the list of standards below (or any others on the broader
> list) should stay or go.  The original list was generated
> programmatically by looking for proposed standards below RFC 2000 that
> are not obsoleted (we'll do draft later).

I have to say I question the wisdom of moving most specifications that made it
to draft to historical, but we'll cross that bridge when we come to it.

> Here they are:

> RFC1421       Privacy Enhancement for Internet Electronic Mail: Part I:
> Message  Encryption and Authentication Procedures
> RFC1422       Privacy Enhancement for Internet Electronic Mail: Part II:
> Certificate-Based Key Management
> RFC1423       Privacy Enhancement for Internet Electronic Mail: Part
> III: Algorithms, Modes, and Identifiers
> RFC1424       Privacy Enhancement for Internet Electronic Mail: Part IV:
> Key Certification and Related Services

PEM is, as far as I know, undeployed. I therefore have no issue with
moving the PEM documents to historic.

> RFC1494       Equivalences between 1988 X.400 and RFC-822 Message Bodies

The situation is somewhat confused, but I think RFC 2157 effectively obsoletes
RFC 1494. So this could be moved to historic.

> RFC1496       Rules for downgrading messages from X.400/88 to X.400/84
> when MIME content-types are present in the messages

In retrospect specifying a mapping to new forms for an old-at-the-time system
that by definition isn't interested in upgrading was something of a waste.  I
have no problem with moving this to historic.

> RFC1502       X.400 Use of Extended Character Sets

Some nice ideas here, but basically they never worked well if at all. No
objection to moving to historic.

> RFC1648       Postmaster Convention for X.400 Operations

Historic would be good.

> RFC1740       MIME Encapsulation of Macintosh Files - MacMIME

This stuff is widely supported and usage is fairly common. Probably should be
advanced to draft. Definitely not a candidate for historic.

> RFC1767       MIME Encapsulation of EDI Objects

I'll defer to those with substantive EDI experience.

> RFC1848       MIME Object Security Services

Never deployed. Historic.

> RFC1985       SMTP Service Extension for Remote Message Queue Starting
>                (ETRN)

ETRN is widely supported and used. A good candidate to move to draft,
not historic.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>, [email-masked]
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>, [email-masked]
Subject: Re: Fwd: standards spring cleaning
Date: Mon, 6 Dec 2004 12:43:43 -0500
Cc: Eliot Lear <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon December 6 2004 10:32, Paul Hoffman / IMC wrote:

> >I am currently involved in an experimental process to see what it 
> >would take to hold to the notion that Proposed and Draft Standards 
> >shouldn't stay in that state forever.  There are a number of mail 
> >related standards that fall into this category, and I wonder if 
> >people can tell me whether the list of standards below (or any 
> >others on the broader list) should stay or go.  The original list 
> >was generated programmatically by looking for proposed standards 
> >below RFC 2000 that are not obsoleted (we'll do draft later).

Don't forget Informational RFCs.  For example, RFC 1344 has
some very important advice for gateway implementors (and
that includes software which acts as a gateway, such as
message scanners).   Unfortunately some such implementors
have ignored 1344, resulting in problems:
http://www.kb.cert.org/vuls/id/836088

Date: Mon, 6 Dec 2004 07:32:02 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: standards spring cleaning
Sender: [email-masked]

[[ For those of you not on the original mailing lists this was sent to. ]]

>X-BrightmailFiltered: true
>X-Brightmail-Tracker: AAAAAA==
>Date: Mon, 06 Dec 2004 11:49:54 +0100
>From: Eliot Lear <[email-masked]>
>X-Accept-Language: en-us, en
>To: [email-masked], [email-masked], [email-masked]
>Subject: standards spring cleaning
>X-Enigmail-Version: 0.86.1.0
>X-Enigmail-Supports: pgp-inline, pgp-mime
>X-Spam-Score: 0.0 (/)
>X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
>Cc:
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.5
>List-Id: general discussion of application-layer protocols
>	<discuss.apps.ietf.org>
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>,
>	<mailto:[email-masked]?subject=unsubscribe>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>,
>	<mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>
>Good day,
>
>I am currently involved in an experimental process to see what it 
>would take to hold to the notion that Proposed and Draft Standards 
>shouldn't stay in that state forever.  There are a number of mail 
>related standards that fall into this category, and I wonder if 
>people can tell me whether the list of standards below (or any 
>others on the broader list) should stay or go.  The original list 
>was generated programmatically by looking for proposed standards 
>below RFC 2000 that are not obsoleted (we'll do draft later).
>
>Here they are:
>
>RFC1421       Privacy Enhancement for Internet Electronic Mail: Part 
>I: Message  Encryption and Authentication Procedures
>RFC1422       Privacy Enhancement for Internet Electronic Mail: Part 
>II: Certificate-Based Key Management
>RFC1423       Privacy Enhancement for Internet Electronic Mail: Part 
>III: Algorithms, Modes, and Identifiers
>RFC1424       Privacy Enhancement for Internet Electronic Mail: Part 
>IV: Key Certification and Related Services
>RFC1494       Equivalences between 1988 X.400 and RFC-822 Message Bodies
>RFC1496       Rules for downgrading messages from X.400/88 to 
>X.400/84 when MIME content-types are present in the messages
>RFC1502       X.400 Use of Extended Character Sets
>RFC1648       Postmaster Convention for X.400 Operations
>RFC1740       MIME Encapsulation of Macintosh Files - MacMIME
>RFC1767       MIME Encapsulation of EDI Objects
>RFC1848       MIME Object Security Services
>RFC1985       SMTP Service Extension for Remote Message Queue Starting
>               (ETRN)
>
>If you believe any of the above standards should not be reclassified 
>as historic, could you please send a note to 
>[email-masked] with the RFC number and a brief reason 
>as to why not and whether the document should be advanced.  A good 
>reason is that the standard is still generally useful.  A bad reason 
>is that a piece of old code implements it somewhere on the 'net. 
>That having been said we have a pretty low threshold for removing 
>something from the above list.
>
>Thanks for your time,
>
>Eliot

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 2 Dec 2004 18:01:14 -0600
To: [email-masked] (Kai Henningsen)
From: Steve Dorner <[email-masked]>
Subject: Re: Attempts at establishing harmful conventions
Cc: [email-masked]
Sender: [email-masked]

At 8:22 PM +0200 12/2/04, Kai Henningsen wrote:
>This here UA does something like "You changed the subject. Do you want to 
>keep the references? Y/N", except that's not the actual text. (Too lazy to 
>test it now, and it's in German anyway.)
>
>That seems simple enough.

Indeed, it seems simple enough, and you would think that stating 
something plainly in the user's language would do some good.

Unfortunately, users make only so much room in their brains for 
communications technology.  I know that, for example, if my 
mailserver is down for a while and somebody (not in the email 
business) gets a delay notification, there is a better than even 
chance that they will resend the message, saying "I'm not sure if you 
got this", despite the text in the notification that says:  YOU DO 
NOT NEED TO RESEND YOUR MESSAGE.  :-(
-- 
Where are we going, and why are we in this handbasket?

Date: Thu, 2 Dec 2004 17:58:44 -0600
To: [email-masked] (Kai Henningsen)
From: Steve Dorner <[email-masked]>
Subject: Re: Attempts at establishing harmful conventions
Cc: [email-masked]
Sender: [email-masked]

At 8:27 PM +0200 12/2/04, Kai Henningsen wrote:
>  > For that matter, how many permit a user to select multiple
>>  messages to compose a response citing all of the selected
>>  messages (including appropriate setting of In-Reply-To and
>>  References fields)?
>
>Hopefully few, as there *is no* appropriate setting for those fields in 
>that situation.

We actually hashed out a way that seemed right enough on this list a 
year or so ago.

>In any case, the result is confusing and frustrating for the human readers 
>of those messages.

Perhaps those who are dependent on UA's that make certain assumptions 
about the construction of such headers.

>It's simply a bad idea.

I heartily disagree.  Saves time when composing and reading.
-- 
Where are we going, and why are we in this handbasket?

Date: 02 Dec 2004 20:27:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Attempts at establishing harmful conventions
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Bruce Lilly)  wrote on 30.11.04 in <[email-masked]>:

> For that matter, how many permit a user to select multiple
> messages to compose a response citing all of the selected
> messages (including appropriate setting of In-Reply-To and
> References fields)?

Hopefully few, as there *is no* appropriate setting for those fields in  
that situation.

In any case, the result is confusing and frustrating for the human readers  
of those messages.

It's simply a bad idea.

MfG Kai

Date: 02 Dec 2004 20:22:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Attempts at establishing harmful conventions
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Steve Dorner)  wrote on 01.12.04 in <a07000c56bdd3a4c5c127@[129.46.158.103]>:

> At 8:14 PM -0500 11/30/04, Bruce Lilly wrote:
> >How many UAs make it possible, let alone easy, for authors to
> >edit References or In-Reply-To fields?
>
> The only ones I know of where it's possible are ones that have a
> "dump the whole message in a buffer" mode.
>
> I question whether this sort of thing could be done in a way that
> would make it comprehensible enough for any significant number of
> users to bother with.

This here UA does something like "You changed the subject. Do you want to  
keep the references? Y/N", except that's not the actual text. (Too lazy to  
test it now, and it's in German anyway.)

That seems simple enough.

MfG Kai

Date: Thu, 2 Dec 2004 11:31:29 +1000
From: Laird Breyer <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: Attempts at establishing harmful conventions
Reply-To: [email-masked]
Mail-Followup-To: ietf-822 <[email-masked]>
Sender: [email-masked]

On Dec 01 2004, Bruce Lilly wrote:
> 
> I don't think it's fair to single out IMAP; the issues that you mention
> are far more germane to a protocol like POP3, where there are no
> mechanisms for server-based searching/sorting/filtering or for
> retrieval of message components.  IMAP has mechanisms which
> could be extended to handle statistical filtering etc., with the
> same set of benefits that are characteristic of IMAP's other
> features (e.g. access to the same message store -- and in the
> case of Bayesian filtering, to the same set of data -- from any
> client anywhere).  POP3, on the other hand, doesn't have the
> basic server-side processing as IMAP that would be a prerequisite
> to implementation of specific server-side processing such as
> statistical filtering.

I seem to be taken as more critical than I intended today, both on this and
the Outlook Express comment I made to Keith just now. My intention
was to give specific concrete examples rather than generalities.

IMAP is not the issue. As a mail system, it's far superior to POP3,
except in simplicity. I wanted to illustrate an issue with Bayesian
filtering which was a response to Steve Dorner's comment about
detecting a change of topic within a thread. Perhaps a more abstract
description is more appropriate.

Bayesian analysis works best with full messages (or the human readable
text parts at any rate). For reasons of performance and
responsiveness, many mail user agents often separate the mail headers
from the body. This allows for example to quickly display messages
alphabetically by subject, which is an example of an
operation which need only involve the mail headers. On-the-fly
Bayesian analysis is not well suited for operations which naturally
only involve mail headers, so as part of the user interface, it has
certain natural limitations. Precomputed Bayesian analysis can go stale
when many new untypical messages are received.  

(Which is not to say Bayesian analysis is slow,
my own implementation [dbacl] handles about 100 messages per second on an
oldish Pentium 3/500 Mhz. But that still means a minute and a half for
10,000 messages).

The complexity of a Bayesian system is similar to the complexity of
implementing and maintaining a full text index, except a full text
index is universal while a Bayesian system works much better if it is
user specific.  In particular, this means that while a full text index
is easily distributed, a statistical database works best when centralized
as near the user as possible, who would ideally carry his wordlists
with him. 

Which is why I thought IMAP illustrates the difficulties quite well.

I mentioned POPFile at some point, but it really is a hack due to its
location as a POP3 proxy rather than a MUA plugin, which forces the
authors to essentially reimplement a MUA for managing/learning message
categorizations. BTW, they also have an IMAP module, which tries
to keep in sync with changes happening on the server, but again purely for
managing/relearning message categorizations, with consequent network traffic.

While I'm plugging the competition, I might as well mention the following
internet survey the author is doing regarding how much spam people get:

http://getpopfile.org/cgi-bin/start.cgi

Laird.

Date: Wed, 01 Dec 2004 16:37:04 -0800 (PST)
From: [email-masked]
Subject: RE: Company-Confidential indication
To: Bruce Lilly <[email-masked]>
Cc: ietf-822 <[email-masked]>, Vaudreuil Greg M Greg <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Wed December 1 2004 17:07, [email-masked] wrote:

> > In the very unlikely event that this ever happens (Oh look! The pigs have taken
> > wing!) the right thing to do IMO would be to sync the MIXER revision with VPIM,
> > not the other way around. There are probably more VPIM systems in use now than
> > there ever were MIXER gateways in their heyday. And I speak here as the author
> > of a MIXER gateway who has never done a VPIM implementation.

> There's another possible approach, based on general utility of the
> functionality represented by the fields as used by both MIXER and
> VPIM, viz. standardization of the fields for general use.  Of course
> that tends to run counter to RFC 2156 section 1.12.

Yep, that would be fine with me, but I do note that such efforts have
in the past had lots of trouble reaching consensus.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Attempts at establishing harmful conventions
Date: Wed, 1 Dec 2004 19:13:01 -0500
Sender: [email-masked]

On Wed December 1 2004 17:15, Laird Breyer wrote:
> 
> On Dec 01 2004, Bruce Lilly wrote:
> > On Tue November 30 2004 21:46, Laird Breyer wrote:
> > 
> > > Unfortunately, retrieving/analysing full bodies are expensive
> > > operations, for example think of an IMAP server where the MUA works
> > > with headers only and downloads bodies only if absolutely necessary.
> > 
> > IMAP has a number of features that operate on the server's
> > message store as directed by the client, including searching
> > capability.  There's also Sieve-based filtering.
> 
> IMAP is great for many things, but statistical filtering probably
> isn't among them. A typical Bayesian filter [...]

> It is certainly conceivable that an IMAP server would implement a
> statistical component, but there are drawbacks,[...]

I don't think it's fair to single out IMAP; the issues that you mention
are far more germane to a protocol like POP3, where there are no
mechanisms for server-based searching/sorting/filtering or for
retrieval of message components.  IMAP has mechanisms which
could be extended to handle statistical filtering etc., with the
same set of benefits that are characteristic of IMAP's other
features (e.g. access to the same message store -- and in the
case of Bayesian filtering, to the same set of data -- from any
client anywhere).  POP3, on the other hand, doesn't have the
basic server-side processing as IMAP that would be a prerequisite
to implementation of specific server-side processing such as
statistical filtering.

From: Bruce Lilly <[email-masked]>
Reply-To: Bruce Lilly <[email-masked]>
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>
Subject: RE: Company-Confidential indication
Date: Wed, 1 Dec 2004 19:03:13 -0500
Cc: Vaudreuil Greg M Greg <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed December 1 2004 17:07, [email-masked] wrote:

> In the very unlikely event that this ever happens (Oh look! The pigs have taken
> wing!) the right thing to do IMO would be to sync the MIXER revision with VPIM,
> not the other way around. There are probably more VPIM systems in use now than
> there ever were MIXER gateways in their heyday. And I speak here as the author
> of a MIXER gateway who has never done a VPIM implementation.

There's another possible approach, based on general utility of the
functionality represented by the fields as used by both MIXER and
VPIM, viz. standardization of the fields for general use.  Of course
that tends to run counter to RFC 2156 section 1.12.

Date: Wed, 1 Dec 2004 14:49:42 -0800
To: ietf-822 <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: Attempts at establishing harmful conventions
Cc: ietf-822 <[email-masked]>, Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

At 5:28 PM -0500 12/1/04, Bruce Lilly wrote:
>I've said elsewhere (mail-ng) that there are a number of
>reasons favoring splitting message content into clearly-delineated
>areas where message authors, user agents, transport agents,
>list expanders, etc. can each place relevant information without
>getting in each other's way.

I agree.  I think the more labelling of content is possible, the 
better the chance is that we can come up with proposals that will 
meet everyone's needs.  Once there are actually viable, interoperable 
ways to move forward, we can hope for widespread change.

Otherwise, all we do is end up arguing about making tradeoff X 
instead of tradeoff Y, which is hardly ever compelling.
-- 
Where are we going, and why are we in this handbasket?

Date: Thu, 2 Dec 2004 08:29:18 +1000
From: Laird Breyer <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: New I-D: draft-koch-subject-tags-considered-00.txt
Reply-To: [email-masked]
Mail-Followup-To: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

On Dec 01 2004, Keith Moore wrote:
> 
> Given that users are going to replace or upgrade what they have sooner
> or later, what should that replacement or upgrade do differently than
> current software does?
> 

Allow inspection of all mail header fields in user defined rules would
be a good start. I think we've gone off on a tangent. I'm happy to
leave it at this: Outlook Express is simply one current example of
software which tends to encourage the practice of adding [] type tags
to the Subject by other software attempting to complement its
limitations.

Laird.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Attempts at establishing harmful convention with multilingual =?utf-8?q?=D7=A2=D7=91=D7=A8=D7=99=D7=AA_/English?= subjects
Date: Wed, 1 Dec 2004 17:28:37 -0500
Cc: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

On Wed December 1 2004 13:30, Nathaniel Borenstein wrote:

> But even then, what's an "intelligent" thing for software to do?  If 
> we're a polyglot mailing list discussing complex linguistic issues, 
> does the fact that my subject line is all Hebrew, Arabic, and French 
> somehow imply that "Re:" is the wrong reply convention?

That's up to the author of the message; software should provide
the author with the ability to view metadata such as charset and
language information (and to provide the author with the ability
to edit that information from a set of legal values when
generating a message).

> , or that any  
> inserted [] prefix should occur in any particular language?

If such insertion is being performed by the message author, the
remarks above apply.  If you're taking about some other software
modifying an author's field without his knowledge or approval,
I've already said that I think that shouldn't be done.

I've said elsewhere (mail-ng) that there are a number of
reasons favoring splitting message content into clearly-delineated
areas where message authors, user agents, transport agents,
list expanders, etc. can each place relevant information without
getting in each other's way.  Having intermediaries screw around
with author's information hampers certain operations (e.g.
signing of message content including author header fields such
as Subject, To, From, Date, Keywords, Cc, Reply-To).  The only
way signing can work (by definition, since the purpose is to
verify that content hasn't changed) is if the signed information
remains unaltered.  And before you mention triple-wrapped
security multiparts, make sure that you  can point to UAs that
can generate and read triple-wrapped messages (and that
would include details such as displaying the Subject, etc.
fields from the signed part in message "folder" lists).

Date: Thu, 2 Dec 2004 08:15:16 +1000
From: Laird Breyer <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: Attempts at establishing harmful conventions
Reply-To: [email-masked]
Mail-Followup-To: ietf-822 <[email-masked]>
Sender: [email-masked]

On Dec 01 2004, Bruce Lilly wrote:
> On Tue November 30 2004 21:46, Laird Breyer wrote:
> 
> > Unfortunately, retrieving/analysing full bodies are expensive
> > operations, for example think of an IMAP server where the MUA works
> > with headers only and downloads bodies only if absolutely necessary.
> 
> IMAP has a number of features that operate on the server's
> message store as directed by the client, including searching
> capability.  There's also Sieve-based filtering.

IMAP is great for many things, but statistical filtering probably
isn't among them. A typical Bayesian filter carries around one (or
more) word list(s) with frequencies and other quantities, one per
word. Such a word list is updated in complex ways whenever "learning"
occurs, and typical current implementations produce word list sizes
anywhere from a few hundred k to tens of megabytes or more. It must
also be available for fast retrieval, because incoming mail has many
words, and most words occur once, making size reductions difficult.

It is certainly conceivable that an IMAP server would implement a
statistical component, but there are drawbacks, among them:

1) The training data to construct and maintain word lists would be
restricted to mail accessible by the IMAP server, e.g. only the
folders it manages for the user.

2) If a user has several mail accounts, with a different Bayesian
filter set up on each, all the filters would be trained and maintained
independently, with varying rates of success. It is much easier to let
a single point learn and filter mail. Statistically, this also gives a
bigger dataset to work with, and probably therefore better filtering
accuracy.

Laird.

p.s. I stand corrected on the Comments field.

Date: Wed, 01 Dec 2004 14:07:28 -0800 (PST)
From: [email-masked]
Subject: RE: Company-Confidential indication
To: Vaudreuil Greg M Greg <[email-masked]>
Cc: [email-masked], Bruce Lilly <[email-masked]>, ietf-822 <[email-masked]>, Keith Moore <[email-masked]>
Sender: [email-masked]

> VPIM did not ignore mixer.  RFC1911 and 24212 refers to mixer as the
> normative reference for sensitivity and importance.  VPIM profiled how to map
> these to existing semantics in the voicemail world, where there is no
> equivalent to company confidential.  Because there was no hope of advancing
> mixer, when it was time to advance VPIM to draft, the VPIM WG was advised to
> define these two fields directly.  Every effort was to make the definitions
> consistent.

> If Mixer comes back to life, we may have to do some work to make sure the
> paperwork matches the intention (and current reality) that these be the same.

In the very unlikely event that this ever happens (Oh look! The pigs have taken
wing!) the right thing to do IMO would be to sync the MIXER revision with VPIM,
not the other way around. There are probably more VPIM systems in use now than
there ever were MIXER gateways in their heyday. And I speak here as the author
of a MIXER gateway who has never done a VPIM implementation.

				Ned

Date: Wed, 1 Dec 2004 17:19:16 -0500
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: New I-D: draft-koch-subject-tags-considered-00.txt
Sender: [email-masked]

> Given the wide deployment of Outlook Express however, I expect it
> alone is sufficient to ensure the continuation of this convention,
> ceteris paribus. 

With that same justification we could blame almost any misfeature of the
current mail system on Outlook Express.

The half-life of a windows system before it's upgraded, reinstalled, or
retired is what, two or three years?  Even Outlook Express can change, 
and people tend to install new software or even buy new hardware when their
current systems succumb to bitrot.  

Given that users are going to replace or upgrade what they have sooner
or later, what should that replacement or upgrade do differently than
current software does?

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: UA author advice / message operations vs. message access protocols
Date: Wed, 1 Dec 2004 17:07:55 -0500
Cc: Steve Dorner <[email-masked]>
Sender: [email-masked]

On Wed December 1 2004 11:50, Steve Dorner wrote:
> 
> At 8:14 PM -0500 11/30/04, Bruce Lilly wrote:

> >This is probably an area where some advice to UA authors is called for.
> 
> But what advice?

Here are some starter suggestions:

* Get out of the user's way; don't force noise (e.g. "Re: ") into
   author fields -- let the user configure such behavior.

* Let the user configure which message header fields are
  displayed under various circumstances.

* Provide proper threading capability (using Message-ID,
   In-Reply-To, and References fields).
[There are some missing pieces here, particularly for messages
which are responses to multiple predecessors, but I'll leave
that for another day]

* Assume nothing about content in unstructured fields (Subject,
  Comments, Organization, Summary); decode encoded-words
  for display per RFC 2047/2231 and errata, but otherwise treat
  content as opaque data which is meaningful only to humans.

* Provide ability for the user to easily perform typical operations
  (edit recipients and other fields which an author is responsible
  for, compose new messages, prepare responses to the author(s)
  of one or more messages, prepare responses to the Reply-To
  address lists of one or more messages, Resend one or more
  messages, forward one or more messages, etc.)  Don't force
  the user to (e.g.) use a forward function to prepare a new
  (unrelated) message to a group of recipients.

* Ensure compliance with the relevant standards (e.g. ensure
  that header field lines containing encoded-words are no
  longer than 76 octets).

* For text (in the RFC 2277 sense), allow the user to configure,
  view, and edit language and charset of each piece of text
  (ensuring that only legal charsets and language tags are used).

> >IMAP has a number of features that operate on the server's
> >message store as directed by the client, including searching
> >capability.
> 
> If the exact operation you want to do is built into the IMAP 
> protocol, and if you happen to be talking to a server that hasn't 
> taken one of the numerous escape hatches available to IMAP servers, 
> great.  Unfortunately, your chances of implementing anything complex 
> or unanticipated with help from an IMAP server are small.  You would 
> certainly wind up fetching the message to do Bayesian analysis on it, 
> for example.

Let's keep things in perspective; fetching a message isn't always
a horrendous operation, and doing so via IMAP is little different
(modulo protocol baroqueness) than using other protocols such
as POP3.  At least IMAP does have the ability to handle some
search/sort operations on the server side of a narrow client/server
communications channel; POP3 doesn't.  Moreover, IMAP has
the ability to specify retrieval of specific parts of a message
(specific header fields, specific MIME parts, etc.), whereas POP3
is limited to a number of lines from the beginning of the message,
or the entire message.  I can't think of any operation that would
require retrieval of an entire message via IMAP that would not
also require retrieval of an entire message via POP3.

Date: Thu, 2 Dec 2004 07:45:53 +1000
From: Laird Breyer <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Steve Dorner <[email-masked]>, Peter Koch <[email-masked]>, [email-masked]
Subject: Re: New I-D: draft-koch-subject-tags-considered-00.txt
Reply-To: [email-masked]
Mail-Followup-To: Keith Moore <[email-masked]>, Steve Dorner <[email-masked]>, Peter Koch <[email-masked]>, [email-masked]
Sender: [email-masked]

On Dec 01 2004, Keith Moore wrote:
> > FWIW, I happen to know that the reason [] is added to the subject in 
> > that
> > particular case is because Outlook Express doesn't allow automatic 
> > filing
> > of messages based on arbitrary header fields, but can trigger rules
> > based on words in the subject.
> 
> that's an interesting observation, but it seems like an 
> overgeneralization.  not everyone who wants [listname] tags in the 
> subject uses Outlook Express.

Yes, I wouldn't suggest it's the major reason for the convention, or
even an original reason for it.

Given the wide deployment of Outlook Express however, I expect it
alone is sufficient to ensure the continuation of this convention,
ceteris paribus. Of course this can probably be said about other
software as well. 

Laird.

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked], Bruce Lilly <[email-masked]>
Cc: ietf-822 <[email-masked]>, Keith Moore <[email-masked]>
Subject: RE: Company-Confidential indication
Date: Wed, 1 Dec 2004 13:40:09 -0600 
Sender: [email-masked]

VPIM did not ignore mixer.  RFC1911 and 24212 refers to mixer as the normative reference for sensitivity and importance.  VPIM profiled how to map these to existing semantics in the voicemail world, where there is no equivalent to company confidential.  Because there was no hope of advancing mixer, when it was time to advance VPIM to draft, the VPIM WG was advised to define these two fields directly.  Every effort was to make the definitions consistent.

If Mixer comes back to life, we may have to do some work to make sure the paperwork matches the intention (and current reality) that these be the same.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 01, 2004 1:33 PM
To: Bruce Lilly
Cc: ietf-822; Keith Moore
Subject: Re: Company-Confidential indication

> As best I can tell from reviewing the documents, Sensitivity
> (and Importance) were defined first by MIXER in RFC 987.

I believe that's correct.

> VPIM then grabbed ahold of the same fields in RFC 1911.
> When MIXER was revised as RFC 2156, there was a note
> cautioning about other (non-MIXER) uses of these fields.
> RFC 1911 was then updated to RFC 2421 (and again to
> 3801), apparently ignoring the MIXER cautionary note.

I would like to think that MIXER is dead for all practical purposes. There
certainly is little if any chance of the specification ever getting updated
again. I therefore cannot see taking this cautionary note very seriously.

However, I should add that only a few months ago I was contacted by someone
writing a brand new implementation. The mind boggles...

				Ned

Date: Wed, 01 Dec 2004 10:33:00 -0800 (PST)
From: [email-masked]
Subject: Re: Company-Confidential indication
To: Bruce Lilly <[email-masked]>
Cc: ietf-822 <[email-masked]>, Keith Moore <[email-masked]>
Sender: [email-masked]

> As best I can tell from reviewing the documents, Sensitivity
> (and Importance) were defined first by MIXER in RFC 987.

I believe that's correct.

> VPIM then grabbed ahold of the same fields in RFC 1911.
> When MIXER was revised as RFC 2156, there was a note
> cautioning about other (non-MIXER) uses of these fields.
> RFC 1911 was then updated to RFC 2421 (and again to
> 3801), apparently ignoring the MIXER cautionary note.

I would like to think that MIXER is dead for all practical purposes. There
certainly is little if any chance of the specification ever getting updated
again. I therefore cannot see taking this cautionary note very seriously.

However, I should add that only a few months ago I was contacted by someone
writing a brand new implementation. The mind boggles...

				Ned

From: Nathaniel Borenstein <[email-masked]>
Subject: =?UTF-8?Q?Re:_Attempts_at_establishing_harmful_convention_with_m?= =?UTF-8?Q?ultilingual_=D7=A2=D7=91=D7=A8=D7=99=D7=AA_/English_su?= =?UTF-8?Q?bjects?=
Date: Wed, 1 Dec 2004 13:30:58 -0500
To: ietf-822 <[email-masked]>
Sender: [email-masked]

On Dec 1, 2004, at 11:30 AM, Bruce Lilly wrote:

> On Wed December 1 2004 08:26, Nathaniel Borenstein wrote:
>
>> And what about what I've done to this message's subject?  Should a 
>> list
>> processor have to analyze it and infer from its character sets what
>> *languages* are OK for subject annotations?
>
> Had you included the language tag as provided for by the RFC 2231
> amendment to RFC 2047 (as further amended by errata), and in
> accordance with RFC 2277, there would be no need to guess...

But even then, what's an "intelligent" thing for software to do?  If 
we're a polyglot mailing list discussing complex linguistic issues, 
does the fact that my subject line is all Hebrew, Arabic, and French 
somehow imply that "Re:" is the wrong reply convention, or that any 
inserted [] prefix should occur in any particular language?  There's no 
right answer, it's completely a human-level decision.

Cc: Steve Dorner <[email-masked]>
From: Nathaniel Borenstein <[email-masked]>
Subject: Re: MoreOn: Attempts at establishing harmful conventions
Date: Wed, 1 Dec 2004 13:28:08 -0500
To: ietf-822 <[email-masked]>
Sender: [email-masked]

On Nov 30, 2004, at 10:19 PM, Bruce Lilly wrote:

> On Tue November 30 2004 19:39, Steve Dorner wrote:
>
>> Is [nameoflist] inserted by a list processor a human-level convention?
>>
>> If a machine puts it there, I think it's reasonable for another
>> machine to try to take it out.
>
> The problem is that given a message with such a string in its
> Subject field, there is no way to determine whether it was
> put there by a machine or by the message's author.

Precisely.  And this implies that software should (at most) only put 
such a string into the subject field if it is aimed at a human, not 
software.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>
Subject: Re: Company-Confidential indication
Date: Wed, 1 Dec 2004 12:06:40 -0500
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

I see that as of RFC 3801, the discrepancy in VPIM seems
to have been corrected, and there is some verbiage about use
(3801 section 4.2.13).

On Tue November 30 2004 21:03, Keith Moore wrote:

> sounds like an opportunity for an addition to one or two of the RFC 
> Editor's errata pages:
> 
> 1. for VPIM - point out (a) that MIXER also uses the Sensitivity field 
> (b) that it's possible to receive a message from a MIXER gateway that 
> has such a field with the value of Company-Confidential and (c) VPIM 
> implementations should not break when they see such a field.
> 
> 2. for MIXER - point out that VPIM also uses the Sensitivity field, and 
> (if the VPIM uses are at odds with those in MIXER) point out that MIXER 
> gateways should do something reasonable if they see Sensitivity fields 
> with values they don't understand.

As noted above, 3801 seems to have addressed the VPIM
side of things.  I'm not sure if anybody is actively maintaining
the MIXER specifications.

As best I can tell from reviewing the documents, Sensitivity
(and Importance) were defined first by MIXER in RFC 987.
VPIM then grabbed ahold of the same fields in RFC 1911.
When MIXER was revised as RFC 2156, there was a note
cautioning about other (non-MIXER) uses of these fields.
RFC 1911 was then updated to RFC 2421 (and again to
3801), apparently ignoring the MIXER cautionary note.

Date: Wed, 1 Dec 2004 09:02:41 -0800
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: New I-D: draft-koch-subject-tags-considered-00.txt
Sender: [email-masked]

At 6:55 AM +0100 12/1/04, Arnt Gulbrandsen wrote:
>Sounds like an arms race.
>
>1. Proxy adds header fields.
>2. MUA learns to show only a select few fields.
>3. Proxy sticks information into subject using []
>4. MUA learns to suppress [].
>
>In step 5, the proxy must stop using [] and switch to something it's 
>more difficult to suppress.

Possibly.  Implementation details would matter significantly, I 
think.  In my mind, I would show these things where there was "room" 
and not where there wasn't.  So, message listings, I'd hide them. 
Actual message display, I'd let them through.  I think this would 
meet most of the desires of the taggers, and so wouldn't be worked 
around.

>You can never distinguish a machine added [] tag from a parenthesis
>inserted by a human. In fact, POPFile is a good example, because the
>contents of the [] can be literally any string the user wants to insert
>as a category label. So your MUA would have to query POPFile for the
>list of category strings used or ask the user etc.

Again, implementation details matter here.  If POPFile adds its tag, 
my MUA processes the email with filters based on the tag (say, to ... 
file ... it), but then hides the tag from the user in display (and 
probably reply), everybody wins.

>If a MUA did consider [] as a comment, wouldn't that break "Re[2]:
>foo" parsing ?

Details, details.  :-)

At 8:16 AM -0500 12/1/04, Nathaniel Borenstein wrote:
>On Dec 1, 2004, at 1:46 AM, SM wrote:
>
>>The tags that are inserted in the Subject header break DomainKeys.
>
>But not if the canonicalization algorithm is modified to ignore them.

Yup.  Cooperate with the inevitable.

I'm much more used to wearing an implementor hat, where I have to 
deal with the world as I find it, rather than a protocol designer 
hat, where I get to fantasize about changing someone else's behavior. 
That undoubtedly colors my outlook here.
-- 
Where are we going, and why are we in this handbasket?

Date: Wed, 1 Dec 2004 08:50:55 -0800
To: ietf-822 <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: Attempts at establishing harmful conventions
Sender: [email-masked]

At 8:14 PM -0500 11/30/04, Bruce Lilly wrote:
>How many UAs make it possible, let alone easy, for authors to
>edit References or In-Reply-To fields?

The only ones I know of where it's possible are ones that have a 
"dump the whole message in a buffer" mode.

I question whether this sort of thing could be done in a way that 
would make it comprehensible enough for any significant number of 
users to bother with.

>For that matter, how many permit a user to select multiple
>messages to compose a response citing all of the selected
>messages (including appropriate setting of In-Reply-To and
>References fields)?

Only one that I know of. ;-)

>This is probably an area where some advice to UA authors is called for.

But what advice?

>IMAP has a number of features that operate on the server's
>message store as directed by the client, including searching
>capability.

If the exact operation you want to do is built into the IMAP 
protocol, and if you happen to be talking to a server that hasn't 
taken one of the numerous escape hatches available to IMAP servers, 
great.  Unfortunately, your chances of implementing anything complex 
or unanticipated with help from an IMAP server are small.  You would 
certainly wind up fetching the message to do Bayesian analysis on it, 
for example.
-- 
Where are we going, and why are we in this handbasket?

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>, [email-masked]
Subject: Re: Attempts at establishing harmful conventions
Date: Wed, 1 Dec 2004 11:19:30 -0500
Sender: [email-masked]

On Tue November 30 2004 21:33, Laird Breyer wrote:

> So it seems to me inevitable that some tagging field (Tagged:,
> Processed:, or whatever) must be devised. Perhaps the existing Comment:
> field can be used for that purpose? I don't know.

The field name is "Comments", not "Comment" (error in RFC 724
examples notwithstanding), and it's in the same boat as Subject;
both fields are unstructured and designated for the message
author's use for "only human-readable content".

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>
Subject: Re: Attempts at establishing harmful convention with multilingual =?utf-8?q?=D7=A2=D7=91=D7=A8=D7=99=D7=AA_/English?= subjects
Date: Wed, 1 Dec 2004 11:30:29 -0500
Cc: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

On Wed December 1 2004 08:26, Nathaniel Borenstein wrote:

> And what about what I've done to this message's subject?  Should a list 
> processor have to analyze it and infer from its character sets what 
> *languages* are OK for subject annotations?

Had you included the language tag as provided for by the RFC 2231
amendment to RFC 2047 (as further amended by errata), and in
accordance with RFC 2277, there would be no need to guess...

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: "ietf-822" <[email-masked]>, [email-masked]
Subject: Re: Attempts at establishing harmful conventions
Date: Wed, 1 Dec 2004 11:14:46 -0500
Sender: [email-masked]

On Tue November 30 2004 21:46, Laird Breyer wrote:

> Unfortunately, retrieving/analysing full bodies are expensive
> operations, for example think of an IMAP server where the MUA works
> with headers only and downloads bodies only if absolutely necessary.

IMAP has a number of features that operate on the server's
message store as directed by the client, including searching
capability.  There's also Sieve-based filtering.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: MoreOn: Attempts at establishing harmful conventions
Date: Tue, 30 Nov 2004 22:19:44 -0500
Cc: Steve Dorner <[email-masked]>
Sender: [email-masked]

On Tue November 30 2004 19:39, Steve Dorner wrote:

> Is [nameoflist] inserted by a list processor a human-level convention?
> 
> If a machine puts it there, I think it's reasonable for another 
> machine to try to take it out.

The problem is that given a message with such a string in its
Subject field, there is no way to determine whether it was
put there by a machine or by the message's author.

Cc: Steve Dorner <[email-masked]>, Peter Koch <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: New I-D: draft-koch-subject-tags-considered-00.txt
Date: Wed, 1 Dec 2004 09:23:40 -0500
To: [email-masked]
Sender: [email-masked]

> FWIW, I happen to know that the reason [] is added to the subject in 
> that
> particular case is because Outlook Express doesn't allow automatic 
> filing
> of messages based on arbitrary header fields, but can trigger rules
> based on words in the subject.

that's an interesting observation, but it seems like an 
overgeneralization.  not everyone who wants [listname] tags in the 
subject uses Outlook Express.

Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>
From: Nathaniel Borenstein <[email-masked]>
Subject: =?UTF-8?Q?Re:_Attempts_at_establishing_harmful_convention_with_m?= =?UTF-8?Q?ultilingual_=D7=A2=D7=91=D7=A8=D7=99=D7=AA_/English_su?= =?UTF-8?Q?bjects?=
Date: Wed, 1 Dec 2004 08:26:27 -0500
To: Keith Moore <[email-masked]>
Sender: [email-masked]

On Nov 30, 2004, at 9:52 PM, Keith Moore wrote:

>> How would you handle foreign-language abbreviations?
>
> IMHO - if the subject line is in Klingon, any annotations should also 
> be in Klingon.

And what about what I've done to this message's subject?  Should a list 
processor have to analyze it and infer from its character sets what 
*languages* are OK for subject annotations?

Cc: [email-masked]
From: Nathaniel Borenstein <[email-masked]>
Subject: Re: New I-D: draft-koch-subject-tags-considered-00.txt
Date: Wed, 1 Dec 2004 08:16:17 -0500
To: SM <[email-masked]>
Sender: [email-masked]

On Dec 1, 2004, at 1:46 AM, SM wrote:

> The tags that are inserted in the Subject header break DomainKeys.

But not if the canonicalization algorithm is modified to ignore them.