Subject: RE: Halloween/Message receipts
From: Keith Moore <[email-masked]>
To: "'Keith Moore'" <[email-masked]>, Antony Bowesman <[email-masked]>
Cc: "Brian Trenbeath (Exchange)" <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], Pete Resnick <[email-masked]>
Date: Tue, 24 Nov 1998 11:30:42 -0800

Yes, there's another Keith Moore. I work on the IIS team.

KM

		-----Original Message-----
		From:	Keith Moore [mailto:[email-masked]]
		Sent:	Monday, November 23, 1998 6:36 PM
		To:	Antony Bowesman
		Cc:	Brian Trenbeath (Exchange); Ned Freed; Keith Moore;
[email-masked]; Keith Moore; Pete Resnick
		Subject:	Re: Halloween/Message receipts 

		> If the Outlook 98 buggy version continues to be shipped
until O2k then
		> it appears this may have quite an effect on the standards
review process
		> simply as a result of the installed base. 

		maybe Microsoft will see fit to issue a patch.

		> Lastly, 
		> 
		> >To: "Keith Moore" <[email-masked]>
		> 
		> Are there two KM?  

		In fact there are.  Though I've never met the Keith Moore
from
		Microsoft and wasn't aware that he was doing Internet email
stuff.

		(Hi Keith!)

		Keith

From: Keith Moore <[email-masked]>
To: Antony Bowesman <[email-masked]>
cc: Brian Trenbeath <[email-masked]>, Ned Freed <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>
Subject: Re: Halloween/Message receipts 
Date: Mon, 23 Nov 1998 21:35:38 -0500
Sender: [email-masked]

> If the Outlook 98 buggy version continues to be shipped until O2k then
> it appears this may have quite an effect on the standards review process
> simply as a result of the installed base. 

maybe Microsoft will see fit to issue a patch.

> Lastly, 
> 
> >To: "Keith Moore" <[email-masked]>
> 
> Are there two KM?  

In fact there are.  Though I've never met the Keith Moore from
Microsoft and wasn't aware that he was doing Internet email stuff.

(Hi Keith!)

Keith

Date: Tue, 24 Nov 1998 11:10:05 +0900
From: Antony Bowesman <[email-masked]>
To: Brian Trenbeath <[email-masked]>
CC: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>
Subject: Re: Halloween/Message receipts
Sender: [email-masked]

I missed the discussion due to a long weekend however...

Brian Trenbeath wrote:
> 
> Outlook 98 was never meant to even try to be compliant with the MDN RFC. In
> fact, we
> consider it an unfortunate bug that Outlook 98 is even attempting to
> understand these
> headers as it is very obviously not compliant.
> 
> Outlook 2k, the next release of Outlook has fixed this bug, and is compliant
> with the
> RFC. We no longer send out TNEF'ed receipts in response to the MDN headers.
> In fact,
> the beta of Outlook 2k that recently was released is compliant to this RFC
> and has
> fixed this bug.

Good.  However, does that mean that the bug in Outlook 98 will remain
and continue to be shipped until O2k is released.  If that is the case
there will be a large installed base of non conformant clients throwing
these TNEF'd receipts onto the internet.  

Ned Freed wrote:
> 
> Alas, it looks like people are aren't following the rules laid down
> in the RFC, which makes makes this mechanism an accident waiting to
> happen, just like the ad-hoc things that preceeded it.

Is there a common mistake/misinterpretation in vendors' implementations
of the RFC?  I expect the Return-Path/DNT address match is a common one.

Pete Resnick wrote:
> 
> On 11/23/98 at 3:58 PM -0500, Keith Moore wrote:
> 
> > sounds like a good reason to declare the whole thing Experimental,
> > or maybe Historic...
> 
> Not to me. Just because people can screw it up does not mean that
> most will. We have massive experience with people screwing up SMTP,
> MIME, etc. The fact that we have plenty of good implementations means
> that we shouldn't be moving things to Experimental or Historic; to do
> so would just be reactionary.
> 
> Some of us are doing this right.

I agree.  It is a valuable extension and (hopefully) many of us are
doing it correctly.  In addition it gives a far better way for X.400 to
implement (N)RN in gateways as opposed to using RNR comments inside
recipient header which are not understood by Internet clients.

If the Outlook 98 buggy version continues to be shipped until O2k then
it appears this may have quite an effect on the standards review process
simply as a result of the installed base. 

Lastly, 

>To: "Keith Moore" <[email-masked]>

Are there two KM?  

Rgds
-- 
Antony Bowesman
[email-masked]

From: "Brian Trenbeath" <[email-masked]>
To: "Ned Freed" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>
Subject: RE: Halloween/Message receipts
Date: Mon, 23 Nov 1998 14:55:06 -0800
Importance: Normal
Sender: [email-masked]

My apologies for getting into this thread so late. (I am not on the mailing
list)

