Subject: Re: Regarding SMTP Message specification syntax ...
From: Bruce Lilly <[email-masked]>
To: dhananjay <[email-masked]>
Cc: [email-masked]
Date: Tue, 30 Sep 2003 23:53:47 -0400
List-Id: <ietf-822.imc.org>

dhananjay wrote:
> Hi,
>     If user enters "." or "CR" as a first character for a response to 
> DATA command. Then, should that be treated as illegal message format ?
>     I went through RFC822 in search of this, but could not gain much 
> from "Message specification section 4.1" with regards to this issue.
>     It would be really great, if I can get some pointers to resolve this 
> issue.

If you mean a completely empty message, i.e. no body and no header, then that
is not legal. RFC 822 section 4.1 gives the message syntax; date, originator
(From), and at least one recipient (To, Cc, Bcc) header fields are mandatory:

      message     =  fields *( CRLF *text )       ; Everything after
                                                  ;  first null line
                                                  ;  is message body

      fields      =    dates                      ; Creation time,
                       source                     ;  author id & one
                     1*destination                ;  address required
                      *optional-field             ;  others optional

RFC 2822 is somewhat more liberal; it does not require a recipient field.
See the table in RFC 2822 section 3.6.

From: "dhananjay" <[email-masked]>
To: <[email-masked]>
Subject: Regarding SMTP Message specification syntax ...
Date: Tue, 30 Sep 2003 18:54:35 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_023B_01C38784.4A938300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,
    If user enters "." or "CR" as a first character for a response to DATA
command. Then, should that be treated as illegal message format ?
    I went through RFC822 in search of this, but could not gain much from
"Message specification section 4.1" with regards to this issue.
    It would be really great, if I can get some pointers to resolve this
issue.

Regards,
Dhananjay.

------=_NextPart_000_023B_01C38784.4A938300
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; If user enters "." =
or "CR" as a=20
first character for a response to DATA command. Then, should that be =
treated as=20
illegal message format ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;I went through =
RFC822 in=20
search of this, but could not gain much from "Message specification =
section 4.1"=20
with regards to this issue.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; It would be really =
great, if I=20
can get some pointers to resolve this issue.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>Regards,<BR>Dhananjay.</FONT></DIV></BODY></HTML>

------=_NextPart_000_023B_01C38784.4A938300--

Date: 30 Sep 2003 14:24:00 +0200
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
To: [email-masked]
Subject: Re: Why do MIME imlementations sometimes fail
Sender: [email-masked]

Nathaniel Borenstein <[email-masked]> schrieb/wrote:
> You're certainly right here -- most software developers are
> monolingual whether or not they're Americans.  It's just that most of
> them are Americans, hence my hasty overgeneralization.

The problem ist not monoligualism but monoscriptualism. Even developers
that have heard of other languages don't have an idea about non-Latin
scripts (or even scripts that need other characters than thos from the
Latin-1 repertoire).

A German developer speaking German, English, French, Spanish and   
Italian does not know anything about the problems of a Czech user who
needs Latin-2.

Claus
-- 
http://www.faerber.muc.de/

Date: Mon, 29 Sep 2003 15:02:27 +0200
To: Nathaniel Borenstein <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Why do MIME imlementations sometimes fail
Cc: [email-masked]
Sender: [email-masked]

At 23:27 -0400 03-09-27, Nathaniel Borenstein wrote:
>I seriously doubt that this is a standards issue, though 
>-- I think it's a combination of a cultural issue 
>(Americans are mostly monolingual) and a simple technical 
>issue: it's really *hard* to build a good monolingual user 
>interface, and anyone who wants to do so is unlikely to 
>find MIME encoding to be one of his greatest challenges. 
>In many cases, I think what's failing is not so much the 
>standards as the user interface.  -- Nathaniel

We have developed a non-standard messaging system which
supports multi-linguality and translation, including both
human and machine translation. One issue we have not fully
solved is how to combine knowledge about the readers
capability of reading different languages with the
availability of different quality translations, such as
original in German, machine translation to English, which
language version should be shown to a user who has English
as native language but can read some German!

In our system, multilinguality is defined at a rather low
level, so that every object can be specified in more than
one language.

We have however not handled the problem of different
languages in different parts of the same message.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Mon, 29 Sep 2003 14:57:01 +0200
To: IETF RFC-822 list <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Cc: IETF mailing list on e-mail headers <[email-masked]>
Sender: [email-masked]

At 02:29 +0000 03-09-28, Adam M. Costello wrote:
>They use iso-2022-jp, which is a single character encoding (charset)
>that uses a few ISO 2022 escape sequences to switch between exactly four
>coded character sets (ASCII and three Japanese sets).

ISO 2022 is a general standard for specifying "switch
codes" between different character sets. It has never
become widely used except in Japan, I believe.ISO 2022-jp
is probably a subset of ISO 2022.

