Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Date: Fri, 31 Oct 2003 13:07:23 GMT
Newsgroups: local.mime
List-Id: <ietf-822.imc.org>

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

>So my question remains:  are we doing the 3 billion asians a favor by forcing
>them to be able to tell the difference between e-caron and e-breve?

>....  You don't believe me? Take the character
>string 'valdis.kletnieks', change the first e to 0113 (small e-macron), punycode it,
>and let me know how much mnemonic value it has.

VALDIS.KLTNIEKS-q6B

Doesn't look too bad to me (I could guess which of the contributors to
this thread it related to).

But it wouldn't be of much use to a mongolian name, though.

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

To: [email-masked]
Xref: clerew local.mime:2752
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Fri, 31 Oct 2003 17:01:29 GMT
Lines: 61
Sender: [email-masked]

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

>OK.. I get that part.  Now for the big question:  You're there in this
>Mongolian intranet, and find you need to ask me a technical question,
>so my address gets entered in ascii. OK so far.  You now decide you
>need to cc: somebody on the intranet so they know I've been asked.

>1) What does that person do with my ascii-fied address?
>2) How do I do a 'reply all' to both of you?

I would suppose that the Mongolian (who is probably using the Mongolified
version of OE) will see his own address in Mongolian and your address in
ASCII (because for sure Microsoft will have left an "ASCII back-door" in
Mongolified OE :-) ).

Those ASCII characters look like nothing he has ever seen before, he has no
idea how to type them in even if he wanted to, but he gathers from the
body of the message that this American guy has been brought into the
thread, so he clicks the Mongolian equivalent of "Reply-to-all" and hopes
for the best. And indeed his MUA should then manage to send your copy back
to you (understanding his reply is another matter, but that is your
problem).

Your copy of the original message is probably worse. Your ASCII address
will surely be there, but it is most unlikely that your MUA knows how to
display Mongolian characters. If it is a good MUA, it will display some
set of Latin characters (perhaps a punycode verion of the Mongolian ones)
such that if you laboriously and correctly typed them into another email
it would get sent to the right place.

If it is a poor MUA, then it will simply replace each undisplayable
character with a '?'. But even then, unless it is an absolutely abysmal
MUA, I would expect it to generate a correct return address from its
internal representation of those characters, not from the
'?????@????.????.???' on your screen.

>3) How is your From: address encoded so it's usable *BOTH* from where
>I am and from where your co-worker is?

For that, you need some unique representation of Unicode that can be input
to any computer worldwide. Inevitably, it is going to look like gibberish
in all but a few environments, and basing it on ASCII (e.g. punycode) is
the only solution that is likely to fly.

What this IEA effort needs to do is to decide whether it wants to go that
way, and if not what alternatives there are. At the moment, all solutions
seem to have disadvantages, but that may be a part of the fundamental
nature of the problem. There is no law of nature which states that all
problems have a solution acceptable to all parties which will surely
become apparent if we debate them for a sifficient number of years.

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

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: [email-masked], [email-masked], IETF RFC-822 list <[email-masked]>, IMAA list <[email-masked]>
Date: Fri, 31 Oct 2003 17:24:33 +0100
Sender: [email-masked]

[email-masked] writes:
> So my question remains: are we doing the 3 billion asians a favor by 
> forcing them to be able to tell the difference between e-caron and 
> e-breve?

I got some advertising for www.renault-branchenloesungen.de the other 
day, because I'm part of the target group "clearly" expressed by that 
domain name.

Is Renault doing the people on this list, or those three billion Asians, 
a favour by using such an incomprehensible domain name? Not? But I 
don't think it's a problem either.

And I don't think the number of people who need to deal with e-macron, 
but don't know Lithuanian or Lettish, will be big. It'll be 
self-regulatingly small. People like you (Valdis), who might expose 
e-macron to us foreigners, tend to make our lives easier by changing 
the way you spell your names. Sure, if you were to insist that we (or 
those three billion) spell your name correctly, you'd cause some pain. 
But you don't, so that macron of yours isn't a problem for us.

(Btw, are those the right languages for e-macron? I'm fuzzy on that.)

--Arnt

Date: Fri, 31 Oct 2003 09:50:06 -0500
From: John Stracke <[email-masked]>
Organization: Centive
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Dave Aronson wrote:

>Think also of many businesses that cater to the general public, from 
>bleeding-edge geeks like us, to those who can barely spell PDA and 
>don't know what one is.
>
I think the only times I've seen anybody use PDAs to exchange contact 
information were at IETF meetings, in the hallways, when people had time 
to kill.  It just takes too long.  Typically, when two companies are 
meeting, and you've got, say, four people on each side, everybody swaps 
business cards in under a minute, and you're done.  Doing the same thing 
via IR would hold the meeting up too long.

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|I have strong opinions about ambivalence. |
\==========================================/

Date: Fri, 31 Oct 2003 17:39:01 +0800
From: James Seng <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
CC: [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Use ENUM. Get a phone number and NAPTR it to a mailto:[email-masked]

-James Seng

Adam M. Costello wrote:

> Sam Roberts <[email-masked]> wrote:
> 
> 
>>I'm suggesting that email addresses should be at least as useable as
>>telephone numbers.
> 
> 
> If you want email addresses to be at least as usable as telephone
> numbers, don't you need to restrict them to just the digits?  Certainly
> the number of people who can cope with digits exceeds the number of
> people who can cope with Latin letters.
> 
> If ASCII email addresses are better than non-ASCII email addresses,
> would numeric email addresses be even better still?  Is it unfortunate
> that non-digits were ever allowed in domain names and local parts in
> the first place?  Did allowing ASCII letters make email addresses less
> usable than they otherwise would have been?
> 
> Or did allowing ASCII letters make email addresses more usable?  Maybe
> it's a tradeoff between different kinds of usability.
> 
> Would allowing even more characters make email addresses even less
> usable, or even more usable?  Is the set of ASCII letters and digits the
> optimal point between the extremes?  If so, why?
> 
> AMC
> 
> P.S.  We can't quite limit email addresses to just the digits, because
> there has to be an at-sign, and scalable administration demands dots
> in the domain name, and the TLD needs to contain a non-digit to avoid
> being confused with an IP address, so the closest we can come might be
> something like this:
> 
> [email-masked]
> 
> 

Date: Fri, 31 Oct 2003 07:13:35 +0100
To: Sam Roberts <[email-masked]>
From: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 04:01 31/10/03, Sam Roberts wrote:
>Quoteing [email-masked], on Thu, Oct 30, 2003 at 08:39:26PM -0500:
> > So are you suggesting creating email addresses that look like:
> >
> > 4301@908-410
> >
> > which would translate to an existing phone number 908-410-4301
>
>Huh? What does that have to do with multi-lingual email addresses?
>
>I'm suggesting that email addresses should be at least as useable as
>telephone numbers. I can dial anywhere in the world on any handset
>using 0-9, any email scheme that ends in me not being to email a
>french friend because I'm in outer Mongolia, and the keyboard doesn't
>do e-grave is going to be a pain in the ass, and nobody will thank you
>for it.

This is a perfect example of real life vernacular. Thank you.
jfc  

Date: Fri, 31 Oct 2003 04:02:22 +0100
To: Markus Stumpf <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: jfcm <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

At 23:24 30/10/03, Markus Stumpf wrote:
>A big fair in Munich had tested kinda electronic cards lately. As you
>buy your ticket you type in your contact data and it is printed on the
>card as a barcode. Exhibitors had barcode readers and special
>software, so if you want to make a contact you hand over your ticket
>and the infos flow ...

Markus,
We are here in a typical layer violation we do not see. We think that 
passing information from layer 7 to a user is a simple task because ascii 
simplifies it to ascii readers. ENS Model puts 2 layers for that.

Your example is a very good common example of this:
- the application layer (7) has an infromation: the visitor carries and 
delivers his name to the registration system
- the interapplication layer (8) corresponds to the trade show system which 
organizes and manages the bar codes or other systems (magnetic, noise 
printing, laser, etc.) and the event and the lanes for him to stop at your 
boot using his feet and not bytes on a wire.
- the assistant layer (9) which is going to read the information for you 
and/or for your computer.
- until eventually you the user (layer 10) may access to the infromation 
and possibly disseminate to other layer 10 colleagues or colleges, or to 
escalate it to other communicating structures (11). For example the visitor 
may be a common client for your trade pavillon and benefit from a discount. 
And then you may want to verify his legal ID and hit the societal system 
layer (12).

All these layers car be executed by people and by machines. The simplest 
protocol is yes/no. It then increases in complexity through numbers, then 
langages and characters. Basic English and ASCII are one of the most 
interesting level for naked brainq. But what about computer (software) or 
community assisted (brainware) brains: whre is/are the most interesting 
levels of equilibrium?

This is why I say the target is not to develop internationalized, nor 
multilingual names. To please  Hindi vs American (objections stand). But a 
truly fully vernacular support for users and applications. This means even 
more than transparent binary, because binary is only to be one occurence in 
it.

We have a default : ascii. We have a first level of complexity : IDNA. This 
must continue. This is why I objected to the (xn--) structure. It is to be 
necessarily the begining of an unlimited vernacularisation. Having entered 
the xn-- in the left of the name label introduced a cross hierarchical 
structure in the DNS (levels from right to left and layers within the 
labels from left to right). With a complex impact on the DNS administration 
and evolution - as we start seeing it now. Another exemple is IPv6. I doubt 
we can continue writing manually db.flles addresses.

Now, several question the need of a change. IMHO they are right and wrong 
as we do not consider the layers. At the user's layer we must have 
everything in the language and culture of the user. We are not going to say 
that cultures are bugs to correct to fit IDNA! But at the old SMTP level or 
DNS do we need that complexity? I think not. Even if we were building a 
brand nwe DNS.

What Vint suggests is to use ASCII as a 35 or 37 highly readable numbering 
pad (2 to 9 A to Z and "-", or 0 to 9) to give more capacities to support 
vernacularization on the layer above. Otherwise everything is going to 
collapse into a too complex system. For example where are you going to 
introduce the OPES which will read the written chinese in the proper local 
way? This is the same problem as for the multilingual TLDs. In a flat model 
we saw it was not possible. I do not see a real problem in a properly set 
multi-layer model. One layer can go one way and the next layer the other 
way. Then you know what you wand to do where.

jfc

>There WILL be a lot of problems with internationalized email addresses
>but IMHO a lot of them will be solvable by sophisticated software.
>Some of them won't as in print media (and also tv. radio, ...) a domain
>     �.de        (in 8859-1)
>and
>     �.de        (in 8859-7)
>looks identical, but isn't as the � sit on different codes. So the
>commercials will be fun:
>     "visit us in the Internet on www.�.de in good old 8859-1 coding."
>
>And despite all these I think it will be a long time until addresses like
>     j�rgen.gr��l@h�berbr�u.de
>will look familiar (even if this is a (for me) local coding).
>
>         \Maex
>
>--
>SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
>Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
>"The security, stability and reliability of a computer system is reciprocally
>  proportional to the amount of vacuity between the ears of the admin"

Date: Thu, 30 Oct 2003 22:01:42 -0500
From: Sam Roberts <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Quoteing [email-masked], on Thu, Oct 30, 2003 at 08:39:26PM -0500:
> So are you suggesting creating email addresses that look like:
> 
> 4301@908-410 
> 
> which would translate to an existing phone number 908-410-4301

Huh? What does that have to do with multi-lingual email addresses?

I'm suggesting that email addresses should be at least as useable as
telephone numbers. I can dial anywhere in the world on any handset
using 0-9, any email scheme that ends in me not being to email a
french friend because I'm in outer Mongolia, and the keyboard doesn't
do e-grave is going to be a pain in the ass, and nobody will thank you
for it.

Sam

 Al
> ----- Original Message ----- 
> From: "Sam Roberts" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Thursday, October 30, 2003 8:36 PM
> Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
> 
> 
> > 
> > We already have internationalized email addresses, in a sense, you can
> > put a multi-lingual phrase before the address. A few email clients (that
> > I hate, but whatever) actually don't even show you the email address,
> > they just show you the (multilingual) name. So, its possible to write
> > your name in any character set you like beside your address.
> > 
> > The idea of multi-lingual local-parts sounds great, the inability to
> > communicate with people in other countries doesn't. I couldn't even
> > get a chinese speaking friend to type in a chinese email address on my
> > machine, since I don't have a chinese character input method for Mutt,
> > so even literacy wouldn't necessarily help!
> > 
> > Somebody else mentioned the hotel in Turkey with the Turkish email
> > address.  With a phone, I may not be able to speak to that hotel keeper
> > in Turkey, but I can dial his number with my phone, and my roommate
> > speaks French, and maybe so does he a little, so she can help me out.
> > Email needs to be like that.
> > 
> > Cheers,
> > Sam
> > 
> > 

From: "Al Costanzo" <[email-masked]>
To: "Sam Roberts" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Thu, 30 Oct 2003 20:39:26 -0500
Sender: [email-masked]

So are you suggesting creating email addresses that look like:

4301@908-410 

which would translate to an existing phone number 908-410-4301

Al
----- Original Message ----- 
From: "Sam Roberts" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, October 30, 2003 8:36 PM
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)

> 
> We already have internationalized email addresses, in a sense, you can
> put a multi-lingual phrase before the address. A few email clients (that
> I hate, but whatever) actually don't even show you the email address,
> they just show you the (multilingual) name. So, its possible to write
> your name in any character set you like beside your address.
> 
> The idea of multi-lingual local-parts sounds great, the inability to
> communicate with people in other countries doesn't. I couldn't even
> get a chinese speaking friend to type in a chinese email address on my
> machine, since I don't have a chinese character input method for Mutt,
> so even literacy wouldn't necessarily help!
> 
> Somebody else mentioned the hotel in Turkey with the Turkish email
> address.  With a phone, I may not be able to speak to that hotel keeper
> in Turkey, but I can dial his number with my phone, and my roommate
> speaks French, and maybe so does he a little, so she can help me out.
> Email needs to be like that.
> 
> Cheers,
> Sam
> 
> 

Date: Thu, 30 Oct 2003 20:36:30 -0500
From: Sam Roberts <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

We already have internationalized email addresses, in a sense, you can
put a multi-lingual phrase before the address. A few email clients (that
I hate, but whatever) actually don't even show you the email address,
they just show you the (multilingual) name. So, its possible to write
your name in any character set you like beside your address.

The idea of multi-lingual local-parts sounds great, the inability to
communicate with people in other countries doesn't. I couldn't even
get a chinese speaking friend to type in a chinese email address on my
machine, since I don't have a chinese character input method for Mutt,
so even literacy wouldn't necessarily help!

Somebody else mentioned the hotel in Turkey with the Turkish email
address.  With a phone, I may not be able to speak to that hotel keeper
in Turkey, but I can dial his number with my phone, and my roommate
speaks French, and maybe so does he a little, so she can help me out.
Email needs to be like that.

Cheers,
Sam

Date: Thu, 30 Oct 2003 14:34:40 -0700 (MST)
From: Vernon Schryver <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> From: [email-masked]
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]

> ...
> Are we doing *anybody* favors ...

Contrary to super heated claims about unfairness and disenfranchisement,
the purposes of this approaching train wreck do not include doing any
users any favors.  At best it is about proving the maturity of the
IETF by inventing a scheme that will make x.400 addresses seem clear
and obvious.

The first and most important thing about train wrecks is that you
don't want to be standing close to where they happen.  After waiving
your lantern at the people in the engine cabs, it's best run as fast
as you can.

The second thing is that after the fire, smoke, and noise settles,
you will see armies of people and equipment working on enormous piles
of debris.

The third thing is that although the debris piles and surrounding
encampments will look permanent, they will disappear almost overnight
and leave almost no sign.  In 5 years, everyone except the most laggard
acolytes of trade rag gurus will have forgotten it.  By then there
will be a new runaway internationalization mail address train about
to derail. 

It's not as if we've not been here before.  It's past time to start
running to get out of the way of this train.  Who knows?  Maybe this
time time the internationalized mail address train won't wreck itself
at the bottom of the pass.

In other words, do all three of these mailing lists need this traffic?

Vernon Schryver    [email-masked]

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) 
From: [email-masked]
Date: Thu, 30 Oct 2003 15:44:06 -0500
Sender: [email-masked]

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

On Thu, 30 Oct 2003 09:13:55 PST, [email-masked] said:
> Forget Mongolian. Think Chinese and Hindi, plus related languages that
> use their character sets. Between the two of them you have nearly 3
> billion potential users, i.e. half the world's population. Admittedly
> not all of them are literate, and many do understand the Latin character
> set, but this is still a very large group to disenfranchise.

Right.  The yet unanswered question is how many would be disenfranchised
by making them learn the Latin charset, compared to how many would
be disenfranchised by a non-perfect globalization scheme (see my comment
yesterday regarding macrons and carons).

> There is a second thread to your argument which I object to. Just
> because many Internet users can understand the Latin character set does
> not mean they do not want to send stuff in their native character set,
> or be forced to use the Latin character set. Of course so far we have
> made it impossible to do so.

Note that this is discussing *addresses only*.  We've had charset
support for bodyparts and 2047-encoding for other header fields for *years*.

I get at least 5 or 6 emails a day that have addresses of the form
From: "kanji/big5/etc string here" <[email-masked]>
and/or have charset=utf-8 and kanji in them.

> Why place unnecessary restrictions on the Internet just because it
> results in messages that you personally can't understand?

An equally important consideration is that it result in messages that
are *usable* (possibly without comprehension). If whatever scheme we
decide on results in messages that I can't hit "reply" to or otherwise
process, it's not doing anybody any favors.

An often overlooked aspect of the ASCII charset is that it has 52 glyphs
which for the most part are visually distinctive (except for zero/oh, and
one/lower-ell), so even a non-speaker can make a determination "have I
entered the same glyphs as are on the business card?". This is not true
for any of the Asian glyph sets (at least *I* can't tell easily), and I
don't think that the Latin 1/A/B extension has this property either,
once you start dealing with macrons, cedillas, ogonceks, carons, dots,
and other ornamentation....

So my question remains:  are we doing the 3 billion asians a favor by forcing
them to be able to tell the difference between e-caron and e-breve?

Are we doing *anybody* favors if we make them use rfc3490-style xn-- strings
that are totally incomprehensible if they are from outside the local conclave?
Remember - if they don't understand Latin charsets, a 3490-encoded address will
be *painful*, even for the *owner*.  You don't believe me? Take the character
string 'valdis.kletnieks', change the first e to 0113 (small e-macron), punycode it,
and let me know how much mnemonic value it has.

And remember - the string you get there is the sort of thing that all 3 billion
Asians will get to enter (after I get my sysadmin to set up the aliases to get that
punycode to actually drop into *my* mailbox).

Are you sure it's worth the effort?

It's not that I'm unsympathetic to the goals - far from it.  It's just that I
was there during the RFC2047 wars (which are *still* going on in the spam
world, silly spammers sending around untagged 8-bit headers), and a big part
of me wants to say "Oh no, not again....".

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

--==_Exmh_1769311138P--

Date: Thu, 30 Oct 2003 17:23:25 +0100
To: Keith Moore <[email-masked]>
From: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 18:53 29/10/03, Keith Moore wrote:
>Content-Transfer-Encoding: 7bit
>I suspect it would much more useful if people tried to characterize
>what they and their cohorts want, rather than trying to characterize what 
>some
>other group wants.

This is exactly what I do. As a users (icannatlarge) a community (intlnet) 
and a language (Eurolinc) organizations. The people this group says it to 
want to hear from and never sent a questionnaire to.
So, I will say it again on behalf of my cohort.

When asked what they want, they are first ambarassed because people tend to 
say they want things which are feasible. When explained what there was 
(ascii) and what there is/could be and to suppose that everything is 
possible there are three responses. I repeat, in my cohort:

- American speaking people feel IDNA is great (responses from CONs people 
are more complex)
- international project managers respond like Tan Tin Wee : multilingual
- the users respond "what I do everywhere else". This has a name : vernacular.

If your cohort do not want to hear what my cohort wants, don't ask! If you 
are not convinced or know better than me, you welcome to ask yourself. I 
ran questionnaires, I had a web page quizz on on that. Now, I am not M$, 
ICANN or Verisign to get thousand of responses. But I am reasonably 
satisfied that this is a fair and accurate representation of the demand.
jfc

> > This being said only Americans want/are satisfied with "internationalized"
> > (sic) names (the artificial extension of the American character set with
> > most of the American foreign scripting, within an ascii frame). No one
> > really wants multilingual names (a totally internationalized (sic) frame
> > supporting languages and therefore some language oriented rules - at least
> > ni management and user support). The users need vernacular support, 
> that is
> > to be able to freely do in the mail what they use to do elsewhere.
> >
> > I note that for non-American writers "international names" means names 
> that
> > everyone from every nation will understand. It happens to be the ascii
> > character set limited to the DNS used names (they were selected for that
> > reason).
> > jfc

To: [email-masked]
Xref: clerew local.mime:2739
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Date: Thu, 30 Oct 2003 11:22:41 GMT
Lines: 38
Sender: [email-masked]

In <prYqvhAU+WKtGdjb/[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>Perhaps the auto-submitted "parameter" could be elaborated a little, 
>mentioning two optional parameters, "generator" and "type", and saying 
>that "type" is "antivirus", "vacation", "new-ticket" or something else, 
>and generator is a string describing the product.

>   Auto-Submitted: auto-generated; type=antivirus; generator="sophos blah".

>That would be very like e.g. content-type and content-disposition.

Yes indeed. That is the way USEFOR has been moving. _Every_ header has
provision for an arbitrary number of MIME-style headers
(ideally - it will be some years before you can rely on it for all headers
but is fine for new ones). That way, extensions can be defined in future RFCs
in a way that is upwards compatible, and without having to invent YANH
each time.

So you define your Auto-Submitted header with 'type' and 'generator'
parameters (which you foresee as being useful). And you state that all
other parameters SHOULD be simply ignored by agents which do not recognize
them. That even allows individual responders to insert their own
X-parameters for whatever reason, which recipients can then immediately
ignore.

And a 'ticket-no=123456' parameter might indeed be a useful one to have
from the start.

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

Date: Thu, 30 Oct 2003 07:58:27 +0000
To: [email-masked], Tan Tin Wee <[email-masked]>
From: Steve Dyer <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) 
Sender: [email-masked]

At 01:24 30/10/2003 -0500, [email-masked] wrote:
>On Thu, 30 Oct 2003 13:33:31 +0800, Tan Tin Wee said:
> >snip
>If whatever Mongolia was doing was guaranteed to stay in Mongolia, it wouldn't
>be an issue.  However, people inside the enclave *will* want to communicate
>with outsiders as well - and the instant you allow an e-mail to cross the
>border, you have to get all these types of issues sorted out.
>
>Mark Crispin's point was that currently, knowledge of Latin glyphs *is*
>assumed, and as far as anybody has evidenced, this hypothetical Mongolian
>intranet with many non-Latin-aware users is still hypothetical - and with no
>evidence saying there actually IS one in the works someplace.  So Mark quite
>reasonably pointed out that it may very well make more *engineering* sense to
>simply train the very small number of users who don't know Latin glyphs 
>than to
>come up with some very convoluted scheme that annoys everybody else.

Hi

The above is a self-fulfilling prophesy. Of course you have to have a 
knowledge of Latin glyphs because the only Internet around is based on it.
The millions of people (including Mongolians) who don't know latin glyphs 
(and may not yet have computers, and may be illiterate) are still the 
future users, possibly the majority of future users, of the Internet and 
this effort is to address their future needs.

My observation is that we are maybe worrying too much about the characters 
being represented and how they are used, We should merely define a 
protocol. In my book that protocol should allow email addresses to carry 
the widest possible eight-bit ASCII payload. (ie. everything except control 
characters) so that existing non-unicode special characters can be carried, 
and can also carry IDN-style unicoded characters.

Sure there will be problems, - there will be anyway. However we need to 
enable local users to communicate in local scripts in the local language.

In this regard Europeans and Americans are maybe too steeped in the 
existing latin/ASCII to address this issue.  We should listen carefully to 
the non-latin world rather than trying to find reasons not to do it.

I often get completely incomprehensible emails which originated in 
non-latin scripts - I just delete them. I know they're not important for me 
because no author who tries to write to me in Chinese is going to get very 
far no matter what communication medium he uses. Why? Because I don't speak 
Chinese.

>The tail has to be a certain size before it's able to wag the dog.

This dog is almost all tail!

Regards

Steve Dyer 

Date: Wed, 29 Oct 2003 23:09:24 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Valdis,

VKve> Mark actually *does* have a *very* valid point - on today's internet, if you

1. The goal is to go beyond today's internet. (But then, that is always the
goal of a new standard.)

2. Although the primary focus of IETF work is to make standards for global
interoperability, there are fine and valid needs for making global conventions
to support local interoperability. Permitting local-part to be unicode is one
of those. (And, no, I do not believe this requires changing the global parsing
rules.)

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

To: Tan Tin Wee <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) 
From: [email-masked]
Date: Thu, 30 Oct 2003 01:24:33 -0500
Sender: [email-masked]

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

On Thu, 30 Oct 2003 13:33:31 +0800, Tan Tin Wee said:
> And if they need to send email to outsiders, then they would
> send in ASCII email address, as routinely as they would

OK.. I get that part.  Now for the big question:  You're there in this
Mongolian intranet, and find you need to ask me a technical question,
so my address gets entered in ascii. OK so far.  You now decide you
need to cc: somebody on the intranet so they know I've been asked.

1) What does that person do with my ascii-fied address?
2) How do I do a 'reply all' to both of you?

3) How is your From: address encoded so it's usable *BOTH* from where
I am and from where your co-worker is?  

3a) Can you achieve goal (3) while using the same From: as you would use
if you were mailing ONLY to the intranet (so people don't have to maintain
2 differently encoded values for your address for filtering purposes, etc).

If whatever Mongolia was doing was guaranteed to stay in Mongolia, it wouldn't
be an issue.  However, people inside the enclave *will* want to communicate
with outsiders as well - and the instant you allow an e-mail to cross the
border, you have to get all these types of issues sorted out.

Mark Crispin's point was that currently, knowledge of Latin glyphs *is*
assumed, and as far as anybody has evidenced, this hypothetical Mongolian
intranet with many non-Latin-aware users is still hypothetical - and with no
evidence saying there actually IS one in the works someplace.  So Mark quite
reasonably pointed out that it may very well make more *engineering* sense to
simply train the very small number of users who don't know Latin glyphs than to
come up with some very convoluted scheme that annoys everybody else.

The tail has to be a certain size before it's able to wag the dog. 

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

--==_Exmh_-458448288P--

Date: Thu, 30 Oct 2003 13:33:31 +0800
From: Tan Tin Wee <[email-masked]>
To: [email-masked]
CC: James Seng <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