I'm a program manager at Microsoft on the Outlook product.

Outlook 98 was never meant to even try to be compliant with the MDN RFC. In
fact, we
consider it an unfortunate bug that Outlook 98 is even attempting to
understand these
headers as it is very obviously not compliant.

Outlook 2k, the next release of Outlook has fixed this bug, and is compliant
with the
RFC. We no longer send out TNEF'ed receipts in response to the MDN headers.
In fact,
the beta of Outlook 2k that recently was released is compliant to this RFC
and has
fixed this bug.

If you have any questions with regards to Outlook's support of this
protocol, please
feel free to send mail.

Brian Trenbeath
Outlook Program Manager

-----Original Message-----
From: Ned Freed [mailto:[email-masked]]
Sent: Monday, November 23, 1998 2:06 PM
To: Keith Moore
Cc: Pete Resnick; Keith Moore; Ned Freed; Paul Overell; [email-masked]
Subject: Re: Halloween/Message receipts

> > > sounds like a good reason to declare the whole thing Experimental,
> > > or maybe Historic...
> >
> > Not to me. Just because people can screw it up does not mean that
> > most will. We have massive experience with people screwing up SMTP,
> > MIME, etc. The fact that we have plenty of good implementations means
> > that we shouldn't be moving things to Experimental or Historic; to do
> > so would just be reactionary.

> This has the potential to cause a lot more harm than the typical
> screwed-up SMTP.... particularly if a huge portion of the installed
> base is polluted by the irresponsibility of a major vendor.

Basically I agree. This is why I didn't reject your (Keith's) call to move
this
mechanism to experimental or historic out of hand.

However, the bottom line is that all we need to do is follow the process.
When
the time comes to review this document with an eye to moving to draft (in,
say,
6-8 months), there is still demonstrable evidence of widely used products
shipping that don't follow the standard, then it will be clear that this
protocol, for whatever reason, does not interoperate satisfactorily. And at
that time a move to historical, not experimental, will be appropriate.

And we will have learned something -- specifically, that the mechanism which
if
memory serves Keith actually proposed, while technically adequate, isn't
practical from an implementation/deployment perspective.

I hope the folks at Microsoft who are responsible for this area of
non-compliance in their products are listening and understand what the
consequences of their continued non-compliance are likely to be.

				Ned

To: Ned Freed <[email-masked]>
Cc: [email-masked]
Subject: Re: Halloween/Message receipts 
From: [email-masked]
Date: Mon, 23 Nov 1998 17:38:06 -0500
Sender: [email-masked]

--==_Exmh_-1633084978P
Content-Type: text/plain; charset=us-ascii

On Mon, 23 Nov 1998 12:14:39 PST, you said:
> Alas, it looks like people are aren't following the rules laid down in the RFC,
> which makes makes this mechanism an accident waiting to happen, just like
> the ad-hoc things that preceeded it.

Is there a specific thing(s) that vendor(s) seem to be having trouble
doing correctly?  And are said vendors just screw-ups, or does their
logic/implementation deserve some consideration?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-1633084978P
Content-Type: application/pgp-signature

--==_Exmh_-1633084978P--

Date: Mon, 23 Nov 1998 14:06:13 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Halloween/Message receipts
To: Keith Moore <[email-masked]>
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Ned Freed <[email-masked]>, Paul Overell <[email-masked]>, [email-masked]
Sender: [email-masked]

> > > sounds like a good reason to declare the whole thing Experimental,
> > > or maybe Historic...
> >
> > Not to me. Just because people can screw it up does not mean that
> > most will. We have massive experience with people screwing up SMTP,
> > MIME, etc. The fact that we have plenty of good implementations means
> > that we shouldn't be moving things to Experimental or Historic; to do
> > so would just be reactionary.

> This has the potential to cause a lot more harm than the typical
> screwed-up SMTP.... particularly if a huge portion of the installed
> base is polluted by the irresponsibility of a major vendor.

Basically I agree. This is why I didn't reject your (Keith's) call to move this
mechanism to experimental or historic out of hand.

However, the bottom line is that all we need to do is follow the process. When
the time comes to review this document with an eye to moving to draft (in, say,
6-8 months), there is still demonstrable evidence of widely used products
shipping that don't follow the standard, then it will be clear that this
protocol, for whatever reason, does not interoperate satisfactorily. And at
that time a move to historical, not experimental, will be appropriate.

And we will have learned something -- specifically, that the mechanism which if
memory serves Keith actually proposed, while technically adequate, isn't
practical from an implementation/deployment perspective.

I hope the folks at Microsoft who are responsible for this area of
non-compliance in their products are listening and understand what the
consequences of their continued non-compliance are likely to be.

				Ned

