Subject: Re: multipart/signed and QP - is this a dumb idea, or a good one?
From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Date: Tue, 27 Jun 2000 15:01:40 -0400
List-Id: <ietf-822.imc.org>

> Trailing blanks are significat for text/plain;format=flowed (RFC 2646).

good point.  

but perhaps that just illustrates my point - when generating format=flowed 
from typed-in text, you want to delete any trailing blanks typed in by
the user, so they won't be confused with trailing blanks that indicate
soft line breaks.

Keith

Date: Tue, 27 Jun 2000 20:11:14 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: multipart/signed and QP - is this a dumb idea, or a good one?
Sender: [email-masked]

At 11.42 -0400 0-06-27, Keith Moore wrote:
> in general, I find it useful to delete trailing blanks *before* applying
> quoted-printable (for typed-in text, not attachments) so that
> the quoted-printable encoding is readable on non-MIME UAs.

Trailing blanks are significat for text/plain;format=flowed (RFC 2646).
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: multipart/signed and QP - is this a dumb idea, or a good one? 
Date: Tue, 27 Jun 2000 11:42:51 -0400
Sender: [email-masked]

> Would it be a Good Thing for Exmh to scan for known "problem sequences"
> such as trailing blanks in a text/plain, and if found, force a QP CTE
> so the list software isn't as likely to mangle things?

in general, I find it useful to delete trailing blanks *before* applying
quoted-printable (for typed-in text, not attachments) so that 
the quoted-printable encoding is readable on non-MIME UAs.

so maybe the best exmh solution is to provide an option to delete
trailing blanks (etc) before signing.

Keith

From: [email-masked]
To: [email-masked]
Subject: multipart/signed and QP - is this a dumb idea, or a good one?
Date: Tue, 27 Jun 2000 10:06:46 -0400
Sender: [email-masked]

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

I'm one of the people maintaining the Exmh MUA, and was recently fixing up
the PGP support.  One of the things that I noticed was that quite often,
various list processor software would seriously break the PGP signature.
The failure mode is that the text/plain is sent out with a '7bit' CTE,
the list software trims trailing blanks or expands tabs, thus breaking the
signature.

Would it be a Good Thing for Exmh to scan for known "problem sequences"
such as trailing blanks in a text/plain, and if found, force a QP CTE
so the list software isn't as likely to mangle things?  Or are there still
enough "I hate seeing =20 in my mail" non-MIME people out there?