[email-masked] wrote:
> On Thu, 30 Oct 2003 07:32:46 +0800, James Seng said:
> 
>>to your opinion but please do so in other place, and not here. The group 
>>is suppose to work on Internationalization of Email address 
>>(identifiers), not debate whether we need it or not.
> 
> 
> Any group that addresses "how" and "for which contexts" without having
> a good grasp on "why" is inventing solutions in search of problems.
[snipped]

> 
> And if you can't safely put e-caron on a business card, why are we bothering?

We're bothering because it has occurred to some of us that
some folks somewhere in the world may wish to send email only to
themselves within an intranet or a large national intranet or
wish to launch their own internal e-government or
e-education system that involves interpersonal
and interdepartmental communications amongst folks that
speak the same language which doesn't not happen to be Latin-based.
And if they need to send email to outsiders, then they would
send in ASCII email address, as routinely as they would
flipping between the reverse and obverse of their
namecards, one side the local language (including their
local IEA address) and the other, the global lingua franca
latin.

Right now, the Mongolian (or whatever) government cannot launch say
their e-Government intranet email system seamlessly with
the Internet without much pain in getting everyone up to
speed on the latin character set. IEA support will definitely
be a boon to such folks.

To: James Seng <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) 
From: [email-masked]
Date: Wed, 29 Oct 2003 23:44:56 -0500
Sender: [email-masked]

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

On Thu, 30 Oct 2003 07:32:46 +0800, James Seng said:
> to your opinion but please do so in other place, and not here. The group 
> is suppose to work on Internationalization of Email address 
> (identifiers), not debate whether we need it or not.

Any group that addresses "how" and "for which contexts" without having
a good grasp on "why" is inventing solutions in search of problems.

Mark actually *does* have a *very* valid point - on today's internet, if you
cannot recognize and enter the glyphs for at least c, h, m, o p, t, w, ':',
'@', '.', and '/' you are effectively unable to use the internet.  It may not
make any sense to you, but you can at least recognize and enter them (note that
this same issue was one of the biggest arguments against the .biz domain).

So.. having established that if they're currently using the internet, they can at least
recognize and enter the Latin glyphs, this raises a number of *very* important questions:

1) Is there reason to *not* expect said knowledge of Latin glyphs in the future?
If not, what user group(s) will be literate but not know the Latin charset?

2) Is a "community" approach acceptable?  Is usage of Han OK as long as
you're interacting with other Han users, or are the issues of leakage too high?

3) What *are* the issues of leakage? What am I expected to see if I get some Han,
and how am I to interact with it?  Equally important, what does the Han user do
with my leaked Latin-A characters?

4) Here's a somewhat related issue - looking at the U0100.pdf from www.unicode,org,
I had to enlarge page 2 quite a bit before I could see the difference between the glyphs
at 0114/0115 (capital/small e with breve) and 011A/011B (capital/small e with caron).
And I know my way around most of the Latin characters - our hypothetical Han
user is going to be swinging in the breeze if he gets a business card with e-caron on it.

And if you can't safely put e-caron on a business card, why are we bothering?

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

--==_Exmh_-1782565142P--

Date: Thu, 30 Oct 2003 07:32:46 +0800
From: James Seng <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Abhijit Menon-Sen <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> I do not believe that this is true for Chinese.  AFAIK, Chinese primary
> school kids use Latin script with hanyu-pinyin as a stopgap prior to their
> mastery of Han script (which takes many years).

Nope. Hanyu Pinyin was designed to replace the Han ideograph but it 
never did.

> Note that when I say "recognize Latin script", I mean the ability to
> determine that "dog" is a three-letter word that has the letters "d", "o",
> and "g", each of which the individual recognizes and can name.  This does
> not include the ability to recognize that this refers to a domesticated
> canine.

Based on your reasonings, I think we should all reverted back to 
numbers, because that is the only universal recongizable set of symbols 
we have.

We have this argument in IDN before and we certainly dont need this 
again. If you feel we should all stick to Latin, yes, you are entitled 
to your opinion but please do so in other place, and not here. The group 
is suppose to work on Internationalization of Email address 
(identifiers), not debate whether we need it or not.

-James Seng

Date: Thu, 30 Oct 2003 07:26:28 +0800
From: James Seng <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Crispin,

You need to get out of US (or Wsshington) more often.

-James Seng

> I am not convinced that it is possible to use a computer on the Internet
> anywhere in the world without at least a basic acquaintance with Latin
> script.
> 
> I do not believe many individuals (other than primary school children) are
> literate in their native language but are completely illiterate in Latin
> script.  This does not mean "being able to read or write the English
> language"; rather, this simply means knowing the Latin script alphabet.
> 
> Put another way, individuals who are completely illiterate in Latin script
> are also likely to be illiterate in their native language script as well.
> 
> No other script on the planet has such international recognition.
> 
> There is undoubtably a *preference* for one's native script; and that
> preference should be respected as much as possible.
> 
> -- Mark --
> 
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
> 
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: [idn] FYI: BOF on Internationalized Email Addresses (IEA)
Date: Wed, 29 Oct 2003 15:18:45 -0800
From: "Michel Suignard" <[email-masked]>
To: "James Seng" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Pete Resnick" <[email-masked]>, "Ted Hardie" <[email-masked]>, "Ned Freed" <[email-masked]>
Sender: [email-masked]

JS>I seen John and Paul proposal but I have not seen Michel. Is there a draft that I can read
JS>up? 

I don't have a proposal. I am listed there as a co-editor of the IRI spec which has a peripheral impact on the IEA (such as extending the URI mailto scheme). Like many I am listening with interest to the points made for or against the two proposals.

Michel Suignard

Date: Wed, 29 Oct 2003 12:53:52 -0500
From: Keith Moore <[email-masked]>
To: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

I suspect it would much more useful if people tried to characterize
what they and their cohorts want, rather than trying to characterize what some 
other group wants.

> This being said only Americans want/are satisfied with "internationalized" 
> (sic) names (the artificial extension of the American character set with 
> most of the American foreign scripting, within an ascii frame). No one 
> really wants multilingual names (a totally internationalized (sic) frame 
> supporting languages and therefore some language oriented rules - at least 
> ni management and user support). The users need vernacular support, that is 
> to be able to freely do in the mail what they use to do elsewhere.
> 
> I note that for non-American writers "international names" means names that 
> everyone from every nation will understand. It happens to be the ascii 
> character set limited to the DNS used names (they were selected for that 
> reason).
> jfc

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Cc: Markus Stumpf <[email-masked]>, IETF RFC-822 list <[email-masked]>
Date: Wed, 29 Oct 2003 17:57:05 +0100
Sender: [email-masked]

Keith Moore writes:
> auto-submitted doesn't want to be come a general-purpose message 
> labelling mechanism. arguably we have too many of those already. we 
> could use content-disposition or content-type or 
> content-description....

The example I posted, "auto-submitted: auto-generated; generator=sophos; 
type=antivirus". Where should it go? Is it reasonable in the first 
place? Markus has presented a case that such details are useful - a 
sufficient case?

Content-Type is about the content's format, not about its nature. That 
is to say, it's text/plain rather than text/essay or text/autoresponse.

Content-Description is unstructured human-readable text which IMO makes 
it unusable.

Content-Disposition is about how the receiver should present the 
message, e.g. a suggested filename for a file. I suppose something like 
"type=antivirus" might go here, since the purpose of that is to enable 
appropriate disposition (AKA file in /dev/null).

I've seen X-Mailer and User-Agent, but can't summon much enthusiasm for them.

So if an autoresponder wants to say something about which generator 
auto-generated a message, auto-submitted seems the right place. The 
"type" could go either here or in content-disposition, both seem about 
equally appropriate to me, depending on whether the "type" is seen as 
the type of responder or the type of response.

--Arnt

Date: Wed, 29 Oct 2003 16:50:39 +0100
To: Zefram <[email-masked]>
From: "J-F C. (Jefsey)  Morfin" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 10:31 28/10/03, Zefram said:
>I think the first task in this area should be to investigate the nature 
>and degree of desire for non-ASCII local parts.  This desire needs to be 
>weighed against the benefits we derive from writing all local parts in a 
>small, fixed alphabet (ASCII printables).

May I ask which part of the world you come from?

This being said only Americans want/are satisfied with "internationalized" 
(sic) names (the artificial extension of the American character set with 
most of the American foreign scripting, within an ascii frame). No one 
really wants multilingual names (a totally internationalized (sic) frame 
supporting languages and therefore some language oriented rules - at least 
ni management and user support). The users need vernacular support, that is 
to be able to freely do in the mail what they use to do elsewhere.

I note that for non-American writers "international names" means names that 
everyone from every nation will understand. It happens to be the ascii 
character set limited to the DNS used names (they were selected for that 
reason).
jfc

To: [email-masked]
Xref: clerew local.mime:2727
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Wed, 29 Oct 2003 11:28:21 GMT
Lines: 42
Sender: [email-masked]

In <8588837.1067340808@localhost> John C Klensin <[email-masked]> writes:

>(1) Another advantage of "just" using UTF-8 in an appropriately
>negotiated, controlled, and constrained environment is that any
>idiosyncracies and coding difficulties are Unicode
>idiosyncracies and coding difficulties.  If we decide to use a
>specialized coding designed for email local-parts (and, fwiw, I
>think Adam's coding solution is brilliant... I'm ultimately just
>unhappy with the problem definition to which it responds), then
>we have to deal with both its idiosyncracies _and_ those of
>Unicode.  Strikes me as a bad idea -- better to just blame
>"them" :-)

Exactly so. "Just send UTF-8" is undoubtedly going to happen, and probably
sooner rather than later. All the IETF can do is to try to ensure that the
transition to it is an orderly one.

Therefore, solutions to this problem should be on the assumption that
ultimately "just send UTF-8" will happen, and they should look sensible in
that context. That then means the solutions can be based on Unicode
practice (which will already be dealing with rather similar problems in
other protocols). Issues such as what normalization and/or strinprep to
use, who is responsible for doing the normalization, and when, how wide
your "@" character should be (and doesn't NFKC and/or stringprep already
narrow it anyway?), and so on.

Encodings into and out of punycode (and other encodings) will be needed
during a transitional period, and that period may well last for a very
long time. But the system must appear to the users as if the UTF-8 had
indeed travelled end to end, and eventually that should be exactly what it
does.

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

From: Arnt Gulbrandsen <[email-masked]>
To: Markus Stumpf <[email-masked]>
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Cc: IETF RFC-822 list <[email-masked]>
Date: Wed, 29 Oct 2003 11:41:06 +0100
Sender: [email-masked]

Markus Stumpf writes:
> On Tue, Oct 28, 2003 at 05:43:52PM +0100, Arnt Gulbrandsen wrote:
>>  >  IMHO a personal responder (vacation) should send the message to the
>>  >From field.
>>
>>  Do that, and the document die as irate mailing-list posters complain 
>>  about having received vacation messages whenever they post to a 
>>  list.
>
> As outlined in the draft vaction programs should never answer to posts
> from a mailing list ;-)

Yep. IMO, in the best case, there'll be a five-year transition until 99% 
of responders are "good". Can't have too much pain during that 
transition.

> So add a list that lists the pro's and con's of each field. Just 
> because there are controversal opinions is not a reason to drop the 
> topic at all.

It is, IMHO. An RFC that draws too many flames is not an RFC that'll be 
implemented widely and well.

Feel free to suggest text changes/additions.

>>  Achieve agreement on what the rules should be?
>
> If there are rules there would be something a programmer of a vacation 
> type program could stick to.

And disagree visciously about. Recently, X-* fields were mentioned on 
this list. Apparently, people disagreed so viciously that RFC 2822 
finally came out without any mention of x-*.

Broken stuff won't go away. But please, let's have a document that won't 
be ignored because some parts are flame-worthy, or held up because it 
attempts to specify too much. Let's have something modest and good. 
It's always possible to supplement it with a later vacation 
specification.

>>  Inappropriate, IMO. Too much of a special case, and besides, you 
>>  don't want to ignore a whole category just like that.
>
> You mean something that makes 90% of all "responder" traffic at times 
> is an "inappropriate special case"? ;-)

Yes. Just like it would be an inappropriate special case to say 
"Content-type: antivirus-warning".

> The same could however be achieved with
>     Auto-Submitted: auto-generated; antivirus W32/Sobig-F
> and maybe antivirus vendors will take it up in a way like that but 
> then we'd have 30 different semi-standarized comment fields ;-)

That would be much better, but I'm still not quite persuaded. That seems 
to be turning auto-submitted towards being a hierarchical 
specification, which fits badly in its environment.

Perhaps the auto-submitted "parameter" could be elaborated a little, 
mentioning two optional parameters, "generator" and "type", and saying 
that "type" is "antivirus", "vacation", "new-ticket" or something else, 
and generator is a string describing the product.

   Auto-Submitted: auto-generated; type=antivirus; generator="sophos blah".

That would be very like e.g. content-type and content-disposition.

--Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Cc: Markus Stumpf <[email-masked]>, IETF RFC-822 list <[email-masked]>
Date: Wed, 29 Oct 2003 10:54:28 +0100
Sender: [email-masked]

Keith Moore writes:
>> Shall we say it started out as a BCP, which then grew small 
>> prescriptive leanings in the form of the "auto" prefix and 
>> auto-submitted?
>
> you could say that, but I don't think it would be accurate.

The huge thread last year seemed to be about best current practice 
rather than innovative improvement... but it doesn't matter. The 
document is where it is, neither a simple description of the past nor a 
prescription for radical change.

IMHO, the document strikes the right balance between describing BCP and 
making small, safe improvements that will not launch flame wars.

> the document has always been about protocols, and it has always been 
> intended to affect running code, even if it wasn't so much specifying 
> data formats.

Even a 100% pure BCP would affect much running code, sadly ;)

--Arnt

To: Zefram <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA) 
From: [email-masked]
Date: Wed, 29 Oct 2003 02:51:55 -0500
Sender: [email-masked]

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

On Tue, 28 Oct 2003 15:13:06 GMT, Zefram said:

> It doesn't start to get tricky until we get into the eastern European
> languages -- ASCII only intentionally provides western European
> diacriticals.

"Macrons and carons and cedillas, oh my..." :)

Actually, ASCII doesn't intentionally provide any diacriticals. Western
European diacriticals are in the Unicode Latin-1 Supplement, and (as you
correctly note) some of us of the eastern European persuasion need characters
from Latin-A and/or Latin-B to actually do things...
  
> Cue the debate about whether the diacritic should go before or after
> the base letter.

So tell me, does the dot on an 'i' go before or after the base letter?

(OK, so I'm just touchy because nobody on this side of the big puddle
wants to deal with the fact that the 3rd letter of the preferred spelling of
my last name is Unicode codepoint 0113 (Latin small e with macron)).

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

--==_Exmh_-1326845046P--

Date: Tue, 28 Oct 2003 23:47:40 -0500
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> Given that we have gone through this paradigm debate several times over the
> last decade, I am hard-pressed to understand why anyone would think that it
> will be productive to do it again.

because
- email addresses are much more heavily used by humans than URLs are,
  and the impact of an IDNA-like scheme on email addresses is greater
  than for other apps using DNS names
- email is more disruption-sensitive than most apps (every MTA that a
  message passes through is another opportunity for failure)
- people expect to use their names in email local-parts more often 
  than they expect to use enterprise names as DNS domain names
- matching/uniqueness issues for personal names (thus email local-parts)
  are somewhat different than for enterprise names (especially given 
  influence of trademark laws on the latter)
- having IDNA for the domain portion of an address provides a useful hook
  for looking up mappings from I18Ned local-parts to unique portable
  identifiers

because failure to actually do analysis on the problem is irresponsible and
inconsistent with the engineering that we're supposed to be doing

(note this is about why it's appropriate to analyze the specific problem
at hand rather than blindly pursue a particular approach - not about the
merits of John's proposal - which I haven't finished reading yet)

Keith

Date: Tue, 28 Oct 2003 20:15:02 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: IETF RFC-822 list <[email-masked]>, [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Pete,

>>putting anything other than ASCII characters in email headers is
>>completely unacceptable.
PR> Let me try this one more time: Please read John Klensin's draft
PR> before making these kinds of statements. Either you and Dave have 
PR> dismissed this draft without giving technical reasons for why you 
PR> have, or you simply haven't read the draft. Please let's all get on 
PR> the same page before arguing.

Sorry.  Thought I was being pretty clear, but now that you mention it, I
didn't connect all the dots -- perhaps my latest note did, but just to be
clear:

Yes, I've dismissed John's proposal, in terms of any near-term benefit.

I see the issue as exactly the same as we had for MIME/ESMTP, with one
approach being solely adopted in the user agent software that adopts the
enhancement, and the other approach requiring infrastructure modification.

I see one as continuing the model started by IDNA, and the other as
essentially tossing it out and starting over.

Given that we have gone through this paradigm debate several times over the
last decade, I am hard-pressed to understand why anyone would think that it
will be productive to do it again.

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

Date: Tue, 28 Oct 2003 17:41:55 -0800
To: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Location of the IMAA list (was: RE: FYI: BOF on Internationalized Email Addresses (IEA))
Sender: [email-masked]

At 11:54 AM -0500 10/28/03, [email-masked] wrote:
>The BOF description lists [email-masked] as the
>discussion list, but this discussion is being
>cc:ed to [email-masked].  I'd suggest that you
>move this discussion to whichever of those lists
>is actually correct.

It is [email-masked], although because Patrik sent out the wrong 
address, I have made sure that both addresses work. An archive of the 
list, and links to the current versions of the drafts, can be found 
at <http://www.imc.org/ietf-imaa/>.

No more messages to all lists: that's what the IMAA list is for.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 28 Oct 2003 16:20:00 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: John Cowan <[email-masked]>
cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, John Cowan wrote:
> But if they write you for support, they have to use a language you
> understand; people who can only handle Hindi can't get support from you
> and don't need to be able to type your email address (assuming wlg that
> you have no Hindi).

This is confusing apples and oranges again.  We are not talking about the
language of the email text.  We are talking about the email address, and
whether or not the individuals at each end can read and enter the other's
email address.

We are, in effect, talking about the equivalent of extending the 10 digits
of telephone numbers to have letters.  And I'm not talking about the
strange American convention of saying "my phone number is 555-COOL-GUY"
when in fact the number is 555-266-5489.  I'm talking about adding
entirely new discreet things that can be dialed.  And phones which only
have digits can't call these numbers.  Or can they?

If so, how?  That, more than anything else, is what any IEA solution will
have to address.  We can safely assume that if Hindi IEA addresses are
possible, Hindi environment software will quite capably provide a means
for Hindi users to use these addresses.  We can even safely assume that as
long as there is a way (any way), it doesn't really matter what format the
bits are in; the Hindi user interface software will smooth over any rough
edges.

The messy part is how software that doesn't know Hindi from Martian is to
cope with such an address.  It is in this case that the format of the bits
becomes important.

> > Furthermore, we are not talking about the language used by any support
> > messages to/from me.  We are talking about whether someone in Lower
> > Slobbovia can enter the developer's email address, and whether the
> > developer can enter the Lower Slobbovian address.
> What's the point of their entering your email address if they can only
> write to you in Slobbovian?

Maybe he only knows Slobbovian, but the village schoolteacher may know
enough English to cobble together something that I can comprehend, and
decypher my response.

Like most other developers with an international audience, I've become
fairly skilled in determining the meaning from broken, ungrammatical
English, and in framing my response so that the village schoolteacher (who
dimly remembers learning English in grade school decades ago) can do
likewise.

Alternatively, I may know of a Slobbovian restaurant downtown where I can
either have his letter, or my response, translated.  Or perhaps find a
Slobbovian student.  Or there may even be a Department of Slobbovian
Studies at the nearby university.

This sort of thing is quite common.  It is fallacious to assume that two
people do not communicate just because neither speaks the other's
language.  This is not a major barrier.

An incautious implementation of IEA, on the other hand, would be a major
barrier.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From: [email-masked]
To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) 
Date: Tue, 28 Oct 2003 15:07:19 -0500
Sender: [email-masked]

--==_Exmh_-1503687178P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said:

> email addresses. Mr. Tanaka can have one with Latin letters and one wit=
h
> Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF=
=E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5=
).

This gets interesting in the context of a "reply all".

Apologies for breaking the UTF-8 in the quote, but it's illustrative - if=
 the
breakage had been in the To/Cc lines, things would have broken even worse=

unless whatever scheme we end up using is ASCII-transparent.

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

--==_Exmh_-1503687178P--

Date: Tue, 28 Oct 2003 12:36:07 -0500
From: John C Klensin <[email-masked]>
To: Marc Blanchet <[email-masked]>, Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

--On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet
<[email-masked]> wrote:

> it appears to me that this thread is not very different from
> the idn considerations on usage of idn in the world. So what
> is really new in this discussion?

See the draft.

Quick answer: DNS interfaces really exist at the protocol level,
and a large part of the hypothesis behind IDNA was that it would
be possible, after we had enough implementations, to prevent an
end-user from ever seeing an encoded domain name.  That story
just doesn't hold for a special encoding-based (aka MUA-only)
email local part implementation, and maybe not for email
generally.  For example, under current rules, an MTA is required
to stuff the name it actually sees in HELO/EHLO and the MAIL
command into various headers.  If it is expected to notice that
they have special encodings and decodes them, we've gone rather
far into "the infrastructure is involved", even if the actual
on-the-wire transport is not impacted.  If it doesn't do that,
the encodings --both the IDNA domain parts and the special mail
encoding-- are going to be in the user's face, in the most
literal sense of that term.  

The similarity of that situation to the early IDN discussions is
the importance of the "what problem are you solving" question.
And it is very clear to me that, for email addresses, the answer
has got to "user sees their own characters in their email
addresses and the email addresses of those whose languages they
speak/ recognize.  Users typically don't actually see envelopes.
But seeing, e.g., different forms/codings of an address in the
header "From:" field than appears in "Return-path:" or than
appears in a signature line in the message body, is going to
create real unhappiness.  Similarly as has been pointed out in
another context, seeing an address in different from when it
appears in a header than when it (and that header) are
encapsulated in a message/?? body part is just not going to
amuse any user to whom we've said "ok, now you have i18n
strings, enjoy your new found local language capabilities".  And
I guess that tells you what I think the problem is that we need
to solve.  YMMD.

     john

Date: Tue, 28 Oct 2003 16:30:02 -0500
From: John Cowan <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Mark Crispin scripsit:

> Well, then, how many are there, and is there a list?  This will allow us
> to eliminate all the non-live scripts from future consideration.

There are a little more than 50 scripts in current use.
http://www.evertype.com/standards/iso15924/document/dis15924.pdf gives
a list, and http://www.unicode.org/Public/4.0-Update/Scripts-4.0.0.txt
can be massaged into a list of scripts currently in Unicode with

	awk '$4 = "#" {print $3}' | sort -u

> Those of us who develop system tools build software that is used
> everywhere in the world.  Because system tools are not a user interface,
> they are not restricted to the set of languages or scripts which are
> understood by the author.

True.  But if they write you for support, they have to use a language you
understand; people who can only handle Hindi can't get support from you
and don't need to be able to type your email address (assuming wlg that
you have no Hindi).  This is quite independent of the product type; it
applies just as much to buggy whips as to system software.

> Furthermore, we are not talking about the language used by any support
> messages to/from me.  We are talking about whether someone in Lower
> Slobbovia can enter the developer's email address, and whether the
> developer can enter the Lower Slobbovian address.

What's the point of their entering your email address if they can only
write to you in Slobbovian?

-- 
Eric Raymond is the Margaret Mead               John Cowan
of the Open Source movement.                    [email-masked]
        --Lloyd A. Conway,                      http://www.ccil.org/~cowan
          amazon.com review                     http://www.reutershealth.com

Date: Tue, 28 Oct 2003 13:28:43 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Markus Stumpf <[email-masked]>
cc: John Cowan <[email-masked]>, Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, Markus Stumpf wrote:
> How does
>[snip]
> look to you? (This is not an example crafted to be a pain.)

Thanks for a great example!!

It appears to me as:
 "g" <center-dot> "ther.gr" <center-dot> "l@h" <center-dot> "nerbr"
 <Han character for "moor" (as in a boat)> ".de".

Now, if I set my environment so that I'm interpreting things in Latin-1,
then I see the German string which is Anglicized as:
 [email-masked]

Of course, if my environment had been UTF-8 instead of Japanese, it
would have been rendered correctly without change.  But, I still would
have had to change my Japanese input environment to enter that string.  I
would have had to know how to enter umlauts and ess-tset.

If I was a native Japanese, I would have learned the Latin alphabet
without any diacriticals.  I would know how to write my name in the Latin
alphabet, albeit with numerous spelling variances; "Fujishima",
"Huzisima", "Fujisima", "Fuzishima", etc. are all the same name.  Umlauts
(and especially ess-tset) are a different matter.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 28 Oct 2003 21:38:48 +0100
From: Markus Stumpf <[email-masked]>
To: John Cowan <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, Oct 28, 2003 at 02:13:35PM -0500, John Cowan wrote:
> For myself, I support people in English, and I need to be able to
> recognize support requests in French and Spanish so that I can route them
> to the right places.  A single Latin-script email address is sufficient
> for this.  Adding a Cyrillic-script email address would be as silly
> as adding Russian contact information to my business card: I can't do
> anything for people who want to communicate with me in Russian anyway.

I have friends all over the word. My name doesn't have any German
umlauts but a lot of do.
How does
    g�nther.gr��l@h�bnerbr�u.de
look to you? (This is not an example crafted to be a pain.)
Does your mailclient render this correctly with all the umlauts?
Will a Chinese do? Or a Russian? Or ...?
Aren't we not all on the same mailinglists? We all can talk to each
other using English as the (current) lingua franca on the Internet.
And we can all type our email addresses as every keyboard I know of
is able to produce ASCII characters. Does yours have a mapping for
iso-8859-1 (probably as you have to use French). Does it have a Greek
mapping (iso-8859-7)? Wouldn't it be a pain if you couldn't send email
to the hotel in Athens we're you want to go to the Olymic Games, only
because they have an email address in iso-8859-7 only and you don;t have
the characters on your keyboard? ;-)

If I have latin-1 addresses on my business card and go to some international
fair, do I also need a business card with a ASCII coded address on it?
Do I need a bag only for all the different business cards with my email
address in different codings??
And if I need a ASCII coded address anyway, to avaoid the bag, why would
I want to have another one that cannot be used by probably 98% of the
people on this planet at all?

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA) 
From: [email-masked]
Date: Tue, 28 Oct 2003 15:07:19 -0500
Sender: [email-masked]

--==_Exmh_-1503687178P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 27 Oct 2003 17:39:32 PST, Mark Davis said:

> email addresses. Mr. Tanaka can have one with Latin letters and one wit=
h
> Japanese (e.g. =E3=83=A0=E3=83=AB=E3=82=AF@=E3=82=AB=E3=82=AF.=E3=83=AF=
=E3=82=B7=E3=83=B3=E3=82=B0=E3=83=88=E3=83=B3.=E3=82=A8=E3=83=87=E3=82=A5=
).

This gets interesting in the context of a "reply all".

Apologies for breaking the UTF-8 in the quote, but it's illustrative - if=
 the
breakage had been in the To/Cc lines, things would have broken even worse=

unless whatever scheme we end up using is ASCII-transparent.

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

--==_Exmh_-1503687178P--

Date: Tue, 28 Oct 2003 11:37:19 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: John Cowan <[email-masked]>
cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, John Cowan wrote:
> First of all, there aren't hundreds of scripts in live use.

Well, then, how many are there, and is there a list?  This will allow us
to eliminate all the non-live scripts from future consideration.

> Second,
> you probably support people in at most five languages, using at most
> two or three scripts, unless you are a prodigy.

I think that you have misunderstood the problem.  You seem to be thinking
about the needs of a user interface developer, who only supports people
who use the languages that are supported by that user interface.

Those of us who develop system tools build software that is used
everywhere in the world.  Because system tools are not a user interface,
they are not restricted to the set of languages or scripts which are
understood by the author.

Furthermore, we are not talking about the language used by any support
messages to/from me.  We are talking about whether someone in Lower
Slobbovia can enter the developer's email address, and whether the
developer can enter the Lower Slobbovian address.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 28 Oct 2003 14:18:36 -0500
From: Keith Moore <[email-masked]>
To: Markus Stumpf <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Sender: [email-masked]

> > To me, it makes little sense for the secretary to get DSNs and MDNs but
> > for the boss to get vacation notices.  If the boss really wants to see
> > all of those responses, he can tell his secretary to configure the
> > secretary's MUA to use the boss's address in MAIL FROM.
> 
> I always try to use real life analogies.
> The boss wants to send a letter. He tells the secretary to handle it.
> The secretary puts the name of the boss on the paper and puts it in
> a company envelope. If it's a return to sender the company gets it
> and they look at the content and everything goes it's way. But the
> other is more interesting now. The recipient is on vacation. His
> secretary will open the letter, look at the content and she will write
> back a latter to the "sender boss" telling that her boss in on vacation.
> She will not address it to the senders' secreatry nor the senders
> company. Right? ;-) 

Yes, but the secretary's response is not an automatic one.  furthermore,
the secretary writing the response will understand enough about the
content of the letter to know whether it's appropriate to respond, and
to form a response that's appropriate for the message.

> > Besides I think you missed the point of the argument in section 4.
> > It's not that From/Reply-to are likely to contain incorrect information,
> > it's that they exist for very different purposes than to specify the
> > destination of automatic responses.
> 
> No I didn't really. It was more the
> 
> *> The Return-Path address is really the only one from the message header
> *> that can be expected, as a matter of protocol, to be suitable for
> *> automatic responses that were not anticipated by the sender.
> 
> at which I looked with my antispam hat on. But then, with spam, what is
> realiable.

if it can tell that the message is spam (or is not a valid message for
that kind of responder), the responder should not respond at all.

> > >    If it's not too late I'd definitely would vote for a third keyword
> > >    in "5.1 Syntax" and have "antivirus-generated" added. This would be
> > >    a huge benefit if antivirus vendors would add that (and probably in
> > >    the comment area the name of the virus).
> > 
> > This doesn't really seem consistent with the purpose of auto-submitted.
> 
> Hmmmm ... I don't understand what the inconsistency is.

auto-submitted doesn't want to be come a general-purpose message labelling
mechanism.  arguably we have too many of those already.  we could use
content-disposition or content-type or content-description....
 
> > > - Another member of IRTF ASRG BCP mentioned:
> > >    > I'm a little concerned about the top of section 2 
> > >    > "An automatic responder MUST NOT send a response for every
> > >    > message ..." while this is in a sense the whole thrust of the
> > >    > draft, I'd imagine that it sits badly with some applications -
> > >    > like forms of RPC over SMTP. Perhaps this is one to ask someone
> > >    > who knows SOAP etc?
> > >   So maybe a wording like
> > >    "An automatic responder MUST NOT _blindly_ send a response for
> > >    every message received."
> > >   can make that statement more clearer.
> > 
> > I understand your concern, but I guess I don't think your suggested text
> > is any clearer.
> 
> I didn't say it is perfect and it is surely easier for a native english
> speaker to phrase it than for me, we only wanted to clarify out concerns
> a bit.

Maybe, maybe not :)  If I think of some better way to say it before the final
draft, I'll quite willingly change it.

Keith

Date: Tue, 28 Oct 2003 14:13:35 -0500
From: John Cowan <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Mark Crispin scripsit:

> > That's like asking how many languages should appear on your business card.
> > As many as the different kinds of people with whom you habitually interact.
> 
> That is not a satisfactory answer to the question.
> 
> I am engaged in software support.  I habitually interact with people from
> around the planet.  Any proposal, that states that someone like me must
> maintain hundreds (if not thousands) of email addresses, is a non-starter.

First of all, there aren't hundreds of scripts in live use.  Second,
you probably support people in at most five languages, using at most
two or three scripts, unless you are a prodigy.  (You may have more
nationalized versions of some products than that, but you probably
can't handle more than that many languages *in email*.)  An address
like "[email-masked]" might need a hundred variants, but you
certainly won't.

For myself, I support people in English, and I need to be able to
recognize support requests in French and Spanish so that I can route them
to the right places.  A single Latin-script email address is sufficient
for this.  Adding a Cyrillic-script email address would be as silly
as adding Russian contact information to my business card: I can't do
anything for people who want to communicate with me in Russian anyway.

> > No address is quite domestic-only, though it may be a meaningless jumble
> > to people who are interacting with the ASCII representation.
> 
> Again, that assumes a requirement that (as far as I can tell) has not been
> made.

Well, it's certainly what John's draft prescribes.  As for the fullwidth @,
the only significance of that is that it's folded into an ASCII @ before
doing anything else, so that people who type a fullwidth @ instead of an
ASCII one are not inconvenienced too much.

> If that truly is the requirement, we can have a very short meeting; just
> sufficient to say "just use UTF-7" (or any other politically correct
> rendering of the day), get the hum, and go home.

That doesn't address appropriate folding, nor does it avoid stepping on
email addresses that are likely to be already in use.

-- 
I suggest you call for help,                    John Cowan
or learn the difficult art of mud-breathing.    [email-masked]
        --Great-Souled Sam                      http://www.ccil.org/~cowan

Date: Tue, 28 Oct 2003 20:10:44 +0100
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, Oct 28, 2003 at 10:18:54AM -0800, [email-masked] wrote:
> And the direction of late from the IESG for such documents is clear: They
> belong on the proposed-draft-full track, not BCP. 

This was my fault. I shouldn't have used the keyword "BCP" here, as it
is afflicted with a special meaning. Using "guideline" or "howto" would
have probably suited better.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Date: Tue, 28 Oct 2003 20:04:29 +0100
From: Markus Stumpf <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Markus Stumpf <[email-masked]>, [email-masked]
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, Oct 28, 2003 at 12:44:08PM -0500, Keith Moore wrote:
> >   Resent-From isn't handled at all. But it is important IMHO for
> >   vacation programs not to answer to the From but Resent-From if
> >   present.
> [ ... ] 
> Indeed, about the only time I personally use resent is to forward a
> message to a responder - either because the original message was
> misdirected or because I want to respond with a form letter.  Having the
> responder respond to Resent-From would make resent entirely useless,
> IMHO.

Ok, I just noticed that I probably abuse "bounce" for some years now ;-))
Each time I see an interesting document, announcement, etc. that I think
one of my colleagues or friends would find interesting, too, I bounce
it, if I think no additional comment is needed and I forward it if I
want to add comments.
A vacation type responder then answering to the From: surely will puzzle
the original sender. That's why I thought it would be more appropriate
to answer to Resent-From:

> Well, you're simply wrong about that :)

That was the risk involved ;-)

> To me, it makes little sense for the secretary to get DSNs and MDNs but
> for the boss to get vacation notices.  If the boss really wants to see
> all of those responses, he can tell his secretary to configure the
> secretary's MUA to use the boss's address in MAIL FROM.

I always try to use real life analogies.
The boss wants to send a letter. He tells the secretary to handle it.
The secretary puts the name of the boss on the paper and puts it in
a company envelope. If it's a return to sender the company gets it
and they look at the content and everything goes it's way. But the
other is more interesting now. The recipient is on vacation. His
secretary will open the letter, look at the content and she will write
back a latter to the "sender boss" telling that her boss in on vacation.
She will not address it to the senders' secreatry nor the senders
company. Right? ;-) Sending to MAIL FROM however would mean to send a
letter "Dear company, my boss is on vacation".

But as I agree with your statement a bit below I am convinced your
strategy is the way to go.

> Even though the draft only says SHOULD NOT, IMHO responses should
> *never* be sent to Sender.  Sender is essentially a trace field, like
> Received.

I totally agree.

> Look, we can either tell MUAs and responders to guess which address they
> should respond to (based on the phase of the moon, a random number
> derived from a camera on a crystal ball, or whatever) or we can specify 
> a _protocol_ (wow!) that lets the sender tell the recipient where to
> send certain kinds of mail.  We've chosen to do the latter: MAIL FROM/
> Return-path for bounces and automatic responses, From for the author(s),
>  Reply-To for wherever the author(s) think the likely response should
> go, and To/Cc if the responder wants to include the original recipients
> of the message (at least, those who were visible to the responder). And
> while it's true that this set of categories is occasionally
> insufficient, there is ample experience to indicate that lumping all of
> the sender/author addresses onto From is much, much worse.

Agreed.

> Besides I think you missed the point of the argument in section 4.
> It's not that From/Reply-to are likely to contain incorrect information,
> it's that they exist for very different purposes than to specify the
> destination of automatic responses.

No I didn't really. It was more the

*> The Return-Path address is really the only one from the message header
*> that can be expected, as a matter of protocol, to be suitable for
*> automatic responses that were not anticipated by the sender.

at which I looked with my antispam hat on. But then, with spam, what is
realiable.

> IMHO good behaving responders should use <>.  Most responders don't
> need to process bounces.

Valid point of view.
For some incident areas we create responder messages that tell the
customer that his messages has arrived and the incident number it
has been assigned.
With the increase of spam we utilize  bounce-<incident_no>@... and
if the notificiation bounces we mark the incident as "has a high
probability of being spam" and it is moved to a low prio queue.
But again you're correct: Most responders don't need to process bounces.

> >    If it's not too late I'd definitely would vote for a third keyword
> >    in "5.1 Syntax" and have "antivirus-generated" added. This would be
> >    a huge benefit if antivirus vendors would add that (and probably in
> >    the comment area the name of the virus).
> 
> This doesn't really seem consistent with the purpose of auto-submitted.

Hmmmm ... I don't understand what the inconsistency is.

*> Other types of automatic response in common use include:
*> [ ... ]
*> -    Various kinds of mail filters (including "virus scanners") which
*>      act on behalf of a recipient to alter the content of messages
*>      before forwarding them to that recipient, and issue responses in
*>      the event a message is altered.

and virus scanners are mentioned also under "Group Responders".
So you seem to think they are responders and they auto submit messages,
even to whole groups of addresses.

> > - Another member of IRTF ASRG BCP mentioned:
> >    > I'm a little concerned about the top of section 2 
> >    > "An automatic responder MUST NOT send a response for every
> >    > message ..." while this is in a sense the whole thrust of the
> >    > draft, I'd imagine that it sits badly with some applications -
> >    > like forms of RPC over SMTP. Perhaps this is one to ask someone
> >    > who knows SOAP etc?
> >   So maybe a wording like
> >    "An automatic responder MUST NOT _blindly_ send a response for
> >    every message received."
> >   can make that statement more clearer.
> 
> I understand your concern, but I guess I don't think your suggested text
> is any clearer.

I didn't say it is perfect and it is surely easier for a native english
speaker to phrase it than for me, we only wanted to clarify out concerns
a bit.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Date: Tue, 28 Oct 2003 11:00:48 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, IETF RFC-822 list <[email-masked]>, IMAA list <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, Arnt Gulbrandsen wrote:
> > Is ASCII formally abolished as the lingua franca of email addresses,
> > meaning that some people will be unable to use ASCII addresses?
> I think the latter will some day be the case. Personally I'm not unhappy
> about it - anyone who doesn't know my alphabet is unlikely to know any
> language I also know.

Such a prospect appalls me.

> > If not, doesn't that create a two tier world of persons who have
> > usable international addresses and those who have domestic-only
> > addresses?
> Yep. Just like some of us speak foreign languages and others don't.
> As long as the email addresses are fully sufficient for communication
> with everyone with whom the user shares a language, it's okay.

This mixes apples and oranges; that is, the ability to have an email
address in your native script with language ability.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 28 Oct 2003 10:51:16 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: John Cowan <[email-masked]>
cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, John Cowan wrote:
> All email addresses will continue to have an ASCII *representation*, which
> will not, for most people, have mnemonic value.

Is that a given as one of the requirements?  If so, that greatly
constrains the solution set.  I happen to think that that is a desirable
constraint; but I have certainly not heard any definite hum of concensus
that this shall be a requirement.

Talk about using alternate forms of "@" (and the like) doesn't sound like
a hum to me.

> > If so, how many email addresses will a diplomat (or any other individual
> > engaged in multinational business) need?
> That's like asking how many languages should appear on your business card.
> As many as the different kinds of people with whom you habitually interact.

That is not a satisfactory answer to the question.

I am engaged in software support.  I habitually interact with people from
around the planet.  Any proposal, that states that someone like me must
maintain hundreds (if not thousands) of email addresses, is a non-starter.

It is obvious (at least to me) that there is a constraint that prevents
such an outcome.  What is that constraint?

> No address is quite domestic-only, though it may be a meaningless jumble
> to people who are interacting with the ASCII representation.

Again, that assumes a requirement that (as far as I can tell) has not been
made.

If that truly is the requirement, we can have a very short meeting; just
sufficient to say "just use UTF-7" (or any other politically correct
rendering of the day), get the hum, and go home.

Something tells me that isn't going to happen.  :-)

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 28 Oct 2003 10:18:54 -0800 (PST)
From: [email-masked]
Subject: Re: comments: draft-moore-auto-email-response-04.txt
To: Keith Moore <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > - I can't see the main goal of this draft. Is it a BCP "how to write
> > >   a correct autoresponder" or is it mainly a proposal for a new
> > >   2822 header field to standardise autoresponder communication. Or
> > >   is it both (IMHO a good idea)
> >
> > Shall we say it started out as a BCP, which then grew small
> > prescriptive leanings in the form of the "auto" prefix and
> > auto-submitted?

> you could say that, but I don't think it would be accurate.  the
> document has always been about protocols, and it has always been
> intended to affect running code, even if it wasn't so much specifying
> data formats.

And the direction of late from the IESG for such documents is clear: They
belong on the proposed-draft-full track, not BCP. 

				Ned

Date: Tue, 28 Oct 2003 19:09:43 +0100
From: Markus Stumpf <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Markus Stumpf <[email-masked]>, IETF RFC-822 list <[email-masked]>
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, Oct 28, 2003 at 05:43:52PM +0100, Arnt Gulbrandsen wrote:
> >  IMHO a personal responder (vacation) should send the message to the 
> >From field.
> 
> Do that, and the document die as irate mailing-list posters complain 
> about having received vacation messages whenever they post to a list.

As outlined in the draft vaction programs should never answer to posts
from a mailing list ;-)
So I don't see that point. Some mailservers (e.g. Lotus) even bounce to
the "From:" field if the bounce is really a double bounce.
My impression was the draft should put things right.

> Yep, but at least if things are vaguely close to correct, return-path 
> does no damage. Sending to reply-to means spewing vacation notices to a 
> lot of lists, for example. Hardly best current practice.

See above ;-)

> Do that, and watch the flames over what should/should not be included. 
> The same applies to x- fields.
> 
> Some people apparently think that mentioning the jungle of fields such as
> 
> >     mailing-list, x-mailing-list, x-listname, x-listmember, x-loop
> 
> in an RFC will only cause the jungle to grow worse. Mention only RFC 
> 2369, and people will move to RFC 2369 syntax. There is a point to 
> that.

So add a list that lists the pro's and con's of each field. Just because
there are controversal opinions is not a reason to drop the topic at all.

> That's nowhere close to BCP, and IMO far too controversial.
> I kind of wish djb weren't so polarizing.

We had about 5 customers the last 2 month which were sending out weekly
newsletters and complained about the burden of handling the bounces
each week. We talked to them about the principle of VERP and now
they use news+<nnnn>@example.com and a simple script flags the <nnnn>
user in the database and he never gets the newsletter again. They
haven't even thought about that kind of concept before.

I can't see what's controversial or polarizing. I only see as a
postmaster that I have nearly zero problems with lists using VERP
and I have tons of problems with lists using sender addresses like
[email-masked], especially large lists.

Don't mention DJB, don't call it VERP, but give the readers a hint and a
possible solution.

> >- As the most important and widely used responder is probably the
> >  "vacation" type it would be nice to have a section with a strict 
> >  ruleset how a vacation program is to be written (timeout sender 
> >  addresses at least n days, dont answer if ..., send repsonse to, 
> >  ...)
> 
> Achieve agreement on what the rules should be?

If there are rules there would be something a programmer of a vacation
type program could stick to. Now they all invent the wheel from scratch
and the result is all the broken vacation programs we have now.
And what are rules for a vacation program can also be applied to "my
address has changed" or "we have received your message and are working
on it "type of responders.
The draft will not change anything with regard to this without rules
and we'll see more and more broken stuff.

> Inappropriate, IMO. Too much of a special case, and besides, you don't 
> want to ignore a whole category just like that.

You mean something that makes 90% of all "responder" traffic at times
is an "inappropriate special case"? ;-)

If someone wants to ignore a whole category or not is IMHO the decision
of this person/company. But you deny them the opportunity at all.
I personally wouldn't like to ignore the whole category, but at times
I would like to ignore exactly
    Auto-Submitted: antivirus-generated; W32/Sobig-F

> Lobby Sophos to add "auto-generated" and tweak your incident system to 
> add a call only when you receive an auto-generated message with 
> previously unseen body text. That way, you deal with each virus once, 
> which sounds about right.

We don't get the messages from our own scanners. I have hooks in that
don't send notifies at all on e.g. W32/Sobig-F, W32/Klez-H,
W32/Fizzer-A, ...
But a lot of viri scanner seem to have a template mechanism where each
admin can configure his own warning messages. With current viri faking
sender addresses you get flooded with false warnings from other
scanners. At the prime time of Sobig-F we had more than 100 false
warnings to our [email-masked] within an hour.
I have tried to use filters for W32/Sobig-F warnings and gave up after
30 different warnings within one hour.

The same could however be achieved with
    Auto-Submitted: auto-generated; antivirus W32/Sobig-F
and maybe antivirus vendors will take it up in a way like that but then
we'd have 30 different semi-standarized comment fields ;-)

Anyway ... I don't want to look like a killjoy and all your comments
are perfectly valid. I only wanted to add a few thoughts and make
some of them a bit clearer.

> --Arnt (sitting maybe 15m from Markus)

*smile*
(Which I admittedly wouldn't have noticed without you mentioning it :)

Enjoy your meal!

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, IETF RFC-822 list <[email-masked]>, IMAA list <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
Date: Tue, 28 Oct 2003 18:55:58 +0100
Sender: [email-masked]

Mark Crispin writes:
> Just as a few off the cuff-examples:
>
> Is ASCII formally abolished as the lingua franca of email addresses, 
> meaning that some people will be unable to use ASCII addresses?

I think the latter will some day be the case. Personally I'm not unhappy 
about it - anyone who doesn't know my alphabet is unlikely to know any 
language I also know.

> If so, how many email addresses will a diplomat (or any other 
> individual engaged in multinational business) need?

1<=n<=m, where m is the number of alphabets that individual uses.

A Chinese diplomat in Saudi Arabia might have three - one for each of 
the alphabets in which he communicates. His Indian counterpart might 
take the position that his Saudi hosts had better know the Latin 
alphabet, and have just one email address. Matter of judgment. (I'm 
misquoting an Indian newspaper, btw. Badly so.)

> If not, doesn't that create a two tier world of persons who have 
> usable international addresses and those who have domestic-only 
> addresses?

Yep. Just like some of us speak foreign languages and others don't.

As long as the email addresses are fully sufficient for communication 
with everyone with whom the user shares a language, it's okay.

--Arnt

Date: Tue, 28 Oct 2003 12:44:08 -0500
From: Keith Moore <[email-masked]>
To: Markus Stumpf <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Sender: [email-masked]

> I'm missing something like a "clear structure" in that draft.
> When reading the draft I always had to maintain kinda groups in my
> brain and add each of the unnumberd list topics to a group or case
> study. Maybe it's just me, but it would be nice to have a somewhat
> clearer "clustering". Some information that belongs together is also
> splitted across several sections.

Different types of people organize things in their heads differently,
so what is unclear to one person may be clear to another.

This document is basically orgnaized as follows:

- when to send automatic responses
- format of responses
- where to send responses

for all kinds of responses.  An alternate organization would be 

- rules for personal responders
- rules for group responders
- rules for service responders

but this would lead to a lot of either duplication, or
cross-referencing.  The current structure seems cleaner to me.

> - I can't see the main goal of this draft. Is it a BCP "how to write
>   a correct autoresponder"

The former, except that BCP is not the best label.  It's intended as
a standards-track document.  Nothing in RFC 2026 requires that all
protocol standards be specified down to the last bit.

>   or is it mainly a proposal for a new
>   2822 header field to standardise autoresponder communication. Or is
>   it both (IMHO a good idea)

Right now it's both, though I can certainly entertain arguments that
auto-submitted should be in a separate document.

>   Some of the following topics depend on that goal.
> 
> - Section 5 (Auto-Submitted) should be Section 2, as in sections 2,3,4
>   it is referenced but not yet defined.

Either way can be confusing, depending on how you represent information
in your head.   I don't think it's worth changing the structure of the
document for this reason.  And I really see auto-submitted as being 
ancillary to this document.

> - I'd like to see a clearer structure. There are three responders
>   defined (good). If I want to write a responder X what are the
>   pitfalls. In which cases should I not send an answer. In which cases
>   am I allowed to send a response and where should I send it to?
>   Return-Path? From? Resent-From?

Right now I don't see a way to specify to any significant level of 
completeness when a responder should or should not send an answer.
Each responder is different.  Maybe section 2 should say that
explicitly.

As for where the response should be sent, this is clearly specified
in section 4.

>   Resent-From isn't handled at all. But it is important IMHO for
>   vacation programs not to answer to the From but Resent-From if
>   present.

As I see it, resent-* is kind of an oddball half-forward mechanism - 
it essentially says to the resent recipient "treat this as if it had
been sent to you directly".  To me, that means having responses go
to the same place as they would have gone had the original recipient
responded.  IF the resender had wanted responses to go somewhere else,
he would have forwarded the message.  

Indeed, about the only time I personally use resent is to forward a
message to a responder - either because the original message was
misdirected or because I want to respond with a form letter.  Having the
responder respond to Resent-From would make resent entirely useless,
IMHO.

OTOH, I can see that there might be exceptions to this for certain kinds
of responders.

Maybe I should add a discussion of resent-from in section 4, just
for the sake of completeness.

>   Also I disagree that responders should always send to the
>   Return-Path field if possible. Both (and Sender, Reply-To,
>   Resent-From also) serve different purposes. Szenario: a secretary
>   sends a message on behalf of her boss who is in the airplane. This
>   leads to (RFC2822 3.6.2. Originator fields)
>      Return-Path: secretary
>      Sender: secretary
>      From: boss
>   IMHO a personal responder (vacation) should send the message to the
>   From field.

Well, you're simply wrong about that :)

To me, it makes little sense for the secretary to get DSNs and MDNs but
for the boss to get vacation notices.  If the boss really wants to see
all of those responses, he can tell his secretary to configure the
secretary's MUA to use the boss's address in MAIL FROM.

There are probably cases where From or even Resent-From is a better
choice than Return-Path, but Return-Path is only a SHOULD.  Individual
responders are free to respond to From if there's a good reason to do
so.  

In some sense, the intent of this document is to encourage greater
uniformity among mail responders without trying to force them all into
the same mold.

Even though the draft only says SHOULD NOT, IMHO responses should
*never* be sent to Sender.  Sender is essentially a trace field, like
Received.

>   The arguments in (4) that From/Reply-To don't hold reliable
>   information also hold true for the Return-Path field, sometimes
>   even more, as I see a lot of hosts that are (speaking of the MTA)
>   misconfigured to the bones and use ENV senders like
>   "[email-masked]" but the address in the From field is set
>   by the user to a correct and working address.

The appropriate fix for such situations should be obvious.

Look, we can either tell MUAs and responders to guess which address they
should respond to (based on the phase of the moon, a random number
derived from a camera on a crystal ball, or whatever) or we can specify 
a _protocol_ (wow!) that lets the sender tell the recipient where to
send certain kinds of mail.  We've chosen to do the latter: MAIL FROM/
Return-path for bounces and automatic responses, From for the author(s),
 Reply-To for wherever the author(s) think the likely response should
go, and To/Cc if the responder wants to include the original recipients
of the message (at least, those who were visible to the responder). And
while it's true that this set of categories is occasionally
insufficient, there is ample experience to indicate that lumping all of
the sender/author addresses onto From is much, much worse.

Besides I think you missed the point of the argument in section 4.
It's not that From/Reply-to are likely to contain incorrect information,
it's that they exist for very different purposes than to specify the
destination of automatic responses.

> - Backward compatibility
>   Currently most responders (if they do) use blacklists based on
>   addresses. That is mentioned in the draft, but a list of
>   addresses/address fragments would help like (perl regex):
>    if ($address =~
>         m/^$|daemon|request|bounce|mailer|postm|owner|lists|majordo|\
>         -(return|error)/i) { dontanswer; }

I specifically want to avoid including a complete list of such
addresses. (a) it would take too long.  (b) even if I could make up a
complete list today, it wouldn't be complete a year from now.

>   Also current responders look (and set) the Precedence field.
>   Messages with a precedence of (bulk|list|junk)/i) should not be
>   answered. This is mentioned, but only for "list".

Precedence is just used as an example of a reason why a responder might
refuse to respond to a message.  Perhaps you missed this part?

                                  (Because Precedence is not a standard
     header field, and its use and interpretation vary widely in the
     wild, no particular responder behavior in the presence of
     Precedence is recommended by this specification.)