Date: Mon, 23 Nov 1998 14:01:11 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Halloween/Message receipts
To: Keith Moore <[email-masked]>
Cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>, Paul Overell <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Alas, it looks like people are aren't following the rules laid down in
> > the RFC, which makes makes this mechanism an accident waiting to happen,
> > just like the ad-hoc things that preceeded it.

> sounds like a good reason to declare the whole thing Experimental, or maybe
> Historic...

Speaking as a co-chair of the RECEIPT WG, I'm not ready to do that just yet.
But I think it is important that implementors understand that the IETF is
serious about interoperability in general and this issue in particular, and
that if enough widely used implementations fail to conform to the standard they
are likely to lose their shot at having a standardized mechanism.

It's not like the participants in this effort weren't warned...

				Ned

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, Ned Freed <[email-masked]>, Paul Overell <[email-masked]>, [email-masked]
Subject: Re: Halloween/Message receipts 
Date: Mon, 23 Nov 1998 16:11:04 -0500
Sender: [email-masked]

> > sounds like a good reason to declare the whole thing Experimental, 
> > or maybe Historic...
> 
> Not to me. Just because people can screw it up does not mean that 
> most will. We have massive experience with people screwing up SMTP, 
> MIME, etc. The fact that we have plenty of good implementations means 
> that we shouldn't be moving things to Experimental or Historic; to do 
> so would just be reactionary.

This has the potential to cause a lot more harm than the typical
screwed-up SMTP.... particularly if a huge portion of the installed 
base is polluted by the irresponsibility of a major vendor.

Keith

Date: Mon, 23 Nov 1998 15:07:47 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Halloween/Message receipts
Cc: Ned Freed <[email-masked]>, Keith Moore <[email-masked]>, Paul Overell <[email-masked]>, [email-masked]
Sender: [email-masked]

On 11/23/98 at 3:58 PM -0500, Keith Moore wrote:

>> Alas, it looks like people are aren't following the rules laid 
>> down in the RFC, which makes makes this mechanism an accident 
>> waiting to happen, just like the ad-hoc things that preceeded it.
>
> sounds like a good reason to declare the whole thing Experimental, 
> or maybe Historic...

Not to me. Just because people can screw it up does not mean that 
most will. We have massive experience with people screwing up SMTP, 
MIME, etc. The fact that we have plenty of good implementations means 
that we shouldn't be moving things to Experimental or Historic; to do 
so would just be reactionary.

Some of us are doing this right.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Keith Moore <[email-masked]>, Paul Overell <[email-masked]>, [email-masked]
Subject: Re: Halloween/Message receipts 
Date: Mon, 23 Nov 1998 15:58:17 -0500
Sender: [email-masked]

> Alas, it looks like people are aren't following the rules laid down in 
> the RFC, which makes makes this mechanism an accident waiting to happen, 
> just like the ad-hoc things that preceeded it.

sounds like a good reason to declare the whole thing Experimental, or maybe
Historic...

Keith

Date: Mon, 23 Nov 1998 12:14:39 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Halloween/Message receipts
To: Keith Moore <[email-masked]>
Cc: Paul Overell <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Or does the DNT header predate MDN?

> nope.

More generally, there are plenty of ad-hoc read receipt headers in use,
including:

   X-PMrqc:
   Read-receipt-to:
   X-Confirm-reading-to:
   Return-receipt-to: (most systems treat this as a delivery receipt request,
                       but not all)
   Return-receipt-requested: (same issues as return-receipt-to:)
   Registered-mail-reply-requested-by: (my personal favorite)

Although the RECEIPT WG could have reused some previously employed ad-hoc
field, we very deliberately chose to avoid existing fields on the grounds that
the semantics we wanted were quite different than any previous field was given.
We wanted a new field nobody had used before so we could get the semantics
right. And we were very careful to spell out the semantics in the RFC.

Alas, it looks like people are aren't following the rules laid down in the RFC,
which makes makes this mechanism an accident waiting to happen, just like
the ad-hoc things that preceeded it.

				Ned

From: "David Lemson (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Larry Osterman (Exchange)" <[email-masked]>
Cc: IETF-822 <[email-masked]>, MIME <[email-masked]>
Subject: RE: Halloween/Message receipts 
Date: Mon, 23 Nov 1998 09:45:00 -0800
Sender: [email-masked]

It's documented in MSDN.  This link opens up the top level of it for me:
http://premium.microsoft.com/msdn/library/sdkdoc/mapi/apptnef_1cv3.htm
It's kind of messy, you have to do "Show in frames", then go up one level.

Additionally, a friend of mine (from school, before I came to work for
Microsoft :-) wrote a portable TNEF parser.  He also has some documentation
that he got from Microsoft about it contained within the package.  Here's a
pointer:

http://www.fiction.net/blong/programs/#tnef2txt

David Lemson
Microsoft Exchange Product Group

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 23, 1998 6:50 AM
To: Larry Osterman (Exchange)
Cc: IETF-822; MIME
Subject: Re: Halloween/Message receipts 