(Of course, if they're seeing the =20 in their mail, they're probably going
to be equally torqued off by the fact there's a digital signature attached ;)

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

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

--==_Exmh_754161160P--

Reply-To: "Salus Financial" <[email-masked]>
From: "Salus Financial" <[email-masked]>
To: <Undisclosed-Recipient:@tot-ti.proxy.aol.com;;>
Subject: The Insurance Professionals
Date: Wed, 21 Jun 2000 14:37:06 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00A8_01BFDB8E.2CCAF240
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00A9_01BFDB8E.2CD29360"

------=_NextPart_001_00A9_01BFDB8E.2CD29360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
=20

=20

=20

=20

Few of us are prepared for the financial burdens that can threaten both =
our lifestyle and our security

=20

=B7        Convalescence

=B7        Private nursing costs

=B7        Reduction or permanent loss of income

=B7        A change of profession

=B7        Child care

=B7        Medical equipment or home refitting

=B7        Mortgage and other debt payments

=B7         Relocation of your home to a warmer climate etc etc..

If any of these strikes
Will your finances survive?

=20

                                                            =20

=20

There is a new way of protecting yourself against the high cost of =
rebuilding your lifestyle following critical illness.  Picture receiving =
$100,000 or $250,000 tax-free lump-sum to help towards recovery, =
maintaining your lifestyle or saving your business.

And it's something every Canadian should know about
 Fax (604) 647-0631 or return this email today for more information

------=_NextPart_001_00A9_01BFDB8E.2CD29360
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2722.2800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>&nbsp;
<P class=3DMsoBodyText><SPAN=20
style=3D"POSITION: relative; mso-ignore: vglayout"><SPAN=20
style=3D"HEIGHT: 122px; LEFT: -6px; POSITION: absolute; TOP: -4px; =
WIDTH: 580px"><IMG=20
alt=3D"Text Box: It&#8217;s a fact that one out of every three Canadians =
will contract a life-altering illness during his or her lifetime"=20
height=3D122 src=3D"cid:00a501bfdbc8$d9083880$2a7e9bac@suzannejacob" =
width=3D580=20
v:shapes=3D"_x0000_s1027"></SPAN></SPAN><B><SPAN=20
style=3D"COLOR: fuchsia; FONT-FAMILY: 'PC =
Brussels'">&nbsp;<?xml:namespace prefix=20
=3D o ns =3D "urn:schemas-microsoft-com:office:office" =
/><o:p></o:p></SPAN></B></P>
<P class=3DMsoBodyText><B><SPAN=20
style=3D"COLOR: fuchsia; FONT-FAMILY: 'PC =
Brussels'">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=3DMsoBodyText><B><SPAN=20
style=3D"COLOR: fuchsia">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal>&nbsp;<o:p></o:p></P>
<P class=3DMsoBodyTextIndent><SPAN style=3D"FONT-SIZE: 14pt">Few of us =
are prepared=20
for the financial burdens that can threaten both our lifestyle and our=20
security<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Symbol; FONT-SIZE: 12pt; =
mso-bidi-font-weight: bold">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: =
12pt">Convalescence<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Symbol; FONT-SIZE: 12pt; =
mso-bidi-font-weight: bold">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: 12pt">Private =
nursing=20
costs<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Symbol; FONT-SIZE: 12pt; =
mso-bidi-font-weight: bold">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: 12pt">Reduction =
or=20
permanent loss of income<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Symbol; FONT-SIZE: 12pt; =
mso-bidi-font-weight: bold">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: 12pt">A change =
of=20
profession<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Symbol; FONT-SIZE: 12pt; =
mso-bidi-font-weight: bold">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: 12pt">Child=20
care<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Symbol; FONT-SIZE: 12pt; =
mso-bidi-font-weight: bold">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: 12pt">Medical =
equipment or=20
home refitting<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Symbol; FONT-SIZE: 12pt; =
mso-bidi-font-weight: bold">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: 12pt">Mortgage =
and other=20
debt payments<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 1.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"FONT-FAMILY: Symbol; FONT-SIZE: 11pt">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><B><SPAN=20
style=3D"COLOR: #333399; FONT-FAMILY: Arial; FONT-SIZE: 12pt">Relocation =
of your=20
home to a warmer climate etc etc&#8230;.</SPAN></B><SPAN=20
style=3D"FONT-FAMILY: Arial; FONT-SIZE: 11pt"><o:p></o:p></SPAN></P>
<H1><SPAN style=3D"FONT-SIZE: 12pt">If any of these =
strikes<o:p></o:p></SPAN></H1>
<P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
16pt">Will=20
your finances survive?<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal><B><SPAN=20
style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
14pt">&nbsp;<o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal><SPAN style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
11pt"><IMG=20
height=3D104 src=3D"cid:00a601bfdbc8$d9083880$2a7e9bac@suzannejacob" =
width=3D104=20
v:shapes=3D"_x0000_i1025"></SPAN><B><SPAN=20
style=3D"FONT-FAMILY: Arial; FONT-SIZE: 14pt"><o:p></o:p></SPAN></B></P>
<P class=3DMsoNormal><SPAN=20
style=3D"POSITION: relative; Z-INDEX: 1; mso-ignore: vglayout"><SPAN=20
style=3D"HEIGHT: 170px; LEFT: 282px; POSITION: absolute; TOP: -157px; =
WIDTH: 388px"><IMG=20
alt=3D"Text Box: 3Heart =
Attack&#9;&#9;3Cancer&#13;&#10;3Stroke&#9;&#9;3Coronary Artery Bypass =
Surgery&#13;&#10;3Multiple Sclerosis&#9;3Alzheimer&#8217;s =
Disease&#13;&#10;3Parkinson&#8217;s Disease&#9;3Major Organ =
Transplant&#13;&#10;3Paralysis&#9;&#9;3Kidney =
Failure&#13;&#10;3Coma&#9;&#9;3Blindness&#13;&#10;3Severe Burns&#9;3Loss =
of Speech&#13;&#10;3Occupational HIV&#9;3Loss of =
Limbs&#13;&#10;&#9;&#9;&#9;3Deafness&#13;&#10;&#13;&#10;"=20
height=3D170 src=3D"cid:00a701bfdbc8$d90fd9a0$2a7e9bac@suzannejacob" =
width=3D388=20
v:shapes=3D"_x0000_s1026"></SPAN></SPAN><SPAN=20
style=3D"FONT-FAMILY: Arial; FONT-SIZE: 11pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
</SPAN><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
11pt">&nbsp;<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN style=3D"FONT-FAMILY: Arial; FONT-SIZE: =
12pt">There is a=20
new way of protecting yourself against the high cost of rebuilding your=20
lifestyle following critical illness.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>Picture receiving $100,000 or $250,000 tax-free lump-sum to help =
towards=20
recovery, maintaining your lifestyle or saving your=20
business.<o:p></o:p></SPAN></P>
<H2>And it&#8217;s something every Canadian should know about</H2>
<P class=3DMsoBodyText3><SPAN=20
style=3D"BACKGROUND: #333399; COLOR: white; FONT-SIZE: 12pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>Fax (604) 647-0631 or return =
this email=20
today for more information</SPAN><SPAN=20
style=3D"COLOR: white; FONT-SIZE: =
12pt"><o:p></o:p></SPAN></P></FONT></DIV></BODY></HTML>

------=_NextPart_001_00A9_01BFDB8E.2CD29360--

------=_NextPart_000_00A8_01BFDB8E.2CCAF240
Content-Type: image/gif;
	name="clip_image002.gif"
Content-Transfer-Encoding: base64
Content-ID: <00a501bfdbc8$d9083880$2a7e9bac@suzannejacob>

------=_NextPart_000_00A8_01BFDB8E.2CCAF240
Content-Type: image/jpeg;
	name="clip_image004.jpg"
Content-Transfer-Encoding: base64
Content-ID: <00a601bfdbc8$d9083880$2a7e9bac@suzannejacob>

------=_NextPart_000_00A8_01BFDB8E.2CCAF240
Content-Type: image/gif;
	name="clip_image005.gif"
Content-Transfer-Encoding: base64
Content-ID: <00a701bfdbc8$d90fd9a0$2a7e9bac@suzannejacob>

------=_NextPart_000_00A8_01BFDB8E.2CCAF240--

From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: Fw: Informal last call: Announcement of draft-murata-xml-06.txt
Date: Wed, 21 Jun 2000 01:11:20 +0900 (JST)
Lines: 77
Sender: [email-masked]

----Next_Part(Wed_Jun_21_01:11:03_2000_444)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear Colleagues,

A new Internet Draft for XML media types has been released.  
If we receive no comments, we will ask the IESG to 
publish it as a proposed standard.

Discussion about this I-D is done at the ietf-xml-mime mailing list.
Information about this mailing list is available at:

	http://www.imc.org/ietf-xml-mime/

Sincerely yours,

IBM Tokyo Research Lab
MURATA Makoto (FAMILY Given)

----Next_Part(Wed_Jun_21_01:11:03_2000_444)--
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit

From: [email-masked]
To: [email-masked]
Subject: Informal last call: Announcement of draft-murata-xml-06.txt
Date: Wed, 21 Jun 2000 00:39:36 +0900 (JST)
Lines: 24
Sender: [email-masked]

Simon St. Laurent, Dan Kohn, and I create a new I-D for XML media
types.  It is available at:

	http://www.ietf.org/internet-drafts/draft-murata-xml-06.txt

Differnces from the previous version are as below:
  - added descriptions of changes to RFC 2376. 
  - changed SHOULDs to MUSTs in the inconsistent example, section 8.20.

Major differences from RFC 2376 are as below:

      (1) the addition of text/xml-external-parsed-entity,
      application/xml-external-parsed-entity, and application/xml-dtd,

      (2) the '+xml' suffix convention (which also updates the RFC 2048
      registration process), and

      (3) the discussion of "utf-16le" and "utf-16be".

If we do not receive any comments, we will ask the IESG to consider
publication of this Internet-Draft as a Proposed Standard.

IBM Tokyo Research Lab
MURATA Makoto

----Next_Part(Wed_Jun_21_01:11:03_2000_444)----

From: MURATA Makoto <[email-masked]>
Date: Wed, 14 Jun 2000 11:41:21 +0900
To: [email-masked], [email-masked], [email-masked]
Subject: Fwd: Announcement of draft-murata-xml-05.txt
Sender: [email-masked]

Dear Colleagues,

A new Internet Draft for XML media types has been released.  
Please discuss about it at the ietf-xml-mime mailing list.  
Information about this mailing list is available at:

	http://www.imc.org/ietf-xml-mime/

Sincerely yours,

IBM Tokyo Research Lab
MURATA Makoto (FAMILY Given)

------------------------------------------
> Dan, Simon, and I created yet another I-D for XML media types.
> It is available at:
> 
> http://www.ietf.org/internet-drafts/draft-murata-xml-05.txt
> 
>    draft-murata-xml-05: added XML, MIME, and this document definitions
>    for entity.  Added new invalid example.  Fixed magic number by
>    adding "l" to UTF-16 examples.  Added IANA considerations.  Removed
>    extraneous notes. Made clear that examples are not registrations. 
>    Mention the standalone declaration.  Removed normative references to
>    XML Base, XLink, and XPointer, since they are still working drafts. 
>    Fragment identifiers are still undefined.  Mechanisms for embedding
>    the base URI are still undefined.  Strengthened and filled out
>    Referencing section, and moved to section 7.1.
> 
> We are looking forward to your feedbacks.
> 
> IBM Tokyo Research Lab
> MURATA Makoto
> 

From: [email-masked]
Date: Tue, 13 Jun 2000 06:59:23 -0700 (PDT)
Subject: Re: "Importance" and "Priority"
To: Jacob Palme <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> At 04.24 -0700 0-06-12, [email-masked] wrote:
> > The history of the precedence field is a pretty strong argument for
> > standardization, actually.

> When there is such a field already used, but in different ways
> by different mailers, it is often best to define a new field.
> Since both "Priority" and "Importance" already are standardized,
> but only for limited domains, it seems natural to extend what
> already exists.

Jacob, what I was saying is that the experience with the Precedence field,
which is now largely useless because of differing interpretations by
different implementations, shows why it standardization of such things is
a good idea. I was not advocating standardization of Precedence; that would
be a very bad idea.

And since much of what Precedence does is covered by other mechanisms now
I don't see a reason to move any of its functions to a new field either.

> I am not sure one should really distinguish between "Priority"
> and "Importance" in the way X.400 does. This distinction is not
> very clear. If my mailer sorts by incoming messages, one could
> argue that this should be based on "Priority" since this means
> that the messages will reach me faster, or based on "Importance"
> becuase sorting is a UA operation, not an MTA operation.

On the contrary, the difference is quite clear -- one is an envelope field that
acts on message routing and transport and has no effect on user agents, and the
other is a sorting indicator for user agents that has no effect on routing
and transport.

As I said before, opinions vary as to whether or not the user agent function is
worth having. But contrary to your previous assertions, there is considerable
customer demand for the sort of control over transport priority provides.

				Ned

Date: Tue, 13 Jun 2000 12:33:22 +0200
To: [email-masked], [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: "Importance" and "Priority"
Cc: [email-masked]
Sender: [email-masked]

At 04.24 -0700 0-06-12, [email-masked] wrote:
> The history of the precedence field is a pretty strong argument for
> standardization, actually.

When there is such a field already used, but in different ways
by different mailers, it is often best to define a new field.
Since both "Priority" and "Importance" already are standardized,
but only for limited domains, it seems natural to extend what
already exists.

I am not sure one should really distinguish between "Priority"
and "Importance" in the way X.400 does. This distinction is not
very clear. If my mailer sorts by incoming messages, one could
argue that this should be based on "Priority" since this means
that the messages will reach me faster, or based on "Importance"
becuase sorting is a UA operation, not an MTA operation.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: [email-masked]
Date: Mon, 12 Jun 2000 04:24:42 -0700 (PDT)
Subject: Re: "Importance" and "Priority"
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> What about the existing Precedance header, which is sometimes used? Is it
> defined in any RFC?

AFAIK, no.

> I observe that it does seem to have levels below
> normal, such as "bulk" and "junk".

And several other values. Unfortunately, the semantics of this field are quite
inconsistent across various implementations. It is sometimes seen as a sort of
priority field, sometimes as an indication that delay notifications should not
be returned, and sometimes as an indicatin that no notifications should be
returned. And the values that cause each of these results are inconsistent as
well.

The history of the precedence field is a pretty strong argument for
standardization, actually.

> Also, is there any use of such a header
> for saying "this is so unimportant that I do not want you to bother to
> tell me if it fails to get delivered"?

This is one of the functions of NOTARY, which does it using an SMTP
extension rather than a header field.

And as pointed out above, this is one of the various interpretations of
nonstandard precedence field as well.

> I am frequently annoyed by systems
> that are on some mailing list and tell everyone who posts to the list that
> their message was not received :-( .

This is really a different problem. Lists should redirect error returns to a
handling address by changing the MAIL FROM (envelope from), and MTAs and
delivery agents should respect this redirection. Unfortunately, there are a few
lists that don't do this when they should. And worse, there are a fair number
of agents that send error reports to the wrong address.

Most lists should suppress delay notifications using NOTARY, but suppression
of all nondelivery notifications isn't a good idea.

There is also a school of thought that says since problems with errors being
returned to the wrong address are fairly common, errors should be suppressed
for all but a small subset of list postings. 

				Ned

To: [email-masked]
Xref: clerew local.mime:419
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: "Importance" and "Priority"
Date: Mon, 12 Jun 2000 10:46:05 GMT
Lines: 37
Sender: [email-masked]

In <v04210116b5681ebb99de@[130.237.150.138]> Jacob Palme <[email-masked]> writes:

>RFC 2156 defines importance as:

>importance      = "low" / "normal" / "high"

>and priority as:

>priority        = "normal" / "non-urgent" / "urgent"

>The difference between these fields is not very clear
>from RFC 2156, but in X.400, priority is an envelope
>attribute, while importance is a heading attribute,
>so presumably priority is meant to be able to influence
>transmission. Existing Internet mailers, however, only
>seem to use these attributes in local mailers. Mail
>transmission today is so fast, that priority in
>transmission is probably not felt very much needed.

What about the existing Precedance header, which is sometimes used? Is it
defined in any RFC? I observe that it does seem to have levels below
normal, such as "bulk" and "junk". Also, is there any use of such a header
for saying "this is so unimportant that I do not want you to bother to
tell me if it fails to get delivered"? I am frequently annoyed by systems
that are on some mailing list and tell everyone who posts to the list that
their message was not received :-( .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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: [email-masked]
Xref: clerew local.mime:418
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Format=Flowed and CJK
Date: Mon, 12 Jun 2000 10:41:43 GMT
Lines: 29
Sender: [email-masked]

In <p04320405b569b0800819@[192.168.1.5]> Randall Gellens <[email-masked]> writes:

>There is a proposal to update the spec as follows:

If you are considering updates to this spec, then could you please also
put in a feature to retain whatever indentation existed in the original. I
explained to you before the present proposal was adopted that it could
easily be done within the spirit of the present system, but I had come
onto the scene too late in the process to influence what was being done at
that time.

I can put this idea into more detail if you like.

>1.  On generation, add SP CRLF where a soft line break is desired 
>following or preceding a CJK character.

Please will someone remind me what "CJK stands for, and also which RFC
contains the present proposal.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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: Sun, 11 Jun 2000 15:16:52 -0700
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Format=Flowed and CJK
Sender: [email-masked]

Currently, the F=F spec does not allow for languages where spaces are 
not normally used.

Not using F=F causes just as bad problems with poor line wrap and 
quotes in Japanese and other such languages as in English, I'm told.

There is a proposal to update the spec as follows:

1.  On generation, add SP CRLF where a soft line break is desired 
following or preceding a CJK character.

2.  If a space exists at the point where a soft line break is being 
added following or preceding a CJK character (i.e., the user typed a 
space) add an extra space: SP SP CRLF.

3.  On receiving, if you see 1*SP CRLF, and the character before the 
space(s) is CJK, or the character following the CRLF is CJK, delete 
one SP as well as the CRLF.

The problem with this is that when sending to current F=F clients, a 
space will be left between characters, which looks bad.  When sending 
to non-F=F clients, some lines will end in SP CRLF, which is not much 
of a problem.

A more fundamental problem is how to define CJK characters.

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

One alternate suggestion is to add TAB CRLF whenever a soft line 
break is desired at a point where no SP exists.  On reception, the 
TAB CRLF sequence is deleted.

When sending to all older clients (both non-F=F and current F=F) some 
lines will end in TAB CRLF.  This is worse than SP CRLF, since TAB is 
not always treated as white space.  TABs may cause output to be 
double-spaced in some situations.  I'm told that stray tabs in 
Japanese text is even worse than stray spaces.

A current F=F client could generate text with a TAB CRLF sequence at 
the end of a line, causing the words on either side to be run 
together if received by a new F=F client.

Some of these problems could be avoided by using a different Format 
value (e.g., "Format2") or an additional parameter (e.g., 
"Format=Flowed; Flowed-Version=2").

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

A third suggestion is to use SP SP CRLF whenever a soft line break is 
desired at a point where no SP exists.  On reception, the entire SP 
SP CRLF sequence is deleted.

When sending to current F=F clients, two spaces will be left between 
characters, which looks bad where spaces are unnatural.

When generating F=F, clients must be careful to not insert a soft 
line break at a point where the user wants two spaces (for example, 
following a sentence-ending period) because the end result would be 
only one space or no spaces, depending on which sequence was sent.

In addition, if a current F=F client sends text which is received by 
a new F=F client, the sequence SP SP CRLF could occur between words, 
resulting in no spaces at all between the words.

Some of these problems could be avoided by using a different Format 
value (e.g., "Format2") or an additional parameter (e.g., 
"Format=Flowed; Flowed-Version=2").

There is some additional complexity in counting trailing spaces on a line.

The current spec says any number of spaces at the end of a line mean 
the same thing.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I love the smell of excessive quoting in the morning.
                                         --Steve Dorner

From: [email-masked]
Date: Sun, 11 Jun 2000 11:32:05 -0700 (PDT)
Subject: Re: "Importance" and "Priority"
To: Jacob Palme <[email-masked]>
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

> Both

> 2421 Voice Profile for Internet Mail - version 2. G. Vaudreuil, G.
>      Parsons. September 1998. (Format: TXT=123663 bytes) (Obsoletes
>      RFC1911) (Status: PROPOSED STANDARD)

> and

> 2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400
>      and RFC 822/MIME. S. Kille. January 1998. (Format: TXT=280385 bytes)
>      (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495)
>      (Updates RFC0822) (Status: PROPOSED STANDARD)

> specify two useful e-mail header fields: "Sensitivity" and
> "Importance". RFC 2156 also has a related header field
> "Importance".

I think you meant to say "Priority", rather than repeating "Importance".
However, "Priority" isn't really related to the other two.

> Such fields are obviously felt important by several mailer
> developers, since they use various own headers for this,
> such as X-Priority (Eudora) or X-MSMail-Priority
> (Microsoft).

Correct, although whether these fields are intended to mean "Importance" or
"Priority" in the X.400 sense isn't clear to users -- I've seen both
interpretations demanded of the fields.

> As an e-mail user, I often send and get messages in which
> we do use the X-Priority heading, even though they only
> work between certain mailers, so this heading is also
> obviously felt useful by many people. Very few messages
> indicate a lower than normal priority, the usage is
> almost only to indicate a higher than normal priority
> for some messages.

It depends on what you think the fields mean and who you talk to. If, for
example, you think the fields are equivalent to X.400 "Importance", and thus
mean "how important the message sender thinks the message is", then I for one
assign the field no value whatsoeever.

> RFC 2156 defines importance as:

> importance      = "low" / "normal" / "high"

> and priority as:

> priority        = "normal" / "non-urgent" / "urgent"

> The difference between these fields is not very clear
> from RFC 2156, but in X.400, priority is an envelope
> attribute, while importance is a heading attribute,
> so presumably priority is meant to be able to influence
> transmission.

On the contrary, the meaning of all these fields is reasonably clear in 
X.400, and RFC 2156, as a simple mapping of field content, doesn't change
their meaning.

In particular:

   (1) Importance is an assessment of the message's importance assigned by the
       sender and interpreted by the receiever.
   (2) Sensitivity is an assessment of how sensitive the data in the message
       is, also assigned by the sender and interpreted by the receiver.
   (3) Priority is a routing/transfer/return indicator that is supposed to
       influence, among other things, the order in which messages are
       transferred and the amount of delay that can be tolerated before
       messages are returned.

> Existing Internet mailers, however, only
> seem to use these attributes in local mailers.

This is mostly true for "Importance" and "Sensitivity", but then, that's how
the fields are defined to work. But in the case of "Priority", this isn't
true at all. Exchange, for example, follows X.400 semantics fairly closely in
a lot of places, and that includes priority handling, at least in terms of
timeouts.

> Mail
> transmission today is so fast, that priority in
> transmission is probably not felt very much needed.

This isn't true either. Prioritized handling is a commonly requested and
frequently used feature.

				Ned

Date: Sun, 11 Jun 2000 12:07:23 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: "Importance" and "Priority"
Sender: [email-masked]

Both

2421 Voice Profile for Internet Mail - version 2. G. Vaudreuil, G.
     Parsons. September 1998. (Format: TXT=123663 bytes) (Obsoletes
     RFC1911) (Status: PROPOSED STANDARD)

and

2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400
     and RFC 822/MIME. S. Kille. January 1998. (Format: TXT=280385 bytes)
     (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495)
     (Updates RFC0822) (Status: PROPOSED STANDARD)

specify two useful e-mail header fields: "Sensitivity" and
"Importance". RFC 2156 also has a related header field
"Importance".

Such fields are obviously felt important by several mailer
developers, since they use various own headers for this,
such as X-Priority (Eudora) or X-MSMail-Priority
(Microsoft).

As an e-mail user, I often send and get messages in which
we do use the X-Priority heading, even though they only
work between certain mailers, so this heading is also
obviously felt useful by many people. Very few messages
indicate a lower than normal priority, the usage is
almost only to indicate a higher than normal priority
for some messages.

RFC 2156 defines importance as:

importance      = "low" / "normal" / "high"

and priority as:

priority        = "normal" / "non-urgent" / "urgent"

The difference between these fields is not very clear
from RFC 2156, but in X.400, priority is an envelope
attribute, while importance is a heading attribute,
so presumably priority is meant to be able to influence
transmission. Existing Internet mailers, however, only
seem to use these attributes in local mailers. Mail
transmission today is so fast, that priority in
transmission is probably not felt very much needed.

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

Date: Tue, 6 Jun 2000 19:02:40 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: ERROR! Someone May Be Ripping You Off!
Organization: Khoury, Jackson, & Associates
Sender: [email-masked]

--=200006061658=
Content-Type: text/plain;charset=US-ASCII

If you are receiving this, than you are in a special database and

you may have been ripped off!

Check http://www.ecomtogo.cc

This message is sent in compliance of the new email bill section 301. Under
Bill S.1618 TITLE III passed by the 105th U.S. Congress this message cannot
be Considered Spam as long as we include the way to be removed. Per Section
301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the
sender of this email may be stopped at no cost to you by sending a request
to be removed to - mailto: [email-masked] . Please type "Remove" in the
subject line. Your request to be removed will be processed within 24 hours.
Please DO NOT Reply to this message if you wish to be removed.

**************************************************************************************
Notice:  This letter is not spam.  It is sent to you with your 
permission, subject to terms given when posting your ad on my links page,
or sending an e-mail to my address: [email-masked]
To review your post, simply go to: [ http://ffanet.com/links/slightedge.htm ]
**************************************************************************************

--=200006061658=--