>   Also the draft mentions header List-* fields. There are a lot of
>   others that should probably listed liked:
>      mailing-list, x-mailing-list, x-listname, x-listmember, x-loop
>   Some are not standard (x-) but widely used. If any of this is
>   present reponders that are not special purpose for exactly that
>   should not answer to messages with those header fields.

Again, for the reasons listed above, I'm not going to try to make a
complete list of reasons why a responder might choose to not respond to
a message.
 
> - Subject lines
>   I think it is important that the original content of the Subject
>   line stays intact with a message from an responder and therefor a
>   MUST is inserted. Also the "portion" should be worded that it is
>   only allowed to truncate the subject line because of rfc2822
>   limitations (line length).

There are other reasons than that, e.g. to thwart buffer overflow
attacks.  But I agree that in general it's undesirable to truncate
Subject lines that aren't excessively long. If I end up revising this
document for other reasons, (or if IESG insists) I'll consider
explaining more about when it's  acceptable to truncate a Subject line. 

>  About the "Auto:" I don't
>   like the allowance for translation.

I should have said this translation was for display purposes only.  
I agree that mail processing software shouldn't translate this.

> - VERPs (Variable Envelope Return Paths)
>   http://cr.yp.to/proto/verp.txt
>   IMHO good behaving responders should use these and code the
>   destination address. 

IMHO good behaving responders should use <>.  Most responders don't
need to process bounces.

> - Section 5.2
>   Extension keywords [ ... ] other than "no" MAY assume that the
>   message was not manually submitted by a human.
>   "Auto-Submitted: no" means it is submitted by a human. If there is a
>   extension keyword (RFC released or experimental) that the responder
>   doesn't know about it IMHO *MUST* (not MAY) assume a not human
>   generated message and MUST NOT reply to it.
> 
> - As the most important and widely used responder is probably the
>   "vacation" type it would be nice to have a section with a strict
>   ruleset how a vacation program is to be written (timeout sender
>   addresses at least n days, dont answer if ..., send repsonse to,
>   ...)

I agree that this would be useful. I'll consider putting this in an
Appendix, but probably as an example rather than as a normative part
of the specification.

> - It would be nice to include a paragraph that requests anti virus
>   vendors to have their software stop sending out virus warnings
>   for viri faking sender addresses. They do analysis and they know
>   that the virus fakes the senders so they could stop sending out
>   false warnings to faked senders. Maybe it's more pressure for them
>   if a RFC requests it.

Seems like something that would be better suited for a separate RFC.
I doubt it would be controversial, and it would have more impact that
way than if it were embedded in a document about responders.

>    If it's not too late I'd definitely would vote for a third keyword
>    in "5.1 Syntax" and have "antivirus-generated" added. This would be
>    a huge benefit if antivirus vendors would add that (and probably in
>    the comment area the name of the virus).

This doesn't really seem consistent with the purpose of auto-submitted.

> - Another member of IRTF ASRG BCP mentioned:
>    > I'm a little concerned about the top of section 2 
>    > "An automatic responder MUST NOT send a response for every
>    > message ..." while this is in a sense the whole thrust of the
>    > draft, I'd imagine that it sits badly with some applications -
>    > like forms of RPC over SMTP. Perhaps this is one to ask someone
>    > who knows SOAP etc?
>   So maybe a wording like
>    "An automatic responder MUST NOT _blindly_ send a response for
>    every message received."
>   can make that statement more clearer.

I understand your concern, but I guess I don't think your suggested text
is any clearer.

Keith

Date: Tue, 28 Oct 2003 12:36:07 -0500
From: John C Klensin <[email-masked]>
To: Marc Blanchet <[email-masked]>, Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

--On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet
<[email-masked]> wrote:

> it appears to me that this thread is not very different from
> the idn considerations on usage of idn in the world. So what
> is really new in this discussion?

See the draft.

Quick answer: DNS interfaces really exist at the protocol level,
and a large part of the hypothesis behind IDNA was that it would
be possible, after we had enough implementations, to prevent an
end-user from ever seeing an encoded domain name.  That story
just doesn't hold for a special encoding-based (aka MUA-only)
email local part implementation, and maybe not for email
generally.  For example, under current rules, an MTA is required
to stuff the name it actually sees in HELO/EHLO and the MAIL
command into various headers.  If it is expected to notice that
they have special encodings and decodes them, we've gone rather
far into "the infrastructure is involved", even if the actual
on-the-wire transport is not impacted.  If it doesn't do that,
the encodings --both the IDNA domain parts and the special mail
encoding-- are going to be in the user's face, in the most
literal sense of that term.  

The similarity of that situation to the early IDN discussions is
the importance of the "what problem are you solving" question.
And it is very clear to me that, for email addresses, the answer
has got to "user sees their own characters in their email
addresses and the email addresses of those whose languages they
speak/ recognize.  Users typically don't actually see envelopes.
But seeing, e.g., different forms/codings of an address in the
header "From:" field than appears in "Return-path:" or than
appears in a signature line in the message body, is going to
create real unhappiness.  Similarly as has been pointed out in
another context, seeing an address in different from when it
appears in a header than when it (and that header) are
encapsulated in a message/?? body part is just not going to
amuse any user to whom we've said "ok, now you have i18n
strings, enjoy your new found local language capabilities".  And
I guess that tells you what I think the problem is that we need
to solve.  YMMD.

     john

Date: Tue, 28 Oct 2003 11:58:49 -0500
From: John Cowan <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Mark Davis <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Mark Crispin scripsit:

> Is ASCII formally abolished as the lingua franca of email addresses,
> meaning that some people will be unable to use ASCII addresses?

All email addresses will continue to have an ASCII *representation*, which
will not, for most people, have mnemonic value.  It may therefore be useful
to have two email addresses, one which can be decoded into a non-ASCII
representation and is good for fellow-countrymen, and another which cannot
be decoded, but has mnemonic value for those who use the Latin script.

> If so, how many email addresses will a diplomat (or any other individual
> engaged in multinational business) need?

That's like asking how many languages should appear on your business card.
As many as the different kinds of people with whom you habitually interact.

> If not, doesn't that create a two tier world of persons who have usable
> international addresses and those who have domestic-only addresses?  It is
> not difficult to envision that in many countries, an ASCII address would
> be a privilege available only to select individuals (much as a phone line
> with international dialing).

No address is quite domestic-only, though it may be a meaningless jumble
to people who are interacting with the ASCII representation.  Still,
a good friend of mine has the already very annoying email address of
<Onederful111s@[censored].net>, yes lower-case ell followed by three
digit ones.  Go figure.

> Many decades ago, one of my professors told me something that I have
> always kept in mind since: "you have to learn to walk before you learn to
> run."

Actually, running before walking is quite possible in child development.  :-)

-- 
I marvel at the creature: so secret and         John Cowan
so sly as he is, to come sporting in the pool   [email-masked]
before our very window.  Does he think that     http://www.reutershealth.com
Men sleep without watch all night?  --Faramir   http://www.ccil.org/~cowan

Date: Tue, 28 Oct 2003 11:50:56 -0500
From: Keith Moore <[email-masked]>
To: Marc Blanchet <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> it appears to me that this thread is not very different from the idn
> considerations on usage of idn in the world. So what is really new in this
> discussion?

many of the considerations are the same.  however, because email addresses
are used differently than domain names, the relative importance of the 
considerations may be different.

Date: Tue, 28 Oct 2003 11:48:27 -0500
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Sender: [email-masked]

> > - I can't see the main goal of this draft. Is it a BCP "how to write
> >   a correct autoresponder" or is it mainly a proposal for a new
> >   2822 header field to standardise autoresponder communication. Or
> >   is it both (IMHO a good idea)
> 
> Shall we say it started out as a BCP, which then grew small
> prescriptive leanings in the form of the "auto" prefix and
> auto-submitted?

you could say that, but I don't think it would be accurate.  the
document has always been about protocols, and it has always been
intended to affect running code, even if it wasn't so much specifying
data formats.  

Date: Tue, 28 Oct 2003 11:40:07 -0500
From: John Wagner <[email-masked]>
Organization: Princeton University - OIT Web Services
To: [email-masked]
CC: [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Mark Davis wrote:
> 
> An international email address would be portable as far a computers are
> concerned; the issue would be for people: how to view it and how to key it in
> (as you note). In both cases, that depends more on the client software than the
> protocols.
> 
> I wouldn't be able to type in an email address in Tamil (though I could
> certainly copy and paste it). I would wager that anyone who cares to have his
> email used by foreigners would have dual email addresses, or perhaps even more;
> e.g. Tamil, Latin, and Chinese.

I seem to remember this coming up in another discussion and the immediately following point was how hard it is to do a cut and paste from a business card with the "native language" email address into a user interface that has no clue.

The problem is there is more than one human/machine interface for email addresses.  It is a technically simple thing to have multiple addresses, but it is not technically simple to be certain that the address I give you works when you try to communicate with me. 

-- 
John Wagner

From: Arnt Gulbrandsen <[email-masked]>
To: Markus Stumpf <[email-masked]>
Subject: Re: comments: draft-moore-auto-email-response-04.txt
Cc: IETF RFC-822 list <[email-masked]>
Date: Tue, 28 Oct 2003 17:43:52 +0100
Sender: [email-masked]

Markus Stumpf writes:
> - I can't see the main goal of this draft. Is it a BCP "how to write
>   a correct autoresponder" or is it mainly a proposal for a new
>   2822 header field to standardise autoresponder communication. Or is
>   it both (IMHO a good idea)

Shall we say it started out as a BCP, which then grew small prescriptive 
leanings in the form of the "auto" prefix and auto-submitted?

I'll comment most of the points since noone else has, then I'll go eat.

>   Some of the following topics depend on that goal.
>
> - Section 5 (Auto-Submitted) should be Section 2, as in sections 2,3,4
>   it is referenced but not yet defined.

Alternatively, one might say it's justified first, and then defined afterwards.

>   IMHO a personal responder (vacation) should send the message to the 
> From field.

Do that, and the document die as irate mailing-list posters complain 
about having received vacation messages whenever they post to a list.

The document may not be a pure BCP, but it has to stay close to best 
current practice if it is to have any moral authority.

>   The arguments in (4) that From/Reply-To don't hold reliable
>   information also hold true for the Return-Path field, sometimes
>   even more, as I see a lot of hosts that are (speaking of the MTA)
>   misconfigured to the bones and use ENV senders like
>   "[email-masked]" but the address in the From field is set
>   by the user to a correct and working address.

Yep, but at least if things are vaguely close to correct, return-path 
does no damage. Sending to reply-to means spewing vacation notices to a 
lot of lists, for example. Hardly best current practice.

> - Backward compatibility
>   Currently most responders (if they do) use blacklists based on 
>   addresses. That is mentioned in the draft, but a list of 
>   addresses/address fragments would help like (perl regex):
>    if ($address =~
>         m/^$|daemon|request|bounce|mailer|postm|owner|lists|majordo|\-(return|error)/i) 
>         { dontanswer; }

Do that, and watch the flames over what should/should not be included. 
The same applies to x- fields.

Some people apparently think that mentioning the jungle of fields such as

>      mailing-list, x-mailing-list, x-listname, x-listmember, x-loop

in an RFC will only cause the jungle to grow worse. Mention only RFC 
2369, and people will move to RFC 2369 syntax. There is a point to 
that.

> - VERPs (Variable Envelope Return Paths)
>   http://cr.yp.to/proto/verp.txt IMHO good behaving responders should 
>   use these and code the destination address. If they receive a 
>   bounce for that address they may put all messages in the responder 
>   queue for that destination on hold or stop acting on messages from 
>   that sender. So this should be recommended more explicitely.

That's nowhere close to BCP, and IMO far too controversial.

I kind of wish djb weren't so polarizing.

> - As the most important and widely used responder is probably the
>   "vacation" type it would be nice to have a section with a strict 
>   ruleset how a vacation program is to be written (timeout sender 
>   addresses at least n days, dont answer if ..., send repsonse to, 
>   ...)

Achieve agreement on what the rules should be?

>    If it's not too late I'd definitely would vote for a third keyword 
>    in "5.1 Syntax" and have "antivirus-generated" added. ...

Inappropriate, IMO. Too much of a special case, and besides, you don't 
want to ignore a whole category just like that.

Lobby Sophos to add "auto-generated" and tweak your incident system to 
add a call only when you receive an auto-generated message with 
previously unseen body text. That way, you deal with each virus once, 
which sounds about right.

> - Another member of IRTF ASRG BCP mentioned:
>    > I'm a little concerned about the top of section 2
>   So maybe a wording like
>    "An automatic responder MUST NOT _blindly_ send a response for 
>    every message received."
>   can make that statement more clearer.

Agreed.

--Arnt (sitting maybe 15m from Markus)

Date: Tue, 28 Oct 2003 08:35:09 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Mark Davis <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

On Tue, 28 Oct 2003, Mark Davis wrote:
> I would wager that anyone who cares to have his
> email used by foreigners would have dual email addresses, or perhaps even more;
> e.g. Tamil, Latin, and Chinese.

I wonder if the full implications of this statement are understood by
those who blithely advocate its position.  The Law of Unintended
Consequences severely punishes those who disregard it.

Just as a few off the cuff-examples:

Is ASCII formally abolished as the lingua franca of email addresses,
meaning that some people will be unable to use ASCII addresses?

If so, how many email addresses will a diplomat (or any other individual
engaged in multinational business) need?

If not, doesn't that create a two tier world of persons who have usable
international addresses and those who have domestic-only addresses?  It is
not difficult to envision that in many countries, an ASCII address would
be a privilege available only to select individuals (much as a phone line
with international dialing).

Authors of spam-blocking software (including me!) will be delighted.
Here will be yet another weapon in our arsenal.

I am not arguing any particular course of action.  I am tossing a few
paper airplanes at the clay feet of those who seem to disregard some
serious problems.  Those problems need to be addressed; but every time
these problems are mentioned, we keep hearing about the email needs of
illiterate villagers in the third world who will have high-speed Internet
before they have safe drinking water.

Nobody has disputed the desirability of enabling computer users to use
their native scripts to the maximum extent possible.  What we are
discussing is what is "possible", and how to make the "impossible" become
"possible".

Many decades ago, one of my professors told me something that I have
always kept in mind since: "you have to learn to walk before you learn to
run."

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 28 Oct 2003 11:33:28 -0500
From: John C Klensin <[email-masked]>
To: Keith Moore <[email-masked]>, Mark Davis <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Everyone,

Either for general efficiency or just to do me a favor, can we
please pick one list --I'd recommend IMAA unless Paul objects--
and move these discussions to it only.   I'd like to participate
(after all, it is my draft and BOF request that set off these
two threads), but am in an environment that is hostile to my
being to read email in a leisurely way -- the cross-postings are
making the volume look larger than it is, and I don't have time
to sift through and organize it.

Now, an observation or two.

Keith, please read draft-klensin-emailaddr-01.txt -- it contains
a fairly extensive treatment of the issue you identify below.
It also explicitly discusses the tradeoffs along the spectrum
from easy global interoperability (at both the prootocol and the
user interface/perception level) to full, culturally-appropriate
and optimized, localization.  Short answer is "can't have it
both ways", but that is a no-brainer.   I don't know that my
analysis is any better than yours, or where you would eventually
end up, but, if we can start from a common base and terminology
and then, as needed, argue about it, we will, I think, save a
lot of time.

It also explores the case beyond the one you and Mark are
discussing -- what happens if one decides to start tampering
with the "@" in mail or those nasty ASCII slashes, etc., in
URIs: if one is to go all the way to significantly non-Roman
scripts, those need to go too... or, at least, we need to
explore whether that is sensible and plausible.

There are two additional issues that I should have written about
in the draft and didn't.   

(1) Another advantage of "just" using UTF-8 in an appropriately
negotiated, controlled, and constrained environment is that any
idiosyncracies and coding difficulties are Unicode
idiosyncracies and coding difficulties.  If we decide to use a
specialized coding designed for email local-parts (and, fwiw, I
think Adam's coding solution is brilliant... I'm ultimately just
unhappy with the problem definition to which it responds), then
we have to deal with both its idiosyncracies _and_ those of
Unicode.  Strikes me as a bad idea -- better to just blame
"them" :-)

(2)  One might imagine using the machinery outlined in that
draft to transport mail across the network, and then, if needed,
use IMAA encoding to push the message into the mail store, make
it available for IMAP and POP, etc.  Not an ideal situation, but
that would clearly put that coding into the category of a
transition strategy that we could incrementally retire.  By
contrast, once we start moving tricky encodings across the
network as an alternative to a transport-based solution, every
realistic scenario I can think of says that we are stuck with
them forever.   That is, I think, more or less one of Mark's
arguments, but with a slightly different twist.

One final observation for now...

Our success record in not requiring email addresses to be typed
in, usually associated with some version of "The Directory", has
been abysmal.  Similarly, if users never had to look at URLs
(which was the intent) we would almost certainly not be having
these arguments about domain names and their formats -- the
"protocol element" argument would fly, and we'd all be working
on internationalization at a less constrained level of
abstraction.  But the pigs don't seem to be circling at
altitude, at least here in Carthage.

     john

--On Tuesday, October 28, 2003 10:27 -0500 Keith Moore
<[email-masked]> wrote:

>> It is currently impossible to use the Internet without
>> knowing the Latin script. However, the goal of most
>> well-designed client software and operating systems is to
>> permit the user to work entirely within their native
>> language, with a fully localized system. This is reaching to
>> India and other countries; Microsoft has introduced fully
>> localized versions of Indic Windows just recently, and Linux
>> vendors are hard at work to produce fully localized versions
>> of their software.
>> 
>> Email and Web addresses are the big remaining holdouts for
>> most people. People should not be forced to use a script that
>> they are unfamiliar with, just to use email addresses and
>> sites in their own countries. Even if they are familiar with
>> the Latin script, it is very often a very bad match for their
>> languages, making it very difficult to figure out how native
>> words would be spelled in it.
> 
> and yet, as we've seen time and time again, local use of
> nonportable addresses can cause major problems for the net as
> a whole.   we saw this in earlier days of email with the
> admixture of bitnet/rscs/nje, uucp, decnet, x.400, and Internet
> addresses.  we've seen it in the IP space with RFC 1918
> addresses.
> 
> in some ways internationalizing email addresses is a much
> harder problem than internationalizing IDNs, because no other
> application is as dependent on having human beings actually
> use addresses as email.  (yes, people do sometimes type in
> URLs, but not nearly as often as they click on links.  and
> there are apps which require humans to type in domain names,
> but for most of them this only happens  at configuration time.)
> 
> one way to approach this problem might be to make email less
> dependent on having addresses typed in.
> 
> Keith

 

Date: Tue, 28 Oct 2003 11:29:14 -0500
From: Keith Moore <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> An international email address would be portable as far a computers
> are concerned; the issue would be for people: how to view it and how
> to key it in(as you note). In both cases, that depends more on the
> client software than the protocols.

it depends on client software, keyboards, and the ability of the users
to use them.  but I suspect that the choice of protocol can change the
degree of dependence on these.

> I wouldn't be able to type in an email address in Tamil (though I
> could certainly copy and paste it). I would wager that anyone who
> cares to have his email used by foreigners would have dual email
> addresses, or perhaps even more; e.g. Tamil, Latin, and Chinese.

it's a bit more difficult than that - because email often involves more
than two parties.   and it's not as if you can expect those who speak only
(e.g.) Tamil to correspond exclusively with others in that same set.

Keith

From: "Mark Davis" <[email-masked]>
To: "Marc Blanchet" <[email-masked]>, "Mark Crispin" <[email-masked]>, "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 08:22:37 -0800
Sender: [email-masked]

I wouldn't have thought so either, but at least some people questioned the need
for non-Latin characters, and went so far as to exclude them from a proposed
problem statement:

> ... There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and non-Latin
> characters, in email addresses to better serve the needs of the
> multi-national Internet community...

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Marc Blanchet" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "Mark Crispin"
<[email-masked]>; "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tue, 2003 Oct 28 08:12
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

>
> it appears to me that this thread is not very different from the idn
> considerations on usage of idn in the world. So what is really new in this
> discussion?
>
> Marc.
>
> -- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis
> <[email-masked]> wrote/a ecrit:
>
> >> > (I agree that it's currently nearly impossible to use computers if one
> >> > isn't familiar with the Latin script, of course.)
> >>
> >> Which probably makes the rest of this discussion academic, unless we're
> >> going to undertake solving *that* problem for Microsoft and the various
> >> UNIX/Linux vendors...
> >
> > It is currently impossible to use the Internet without knowing the Latin
> > script. However, the goal of most well-designed client software and
> > operating systems is to permit the user to work entirely within their
> > native language, with a fully localized system. This is reaching to India
> > and other countries; Microsoft has introduced fully localized versions of
> > Indic Windows just recently, and Linux vendors are hard at work to
> > produce fully localized versions of their software.
> >
> > Email and Web addresses are the big remaining holdouts for most people.
> > People should not be forced to use a script that they are unfamiliar
> > with, just to use email addresses and sites in their own countries. Even
> > if they are familiar with the Latin script, it is very often a very bad
> > match for their languages, making it very difficult to figure out how
> > native words would be spelled in it.
> >
> > Mark
> >
>
>
>
> ------------------------------------------
> Marc Blanchet
> Hexago
> tel: +1-418-266-5533x225
> ------------------------------------------
> http://www.freenet6.net: IPv6 connectivity
> ------------------------------------------
>

Date: Tue, 28 Oct 2003 11:12:54 -0500
From: Marc Blanchet <[email-masked]>
To: Mark Davis <[email-masked]>, Mark Crispin <[email-masked]>, Abhijit Menon-Sen <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

it appears to me that this thread is not very different from the idn
considerations on usage of idn in the world. So what is really new in this
discussion?

Marc.

-- Tuesday, October 28, 2003 07:10:59 -0800 Mark Davis
<[email-masked]> wrote/a ecrit:

>> > (I agree that it's currently nearly impossible to use computers if one
>> > isn't familiar with the Latin script, of course.)
>> 
>> Which probably makes the rest of this discussion academic, unless we're
>> going to undertake solving *that* problem for Microsoft and the various
>> UNIX/Linux vendors...
> 
> It is currently impossible to use the Internet without knowing the Latin
> script. However, the goal of most well-designed client software and
> operating systems is to permit the user to work entirely within their
> native language, with a fully localized system. This is reaching to India
> and other countries; Microsoft has introduced fully localized versions of
> Indic Windows just recently, and Linux vendors are hard at work to
> produce fully localized versions of their software.
> 
> Email and Web addresses are the big remaining holdouts for most people.
> People should not be forced to use a script that they are unfamiliar
> with, just to use email addresses and sites in their own countries. Even
> if they are familiar with the Latin script, it is very often a very bad
> match for their languages, making it very difficult to figure out how
> native words would be spelled in it.
> 
> Mark
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

From: "Mark Davis" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 08:02:23 -0800
Sender: [email-masked]

An international email address would be portable as far a computers are
concerned; the issue would be for people: how to view it and how to key it in
(as you note). In both cases, that depends more on the client software than the
protocols.

I wouldn't be able to type in an email address in Tamil (though I could
certainly copy and paste it). I would wager that anyone who cares to have his
email used by foreigners would have dual email addresses, or perhaps even more;
e.g. Tamil, Latin, and Chinese.

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tue, 2003 Oct 28 07:27
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)

> > It is currently impossible to use the Internet without knowing the Latin
script.
> > However, the goal of most well-designed client software and operating
systems is
> > to permit the user to work entirely within their native language, with a
fully
> > localized system. This is reaching to India and other countries; Microsoft
has
> > introduced fully localized versions of Indic Windows just recently, and
Linux
> > vendors are hard at work to produce fully localized versions of their
software.
> >
> > Email and Web addresses are the big remaining holdouts for most people.
People
> > should not be forced to use a script that they are unfamiliar with, just to
use
> > email addresses and sites in their own countries. Even if they are familiar
with
> > the Latin script, it is very often a very bad match for their languages,
making
> > it very difficult to figure out how native words would be spelled in it.
>
> and yet, as we've seen time and time again, local use of nonportable addresses
> can cause major problems for the net as a whole.   we saw this in earlier days
> of email with the admixture of bitnet/rscs/nje, uucp, decnet, x.400, and
Internet
> addresses.  we've seen it in the IP space with RFC 1918 addresses.
>
> in some ways internationalizing email addresses is a much harder problem than
> internationalizing IDNs, because no other application is as dependent on
having
> human beings actually use addresses as email.  (yes, people do sometimes type
in
> URLs, but not nearly as often as they click on links.  and there are apps
which
> require humans to type in domain names, but for most of them this only happens
> at configuration time.)
>
> one way to approach this problem might be to make email less dependent on
having
> addresses typed in.
>
> Keith
>

Date: Tue, 28 Oct 2003 10:27:10 -0500
From: Keith Moore <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> It is currently impossible to use the Internet without knowing the Latin script.
> However, the goal of most well-designed client software and operating systems is
> to permit the user to work entirely within their native language, with a fully
> localized system. This is reaching to India and other countries; Microsoft has
> introduced fully localized versions of Indic Windows just recently, and Linux
> vendors are hard at work to produce fully localized versions of their software.
> 
> Email and Web addresses are the big remaining holdouts for most people. People
> should not be forced to use a script that they are unfamiliar with, just to use
> email addresses and sites in their own countries. Even if they are familiar with
> the Latin script, it is very often a very bad match for their languages, making
> it very difficult to figure out how native words would be spelled in it.

and yet, as we've seen time and time again, local use of nonportable addresses
can cause major problems for the net as a whole.   we saw this in earlier days
of email with the admixture of bitnet/rscs/nje, uucp, decnet, x.400, and Internet
addresses.  we've seen it in the IP space with RFC 1918 addresses.

in some ways internationalizing email addresses is a much harder problem than
internationalizing IDNs, because no other application is as dependent on having
human beings actually use addresses as email.  (yes, people do sometimes type in
URLs, but not nearly as often as they click on links.  and there are apps which
require humans to type in domain names, but for most of them this only happens 
at configuration time.)

one way to approach this problem might be to make email less dependent on having
addresses typed in.

Keith

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Abhijit Menon-Sen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 07:10:59 -0800
Sender: [email-masked]