On Fri, 20 Nov 1998 10:59:32 PST, you said:
> It is certainly the case that TNEF isn't standard (although it IS
> documented), but again, there was no standard (or proposed standard) for

Oh? Where is it documented?  I have an MUA that could be extended to
support these (if only to present it better than "this is an
application/tnef,
save or discard?"...).  Could said documentation be overhauled into
an Informational RFC?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

From: Keith Moore <[email-masked]>
To: Paul Overell <[email-masked]>
cc: [email-masked]
Subject: Re: Halloween/Message receipts 
Date: Mon, 23 Nov 1998 11:08:17 -0500
Sender: [email-masked]

> Or does the DNT header predate MDN? 

nope.  

Keith

To: "Larry Osterman (Exchange)" <[email-masked]>
Cc: IETF-822 <[email-masked]>, MIME <[email-masked]>
Subject: Re: Halloween/Message receipts 
From: [email-masked]
Date: Mon, 23 Nov 1998 09:49:32 -0500
Sender: [email-masked]

--==_Exmh_869414520P
Content-Type: text/plain; charset=us-ascii

On Fri, 20 Nov 1998 10:59:32 PST, you said:
> It is certainly the case that TNEF isn't standard (although it IS
> documented), but again, there was no standard (or proposed standard) for

Oh? Where is it documented?  I have an MUA that could be extended to
support these (if only to present it better than "this is an application/tnef,
save or discard?"...).  Could said documentation be overhauled into
an Informational RFC?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_869414520P
Content-Type: application/pgp-signature

--==_Exmh_869414520P--

Date: Mon, 23 Nov 1998 10:11:12 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: Halloween/Message receipts
Sender: [email-masked]

In article <01D6C7224936D211BA450000F805D5388988A9@TOTO>, Larry Osterman
(Exchange) <[email-masked]> writes
>Outlook operates in two different modes - Corporate or Internet.  I can't
>speak for the Internet support, I don't work on that team, but I CAN talk
>about the corporate mode.
>
>In the corporate mode, Outlook uses Exchange server to provide it's internet
>native content, which is done internally in the message store, so Exchange
>is responsible for creating read receipts, etc.  Currently there is no
>support in Exchange for MDNs, so it can't be faulted for not producing valid
>MDNs.  Please don't think this is a case of perverting the standard either.
>The exchange support for read receipts predates MDN's by several years - we
>cannot follow standards that do not exist.

Outlook does pervert the MDN standard, RFC 2298, because it responds to
the Disposition-Notification-To: header with a proprietary format return
receipt.

If it does not support MDNs then is should ignore DNT, which (as far as
I am aware) was only defined by the MDN standard.

Or does the DNT header predate MDN? 

Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd

From: "Larry Osterman (Exchange)" <[email-masked]>
To: "'Antony Bowesman'" <[email-masked]>, IETF-822 <[email-masked]>, MIME <[email-masked]>
Subject: RE: Halloween/Message receipts
Date: Fri, 20 Nov 1998 10:59:32 -0800
Sender: [email-masked]

Outlook operates in two different modes - Corporate or Internet.  I can't
speak for the Internet support, I don't work on that team, but I CAN talk
about the corporate mode.

In the corporate mode, Outlook uses Exchange server to provide it's internet
native content, which is done internally in the message store, so Exchange
is responsible for creating read receipts, etc.  Currently there is no
support in Exchange for MDNs, so it can't be faulted for not producing valid
MDNs.  Please don't think this is a case of perverting the standard either.
The exchange support for read receipts predates MDN's by several years - we
cannot follow standards that do not exist.  Instead, we implemented read
receipts/non read receipts in our TNEF encapsulation layer (also known as
application/ms-tnef).  Exchange WILL correctly support MDNs in a future
release, it's just not in the current product.

It is certainly the case that TNEF isn't standard (although it IS
documented), but again, there was no standard (or proposed standard) for
transmitting rich text and embedded graphics in a message at the time it was
first deployed (1995).

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 98 and
Exchange Server 5.5.  Please notify the sender of any difficulties

-----Original Message-----
From: Antony Bowesman [mailto:[email-masked]]
Sent: Sunday, November 22, 1998 12:29 AM
To: IETF-822; MIME
Subject: Halloween/Message receipts

Something that comes close to the accusations made about the recent
Halloween report is the Outlook 98 support for
Message-Disposition-Notification to MIME header.

It seems that a proprietary format message is returned
(application/ms-tnef) with along with well known 'winmail.dat' which of
course not many people can read and plenty has been written about on the
web.  Does anyone know if Outlook can configured to produce
multipart/report MDNs?

Of all the possible implementations of MDN available it does seem that
the most 'hard-for-other' was chosen.

Now there is a choice for gateways/non ms mailers.