Unicode, of course, solves the same problem in a better way.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sun, 28 Sep 2003 08:16:45 -0700 (PDT)
From: [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Cc: IETF mailing list on e-mail headers <[email-masked]>
Sender: [email-masked]

> If you want to support a great number of coded character sets, I guess
> one approach would be to define a new media type that doesn't use a
> charset parameter, and instead provides its own internal charset tagging
> (so it would not merely support many coded character sets, but many
> character encodings).  Another approach is to create a general iso-2022
> charset that includes all registered 2022-compatible coded character
> sets.  Either way there would be a deployment hurdle to overcome.

The approach of a new media type that provides its own internal charset
tagging was tried in the very version of MIME. We called it text/richtext.
See RFC 1341 section 7.1.3.

Text/richtext was not successful.

As for the approach of creating a general iso-2022 charset, I again note this
idea was discussed at considerable length when MIME was first designed, and
rejected. I'm sure the discussion can be found in the list archives if anybody
cares.

It is also important to note that all this happened before Unicode, UTF-8, and
UTF-16. The need for multiple charset support was therefore much greater at the
time, and yet it was unsufficient to the task.

I again have to ask "where's the beef"? What vital piece of functionality is
provided by any of these schemes that cannot be accomplished with text/plain
and utf-8? We have a universal character set now that subsumes almost
previously defined charsets. While it is true that Unicode support is
nontrivial, it is axiomatic that supporting a vast array of charsets that
collectively provide about the same functionality piecemeal is even more
difficult.

				Ned

Date: 28 Sep 2003 16:13:00 +0200
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
To: [email-masked]
Subject: Re: Why do MIME imlementations sometimes fail
Sender: [email-masked]

Keith Moore <[email-masked]> schrieb/wrote:
> And in fact, it's still possible.  Nothing stops Jacob or anyone else
> from defining a new type of body part that supports text of multiple
> character encodings.

Or you define a charset that can switch encodings with escape  
sequences... wait, that's ISO-2022.

Claus
-- 
http://www.faerber.muc.de/

Date: Sun, 28 Sep 2003 10:20:24 -0400
Subject: Re: MIME roadmap (was Re: Dual names [...] in e-mail addresses?)
Cc: "Abhijit Menon-Sen" <[email-masked]>, "Keith Moore" <[email-masked]>, <[email-masked]>
To: "Al Costanzo" <[email-masked]>
From: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

Believe me, I've thought about that one a lot.  First of all, I don't 
think we necessarily need to make any changes that aren't backwards 
compatible, which is the only way MIME-version would need to be 
changed.  If there were (and they were important enough), I'd be 
willing (sigh) to revisit the issue if necessary and see if there's any 
way to move MIME-version off the mark, although I know it would be very 
hard.  But I don't know of any needed changes that would *require* a 
MIME-version change, do you? -- Nathaniel

On Saturday, September 27, 2003, at 11:25  PM, Al Costanzo wrote:

> If the group cannot fix the mime version number stuck at version 1.0 
> since
> day one dont bother writing anything. :(
>
> Al
> ----- Original Message -----
> From: "Nathaniel Borenstein" <[email-masked]>
> To: "Abhijit Menon-Sen" <[email-masked]>
> Cc: "Keith Moore" <[email-masked]>; <[email-masked]>
> Sent: Saturday, September 27, 2003 11:15 PM
> Subject: Re: MIME roadmap (was Re: Dual names [...] in e-mail 
> addresses?)
>
>
>>
>> On Friday, September 26, 2003, at 11:50  PM, Abhijit Menon-Sen wrote:
>>
>>> Yes. (And I'd be happy to write it, if nobody else wants to.)
>>
>> I suspect that this will be most valuable if a whole bunch of us write
>> it together, actually.  But before anyone starts writes anything, I
>> think it's worth clarifying our goals, which might be:
>>
>> -- Providing a tour of the MIME-related RFC's for new implementors
>>
>> -- Updating various of the MIME RFC's to bring them mutually up to 
>> date
>> and in sync with RFC 2822
>>
>> -- Fixing specific minor problems with MIME that have accumulated in
>> the last decade.  (I suspect this list is small but non-zero.)
>>
>> Are we talking about some or all of the above, and are they best 
>> viewed
>> as a single task or multiple tasks?  For my part, I'm not interested 
>> in
>> doing this more than once every decade or so, and would therefore be
>> more interested in something reasonably comprehensive.  -- Nathaniel
>>
>>
>

Date: Sun, 28 Sep 2003 10:18:51 -0400
Subject: Re: Why do MIME imlementations sometimes fail
Cc: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked], [email-masked]
To: [email-masked]
From: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

--Apple-Mail-18-552185593
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

On Sunday, September 28, 2003, at 01:24  AM, [email-masked] 
wrote:

> But is this a peculiarly American problem? I'm sorry, but I don't 
> think so. In
> fact, in my experience the bias towards localization (or if you prefer,
> unilingualism) committed by Americans is no worse than what's been done
> elsewhere.

You're certainly right here -- most software developers are monolingual 
whether or not they're Americans.  It's just that most of them are 
Americans, hence my hasty overgeneralization.

> Humph. I don't know if it counts, but the software I work on 
> personally is
> internationalized, not localized.

Well, I fully believe that this is the intention, and not being 
familiar with that software I of course can't say that it doesn't do it 
well.  I'm just saying that I haven't yet personally seen any software 
that I thought did it well -- and I work nowadays for a company that 
puts a lot of time into trying to do so.  Maybe I'm too picky, but I 
think there are precious few user interfaces that do a good job of 
making it easy to write in *one* language, and I have yet to see one 
that I would endorse as doing a good job of more than one.

Again, this is completely a question of me being critical of the user 
interface, and I think the role of standards here is minor at best.  -- 
Nathaniel
--Apple-Mail-18-552185593
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

On Sunday, September 28, 2003, at 01:24  AM, [email-masked]
wrote:

<excerpt><fixed>But is this a peculiarly American problem? I'm sorry,
but I don't think so. In

fact, in my experience the bias towards localization (or if you prefer,

unilingualism) committed by Americans is no worse than what's been done

elsewhere.

</fixed></excerpt>

You're certainly right here -- most software developers are
monolingual whether or not they're Americans.  It's just that most of
them are Americans, hence my hasty overgeneralization.<fixed>

</fixed>

<excerpt><fixed>Humph. I don't know if it counts, but the software I
work on personally is

internationalized, not localized. 

</fixed></excerpt>

Well, I fully believe that this is the intention, and not being
familiar with that software I of course can't say that it doesn't do
it well.  I'm just saying that I haven't yet personally seen any
software that I thought did it well -- and I work nowadays for a
company that puts a lot of time into trying to do so.  Maybe I'm too
picky, but I think there are precious few user interfaces that do a
good job of making it easy to write in *one* language, and I have yet
to see one that I would endorse as doing a good job of more than one.

Again, this is completely a question of me being critical of the user
interface, and I think the role of standards here is minor at best. 
-- Nathaniel
--Apple-Mail-18-552185593--

Date: Sun, 28 Sep 2003 08:10:47 -0400
From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

On Sun, 28 Sep 2003 03:45:21 +0200
Jacob Palme <[email-masked]> wrote:

> 
> At 17:53 -0400 03-09-27, Keith Moore wrote:
> >I can see how having non-ascii characters in an email address can
> >improve the mnenomic value for original messages, but what is the
> >value added for using them in replies?
> 
> If you have a national-language e-mail address,
> then of course you prefer to see it always
> when communicating in your national language.

that's easy to arrange - just set up your mail reader so that it
rewrites your address when it accepts incoming mail.

Date: Sun, 28 Sep 2003 03:45:21 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

At 17:53 -0400 03-09-27, Keith Moore wrote:
>I can see how having non-ascii characters in an email address can
>improve the mnenomic value for original messages, but what is the
>value added for using them in replies?

If you have a national-language e-mail address,
then of course you prefer to see it always
when communicating in your national language.

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

Date: Sat, 27 Sep 2003 22:24:53 -0700 (PDT)
From: [email-masked]
Subject: Re: Why do MIME imlementations sometimes fail
To: Nathaniel Borenstein <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > The particular challenge of a format whose major feature is to allow for
> > multiple charsets would be to provide something that's superior to
> > utf-8 text/plain.

> Precisely.  But Jacob is also right on target when he writes:

> > One interesting thing I have noted is that localized
> > software often works well when a user only uses his
> > national language, but not when a local user wants to use
> > another language than his own.

> Even more deeply than a bias towards English, American programmers are
> biased towards unilingualism, and this bias is simply translated into
> any other single language.

I'm not sure of the cause, but it is undeniably true that lots of software
suffers from being simply localized rather than being fully internationalized. 

But is this a peculiarly American problem? I'm sorry, but I don't think so. In
fact, in my experience the bias towards localization (or if you prefer,
unilingualism) committed by Americans is no worse than what's been done
elsewhere.

Examples of this I've seen include:

(1) There are a large number of Japanese email clients that not only are
    highly Japanese-centric, they also adopt their own set of peculiar
    conventions for encoded word handling that doesn't interoperate well
    with standards-compliant software that supports Japanese produced elsewhere.
    There appears to be no interesting in fixing this either, which forces
    other clients that wish to interoperate to go through all sorts of
    contortions.

(2) GB18030. For those of you who aren't familiar with it, this is a *new*
    coded character set that is backwards compatible with GBK but includes
    the full Unicode repetoire. (Actually, the degree of backwards
    compatibility is somewhat debatable, since GBK only uses one and two
    octet sequences wherease GB18030 uses one, two and four octet sequences.
    I view the changes that existing GBK software will handle this well as
    remote in the extreme.) The Chinese government is mandating support for
    this in software sold in China. Now, while there might be sufficient
    justification for defining such a thing for limited applications where
    GBK compatibility is necessary. But if it comes into general use it will
    end up stifling internationalization in favor of localization.

(3) Even properly internationalized software has to provide language-specific
    text. And the expertise for doing this sort of work often doesn't exist
    within a given programming team and has to be done else, often by some
    other company in some other country. Yet I've found on more than one
    occasion that such work comes back as a total botch -- the team ignored
    the need to follow the internationalization paradigm and localized 
    things instead.

> I have yet to see a mail tool (or actually
> any computing environment) that does a really good job of supporting
> people trying to communicate regularly in multiple languages.

Humph. I don't know if it counts, but the software I work on personally is
internationalized, not localized. Our design review process includes specific
checks to try and make sure this is so. And so does our QA process. (As a
result when testing it often suffices to install a single copy of our software
for multiple different language tests since we try and provide everything in
the base installation.)

Mind you, I don't claim our software is free from internationalization
problems. We have legacy code in some other parts of the product that is
intrinsicly incapable of being properly internationalized. We have a couple of
different charset translators -- obviously two is one too many. And so on.
There's always work to do, although I sure wish it didn't have to include so
many hacks for broken clients and support for GB18030.

Now, did this all come to pass because we're all such good network citizens at
Sun? Not hardly. The motivation for this is financial, plain and simple. A
significant portion of Sun's revenue comes from other countries. Not only do
folks in other countries demand that our software support their languages, they
increasingly demand the ability for a single installation or set of
installations to support multiple user populations using different languages
and charsets. (Globalization creates strange bedfellows, and some of the
mixtures of languages and charsets we're asked to support are fairly bizarre.)

I find it very hard to believe that other companies aren't in the same position
as Sun and haven't instituted similar development strategies as a result. It is
simply good business to do so.

Of course financial motivation does have a downside: Languages that don't have
a revenue stream attached don't get supported. (We do try and provide the hooks
so customers can do their own translations and so forth, but it still doesn't
work out of the box.) I doubt that Sun is unique in this regard either.

> I seriously doubt that this is a standards issue, though -- I think
> it's a combination of a cultural issue (Americans are mostly
> monolingual)

Humph again. Maybe I'm just lucky, but our team includes folks fluent in
French, Mandarin, Cantonese, Japanese, several Indian languages I won't
embarass myself trying to name, and no doubt several others I'm unaware of.
Although I happen to be fairly knowledgable about charsets and the like, I'm
basically a monolinguistic ignoramus by comparison with the many of the others
I work with.

I do note that no amount of QA beats having someone on your team using your
software on a daily basis in some other language. 

> and a simple technical issue: it's really *hard* to build
> a good monolingual user interface, and anyone who wants to do so is
> unlikely to find MIME encoding to be one of his greatest challenges.
> In many cases, I think what's failing is not so much the standards as
> the user interface.  -- Nathaniel

True enough. I haven't done serious UI work in a long time, and I have to say
I'm thankful I haven't had to.

				Ned

Date: Sat, 27 Sep 2003 21:47:45 -0700 (PDT)
From: [email-masked]
Subject: Re: Why do MIME imlementations sometimes fail
To: Jacob Palme <[email-masked]>
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

> > And in fact, it's still possible.  Nothing stops Jacob or anyone else from
> > defining a new type of body part that supports text of multiple character
> > encodings.  The challenge is in making it technically sound and enough of a
> > win over HTML (which is already widely supported) that people want to
> > implement it and use it.

> Are not Japanese people already doing this in order to
> allow Japanese e-mail to contain a mixture between English
> and Japanese text, by using ISO 2022 character set switch
> marks in the text.

Not really. You're referring to the iso-2022-jp charset, which is basically a
combination of the ASCII, JIS X 0201, and JIS X 0208 coded character sets
using the ISO-2022 character encoding scheme. It does not allow for selection
of arbitrary coded character sets, let alone the selection of multiple
charsets.

While ISO-2022 does allow for the use of many (but by no means all) coded
character sets, the idea of defining a text format or a charset that allowed
for selection of arbitrary coded character sets was considered early on in the
MIME work -- and rejected. Several other charsets based on ISO-2022 have
been defined, but they all have the same sort of structure as iso-2022-jp.

				Ned

Date: Sat, 27 Sep 2003 21:44:03 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Nathaniel Borenstein <[email-masked]>
CC: [email-masked]
Subject: Re: MIME roadmap (was Re: Dual names [...] in e-mail addresses?)
Sender: [email-masked]

Nathaniel,

NB> Are we talking about some or all of the above, and are they best viewed 
NB> as a single task or multiple tasks?  For my part, I'm not interested in 
NB> doing this more than once every decade or so, and would therefore be 
NB> more interested in something reasonably comprehensive.  -- Nathaniel

The problem is when this sort of effort takes 5 years.

I suggest that the target for the effort be 9 months, maximum.  And stick to
it.   In fact, 6 months would be better.

That will filter out all sorts of cruft.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Sat, 27 Sep 2003 21:41:55 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Adam,

AMC> Unfortunately this tells the recipient to send the reply to both
AMC> addresses, which is not what the sender really wants.

 good point.  in effect, that means semantics like multipart/alternative,
 rather than multipart/mixed.  In fact, as I recall, that was the difference
 between the RFC 733 constructs for an individual having multiple addresses,
 versus a group with multiple addresses.

 this is a nice example of the reason this topic is probably more complicated
 that it would seem, at first consideration.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Sat, 27 Sep 2003 21:36:04 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Jacob Palme <[email-masked]>
CC: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob,

>>But, again, this has nothing to do with MIME.

JP> I did not especially say that this was a MIME issue,

I was responding to your comment:

JP> One of the areas where MIME still, ten years after its
JP> introduction, often fails is when people copy e-mail

so, please forgive my misunderstanding that your statement that MIME had a
failure really meant that it was not a MIME issue.

JP> This may be an issue which IETF has already discussed and
JP> made a decision about, I have not been able to get funding
JP> to participate in much IETF work in the last years, so I
JP> may have missed work already done.

The work was done in the late '70s, when RFC733 was written.

As some of the other postings have suggested, the issues that are created by
having IDN-based addresses are likely to be more complicated -- and I suspect
more contingent -- than simply needing to list multiple addresses.

This is a topic that would be dangerous to hypothesize about too much, since
we have a poor track record predicting things.  When we have concrete data
about user needs, we can design a solution for them.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Sat, 27 Sep 2003 23:27:48 -0400
Subject: Re: Why do MIME imlementations sometimes fail
Cc: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked], [email-masked]
To: [email-masked]
From: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

--Apple-Mail-14-513122745
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

On Saturday, September 27, 2003, at 11:45  AM, [email-masked] 
wrote:

> The particular challenge of a format whose major feature is to allow 
> for
> multiple charsets would be to provide something that's superior to 
> utf-8
> text/plain.

Precisely.  But Jacob is also right on target when he writes:

> One interesting thing I have noted is that localized
> software often works well when a user only uses his
> national language, but not when a local user wants to use
> another language than his own.

Even more deeply than a bias towards English, American programmers are 
biased towards unilingualism, and this bias is simply translated into 
any other single language.  I have yet to see a mail tool (or actually 
any computing environment) that does a really good job of supporting 
people trying to communicate regularly in multiple languages.

I seriously doubt that this is a standards issue, though -- I think 
it's a combination of a cultural issue (Americans are mostly 
monolingual) and a simple technical issue: it's really *hard* to build 
a good monolingual user interface, and anyone who wants to do so is 
unlikely to find MIME encoding to be one of his greatest challenges.  
In many cases, I think what's failing is not so much the standards as 
the user interface.  -- Nathaniel
--Apple-Mail-14-513122745
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

On Saturday, September 27, 2003, at 11:45  AM,
[email-masked] wrote:

<excerpt><fixed>The particular challenge of a format whose major
feature is to allow for

multiple charsets would be to provide something that's superior to
utf-8

text/plain. 

</fixed></excerpt>

Precisely.  But Jacob is also right on target when he writes:

<excerpt>One interesting thing I have noted is that localized

software often works well when a user only uses his

national language, but not when a local user wants to use

another language than his own. 

</excerpt>

Even more deeply than a bias towards English, American programmers are
biased towards unilingualism, and this bias is simply translated into
any other single language.  I have yet to see a mail tool (or actually
any computing environment) that does a really good job of supporting
people trying to communicate regularly in multiple languages.  

I seriously doubt that this is a standards issue, though -- I think
it's a combination of a cultural issue (Americans are mostly
monolingual) and a simple technical issue: it's really *hard* to build
a good monolingual user interface, and anyone who wants to do so is
unlikely to find MIME encoding to be one of his greatest challenges. 
In many cases, I think what's failing is not so much the standards as
the user interface.  -- Nathaniel
--Apple-Mail-14-513122745--

Date: Sat, 27 Sep 2003 23:15:22 -0400
Subject: Re: MIME roadmap (was Re: Dual names [...] in e-mail addresses?)
Cc: Keith Moore <[email-masked]>, [email-masked]
To: Abhijit Menon-Sen <[email-masked]>
From: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

On Friday, September 26, 2003, at 11:50  PM, Abhijit Menon-Sen wrote:

> Yes. (And I'd be happy to write it, if nobody else wants to.)

I suspect that this will be most valuable if a whole bunch of us write 
it together, actually.  But before anyone starts writes anything, I 
think it's worth clarifying our goals, which might be:

-- Providing a tour of the MIME-related RFC's for new implementors

-- Updating various of the MIME RFC's to bring them mutually up to date 
and in sync with RFC 2822

-- Fixing specific minor problems with MIME that have accumulated in 
the last decade.  (I suspect this list is small but non-zero.)

Are we talking about some or all of the above, and are they best viewed 
as a single task or multiple tasks?  For my part, I'm not interested in 
doing this more than once every decade or so, and would therefore be 
more interested in something reasonably comprehensive.  -- Nathaniel

Date: Sun, 28 Sep 2003 02:29:36 +0000
From: "Adam M. Costello" <[email-masked]>
To: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

Bruce Lilly wrote:

> A named group may suffice where the syntax permits an address
> rather than a single mailbox, e.g.:
>
>   Reply-To: Bruce Lilly: <[email-masked]>, <[email-masked]>;
>
> [obviously the phrase could use RFC 2047 encoded-words, and
> an IDN could be used in any of the group mailboxes]

Unfortunately this tells the recipient to send the reply to both
addresses, which is not what the sender really wants.

IDNA and IMAA will allow an address to be compatible with both
ASCII-only software and Unicode-enabled software.  But they won't
allow an address to be user-friendly for both English-only users and
no-English users.  As messages get copied, forwarded, and replied to,
addresses get copied from one header field to another, and there's no
telling who will end up looking at them.  That is the motivation for
trying to think of a way for two addresses to be paired up and copied
together, so that both remain available for display.

On the other hand, the body of the message will typically not be
user-friendly to both English-only users and no-English users,
so any effort to support dual addresses might be mostly wasted
anyway.  (Although the body could be non-textual, or could be a
multipart/alternative with translations into multiple languages.)

Anyway, here's yet another idea:

From: "=?iso-8859-1?q?G=F6ran=20M=FCller?= / Goran Muller
 <[email-masked]>" <[email-masked]>

Ancient software will display it exactly as above, while MIME-enabled
IMAA-enabled software will display it as:

From: "Göran Müller / Goran Muller
 <[email-masked]>" <[email-masked]>

I think this will survive replies, and will survive getting copied
into a message body.  In the latter case, the ASCII parts will get
copied verbatim, and the non-ASCII parts will get copied either in
their display form or their encoded form.  In any case, both forms will
be available to the recipient to view and to paste back into message
headers.

Keith Moore wrote:

> Nothing stops Jacob or anyone else from defining a new type of
> body part that supports text of multiple character encodings.  The
> challenge is in making it technically sound and enough of a win over
> HTML (which is already widely supported) that people want to implement
> it and use it.

Note that HTML doesn't allow mixing of multiple character encodings.  It
allows mixing arbitrary Unicode characters together with *one* character
encoding.  That's more than you can do with text/plain, but less than
the multi-charset support that Jacob was hoping for.

Jacob Palme <[email-masked]> replied:

> Are not Japanese people already doing this in order to allow Japanese
> e-mail to contain a mixture between English and Japanese text, by
> using ISO 2022 character set switch marks in the text.

They use iso-2022-jp, which is a single character encoding (charset)
that uses a few ISO 2022 escape sequences to switch between exactly four
coded character sets (ASCII and three Japanese sets).

If you want to support a great number of coded character sets, I guess
one approach would be to define a new media type that doesn't use a
charset parameter, and instead provides its own internal charset tagging
(so it would not merely support many coded character sets, but many
character encodings).  Another approach is to create a general iso-2022
charset that includes all registered 2022-compatible coded character
sets.  Either way there would be a deployment hurdle to overcome.

AMC

Date: Sat, 27 Sep 2003 17:53:33 -0400
From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

> What I did ask is if it is probable that people in the
> future are going to want dual e-mail adresses, not only a
> display version and an ACE version but two separate
> addresses, like "[email-masked]" for national use and
> "[email-masked]" for international use.
> 
> And if people are going to want this, would it help them if
> the standards supported this, for example by allowing the
> "From" and "Sender" headers to specify both the national
> and the international name, so that the recipient could
> choose which of these names to use, dependent on whether
> the recipient can handle national names or not.

why does the recipient care which names are used in replies?
the message goes to the same place either way.
rfc 2047 already provides a way to have the name displayed correctly
in the message header.  

I can see how having non-ascii characters in an email address can
improve the mnenomic value for original messages, but what is the
value added for using them in replies?

Keith

Date: Sat, 27 Sep 2003 16:40:24 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

> If the "roadmap" is to be simply a list of the MIME-related RFCs, it
> would be of little value except perhaps as a working document leading
> to consolidation.

if the intended audience is new or recent implementors, a list of RFCs along
with recommendations as to which of those RFCs need to be implemented might
indeed be useful.

such a document might also provide an opportunity to resolve conflicts
between the different specs, emphasize things in existing specs that need
emphasis, provide implementation advice, etc.

Date: Sat, 27 Sep 2003 20:52:14 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Why do MIME imlementations sometimes fail
Sender: [email-masked]

At 08:05 -0700 03-09-27, Dave Crocker wrote:
>JP> The main reason for this problem is, in my belief, that
>JP> implementors live in the U.S.A. and do not meet this
>JP> problem themselves.
>
>Perhaps you have some data to support this rather interesting theory?

My theory is that software development often is done in
stages as follows:

(1) Developing a version which works for English.

(2) Localization = modifying the software to work for
     other languages.

And that (2) is often done on a very tight time schedule
and sometimes by different people than those who developed
the English version of the software.

This means that (2) will often solve the obvious problems,
but that non-obvious problems, which crop up only in user
testing, are often recognized when the "Localization" time
slot for a new release of the software is already passed.

The only data I have to support this theory is certain
contacts I have had with the people doing the localization
work for some software products.

Software gets good only through feed-back from actual
users, and problems of non-English users may not easily
reach the ears of developers in such ways that it can make
new releases work later. For example, the "localization"
team may only be active during the actual time of doing the
localization, and will then not be able to get problem
reports from users, since the team is not working any more
when the user problems occur.

One interesting thing I have noted is that localized
software often works well when a user only uses his
national language, but not when a local user wants to use
another language than his own. For example, the software I
use is of the opinion that the decimal separator should be
a comma (,), and makes it somewhat difficult for me to
create content in English where the decimal separator
should be a period (.).

At 11:25 -0400 03-09-27, Keith Moore wrote:
>And in fact, it's still possible.  Nothing stops Jacob or anyone else from
>defining a new type of body part that supports text of multiple character
>encodings.  The challenge is in making it technically sound and enough of a
>win over HTML (which is already widely supported) that people want to
>implement it and use it.

Are not Japanese people already doing this in order to
allow Japanese e-mail to contain a mixture between English
and Japanese text, by using ISO 2022 character set switch
marks in the text.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 27 Sep 2003 20:51:39 +0200
To: IETF mailing list on e-mail headers <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

At 13:16 -0400 03-09-27, Bruce Lilly wrote:
>A named group may suffice where the syntax permits an address
>rather than a single mailbox, e.g.:
>   Reply-To: Bruce Lilly: <[email-masked]>, <[email-masked]>;
>[obviously the phrase could use RFC 2047 encoded-words, and
>an IDN could be used in any of the group mailboxes]  Named
>groups have been part of message syntax since RFC 724, so there
>are no backwards compatibility issues (there may be broken
>implementations of parsers, but that's a different matter).

That sounds like a very good idea! A pity that the group
syntax is not allowed in the "From:" header field according
to RFC2822, but one could put it into "Reply-To:" as you
suggest.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 27 Sep 2003 20:37:41 +0200
To: IETF mailing list on e-mail headers <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

>Keith Moore wrote:
>
>>what do people think - would a MIME roadmap document be worth the trouble of
>>writing?

When we developed the MHTML standard, I actually wrote such
a document discussing implementation issues. I was
submitted some times as Internet drafts, but sadly I never
asked for it to be published as an RFC. I should have done
that. I have the text still, see
http://dsv.su.se/jpalme/ietf/mhtml-info.html, so maybe I
should ask to have it published as an RFC or alternatively
it could be part of the roadmap document you are discussing.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 27 Sep 2003 19:50:26 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

At 08:00 -0700 03-09-26, Dave Crocker wrote:
>But, again, this has nothing to do with MIME.

I did not especially say that this was a MIME issue,
although it is of course related to MIME, since MIME is the
standard for non-ASCII in e-mail headers.

What I did ask is if it is probable that people in the
future are going to want dual e-mail adresses, not only a
display version and an ACE version but two separate
addresses, like "[email-masked]" for national use and
"[email-masked]" for international use.

And if people are going to want this, would it help them if
the standards supported this, for example by allowing the
"From" and "Sender" headers to specify both the national
and the international name, so that the recipient could
choose which of these names to use, dependent on whether
the recipient can handle national names or not.

This may be an issue which IETF has already discussed and
made a decision about, I have not been able to get funding
to participate in much IETF work in the last years, so I
may have missed work already done.

At 09:32 -0700 03-09-26, [email-masked] wrote:
>If so it will be completely nonstandard, since IDN is clearly
>scoped to apply to domain names only.

When IDN starts to be used, people will want to use
national characters also in the local part of e-mail
addresses, and ask for standards to support it.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 27 Sep 2003 19:44:44 +0200
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

At 09:20 -0400 03-09-26, Keith Moore wrote:
>what do people think - would a MIME roadmap document be worth the trouble of
>writing?

A document describing common implementation problems and
solutions would certainly be useful. There seem to be
certain mistakes which each new implementor tends to
repeat, like the problem with getting the encoding right
when you copy a previous e-mail into the body of a new
message. Just making implementors aware that this is
a problem that they should tackle would probably mean
that more implementations do it right the first time.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: IETF mailing list on e-mail headers <[email-masked]>
Cc: Jacob Palme <[email-masked]>
Subject: Re: Why do MIME imlementations sometimes fail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 27 Sep 2003 12:20:44 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:

> Yes, RFC 2046 gives the syntax for multipart MIME entities, and that
> syntax is such that an entity may end at some content other than CRLF
> (CRLF introduces a delimiter).  So technically it is possible to change
> charset and/or language by using a multipart message, probably
> multipart/related.  However, it would be impractical, as the MIME
> "markup" (delimiters, MIME-part headers) would be at least as onerous
> for a reader using a non-MIME UA as the corresponding HTML markup in a
> non-HTML UA. And in practice there are too many broken implementations

I think you're being far too pessimistic about this.  Gnus currently uses
this mechanism.

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

Date: Sat, 27 Sep 2003 10:39:24 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Jacob Palme <[email-masked]>
CC: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob,

JP> If the mail standards were developed anew with no need
JP> for backwards compatibility, one might say that an
JP> e-mail address should look like this:
...
JP> Now, I am fully aware that something like I describe
JP> above is not possible for backwards compatibility
JP> reasons.

You wrote the above immediately after responding to a note from me that
explained that we had such a notation for some years, but it was never used,
so it was finally deprecated.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Sat, 27 Sep 2003 13:16:10 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF mailing list on e-mail headers <[email-masked]>
Organization: Bruce Lilly
To: Jacob Palme <[email-masked]>
CC: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob Palme wrote:

> If the mail standards were developed anew with no need
> for backwards compatibility, one might say that an
> e-mail address should look like this:
> 
> <N:[email-masked],I:[email-masked]>.
> 
> Only one of the two subfields N and I would then be
> mandatory, and both should always reach the same
> recipient.
> 
> Now, I am fully aware that something like I describe
> above is not possible for backwards compatibility
> reasons.

A named group may suffice where the syntax permits an address
rather than a single mailbox, e.g.:
   Reply-To: Bruce Lilly: <[email-masked]>, <[email-masked]>;
[obviously the phrase could use RFC 2047 encoded-words, and
an IDN could be used in any of the group mailboxes]  Named
groups have been part of message syntax since RFC 724, so there
are no backwards compatibility issues (there may be broken
implementations of parsers, but that's a different matter).

Date: Sat, 27 Sep 2003 12:53:57 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Keith Moore wrote:

> what do people think - would a MIME roadmap document be worth the trouble of
> writing?

That depends on what such a document would contribute to making
implementations more consistent.

I have stated (and still believe) that combining the many separate
MIME-related RFCs into a small set of consistent RFCs (a la RFC 2822's
consolidation of what was in 822 amended by ... amended by 1123) and
revised to use current ABNF would go a long way toward clarifying
matters.  In the process, some of the existing ambiguities and
contradictions would have to be resolved.  Currently the core MIME
RFCs refer back to RFC 822 -- as RFC 2822 is on the standards track
and (its successor) will someday obsolete RFC 822, those core MIME
RFCs will need to be updated.

If the "roadmap" is to be simply a list of the MIME-related RFCs, it
would be of little value except perhaps as a working document leading
to consolidation.

Date: Sat, 27 Sep 2003 08:45:49 -0700 (PDT)
From: [email-masked]
Subject: Re: Why do MIME imlementations sometimes fail
To: Keith Moore <[email-masked]>
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > JP> (Possibly one could criticize MIME for not supporting more
> > JP> than one character set within the same body part.
> >
> > You may have noticed that the process of creating standards -- or, for that
> > matter, any engineering design process -- requires making compromises.
> >
> > The possibility of allowing fine-grained changes in the type of the data was
> > considered for MIME.

> And in fact, it's still possible.  Nothing stops Jacob or anyone else from
> defining a new type of body part that supports text of multiple character
> encodings.  The challenge is in making it technically sound and enough of a
> win over HTML (which is already widely supported) that people want to
> implement it and use it.

> Good luck to anyone who wants to try!

Er, exactly. There have been many attempts to define something that's more than
plain text but less than a full blown markup system: X.400's Structured
Formatted Documents, simpletext, text/richtext, and text/enriched all come to
mind. I reviewed a media type registration for a new one a couple of days ago,
as a matter of fact. But so far none of these have been very successful.

The particular challenge of a format whose major feature is to allow for
multiple charsets would be to provide something that's superior to utf-8
text/plain. IMO that's a pretty serious challenge, both technically and
politically. While utf-8 isn't displacing legacy use of old charsets neearly to
the extent I'd like, the trend in new deployment is clearly to use utf-8 to
address the text internationalization problem. And any new text format is by
definition going to be a new deployment.

				Ned

Date: Sat, 27 Sep 2003 11:25:36 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Why do MIME imlementations sometimes fail
Sender: [email-masked]

> JP> (Possibly one could criticize MIME for not supporting more
> JP> than one character set within the same body part.
> 
> You may have noticed that the process of creating standards -- or, for that
> matter, any engineering design process -- requires making compromises.
> 
> The possibility of allowing fine-grained changes in the type of the data was
> considered for MIME.

And in fact, it's still possible.  Nothing stops Jacob or anyone else from
defining a new type of body part that supports text of multiple character
encodings.  The challenge is in making it technically sound and enough of a
win over HTML (which is already widely supported) that people want to 
implement it and use it.  

Good luck to anyone who wants to try!

Keith

Date: Sat, 27 Sep 2003 08:05:28 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Jacob Palme <[email-masked]>
CC: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Why do MIME imlementations sometimes fail
Sender: [email-masked]

Jacob,

JP> (Possibly one could criticize MIME for not supporting more
JP> than one character set within the same body part.

You may have noticed that the process of creating standards -- or, for that
matter, any engineering design process -- requires making compromises.

The possibility of allowing fine-grained changes in the type of the data was
considered for MIME. The problem is that, at that point, you really are
talking about a markup language. This requires getting "into" the content much
more deeply, with the technical work being notably more complicated than MIME.
So, the decision was to work at the level of "attachment" -- although I do not
remember if we used that term. In fact, I sometimes refer to MIME as a
"document stapling" mechanism. Given how long it took to get MIME designed and
agreed to, I am very certain we should not have attempted anything more
ambitious.

JP> The main reason for this problem is, in my belief, that
JP> implementors live in the U.S.A. and do not meet this
JP> problem themselves.

Perhaps you have some data to support this rather interesting theory?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Sat, 27 Sep 2003 10:18:37 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF mailing list on e-mail headers <[email-masked]>
Organization: Bruce Lilly
To: Jacob Palme <[email-masked]>
CC: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Why do MIME imlementations sometimes fail
Sender: [email-masked]

Jacob Palme wrote:

> (Possibly one could criticize MIME for not supporting more
> than one character set within the same body part. I know
> that some MIME implementations implemenent multiple body
> parts in such a way that not even a line break need be
> visible between the body part, but does the MIME standard
> specify that it should work in this way?)

Yes, RFC 2046 gives the syntax for multipart MIME entities, and
that syntax is such that an entity may end at some content other
than CRLF (CRLF introduces a delimiter).  So technically it is
possible to change charset and/or language by using a multipart
message, probably multipart/related.  However, it would be
impractical, as the MIME "markup" (delimiters, MIME-part headers)
would be at least as onerous for a reader using a non-MIME UA
as the corresponding HTML markup in a non-HTML UA. And in practice
there are too many broken implementations -- e.g. many fail to
present the parts of multipart/related, particularly if multiple
levels of nesting are used (an example was discussed here: see
http://www.imc.org/ietf-822/mail-archive/msg02593.html).

> The fact that this problem still happens, even if it is
> a failure, might be a reason that the MIME standard should
> maybe expressly specify that text copied between body parts,
> or between header and body parts, should gets its encoding
> transformed to the encoding of the target body part.

One issue facing any potential implementor of such a scheme is
that one needs to know a substantial amount of context. Whether
or not a sequence of octets is an (RFC 2047) encoded-word depends
heavily on its context, to the point of requiring knowledge of
which header field it appears in and the syntax of that field, as
well as a number of rather complex rules (which could perhaps be
defined more clearly). For example,
    From: =?ISO-8859-1?Q?foo?= =?ISO-8859-1?Q?bar?=@baz.com
contains exactly one encoded-word.
    Received: from [1.2.3.4] by [5.6.7.8] for =?ISO-8859-1?Q?bar?=@baz.com ; 1 Jan 2003 12:34 +0100 (=?iso-8859-1?q?Mitteleurop=E4ische_Zeit?=)
contains no encoded-words, whereas
    Date: 1 Jan 2003 12:34 +0100 (=?iso8859-1?q?Mitteleurop=E4ische_Zeit?=)
contains an encoded-word, and
    X-blurfl: =?ISO-8859-1?Q?foo?= (=?iso8859-1?q?Mitteleurop=E4ische_Zeit?=) ; =?ISO-8859-1?Q?bar?=
might contain from 0 to 3 encoded-words depending on the definition
of the X-blurfl header field -- and if you don't know what that
definition is, you can't determine how many encoded-words it
contains.  The implementor must know the syntax of every header
field, including private-use fields.  And he must know the context
of the text which is to be copied (i.e. if the user highlights some
text in a GUI, the implementor needs some way to retrieve the
header field in which the text appears, even if that header field
is folded across multiple lines). Consider whether or not
   Content-Location: http://users.erols.com/blilly/mailparse/(=?us-ascii?q?=3D?=)
contains an encoded-word.

Another issue is that the encoded-word in a header field may use
a different charset from that specified for the body text. Indeed,
if multiple encoded-words are to be copied, each one might specify
a different charset (see the example and NOTE at the beginning of
RFC 2047 section 8).  A body part has a single charset. The
implementor is faced with the prospect of having to be able to
convert any of a quite large number of charsets
(http://www.iana.org/assignments/character-sets)
to any of the others.  That of course requires detailed knowledge
of all of those charsets and is further complicated by the fact that
several charsets use shift sequences (so what needs to be pasted may be
sensitive to the destination context). It should be noted that
some charset transformations are irreversible.  In some cases, no
transformation is possible (e.g. because the target charset has no
provision for the character in the source charset).

Anybody who thinks either of those issues is trivial is welcome to
try his hand at an implementation.

(RFC 2047) Encoded-words (and IDNs) are primarily intended for
presentation; encoded-words are never part of any protocol exchange
(encoded-words only appear in comments, in unstructured fields such
as Subject, and in phrases such as a display name). Valid domain
name components consist solely of (US-ASCII) letters, digits, and
the hyphen character (LDH) -- the stuff obtained by transforming the
LDH octets that comprise an IDN is solely for presentation. I can
see no situation where it is *necessary* to copy an encoded-word
into a text/plain message body.

Given the implementation difficulties and lack of necessity, I
would not be in favor of any requirement such as proposed. Any
UA implementor who wishes to make provision for copying header field
content into a plain text message body or vice versa needs to
carefully consider the issues and reconsider whether such provision
is wise.

> The main reason for this problem is, in my belief, that
> implementors live in the U.S.A. and do not meet this
> problem themselves.

Perhaps it has more to do with the nature of the "problem"?

Date: Sat, 27 Sep 2003 09:20:39 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: MIME roadmap (was Re: Dual names [...] in e-mail addresses?)
Sender: [email-masked]

At 2003-09-26 09:20:32 -0400, [email-masked] wrote:
>
> what do people think - would a MIME roadmap document be worth the
> trouble of writing?

Yes. (And I'd be happy to write it, if nobody else wants to.)

-- ams

Date: Fri, 26 Sep 2003 21:04:04 +0000
From: "Adam M. Costello" <[email-masked]>
To: IETF-822 Mailing List <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

Jacob Palme <[email-masked]> wrote:

> IDN will soon be a practical reality, and non-ASCII characters in
> e-mail addresses will probably soon be common also in the localpart of
> the e-mail address.

IDNA has nothing to do with email address local parts, but perhaps you
are alluding to IMAA (http://www.imc.org/ietf-imaa/) which is a work in
progress and is similar to IDNA.

> many people will have business cards with English information on one
> side, and information in their own language on the other side. They
> will then also have two e-mail addresses, since the ASCII version of
> IDN should obviously be hidden from humans as much as possible.

The English side of the card could show either a separate "English"
email address, or it could show the ACE form of the same address that
appears on the non-English side of the card.

The advantage of creating a separate address is that it would be much
easier to remember and type, but there would also be advantages in using
the same address on both sides.

For example, suppose I have the cards of two people from Korea and I
send a single message to both of them.  I cannot type Hangul characters,
so I use the ASCII addresses.  If they are separately-created "English"
addresses, they might be intuitive to me, but they might be completely
non-intuitive to the recipients when they each look at the other address
in the To: field.  On the other hand, if the ASCII addresses are the ACE
forms of the Korean addresses, they will be tricky for me to type in,
but will be displayed to the recipients using Hangul characters.

Also, if I put the ACE form in my address book along with the romanized
form of the person's full name, and later receive (directly or
indirectly) a message from that person in which the full name is Korean,
my mail program could recognize that the address matches an address book
entry and could show the romanized full name from the address book (in
addition to or instead of the Korean full name from the message header).

But the unwieldiness of the ACE form might trump all its advantages.

> One of the areas where MIME still, ten years after its introduction,
> often fails is when people copy e-mail messages into the bodies of new
> e-mail addresses.  Quite often, you see text encoded according to the
> e-mail heading rules for non-ASCII characters in the bodies of such
> messages.

It's not clear what is the "right" thing to do in this situation.

By the way, if messages were simply attached, instead of copied into
the body, then there would be no problem.  The header would not be
transformed in any way until it was displayed by the final recipient.

But when headers are copied into message bodies, there are two
approaches.  (1) You can do a simple copy of the ASCII header itself,
resulting in MIME-encoded and ACE strings that look like garbage.  But
this results in a valid message header, and anyone (even someone using
a legacy mail program) can paste the fields back into the header of a
new message, where they will once again work properly.  (2) You can copy
the non-ASCII text that would be displayed.  The result looks nice, but
is not a valid message header, and pasting the fields back into the
header of a new message will not work on old mail programs (which don't
know how to re-encode the non-ASCII text), but might work on new mail
programs.

> there will maybe be a need to extend the existing e-mail standards,
> so that the e-mail address of especially From and Sender fields
> can be specified in a dual format, with both the national and the
> international (ASCII) name specified at the same time.  Is this
> something IETF should begin thinking about?  Or is it something IETF
> has already started thinking about?

IMAA will allow a single address to have both non-ASCII and ASCII forms,
but the ASCII form will look like garbage.  IMAA restricts its attention
to individual addresses; it is not designed to express connections
between distinct addresses.  For that I think you'd need something that
looks at larger pieces of message headers.

Bruce Lilly <[email-masked]> wrote:

> I don't know of any provision for language tagging for IDN...[*]
>
> * Unicode 3.something introduced a set of codes for language tagging,
> but they do not use standard language tags (which are specified using
> a subset of US-ASCII), they of course are not available in earlier
> versions of Unicode implementations

And they are not allowed in IDNs anyway (Nameprep prohibits them).

It would be no good to have language tags be part of the identifier;
we wouldn't want the very same string of characters to refer to two
different mailboxes depending on whether it was tagged as Chinese or
Japanese.  Language tags would have to be markup around the identifier,
which would have to be done at a higher layer than IDNA (for example, by
extending the message header syntax).

Claus Färber <[email-masked]> wrote:

> From: Claus Faerber <[email-masked]>
>   (INT: Claus =?ISO-8859-1?Q?F=E4rber?= <[email-masked]>)

A MIME-aware IDN-aware user agent would decode the alternate
display-name, but not the alternate addr-spec.  Therefore it might be
better to put the ASCII form in the comment:

From: Claus =?ISO-8859-1?Q?F=E4rber?= <[email-masked]>
  (ASCII: Claus Faerber <[email-masked]>)

This way everything would be decoded and displayed nicely by a
MIME-aware IDN-aware user agent.

Or not... I just tried this with mutt and discovered that it refuses to
show address fields as-is, even when I explicitly ask to see the whole
header.  If a mailbox has a display-name, then its comments are not
shown; if it has no display-name, then all its comments are concatenated
and converted to a display-name (quoted if necessary).

I don't know if other mail programs would be quite so heavy-handed
as this, but I wouldn't be surprised if they failed to preserve
address-field comments in replies.

AMC

Date: Fri, 26 Sep 2003 09:32:41 -0700 (PDT)
From: [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
To: Jacob Palme <[email-masked]>
Cc: IETF-822 Mailing List <[email-masked]>
Sender: [email-masked]

> IDN will soon be a practical reality, and non-ASCII
> characters in e-mail addresses will probably soon be common
> also in the localpart of the e-mail address.

If so it will be completely nonstandard, since IDN is clearly
scoped to apply to domain names only.

> This means that lots of people are going to have e-mail
> addresses like [email-masked]. And one of the main
> problems with such names is that people in other countries
> will have difficulty typing them. My guess is that many
> Americans will have problem typing [email-masked], and
> typing names in totally different alphabets like Greek,
> Arabic, Cyrillic, Chinese, Korean, Japanese will be even
> more difficult.

> Because of this, many people will have business cards with
> English information on one side, and information in their
> own language on the other side. They will then also have
> two e-mail addresses, since the ASCII version of IDN should
> obviously be hidden from humans as much as possible.

> They might then use their national e-mail address for
> national mail, and their international e-mail address for
> international mail. And certainly mail intended for one
> region may get into another region, so that e-mail with
> national names in some heading field will often get resent
> internatinally.

Everyone who has participated in the IDN work is well aware of
the implications.

> One of the areas where MIME still, ten years after its
> introduction, often fails is when people copy e-mail
> messages into the bodies of new e-mail addresses. Quite
> often, you see text encoded according to the e-mail heading
> rules for non-ASCII characters in the bodies of such
> messages.

Please. This is an implementation failure, not a MIME failure.

> The conclusion of what I have written above is that there
> will maybe be a need to extend the existing e-mail
> standards, so that the e-mail address of especially From
> and Sender fields can be specified in a dual format, with
> both the national and the international (ASCII) name
> specified at the same time. Is this something IETF should
> begin thinking about? Or is it something IETF has already
> started thinking about?

The IETF started thinking about this long before the IDN work started. Any
number of drafts have been posted about it over the years. The latest one I've
seen, which leverages the IDN work, is draft-hoffman-imaa-02.txt. There's also
a mailing list, see http://www.imc.org/ietf-imaa/.

					Ned

Date: 26 Sep 2003 17:00:00 +0200
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
To: [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob Palme <[email-masked]> schrieb/wrote:
> If the mail standards were developed anew with no need for backwards
> compatibility, one might say that an e-mail address should look like
> this:
> <N:[email-masked],I:[email-masked]>.
...
> Now, I am fully aware that something like I describe above is not
> possible for backwards compatibility reasons.

From: Claus Faerber <[email-masked]>
  (INT: Claus =?ISO-8859-1?Q?F=E4rber?= <[email-masked]>)

Claus
-- 
http://www.faerber.muc.de/

Date: 26 Sep 2003 16:58:00 +0200
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
To: [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob Palme <[email-masked]> schrieb/wrote:
> So even though mailers support IDN, this does not mean that they will
> support all character sets which might occur in incoming e-mail
> addresses.

It might be a good idea to show the ASCII form of the address if you  
either don't have a character set supporting all of the Unicode  
characters used for the address or don't have a user supporting^W being  
able to read all of the scripts used for the address.

Claus
-- 
http://www.faerber.muc.de/

Date: Fri, 26 Sep 2003 08:00:05 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Jacob Palme <[email-masked]>
CC: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob,

>>In order to see such addresses in their "native" form, when they are encoded
>>using IDN, people will need email (or other) software that understands IDN.
>>Hence, they will be using software that is "internationalized" in the
>>necessary manner.

JP> I am not so sure. When I tried to view a web page in Greek
JP> two months ago, a page which was using the Greek version of
JP> ISO 8859, one web browser I used at one time said that I
JP> had to install the greek alphabet or else not see the page
JP> at all. (Another web browser showed the page, replacing
JP> characters it did not support by "?").

Your examples seem to support my point.

JP> And people still need to be able to have business cards
JP> printed on paper containing their e-mail address.

So?  How does this call for modifying MIME?

>>But this has nothing to do with email. It has to do with software support for
>>typing more characters than are supported on my keyboard.

JP> Do you mean that everyone all over the world has to learn
JP> how to type Japanese or Chinese characters on their keyboards?

Folks who wish to generate those characters do need to learn how to type them,
yes.

But, again, this has nothing to do with MIME.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Fri, 26 Sep 2003 10:13:15 -0400
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
To: Keith Moore <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

[email-masked] (Keith Moore) writes:
>> If the spec is too hard to support properly, implementations will not 
>> contain proper support. IMO that is then a failure of the 
>> specification. Is MIME too hard? Arguably, yes, in parts. For
example, 
>> it doesn't take a moron to overlook one of the content-disposition 
>> RFCs. How many programs get filename encoding wrong? (I suspect I do, 
>> come to think of it.)
>
>what do people think - would a MIME roadmap document be worth the
>trouble of writing?

Yes - I'd very much like to have one.  

I'd love to have something I could show people to get them up to speed
and into the conversation with all the parts they need.  Of course, I'd
have to get myself up to speed first!

Date: Fri, 26 Sep 2003 09:20:32 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

> If the spec is too hard to support properly, implementations will not 
> contain proper support. IMO that is then a failure of the 
> specification. Is MIME too hard? Arguably, yes, in parts. For example, 
> it doesn't take a moron to overlook one of the content-disposition 
> RFCs. How many programs get filename encoding wrong? (I suspect I do, 
> come to think of it.)

what do people think - would a MIME roadmap document be worth the trouble of
writing?

Date: Fri, 26 Sep 2003 09:20:36 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF-822 Mailing List <[email-masked]>
Organization: Bruce Lilly
To: Jacob Palme <[email-masked]>
CC: IETF-822 Mailing List <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob Palme wrote:
> 
> IDN will soon be a practical reality, and non-ASCII
> characters in e-mail addresses will probably soon be common
> also in the localpart of the e-mail address.
> 
> This means that lots of people are going to have e-mail
> addresses like [email-masked]. And one of the main
> problems with such names is that people in other countries
> will have difficulty typing them. My guess is that many
> Americans will have problem typing [email-masked], and
> typing names in totally different alphabets like Greek,
> Arabic, Cyrillic, Chinese, Korean, Japanese will be even
> more difficult.
> 
> Because of this, many people will have business cards with
> English information on one side, and information in their
> own language on the other side. They will then also have
> two e-mail addresses, since the ASCII version of IDN should
> obviously be hidden from humans as much as possible.

Actually, the "ASCII version", i.e. the one that actually is
used with DNS and other protocols, as opposed to the display
version, probably shouldn't be hidden (w.r.t. business cards
etc.) -- there are in fact many reasons to prefer it over the
display version:

1. it can be typed unambiguously, unlike the display version,
    for which, in the example given, there may be a multitude
    of ways to type lower-case latin o with dieresis and/or
    lower-case latin u with dieresis.  Of course when using
    IDN, there is *supposed* to be a normalization process,
    but it is not at all clear how many implementations will
    fail to correctly implement IDN, including the quite complex
    normalization process.
2. For conventional paper-and-ink business cards, as well as
    for handwritten communications, it can be written and read
    unambiguously. The difference between lower-case latin o
    with dieresis and lower-case latin o with double acute is
    subtle. Latin upper-case A and Cyrillic upper-case A are
    for all practical purposes indistinguishable (likewise for
    K, M, O, T, with the added possibility of confusing H, C, P
    and possibly a few others).
3. It *can* be displayed (or printed, etc.). Many display
    and print devices lack some characters. Aside from the obvious
    cases of non-latin scripts, consider the lower-case latin c
    with caron, which is not unusual in some eastern European
    names.
etc. These are not new issues; the same issues arose in URL's.
    See the discussion in RFC 2396 section 1.5.

> They might then use their national e-mail address for
> national mail, and their international e-mail address for
> international mail. And certainly mail intended for one
> region may get into another region, so that e-mail with
> national names in some heading field will often get resent
> internatinally.

I think you may be confusing the display version with the actual
protocol exchange -- the protocol exchange is always in a subset
of US-ASCII, and UAs and other software MUST use that form in
protocol exchanges and not some (device-specific!) display codes.
This is not really new either; the display name (phrase) associated
with an email address may well be encoded via RFC 2047 methods
(and MUST always be used as such in message header fields), but
a UA might display such an encoded phrase by decoding into the
specified charset (and possibly language in the case of text-to-
speech conversion for the visually impaired).  Fortunately, RFC 2047
(as amended by RFC 2231) provides charset and language-tagging
facilities in compliance with RFC 2277. I don't know of any provision
for language tagging for IDN...[*]

> One of the areas where MIME still, ten years after its
> introduction, often fails is when people copy e-mail
> messages into the bodies of new e-mail addresses. Quite
> often, you see text encoded according to the e-mail heading
> rules for non-ASCII characters in the bodies of such
> messages.

There is indeed one limitation of MIME w.r.t. message bodies, viz.
there is no convenient mechanism for switching charset or language
within a text message body.  One could of course use HTML (suitably
tagged via MIME) for the message body, using HTML's capability for
charset and language tagging. But not all UAs are capable of rendering
HTML.

The key issue in any case is implementation. It is certainly possible
for a UA to take an RFC 2047/2231 Q-encoded display name from a header
field and, by performing a few simple transformations, generate quoted-
printable encoded text suitable for a message body (and appropriately
tag the message body as quoted-printable). Since B encoding can be
transformed to Q encoding, the same can be done if the display name is
B encoded.  Likewise, it is possible to generate HTML for the body.

> The conclusion of what I have written above is that there
> will maybe be a need to extend the existing e-mail
> standards, so that the e-mail address of especially From
> and Sender fields can be specified in a dual format, with
> both the national and the international (ASCII) name
> specified at the same time. Is this something IETF should
> begin thinking about? Or is it something IETF has already
> started thinking about?

It is a fait accompli.  The display form can be provided as a phrase
using RFC 2047/2231 encoding.  It could also be provided in an RFC 822
comment (though the proposed standard RFC 2822 deprecates comments in
address fields).  The display name is just that -- for display, not for
protocol exchanges.

> It is not a simple problem to solve, especially if you
> want both backwards compatibility with existing mail,
> and something user-friendly, preferally user-friendly
> even for people using mail programs which do not support
> dual e-mail addresses.

Problem? What is the problem with
From: =?ISO-8859-1*de?Q?Claus_F=E4rber?= [email-masked]
which is legal (i.e. compatible with all existing text message clients),
includes language-tagging, and is displayed appropriately in MIME-conforming
UAs (and can be displayed with pre-MIME UAs via metamail) (i.e. is
user-friendly, even for those using pre-MIME UAs (provided they use metamail)
and for those using text-to-speech)?  None of that changes even if the domain
name becomes something like qz-blurfl.de -- with a display name provided,
many UAs do not even display the raw address.  Indeed, if an IDN-ized domain
name is used, how is a text-to-speech processor supposed to know what
language to use for the domain name if it is "displayed" (i.e. converted to
speech)?

* Unicode 3.something introduced a set of codes for language tagging,
but they do not use standard language tags (which are specified using
  a subset of US-ASCII), they of course are not available in earlier
versions of Unicode implementations, and they may well have been
withdrawn in Unicode 4.0.

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Cc: IETF-822 Mailing List <[email-masked]>, Jacob Palme <[email-masked]>
Date: Fri, 26 Sep 2003 13:48:18 +0200
Sender: [email-masked]

Keith Moore writes:
> is that a failure of MIME or a failure to completely implement MIME? 
> how can the MIME spec (or any spec) solve a problem if implementors 
> pick and choose which parts they are going to implement?

You can't force people to do a good job. Saying m-t-i adds some pressure 
to implement some support, but not adequate support.

If the spec is too hard to support properly, implementations will not 
contain proper support. IMO that is then a failure of the 
specification. Is MIME too hard? Arguably, yes, in parts. For example, 
it doesn't take a moron to overlook one of the content-disposition 
RFCs. How many programs get filename encoding wrong? (I suspect I do, 
come to think of it.)

I don't want to discuss that specific issue, or any other issues from 
the distant past. Done is done.

I do want to emphasize that since programs already have trouble with 
some of the odder corners, adding more complexity is best avoided.

--Arnt

Date: Fri, 26 Sep 2003 07:35:57 -0400
From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Why do MIME imlementations sometimes fail
Sender: [email-masked]

>  But
> it is a problem, and that this problem still occurs, may
> mean that IDN will get similar problems for many years in
> the future.

I don't think anyone doubts that.  But the alternative to developing IDN
would have been to not develop IDN, or to insist that all software be fully
internationalized.  The first was clearly unacceptable; the second was clearly
infeasible.

Date: Fri, 26 Sep 2003 13:17:24 +0200
To: IETF mailing list on e-mail headers <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Why do MIME imlementations sometimes fail
Sender: [email-masked]

At 16:00 -0400 03-09-25, Keith Moore wrote:
>  > One of the areas where MIME still, ten years after its
>>  introduction, often fails is when people copy e-mail
>>  messages into the bodies of new e-mail addresses. Quite
>>  often, you see text encoded according to the e-mail heading
>>  rules for non-ASCII characters in the bodies of such
>>  messages.
>
>is that a failure of MIME or a failure to completely implement MIME?
>how can the MIME spec (or any spec) solve a problem if implementors
>pick and choose which parts they are going to implement?

At 13:32 -0700 03-09-25, Dave Crocker wrote:
>This is not a failing with MIME.  MIME actually appears to have the right set
>of labeling mechanisms.

Sorry, I used the wrong wording. I should have written
"MIME implementations", not "MIME". Of course it is a
failure of implementations, not of the MIME standard. But
it is a problem, and that this problem still occurs, may
mean that IDN will get similar problems for many years in
the future.

(Possibly one could criticize MIME for not supporting more
than one character set within the same body part. I know
that some MIME implementations implemenent multiple body
parts in such a way that not even a line break need be
visible between the body part, but does the MIME standard
specify that it should work in this way?)

The fact that this problem still happens, even if it is
a failure, might be a reason that the MIME standard should
maybe expressly specify that text copied between body parts,
or between header and body parts, should gets its encoding
transformed to the encoding of the target body part.

The main reason for this problem is, in my belief, that
implementors live in the U.S.A. and do not meet this
problem themselves. Making their software work for the
rest of the world is often done by special localization
experts, who work on a tight timescale during a limited
time slot and with not enough input from actual users.
Software will only get well through input from users who
meet special-case problems, and such input from non-
English users is probably not channeled the right way
to the developers.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Fri, 26 Sep 2003 13:15:55 +0200
To: IETF mailing list on e-mail headers <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

At 16:00 -0400 03-09-25, Keith Moore wrote:
>  > The conclusion of what I have written above is that there
>>  will maybe be a need to extend the existing e-mail
>>  standards, so that the e-mail address of especially From
>>  and Sender fields can be specified in a dual format, with
>>  both the national and the international (ASCII) name
>>  specified at the same time.
>
>not clear.  one sure way to cause problems is to provide two different
>ways to specify the same thing, when those two things have any
>possibility of diverging.

If the mail standards were developed anew with no need
for backwards compatibility, one might say that an
e-mail address should look like this:

<N:[email-masked],I:[email-masked]>.

Only one of the two subfields N and I would then be
mandatory, and both should always reach the same
recipient.

Now, I am fully aware that something like I describe
above is not possible for backwards compatibility
reasons.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Fri, 26 Sep 2003 13:12:11 +0200
To: IETF mailing list on e-mail headers <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

At 13:32 -0700 03-09-25, Dave Crocker wrote:
>JP> This means that lots of people are going to have e-mail
>JP> addresses like [email-masked]. And one of the main
>
>In order to see such addresses in their "native" form, when they are encoded
>using IDN, people will need email (or other) software that understands IDN.
>Hence, they will be using software that is "internationalized" in the
>necessary manner.

I am not so sure. When I tried to view a web page in Greek
two months ago, a page which was using the Greek version of
ISO 8859, one web browser I used at one time said that I
had to install the greek alphabet or else not see the page
at all. (Another web browser showed the page, replacing
characters it did not support by "?"). So even though
mailers support IDN, this does not mean that they will
support all character sets which might occur in incoming
e-mail addresses.

And people still need to be able to have business cards
printed on paper containing their e-mail address.

At 13:32 -0700 03-09-25, Dave Crocker wrote:
>People are already faced with this problem. It is not new to email. In fact,
>it has almost nothing at all to do with email or IDN.
>
>It has to do with user interface support for multiple character sets. I find
>typing Spanish, in my US version of Windows to be onerous. And that only
>involves a few accent marks.
>
>But this has nothing to do with email. It has to do with software support for
>typing more characters than are supported on my keyboard.

Do you mean that everyone all over the world has to learn
how to type Japanese or Chinese characters on their keyboards?
-- 

At 13:32 -0700 03-09-25, Dave Crocker wrote:
>JP> Because of this, many people will have business cards with
>JP> English information on one side, and information in their
>JP> own language on the other side. They will then also have
>JP> two e-mail addresses, since the ASCII version of IDN should
>JP> obviously be hidden from humans as much as possible.
>
>This is no different from the challenges that people have long been facing,
>concerning postal addresses and even telephone numbers.

Phone numbers only contain digits, and thus do not have this
problem. Postal addresses are interpreted by human sorters
(if needed) in order to understand a postal address even
if it is spelled in non-normal ways. E-mail, however,
should work automatically! Jacob Palme <[email-masked]> 
(Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 25 Sep 2003 13:33:05 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Jacob Palme <[email-masked]>
CC: IETF-822 Mailing List <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob,

Your concerns are timely and reasonable.  However I believe they are misguided.

Here is why:

JP> This means that lots of people are going to have e-mail
JP> addresses like [email-masked]. And one of the main

In order to see such addresses in their "native" form, when they are encoded
using IDN, people will need email (or other) software that understands IDN.
Hence, they will be using software that is "internationalized" in the
necessary manner.

Others will see the ASCII version of the IDN string. Although these will be
ugly, they are completely compatible with existing email software. They can be
typed, and copied, etc., with no change to that software.

JP> problems with such names is that people in other countries
JP> will have difficulty typing them. My guess is that many
JP> Americans will have problem typing [email-masked], and
JP> typing names in totally different alphabets like Greek,
JP> Arabic, Cyrillic, Chinese, Korean, Japanese will be even
JP> more difficult.

People are already faced with this problem. It is not new to email. In fact,
it has almost nothing at all to do with email or IDN.

It has to do with user interface support for multiple character sets. I find
typing Spanish, in my US version of Windows to be onerous. And that only
involves a few accent marks.

But this has nothing to do with email. It has to do with software support for
typing more characters than are supported on my keyboard.

JP> Because of this, many people will have business cards with
JP> English information on one side, and information in their
JP> own language on the other side. They will then also have
JP> two e-mail addresses, since the ASCII version of IDN should
JP> obviously be hidden from humans as much as possible.

This is no different from the challenges that people have long been facing,
concerning postal addresses and even telephone numbers.

JP> They might then use their national e-mail address for
JP> national mail, and their international e-mail address for
JP> international mail. And certainly mail intended for one
JP> region may get into another region, so that e-mail with
JP> national names in some heading field will often get resent
JP> internatinally.

JP> One of the areas where MIME still, ten years after its
JP> introduction, often fails is when people copy e-mail
JP> messages into the bodies of new e-mail addresses. Quite
JP> often, you see text encoded according to the e-mail heading
JP> rules for non-ASCII characters in the bodies of such
JP> messages.

This is not a failing with MIME.  MIME actually appears to have the right set
of labeling mechanisms.

The problems are with the software that uses MIME. Often, the user's system
does not properly mark the local "language" or "character set". Hence, the
MIME software does not label the content that is produced. They package the
content as MIME default, when it is not. (This is a good reason for having
global standards never have labeling defaults.)

So, when the sender's default actually is Kanji and the receiver's default is
really Spanish, they have a problem. The problem is not with MIME but with the
senders _use_ of MIME. This difference is fundamental.

JP> The conclusion of what I have written above is that there
JP> will maybe be a need to extend the existing e-mail
JP> standards, so that the e-mail address of especially From
JP> and Sender fields can be specified in a dual format, with
JP> both the national and the international (ASCII) name
JP> specified at the same time. Is this something IETF should
JP> begin thinking about? Or is it something IETF has already
JP> started thinking about?

There might be an interesting task, here, but not for the reasons you have
described.

What you are really describing is a desire to have multiple email addresses
identified as belonging to the same entity (person, or whatever). I think of
of this as being the same as having multiple A records for an entry in the
DNS.

The IDN-vs-ASCII motivation for having multiple addresses is just one example.

Interestingly, this capability was originally specified in RFC 733:

     address     =  host-phrase / quoted-string
                 / (*phrase "<" #address ">" )
                 / (*phrase ":" #address ";" )
                 / (":" ("Include" / "Postal" / atom) ":" address)

Note that the value inside angle brackets may be a list.

Although I thought it was reasonable and clever to permit this, no one ever
used it, so it was deprecated for RFC822.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Thu, 25 Sep 2003 13:32:26 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Jacob Palme <[email-masked]>
CC: IETF-822 Mailing List <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Jacob,

Your concerns are timely and reasonable.  However I believe they are misguided.

Here is why:

JP> This means that lots of people are going to have e-mail
JP> addresses like [email-masked]. And one of the main

In order to see such addresses in their "native" form, when they are encoded
using IDN, people will need email (or other) software that understands IDN.
Hence, they will be using software that is "internationalized" in the
necessary manner.

Others will see the ASCII version of the IDN string. Although these will be
ugly, they are completely compatible with existing email software. They can be
typed, and copied, etc., with no change to that software.

JP> problems with such names is that people in other countries
JP> will have difficulty typing them. My guess is that many
JP> Americans will have problem typing [email-masked], and
JP> typing names in totally different alphabets like Greek,
JP> Arabic, Cyrillic, Chinese, Korean, Japanese will be even
JP> more difficult.

People are already faced with this problem. It is not new to email. In fact,
it has almost nothing at all to do with email or IDN.

It has to do with user interface support for multiple character sets. I find
typing Spanish, in my US version of Windows to be onerous. And that only
involves a few accent marks.

But this has nothing to do with email. It has to do with software support for
typing more characters than are supported on my keyboard.

JP> Because of this, many people will have business cards with
JP> English information on one side, and information in their
JP> own language on the other side. They will then also have
JP> two e-mail addresses, since the ASCII version of IDN should
JP> obviously be hidden from humans as much as possible.

This is no different from the challenges that people have long been facing,
concerning postal addresses and even telephone numbers.

JP> They might then use their national e-mail address for
JP> national mail, and their international e-mail address for
JP> international mail. And certainly mail intended for one
JP> region may get into another region, so that e-mail with
JP> national names in some heading field will often get resent
JP> internatinally.

JP> One of the areas where MIME still, ten years after its
JP> introduction, often fails is when people copy e-mail
JP> messages into the bodies of new e-mail addresses. Quite
JP> often, you see text encoded according to the e-mail heading
JP> rules for non-ASCII characters in the bodies of such
JP> messages.

This is not a failing with MIME.  MIME actually appears to have the right set
of labeling mechanisms.

The problems are with the software that uses MIME. Often, the user's system
does not properly mark the local "language" or "character set". Hence, the
MIME software does not label the content that is produced. They package the
content as MIME default, when it is not. (This is a good reason for having
global standards never have labeling defaults.)

So, when the sender's default actually is Kanji and the receiver's default is
really Spanish, they have a problem. The problem is not with MIME but with the
senders _use_ of MIME. This difference is fundamental.

JP> The conclusion of what I have written above is that there
JP> will maybe be a need to extend the existing e-mail
JP> standards, so that the e-mail address of especially From
JP> and Sender fields can be specified in a dual format, with
JP> both the national and the international (ASCII) name
JP> specified at the same time. Is this something IETF should
JP> begin thinking about? Or is it something IETF has already
JP> started thinking about?

There might be an interesting task, here, but not for the reasons you have
described.

What you are really describing is a desire to have multiple email addresses
identified as belonging to the same entity (person, or whatever). I think of
of this as being the same as having multiple A records for an entry in the
DNS.

The IDN-vs-ASCII motivation for having multiple addresses is just one example.

Interestingly, this capability was originally specified in RFC 733:

     address     =  host-phrase / quoted-string
                 / (*phrase "<" #address ">" )
                 / (*phrase ":" #address ";" )
                 / (":" ("Include" / "Postal" / atom) ":" address)

Note that the value inside angle brackets may be a list.

Although I thought it was reasonable and clever to permit this, no one ever
used it, so it was deprecated for RFC822.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

Date: Thu, 25 Sep 2003 16:00:33 -0400
From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

> One of the areas where MIME still, ten years after its
> introduction, often fails is when people copy e-mail
> messages into the bodies of new e-mail addresses. Quite
> often, you see text encoded according to the e-mail heading
> rules for non-ASCII characters in the bodies of such
> messages.

is that a failure of MIME or a failure to completely implement MIME?
how can the MIME spec (or any spec) solve a problem if implementors
pick and choose which parts they are going to implement?

> The conclusion of what I have written above is that there
> will maybe be a need to extend the existing e-mail
> standards, so that the e-mail address of especially From
> and Sender fields can be specified in a dual format, with
> both the national and the international (ASCII) name
> specified at the same time. 

not clear.  one sure way to cause problems is to provide two different
ways to specify the same thing, when those two things have any
possibility of diverging.

Date: Thu, 25 Sep 2003 18:10:22 +0200
To: IETF-822 Mailing List <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

IDN will soon be a practical reality, and non-ASCII
characters in e-mail addresses will probably soon be common
also in the localpart of the e-mail address.

This means that lots of people are going to have e-mail
addresses like [email-masked]. And one of the main
problems with such names is that people in other countries
will have difficulty typing them. My guess is that many
Americans will have problem typing [email-masked], and
typing names in totally different alphabets like Greek,
Arabic, Cyrillic, Chinese, Korean, Japanese will be even
more difficult.

Because of this, many people will have business cards with
English information on one side, and information in their
own language on the other side. They will then also have
two e-mail addresses, since the ASCII version of IDN should
obviously be hidden from humans as much as possible.

They might then use their national e-mail address for
national mail, and their international e-mail address for
international mail. And certainly mail intended for one
region may get into another region, so that e-mail with
national names in some heading field will often get resent
internatinally.

One of the areas where MIME still, ten years after its
introduction, often fails is when people copy e-mail
messages into the bodies of new e-mail addresses. Quite
often, you see text encoded according to the e-mail heading
rules for non-ASCII characters in the bodies of such
messages.

The conclusion of what I have written above is that there
will maybe be a need to extend the existing e-mail
standards, so that the e-mail address of especially From
and Sender fields can be specified in a dual format, with
both the national and the international (ASCII) name
specified at the same time. Is this something IETF should
begin thinking about? Or is it something IETF has already
started thinking about?

It is not a simple problem to solve, especially if you
want both backwards compatibility with existing mail,
and something user-friendly, preferally user-friendly
even for people using mail programs which do not support
dual e-mail addresses.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Cc: [email-masked]
From: "Baillie, Grant" <[email-masked]>
Subject: Re: Dealing with invalid UTF-8
Date: Thu, 11 Sep 2003 08:11:59 -0700
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

I have seen similarly misguided mailing list software which prepended  
an announcement to messages, regardless of the MIME structure. In many  
cases, because base64-decoding the announcement didn't correspond to an  
integral number of output bytes, the rest of the output ended up being  
bit-shifted. (Of course, the '=' padding at the end of the input wasn't  
correct, but it was too late for the decoder to recover).

One approach is to ignore lines which contain invalid base64  
characters, rather than just ignoring the invalid characters. That  
would work in these cases, at any rate; maybe other GIGO cases would  
behave worse, though.

--Grant

On Sep 11, 2003, at 2:39, Arnt Gulbrandsen wrote:

>
> Hi,
>
> this morning I received a single-part mail message looking like this:
>
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: base64
> ...
> b2VrcmlzIEVuZ2luZWVyaW5nLCB0ZWNobmljYWwgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3Q 
> NCgk+  
> IFt1bl1zdWJzY3JpYmU6IGh0dHA6Ly9saXN0cy5zb2VrcmlzLmNvbS9tYWlsbWFuL2xpc3R 
> pbmZv
> L3NvZWtyaXMtdGVjaA0KCT4NCgkNCgkNCg0K
> _____________________________________________________________________
> Soekris Engineering, technical discussion mailing list
> [un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech
>
> What's considered the best approach for dealing with something like  
> this? ("Complain to GNU Mailman maintainer", while doubtless  
> satisfying to some, is not my thing. I suppose I'm growing old.)
>
> The RFC states that "Any characters outside of the base64 alphabet are  
> to be ignored in base64-encoded data". That approach leads to appended  
> garbage. Stopping decoding as soon as an illegal character is seen  
> works in this case, but perhaps it might lead to truncation in other  
> error cases?
>
> Comments? Advice?
>
> --Arnt
>

Date: Thu, 11 Sep 2003 07:37:08 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Dilip Menon <[email-masked]>
CC: 822 <[email-masked]>
Subject: Re: SMTPPATH LEN to include '<' , '>' or not..
Sender: [email-masked]

Dilip Menon wrote:
> Hi,
> I have a question regarding the maximum path length allowed in RCPT TO as
> well as MAIL FROM.    RFC 2821 says, this limit is 256 bytes.
> For e.g. if address is [email-masked]
> 
> So if we include the '<' and '>' characters,  will the total length be 258.
> Or is it 256 inclusive of these characters?
> 
> Regards
> Dilip Menon

The exact wording in RFC 2821 is:

    path
       The maximum total length of a reverse-path or forward-path is 256
       characters (including the punctuation and element separators).

       Reverse-path = Path
       Forward-path = Path
       Path = "<" [ A-d-l ":" ] Mailbox ">"
       A-d-l = At-domain *( "," A-d-l )
             ; Note that this form, the so-called "source route",
             ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
             ; ignored.
       At-domain = "@" domain

The 256 character limit includes the angle brackets, @, local-part, domain(s),
(and in the case of deprecated source routes) commas and colon; those are
included in the definition of "Path" and explicitly referenced in the phrase
"including the punctuation and element separators".

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Dealing with invalid UTF-8
Date: Thu, 11 Sep 2003 11:39:43 +0200
Sender: [email-masked]

Hi,

this morning I received a single-part mail message looking like this:

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
...
b2VrcmlzIEVuZ2luZWVyaW5nLCB0ZWNobmljYWwgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QNCgk+ 
IFt1bl1zdWJzY3JpYmU6IGh0dHA6Ly9saXN0cy5zb2VrcmlzLmNvbS9tYWlsbWFuL2xpc3RpbmZv
L3NvZWtyaXMtdGVjaA0KCT4NCgkNCgkNCg0K
_____________________________________________________________________
Soekris Engineering, technical discussion mailing list
[un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech

What's considered the best approach for dealing with something like 
this? ("Complain to GNU Mailman maintainer", while doubtless satisfying 
to some, is not my thing. I suppose I'm growing old.)

The RFC states that "Any characters outside of the base64 alphabet are 
to be ignored in base64-encoded data". That approach leads to appended 
garbage. Stopping decoding as soon as an illegal character is seen 
works in this case, but perhaps it might lead to truncation in other 
error cases?

Comments? Advice?

--Arnt

From: "Dilip Menon" <[email-masked]>
To: "822" <[email-masked]>
Subject: SMTPPATH LEN to include '<' , '>' or not..
Date: Mon, 8 Sep 2003 09:26:54 -0700
Sender: [email-masked]

Hi,
I have a question regarding the maximum path length allowed in RCPT TO as
well as MAIL FROM.    RFC 2821 says, this limit is 256 bytes.
For e.g. if address is [email-masked]

So if we include the '<' and '>' characters,  will the total length be 258.
Or is it 256 inclusive of these characters?

Regards
Dilip Menon

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-moore-auto-email-response-03.txt,.ps,.pdf
Date: Wed, 03 Sep 2003 10:15:57 -0400
Sender: [email-masked]

--MIMEStream=_0+101333_9689738415055_14668048412

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

	Title		: Recommendations for Automatic Responses to Electronic 
                          Mail
	Author(s)	: K. Moore
	Filename	: draft-moore-auto-email-response-03.txt,.ps,.pdf
	Pages		: 19
	Date		: 2003-9-3
	
This memo makes recommendations for software that automatically responds
to incoming electronic mail messages, including 'out of the office' or
'vacation' response generators, mail filtering software, email-based
information services, and other automatic responders.  The purpose of
these recommendations is to discourage undesirable behavior which is
caused or aggravated by such software, to encourage uniform behavior
(where appropriate) among automatic mail responders, and to clear up
some sources of confusion among implementors of automatic email
responders.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-moore-auto-email-response-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-moore-auto-email-response-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-moore-auto-email-response-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--MIMEStream=_0+101333_9689738415055_14668048412
Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+180145_308750275821_623468290739"

--MIMEStream=_1+180145_308750275821_623468290739
Content-Type: Message/External-body; access-type="mail-server"; server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-moore-auto-email-response-03.txt

--MIMEStream=_1+180145_308750275821_623468290739
Content-Type: Message/External-body; name="draft-moore-auto-email-response-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--MIMEStream=_1+180145_308750275821_623468290739--
--MIMEStream=_0+101333_9689738415055_14668048412--

Date: Wed, 3 Sep 2003 10:39:16 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: changes in draft-moore-auto-email-response-03
Sender: [email-masked]

I thank everyone who sent in comments.  Most changes requested were
simple wording changes, and I made most of these.  I appreciate the
effort it took to read this document carefully.

One person recommended I broaden the scope of this document to include
all automatically generated messages.  I decided not to do that, as I
thought it would dilute the effectivness of this document regarding
automatic responses.  Also, I didn't want to think about what additional
considerations there might be for automatically generated messages, and 
I think it's much more important to specify the behavior of automatic
responses.

Keith
-- 
During times of universal deceit, telling the truth becomes a
revolutionary act. 			-- George Orwell

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-moore-auto-email-response-03.txt,.ps,.pdf
Date: Wed, 03 Sep 2003 10:15:57 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Recommendations for Automatic Responses to Electronic 
                          Mail
	Author(s)	: K. Moore
	Filename	: draft-moore-auto-email-response-03.txt,.ps,.pdf
	Pages		: 19
	Date		: 2003-9-3
	
This memo makes recommendations for software that automatically responds
to incoming electronic mail messages, including 'out of the office' or
'vacation' response generators, mail filtering software, email-based
information services, and other automatic responders.  The purpose of
these recommendations is to discourage undesirable behavior which is
caused or aggravated by such software, to encourage uniform behavior
(where appropriate) among automatic mail responders, and to clear up
some sources of confusion among implementors of automatic email
responders.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-moore-auto-email-response-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-moore-auto-email-response-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-moore-auto-email-response-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-moore-auto-email-response-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-moore-auto-email-response-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--