> > (I agree that it's currently nearly impossible to use computers if one
> > isn't familiar with the Latin script, of course.)
>
> Which probably makes the rest of this discussion academic, unless we're
> going to undertake solving *that* problem for Microsoft and the various
> UNIX/Linux vendors...

It is currently impossible to use the Internet without knowing the Latin script.
However, the goal of most well-designed client software and operating systems is
to permit the user to work entirely within their native language, with a fully
localized system. This is reaching to India and other countries; Microsoft has
introduced fully localized versions of Indic Windows just recently, and Linux
vendors are hard at work to produce fully localized versions of their software.

Email and Web addresses are the big remaining holdouts for most people. People
should not be forced to use a script that they are unfamiliar with, just to use
email addresses and sites in their own countries. Even if they are familiar with
the Latin script, it is very often a very bad match for their languages, making
it very difficult to figure out how native words would be spelled in it.

Mark

To: [email-masked]
Xref: clerew local.mime:2691
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 12:35:15 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> Mark Crispin <[email-masked]> writes:

>Here's a start at such a statement:

>As presently constituted, email addresses are limited to the 26 Latin
>alphabetics, 10 digits, and a limited number of special characters in the
>ASCII character set.  There is a growing need to use additional
>characters, specifically Latin characters with diacriticals and non-Latin
>characters, in email addresses to better serve the needs of the
>multi-national Internet community.  However, the restrictions of ASCII
>email addresses have served as a "lingua franca" since everybody can enter
>ASCII email addresses, and there is an ongoing need for this as well.  The
>problem to be solved is the resolution of these two needs.

Is that talking about the local-part of the domain-part of an email
address, or both?

I thought IDNA (ugly as it is) was now a done thing as regards the
domain-part, so can we be clear that this is not a "let us have the IDNA
debate again" thing (or be clear that it is, if it is). OTOH, means of
ensuring the phasing out of any need for people to have to see or type in
raw punycode should definitely be on topic.

I see from later contributions to this thread that it is indeed mainly
about local-parts, but this needs to be made clear before the BOF get
under way.

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

To: [email-masked]
Xref: clerew local.mime:2692
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 12:35:57 GMT
Lines: 20
Sender: [email-masked]

In <[email-masked]> [email-masked] (WJCarpenter) writes:

>mc> As presently constituted, email addresses are limited to the 26
>mc> Latin alphabetics, 10 digits, and a limited number of special
>mc> characters in the ASCII character set.  There is a growing need to

>upper and lower case alphabetics

Please NO!

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

From: "Mark Davis" <[email-masked]>
To: "Stephane Bortzmeyer" <[email-masked]>
Cc: "Mark Crispin" <[email-masked]>, "Keith Moore" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 06:54:45 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0068_01C39D20.5EDF9090
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sigh. I used "Greek" in an analogy because I was hoping that some of the =
Latin-only folks out there would at least recognize the name of one =
other script. But how comforable would you really be, if =
=D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 =
=D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F =
=D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 =
=D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A =
=D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA =
=D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C =
=D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F =
=D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF =
=D9=90=D9=85=D9=8E=D9=90=D9=84 =
=D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C =
=D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA =
=D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF =
=D9=8F=D9=86=D9=84=D9=8A =
=D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A =
=D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90 =
=D8=B1=D9=8E=D9=90=D9=84 =
=D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 =
=D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?

Mark
__________________________________

=20
----- Original Message -----=20
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: "Mark Crispin" <[email-masked]>; "Keith Moore" =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>; "IMAP Extensions WG" <[email-masked]>; =
<[email-masked]>; <[email-masked]>; <[email-masked]>; =
<[email-masked]>
Sent: Tue, 2003 Oct 28 00:50
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses =
(IEA)

> On Mon, Oct 27, 2003 at 05:39:32PM -0800,
>  Mark Davis <[email-masked]> wrote=20
>  a message of 76 lines which said:
>=20
> > We should remember that for a great many people in the world, Latin =
letters are
> > quite unnatural; it'd be a bit like if we had to use Greek letters =
in all email
> > addresses.=20
>=20
> It would be a bit like if we had to use Greek letters in mathematics
> :-)
>=20
> 
------=_NextPart_000_0068_01C39D20.5EDF9090
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Times New Roman">Sigh. I used "Greek" in an analogy =
because I=20
was hoping that some of the Latin-only folks out there would at least=20
recognize&nbsp;the name of one&nbsp;other script. But how comforable =
would you=20
really be, if =D9=8A=D9=8F=D9=8F =D9=88=D9=90=D8=B1=D9=90 =
=D9=81=D9=8F=D8=B1=D8=B3=D9=90=D8=AF =D8=AA=D9=8F =
=D8=B1=D9=8E=D9=90=D8=AF =D9=8E=D9=86 =
=D9=90=D9=86=D8=AA=D9=90=D8=B1=D9=90=D9=84=D9=8A =
=D8=AF=D9=90=D9=81=D9=81=D9=90=D8=B1=D9=90=D9=86=D8=AA =
=D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA=D8=8C =
=D8=B3=D9=90=D9=85=D9=BE=D9=84=D9=8A =D8=AA=D9=8F=20
=D9=8F=D9=86=D8=AF=D9=90=D8=B1=D8=B3=D8=AA=D9=8E=D9=86=D8=AF =
=D9=90=D9=85=D9=8E=D9=90=D9=84 =
=D9=8E=D8=AF=D8=AF=D8=B1=D9=90=D8=B3=D8=B3=D9=90=D8=B3=D8=8C =
=D9=8E=D9=86=D8=AF =D9=8E =D8=B3=D9=83=D8=B1=D9=90=D9=BE=D8=AA =
=D8=AA=D9=87=D9=8E=D8=AA =D9=83=D9=8F=D9=8F=D9=84=D8=AF =
=D9=8F=D9=86=D9=84=D9=8A =
=D9=BE=D9=8E=D8=B1=D8=AA=D9=8E=D9=90=D9=84=D9=84=D9=8A =
=D8=B1=D9=90=D9=81=D9=84=D9=90=D9=83=D8=AA =D8=AA=D9=87=D9=90=20
=D8=B1=D9=8E=D9=90=D9=84 =
=D8=B3=D9=BE=D9=90=D9=84=D9=84=D9=90=D9=86=DA=AF =D9=8F=D9=81 =
=D9=8A=D9=8F=D9=8F=D8=B1 =D9=88=D9=8F=D8=B1=D8=AF=D8=B3?</FONT></DIV>
<DIV><BR><FONT=20
size=3D2>Mark<BR>__________________________________<BR><BR>&nbsp;</FONT><=
/DIV>
<DIV><FONT size=3D2>----- Original Message ----- </FONT>
<DIV><FONT size=3D2>From: "Stephane Bortzmeyer" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>To: "Mark Davis" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>Cc: "Mark Crispin" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; "Keith =
Moore"=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =

size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; "IMAP =
Extensions WG"=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT =
size=3D2>[email-masked]</FONT></A><FONT=20
size=3D2>&gt;; &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =

size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT size=3D2>Sent: Tue, 2003 Oct 28 00:50</FONT></DIV>
<DIV><FONT size=3D2>Subject: Re: [idn] Re: FYI: BOF on Internationalized =
Email=20
Addresses (IEA)</FONT></DIV></DIV>
<DIV><FONT size=3D2><BR></FONT></DIV><FONT size=3D2>&gt; On Mon, Oct 27, =
2003 at=20
05:39:32PM -0800,<BR>&gt; &nbsp;Mark Davis &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT=20
size=3D2>[email-masked]</FONT></A><FONT size=3D2>&gt; wrote =
<BR>&gt; &nbsp;a=20
message of 76 lines which said:<BR>&gt; <BR>&gt; &gt; We should remember =
that=20
for a great many people in the world, Latin letters are<BR>&gt; &gt; =
quite=20
unnatural; it'd be a bit like if we had to use Greek letters in all=20
email<BR>&gt; &gt; addresses. <BR>&gt; <BR>&gt; It would be a bit like =
if we had=20
to use Greek letters in mathematics<BR>&gt; :-)<BR>&gt; <BR>&gt;=20
</FONT></BODY></HTML>

------=_NextPart_000_0068_01C39D20.5EDF9090--

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark Davis'" <[email-masked]>, "'Mark Crispin'" <[email-masked]>, "'Keith Moore'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Tue, 28 Oct 2003 20:13:42 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> I'm curious: why do you think that everyone would be 
> satisfied with Latin characters only, and no non-Latin characters?
> 
> Mark
> __________________________________
> http://www.macchiato.com
> ► शिष्यादिच्छेत्पराजयम् ◄

Yes, I also agree. Especially in India, we have more than 10 Languages ( Hindi, Tamil, Telugu, Kannada, Malayalam, etc., )

Date: Tue, 28 Oct 2003 12:07:08 +0000
To: Pete Resnick <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
From: Roy Badami <[email-masked]>
Sender: [email-masked]

[Trimmed distribution]

 > Please review John Klensin's draft before making these kinds of assumptions.

Sorry, I realized that as soon as I had posted.  But, AIUI, John
Klensin's proposal also discusses whether domains should be allowed to
be represented in UTF-8 rather than punycode.  So it, too, does not
confine itself to considering only localpart issues.

 > >RB> Restricting the disucssion to local-parts runs the risk of excluding
 > >RB> other potentially relevent issues.
 > 
 > I agree. Limiting discussion at this point to local-part does not 
 > take into account some of the possibilities.

That was the only point I was trying to make.  The existing proposals
address broader issues that just the localpart.

	-roy

From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: [email-masked], [email-masked], IETF RFC-822 list <[email-masked]>, IMAA list <[email-masked]>, IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], Abhijit Menon-Sen <[email-masked]>, [email-masked], IETF/IDN WG <[email-masked]>
Date: Tue, 28 Oct 2003 11:15:17 +0100
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote:
>> (I agree that it's currently nearly impossible to use computers if 
>> one isn't familiar with the Latin script, of course.)
>
> Which probably makes the rest of this discussion academic, unless 
> we're going to undertake solving *that* problem for Microsoft and the 
> various UNIX/Linux vendors...

You're not appreciating the full complexity of the problem. ;)

Not only should the email standards permit MUAs and MTAs of the year 
2020 to solve the problem Abhijit mentions, but they should even permit 
such future programs to interoperate with latinate ones of the present 
and near future. And if it's too hard for latinate MUAs to implement 
the IEA standard, that won't happen.

--Arnt

Date: Tue, 28 Oct 2003 01:13:50 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Pete,

>>RB> Restricting the disucssion to local-parts runs the risk of excluding
>>RB> other potentially relevent issues.
PR> I agree. Limiting discussion at this point to local-part does not
PR> take into account some of the possibilities.

That was exactly the intent of the text.

We have already seen how nicely the text served to bring into pretty stark
relief one bit of expectation from one of the proposals. It is only fitting to
have it serve the same purpose for another one.

IETF BOF time is pretty lousy for an open-ended chat.  Having specifications
to chat about is only marginally better than not having them.

What makes the real difference is having serious focus to the meeting. If we
go into this meeting without even having a clear sense of the scope of the
problem to be tackled, then the chance of having a productive meeting is
pretty small.

At the moment, it appears that the focus of the meeting is likely to be:
Shall we break existing Internet mail or shall we lay an enhancement on top of
it that preserves the installed base.  (I'm sure that everyone else who was
present at the pre-MIME/ESMTP discussions is really looking forward to
repeating the experience.)

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

Date: Tue, 28 Oct 2003 08:55:19 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

Keith Moore <[email-masked]> wrote:

> > The current parsing rules allow only ASCII characters, so the rules
> > are going to have to change.
>
> uh, no. putting anything other than ASCII characters in email headers
> is completely unacceptable.

IMAA does *not* put anything other than ASCII characters in email
headers.

Did you stop reading my message right there?  What immediately followed
should have allayed your concern:

    But they can be changed without breaking things.  IMAA is based on
    the principle of not breaking things.  That's where requirement 2
    comes in:

         2) Whenever a mail address (or part of a mail address) is put
            into an IMA-unaware mail address slot (see section 2), it
            MUST contain only ASCII characters....

    The mail addresses in message headers are in IMA-unaware slots,
    and therefore they remain ASCII-only, using the exact same syntax
    they've always used.  IMAA deliberately makes no change to any
    existing protocol.

If internationalized mail addresses are going to be internationalized
in any sense, then they need to contain non-ASCII characters in some
circumstances.  Not in message headers, but at least in user interfaces.
Wherever non-ASCII addresses are used (not in messages headers), that's
where the new parsing rules will be needed.

Dave Crocker <[email-masked]> wrote:

> AMC>          2) Whenever a mail address (or part of a mail address)
> AMC>             is put into an IMA-unaware mail address slot (see
> AMC>             section 2), it MUST contain only ASCII characters.
> 
> You put a great deal of effort into designing features that work
> around the delivering MTA's not knowing that it is dealing with IMAA.
> Yet now you are requiring that knowledge.

IMAA does not expect MTAs to conform to IMAA, or even be aware of IMAA.

IMAA is designed so that software that conforms to IMAA and software
that does not conform to IMAA can interoperate.  Software that does not
conform to IMAA is assumed to see the world in pre-IMAA terms: mail
addresses are ASCII, as specified in all prior standards.

Every piece of mail-related software has the option to continue to abide
by the old rules only, or it can adopt IMAA and abide by its rules too.
There is no meta-requirement that any piece of software must adopt IMAA,
there is merely an incentive: if you don't adopt IMAA, you don't get to
have non-ASCII characters in mail addresses.  For MTAs, which don't come
into contact with regular users, that's not a great incentive.  Regular
users would be perfectly content in a world where MUAs adopt IMAA and
MTAs don't.

This high-level view is not presented in the IMAA draft, but it is
presented in the first two paragraphs of the IDNA spec (RFC 3490), which
the IMAA draft incorporates by reference:

    This document relies heavily on IDNA for both its concepts and
    its justification.  This document omits a great deal of the
    justification and design information that might otherwise be found
    here because it is identical to that in IDNA.  Anyone reading this
    document needs to have first read [IDNA], [PUNYCODE], [NAMEPREP],
    and [STRINGPREP].

Perhaps a future revision of the IMAA draft should copy more of this
material from IDNA.

> AMC>             Given an internationalized mail address, an
> AMC>             equivalent mail address satisfying this requirement
> AMC>             can be obtained by applying ToASCII to the local part
> AMC>             as specified in section 4, changing the at-sign to
> AMC>             U+0040, and processing the domain name as specified
> AMC>             in [IDNA].
> AMC> The mail addresses in message headers are in IMA-unaware slots,
> AMC> and therefore they remain ASCII-only, using the exact same syntax
> AMC> they've always used.  IMAA deliberately makes no change to any
> AMC> existing protocol.
> 
> It looks to me like you very much _do_ make a change.  The fact that
> you then hope some component will do an equivalence to regular at-sign
> does not alter this.

The message header protocol is not changed.  It has the exact same
syntax and semantics as it always did.

There are two mail address protocols: ASCII-only mail addresses as
defined by RFCs 821, 822, 2821, 2822; and internationalized mail
addresses as defined by IMAA.  The new address protocol may be used
only in new places (like new user interfaces and new protocols), while
the old address protocol must continue to be used in all the existing
places (like message headers and SMTP commands).  Any software that
deals with both address protocols acts as a gateway, and implements the
gateway functions specified by IMAA.  (I don't mean a mail gateway in
the RFC 1123 sense, just a protocol-to-protocol gateway in the general
sense.)

> AMC> Requirement 1 has an effect only in places where non-ASCII mail
> AMC> addresses are allowed, like user interfaces and new protocols.
>
> Requirements are not protocol specifications.

In this case they are.  Section 3.1 "Requirements" *is* the IMAA
protocol.  Sections 2 "Terminology" and 4 "Conversion operations" are
supporting sections that define the terms used in section 3.1.  In
particular, section 4 is just a detailed definition of the terms
"ToASCII" and "ToUnicode".

AMC

Date: Tue, 28 Oct 2003 09:50:23 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Mark Davis <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: NIC France
Sender: [email-masked]

On Mon, Oct 27, 2003 at 05:39:32PM -0800,
 Mark Davis <[email-masked]> wrote 
 a message of 76 lines which said:

> We should remember that for a great many people in the world, Latin letters are
> quite unnatural; it'd be a bit like if we had to use Greek letters in all email
> addresses. 

It would be a bit like if we had to use Greek letters in mathematics
:-)

Date: Tue, 28 Oct 2003 01:38:33 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: IETF RFC-822 list <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 10/28/03 at 2:26 AM -0500, Keith Moore wrote:

>putting anything other than ASCII characters in email headers is 
>completely unacceptable.

Let me try this one more time: Please read John Klensin's draft 
before making these kinds of statements. Either you and Dave have 
dismissed this draft without giving technical reasons for why you 
have, or you simply haven't read the draft. Please let's all get on 
the same page before arguing.

pr
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Tue, 28 Oct 2003 02:26:42 -0500
From: Keith Moore <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> The current parsing rules allow only ASCII characters, so the rules
> are going to have to change. 

uh, no. putting anything other than ASCII characters in email headers is
completely unacceptable.  

Date: Tue, 28 Oct 2003 01:20:58 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Roy Badami <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Sender: [email-masked]

On 10/27/03 at 6:42 PM -0800, Dave Crocker wrote:

>RB> Even though, given IDNA now exists as a proposed standard, the main
>RB> issues relate to the local part, the issue under discussion is that of
>RB> internationalized mail addresses, not just internationalized
>RB> local-parts.
>
>Really?  What work needs to be done, except for local part?  IDNA takes care
>of the right-hand side.

Please review John Klensin's draft before making these kinds of assumptions.

>RB> Restricting the disucssion to local-parts runs the risk of excluding
>RB> other potentially relevent issues.

I agree. Limiting discussion at this point to local-part does not 
take into account some of the possibilities.

pr
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Mon, 27 Oct 2003 23:08:57 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: "Adam M. Costello" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Adam,

>> AMC> The current IMAA draft requires that full-width "@" be recognized
>> AMC> as a separator between the local part and the domain part
>> In spite of reading the imaa spec a number of times, I entirely missed
>> that bit of subtlety.

AMC> It's the first requirement listed in section 3 "Requirements and
AMC> applicability".

Sorry for expecting to garner all the rules from the normative syntax and
algorithm section.  I'm not used to having to look into a Requirements
sections to understand basic parsing rules.

>> 2. As to the particulars of idea of allowing a second separator, let
>> me suggest that breaking existing Internet mail will not be conducive
>> to global adoption.  And altering the parsing rules for addresses is a
>> good way to break Internet mail.
AMC> The current parsing rules allow only ASCII characters, so the rules
AMC> are going to have to change.  But they can be changed without breaking
AMC> things.  IMAA is based on the principle of not breaking things.  That's
AMC> where requirement 2 comes in:
AMC>          2) Whenever a mail address (or part of a mail address) is
AMC>             put into an IMA-unaware mail address slot (see section
AMC>             2), it MUST contain only ASCII characters.

You put a great deal of effort into designing features that work around the
delivering MTA's not knowing that it is dealing with IMAA.  Yet now you are
requiring that knowledge.

AMC> Given an
AMC>             internationalized mail address, an equivalent mail address
AMC>             satisfying this requirement can be obtained by applying
AMC>             ToASCII to the local part as specified in section 4,
AMC>             changing the at-sign to U+0040, and processing the domain
AMC>             name as specified in [IDNA].
AMC> The mail addresses in message headers are in IMA-unaware slots, and
AMC> therefore they remain ASCII-only, using the exact same syntax they've
AMC> always used.  IMAA deliberately makes no change to any existing
AMC> protocol.

It looks to me like you very much _do_ make a change. The fact that you then
hope some component will do an equivalence to regular at-sign does not alter
this.

AMC> Requirement 1 has an effect only in places where non-ASCII mail
AMC> addresses are allowed, like user interfaces and new protocols.

Requirements are not protocol specifications.

>> Simplicitly facilitates adoption and interoperability. Multiple forms
>> for the same syntactic constructs do not make for simplicity.

AMC> True, but sometimes it makes sense for computers and computer
AMC> programmers to work harder in order to make things easier for the users.

If RFC2822 and RFC2821 were user interface specifications, I might agree with
you.

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

Date: Tue, 28 Oct 2003 06:47:06 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

Dave Crocker <[email-masked]> wrote:

> AMC> The current IMAA draft requires that full-width "@" be recognized
> AMC> as a separator between the local part and the domain part
>
> In spite of reading the imaa spec a number of times, I entirely missed
> that bit of subtlety.

It's the first requirement listed in section 3 "Requirements and
applicability".

    3. Requirements and applicability

    3.1 Requirements

        IMAA conformance means adherence to the following four
        requirements:

         1) In an internationalized mail address, the following
            characters MUST be recognized as at-signs for separating the
            local part from the domain name:  U+0040 (commercial at),
            U+FF20 (fullwidth commercial at).

> 2. As to the particulars of idea of allowing a second separator, let
> me suggest that breaking existing Internet mail will not be conducive
> to global adoption.  And altering the parsing rules for addresses is a
> good way to break Internet mail.

The current parsing rules allow only ASCII characters, so the rules
are going to have to change.  But they can be changed without breaking
things.  IMAA is based on the principle of not breaking things.  That's
where requirement 2 comes in:

         2) Whenever a mail address (or part of a mail address) is
            put into an IMA-unaware mail address slot (see section
            2), it MUST contain only ASCII characters.  Given an
            internationalized mail address, an equivalent mail address
            satisfying this requirement can be obtained by applying
            ToASCII to the local part as specified in section 4,
            changing the at-sign to U+0040, and processing the domain
            name as specified in [IDNA].

The mail addresses in message headers are in IMA-unaware slots, and
therefore they remain ASCII-only, using the exact same syntax they've
always used.  IMAA deliberately makes no change to any existing
protocol.

Requirement 1 has an effect only in places where non-ASCII mail
addresses are allowed, like user interfaces and new protocols.

> Simplicitly facilitates adoption and interoperability. Multiple forms
> for the same syntactic constructs do not make for simplicity.

True, but sometimes it makes sense for computers and computer
programmers to work harder in order to make things easier for the users.
In IDNA, it was decided that it would be too annoying for CJK users to
have to switch input modes back and forth for every dot in a CJK domain
name.  The same rationale applies to the at-sign in email addresses.

AMC

Date: Mon, 27 Oct 2003 22:08:45 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: "Adam M. Costello" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Adam,

>> RB> For instance, one of the issues that has been discussed on the
>> RB> IMAA list is whether full-width at should be recognized in an
>> RB> internationalized mail address.
>>
>> full-width _where_?
AMC> Roy was using the word "at" not as a preposition, but as the name of a
AMC> character.
AMC> The current IMAA draft requires that full-width "@" be recognized
AMC> as a separator between the local part and the domain part of an

Oh.

In spite of reading the imaa spec a number of times, I entirely missed that
bit of subtlety.

1. Herein lies a useful meta-lesson about the benefits of starting with the
narrowest scope possible: It helps uncover different expectations.

2. As to the particulars of idea of allowing a second separator, let me
suggest that breaking existing Internet mail will not be conducive to global
adoption. And altering the parsing rules for addresses is a good way to break
Internet mail.

This disparity also suggests a confusion between user presentation, versus
interchange format. It is occasionally noted that the problem with having data
be so "directly" readable by users is that people think they are looking at a
user presentation format. Alas, RFC2822 and RFC2821 are about
computer-to-computer interchange, not human presentation. (There is quite a
bit of human-to-human interchange, particularly in 2822, but that is different
from human presentation.)

For those with any interest in history, I'll note that we used to allow a
second separator (" at ") between local-part and domain, but simplified it 20
years ago, to keep the parsing simpler.

Simplicitly facilitates adoption and interoperability. Multiple forms for the
same syntactic constructs do not make for simplicity.

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

Date: Tue, 28 Oct 2003 00:50:42 -0500
From: Keith Moore <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> I've trimmed the To/Cc fields to the most relevant mailing lists.  After
> another couple days, we should probably trim it down to just ietf-imaa.

I suggest we keep it on both ietf-imaa and ietf-822.  I think the
discussion will be more balanced if we include "mainstream" email folks.

Date: Mon, 27 Oct 2003 20:42:19 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Abhijit Menon-Sen <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 28 Oct 2003, Abhijit Menon-Sen wrote:
> The number of people in India who can read and write only their native
> language, but have no usable knowledge of Latin script, is much larger
> than the tiny number who are familiar with both. I'm told that this is
> true for many native speakers of Chinese and Arabic as well.

I defer to your superior knowledge about India.

I do not believe that this is true for Chinese.  AFAIK, Chinese primary
school kids use Latin script with hanyu-pinyin as a stopgap prior to their
mastery of Han script (which takes many years).

> The use of local scripts is much more than just a "preference" for the
> numerous localisation efforts in India which focus on making computing
> more accessible to poor farmers and people in villages.

A poor farmer or villager in China is more likely to be totally illiterate
than to be literate in Han script but unable to recognize Latin script.

Note that when I say "recognize Latin script", I mean the ability to
determine that "dog" is a three-letter word that has the letters "d", "o",
and "g", each of which the individual recognizes and can name.  This does
not include the ability to recognize that this refers to a domesticated
canine.