* Write something to understand ms-tnef winmail.dat and
  decode/understand whatever the content happens to be.
* Discard all application/ms-tnef bodies with appripriately
  labelled subjects
* Explain to the support organisation how to answer support
  calls saying they can't read their mail item.

None of the above are particularly satisfactory.  MS have plenty of X-
headers to indicate the originating mailer is an MS product so it's
surprising, to say the least, that they return tnef receipts in the
obvious knowledge that they will be meaningless to the receiver.

I suppose there is a fourth option.

MAIL FROM: <>
RCPT TO: <[email-masked]>

 :)

Rgds
-- 
Antony Bowesman
[email-masked]

Date: Fri, 20 Nov 1998 09:40:11 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: Halloween/Message receipts
Sender: [email-masked]

In article <[email-masked]>, Antony Bowesman
<[email-masked]> writes
>Something that comes close to the accusations made about the recent
>Halloween report is the Outlook 98 support for
>Message-Disposition-Notification to MIME header.
>
>It seems that a proprietary format message is returned
>(application/ms-tnef) with along with well known 'winmail.dat' which of
>course not many people can read and plenty has been written about on the
>web.  Does anyone know if Outlook can configured to produce
>multipart/report MDNs?
>
>Of all the possible implementations of MDN available it does seem that
>the most 'hard-for-other' was chosen.
>

Agreed, when we implemented MDNs for our MUA we immediately came across
this problem.  Also Outlook fails to observe the rule than an MDN should
not be sent automatically if the DSN address differs from the Return-
Path, this causes problems of multiple MDN flooding if a DSN is sent to
a mailing list.

>Now there is a choice for gateways/non ms mailers.
>
>* Write something to understand ms-tnef winmail.dat and
>  decode/understand whatever the content happens to be.

This was the solution we chose as being the most customer friendly.

>* Discard all application/ms-tnef bodies with appripriately
>  labelled subjects
>* Explain to the support organisation how to answer support
>  calls saying they can't read their mail item.
>
>None of the above are particularly satisfactory.  MS have plenty of X-
>headers to indicate the originating mailer is an MS product so it's
>surprising, to say the least, that they return tnef receipts in the
>obvious knowledge that they will be meaningless to the receiver.
>
>I suppose there is a fourth option.
>
>MAIL FROM: <>
>RCPT TO: <[email-masked]>
>
> :)
>
>

When we came across this problem we raised it in some Microsoft
newsgroups and got a positive response from an MVP and believe that the
problem is being addressed.

Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd

Date: Sun, 22 Nov 1998 17:29:02 +0900
From: Antony Bowesman <[email-masked]>
To: IETF-822 <[email-masked]>, MIME <[email-masked]>
Subject: Halloween/Message receipts
Sender: [email-masked]

Something that comes close to the accusations made about the recent
Halloween report is the Outlook 98 support for
Message-Disposition-Notification to MIME header.

It seems that a proprietary format message is returned
(application/ms-tnef) with along with well known 'winmail.dat' which of
course not many people can read and plenty has been written about on the
web.  Does anyone know if Outlook can configured to produce
multipart/report MDNs?

Of all the possible implementations of MDN available it does seem that
the most 'hard-for-other' was chosen.

Now there is a choice for gateways/non ms mailers.

* Write something to understand ms-tnef winmail.dat and
  decode/understand whatever the content happens to be.
* Discard all application/ms-tnef bodies with appripriately
  labelled subjects
* Explain to the support organisation how to answer support
  calls saying they can't read their mail item.

None of the above are particularly satisfactory.  MS have plenty of X-
headers to indicate the originating mailer is an MS product so it's
surprising, to say the least, that they return tnef receipts in the
obvious knowledge that they will be meaningless to the receiver.

I suppose there is a fourth option.

MAIL FROM: <>
RCPT TO: <[email-masked]>

 :)

Rgds
-- 
Antony Bowesman
[email-masked]

