Subject: Re: text/*
From: Ashley Yakeley <[email-masked]>
To: "Steve Dorner" <[email-masked]>
Cc: "IETF-822 List" <[email-masked]>
Date: Fri, 30 Oct 1998 16:50:32 -0800

At 1998-10-30 16:18, Steve Dorner wrote:

>><ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/vnd.abc>.
>
>Sorry, I thought you had made up an example, I didn't realize this was a 
>real type.
>
>There's an interesting case, but it's a VERY SPECIAL case.  It's audio that 
>can actually be read by humans directly (well, not *this* particular human, 
>but... :-)).

...but even to you it's 'to some extent readable', in the words of RFC 
2046.

>In that case, I can understand your interpretation of 2046 (though I think 
>the registration is wrong and should be audio/vnd.abc and that 2046 should 
>be clarified).  

That would be a change, not a clarification.

>However, I really wouldn't build a theory around such 
>oddball cases.  I would especially worry about using words like "encoding" 
>when talking about them.

Um. By 'encode', I just mean 'represent'.

>Much data that is textual is not intended to be directly read by users and 
>does not belong in text/* by virtue of its textual form. 

Again, that's not what RFC 2046 says. Any type that is 'to some extent 
readable' as plain text should be in text/*.

> May people do not 
>understand this, and believe that any representation that consists of short 
>lines of ascii characters means the type belongs in text/*.  Not so.

No, if the data is formatted textually, it belongs in text/*:

# Such formatted textual data should be
# represented using subtypes of "text".

>>...but that the 'Media' frosting on top can be anything at all:
>>
>>----------Audio----------
>>text/vnd.abc
>
>Only in the oddball case where you have a media type that can actually be 
>directly read in the raw by an ordinary user.  I assert that the set of 
>such types is very small indeed.

I maintain that you're holding a far higher standard of readability than 
that implied by RFC 2046.

>>...whereas 'audio', 'image' and 'video' types describe the top layer of
>>frosting:
>>
>>----------Audio----------
>>audio/aiff
>>----------Octets---------
>
>Ah, but here you can have a textual layer, too:
>
>----------Audio----------
>audio/hypothetical-thing
>----------textual--------
>charset
>----------Octets---------
>
>You just have to say in the registration of audio/hypothetical-thing that 
>it takes a charset parameter (and presumably has other textual behaviors 
>like newline canonicalization).  For example, I might register 
>audio/yes-and-no, where I describe a sound by means of the words yes and 
>no.  I could then say (forgive me on the details):
>
>ct: audio/yes-and-no; charset=us-ascii; language=fr
>
>oui oui oui non non oui
>
>That's textual, but it sure doesn't belong in text/*.

Your example is tendentious, since it's not a reasonable representation 
of audio. But if it were, then it should be in text/*.

A better example would be a hypothetical 'ascii-art' type. ASCII art 
obviously represents images, but since it is readable as text, it should 
(according to RFC 2046) be registered as 'text/ascii-art', not 
'image/ascii-art'.

-- 
Ashley Yakeley, Seattle WA

Date: Fri, 30 Oct 1998 18:18:45 -0600
To: Ashley Yakeley <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: text/*
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

><ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/vnd.abc>.

Sorry, I thought you had made up an example, I didn't realize this was a 
real type.

There's an interesting case, but it's a VERY SPECIAL case.  It's audio that 
can actually be read by humans directly (well, not *this* particular human, 
but... :-)).

In that case, I can understand your interpretation of 2046 (though I think 
the registration is wrong and should be audio/vnd.abc and that 2046 should 
be clarified).  However, I really wouldn't build a theory around such 
oddball cases.  I would especially worry about using words like "encoding" 
when talking about them.

Much data that is textual is not intended to be directly read by users and 
does not belong in text/* by virtue of its textual form.  May people do not 
understand this, and believe that any representation that consists of short 
lines of ascii characters means the type belongs in text/*.  Not so.

>...but that the 'Media' frosting on top can be anything at all:
>
>----------Audio----------
>text/vnd.abc

Only in the oddball case where you have a media type that can actually be 
directly read in the raw by an ordinary user.  I assert that the set of 
such types is very small indeed.

>...whereas 'audio', 'image' and 'video' types describe the top layer of
>frosting:
>
>----------Audio----------
>audio/aiff
>----------Octets---------

Ah, but here you can have a textual layer, too:

----------Audio----------
audio/hypothetical-thing
----------textual--------
charset
----------Octets---------

You just have to say in the registration of audio/hypothetical-thing that 
it takes a charset parameter (and presumably has other textual behaviors 
like newline canonicalization).  For example, I might register 
audio/yes-and-no, where I describe a sound by means of the words yes and 
no.  I could then say (forgive me on the details):

ct: audio/yes-and-no; charset=us-ascii; language=fr

oui oui oui non non oui

That's textual, but it sure doesn't belong in text/*.

Date: Fri, 30 Oct 1998 15:49:25 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: UTF-7 sucks
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Ashley Yakeley <[email-masked]>
Cc: IETF-822 List <[email-masked]>
Sender: [email-masked]

On Fri, 30 Oct 1998, Ashley Yakeley wrote:
> OK. So how's this:
> 
> 1. Pick a charset, in this order: US-ASCII, ISO-8859-1, some other common 
> charset, UTF-8.

Reasonable.

> 2. Use 7bit CTE if you can. Otherwise, use 8bit CTE.

Mandatory.

> 3. Send the message. If the recipient complains that SMTP mangled your 
> 8bit text, resend using quoted-printable CTE.

Nope.  If the SMTP server fails to advertise 8BITMIME in response to EHLO,
then downconvert any 8-bit CTE to quoted-printable prior to sending.

If your local MTA doesn't support 8BITMIME, then it's probably time to
upgrade or replace it.

		- Chris

Subject: Re: text/* 
Date: Fri, 30 Oct 1998 15:42:35 -0800
From: Ashley Yakeley <[email-masked]>
To: "Keith Moore" <[email-masked]>
cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-30 14:53, Keith Moore wrote:

>> My understanding of top-level types is that image, audio & video indicate 
>> what the stream encodes, whereas text (and perhaps message) indicate how 
>> the stream is encoded. For instance, 'text/vnd.abc' encodes audio, but is 
>> encoded in text.
>
>no, that's not how it's intended to work.  for all cases, the top-level
>content-type describes the underlying content, not the encoding.
>the content-transfer-encoding field describes the encoding.

CTE is actually a whole separate encoding layer that I'm not even 
considering at this point.
CTE encoding of octet-streams as other octet-streams is entirely 
orthogonal to MIME encoding of images, audio, video, etc. as 
octet-streams.

I tried to explain this formally in an earlier post. Here's an attempt to 
explain my exegesis of RFC 2046 metaphorically. Think of it as a layer 
cake:

----------Media----------
Content-Type
----------Octets---------
Content-Transfer-Encoding
----------Octets---------
MIME, Transport, etc.

'Content-Type' and 'Content-Transfer-Encoding' are layers of cake 
representing protocols, lines with hyphens are layers of jam or frosting 
representing data-types.

First of all, I'm only interested in the top 'Content-Type' layer:

----------Media----------
Content-Type
----------Octets---------

It's my contention that for text/* types, you can always slice this cake 
halfway and insert 'text' jam between the two slices:

----------Media----------
text/whatever
----------Text-----------
charset
----------Octets---------

...but that the 'Media' frosting on top can be anything at all:

----------Audio----------
text/vnd.abc
----------Text-----------
charset
----------Octets---------

...whereas 'audio', 'image' and 'video' types describe the top layer of 
frosting:

----------Audio----------
audio/aiff
----------Octets---------

Make sense?

-- 
Ashley Yakeley, Seattle WA

Subject: Re: text/*
Date: Fri, 30 Oct 1998 15:39:10 -0800
From: Ashley Yakeley <[email-masked]>
To: "Steve Dorner" <[email-masked]>
cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-30 15:08, Steve Dorner wrote:

>At 2:22 PM -0800 10/30/98, Ashley Yakeley wrote:
>>My understanding of top-level types is that image, audio & video indicate
>>what the stream encodes, whereas text (and perhaps message) indicate how
>>the stream is encoded. For instance, 'text/vnd.abc' encodes audio, but is
>>encoded in text.
>
>This is a very common MISunderstanding.

One encouraged by RFC 2046, sec. 4.1:

# Beyond plain text, there are many formats for representing what might
# be known as "rich text".  An interesting characteristic of many such
# representations is that they are to some extent readable even without
# the software that interprets them.  It is useful, then, to
# distinguish them, at the highest level, from such unreadable data as
# images, audio, or text represented in an unreadable form. In the
# absence of appropriate interpretation software, it is reasonable to
# show subtypes of "text" to the user, while it is not reasonable to do
# so with most nontextual data. Such formatted textual data should be
# represented using subtypes of "text".

>Any MIME content type can have textual semantics, simply by specifying 
>textual semantics in the document that defines the type.  Doesn't matter if 
>it's application/whatever, image/whatever, etc.  You can specify that it be 
>slung around as a textual thing, with newline canonicalization, charset, 
>language, whatever.

...which makes such things 'formatted textual data', which according to 
RFC 2046 'should be represented using subtypes of "text"'.

>Text subtypes, on the other hand are assumed to have textual semantics, but 
>it doesn't end there.  For a subtype to belong in text, it must have a 
>further property, that of being appropriate for normal users to read 
>without any special software.

RFC 2046 merely claims that it needs to be 'to some extent readable'.

>So, your textual encoding of audio is not "text/vnd.abc", it's 
>"audio/vnd.abc".  But it's still allowed to be textual.

No, it's (correctly) 'text/vnd.abc'. See 
<ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/vnd.abc>.

-- 
Ashley Yakeley, Seattle WA

Date: Fri, 30 Oct 1998 17:08:59 -0600
To: Ashley Yakeley <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: text/*
Cc: "Keith Moore" <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 2:22 PM -0800 10/30/98, Ashley Yakeley wrote:
>My understanding of top-level types is that image, audio & video indicate
>what the stream encodes, whereas text (and perhaps message) indicate how
>the stream is encoded. For instance, 'text/vnd.abc' encodes audio, but is
>encoded in text.

This is a very common MISunderstanding.

Any MIME content type can have textual semantics, simply by specifying 
textual semantics in the document that defines the type.  Doesn't matter if 
it's application/whatever, image/whatever, etc.  You can specify that it be 
slung around as a textual thing, with newline canonicalization, charset, 
language, whatever.

Text subtypes, on the other hand are assumed to have textual semantics, but 
it doesn't end there.  For a subtype to belong in text, it must have a 
further property, that of being appropriate for normal users to read 
without any special software.

So, your textual encoding of audio is not "text/vnd.abc", it's 
"audio/vnd.abc".  But it's still allowed to be textual.

From: Keith Moore <[email-masked]>
To: Ashley Yakeley <[email-masked]>
cc: "Keith Moore" <[email-masked]>, "IETF-822 List" <[email-masked]>
Subject: Re: text/* 
Date: Fri, 30 Oct 1998 17:53:06 -0500
Sender: [email-masked]

> My understanding of top-level types is that image, audio & video indicate 
> what the stream encodes, whereas text (and perhaps message) indicate how 
> the stream is encoded. For instance, 'text/vnd.abc' encodes audio, but is 
> encoded in text.

no, that's not how it's intended to work.  for all cases, the top-level
content-type describes the underlying content, not the encoding.
the content-transfer-encoding field describes the encoding.

Subject: text/* 
Date: Fri, 30 Oct 1998 14:22:08 -0800
From: Ashley Yakeley <[email-masked]>
To: "Keith Moore" <[email-masked]>
cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-22 19:55, Keith Moore wrote:

>text/html is a good example of a type name that in hindsight many
>of us wish had not used 'text' as a top-level content-type.  The web
>would have worked just as well had HTML been called application/html.
>Email would have worked *much better*, because recipient's user
>agents wouldn't insist on displaying application/html as if it were 
>text, and therefore nobody's UA would generate HTML in email by default 
>until the capability to display it were *very* widely deployed.

So what subtypes should text/* have, apart from plain?

My understanding of top-level types is that image, audio & video indicate 
what the stream encodes, whereas text (and perhaps message) indicate how 
the stream is encoded. For instance, 'text/vnd.abc' encodes audio, but is 
encoded in text.

-- 
Ashley Yakeley, Seattle WA

Subject: Re: UTF-7 sucks
Date: Fri, 30 Oct 1998 12:48:45 -0800
From: Ashley Yakeley <[email-masked]>
To: "Chris Newman" <[email-masked]>
cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-30 11:47, Chris Newman wrote:

>UTF-7 has the following problems:
>
>* far worse backwards compatibility than quoted-printable.  Some people
>hate MIME due to what they consider "quoted-unreadable".  If you use
>UTF-7, there will be lots of people who will start hating Unicode as a
>result.

>* The uptake of the 8BITMIME SMTP extension has been excellent.  This
>means that unencoded UTF-8 with CTE 8-bit is usually possible.  UTF-8
>doesn't have double-encoding or searching problems.

OK. So how's this:

1. Pick a charset, in this order: US-ASCII, ISO-8859-1, some other common 
charset, UTF-8.

2. Use 7bit CTE if you can. Otherwise, use 8bit CTE.

3. Send the message. If the recipient complains that SMTP mangled your 
8bit text, resend using quoted-printable CTE.

-- 
Ashley Yakeley, Seattle WA

Date: Fri, 30 Oct 1998 11:52:08 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: [email-masked]
Cc: Randall Gellens <[email-masked]>, Steve Dorner <[email-masked]>, Ashley Yakeley <[email-masked]>, IETF-822 List <[email-masked]>
Sender: [email-masked]

On Mon, 26 Oct 1998 [email-masked] wrote:
> OK. It's Monday, and I'm dense.  If you're wrapping your lines so each
> is <80, what's the point of format=flowed?  Just so an MUA can take ONE
> pre-flowed paragraph and re-write it as ANOTHER one?

Precisely.  Think about devices with screens narrower than 80 columns,
wider than 80 columns or ones that use proportional fonts.  format=flowed
is a minor tweak which allows such devices to work great on the Internet
without breaking other things as a side effect the way sending long lines
does.

		- Chris

Date: Fri, 30 Oct 1998 11:47:42 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: UTF-7 sucks (was Re: Format=Flowed and Non-ASCII Characters)
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Ashley Yakeley <[email-masked]>
Cc: IETF-822 List <[email-masked]>
Sender: [email-masked]

On Mon, 26 Oct 1998, Ashley Yakeley wrote:
> ...but I'd like to point out that quoted-printable may not be necessary 
> to encode non-US-ASCII, given UTF-7.
> 
> The question is, which is better for the existing (international) base of 
> installed users as would be recipients: using qp (at the transport 
> level), or using UTF-7 (at the content-type level)?

NO! NO! ARRRGGHGGHGHH!   Don't use UTF-7 in email.

Am I going to have to dust off the draft on "UTF-7 in MIME considered
harmful"?

UTF-7 has the following problems:

* far worse backwards compatibility than quoted-printable.  Some people
hate MIME due to what they consider "quoted-unreadable".  If you use
UTF-7, there will be lots of people who will start hating Unicode as a
result.

* Massive layering violation -- it uses a content-transfer-encoding in a
character set, thus forcing base64 code in multiple layers of code.

* Double-encoding.  UTF-7 is base64-encoded UTF-16 which is itself an
encoding of UCS-4.  Bletch.

* Searches are impossible without decoding UTF-7.  (and it can't be mapped
internally on a signed message, since there's no canonical form).

* The uptake of the 8BITMIME SMTP extension has been excellent.  This
means that unencoded UTF-8 with CTE 8-bit is usually possible.  UTF-8
doesn't have double-encoding or searching problems.

I could go on.  People who generate UTF-7 are doing a great disservice to
the Internet, IMHO. 

		- Chris

Date: Mon, 26 Oct 1998 16:03:57 -0700
To: Randy Gellens <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Cc: [email-masked], Randy Gellens <[email-masked]>, Steve Dorner <[email-masked]>, Ashley Yakeley <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

--============_-1302678157==_ma============
Content-Type: text/plain; charset="us-ascii"
 ; format="flowed"

Hmm, I find that a little misleading. To me CTE is for transport and does 
not affect content semantics or formats. Format=flowed changes content 
semantics.

I agree that from the point of view of two MUAs wanting to send 
paragraphs/flows it is kind of a CTE.

LL

At 3:29 PM -0800 10/26/98, Randall Gellens wrote:
>> If you're wrapping your lines so each
>> is <80, what's the point of format=flowed?  Just so an MUA can take ONE
>> pre-flowed paragraph and re-write it as ANOTHER one?
>
>Well, yes.  Think of Format=Flowed as a kind of 
>content-transfer-encoding.  A generating agent can send paragraph text to 
>a receiving agent, and both know it is paragraph text.  However, if the 
>message happens to get sent to an agent that doesn't know from paragraphs, 
>it can still deal quite well with the message (at least as well as it can 
>deal with anything else).
>
>A generating agent that uses paragraphs internally should probably convert 
>to Format=Flowed when it sends the message (that is, Format=Flowed is only 
>used on the wire).  A receiving agent can likewise convert Format=Flowed 
>to paragraphs.
>
>When generating Format=Flowed, each line is soft-wrapped by adding SPACE 
>CRLF, so that each line is sent on the wire as less than 80 characters.

--============_-1302678157==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: Format=Flowed and Non-ASCII
Characters</title></head><body>
<div>Hmm, I find that a little misleading. To me CTE is for transport
and does not affect content semantics or formats. Format=flowed
changes content semantics.</div>
<div><br></div>
<div>I agree that from the point of view of two MUAs wanting to send
paragraphs/flows it is kind of a CTE.</div>
<div><br></div>
<div>LL</div>
<div><br></div>
<div><br></div>
<div>At 3:29 PM -0800 10/26/98, Randall Gellens wrote:</div>
<blockquote type="cite" cite>&gt; If you're wrapping your lines so
each<br>
&gt; is &lt;80, what's the point of format=flowed?&nbsp; Just so an
MUA can take ONE<br>
&gt; pre-flowed paragraph and re-write it as ANOTHER one?<br>
<br>
Well, yes.&nbsp; Think of Format=Flowed as a kind of
content-transfer-encoding.&nbsp; A generating agent can send
paragraph text to a receiving agent, and both know it is paragraph
text.&nbsp; However, if the message happens to get sent to an agent
that doesn't know from paragraphs, it can still deal quite well with
the message (at least as well as it can deal with anything else).<br>
<br>
A generating agent that uses paragraphs internally should probably
convert to Format=Flowed when it sends the message (that is,
Format=Flowed is only used on the wire).&nbsp; A receiving agent can
likewise convert Format=Flowed to paragraphs.<br>
<br>
When generating Format=Flowed, each line is soft-wrapped by adding
SPACE CRLF, so that each line is sent on the wire as less than 80
characters.</blockquote>
<div><br></div>
</body>
</html>
--============_-1302678157==_ma============--

Date: Mon, 26 Oct 1998 15:29:56 -0800
To: [email-masked], Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Cc: Steve Dorner <[email-masked]>, Ashley Yakeley <[email-masked]>, "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 5:02 PM -0500 10/26/98, [email-masked] wrote:

> If you're wrapping your lines so each
> is <80, what's the point of format=flowed?  Just so an MUA can take ONE
> pre-flowed paragraph and re-write it as ANOTHER one?

Well, yes.  Think of Format=Flowed as a kind of 
content-transfer-encoding.  A generating agent can send paragraph text 
to a receiving agent, and both know it is paragraph text.  However, if 
the message happens to get sent to an agent that doesn't know from 
paragraphs, it can still deal quite well with the message (at least as 
well as it can deal with anything else).

A generating agent that uses paragraphs internally should probably 
convert to Format=Flowed when it sends the message (that is, 
Format=Flowed is only used on the wire).  A receiving agent can 
likewise convert Format=Flowed to paragraphs.

When generating Format=Flowed, each line is soft-wrapped by adding 
SPACE CRLF, so that each line is sent on the wire as less than 80 
characters.

Date: Mon, 26 Oct 1998 16:19:42 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 5:02 PM -0500 10/26/98, [email-masked] wrote:
>OK. It's Monday, and I'm dense.  If you're wrapping your lines so each
>is <80, what's the point of format=flowed?  Just so an MUA can take ONE
>pre-flowed paragraph and re-write it as ANOTHER one?

Randy was saying that the lines on the wire need to be <80, once all the 
encoding is removed.  However, the receiving MUA can remove the linebreaks 
that make it so and reconstitute the original long, flowing paragraphs.  
That way mailers who don't know f=f get stuff that looks ok, but mailers 
that do know f=f can make it even better.

So, lines on the wire, <80.  Paragraphs they represent, long as you wish.

Clearer?

Subject: Re: Format=Flowed and Non-ASCII Characters 
Date: Mon, 26 Oct 1998 14:12:47 -0800
From: Ashley Yakeley <[email-masked]>
To: <[email-masked]>
cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-26 14:02, [email-masked] wrote:

>On Mon, 26 Oct 1998 12:35:30 PST, Randall Gellens said:
>> I meant when you generate the message and add "Format=Flowed", please 
>> wrap your lines, so that each line is < 80 characters.  That way the 
>> message will look good if the recipient understand Format=Flowed, or 
>> not.
>
>OK. It's Monday, and I'm dense.  

It happens to all of us...

>If you're wrapping your lines so each
>is <80, what's the point of format=flowed?  Just so an MUA can take ONE
>pre-flowed paragraph and re-write it as ANOTHER one?
>
>I thought the point of format=flowed was so that MUAs that liked to send
>one VERY long line per paragraph could do so....

By wrapping format=flowed at < 80 characters, but marking each line as 
flowed with a trailing space, the message is most likely to be treated 
optimally by both UAs that understand format=flowed as well as those that 
don't. The former will consider the lines to be part of a single 
paragraph, whereas the latter will show the lines separately, rather than 
as one long line requiring horizontal scrolling to see.

-- 
Ashley Yakeley, Seattle WA

To: Randall Gellens <[email-masked]>
Cc: Steve Dorner <[email-masked]>, Ashley Yakeley <[email-masked]>, "IETF-822 List" <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters 
From: [email-masked]
Date: Mon, 26 Oct 1998 17:02:42 -0500
Sender: [email-masked]

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

On Mon, 26 Oct 1998 12:35:30 PST, Randall Gellens said:
> I meant when you generate the message and add "Format=Flowed", please 
> wrap your lines, so that each line is < 80 characters.  That way the 
> message will look good if the recipient understand Format=Flowed, or 
> not.

OK. It's Monday, and I'm dense.  If you're wrapping your lines so each
is <80, what's the point of format=flowed?  Just so an MUA can take ONE
pre-flowed paragraph and re-write it as ANOTHER one?

I thought the point of format=flowed was so that MUAs that liked to send
one VERY long line per paragraph could do so....

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

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

--==_Exmh_2039432844P--

Subject: Re: Format=Flowed and Non-ASCII Characters
Date: Mon, 26 Oct 1998 13:31:31 -0800
From: Ashley Yakeley <[email-masked]>
To: "Steve Dorner" <[email-masked]>
cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-26 08:22, Steve Dorner wrote:

>Adding "format=flowed" means that long lines are to be treated as
>paragraphs (eg, by wrapping them to the display width).

Right. My mistake.

My question more concerned the use of format=flowed over quoted-printable 
given the proposal's emphasis on readability by the many non MIME-aware 
or MIME-compliant MUAs currently in use. Having just perused the archive 
it turns out it was partly answered by an earlier message:

At 1998-09-01 12:02, Randall Gellens wrote:

...
>Or even
>
>While Quoted-Printable encoding MUST be used when necessary to encode
>non-US-ASCII characters, it SHOULD NOT be used unless required for such
>uses; that is, if the SMTP server supports 8BITMIME, or the message
>only contains US-ASCII characters, there is no need for
>Quoted-Printable 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.

...but I'd like to point out that quoted-printable may not be necessary 
to encode non-US-ASCII, given UTF-7.

The question is, which is better for the existing (international) base of 
installed users as would be recipients: using qp (at the transport 
level), or using UTF-7 (at the content-type level)?

-- 
Ashley Yakeley, Seattle WA

Date: Mon, 26 Oct 1998 12:35:30 -0800
To: Steve Dorner <[email-masked]>, Ashley Yakeley <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

> > Adding "format=flowed" means that long lines are to be treated as
> > paragraphs (eg, by wrapping them to the display width).
>
> Yes, but please wrap those lines so they are less than 80 characters.

I meant when you generate the message and add "Format=Flowed", please 
wrap your lines, so that each line is < 80 characters.  That way the 
message will look good if the recipient understand Format=Flowed, or 
not.

Date: Mon, 26 Oct 1998 12:08:13 -0800
To: Steve Dorner <[email-masked]>, Ashley Yakeley <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 8:22 AM -0800 10/26/98, Steve Dorner wrote:

> Adding "format=flowed" means that long lines are to be treated as
> paragraphs (eg, by wrapping them to the display width).

Yes, but please wrap those lines so they are less than 80 characters.

Date: Mon, 26 Oct 1998 09:55:04 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
To: Ashley Yakeley <[email-masked]>
Cc: IETF-822 List <[email-masked]>
Sender: [email-masked]

> What's the best way to send text with non-ASCII characters, given the
> option of format=flowed? The obvious thing to do is to choose a charset,
> and encode it in quoted-printable. But at that point I hardly need
> format=flowed, since I can now safely transport lines of any length. Or
> should I use UTF-7 instead?

As Lawrence has already stated, what you are effectively proposing here is a
misuse of quoted-printable. More generally, transport limitations and the
encodings used to work around them are _completely_ orthogonal to presentation
issues. Quoted-printable addresses such transport issues, but says nothing at
all about presentation. And since several implementations made this error (but
the vast majority did not) the MIME specification was changed some time back to
make it quite clear that these things really are orthogonal.

I continue to believe that format=flowed is the only proposal made thus far
that addresses the presentation issues adequately while maintaining the highest
degree of compatibility possible with the installed base. We've tried the
markup approach in the field and we've tested the separate subtype approach,
and neither of them works. And no amount of wishful thinking on our part (and
we've had a lot of it over the past few years) has sufficed to change this.

				Ned

Date: Mon, 26 Oct 1998 08:09:46 -0700
To: Ashley Yakeley <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

Your suggestion is actually a common misuse and misunderstanding of QP 
encoding. Content-Transfer-Encoding is part of the transport system, not a 
part of the data format. It is only there to compensate for SMTP's 
limitations. It is entirely legal for mail servers to change the C-T-E for 
parts of a message as they relay it (unless the message is 
multipart/signed).

The reason that we are working on format=flowed is that there is no legal 
type for describing text where a new line separates text flows from each 
other. The current standard separates lines of text. The most proper 
display of the current standard (text/plain) is not to wrap long lines, but 
to display a horizontal scroll bar and display each newline separated run 
on a separate line. In format=flowed the text between "hard" carriage 
returns is specifically to be flowed (wrapped) to fit the display width. A 
horizontal scroll bar should not be used.

Text/plain, format=flowed and text/paragraph all work with the charset 
parameter the same. You can use UTF-8, UTF-7, iso-8859-* or other. They 
only apply to the code points or characters and have nothing to do with the 
formatting.

LL

At 10:40 PM -0800 10/25/98, Ashley Yakeley wrote:
>What's the best way to send text with non-ASCII characters, given the
>option of format=flowed? The obvious thing to do is to choose a charset,
>and encode it in quoted-printable. But at that point I hardly need
>format=flowed, since I can now safely transport lines of any length. Or
>should I use UTF-7 instead?
>
>--
>Ashley Yakeley, Seattle WA

Date: Mon, 26 Oct 1998 08:22:01 -0800
To: Ashley Yakeley <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: Format=Flowed and Non-ASCII Characters
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 10:40 PM 10/25/98 -0800, Ashley Yakeley wrote:
>But at that point I hardly need 
>format=flowed, since I can now safely transport lines of any length.

That's not quite right.  Format=flowed is a semantic indicator, not an
encoding method.

When you send a long line without saying "format=flowed", the official
semantics (grumble, grumble) are that it's a very long line, and the
receiving mailer should treat it as such (eg, by applying a horizontal
scroll bar or something).

Adding "format=flowed" means that long lines are to be treated as
paragraphs (eg, by wrapping them to the display width).

If you're sending normal text that you want a receiving mailer to present
as wrapped paragraphs, you should use format=flowed, whether or not you
also use a content-transfer-encoding.

Subject: Format=Flowed and Non-ASCII Characters
Date: Sun, 25 Oct 1998 22:40:48 -0800
From: Ashley Yakeley <[email-masked]>
To: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

What's the best way to send text with non-ASCII characters, given the 
option of format=flowed? The obvious thing to do is to choose a charset, 
and encode it in quoted-printable. But at that point I hardly need 
format=flowed, since I can now safely transport lines of any length. Or 
should I use UTF-7 instead?

-- 
Ashley Yakeley, Seattle WA

Date: Sun, 25 Oct 1998 15:06:16 -0600 (CST)
From: Rick Troth <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Ashley Yakeley <[email-masked]>, IETF-822 List <[email-masked]>
Subject: Re: Text
Sender: [email-masked]

> As long as we have untyped protocols like FTP, 
> magic numbers will remain useful.   ... 
 
	Good point. 
 
> I'm somewhat depressed by what a half-assed job some systems do 
> when mapping from MIME types to OS-specific types. 
 
	Mee too.   Futhermore,  I really believe there are TWO 
levels of "typing" that should be done,  one at the encoding and/or 
transport level  (and in MIME,  this is exclusively an encoding 
operation and transport should be left alone)  the other at the 
application level.   The former is decidedly a  "canonicalization" 
thing.   The latter should be more closely tied to Content-Type 
than it is in practice. 
 
	In other words,  we're using CT for more than we should. 
 
>                                              If I send a word document
> with a filename "foo.xls" and label it application/msword, then anything
> which doesn't treat it as a word document at the other end is inherently
> broken.
 
	Certainly. 
 
> 		- Chris
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Subject: Re: Text
Date: Sun, 25 Oct 1998 12:14:32 -0800
From: Ashley Yakeley <[email-masked]>
To: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-25 11:33, Chris Newman wrote:

>On Sat, 24 Oct 1998, Ashley Yakeley wrote:
>> This seems to be the way things are heading. I personally would like to 
>> see MIME content-type headers used by file-systems, a system superior for 
>> various reasons to the 'magic number', filename-extension and MacOS 
>> 4-byte code systems.
>
>As long as we have untyped protocols like FTP, magic numbers will remain
>useful. 

Oh yes: new file formats should definitely use them where possible. But 
unfortunately not all formats have them, so any system that relies on 
them exclusively is going to end up typing a large number of files in a 
sort of miscellaneous/plain-text/octet-stream category, which is not very 
useful.

-- 
Ashley Yakeley, Seattle WA

Date: Sun, 25 Oct 1998 11:33:51 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Text
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Ashley Yakeley <[email-masked]>
Cc: IETF-822 List <[email-masked]>
Sender: [email-masked]

On Sat, 24 Oct 1998, Ashley Yakeley wrote:
> This seems to be the way things are heading. I personally would like to 
> see MIME content-type headers used by file-systems, a system superior for 
> various reasons to the 'magic number', filename-extension and MacOS 
> 4-byte code systems.

As long as we have untyped protocols like FTP, magic numbers will remain
useful.  For a good discussion on the design and use of magic numbers, see
RFC 2083.

I'm somewhat depressed by what a half-assed job some systems do when
mapping from MIME types to OS-specific types.  If I send a word document
with a filename "foo.xls" and label it application/msword, then anything
which doesn't treat it as a word document at the other end is inherently
broken.

		- Chris

Date: Sun, 25 Oct 1998 11:27:36 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Text
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Laurence Lundblade <[email-masked]>
Cc: Ashley Yakeley <[email-masked]>, IETF-822 List <[email-masked]>
Sender: [email-masked]

On Fri, 23 Oct 1998, Laurence Lundblade wrote:
> So I don't think there's anything wrong with perusing and registering it 
> even as text/paragraph, but I would like to see text saying that it has 
> been found unsuitable for on-the-wire e-mail use and suggest format=flowed 
> instead.

I will consider doing so *after* format=flowed has been published as an
RFC so it can be referenced directly.  I would probably do text/paragraph
as an informational RFC.  But I have higher priorities, so it may be a
while. 

		- CHris

Date: Sat, 24 Oct 1998 22:49:18 -0700
From: Dan Wing <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Text
Sender: [email-masked]

>     Owing to the behaviour of existing mail user agents, which 
>     frequently treat even unrecognised subtypes of text as 
>     attachments, text/paragraph SHOULD NOT be used as a main body 
>     part in news or e-mail messages without prior indications of 
>     suitability from the recipients.
>
>...the idea being that at some point people may wish to include an 
>indication of the MIME-capability of their mail UA along with their 
>e-mail address and PGP public key...

Which is what the MAILCAP working group is working on.  And also
see draft-ietf-fax-reporting-extensions-03.txt which has hit WG
last call.  Not the best solution, pehaps, but easier to deploy
without directories.

-Dan Wing

Subject: Re: Text
Date: Sat, 24 Oct 1998 13:19:41 -0700
From: Ashley Yakeley <[email-masked]>
To: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-23 09:47, Laurence Lundblade wrote:

>So I don't think there's anything wrong with perusing and registering it 
>even as text/paragraph, but I would like to see text saying that it has 
>been found unsuitable for on-the-wire e-mail use and suggest format=flowed 
>instead.

I'm hesitant to suggest format=flowed while that still has draft status, 
but otherwise I agree. Perhaps something like:

     Owing to the behaviour of existing mail user agents, which 
     frequently treat even unrecognised subtypes of text as 
     attachments, text/paragraph SHOULD NOT be used as a main body 
     part in news or e-mail messages without prior indications of 
     suitability from the recipients.

...the idea being that at some point people may wish to include an 
indication of the MIME-capability of their mail UA along with their 
e-mail address and PGP public key...

>In general, using MIME typing for lots of other applications, internal 
>representations, etc seems like a good idea to me.

This seems to be the way things are heading. I personally would like to 
see MIME content-type headers used by file-systems, a system superior for 
various reasons to the 'magic number', filename-extension and MacOS 
4-byte code systems.

-- 
Ashley Yakeley, Seattle WA

Date: Fri, 23 Oct 1998 09:47:57 -0700
To: Ashley Yakeley <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Text
Cc: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

There's a big difference in the way on-the-wire and local formats are used. 
On-the-wire formats, as format=flowed is targeted to be, have to 
interoperate really well with the installed base of applications that 
communicate  using it. In this case it is e-mail client software and 
gateways. I posted a sample of text/paragraph to this mailing list some 
months ago to find out how well it worked. It was clear that you could not 
send this format in e-mail with impunity. Many mailers treated it as an 
attachment and that's why it was withdrawn. Format=flowed doesn't have this 
problem.

Local formats (or applications where you can negotiate format like HTTP), 
are a little different. If you're looking for a type to use with some local 
application of the MIME type scheme, then text/paragraph makes a lot more 
sense. It allows you to label the format you have correctly. In my 
implementaiton of format=flowed, the mail messages is actually stored in 
text/paragraph while the user is editing it and while it remains a draft 
message. It is converted to format=flowed upon sending because storing 
format=flowed locally for outgoing messages makes no sense. (I don't have 
to actually label it internally as text/paragraph since that's the only 
form of text used).

So I don't think there's anything wrong with perusing and registering it 
even as text/paragraph, but I would like to see text saying that it has 
been found unsuitable for on-the-wire e-mail use and suggest format=flowed 
instead.

In general, using MIME typing for lots of other applications, internal 
representations, etc seems like a good idea to me.

LL

At 8:56 PM -0700 10/22/98, Ashley Yakeley wrote:
>At 1998-10-22 19:55, Keith Moore wrote:
>
>>> But I'm right, aren't I? Text/paragraph fails to be handled correctly by
>>> many existing UAs which don't like unrecognised text/*, but it's still
>>> useful for many applications. I think there's room in the world for it no
>>> matter what solutions anyone comes up with for mail and news.
>>
>>Perhaps.  But the people who designed text/paragraph were trying to
>>solve the mail/news problem.  So to them it's a failure.
>
>Well this may explain the withdrawal, but I'd like to suggest
>re-submitting it in some form... or perhaps there's some way it can be
>registered without being an RFC, perhaps as 'text/vnd.paragraph'.
>
>>Someone
>>else might find it useful in another environment (say the way),
>>but I doubt it, because HTML is more functional and already widely
>>deployed.
>
>Text/paragraph as such is already very widely used, and very useful, but
>by necessity it can only be inaccurately labelled 'text/plain' by systems
>using MIME to type data, such as Java's data-transfer mechanism and some
>file-systems.
>
>HTML may be more functional, but obviously it's rather unwieldy for many
>applications which need nothing more than plain text.
>
>--
>Ashley Yakeley, Seattle WA

Subject: Re: Text 
Date: Thu, 22 Oct 1998 20:56:31 -0700
From: Ashley Yakeley <[email-masked]>
To: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-22 19:55, Keith Moore wrote:

>> But I'm right, aren't I? Text/paragraph fails to be handled correctly by 
>> many existing UAs which don't like unrecognised text/*, but it's still 
>> useful for many applications. I think there's room in the world for it no 
>> matter what solutions anyone comes up with for mail and news.
>
>Perhaps.  But the people who designed text/paragraph were trying to
>solve the mail/news problem.  So to them it's a failure.  

Well this may explain the withdrawal, but I'd like to suggest 
re-submitting it in some form... or perhaps there's some way it can be 
registered without being an RFC, perhaps as 'text/vnd.paragraph'.

>Someone
>else might find it useful in another environment (say the way), 
>but I doubt it, because HTML is more functional and already widely 
>deployed.

Text/paragraph as such is already very widely used, and very useful, but 
by necessity it can only be inaccurately labelled 'text/plain' by systems 
using MIME to type data, such as Java's data-transfer mechanism and some 
file-systems.

HTML may be more functional, but obviously it's rather unwieldy for many 
applications which need nothing more than plain text.

-- 
Ashley Yakeley, Seattle WA

From: Keith Moore <[email-masked]>
To: Ashley Yakeley <[email-masked]>
cc: "IETF-822 List" <[email-masked]>
Subject: Re: Text 
Date: Thu, 22 Oct 1998 22:55:48 -0400
Sender: [email-masked]

> >Running code is a good way to test theory.  
> 
> In my opinion, you can't even write this kind of code until you know 
> exactly (i.e. formally) what it's supposed to do -- specifically, what 
> every given sequence of octets means.

It's a chicken-and-egg problem.  You can't write the code until know
what it's supposed to do, but for something like this (where implementors'
mistakes defy explanation by logic or physical laws) you can't figure out 
what the code needs to do until you guess at a solution and see how well
it works with the installed base.

> >The text/paragraph form 
> >turned out not to interoperate, while format=flowed does.  
> 
> But I'm right, aren't I? Text/paragraph fails to be handled correctly by 
> many existing UAs which don't like unrecognised text/*, but it's still 
> useful for many applications. I think there's room in the world for it no 
> matter what solutions anyone comes up with for mail and news.

Perhaps.  But the people who designed text/paragraph were trying to
solve the mail/news problem.  So to them it's a failure.  Someone
else might find it useful in another environment (say the way), 
but I doubt it, because HTML is more functional and already widely 
deployed.

> The root of my argument is that MIME is no longer just for the Internet 
> Mail of its acronym: it's becoming a general data-typing scheme. I don't 
> think proposed MIME types should be rejected just because they confuse 
> some existing mail UAs -- the obvious example here is text/html, which 
> can annoy mail recipients but works well over HTTP.

text/html is a good example of a type name that in hindsight many
of us wish had not used 'text' as a top-level content-type.  The web
would have worked just as well had HTML been called application/html.
Email would have worked *much better*, because recipient's user
agents wouldn't insist on displaying application/html as if it were 
text, and therefore nobody's UA would generate HTML in email by default 
until the capability to display it were *very* widely deployed.

Keith

Subject: Re: Text
Date: Wed, 21 Oct 1998 20:10:04 -0700
From: Ashley Yakeley <[email-masked]>
To: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

At 1998-10-19 14:43, Randall Gellens wrote:

>Running code is a good way to test theory.  

In my opinion, you can't even write this kind of code until you know 
exactly (i.e. formally) what it's supposed to do -- specifically, what 
every given sequence of octets means.

>The text/paragraph form 
>turned out not to interoperate, while format=flowed does.  

But I'm right, aren't I? Text/paragraph fails to be handled correctly by 
many existing UAs which don't like unrecognised text/*, but it's still 
useful for many applications. I think there's room in the world for it no 
matter what solutions anyone comes up with for mail and news.

The root of my argument is that MIME is no longer just for the Internet 
Mail of its acronym: it's becoming a general data-typing scheme. I don't 
think proposed MIME types should be rejected just because they confuse 
some existing mail UAs -- the obvious example here is text/html, which 
can annoy mail recipients but works well over HTTP.

Now that may be off-topic on a list for extensions to RFC 822, but that 
just happens to be the place where draft-newman-mime-textpara is (or was) 
being evaluated. And it may not be a good extension to RFC 822 but it 
would be very useful for other applications. In fact, the format it 
describes is already being used very widely, and all it needs is a 
suitable MIME content-type header. Come to think of it, it's even being 
used by many mail UAs together with quoted-printable, but being labelled 
'text/plain'.

-- 
Ashley Yakeley, Seattle WA

From: Allen Gwinn <[email-masked]>
Subject: The Passing of Dr. Jon Postel
To: [email-masked]
Date: Tue, 20 Oct 1998 09:18:59 -0500 (CDT)
Sender: [email-masked]

Greetings,

It is with deep regret that I report the passing of Dr. Jon Postel.  Jon
was a pioneer and a leader whose death will be felt far and wide.  Vint
Cerf was kind enough to share this, and I would like to forward it on
to everyone.

Allen Gwinn

---
October 17, 1998

I REMEMBER IANA

Vint Cerf

A long time ago, in a network, far far away, a great adventure took
place.

Out of the chaos of new ideas for communication, the experiments, the
tentative designs, and crucible of testing, there emerged a cornucopia of
networks. Beginning with the ARPANET, an endless stream of networks
evolved, and ultimately were interlinked to become the Internet.

Someone had to keep track of all the protocols, the identifiers, networks and
addresses and ultimately the names of all the things in the networked
universe. And someone had to keep track of all the information that
erupted with volcanic force from the intensity of the debates and
discussions and endless invention that has continued unabated for 30
years. That someone was Jonathan B. Postel, our Internet Assigned
Numbers Authority, friend, engineer, confidant, leader, icon, and now, first
of the giants to depart from our midst.

Jon, our beloved IANA, is gone. Even as I write these words I cannot
quite grasp this stark fact. We had almost lost him once before in 1991.
Surely we knew he was at risk as are we all. But he had been our rock, the
foundation on which our every web search and email was built, always
there to mediate the random dispute, to remind us when our documentation
did not do justice to its subject, to make difficult decisions with apparent
ease, and to consult when careful consideration was needed. We will survive
our loss and we will remember. He has left a monumental legacy for all
Internauts to contemplate. Steadfast service for decades, moving when
others seemed paralyzed, always finding the right course in a complex
minefield of technical and sometimes political obstacles.

Jon and I went to the same high school, Van Nuys High, in the San Fernando
Valley north of Los Angeles. But we were in different classes and I really
didn't know him then. Our real meeting came at UCLA when we became
a part of a group of graduate students working for Prof. Leonard Kleinrock
on the ARPANET project. Steve Crocker was another of the Van Nuys crowd who
was part of the team and led the development of the first host-host
protocols for the ARPANET. When Steve invented the idea of the Request for
Comments series, Jon became the instant editor. When we needed to keep track
of all the hosts and protocol identifiers, Jon volunteered to be the Numbers
Czar and later the IANA once the Internet was in place.

Jon was a founding member of the Internet Architecture Board and served
continuously from its founding to the present. He was the FIRST individual
member of the Internet Society I know, because he and Steve Wolff raced to
see who could fill out the application forms and make payment first and
Jon won. He served as a trustee of the Internet Society. He was the
custodian of the .US domain, a founder of the Los Nettos Internet service,
and, by the way, managed the networking research division of USC
Information Sciences Institute.

Jon loved the outdoors. I know he used to enjoy backpacking in the high
Sierras around Yosemite. Bearded and sandaled, Jon was our resident
hippie-patriarch at UCLA. He was a private person but fully capable of
engaging photon torpedoes and going to battle stations in a good
engineering argument. And he could be stubborn beyond all expectation. 
He could have outwaited the Sphinx in a staring contest, I think.

Jon inspired loyalty and steadfast devotion among his friends and his
colleagues. For me, he personified the words "selfless service."
For nearly 30 years, Jon has served us all, taken little in return, indeed
sometimes receiving abuse when he should have received our deepest
appreciation. It was particularly gratifying at the last Internet Society
meeting in Geneva to see Jon receive the Silver Medal of the International
Telecommunications Union. It is an award generally reserved for Heads of
State but I can think of no one more deserving of global recognition for
his contributions.

While it seems almost impossible to avoid feeling an enormous sense of
loss, as if a yawning gap in our networked universe had opened up and
swallowed our friend, I must tell you that I am comforted as I contemplate
what Jon has wrought. He leaves a legacy of edited documents that tell our
collective Internet story, including not only the technical but also the
poetic and whimsical as well. He completed the incorporation of a
successor to his service as IANA and leaves a lasting legacy of service to
the community in that role. His memory is rich and vibrant and will not
fade from our collective consciousness. "What would Jon have done?" we
will think, as we wrestle in the days ahead with the problems Jon kept so
well tamed for so many years.

There will almost surely be many memorials to Jon's monumental service to
the Internet Community. As current chairman of the Internet Society, I
pledge to establish an award in Jon's name to recognize long-standing
service to the community, the Jonathan B. Postel Service Award, which is
awarded to Jon posthumously as its first recipient.

If Jon were here, I am sure he would urge us not to mourn his passing but
to celebrate his life and his contributions. He would remind us that there
is still much work to be done and that we now have the responsibility and
the opportunity to do our part. I doubt that anyone could possibly
duplicate his record, but it stands as a measure of one man's astonishing
contribution to a community he knew and loved.

Date: Mon, 19 Oct 1998 14:43:30 -0700
To: Ashley Yakeley <[email-masked]>, IETF-822 List <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Text
Sender: [email-masked]

At 1:44 PM -0700 10/18/98, Ashley Yakeley wrote:

[snip]

>draft-newman-mime-textpara defines a MIME type 'text/paragraph' which
>can be used over suitable CTEs just like text/plain.

[snip]

>...and I think it was premature for Chris Newman to withdraw it.

>As for draft-gellens-format, I believe its attempts to handle >-quoted
>text compromise it, mainly because of the various ways people quote
>text. I think if we go that route, we should specify a complete markup
>language of *bold*, _italic_, - bullets, etc., with strict semantics
>for what any given sequence of octets means.

>But if >-quote handling were stripped out, draft-gellens-format might
>work for general email:

[snip]

Running code is a good way to test theory.  The text/paragraph form 
turned out not to interoperate, while format=flowed does.  I'm working 
on a revised draft now, based on some operational experience.

I think a canonical quote form makes sense.  Note that the UI can 
choose to display quoted text in any way it chooses (for example, 
excerpt bars or colors).  I don't want to add any extra markup to 
format=flowed, because it adds complexity for little gain.

If you have specific suggestions for the draft, I'd be interested in 
hearing them.

Subject: Text
Date: Sun, 18 Oct 1998 13:44:07 -0700
From: Ashley Yakeley <[email-masked]>
To: "IETF-822 List" <[email-masked]>
Sender: [email-masked]

I've been reading the archives of ietf-822 on the matter of text and 
soft-wrapping, and I see efforts to deal with the problem seem to be 
sacrificing completeness for the sake of readability and even 
accomodation of USENET quasi-markup conventions.

To understand completeness, here's an attempt to formalise the problem:

I define _codepoint-stream_ as a sequence of zero or more UCS-4 
codepoints excluding 'CR' and 'LF' codepoints. Codepoint-streams 
represent text, and line-separators and paragraph-separators are 
represented by the unambiguous codepoints 'LINE SEPARATOR' (0x2028) and 
'PARAGRAPH SEPARATOR' (0x2029). I'm using this representation solely to 
define a domain for the purposes of formalisation: I'm quite aware that 
these two codepoints are rarely used in practice.

I define _UCS-2 codepoint-stream_ as a codepoint-stream where every 
codepoint is in UCS-2.

I define _octet-stream_ as a sequence of zero or more octets.

I define _7bit octet-stream_ as an octet-stream comforming to the rules 
of '7bit' CTE. Likewise _8bit octet-stream_.

I define _protocol_ as a 'source' domain, a 'code' domain, an 'encode' 
map from source to code, and a 'decode' map from a subset of code to 
source, such that every member x of source, decode(encode(x)) = x.

I define _identity protocol_ as a protocol P where 
 1. P.source is a subset of P.code;
 2. For every x member of P.source, P.encode(x) = x.

A protocol P _represents_ A if A is a subset of P.source.

A protocol P _represents in/as_ A if P.code is a subset of A.

I define _content-transfer-encoding_ as a protocol for representing a 
subset of octet-streams as octet-streams.

A content-transfer-encoding is _complete_ if it represents octet-streams.

A content-transfer-encoding is _7bit-safe_ if it represents as 7bit 
octet-streams.

I define _charset_ as a protocol for representing a subset of 
codepoint-streams as octet-streams.

For instance, I claim that quoted-printable and base64 are each complete 
7bit-safe content-transfer-encodings, and that UTF-8 is a charset.

I define _subprotocol of P_ as a protocol S where:
 1. S.code = P.code;
 2. S.source is a subset of P.source;
 3. For every x member of S.source, S.encode(x) = P.encode(x).

I define _A over B_ for protocols A and B as the protocol C defined by:
 1. C.source = A.source
 2. C.code = B.code
 3. C.encode(x) = B.encode(A.encode(x))
 4. C.decode(x) = A.decode(B.decode(x))
only meaningful is A.code is a subset of B.source.

What protocols are commonly used by UAs? Bear in mind that as far as I 
know no UA actually internally converts to codepoint-streams I've defined 
them directly, but if we use codepoint-streams to represent text 
understood and correctly displayed, most UAs effectively implement 
subprotocols of the protocols of various charsets over various 
content-transfer-encodings.

Now the problem, as I understand it, is to come up with methods of 
representing text in RFC822 mail messages in a way that's as readable as 
possible. These informal 'methods' each involve formal protocols for 
representing some subset of codepoint-streams as 7bit octet-streams 
labelled with MIME-headers: specifically, I don't believe quasi-markup 
such as _italic_, *bold*, >blockquote etc. should get any special 
treatment. I think it's enough for MUAs to insert whatever represents 
hard line-separators between lines when performing >-quoting.

Also, it's sufficient for UAs to effectively implement reasonable 
subprotocols of specified protocols, since UAs are not always going to be 
able to correctly display every defined codepoint of UCS-4.

Desirable fuzzy attributes for such methods (with protocol P) include, in 
no particular order:

- 'Completeness': P.source is the full set of codepoint-streams;

- 'backward-compatible handling' (by existing UAs): for instance, while 
it's my opinion that UAs should display unrecognised text/* as text/plain 
in preference to saving it to some file, I don't believe all existing UAs 
actually do this;

- 'backward-compatible readability': specifically, for a typical text 
string x, and for any 'text/plain' protocol T compatible with US-ASCII, 
T.decode(P.encode(x)) is reasonably readable, given that very few UAs 
understand LINE SEPARATOR and PARAGRAPH SEPARATOR;

- 'applicability': certain existing commonly-used protocols are 
subprotocols of P, most obviously those used by plain-text 
proportional-font soft-wrapping text-editors (e.g. SimpleText);

- 'router-stability': mail-routers are not guaranteed not to filter their 
mail in various ways -- ideally, we want to be sure that for every x 
member of P.source, P.decode(filter(P.encode(x))) = x. At the very least, 
P.decode(filter(P.encode(x))) should reasonably resemble x.

- 'simplicity' of design.

Now not all MIME UAs are MUAs: MIME is used not only by mail and news, 
but also by HTTP and even file-systems (e.g. BeFS). And MIME types and 
options can be used in a number of different scenarios.

For general email with no explicit prior content-negotiation, I'd order 
the desirability of attributes this way:
1. router-stability
2. backward-compatible handling
3. backward-compatible readability
4. completeness
5. applicability
6. simplicity

But for use in typed file-systems and anything involving 
content-negotiation, I see a desire for a method with priorities more 
like this:
1. completeness
2. applicability
3. backward-compatible readability
4. simplicity
5. router-stability
6. backward-compatible handling

Now I've looked at both draft-newman-mime-textpara-00 and 
draft-gellens-format-00, which I assume are latest versions. 
draft-newman-mime-textpara defines a MIME type 'text/paragraph' which can 
be used over suitable CTEs just like text/plain. I consider it a way of 
varying charsets such that CRLF bytes are interpreted as 
paragraph-separators rather than line-separators. In my opinion it's 
ideal for use in typed file-systems, as well as any communication 
featuring content-negotiation:

1. completeness: yes
2. applicability: yes
3. backward-compatible readability: as per qu=6Fted-printable
4. simplicity: yes
5. router-stability: yes, with quoted-printable
6. backward-compatible handling: probably not

...and I think it was premature for Chris Newman to withdraw it.

As for draft-gellens-format, I believe its attempts to handle >-quoted 
text compromise it, mainly because of the various ways people quote text. 
I think if we go that route, we should specify a complete markup language 
of *bold*, _italic_, - bullets, etc., with strict semantics for what any 
given sequence of octets means.

But if >-quote handling were stripped out, draft-gellens-format might 
work for general email:

1. router-stability: not perfect
2. backward-compatible handling: yes
3. backward-compatible readability: yes
4. completeness: not as far as I can tell.
5. applicability: no
6. simplicity: fair

-- 
Ashley Yakeley, Seattle WA

Date: 18 Oct 1998 05:04:52 -0000
Mail-Followup-To: [email-masked]
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Proper way to specify "Do Not Reply"?
Sender: [email-masked]

Vaudreuil, Greg M (Greg) writes:
> What do you suggest a system which has no identifiable sender put in the
> "from" field?  Bogus@bogus? 

In practice people use, e.g.,

   From: [email-masked]

Of course, 822 shouldn't have required a From field in the first place.

---Dan
1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html

DATE: Sat, 17 Oct 1998 15:23:54 -0500
Subject: Worldwide
From: [email-masked]
To: [email-masked]
Sender: [email-masked]

SUBLIMINALLY ENTICE ANY WOMAN TO BE YOURS!
              GUARANTEED.

We know you may be skeptical, but if you're not totally 
satisfied with your sex life and who you're dating you owe 
it to yourself to visit our web site (your choice of 
ENGLISH or ESPANOL) at http://208.166.10.22/ and learn 
how the power of subliminal mind control can change your 
life. It is simply a fact that sexual impulses can be 
awakened and greatly intensified by using subliminal 
commands. We guarantee it!

But, most subliminal enticement tapes don't work. Confused? 
Take 1 minute, go to  http://208.166.10.22/ and read the 
section entitled "THE NUMBER 1 REASON OUR TAPES WORK 
AND THEIRS DON'T!" to find out why.  If nothing else, 
you'll get a good laugh at how downright silly some other 
tapes are.

  EVERYTHING (AND WE MEAN EVERYTHING!) TO GAIN 
              AND NOTHING TO LOSE!

We're so sure that OUR tapes work that every one comes with 
a 100% MONEY BACK GUARANTEE!

Now that you know about the hottest tapes on the Internet, you 
have no excuse not to be successful with any woman you choose. 
If you don't get the facts, you are cheating yourself out of 
HAPPINESS, ROMANCE, GREAT SEX and the TIME OF YOUR LIFE!

Click here http://208.166.10.22/

Millennium Creations, LLC
520 Washington Blvd., Suite 287
Marina Del Rey, Ca. 90292
310-281-6737

To be remove from future mailings, reply to:  
[email-masked] with REMOVE in the subject.
Please understand that our system has filters and any files
larger than 2K, foul language, multiple emails, graphics, 
and/or attachments within the email or it's headers will
automatically delete your email without removal from our 
database.  Only the email address in the from: will be deleted, 
if you have more than one address, please email us using the
email from any account.  Make sure the email address is the 
SAME ADDRESS we used to send the message or it will NOT be
deleted from our database.  You MUST reply with REMOVE in the 
subject line, in order to be removed.  The contents of the
message are NEVER read.  Thank you.

To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: Proper way to specify "Do Not Reply"? 
From: [email-masked]
Date: Fri, 09 Oct 1998 10:07:40 -0400
Sender: [email-masked]

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

On Fri, 09 Oct 1998 09:43:27 +0800, Dave Crocker said:
> "No reply desired" is essentially an annotation, or comment, to the
> recipient.  That is, it does not mean "prohibited".  It is guidance.

Exactly..

> I think a more "natural" way to achieve this is with a null mailbox, along
> the line of:
> 
> 	Reply-to:  No reply needed <>
> 
> but that 822 mandates doesn't permit this.
> 
> Might be worth changing the rules.

OK.. I smell an RFC draft here - is there a better way to address
this?  I can't think of one, and it has nice symmetry with the
RFC821 null return path in the envelopes..

> An entirely different approach is to note that CC: recipients are typically
> not intended to send replies, whereas To: recipients typically are.  Hence,
> using a fake To address and having the real recipients in the CC field
> achieves the stated, human intention, goal.

Yes, the only problem here is that what I was thinking was giving the
recipient MUA enough hints so that if the person hits the reply key,
the MUA can pop up a dialog saying "Are you *sure* you want to reply?
The sender didn't think a reply was a good idea...".  And as we've
seen on some high-traffic IETF lists, having yourself listed in the
cc: field is no bar to sending replies.. ;)

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

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

--==_Exmh_-95983224P--

Date: Fri, 09 Oct 1998 09:43:27 +0800
To: Paul Overell <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Proper way to specify "Do Not Reply"?
Cc: [email-masked]
Sender: [email-masked]

At 04:33 PM 10/8/98 +0100, Paul Overell wrote:
>>Yes, you can point Reply-To: at a bogus address, or a /dev/null, but
>>I can't think of any way to specifically flag a message as "FYI only,
>>no reply desired".  Am I just caffeine-defficient today, or is there
>>in fact no such beast?

"No reply desired" is essentially an annotation, or comment, to the
recipient.  That is, it does not mean "prohibited".  It is guidance.

That said, it doesn't hurt to help the originator communicate this to the
recipient's software, so that software can help the recipient understand
the originator's intent.

The suggestion to use the RFC822 "group" construct in the Reply-To field,
as noted, is an attempt to stay legal with 822.  The other benefit of using
that construct is that it permits adding text, as the group name, which
explains the intent.

I think a more "natural" way to achieve this is with a null mailbox, along
the line of:

	Reply-to:  No reply needed <>

but that 822 mandates doesn't permit this.

Might be worth changing the rules.

An entirely different approach is to note that CC: recipients are typically
not intended to send replies, whereas To: recipients typically are.  Hence,
using a fake To address and having the real recipients in the CC field
achieves the stated, human intention, goal.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1(408)246 8253
<mailto:[email-masked]>                        675 Spruce Drive
                                                  Sunnyvale, CA 94086 USA
Brandenburg Consulting
<http://www.brandenburg.com>                         Tel: +60(19)3299 445
                                              Post Office Box 296, U.P.M.
Fax: +1(408)246 8253                     Serdang, Selangor 43400 MALAYSIA

Date: Thu, 08 Oct 1998 17:20:50 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: RE: Proper way to specify "Do Not Reply"?
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Thu, 8 Oct 1998, Vaudreuil, Greg M (Greg) wrote:
> From RFC 822:
> 
> 	  In  all  cases, addresses in the "From" field
>         must be machine-usable (addr-specs) and may not contain  named
>         lists (groups).
> 
> What do you suggest a system which has no identifiable sender put in the
> "from" field?  Bogus@bogus? 
> 
> My reading of 822 (4.4.2)  is far less clear, but my reading suggests group
> notations would be inappropriate there as well since they should identify
> the singular sender of a message when it is other than the sender.   

You're correct, the From address has to be a "mailbox", rather than an
"address" so it can't be an empty group.

I actually have no problem with the use of <non-mail-user@domain> in the
>From address.  But I have a big problem with probiting replies to that
address.  I don't have a problem with prohibiting replies to a message
with an empty group address in the Reply-To header.

		- Chris

Date: Thu, 8 Oct 1998 12:50:24 -0700
To: [email-masked], [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: Proper way to specify "Do Not Reply"?
Sender: [email-masked]

At 10:39 AM -0400 10/8/98, [email-masked] wrote:

>Yes, you can point Reply-To: at a bogus address, or a /dev/null

What sort of relies are we trying to prevent?  Automated or manual? 
Automated replies should be prohibited with a null return path.  Manual 
replies really can't be prohibited, because (a) the user can always 
override whatever the mailer does, and (b) we don't have a header that 
means "use this reply address instead of any/all others, for all types 
of replies".

I suppose if you're sending a message and want non-delivery reports, 
but don't want users to reply, and the message is only going to one 
user, the suggestion of an empty group in the Reply-To header is the 
best one.

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked], Chris Newman <[email-masked]>
Subject: RE: Proper way to specify "Do Not Reply"?
Date: Thu, 8 Oct 1998 14:37:39 -0500 
Sender: [email-masked]

>From RFC 822:

	  In  all  cases, addresses in the "From" field
        must be machine-usable (addr-specs) and may not contain  named
        lists (groups).

What do you suggest a system which has no identifiable sender put in the
"from" field?  Bogus@bogus? 

My reading of 822 (4.4.2)  is far less clear, but my reading suggests group
notations would be inappropriate there as well since they should identify
the singular sender of a message when it is other than the sender.   

Greg V.

> ----------
> From: 	Chris Newman[SMTP:[email-masked]]
> Sent: 	Thursday, October 08, 1998 1:52 PM
> To: 	[email-masked]
> Subject: 	RE: Proper way to specify "Do Not Reply"?
> 
> On Thu, 8 Oct 1998, Vaudreuil, Greg M (Greg) wrote:
> > VPIM, RFC 2421 suggests using:
> > 
> > 	non-mail-user@domain
> > 
> > for unrepliable messages.  In this case, message originating from a
> > telephone-answering application cannot be replied to.
> > RFC 2421 prohibits replies to this special-case address by conforming
> > systems.
> 
> Hopefully most implementors will ignore that prohibition on the grounds it
> violates the more important full-standard requirement (RFC 1123, 5.2.16)
> that the local-part is uninterpreted except by the system named on the
> right-hand-side. 
> 
> I definitely prefer the empty group address for this purpose:
> 
> Reply-To: Please Don't Reply:;
> 
> It fits RFC 822 syntax and has an obvious interpretation without any
> layering violation.
> 
> 		- Chris
> 

Date: Thu, 08 Oct 1998 11:52:25 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: RE: Proper way to specify "Do Not Reply"?
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: [email-masked]
Sender: [email-masked]

On Thu, 8 Oct 1998, Vaudreuil, Greg M (Greg) wrote:
> VPIM, RFC 2421 suggests using:
> 
> 	non-mail-user@domain
> 
> for unrepliable messages.  In this case, message originating from a
> telephone-answering application cannot be replied to.
> RFC 2421 prohibits replies to this special-case address by conforming
> systems.

Hopefully most implementors will ignore that prohibition on the grounds it
violates the more important full-standard requirement (RFC 1123, 5.2.16)
that the local-part is uninterpreted except by the system named on the
right-hand-side. 

I definitely prefer the empty group address for this purpose:

Reply-To: Please Don't Reply:;

It fits RFC 822 syntax and has an obvious interpretation without any
layering violation.

		- Chris

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked], Paul Overell <[email-masked]>
Subject: RE: Proper way to specify "Do Not Reply"?
Date: Thu, 8 Oct 1998 11:06:52 -0500 
Sender: [email-masked]

VPIM, RFC 2421 suggests using:

	non-mail-user@domain

for unrepliable messages.  In this case, message originating from a
telephone-answering application cannot be replied to.
RFC 2421 prohibits replies to this special-case address by conforming
systems.

Greg V.

> ----------
> From: 	Paul Overell[SMTP:[email-masked]]
> Sent: 	Thursday, October 08, 1998 10:33 AM
> To: 	[email-masked]
> Subject: 	Re: Proper way to specify "Do Not Reply"?
> 
> In article <[email-masked]>,
> [email-masked] writes
> >While discussing a brokked email system at a well-known ISP that is
> >generating unreplyable messages, a co-worker asked me what the proper
> >way to *specify* that no reply is to be attempted.  I was stumped.
> >
> >Yes, you can point Reply-To: at a bogus address, or a /dev/null, but
> >I can't think of any way to specifically flag a message as "FYI only,
> >no reply desired".  Am I just caffeine-defficient today, or is there
> >in fact no such beast?
> >
> >And if there isn't, should there be?
> >
> 
> For news, draft-ietf-usefor-article-01.txt suggests
> 
>         Reply-To: <>
> 
> analogous to the empty SMTP reverse path, but this isn't RFC822
> conformant.
> 
> 
> 
> An empty group has valid RFC822 syntax, it might have the desired
> effect.
> 
>         Reply-To: "FYI only, no reply desired":;
> 
> 
> -- 
> Paul Overell                                        T U R N P I K E  Ltd
> 

Date: Thu, 8 Oct 1998 16:33:24 +0100
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: Proper way to specify "Do Not Reply"?
Sender: [email-masked]

In article <[email-masked]>,
[email-masked] writes
>While discussing a brokked email system at a well-known ISP that is
>generating unreplyable messages, a co-worker asked me what the proper
>way to *specify* that no reply is to be attempted.  I was stumped.
>
>Yes, you can point Reply-To: at a bogus address, or a /dev/null, but
>I can't think of any way to specifically flag a message as "FYI only,
>no reply desired".  Am I just caffeine-defficient today, or is there
>in fact no such beast?
>
>And if there isn't, should there be?
>

For news, draft-ietf-usefor-article-01.txt suggests

        Reply-To: <>

analogous to the empty SMTP reverse path, but this isn't RFC822
conformant.

An empty group has valid RFC822 syntax, it might have the desired
effect.

        Reply-To: "FYI only, no reply desired":;

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

To: [email-masked]
Subject: Proper way to specify "Do Not Reply"?
From: [email-masked]
Date: Thu, 08 Oct 1998 10:39:32 -0400
Sender: [email-masked]

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

While discussing a brokked email system at a well-known ISP that is
generating unreplyable messages, a co-worker asked me what the proper
way to *specify* that no reply is to be attempted.  I was stumped.

Yes, you can point Reply-To: at a bogus address, or a /dev/null, but
I can't think of any way to specifically flag a message as "FYI only,
no reply desired".  Am I just caffeine-defficient today, or is there
in fact no such beast?

And if there isn't, should there be?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

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

--==_Exmh_281133560P--

To: "Al Costanzo" <[email-masked]>
Cc: "MIME" <[email-masked]>, "IETF-822" <[email-masked]>
Subject: Re: utf-8 vs Base64 in LZJU90 and FS 
From: [email-masked]
Date: Thu, 08 Oct 1998 09:35:25 -0400
Sender: [email-masked]

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

On Thu, 08 Oct 1998 06:04:59 EDT, "Al Costanzo" said:
> I have pondered the request to not use utf-8 and use base64.

Um.. Is this one request, or two?

utf-8 is a *charset*, just like iso8859-1 or us-ascii.

base64 is a content-transfer-encoding, used to keep brain-dead MTAs
from screwing up your utf-8, or iso8859-1, or other non-7-bit-clean
charset/binary data.

> LZJU90 uses UTF-8 because brain dead mailers will only understand
> the 7 bit ascii subset of UTF-8 where mailers that understand utf-8
> will make better use of the encoder.

Can you please re-explain this?  There appears to be a confusion regarding
the difference between a charset and a CTE.  A compression algorithm
should be totally immune to charset issues (otherwise, how would you
compress a binary object?).

> Could someone expand on the reason utf-8 should be not used?

For what it's worth, your mail showed up with a base64 encoding wrapped
around what was *flagged* as charset=utf-8.  However, RFC2045, section
4.1.2, states:

   In general, composition software should always use the "lowest common
   denominator" character set possible.  For example, if a body contains
   only US-ASCII characters, it SHOULD be marked as being in the US-
   ASCII character set, not ISO-8859-1, which, like all the ISO-8859
   ....

My MUA generated a warning message that utf-8 was an unknown charset,
but tried its hardest to display it as 8859-1 (which just *happened*
to suceed).  Some MUAs throw up their hands entirely.  That's why you
shouldn't flag it as utf-8 unless it is needed.  I didn't see any non
us-ascii characters in the mail.. and after downgrading to us-ascii,
the base64 CTE wasn't needed either.

/Valdis (who now gets to go figure out why his MUA was able to
display the base64/utf-8 correctly, but Lost Big Time on the reply...)

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

--==_Exmh_16000168P--

Reply-To: "Al Costanzo" <[email-masked]>
From: "Al Costanzo" <[email-masked]>
To: <[email-masked]>
Cc: "MIME" <[email-masked]>, "IETF-822" <[email-masked]>
Subject: utf-8 vs Base64  in LZJU90 and FS
Date: Thu, 8 Oct 1998 06:04:59 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0074_01BDF281.94B16A80
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------=_NextPart_000_0074_01BDF281.94B16A80
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------=_NextPart_000_0074_01BDF281.94B16A80--

Date: Wed, 7 Oct 1998 11:47:28 -0700
To: "Clive D.W. Feather" <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00.txt
Sender: [email-masked]

At 5:49 PM +0100 10/6/98, Clive D.W. Feather wrote:

>(1) It is unclear whether the last line of a paragraph has a space at the
>end or not.

Assuming you have empty lines between your paragraphs, all lines except 
the empty one would have the trailing single space.  I will clarify 
this in the next version.

>(2) I think you need to do something about the Usenet sig separator string.
>The simplest option is probably to declare it as a special case when the
>first line of a flowing paragraph.

Yes, I agree.  At first I thought it wasn't worth the complexity of 
special-casing it, but I've been convinced otherwise.

Date: Tue, 6 Oct 1998 17:49:19 +0100
From: "Clive D.W. Feather" <[email-masked]>
To: [email-masked]
Subject: draft-gellens-format-00.txt
Sender: [email-masked]

[I am not on this mailing list, but happened to come across the draft.]

I like the idea in general. Two comments:

(1) It is unclear whether the last line of a paragraph has a space at the
end or not. In other words, do I write (using _ to show space):

    para_1_line_1_text_
    para_1_line_2_text_
    para_1_line_3_text_

    para_2_only_line_text_

or:

    para_1_line_1_text_
    para_1_line_2_text_
    para_1_line_3_text

    para_2_only_line_text

?

(2) I think you need to do something about the Usenet sig separator string.
The simplest option is probably to declare it as a special case when the
first line of a flowing paragraph.

-- 
Clive D.W. Feather       | Work: <[email-masked]>   | Tel: +44 1733 705000
Regulation Officer       |   or: <[email-masked]>  |  or: +44 973 377646
London Internet Exchange | Home: <[email-masked]> | Fax: +44 1733 353929
(on secondment from Demon Internet)