> (I agree that it's currently nearly impossible to use computers if one
> isn't familiar with the Latin script, of course.)

Which probably makes the rest of this discussion academic, unless we're
going to undertake solving *that* problem for Microsoft and the various
UNIX/Linux vendors...

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 28 Oct 2003 09:52:43 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

At 2003-10-27 19:37:37 -0800, [email-masked] wrote:
>
> I do not believe many individuals (other than primary school children) are
> literate in their native language but are completely illiterate in Latin
> script.  This does not mean "being able to read or write the English
> language"; rather, this simply means knowing the Latin script alphabet.

Mark,

The number of people in India who can read and write only their native
language, but have no usable knowledge of Latin script, is much larger
than the tiny number who are familiar with both. I'm told that this is
true for many native speakers of Chinese and Arabic as well.

The use of local scripts is much more than just a "preference" for the
numerous localisation efforts in India which focus on making computing
more accessible to poor farmers and people in villages.

(I agree that it's currently nearly impossible to use computers if one
isn't familiar with the Latin script, of course.)

-- ams

Date: Tue, 28 Oct 2003 03:44:18 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

I've trimmed the To/Cc fields to the most relevant mailing lists.  After
another couple days, we should probably trim it down to just ietf-imaa.
That should be enough time for people interested in this thread to
subscribe to that list.

Dave Crocker <[email-masked]> wrote:

> RB> For instance, one of the issues that has been discussed on the
> RB> IMAA list is whether full-width at should be recognized in an
> RB> internationalized mail address.
>
> full-width _where_?

:)

Roy was using the word "at" not as a preposition, but as the name of a
character.

The current IMAA draft requires that full-width "@" be recognized
as a separator between the local part and the domain part of an
internationalized mail address, for consistency with the IDNA
requirement that fullwidth "." be recognized as a separator between
labels in an internationalized domain name.

IMAA takes the position that its scope is the entire mail address.  For
the domain part, it simply reuses IDNA (by reference).  That leaves the
local part and the at-sign where it has more to say.

AMC

Date: Mon, 27 Oct 2003 19:37:37 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Mark Davis <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 27 Oct 2003, Mark Davis wrote:
> Based on what I've seen, I think it quite likely that people will want email
> addresses in their native script, even if that means that outsiders can't
> (easily) use those email address.

That may well be the case.

> We should remember that for a great many people in the world, Latin
> letters are quite unnatural; it'd be a bit like if we had to use Greek
> letters in all email addresses. And there are many projects underway in
> less-developed countries to bring computers to masses of people that
> will even less familiarity with Latin letters.

I am not convinced that it is possible to use a computer on the Internet
anywhere in the world without at least a basic acquaintance with Latin
script.

I do not believe many individuals (other than primary school children) are
literate in their native language but are completely illiterate in Latin
script.  This does not mean "being able to read or write the English
language"; rather, this simply means knowing the Latin script alphabet.

Put another way, individuals who are completely illiterate in Latin script
are also likely to be illiterate in their native language script as well.

No other script on the planet has such international recognition.

There is undoubtably a *preference* for one's native script; and that
preference should be respected as much as possible.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 27 Oct 2003 18:42:26 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Roy Badami <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Roy,

 >> Mail Internationalised Local-Part (MILP)

RB> Even though, given IDNA now exists as a proposed standard, the main
RB> issues relate to the local part, the issue under discussion is that of
RB> internationalized mail addresses, not just internationalized
RB> local-parts.

Really?  What work needs to be done, except for local part?  IDNA takes care
of the right-hand side.

So what is there to do about "internationalized mail addresses" other than the
local part?

RB> Restricting the disucssion to local-parts runs the risk of excluding
RB> other potentially relevent issues.  For instance, one of the issues
RB> that has been discussed on the IMAA list is whether full-width at
RB> should be recognized in an internationalized mail address.

full-width _where_?  somewhere other than local part?

if yes, then how can that be practical?  if no, then the charter does not
preclude their use.  (if you think otherwise, please explain.)

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

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "IMAP Extensions WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Mon, 27 Oct 2003 17:39:32 -0800
Sender: [email-masked]

Ok, I understand more about the context.

Based on what I've seen, I think it quite likely that people will want email
addresses in their native script, even if that means that outsiders can't
(easily) use those email address. After all, it is quite easy to have multiple
email addresses. Mr. Tanaka can have one with Latin letters and one with
Japanese (e.g. [email-masked]).

We should remember that for a great many people in the world, Latin letters are
quite unnatural; it'd be a bit like if we had to use Greek letters in all email
addresses. And there are many projects underway in less-developed countries to
bring computers to masses of people that will even less familiarity with Latin
letters.

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Mark Crispin" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "IMAP Extensions WG" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Mon, 2003 Oct 27 17:15
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

> On Mon, 27 Oct 2003, Mark Davis wrote:
> > I'm curious: why do you think that everyone would be satisfied with Latin
> > characters only, and no non-Latin characters?
>
> I didn't say that.  I stated my belief that, for reasons of practicality,
> most individuals in regions which do not use Latin script accept the use
> of Latin script for multinational exchange.
>
> It does not work well for an individual in Japan with surname Tanaka to
> expect the overwhelming majority of non-Japanese individuals worldwide to
> know his surname is written with the Han characters for "rice paddy" and
> "middle", or what those characters look like, or how to enter those
> characters on the computer.
>
> It does, however, work for him to expect that the overwhelming majority of
> individuals worldwide to know how to deal with the 6 Latin letters that
> form the romanization "Tanaka".
>
> Nor is it very likely that this situation will change in the future.  I
> doubt that many individuals in the world are literate in all the world's
> active scripts.  Literacy in one's native script and basic Latin script is
> something that most computer users possess today.
>
> For domestic exchange only, that pair of Han characters are probably
> alright.  Within Western Europe, it's probably alright to use Latin
> characters with diacriticals.
>
> Perhaps the main problem that needs to be decided in any IEA effort is if
> it is alright to have email addresses that are only usable in limited
> areas of the world; or if not, how to represent internationalized email
> addresses in a usable fashion when (not if) the email address needs to be
> represented for a person and/or computer is illiterate in that script.
>
> A likely side issue is whether it is "good enough" to promote Latin
> characters with diacriticals to the same status of "everybody must know
> how to do these" that is required for ASCII.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

Date: Mon, 27 Oct 2003 17:15:00 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Mark Davis <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], IMAP Extensions WG <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 27 Oct 2003, Mark Davis wrote:
> I'm curious: why do you think that everyone would be satisfied with Latin
> characters only, and no non-Latin characters?

I didn't say that.  I stated my belief that, for reasons of practicality,
most individuals in regions which do not use Latin script accept the use
of Latin script for multinational exchange.

It does not work well for an individual in Japan with surname Tanaka to
expect the overwhelming majority of non-Japanese individuals worldwide to
know his surname is written with the Han characters for "rice paddy" and
"middle", or what those characters look like, or how to enter those
characters on the computer.

It does, however, work for him to expect that the overwhelming majority of
individuals worldwide to know how to deal with the 6 Latin letters that
form the romanization "Tanaka".

Nor is it very likely that this situation will change in the future.  I
doubt that many individuals in the world are literate in all the world's
active scripts.  Literacy in one's native script and basic Latin script is
something that most computer users possess today.

For domestic exchange only, that pair of Han characters are probably
alright.  Within Western Europe, it's probably alright to use Latin
characters with diacriticals.

Perhaps the main problem that needs to be decided in any IEA effort is if
it is alright to have email addresses that are only usable in limited
areas of the world; or if not, how to represent internationalized email
addresses in a usable fashion when (not if) the email address needs to be
represented for a person and/or computer is illiterate in that script.

A likely side issue is whether it is "good enough" to promote Latin
characters with diacriticals to the same status of "everybody must know
how to do these" that is required for ASCII.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 27 Oct 2003 20:08:25 -0500
From: Marc Blanchet <[email-masked]>
To: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

- good start!
- timeline seems pretty agressive... will see.
- would probably good to have a requirement document upfront. Might not the
same way that idn requirement ends up, but a narrow-implementable
requirement would help to have a concensus (hopefully) on what needs to be
done. 
- while the idn req went not that good, now that we have experience, I
think we should try to be better and have one.

I know I might start some debate with this, but still think it is the best
way to go...

- would be useful to have some reference to idn (idna) in the charter, as
background work. the developers and users will have to take care of "both"
(ie. idn and imail) in the email infrastructure.

Marc.

-- Monday, October 27, 2003 16:19:25 -0800 Dave Crocker <[email-masked]>
wrote/a ecrit:

> Folks,
> 
> On the theory that discussions go better when they have a concrete
> deliverable, here is a proposed charter for a proposed working group.
> 
> The following started with Mark Crispin's text, although it might not
> look it. Besides the usual goals for a charter, the following text
> attempts to specify the problem domain in the narrowest feasible form
> that is valid. If anyone thinks the scope is too narrow, they need to
> explain why.
> 
> 
> 
> DRAFT CHARTER
> 
> Mail Internationalised Local-Part (MILP)
> ---------------------------------
> 
> The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821
> mail addresses are restricted to a subset of ASCII. This poses a
> fundamental barrier for users needing mail addresses to be expressed in a
> richer set of characters, such as Latin characters with diacriticals and
> the many Asian characters. The goal of the current work is to add
> local-part support for these additional characters, while preserving the
> large, installed base of ASCII usage.
> 
> The group will take:
> 
>    draft-hoffman-imaa-03.txt
>    draft-klensin-emailaddr-i18n-01.txt
>    draft-duerst-iri-04.txt
> 
> as input to discussions.
> 
> The group will pay particular attention to barriers to adoption and
> utility, as well as any impact the new scheme might have on the existing
> base of Internet mail usage.
> 
> 
> Milestones
> ----------
> 
> Nov, 03:  BOF
> 
> Dec, 03:  WG chartered
> 
> Feb, 03:  Initial draft of working group specifications.
> 
> Jun, 03:  Specifications submitted for IETF approval
> 
> 
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
> 

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

Date: Tue, 28 Oct 2003 00:50:53 +0000
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
From: Roy Badami <[email-masked]>
Sender: [email-masked]

 > Mail Internationalised Local-Part (MILP)

Even though, given IDNA now exists as a proposed standard, the main
issues relate to the local part, the issue under discussion is that of
internationalized mail addresses, not just internationalized
local-parts.

Restricting the disucssion to local-parts runs the risk of excluding
other potentially relevent issues.  For instance, one of the issues
that has been discussed on the IMAA list is whether full-width at
should be recognized in an internationalized mail address.  IMHO, the
charter shouldn't be framed in a way that is sufficiently narrow as to
render such questions out of scope.

	-roy

Date: Mon, 27 Oct 2003 16:19:25 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Folks,

On the theory that discussions go better when they have a concrete
deliverable, here is a proposed charter for a proposed working group.

The following started with Mark Crispin's text, although it might not look it.
Besides the usual goals for a charter, the following text attempts to specify
the problem domain in the narrowest feasible form that is valid. If anyone
thinks the scope is too narrow, they need to explain why.

DRAFT CHARTER

Mail Internationalised Local-Part (MILP)
---------------------------------

The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821 mail
addresses are restricted to a subset of ASCII. This poses a fundamental
barrier for users needing mail addresses to be expressed in a richer set of
characters, such as Latin characters with diacriticals and the many Asian
characters. The goal of the current work is to add local-part support for
these additional characters, while preserving the large, installed base of
ASCII usage.

The group will take:

   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

as input to discussions.

The group will pay particular attention to barriers to adoption and utility,
as well as any impact the new scheme might have on the existing base of
Internet mail usage.

Milestones
----------

Nov, 03:  BOF

Dec, 03:  WG chartered

Feb, 03:  Initial draft of working group specifications.

Jun, 03:  Specifications submitted for IETF approval

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

Date: Mon, 27 Oct 2003 19:18:40 -0500
From: Keith Moore <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

[recipient list trimmed]

> I'm curious: why do you think that everyone would be satisfied with Latin
> characters only, and no non-Latin characters?

why do you think that everyone would be satisfied with ten digits on their
telephones?  or for that matter, ten fingers?

From: "Mark Davis" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Mon, 27 Oct 2003 16:16:20 -0800
Sender: [email-masked]

I'm curious: why do you think that everyone would be satisfied with Latin
characters only, and no non-Latin characters?

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Mark Crispin" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Mon, 2003 Oct 27 11:10
Subject: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)

> On Mon, 27 Oct 2003, Keith Moore wrote:
>
>  >> Thanks for taking a stab at a problem statement.  I'd like to drill down
>  >> on this just a bit.
>  >> What is the source of the "growing need"?  Is it:
>  >> [snip]
>
>
> I agree that this needs to be stated, but someone other than me will have
> to do it.
>
> I believe that the primary push for this functionality comes from regions
> which use Latin alphabetics with diacriticals; and that most individuals
> in regions which do not use Latin script are accept the use of Latin
> script for multinational interchange.  In many regions where Latin
> diacriticals are used, there is no acceptable transform of a surname to a
> form that does not use diacriticals.  Simply omitting the diacritical
> causes (at least to the inhabitants of those regions) a misspelling.
>
> This set of beliefs naturally biases how I approach the problem.  The
> problem statement must be free of bias, including mine.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>
>
>
>
>
>
>
>

Date: Mon, 27 Oct 2003 19:07:09 +0800
From: James Seng <[email-masked]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Pete Resnick <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: [idn] FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

I seen John and Paul proposal but I have not seen Michel. Is there a 
draft that I can read up?

ps: I wont be able to join the meeting but I am interested in the subject.

-James Seng

Patrik F�ltstr�m wrote:

> At the IETF in Minneapolis, there will be a BOF on Internationalized 
> Email Addresses (IEA).
> 
> It is *preliminary* on the agenda on Monday, November 10, 2003 at 
> 1530-1730.
> 
> Chairs:  Pete Resnick, Patrik F�ltstr�m
> Mailing list:[email-masked] (other salient lists include [email-masked])
> Agenda:
> 
> Agenda Bashing (Chairs)                5 min.
> Topic Introduction (Chairs)           10 min.
> Proposals
>   IDNA-Based (Paul Hoffman)           15 min.
>   Infrastructure-Based (John Klensin) 15 min.
>   IRI-Based (Michel Suignard)         15 min.
> 
> Discussion                            60 min.
> 
> Topics for discussion:
> 
>   Are there other solutions which have been specified?
> 
>   The solutions present the problem at different scopes;
> 
>      Where should the IETF tackle it?
> 
>      Are some short-term, and other long-term?
> 
>      Can the solutions be staged or co-exist?
> 
>      If staged, how to migrate from one to another?
> 
>   What are the next steps for the IETF?
> 
> 
> NB:  This BoF is exploratory in nature, and it is not intended that the 
> IETF will finalize a decision in this venue.  It was proposed to foster 
> a community discussion, not charter a working group or pick a winner. If 
> further work is required, step one would be identifying individuals 
> willing to carry that work forward.
> 
> Reading material:
>   draft-hoffman-imaa-03.txt
>   draft-klensin-emailaddr-i18n-01.txt
>   draft-duerst-iri-04.txt
> 
> Pete and myself hope people will come with a lot of constructive 
> comments and ideas.
> 
>         Patrik, co-chair of the bof
> 
> 
> 
> 
> 

Date: Mon, 27 Oct 2003 21:22:30 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

The extremely broad To/Cc list was appropriate for the initial
announcement of the BOF, but for this ensuing discussion I'm guessing it
would be good to trim it down, so I did.

Mark Crispin <[email-masked]> wrote:

> As presently constituted, email addresses are limited to the 26 Latin
> alphabetics, 10 digits, and a limited number of special characters in
> the ASCII character set.

Not so limited.  According to RFCs 821 & 822, all ASCII characters are
allowed.  According to RFCs 2821 & 2822, NUL is "obsolete", as are CR
and LF except as the pair CRLF.  (Obsolete means must be accepted and
must not be generated.)

Keith Moore <[email-masked]> wrote:

> What is the source of the "growing need"?  Is it:
>
> a. for users of many languages (particularly those not using Latin
>    alphabets) email addresses are difficult to remember
> b. for users of many languages (particularly those not using Latin
>    alphabets) email addresses are difficult to transcribe or type
> c. users want to use their names in email addresses
> d. users are confused by apparently arbitrary restrictions on use of
>    characters in email addresses, and this leads to mistakes
> e. on computer systems employing non-ASCII names for other purposes
>    (e.g. login or account names) these do not map well to ASCII email
>    addresses
>
> or something else that I don't see?

Regarding (a), there are at least two kinds of remembering: one is
recognition (is this address the same one I saw yesterday? is it a font
variation or a different character?); the other, more challenging, is
recall (mentally retrieve the address I saw yesterday).  Even harder
than remembering is reproducing (draw the characters or find them on a
keyboard) which is (b).

I've heard claims of all of those sources, except (d).  But I think (d)
will become true if internationalized mail addresses are not introduced.
I think users will be astonished that non-ASCII characters are allowed
after the at-sign but not before it.

I guess a problem statement should include both the motivation and the
challenge.  The challenge is the same as for internationalized domain
names:  Given a huge installed infrastructure of protocols, end-user
software, and intermediate software, all built on the assumption that
identifiers are ASCII, how can you relax that assumption without causing
so much breakage and non-interoperability that people would rather stick
with the existing ASCII system than endure the transition?

There are presumably several challenges, but that is the one that I see
as the main challenge.  I suppose that the people advocating approaches
very different from IMAA might think I'm overestimating the height
of this hurdle, and therefore might see something else as the main
challenge.

AMC

Date: Mon, 27 Oct 2003 14:17:54 -0500
From: Keith Moore <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

[recipient list trimmed to what I hope is a reasonable subset]

> On Mon, 27 Oct 2003, Keith Moore wrote:
> > Thanks for taking a stab at a problem statement.  I'd like to drill
> > down on this just a bit.
> > What is the source of the "growing need"?  Is it:
> > [snip]
> 
> I agree that this needs to be stated, but someone other than me will
> have to do it.

Sorry, I should have made that clearer.  I intended the question for
everyone, not just you.

I do suspect that the shape of the solution looks very different 
depending on how a person defines the problem, and in particular,
on his beliefs about the "growing need".

Keith

Date: Mon, 27 Oct 2003 11:10:55 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

On Mon, 27 Oct 2003, Keith Moore wrote:
> Thanks for taking a stab at a problem statement.  I'd like to drill down
> on this just a bit.
> What is the source of the "growing need"?  Is it:
> [snip]

I agree that this needs to be stated, but someone other than me will have
to do it.

I believe that the primary push for this functionality comes from regions
which use Latin alphabetics with diacriticals; and that most individuals
in regions which do not use Latin script are accept the use of Latin
script for multinational interchange.  In many regions where Latin
diacriticals are used, there is no acceptable transform of a surname to a
form that does not use diacriticals.  Simply omitting the diacritical
causes (at least to the inhabitants of those regions) a misspelling.

This set of beliefs naturally biases how I approach the problem.  The
problem statement must be free of bias, including mine.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 27 Oct 2003 13:44:03 -0500
From: Keith Moore <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Mark,

Thanks for taking a stab at a problem statement.  I'd like to drill down
on this just a bit.

What is the source of the "growing need"?  Is it:

a. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to remember
b. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to transcribe or type
c. users want to use their names in email addresses
d. users are confused by apparently arbitrary restrictions on use of 
   characters in email addresses, and this leads to mistakes
e. on computer systems employing non-ASCII names for other purposes (e.g.
   login or account names) these do not map well to ASCII email addresses

or something else that I don't see?

> As presently constituted, email addresses are limited to the 26 Latin
> alphabetics, 10 digits, and a limited number of special characters in
> the ASCII character set.  There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and
> non-Latin characters, in email addresses to better serve the needs of
> the multi-national Internet community.  However, the restrictions of
> ASCII email addresses have served as a "lingua franca" since everybody
> can enter ASCII email addresses, and there is an ongoing need for this
> as well.  The problem to be solved is the resolution of these two
> needs.

Date: Mon, 27 Oct 2003 09:30:46 -0800
From: [email-masked] (WJCarpenter)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

mc> As presently constituted, email addresses are limited to the 26
mc> Latin alphabetics, 10 digits, and a limited number of special
mc> characters in the ASCII character set.  There is a growing need to

upper and lower case alphabetics
-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

Date: Mon, 27 Oct 2003 09:13:29 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

On Mon, 27 Oct 2003, Keith Moore wrote:
> what problem are we trying to solve here?

I agree with Keith.  This isn't to say that I dispute that there is a
problem to be solved -- indeed, I think that the problem is apparent to
all -- but we must have a problem statement that we all agree upon before
we even think about solutions.

I don't think that references to drafts of proposed solutions suffice as a
problem statement.  Leaving aside questions of possible bias (= present a
problem in such a way that this is the obvious best solution), having the
problem statement in a draft (which by its nature is an ephemeral
document) muddies the issues.

The problem statement should consist of a single paragraph (and preferably
in one or two sentences), separate from any proposed solution, and stated
in a charter which is approved by everyone.

Here's a start at such a statement:

As presently constituted, email addresses are limited to the 26 Latin
alphabetics, 10 digits, and a limited number of special characters in the
ASCII character set.  There is a growing need to use additional
characters, specifically Latin characters with diacriticals and non-Latin
characters, in email addresses to better serve the needs of the
multi-national Internet community.  However, the restrictions of ASCII
email addresses have served as a "lingua franca" since everybody can enter
ASCII email addresses, and there is an ongoing need for this as well.  The
problem to be solved is the resolution of these two needs.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 27 Oct 2003 12:00:01 -0500
From: Marc Blanchet <[email-masked]>
To: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

-- Monday, October 27, 2003 10:52:22 -0500 Keith Moore <[email-masked]>
wrote/a ecrit:

>> PF>    What are the next steps for the IETF?
>> 
>> Would it help to have a draft charter for the meeting?  
> 
> let's back up a step further.
> 
> what problem are we trying to solve here?

to me, that (problem we are trying to solve) would be part of the
introduction in the charter...

so I guess some initial proposal for:
- what are we trying to solve
- what would be the way to solve it

would be a good starting point together with the "state-of-the-art"
presentations.

Marc.

> 
> Keith

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

Date: Mon, 27 Oct 2003 10:37:21 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 10/27/03 at 10:52 AM -0500, Keith Moore wrote:

>>DC: Would it help to have a draft charter for the meeting?

As was mentioned in the draft agenda at 
<http://www.ietf.org/ietf/03nov/iea.txt>, we want to simply start the 
discussion, not immediately attempt to charter a working group.

>let's back up a step further.
>
>what problem are we trying to solve here?

Please have a look at draft-hoffman-imaa, 
draft-klensin-emailaddr-i18n, and draft-duerst-iri. Certainly the 
first two have very explicit descriptions of the problem.

pr
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Mon, 27 Oct 2003 17:35:34 +0100
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: comments: draft-moore-auto-email-response-04.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

Hi,

I am a member of the IRTF ASRG BCP-subgroup and we were asked for
comments on the above mention draft.
I became aware of the existance of the draft at this time.
Please note, with all my critics I find it *very* important to have a
RFC defining the behavior of responders of all sorts and I am aware
that I am jumping in this discussion/the draft process at a very late point.

We tried to produce a summary of comments but I was nearly the only one
commenting, so we decided I should simply send my comments directly
and Keith asked to send them to this list.

Here we go ;-)
------------------------------------------------------------------------
General:
I'm missing something like a "clear structure" in that draft.
When reading the draft I always had to maintain kinda groups in my
brain and add each of the unnumberd list topics to a group or case
study. Maybe it's just me, but it would be nice to have a somewhat
clearer "clustering". Some information that belongs together is also
splitted across several sections.

- I can't see the main goal of this draft. Is it a BCP "how to write
  a correct autoresponder" or is it mainly a proposal for a new
  2822 header field to standardise autoresponder communication. Or is
  it both (IMHO a good idea)
  Some of the following topics depend on that goal.

- Section 5 (Auto-Submitted) should be Section 2, as in sections 2,3,4
  it is referenced but not yet defined.

- I'd like to see a clearer structure. There are three responders
  defined (good). If I want to write a responder X what are the
  pitfalls. In which cases should I not send an answer. In which cases
  am I allowed to send a response and where should I send it to?
  Return-Path? From? Resent-From?
  Resent-From isn't handled at all. But it is important IMHO for
  vacation programs not to answer to the From but Resent-From if
  present. That kind of things are handled but on different places
  (2)(4) which makes it hard to track.
  Also I disagree that responders should always send to the Return-Path
  field if possible. Both (and Sender, Reply-To, Resent-From also) serve
  different purposes. Szenario: a secretary sends a message on behalf of
  her boss who is in the airplane. This leads to (RFC2822 3.6.2.
  Originator fields)
     Return-Path: secretary
     Sender: secretary
     From: boss
  IMHO a personal responder (vacation) should send the message to the
  From field.
  The arguments in (4) that From/Reply-To don't hold reliable
  information also hold true for the Return-Path field, sometimes
  even more, as I see a lot of hosts that are (speaking of the MTA)
  misconfigured to the bones and use ENV senders like
  "[email-masked]" but the address in the From field is set
  by the user to a correct and working address.

- Backward compatibility
  Currently most responders (if they do) use blacklists based on
  addresses. That is mentioned in the draft, but a list of
  addresses/address fragments would help like (perl regex):
   if ($address =~
        m/^$|daemon|request|bounce|mailer|postm|owner|lists|majordo|\-(return|error)/i) { dontanswer; }
  Also current responders look (and set) the Precedence field. Messages
  with a precedence of (bulk|list|junk)/i) should not be answered.
  This is mentioned, but only for "list".
  Also the draft mentions header List-* fields. There are a lot of
  others that should probably listed liked:
     mailing-list, x-mailing-list, x-listname, x-listmember, x-loop
  Some are not standard (x-) but widely used. If any of this is present
  reponders that are not special purpose for exactly that should not
  answer to messages with those header fields.

- Subject lines
  I think it is important that the original content of the Subject line
  stays intact with a message from an responder and therefor a MUST is
  inserted. Also the "portion" should be worded that it is only allowed
  to truncate the subject line because of rfc2822 limitations (line length).
  A lot of incident systems add incident tags to help them group the
  messages to incidents and they do not send out receipt notifications
  for an already existing indcident. Mangling/truncating the subject line
  means loosing valuable information and may result in ping pongs.
  About the "Auto:" I don't like the allowance for translation. What
  will happen is that some braindead software translators translate
  it and we will end up with scenarios that we have already with
  "normal" email where we have:
     Subject: Antw: RE: Re: AW: Re: RE: Re: original subject
  because the software is too braindead. I'd force them to exactly
  include "Auto: " at the beginning of the Subject line unless there
  is already an (case insensitive match) "Auto: " present.

- VERPs (Variable Envelope Return Paths)
  http://cr.yp.to/proto/verp.txt
  IMHO good behaving responders should use these and code the
  destination address. If they receive a bounce for that address they
  may put all messages in the responder queue for that destination on hold
  or stop acting on messages from that sender. So this should be
  recommended more explicitely.

- Section 5.2
  Extension keywords [ ... ] other than "no" MAY assume that the message
  was not manually submitted by a human.
  "Auto-Submitted: no" means it is submitted by a human. If there is a
  extension keyword (RFC released or experimental) that the responder
  doesn't know about it IMHO *MUST* (not MAY) assume a not human
  generated message and MUST NOT reply to it.

- As the most important and widely used responder is probably the
  "vacation" type it would be nice to have a section with a strict
  ruleset how a vacation program is to be written (timeout sender
  addresses at least n days, dont answer if ..., send repsonse to, ...)

- It would be nice to include a paragraph that requests anti virus
  vendors to have their software stop sending out virus warnings
  for viri faking sender addresses. They do analysis and they know
  that the virus fakes the senders so they could stop sending out false
  warnings to faked senders. Maybe it's more pressure for them if a RFC
  requests it.

   If it's not too late I'd definitely would vote for a third keyword
   in "5.1 Syntax" and have "antivirus-generated" added. This would be a
   huge benefit if antivirus vendors would add that (and probably in the
   comment area the name of the virus).
   This would result in a standard format that could be used by filters
   and one could apply rules for
      Auto-Submitted: antivirus-generated; W32/Sobig-F
   and get rid of the 500 false alerts a day that hit the info@ addresses
   and flooded our incident system.
   IMHO the number of "warnings" floating around with each new fast spreading'
   virus warrant this.
   Adding this should be a 30 minute expense for AV vendors. I'd try to
   lobby our vendor (Sophos) to add it and as soon as one has it the
   others will follow.