Date: Thu, 19 Nov 1998 18:56:46 +0100
To: Laurence Lundblade <[email-masked]>, Ashley Yakeley <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: text/*
Cc: "IETF-822 List" <[email-masked]>, IETF working group on HTML in e-mail <[email-masked]>
Sender: [email-masked]

At 17.39 +0100 98-11-09, Laurence Lundblade wrote:
> Yes, it would seem the good to see the raw HTML in place of nothing, but
> there are still a few problems:
>
> Your average user will still hate it and complain to the MUA vendor. For
> them it seems that the MUA is broken. I think we should be designing MUAs
> for folks that are totally non-technical these days and showing HTML to
> them is really quite bad. A more suitable option would be have a dialog box
> explaining the situation and then offering to display the raw HTML. Or
> better yet, strip the HTML down to plain text, or provide a hand-off to the
> browser (easier said than done because of imbedded images and such). In
> practice I think any modern MUA that doesn't at least make a modest attempt
> displaying HTML is a bit out of date.

Most implementations of HTML in e-mail use the
Content-Type:Multipart/alternative with plain text as the
first choice, and HTML or Multipart/related containing HTML
as the second choice. This seems like another option for
doing what you are asking for.

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

Date: Tue, 17 Nov 1998 16:36:03 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Updated Format=Flowed Draft
Sender: [email-masked]

I've just sent in version -02 of the Format=Flowed draft.  There are 
two changes from version -01:
	-  Reworded Q-P prohibition again.
	-  Added section on digital signatures and encryption

If anyone wants a copy before it shows up in the I-D directories, you 
can get it at 
<ftp://ftp.pensive.org/Public/Randy/draft-gellens-format-02.txt>.

Date: Tue, 10 Nov 1998 10:30:17 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: draft-gellens-format-01 and qp generation
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Thu, 5 Nov 1998, Ian Bell wrote:
> From draft-gellens-format-01.txt
> >   If Quoted-Printable is used, it SHOULD NOT be used to protect the
> >   trailing space. 
> .
> .
> >   the safer course is to not protect the trailing spaces unless the
> >   body part is cryptographically signed.
> 
> This overrides RFC2045 (where trailing spaces MUST be protected or
> deleted when generating qp, and must be deleted when removing qp).

I had forgotten the rule in RFC 2045 about deleting trailing spaces when
decoding qp.  Given that rule, we need to remove the sentence about not
using quoted-printable to protect the trailing space.  Thanks for catching
this.

> >   The intent of Format=Flowed is to allow user agents to generate
> >   flowed text which is non-obnoxious when viewed as pure Text/Plain;
> >   use of Quoted-Printable hinders this and may cause Format=Flowed to
> >   be rejected by end users.
> 
> QP does not hinder the stated intent when sent to MIME-capable MUAs, it
> is only when QP is sent to non-MIME recipients that problems arise. 

True.

> Perhaps the wording should be aimed at dissuading MUAs from using qp
> when the recipients' MUAs are not known to support MIME. This would be a
> good thing in itself, but almost certainly a lost cause :-(

The rules I'd go for are:

* if the text is 7-bit use CTE 7bit instead of QP.  Don't worry about
"From " or trailing whitespace or similar things.

* if a client supports 8-bit text, it should use ESMTP 8BITMIME and CTE
8bit in preference to QP.

		- Chris

Date: Tue, 10 Nov 1998 10:38:27 -0500 (EST)
From: Nathaniel Borenstein <[email-masked]>
Reply-To: Nathaniel Borenstein <[email-masked]>
To: Laurence Lundblade <[email-masked]>, Steve Dorner <[email-masked]>
Subject: Re: text/*
CC: Ashley Yakeley <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

Excerpts from bulk.interesting.lists: 9-Nov-98 Re: text/* Steve
[email-masked] (557*)

> At 8:39 AM -0800 11/9/98, Laurence Lundblade wrote:
> > I do think it would be nice to have a top level type that meant: this is 
> > probably text you can look at and make sense of if you don't have an 
> > application that is willing to display it for you. The MUA 
> > implementations would then present the entity as an attachment or 
> > similar, but offer to display it if the user wants.

> This is approximately the behavior of text/not{plain,html,enriched} 
> nowadays, contrary to the spec.  Maybe we should just give up and say this 
> is the correct behavior.

This makes sense to me.  But perhaps we should just say that it's an
*acceptable* behavior.

Excerpts from bulk.interesting.lists: 9-Nov-98 Re: text/* Laurence
Lundblade@qualc (786*)

> I thought about that, but it would cause all the applications that do it 
> correctly now to be out of spec, and it would probably recycle the RFC's to 
> proposed..

Maybe not, if there were *two* acceptable semantics -- the old and the
new.  Personally, I think both behaviors are basically acceptable.  --
Nathaniel
--------
Nathaniel Borenstein <[email-masked]> 
http://guppylake.com/~nsb/nsb-faq.html

Date: Mon, 9 Nov 1998 10:28:37 -0800
To: Steve Dorner <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: text/*
Cc: Ashley Yakeley <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

I thought about that, but it would cause all the applications that do it 
correctly now to be out of spec, and it would probably recycle the RFC's to 
proposed..

LL

At 11:54 AM -0600 11/9/98, Steve Dorner wrote:
> At 8:39 AM -0800 11/9/98, Laurence Lundblade wrote:
>> I do think it would be nice to have a top level type that meant: this is 
>> probably text you can look at and make sense of if you don't have an 
>> application that is willing to display it for you. The MUA 
>> implementations would then present the entity as an attachment or 
>> similar, but offer to display it if the user wants.
>
> This is approximately the behavior of text/not{plain,html,enriched} 
> nowadays, contrary to the spec.  Maybe we should just give up and say 
> this is the correct behavior.

Date: Mon, 9 Nov 1998 11:54:21 -0600
To: Laurence Lundblade <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: text/*
Cc: Ashley Yakeley <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 8:39 AM -0800 11/9/98, Laurence Lundblade wrote:
> I do think it would be nice to have a top level type that meant: this is 
> probably text you can look at and make sense of if you don't have an 
> application that is willing to display it for you. The MUA 
> implementations would then present the entity as an attachment or 
> similar, but offer to display it if the user wants.

This is approximately the behavior of text/not{plain,html,enriched} 
nowadays, contrary to the spec.  Maybe we should just give up and say this 
is the correct behavior.

Date: Mon, 9 Nov 1998 08:39:34 -0800
To: Ashley Yakeley <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: text/*
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 3:10 PM -0800 11/2/98, Ashley Yakeley wrote:
>At 1998-11-02 08:54, Laurence Lundblade wrote:
>
>>To me the top level types are very rough groupings based on some common
>>default treatment we want applied to them. For example multipart/xxx
>>defaults to multipart/mixed, a rule that's widely implemented correctly.
>>Text/xxx was supposed to default to text/plain, but since the registration
>>of text/html (very unreadable to humans) most MUAs have stopped display
>>text/xxxx by default.
>
>I disagree with you about the readability of text/html: I'd far rather
>see a message in raw HTML than not see it all. I think that's the idea
>behind text/*.
>
>Now with the rise of HTTP browsers that can read HTML, but mail UAs that
>cannot, the question 'can you interpret HTML' no longer has a trivial
>answer, and saving HTML to a file (where it can be read by a browser)
>becomes a reasonable action for a mail UA.
>
>But I doubt it would make much difference. Much as we all might
>disapprove, I'm sure Netscape et al. would still allow users to generate
>HTML in mail messages no matter what its top-level type is.

Yes, it would seem the good to see the raw HTML in place of nothing, but 
there are still a few problems:

Your average user will still hate it and complain to the MUA vendor. For 
them it seems that the MUA is broken. I think we should be designing MUAs 
for folks that are totally non-technical these days and showing HTML to 
them is really quite bad. A more suitable option would be have a dialog box 
explaining the situation and then offering to display the raw HTML. Or 
better yet, strip the HTML down to plain text, or provide a hand-off to the 
browser (easier said than done because of imbedded images and such). In 
practice I think any modern MUA that doesn't at least make a modest attempt 
displaying HTML is a bit out of date.

I think the user complaints and plain ugliness of HTML is what has caused 
MUAs to not default text/xxxx to text/plain correctly. We can argue about 
the readability of HTML all we want, but we're not going to change the 
behavior of these extent MUAs. The result for standards folks and 
implementors is that we can't count on this rule anymore.

>>I guess for text/* the rules these days amount to this:
>>
>>1) Does it look OK when splatted directly to the screen of a VT100
>>
>>2) Are you willing to let it occasionally be treated like an attachment by
>>mal-conforming MUAs.
>>
>>and
>>
>>3) If you don't like 2 and want to use a parameter, can you convince the
>>standards folks that your type is OK to be identified just by a parameter
>>to text/plain.
>
>If you're willing to be liberal about 'OK' in 1, I'd agree with you. For
>instance. I think the registrations of SGML and XML in both text and
>application was appropriate, since some SGML/XML is sufficiently
>'text-like' to be worth showing plain when there's no alternative, and
>some is not.

Personally I'm not that liberal about it, because I don't think anything 
but very very basic stuff will "play in Peoria". If users see formatting 
that was clearly not intended for humans they will be unhappy and complain. 
We've seen this with quoted-printable encoding, text/enriched and text/html 
and this complaining has been going on for about ten years (when QP was 
introduced).

But as I said before, enough MUA vendors have voted with their 
implementations and we're now at the point where it doesn't really matter. 
You can't count on any particular defaulting behavior for text/xxxx.

I do think it would be nice to have a top level type that meant: this is 
probably text you can look at and make sense of if you don't have an 
application that is willing to display it for you. The MUA implementations 
would then present the entity as an attachment or similar, but offer to 
display it if the user wants.

LL

Date: 06 Nov 1998 22:27:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: text/*
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] (Ashley Yakeley)  wrote on 02.11.98 in <[email-masked]>:

> At 1998-11-02 08:54, Laurence Lundblade wrote:
>
> >To me the top level types are very rough groupings based on some common
> >default treatment we want applied to them. For example multipart/xxx
> >defaults to multipart/mixed, a rule that's widely implemented correctly.
> >Text/xxx was supposed to default to text/plain, but since the registration
> >of text/html (very unreadable to humans) most MUAs have stopped display
> >text/xxxx by default.
>
> I disagree with you about the readability of text/html: I'd far rather
> see a message in raw HTML than not see it all. I think that's the idea
> behind text/*.

Well yes, and I'd far rather not see a message at all, than see a message  
in raw HTML.

And yes, I do mean every word of this. With extremely few exceptions (in  
fact, I can't think of any exception right now), I will refuse to even try  
to read raw HTML messages.

MfG Kai

Date: Thu, 5 Nov 1998 15:09:45 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: draft-gellens-format-01 and qp generation
Sender: [email-masked]

>From draft-gellens-format-01.txt

>   [Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed
>   unless absolutely necessary (for example, non-US-ASCII 8-bit
>   characters over a strictly 7-bit transport such as unextended SMTP).
>   If Quoted-Printable is used, it SHOULD NOT be used to protect the
>   trailing space. 
.
.
>   the safer course is to not protect the trailing spaces unless the
>   body part is cryptographically signed.

This overrides RFC2045 (where trailing spaces MUST be protected or
deleted when generating qp, and must be deleted when removing qp).

This means that an MUA wishing to support format=flowed would have to
consider the media type before removing the transfer-encoding. It would
also have to consider the context of the text part - whether or not it
has been digitally signed.

It is surely a serious and unacceptable layer-violation to make an MUA
consider how a MIME part is going to be dealt with before it can decide
how to remove a transfer-encoding.

>   The intent of Format=Flowed is to allow user agents to generate
>   flowed text which is non-obnoxious when viewed as pure Text/Plain;
>   use of Quoted-Printable hinders this and may cause Format=Flowed to
>   be rejected by end users.

QP does not hinder the stated intent when sent to MIME-capable MUAs, it
is only when QP is sent to non-MIME recipients that problems arise. 

Perhaps the wording should be aimed at dissuading MUAs from using qp
when the recipients' MUAs are not known to support MIME. This would be a
good thing in itself, but almost certainly a lost cause :-(

-- 
Ian Bell                                           T U R N P I K E  Ltd

Subject: Re: text/*
Date: Mon, 2 Nov 1998 15:10:45 -0800
From: Ashley Yakeley <[email-masked]>
To: "Laurence Lundblade" <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-11-02 08:54, Laurence Lundblade wrote:

>To me the top level types are very rough groupings based on some common 
>default treatment we want applied to them. For example multipart/xxx 
>defaults to multipart/mixed, a rule that's widely implemented correctly. 
>Text/xxx was supposed to default to text/plain, but since the registration 
>of text/html (very unreadable to humans) most MUAs have stopped display 
>text/xxxx by default.

I disagree with you about the readability of text/html: I'd far rather 
see a message in raw HTML than not see it all. I think that's the idea 
behind text/*.

Now with the rise of HTTP browsers that can read HTML, but mail UAs that 
cannot, the question 'can you interpret HTML' no longer has a trivial 
answer, and saving HTML to a file (where it can be read by a browser) 
becomes a reasonable action for a mail UA.

But I doubt it would make much difference. Much as we all might 
disapprove, I'm sure Netscape et al. would still allow users to generate 
HTML in mail messages no matter what its top-level type is.

>I guess for text/* the rules these days amount to this:
>
>1) Does it look OK when splatted directly to the screen of a VT100
>
>2) Are you willing to let it occasionally be treated like an attachment by 
>mal-conforming MUAs.
>
>and
>
>3) If you don't like 2 and want to use a parameter, can you convince the 
>standards folks that your type is OK to be identified just by a parameter 
>to text/plain.

If you're willing to be liberal about 'OK' in 1, I'd agree with you. For 
instance. I think the registrations of SGML and XML in both text and 
application was appropriate, since some SGML/XML is sufficiently 
'text-like' to be worth showing plain when there's no alternative, and 
some is not.

-- 
Ashley Yakeley, Seattle WA

Date: Mon, 2 Nov 1998 08:54:24 -0800
To: Ashley Yakeley <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: text/*
Cc: "Steve Dorner" <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 4:50 PM -0800 10/30/98, Ashley Yakeley wrote:
>
>
>I maintain that you're holding a far higher standard of readability than
>that implied by RFC 2046.

At this point the issue is probably whether clients will do what you want 
with it. Text/paragraph is much preferred to to format=flowed (I think) for 
semantic purity, but the mail clients don't what we want with it.

To me the top level types are very rough groupings based on some common 
default treatment we want applied to them. For example multipart/xxx 
defaults to multipart/mixed, a rule that's widely implemented correctly. 
Text/xxx was supposed to default to text/plain, but since the registration 
of text/html (very unreadable to humans) most MUAs have stopped display 
text/xxxx by default.

I guess for text/* the rules these days amount to this:

1) Does it look OK when splatted directly to the screen of a VT100

2) Are you willing to let it occasionally be treated like an attachment by 
mal-conforming MUAs.

and

3) If you don't like 2 and want to use a parameter, can you convince the 
standards folks that your type is OK to be identified just by a parameter 
to text/plain.

LL