- Another member of IRTF ASRG BCP mentioned:
   > I'm a little concerned about the top of section 2 
   > "An automatic responder MUST NOT send a response for every message ..."
   > while this is in a sense the whole thrust of the draft, I'd imagine that it
   > sits badly with some applications - like forms of RPC over SMTP. Perhaps
   > this is one to ask someone who knows SOAP etc?
  So maybe a wording like
   "An automatic responder MUST NOT _blindly_ send a response for every
   message received."
  can make that statement more clearer.
------------------------------------------------------------------------

I hope this is helpful.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Date: Mon, 27 Oct 2003 10:52:22 -0500
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

> PF>    What are the next steps for the IETF?
> 
> Would it help to have a draft charter for the meeting?  

let's back up a step further.

what problem are we trying to solve here?

Keith

Date: Mon, 27 Oct 2003 07:41:11 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: =?ISO-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Pete Resnick <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Sender: [email-masked]

Patrik,

Thanks for putting this BOF together.

PF>       Where should the IETF tackle it?

I am not sure I understand this question.  Please clarify.

PF>    What are the next steps for the IETF?

Would it help to have a draft charter for the meeting?  (I realize that the
presence of such different specifications makes a charter at least a bit
challenging, but it seems to help to have a draft, to make things concrete.)

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

Date: Sun, 26 Oct 2003 14:15:11 -0800
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Format=Flowed/RFC 2646 Bis (-02)
Sender: [email-masked]

An updated draft which is intended to replace RFC 2646 has been sent 
in; because of the crush of last-minute submissions, there may be a 
delay before the announcement appears.  During this time it is 
available at 
<ftp://ftp.pensive.org/Public/Randy/draft-gellens-format-bis-02.txt>.

This version reflects comments received during IETF Last Call.

The changes from the -01 version are a discussion of OpenPGP's 
stripping of trailing whitespace before calculating the signature, 
mention of Unicode Annex 14, and some text clean-ups/clarifications .

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If I like it I say it's mine.  If I don't I say it's a fake.
    --Pablo Picasso

Cc: Pete Resnick <[email-masked]>, Ted Hardie <[email-masked]>, Ned Freed <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Sun, 26 Oct 2003 20:55:08 +0100
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At the IETF in Minneapolis, there will be a BOF on Internationalized 
Email Addresses (IEA).

It is *preliminary* on the agenda on Monday, November 10, 2003 at 
1530-1730.

Chairs:  Pete Resnick, Patrik F�ltstr�m
Mailing list:[email-masked] (other salient lists include [email-masked])
Agenda:

Agenda Bashing (Chairs)                5 min.
Topic Introduction (Chairs)           10 min.
Proposals
   IDNA-Based (Paul Hoffman)           15 min.
   Infrastructure-Based (John Klensin) 15 min.
   IRI-Based (Michel Suignard)         15 min.

Discussion                            60 min.

Topics for discussion:

   Are there other solutions which have been specified?

   The solutions present the problem at different scopes;

      Where should the IETF tackle it?

      Are some short-term, and other long-term?

      Can the solutions be staged or co-exist?

      If staged, how to migrate from one to another?

   What are the next steps for the IETF?

NB:  This BoF is exploratory in nature, and it is not intended that the 
IETF will finalize a decision in this venue.  It was proposed to foster 
a community discussion, not charter a working group or pick a winner. 
If further work is required, step one would be identifying individuals 
willing to carry that work forward.

Reading material:
   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

Pete and myself hope people will come with a lot of constructive 
comments and ideas.

         Patrik, co-chair of the bof

Date: 25 Oct 2003 13:02:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Jacob Palme)  wrote on 26.09.03 in <p05200f24bb99cdacaabd@[192.168.0.182]>:

> Phone numbers only contain digits, and thus do not have this
> problem.

Well, phone numbers only contain digits *on the wire* (forgetting for the  
moment about * # A B C D).

But phone numbers on paper are a different thing. Ever seen stuff like  
"1.888.CYCLADES"?

MfG Kai

Date: 25 Oct 2003 12:44:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

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

> * 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.

Deprecated, not withdrawn, I believe.

Anyway, they *do* use standard language codes to the best of my knowledge  
- they do not define codes of their own. They just shift the encoding of  
the tag characters to plane 14.

Doesn't mean it would be wise to use those for IDN, of course.

MfG Kai

Date: Thu, 23 Oct 2003 16:19:35 -0700
To: IETF RFC-822 list <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Format=Flowed/RFC 2646 Bis (-01)
Cc: "Adam M. Costello" <[email-masked]>
Sender: [email-masked]

Sorry for the delay in responding.

At 7:34 PM +0000 6/26/03, Adam M. Costello wrote:

>  Randall Gellens <[email-masked]> wrote:
>
>>  <ftp://ftp.pensive.org/Public/Randy/draft-gellens-format-bis-01.txt>.
>
>  Overall it looks good, but I'm confused by some statements in section
>  5.5:
>
>      A sequence of quoted lines of the same quote depth SHOULD be encoded
>      as a paragraph, with the last line generated as fixed and prior
>      lines generated as flowed.
>
>      Consecutive lines with the same quoting depth are considered one
>      paragraph and are reformatted together.
>
>  The following example seems to refute both statements:
>
>>The quick brown fox jumps over*
>>the lazy dog.#
>>#
>>Four score and seven years ago*
>>our fathers brought forth on*
>>this continent a new nation.#
>
>  That's a sequence of six consecutive lines, all at the same quote depth,
>  but it's clearly two paragraphs and one blank line, not one paragraph.
>
>  I think all this section is really trying to say is that whenever two
>  adjacent lines have different quote depths, senders should ensure that
>  the earlier line is fixed (does not end in a space), and receivers
>  should treat the earlier line as fixed regardless of whether it ends
>  with a space.  The additional remarks about paragraphs and sections and
>  sequences of lines are misleading (for me at least).

I added some text to clarify things, and also included your suggested 
sentence as an "in other words".

>
>  By the way, the phrase "quote depth" occurs seven times, and the phrase
>  "quoting depth" occurs twice.  You might want to make those consistent.

Thanks.  Now it's always "quote depth".

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Support the League of Winged Voters              --Firesign Theatre

Date: Thu, 9 Oct 2003 10:52:23 WET DST
From: Johnny Eriksson <[email-masked]>
To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

DJB writes:
> 
> Keith Moore writes:
> > if we had tried to sort out all of these issues, we'd have missed the
> > opportunity to use 2822 as an RFC number
> 
> It's cute to replace 822 with 2822. It's mind-bogglingly stupid to use
> that cuteness as an excuse for ignoring issues. This is supposed to be
> a helpful document for implementors, not an April Fool's RFC.

The original aim was for 1821/1822, but that was missed. Also, the
numbers 2821/2822 were reserved for some time before the RFC's were
published. Just checks the dates on the surrounding RFC's.

It was NOT done by waiting for the numbers to fly by, and then just
publish that moment.

> ---D. J. Bernstein

--Johnny, excellent programmer, network tech and agitator.

Date: Wed, 8 Oct 2003 20:37:52 -0400
From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> Keith Moore writes:
> > if we had tried to sort out all of these issues, we'd have missed the
> > opportunity to use 2822 as an RFC number
> 
> It's cute to replace 822 with 2822. It's mind-bogglingly stupid to use
> that cuteness as an excuse for ignoring issues. This is supposed to be
> a helpful document for implementors, not an April Fool's RFC.

Well, that's a long way from the point I was trying to make, which was
basically that we'd still be working on DRUMS if we hadn't given up 
trying to resolve certain issues.  Somehow mail continues to work even
without those issues being resolved.

> If you don't think that complicated decisions should delay publication
> of simple decisions, you'll have to accept the idea of multiple specs,
> each spec labelled as being only part of the picture.

FWIW, I do think that good specifications often have to resolve complicated 
decisions, and that it's usually better to spend the time required to do so
than to gloss over the lack of consensus with silence or ambiguity.  At the
same time, if you don't eventually get a significant reduction in ambiguity
for your trouble, and you can make the protocol work well despite the
ambiguity, it's worth asking whether the effort was worthwhile.   

DRUMS seemed like a good idea at the time, but in hindsight I'm not at all
sure that 282[12] resulted in more uniformity or less confusion for
implementors.  Maybe it's too soon to tell.  Or maybe the process exposed
ambiguities that had always been there.  But I think that (despite efforts
to constrain the group's activities with its charter) DRUMS served as an
invitation to those who wanted to change things for no good reason, or (more
likely) out of noble intentions but for dubious potential benefit.

From: Arnt Gulbrandsen <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Date: Thu, 9 Oct 2003 01:14:42 +0200
Sender: [email-masked]

Bruce Lilly writes:
> Also, I see no reason why some text sequence in different languages 
> should not encode to different DNS names, just as "boot" in German 
> and "boot" in English refer to two very different things (indeed, 
> there are differences between en-us and en-uk) -- in fact it seems 
> highly desirable that they *should* encode to different DNS names.

If "www.jos�.com" resolves to different domains depending on the 
viewer's locale, the phishers and scammers will have a grand time 
registering domains that look like the their victims' domains somewhere 
in the world and then swindling the users in that part of the world.

If "www.jos�.com" isn't usable, because it always has to look like e.g. 
"www.jos�(es).com" or "www.jos�(pt_BR).com", I predict that few 
businesses will bother with the whole thing. (Well. I suppose some 
Turkmen might like having "www.jos�(tm).com".)

--Arnt

Date: 8 Oct 2003 23:11:38 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

Keith Moore writes:
> if we had tried to sort out all of these issues, we'd have missed the
> opportunity to use 2822 as an RFC number

It's cute to replace 822 with 2822. It's mind-bogglingly stupid to use
that cuteness as an excuse for ignoring issues. This is supposed to be
a helpful document for implementors, not an April Fool's RFC.

If you don't think that complicated decisions should delay publication
of simple decisions, you'll have to accept the idea of multiple specs,
each spec labelled as being only part of the picture.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Wed, 8 Oct 2003 22:02:00 +0000
From: "Adam M. Costello" <[email-masked]>
To: IETF RFC-822 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]

Bruce Lilly <[email-masked]> wrote:

> > But the "transit" for domain names is often the telephone,
> > billboards, etc.  It's hard to see how invisible language tags would
> > survive such transit.
>
> The same way URLs with non-ASCII characters do so (see RFC 2396
> section 1.5);

Section 1.5 makes it quite clear that URIs don't contain non-ASCII
characters.  URIs are composed only of ASCII characters.  There is a
recommended way for those characters to be constructed (in a reversible
way) from arbitrary octets, and a recommended way for those octets to
be constructed (in a reversible way) from non-ASCII text.  But URIs
themselves are ASCII, and there is no non-ASCII presentation form; the
user always sees ASCII.  The reversible constructions I just mentioned
may be useful for machines (as in long URIs generated and consumed by
HTML forms), but they're not helpful for making URIs easier to remember
and type for humans who are unfamiliar with ASCII characters.  That is
why people are working on IRIs, which can actually contain non-ASCII
characters.

> > So jos�.com and jos�.com should be two different domain names?  (One
> > is Spanish and the other is Portugese.)
>
> Technically, they would be presentation forms of two distinct domain
> names;
>
> The impetus [for IDN] is to be able to provide for presentation of
> text (in the sense used in RFC 2277) to humans; text in some language.

The view of IDNA and its designers is that internationalized domain
names are not intended to be mere presentation forms.  They are meant to
be an extension of the concept of domain name; something exactly like
a domain name, except that it can truly contain non-ASCII characters.
JOS�, jos�, XN--JOS-DMA, and xn--jos-dma are equally real and legitimate
forms of the same internationalized label; they are all first-class
citizens of the IDN namespace.  Existing protocols (like DNS, SMTP,
message headers) use only the ASCII subset of the IDN namespace, but
that is sufficient to include all the labels, because of the equivalence
relation.  New protocols are welcome to use the non-ASCII forms as
protocol elements.  Applications are encouraged to use the non-ASCII
forms as user-interface elements for both input and output.

> "jos�.com" has never been and is not now (and is unlikely to become) a
> domain name because one of its dot-separated components does not meet
> the requirements for a subdomain;

Sorry, I was using "domain name" as shorthand for "internationalized
domain name" and using "ASCII domain name" to refer to the traditional
concept of "domain name".  That's confusing during the transition, but I
think that's going to become the common usage.

> domain names use characters from a *subset* of US-ASCII which is
> comprised of letters, digits, and the hyphen character (LDH) [I
> suspect that you know that, but your use of "ASCII domain names"
> indicates that you may have temporarily forgotten that -- '$' is a
> perfectly valid ASCII character, but it cannot appear as part of a
> domain name].

Domain names can contain any ASCII characters.  The DNS spec defines a
"preferred syntax" that is encouraged but not required.  STD-3 defines a
syntax for host names.

The DNS spec talks about how to put dots inside labels, and other
standards-track RFCs use labels containing underscores and slashes for
domain names that are not host names.

> > If I see jos�.com on paper, how do I know which of those two domains
> > it is?  And even if I know, how do I type the language tag into my
> > browser?
>
> One will appear as something like qz-jos-blurfl and the other as
> something like qz-jos-grimble.  And either can be typed, even in a
> browser on a PDA or similar device which has no accented character
> input capability.

The whole point of IDNs is to allow users to see and type familiar
characters, not ASCII garbage.  An application that supports IDNs and
accented characters should allow the user to type jos�.com, not require
the user to type qz-jos-blurfl or qz-jos-grimble.  No one would want a
domain name that always had to be typed that way.

AMC

Date: Wed, 8 Oct 2003 13:38:55 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> you mean they varied between dismay and horror?

that sounds about right to me.

Date: Wed, 08 Oct 2003 13:34:23 -0400
From: Tony Hansen <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

Pete Resnick wrote:
> On 10/8/03 at 11:44 AM -0400, Tony Hansen wrote:
>> Unfortunately, I don't think we'll get any work done in time for using 
>> 3821 and 3822 as the numbers.
> 
> Actually, I'm in a position work-wise now that I could get started on a 
> 2822 revision. I'll see if I can get something out before Minneapolis.

Cool!

	Tony

Date: Wed, 08 Oct 2003 13:33:51 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

Dave Crocker wrote:
> TH> When this topic last came up about a year ago, there were mixed feelings about 
> TH> starting up any DRUMS2 group.
> 
> mixed?
> you mean they varied between dismay and horror?

No Dave, there was little dismay or horror expressed back then. But there were 
enough people that thought it could be done WG-less. There are advantages to the 
WG-less approach, but there are also obvious disadvantages. (Over a year later, 
we've seen neither 2821bis nor 2822bis.)

	Tony

Date: Wed, 8 Oct 2003 11:37:39 -0500
To: Tony Hansen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Cc: [email-masked]
Sender: [email-masked]

On 10/8/03 at 11:44 AM -0400, Tony Hansen wrote:

>Unfortunately, I don't think we'll get any work done in time for 
>using 3821 and 3822 as the numbers.

Actually, I'm in a position work-wise now that I could get started on 
a 2822 revision. I'll see if I can get something out before 
Minneapolis.

pr
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 8 Oct 2003 12:05:42 -0400
Subject: Re: Why do MIME imlementations sometimes fail
Cc: [email-masked]
To: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
From: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

Good point, this is a more precise way of putting it.  Being 
multilingual only helps if the languages you know are diverse enough.  
(My limited Hebrew has sensitized me to these issues far more than my 
limited Spanish, for example.)

On Tuesday, September 30, 2003, at 08:24  AM, Claus F�rber wrote:

>
> 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: Wed, 8 Oct 2003 12:06:57 -0400
Subject: Re: Why do MIME imlementations sometimes fail
Cc: [email-masked]
To: Jacob Palme <[email-masked]>
From: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

On Monday, September 29, 2003, at 09:02  AM, Jacob Palme wrote:

> We have developed a non-standard messaging system which
> supports multi-linguality and translation...

I think the interesting question, then, for me and others on this list, 
is:  What precise things did you do in a non-standard way for lack of a 
standards-based alternative?  That's the question that would lead us to 
understand the minimal needed extensions.  -- Nathaniel

Date: Wed, 8 Oct 2003 08:51:20 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

Tony,

TH> When this topic last came up about a year ago, there were mixed feelings about 
TH> starting up any DRUMS2 group.

mixed?

you mean they varied between dismay and horror?

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

Date: Wed, 08 Oct 2003 11:44:53 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

I've spoken with both John and Pete in the past about updating 2821 and 2822. 
They've both been maintaining errata lists and agreed with me at that time that 
new versions of 2821/2822 should eventually be released. Pete felt that 2822bis 
would be ready to move to draft standard, but John felt that 2821bis would have 
too many needed changes to let it move to draft standard at this time.

When this topic last came up about a year ago, there were mixed feelings about 
starting up any DRUMS2 group.

Unfortunately, I don't think we'll get any work done in time for using 3821 and 
3822 as the numbers. Can we do it in time for 4821/4822? :-)

	Tony

Russ Allbery wrote:
> Keith Moore <[email-masked]> writes:
> Once you have a list of errata, I don't understand why you think it's much
> work at all to actually apply them to the document.  Producing the list of
> errata is all the work.
> 
>>obviously this depends on how many things need to be changed.  but I
>>recommend to start working on a list of errata.
> 
> I agree.  Starting with a list of errata is the right approach.  I just
> don't want to see it published solely that way.

Date: Wed, 08 Oct 2003 08:57:37 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF RFC-822 list <[email-masked]>
Organization: Bruce Lilly
To: IETF RFC-822 list <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Adam M. Costello wrote:
> Bruce Lilly <[email-masked]> wrote:
> 
>>Such a tag should not be separate from the IDN; it should be part of
>>the IDN so that it travels with and is processed with the text which
>>is presented to a human (using a client with appropriate IDN support).
>>One wouldn't want the language tag to be stripped or otherwise mangled
>>in transit.
> 
> 
> But the "transit" for domain names is often the telephone, billboards,
> etc.  It's hard to see how invisible language tags would survive such
> transit.

The same way URLs with non-ASCII characters do so (see RFC 2396 section 1.5);
viz. via a compatible encoding which provides for unambiguous rendering.

>>I see no reason why some text sequence in different languages should
>>not encode to different DNS names, just as "boot" in German and
>>"boot" in English refer to two very different things (indeed, there
>>are differences between en-us and en-uk) -- in fact it seems highly
>>desirable that they *should* encode to different DNS names.
> 
> 
> So jos�.com and jos�.com should be two different domain names?  (One is
> Spanish and the other is Portuguese.)

Technically, they would be presentation forms of two distinct domain
names; domain names use characters from a *subset* of US-ASCII which is
comprised of letters, digits, and the hyphen character (LDH) [I suspect
that you know that, but your use of "ASCII domain names" indicates that
you may have temporarily forgotten that -- '$' is a perfectly valid ASCII
character, but it cannot appear as part of a domain name]. "jos�.com" has
never been and is not now (and is unlikely to become) a domain name because
one of its dot-separated components does not meet the requirements for a
subdomain; it is not comprised solely of LDH characters.

Domain names do not always mimic proper names; often a domain name refers
to subject matter, and as noted the same sequence of characters often
means very different things in different languages (and often --
sometimes even when meaning is unchanged -- is spoken differently
(which is why language tagging is essential for presentation via text-to-
speech)).

> If I see jos�.com on paper, how
> do I know which of those two domains it is?  And even if I know, how do
> I type the language tag into my browser?

One will appear as something like qz-jos-blurfl and the other as something
like qz-jos-grimble. And either can be typed, even in a browser on a PDA or
similar device which has no accented character input capability.  Depending
on exactly how the tagging is implemented [it should be clear that I don't
care much for Unicode 3.1 / RFC 2482] one might be printable as jos�(es).com
and the other as jos�(pt-br).com, for example (probably not ideal syntax, but
hopefully you get the idea).  However, in that case, printing or typing may
be issues (identification, normalization, I/O, etc.).  For non-ephemeral
presentation, one would be well-advised to use the unambiguous on-the-wire
form.

> This is why I think language tagging, if used at all, would need to be
> non-essential markup, which could be retained when feasible, but could
> also be lost with no worse result than a degradation in the quality of
> presentation, not a failure to find the domain.

Something like qz-pt-br--jos-farkle, i.e. placing the language tag outside
of the nameprep+punycode process might be feasible, but discarding the tag
discards information.

'Presentation' and 'find[ing] the domain' are distinct operations. Some
form of presentation might be able to get away with hiding some information
which may be essential for other forms of presentation.  However, discarding
such information is incompatible with use in a protocol. Software encountering
"qz-jos-blurfl" as a domain name had better use that when passing the name to
DNS, regardless of what is used for non-protocol (i.e. human) presentation.

Domain name components are comprised of characters from LDH -- 37 elements,
and can have length of up to 63 of those characters.  That's 37^63 distinct
components of length 63. There are also 37^62 possible subdomains of length
62, etc. Total domain name length can be up to 255 (LDH) characters.  Clearly
there is no shortage of domain names -- obviously the motivation for IDN isn't
a need to broaden the characters beyond LDH because of any shortage of domain
names.  The impetus is to be able to provide for presentation of text (in the
sense used in RFC 2277) to humans; text in some language.

Date: Wed, 8 Oct 2003 05:03:03 +0000
From: "Adam M. Costello" <[email-masked]>
To: IETF RFC-822 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]

Bruce Lilly <[email-masked]> wrote:

> The string transmitted via DNS is a 'name' (in the sense used in RFCs
> 1958 and 2277), and need not (should not) be language-tagged -- it is
> not 'text' in the sense used in RFC 2277.

Agreed.

> But as the idea behind IDN is to provide a displayable bit of 'text',
> i.e. some string of characters in some charset (utf-8) and presumably
> in some language and intended for human consumption, it would be
> appropriate for the displayable form to include a language tag.

IDNs are not designed to have different semantics from ASCII domain
names ('text' versus 'name'); they are designed to have the same
semantics and merely support a larger character set.

> Such a tag should not be separate from the IDN; it should be part of
> the IDN so that it travels with and is processed with the text which
> is presented to a human (using a client with appropriate IDN support).
> One wouldn't want the language tag to be stripped or otherwise mangled
> in transit.

But the "transit" for domain names is often the telephone, billboards,
etc.  It's hard to see how invisible language tags would survive such
transit.

> I see no reason why some text sequence in different languages should
> not encode to different DNS names, just as "boot" in German and
> "boot" in English refer to two very different things (indeed, there
> are differences between en-us and en-uk) -- in fact it seems highly
> desirable that they *should* encode to different DNS names.

So jos�.com and jos�.com should be two different domain names?  (One is
Spanish and the other is Portuguese.)  If I see jos�.com on paper, how
do I know which of those two domains it is?  And even if I know, how do
I type the language tag into my browser?

This is why I think language tagging, if used at all, would need to be
non-essential markup, which could be retained when feasible, but could
also be lost with no worse result than a degradation in the quality of
presentation, not a failure to find the domain.

AMC

Date: Tue, 07 Oct 2003 23:55:05 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF RFC-822 list <[email-masked]>
Organization: Bruce Lilly
To: IETF RFC-822 list <[email-masked]>
Subject: Re: Dual names, IDN and ASCII, in e-mail addresses?
Sender: [email-masked]

Adam M. Costello wrote:

> 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).

After some reflection, I believe I disagree.  The string transmitted via
DNS is a 'name' (in the sense used in RFCs 1958 and 2277), and need not
(should not) be language-tagged -- it is not 'text' in the sense used in
RFC 2277.  There is no need for language identification at the level of
DNS; the DNS 'name' is simply an LDH tag that serves as the key for a
database lookup. I.e. there should *not* be language-tagging markup
around the LDH 'name', since natural language is irrelevant to the DNS
protocol.

But as the idea behind IDN is to provide a displayable bit of 'text',
i.e. some string of characters in some charset (utf-8) and presumably in
some language and intended for human consumption, it would be appropriate
for the displayable form to include a language tag. [Of course, there are
portability issues with the Unicode 3.1 language-tagging codes (in
addition to the fact that they are non-standard).]  Such a tag should not
be separate from the IDN; it should be part of the IDN so that it travels
with and is processed with the text which is presented to a human (using a
client with appropriate IDN support). One wouldn't want the language tag to
be stripped or otherwise mangled in transit.

Presumably the holder of a Japanese-language domain name would wish the
displayed text to be identifiable *as* a Japanese name to users of
IDN-capable client software (w/ or w/o text-to-speech capability), and
would almost certainly not wish to tag it as Chinese. Also, if something
like the Unicode 3.1 scheme were used (with suitable changes to nameprep),
the DNS-compatible form for Japanese- and Chinese-tagged text would lead
to different strings of LDH characters, since nameprep+punycode would be
applied to the tagged text, which would differ by virtue of the different
language tags. [but perhaps I misunderstand your meaning of "the very same
string of characters"] Also, I see no reason why some text sequence in
different languages should not encode to different DNS names, just as
"boot" in German and "boot" in English refer to two very different things
(indeed, there are differences between en-us and en-uk) -- in fact it
seems highly desirable that they *should* encode to different DNS names.

Date: Sun, 5 Oct 2003 22:39:32 -0400
From: Keith Moore <[email-masked]>
To: Sam Roberts <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> Quoteing [email-masked], on Wed, Oct 01, 2003 at 09:47:10PM -0400:
> > let's put it this way - anyone wanting to deploy X- fields and then have
> > them standardized later is making things considerably more difficult for
> > themselves than  necessary. 
> 
> Sure, And the reason this is so should be mentioned in 2822, rather than
> leaving folks just mystified, or searching megabytes of the drums
> archives, wherein you will find many opinions expressed, and be lost as
> to the ones which eventually held sway, and resulted in the drop of x-.

>From a standpoint of what belongs in the document, I agree with you.

But if we had tried to sort out all of these issues, we'd have missed the
opportunity to use 2822 as an RFC number, and we'd curently be trying to get
that same document out the door in time for it to be published as RFC 4822.

Date: Fri, 3 Oct 2003 17:42:09 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Quoteing [email-masked], on Wed, Oct 01, 2003 at 09:47:10PM -0400:
> let's put it this way - anyone wanting to deploy X- fields and then have them
> standardized later is making things considerably more difficult for themselves
> than  necessary. 

Sure, And the reason this is so should be mentioned in 2822, rather than
leaving folks just mystified, or searching megabytes of the drums
archives, wherein you will find many opinions expressed, and be lost as
to the ones which eventually held sway, and resulted in the drop of x-.

Cheers,
Sam

To: IETF-Announce: ;
Cc: 
From: The IESG <[email-masked]>
Reply-To: [email-masked]
Date: Fri, 03 Oct 2003 10:19:10 -0400
Subject: Last Call: 'Recommendations for Automatic Responses to Electronic  Mail' to Proposed Standard
Sender: [email-masked]

The IESG has received a request from an individual submitter to consider 
the following document:

- 'Recommendations for Automatic Responses to Electronic Mail '
   <draft-moore-auto-email-response-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2003-10-31.
                                                                                       
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-moore-auto-email-response-04.txt

Date: Thu, 2 Oct 2003 15:48:54 +0100 (BST)
From: Charles Lindsey <[email-masked]>
Reply-To: Charles Lindsey <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
To: [email-masked]
Content-MD5: EtmgpGH5Fnhc/QaPPBr1ow==
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> 
writes:

>> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
>> 2822 is merely a Proposed Standard.
>> 
>> As for things lacking in RFC 2822; I wish the X-* headers could be
>> discussed, at least to explicitly acknowledge that they are no longer
>> the recommended solution to introduce new headers.

>they never were the recommended solution to introduce new header fields.

Graham Klyne's proposed Registry of header names addresses that problem
(in its 'provisional' classification).

BTW, what is progress on that front? Last I heard IESG were looking at it
with a view to RFC.

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

Date: Thu, 02 Oct 2003 08:54:06 -0700 (PDT)
From: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> In <[email-masked]> Keith Moore <[email-masked]>
> writes:

> >> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
> >> 2822 is merely a Proposed Standard.
> >>
> >> As for things lacking in RFC 2822; I wish the X-* headers could be
> >> discussed, at least to explicitly acknowledge that they are no longer
> >> the recommended solution to introduce new headers.

> >they never were the recommended solution to introduce new header fields.

> Graham Klyne's proposed Registry of header names addresses that problem
> (in its 'provisional' classification).

> BTW, what is progress on that front? Last I heard IESG were looking at it
> with a view to RFC.

This is what the datatracker is for. I suggest you check out the state of
the document there.

				Ned

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-moore-auto-email-response-04.txt,.ps,.pdf
Date: Thu, 02 Oct 2003 10:50:21 -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-04.txt,.ps,.pdf
	Pages		: 21
	Date		: 2003-10-2
	
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-04.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-04.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-04.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-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 2 Oct 2003 10:36:07 +0100 (BST)
From: Charles Lindsey <[email-masked]>
Reply-To: Charles Lindsey <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
To: [email-masked]
Content-MD5: EtmgpGH5Fnhc/QaPPBr1ow==
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> 
writes:

>> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
>> 2822 is merely a Proposed Standard.
>> 
>> As for things lacking in RFC 2822; I wish the X-* headers could be
>> discussed, at least to explicitly acknowledge that they are no longer
>> the recommended solution to introduce new headers.

>they never were the recommended solution to introduce new header fields.

Graham Klyne's proposed Registry of header names addresses that problem
(in its 'provisional' classification).

BTW, what is progress on that front? Last I heard IESG were looking at it
with a view to RFC.

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

Date: Thu, 02 Oct 2003 01:43:32 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked], ;, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], ;, [email-masked], [email-masked], [email-masked], ;, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], ;, [email-masked], [email-masked], [email-masked], ;, [email-masked], [email-masked]
Organization: Bruce Lilly
To: dhananjay <[email-masked]>
CC: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

dhananjay wrote:

> When you say .. no body and no header ... does it mean that ... "." can 
> appear in header part like in following example.
>  >>DATA
> <<354 start data; end with <cr><lf>.<cr><lf>
> Subject: -ve testing
> . To: [email-masked] <mailto:[email-masked]>

In SMTP DATA, a '.' at the beginning of a line in the data to be transferred
must be preceded by another '.'. See RFC 2821 section 4.5.2.  A '.' at the
beginning of a line which is not followed by another '.' or by CRLF is not
permitted.

> In such case, such message should be treated as illegal .. is that 
> correct ? 

First let's distinguish between the SMTP protocol as discussed in RFC 2821
and the message format discussed in RFC 2822. SMTP is a means of transferring
some ASCII data from one system to another. That data is conventionally a
message as defined in RFC 2822 -- while in theory any ASCII data could be
transferred, if it's not a message conforming to RFC 2822 it will not be
likely to be recognized as a message by the recipient.  Note that there is a
division of responsibility; the data is transferred by software implementing
the SMTP protocol -- such software is known as a Mail Transfer Agent (MTA).
The message is generated and displayed by different software, a Mail User Agent
(MUA). An MTA is not supposed to care about the message content (see RFC 2821
section 2.4).

That sequence is not legal because it does not comply with RFC 1123 section 5.2.11.
Such a sequence can never arise between conforming SMTP implementations.

It's also not valid message (RFC 2822) content.

> "." cant be accounted for anything, as ". To" can not be considered as a 
> valid optional header field since header field name must not contain <sp>.

Prior to RFC 822, a header field name could theoretically contain spaces, but
no such header field was ever formally defined, and the current syntax does
not permit spaces in a header field name.

Date: Wed, 1 Oct 2003 21:47:10 -0400
From: Keith Moore <[email-masked]>
To: "Michael Bell" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> As it is I can TELL you most implementors are largely looking at 2822 and
> ignoring 822 now.

you can TELL me whatever you wish, but I have no reason to believe you.

let's put it this way - anyone wanting to deploy X- fields and then have them
standardized later is making things considerably more difficult for themselves
than  necessary. 

> So if there is ANYTHING in 822 NOT mentioned in 2822 of importance, it needs
> to be grafted in, or mentioned. Anything else should be specifically listed
> as altered or deprecated.

strongly disagree.  but if your goal is to keep 2822 from being revised for
several years, that's a good way to go about it.

From: "Michael Bell" <[email-masked]>
To: "IETF RFC-822 list" <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Date: Wed, 1 Oct 2003 16:10:52 -0700
Sender: [email-masked]

PMFJI   but your opinion has no relation to the real world. At least IMO <g>

As it is I can TELL you most implementors are largely looking at 2822 and
ignoring 822 now. Making it a fnalized standard (good idea) will effectively
rubberstamp that.

So if there is ANYTHING in 822 NOT mentioned in 2822 of importance, it needs
to be grafted in, or mentioned. Anything else should be specifically listed
as altered or deprecated.

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "IETF RFC-822 list" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 01, 2003 2:10 PM
Subject: Re: Regarding SMTP Message specification syntax ...

>
> > RFC 822 makes a promise that fields beginning with X- will never be
> > standardized.  If RFC 822 is truly obsoleted by a document that
> > doesn't restate that promise, then the promise will have been lost;
>
> "obsoleted" is not a formal action, it's just a label put on by the RFC
> Editor.   and as in this case, it is sometimes misleading.
>
> My view is that the text in RFC 822 stands until it is formally and
> explicitly changed.

Date: Wed, 1 Oct 2003 22:58:31 +0000
From: "Adam M. Costello" <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

Keith Moore <[email-masked]> wrote:

> > RFC 822 makes a promise that fields beginning with X- will never
> > be standardized.  If RFC 822 is truly obsoleted by a document that
> > doesn't restate that promise, then the promise will have been lost;
>
> "obsoleted" is not a formal action, it's just a label put on by the
> RFC Editor. and as in this case, it is sometimes misleading.
>
> My view is that the text in RFC 822 stands until it is formally and
> explicitly changed.

Okay, if a successor to 822 becomes a Standard and if 822 becomes
Historic, and if the new document does not restate the promise,
then the promise will have been effectively rescinded.  Is that the
intended vision of the future?  Do people expect 822 to become Historic
eventually, or to remain a Standard coexisting with the new Standard?

AMC

Date: Wed, 1 Oct 2003 17:10:31 -0400
From: Keith Moore <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> RFC 822 makes a promise that fields beginning with X- will never be
> standardized.  If RFC 822 is truly obsoleted by a document that
> doesn't restate that promise, then the promise will have been lost;

"obsoleted" is not a formal action, it's just a label put on by the RFC
Editor.   and as in this case, it is sometimes misleading.

My view is that the text in RFC 822 stands until it is formally and
explicitly changed.

Date: Wed, 1 Oct 2003 20:52:17 +0000
From: "Adam M. Costello" <[email-masked]>
To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

Keith Moore <[email-masked]> wrote:

> I just don't want to reopen the discussion of whether X- fields are
> good.

Even if we agree that the ultimate successor to RFC 822 should not say
anything about whether X- fields are good, or what they might be good
for, that still leaves an open question:

RFC 822 makes a promise that fields beginning with X- will never be
standardized.  If RFC 822 is truly obsoleted by a document that doesn't
restate that promise, then the promise will have been lost; the IETF
will have effectively reclaimed the right to go back on its word.  Is
that the intention?

If not, then the successor to 822 needs at least one sentence saying
that fields beginning with X- will never be standardized.  It doesn't
need to say why.

AMC

To: Keith Moore <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Oct 2003 22:32:03 +0200
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> Simon is saying that 2822bis Appendix B should have one item added:
>> "31. X-* header fields are not discussed".
>> 
>> I don't see a big problem with that.
>
> nor I, if that's all that's being proposed.

I'd like to see them mentioned, that's it.  If there isn't any
agreement on the rules associated with them (which seem to be the
case), the above text seems appropriate, and is fine by me.

The text above could serve as a reminder that X-* is a potentially
controversial area, so people don't assume that their own opinion
about X-* is something that is universally agreed on.

> I just don't want to reopen the discussion of whether X- fields are
> good.  At least not in the context of revising this document.

Sure.

Thanks,
Simon

From: "dhananjay" <[email-masked]>
To: "Bruce Lilly" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Date: Wed, 1 Oct 2003 12:30:58 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0B39_01C38817.DE1FB0B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>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:

Thank you all for such a nice information.
When you say .. no body and no header ... does it mean that ... "." can
appear in header part like in following example.
>>DATA
<<354 start data; end with <cr><lf>.<cr><lf>
Subject: -ve testing
. To: [email-masked]

In such case, such message should be treated as illegal .. is that correct ?
"." cant be accounted for anything, as ". To" can not be considered as a
valid optional header field since header field name must not contain <sp>.

Regards,
Dhananjay.

------=_NextPart_000_0B39_01C38817.DE1FB0B0
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><FONT face=3D"Times New Roman" =
size=3D3>&gt;If you mean=20
a completely empty message, i.e. no body and no header, then =
that<BR>&gt;is not=20
legal. RFC 822 section 4.1 gives the message syntax; date,=20
originator<BR>&gt;(From), and at least one recipient (To, Cc, Bcc) =
header fields=20
are mandatory:</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you all for such a nice =
information.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>When you say ..=20
no body and no header ... does it mean that ... "." can appear in header =
part=20
like in following example.</FONT></FONT></DIV>
<DIV>&gt;&gt;DATA</DIV>
<DIV><FONT face=3DArial size=3D2>&lt;&lt;354 start data; end with=20
&lt;cr&gt;&lt;lf&gt;.&lt;cr&gt;&lt;lf&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: -ve testing<BR>. To: <A=20
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In such case,&nbsp;such message should =
be treated=20
as illegal .. is that correct ?&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"." cant be accounted for anything, as =
". To" can=20
not&nbsp;be considered as a valid optional header field&nbsp;since =
header field=20
name&nbsp;must not contain &lt;sp&gt;.</DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV><FONT face=3DArial =
size=3D2>Regards,<BR>Dhananjay.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0B39_01C38817.DE1FB0B0--

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Cc: IETF RFC-822 list <[email-masked]>, Simon Josefsson <[email-masked]>
Date: Wed, 1 Oct 2003 21:08:47 +0200
Sender: [email-masked]

Keith Moore writes:
>>  Simon is saying that 2822bis Appendix B should have one item added: 
>>  "31. X-* header fields are not discussed".
>>
>>  I don't see a big problem with that.
>
> nor I, if that's all that's being proposed.  I just don't want to 
> reopen the discussion of whether X- fields are good.  At least not in 
> the context of revising this document.

I think you've persuaded everyone about the last bit, so relax ;)

--Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Cc: Russ Allbery <[email-masked]>, IETF RFC-822 list <[email-masked]>
Date: Wed, 1 Oct 2003 21:07:04 +0200
Sender: [email-masked]

Keith Moore writes:
> and trying to read through a long document looking for minute changes 
> isn't frustrating and time consuming?

RFCs 2822 and 3501 both contain a useful Appendix B detailing the changes.

> just try to avoid the mindset that the entire document is being revised.

Agree entirely.

--ARnt

Date: Wed, 1 Oct 2003 15:02:13 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> Simon is saying that 2822bis Appendix B should have one item added:
> "31. X-* header fields are not discussed".
> 
> I don't see a big problem with that.

nor I, if that's all that's being proposed.  I just don't want to reopen
the discussion of whether X- fields are good.  At least not in the context
of revising this document.

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Cc: IETF RFC-822 list <[email-masked]>, Simon Josefsson <[email-masked]>
Date: Wed, 1 Oct 2003 21:02:07 +0200
Sender: [email-masked]

Keith Moore writes:
>> It would be sufficient that the revised document acknowledge that X-* 
>> are not discussed, if the perception is that nothing else can be 
>> agreed on.
>
> I don't think that belongs in a standards-track document. A separate 
> document, perhaps.

Simon is saying that 2822bis Appendix B should have one item added:
"31. X-* header fields are not discussed".

I don't see a big problem with that.

--Arnt

To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 01 Oct 2003 11:55:13 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> and trying to read through a long document looking for minute changes
> isn't frustrating and time consuming?

So list the changes at the end, just like was done with various other
documents revised for draft standard.

> (not to mention the tremendous amount of work required to revise that
> document)

Once you have a list of errata, I don't understand why you think it's much
work at all to actually apply them to the document.  Producing the list of
errata is all the work.

> obviously this depends on how many things need to be changed.  but I
> recommend to start working on a list of errata.

I agree.  Starting with a list of errata is the right approach.  I just
don't want to see it published solely that way.

> just try to avoid the mindset that the entire document is being revised.

I agree with this too.

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

Date: Wed, 1 Oct 2003 14:45:43 -0400
From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> > not so.  2822 can be advanced in grade without revising it.  I think
> > it would also be reasonable to publish a separate list of errata and
> > declare 2822 + that list to be a draft standard, though I don't know
> > whether IESG would go along with that.
> 
> I think that would be needlessly annoying to implementors.  Reading
> errata lists is frustrating and time-consuming.  

and trying to read through a long document looking for minute changes
isn't frustrating and time consuming?

(not to mention the tremendous amount of work required to revise that
document)

obviously this depends on how many things need to be changed.  but I
recommend to start working on a list of errata.  if that list gets to be
long enough, it's not much more work to fold those changes into the
document.  just try to avoid the mindset that the entire document is
being revised.

Date: Wed, 1 Oct 2003 14:40:54 -0400
From: Keith Moore <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> > There's really no problem with X-* at all; the rules in 822 are clear.  
> 
> Then what is the problem including those rules in a revised document?

the problem is that it's a political can of worms.   there were people arguing
that X- should be legitmized, and there were people arguing that legitimizing
X- would destroy the entire purpose of X-.

> If a revision of 2822 is moved to Draft Standard, and fully obsolete
> 822, I don't believe that what 822 says or not matters. 

822 is going to be definitive for as long as people want their email readers
to be able to read messages that were created before 2822 (or its successor) 
became (a) full standard and (b) widely deployed.   

> It would be
> sufficient that the revised document acknowledge that X-* are not
> discussed, if the perception is that nothing else can be agreed on.

I don't think that belongs in a standards-track document.  A separate document,
perhaps.

> Acting as if X-* never existed is not enlightening.

nobody is proposing to delete all copies of 822 from the archives.

To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Oct 2003 20:36:54 +0200
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> The notion that people should use X-* for experiments (be them
>> implementation experiments or specification experiments) is quite wide
>> spread.  Changing that notion, when there is an opportunity, seems
>> like a good thing.
>
> It's perfectly fine to use X-* for experiments.  What's not fine is
> expecting to widely deploy and/or standardize the protocol used in those
> experiments without changing it.   If you want to widely deploy a field,
> you need to formally define it, publish its definition, and probably
> get some sort of community approval for use of that field.

I agree.

> There's really no problem with X-* at all; the rules in 822 are clear.  

Then what is the problem including those rules in a revised document?
That is what I have been arguing for, if that wasn't clear.

If a revision of 2822 is moved to Draft Standard, and fully obsolete
822, I don't believe that what 822 says or not matters.  It would be
sufficient that the revised document acknowledge that X-* are not
discussed, if the perception is that nothing else can be agreed on.
Acting as if X-* never existed is not enlightening.

> The problem is with people who think it's okay to widely deploy and/or
> standardize half-baked ideas without  doing either analysis or review of
> those ideas.  Changing how X-* is used won't address that problem.

Ignoring X-* won't address the problem either.

Thanks,
Simon

To: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 01 Oct 2003 11:18:05 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> not so.  2822 can be advanced in grade without revising it.  I think it
> would also be reasonable to publish a separate list of errata and
> declare 2822 + that list to be a draft standard, though I don't know
> whether IESG would go along with that.

I think that would be needlessly annoying to implementors.  Reading errata
lists is frustrating and time-consuming.  If someone is going to do all
the work required to produce the errata list, why not incorporate it into
the document and just publish the revised document?

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

Date: Wed, 1 Oct 2003 13:45:33 -0400
From: Keith Moore <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> Keith Moore <[email-masked]> writes:
> 
> >> To turn this discussion into something potentially useful; do you
> >> think a 2822bis (822tres?) should discuss X-* or not?  If so, what
> >do> you think it should say?
> >
> > If 2822 is revised I think it should only contain minor
> > clarifications of the existing material.   The effort to revise 2822
> > should avoid opening up new cans of worms.
> 
> I agree.  Do you also, like me, consider 822 existing material?  822
> discuss X-*, and I think that clarifying its role in a 2822 revision
> would be useful.

I consider X-* a can of worms.  

Clarifying the X-* situation might be useful, but it shouldn't be coupled
with revising 2822.

> The notion that people should use X-* for experiments (be them
> implementation experiments or specification experiments) is quite wide
> spread.  Changing that notion, when there is an opportunity, seems
> like a good thing.

It's perfectly fine to use X-* for experiments.  What's not fine is
expecting to widely deploy and/or standardize the protocol used in those
experiments without changing it.   If you want to widely deploy a field,
you need to formally define it, publish its definition, and probably
get some sort of community approval for use of that field.

There's really no problem with X-* at all; the rules in 822 are clear.  
The problem is with people who think it's okay to widely deploy and/or
standardize half-baked ideas without  doing either analysis or review of
those ideas.  Changing how X-* is used won't address that problem.

To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Oct 2003 18:59:55 +0200
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> To turn this discussion into something potentially useful; do you
>> think a 2822bis (822tres?) should discuss X-* or not?  If so, what do
>> you think it should say?
>
> If 2822 is revised I think it should only contain minor clarifications
> of the existing material.   The effort to revise 2822 should avoid 
> opening up new cans of worms.

I agree.  Do you also, like me, consider 822 existing material?  822
discuss X-*, and I think that clarifying its role in a 2822 revision
would be useful.

The notion that people should use X-* for experiments (be them
implementation experiments or specification experiments) is quite wide
spread.  Changing that notion, when there is an opportunity, seems
like a good thing.

Thanks,
Simon

Date: Wed, 01 Oct 2003 09:23:35 -0700 (PDT)
From: [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
To: Keith Moore <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> On Wed, 01 Oct 2003 15:59:27 +0200
> Simon Josefsson <[email-masked]> wrote:

> > Keith Moore <[email-masked]> writes:
> >
> > >> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
> > >> 2822 is merely a Proposed Standard.
> > >>
> > >> As for things lacking in RFC 2822; I wish the X-* headers could be
> > >> discussed, at least to explicitly acknowledge that they are no longer
> > >> the recommended solution to introduce new headers.
> > >
> > > they never were the recommended solution to introduce new header fields.
> >
> > OK, replace "new header fields" with "user defined header fields"
> > then.  To me, they both result in the same thing, as any new header
> > field at some point in time would have been a user defined header
> > field during experiments, but perhaps you see a difference.

> New fields don't have to be used in experiments before being defined.

> > To turn this discussion into something potentially useful; do you
> > think a 2822bis (822tres?) should discuss X-* or not?  If so, what do
> > you think it should say?

> If 2822 is revised I think it should only contain minor clarifications
> of the existing material.   The effort to revise 2822 should avoid
> opening up new cans of worms.

I agree 100%. New cans of worms will only delay things interminably, and
will also have the effect of resetting the standards clock to proposed.

				Ned

Date: Wed, 1 Oct 2003 10:36:04 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> Keith Moore writes:
> > If 2822 is revised I think it should only contain minor
> > clarifications of the existing material.
> 
> 2822 should be revised, bcause that's the only way to formally
> obsolete 822.

not so.  2822 can be advanced in grade without revising it.  I think it
would also be reasonable to publish a separate list of errata and declare
2822 + that list to be a draft standard, though I don't know whether IESG
would go along with that.

> I agree that 2822 is good and that only very minor changes should be
> done.

I also want to avoid refighting a lot of the same battles that were fought
in DRUMS, to no useful conclusion.

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Cc: IETF mailing list on e-mail headers <[email-masked]>, Simon Josefsson <[email-masked]>
Date: Wed, 1 Oct 2003 16:35:19 +0200
Sender: [email-masked]

Keith Moore writes:
> If 2822 is revised I think it should only contain minor clarifications 
> of the existing material.

2822 should be revised, bcause that's the only way to formally obsolete 822.

I agree that 2822 is good and that only very minor changes should be done.

--Arnt

Date: Wed, 1 Oct 2003 10:04:39 -0400
From: Keith Moore <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

On Wed, 01 Oct 2003 15:59:27 +0200
Simon Josefsson <[email-masked]> wrote:

> Keith Moore <[email-masked]> writes:
> 
> >> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
> >> 2822 is merely a Proposed Standard.
> >> 
> >> As for things lacking in RFC 2822; I wish the X-* headers could be
> >> discussed, at least to explicitly acknowledge that they are no longer
> >> the recommended solution to introduce new headers.
> >
> > they never were the recommended solution to introduce new header fields.
> 
> OK, replace "new header fields" with "user defined header fields"
> then.  To me, they both result in the same thing, as any new header
> field at some point in time would have been a user defined header
> field during experiments, but perhaps you see a difference.

New fields don't have to be used in experiments before being defined. 

> To turn this discussion into something potentially useful; do you
> think a 2822bis (822tres?) should discuss X-* or not?  If so, what do
> you think it should say?

If 2822 is revised I think it should only contain minor clarifications
of the existing material.   The effort to revise 2822 should avoid 
opening up new cans of worms.

To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Oct 2003 15:59:27 +0200
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
>> 2822 is merely a Proposed Standard.
>> 
>> As for things lacking in RFC 2822; I wish the X-* headers could be
>> discussed, at least to explicitly acknowledge that they are no longer
>> the recommended solution to introduce new headers.
>
> they never were the recommended solution to introduce new header fields.

OK, replace "new header fields" with "user defined header fields"
then.  To me, they both result in the same thing, as any new header
field at some point in time would have been a user defined header
field during experiments, but perhaps you see a difference.

To turn this discussion into something potentially useful; do you
think a 2822bis (822tres?) should discuss X-* or not?  If so, what do
you think it should say?

Thanks,
Simon

Date: Wed, 1 Oct 2003 09:33:14 -0400
From: Keith Moore <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Regarding SMTP Message specification syntax ...
Sender: [email-masked]

> RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
> 2822 is merely a Proposed Standard.
> 
> As for things lacking in RFC 2822; I wish the X-* headers could be
> discussed, at least to explicitly acknowledge that they are no longer
> the recommended solution to introduce new headers.

they never were the recommended solution to introduce new header fields.

To: Arnt Gulbrandsen <[email-masked]>
Cc: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
From: Simon Josefsson <[email-masked]>
Date: Wed, 01 Oct 2003 15:29:51 +0200
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

>>     I went through RFC822 in search of this, but could not gain much from
>> "Message specification section 4.1" with regards to this issue.
>
> Please don't read 822 any more. 2821/2822 are the main current RFCs

RFC 2822 doesn't obsolete RFC 822 standards wise though, since RFC
2822 is merely a Proposed Standard.

As for things lacking in RFC 2822; I wish the X-* headers could be
discussed, at least to explicitly acknowledge that they are no longer
the recommended solution to introduce new headers.

From: Arnt Gulbrandsen <[email-masked]>
To: IETF RFC-822 list <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Date: Wed, 1 Oct 2003 12:32:42 +0200
Sender: [email-masked]

Adam M. Costello writes:
> Arnt Gulbrandsen <[email-masked]> wrote:
>
>>  Please don't read 822 any more. 2821/2822 are the main current RFCs
>
> Unless you're writing a mail user agent and wondering whether you need 
> to preserve the upper/lower case information in any of the fields in 
> a message header. RFC 2822 says nothing about preserving case, but 
> 822 tells exactly which fields do and do not need case preservation 
> (in section 3.4.7).

I beg to differ. The rules in RFC822 3.4.7 may be complete, but they're 
not necessarily descriptive of what a MUA needs to do. Try sending FroM 
and see how many receivers choke on it, expecting From. And if I read 
it correctly, 3.4.7 says localparts are case sensitive sometimes but 
generally not (the grammar notes "case-preserved"). The 3.4.7 rules 
don't seem practical for a MUA's addressbook lookup.

I agree that there might be more troublesome omissions in 2822. Is there 
a document editor for 3822 yet?

> I don't know if that's the only omission; I haven't done a thorough search.

Please post about each and every one as you run across them.

--Arnt

Date: Wed, 1 Oct 2003 09:12:19 +0000
From: "Adam M. Costello" <[email-masked]>
To: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Reply-To: IETF RFC-822 list <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> wrote:

> Please don't read 822 any more. 2821/2822 are the main current RFCs

Unless you're writing a mail user agent and wondering whether you need
to preserve the upper/lower case information in any of the fields in a
message header.  RFC 2822 says nothing about preserving case, but 822
tells exactly which fields do and do not need case preservation (in
section 3.4.7).

I don't know if that's the only omission; I haven't done a thorough
search.

Of course 2822 contains new information that you don't want to miss
(like deprecations of some syntax), so I recommend reading both.

AMC

From: Arnt Gulbrandsen <[email-masked]>
To: IETF mailing list on e-mail headers <[email-masked]>
Subject: Re: Regarding SMTP Message specification syntax ...
Date: Wed, 1 Oct 2003 09:48:47 +0200
Sender: [email-masked]

[email-masked] writes:
> 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 ?

You're talking about the SMTP stream now, aren't you? You should treat 
as if no DATA command has been sent at all. See RFC 1854 section 2.1, 
fourth paragraph.

>     I went through RFC822 in search of this, but could not gain much from
> "Message specification section 4.1" with regards to this issue.

Please don't read 822 any more. 2821/2822 are the main current RFCs

--Arnt