Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
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]
Date: Thu, 30 Oct 2003 07:32:46 +0800
List-Id: <ietf-smtp.imc.org>

> 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 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: 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>

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: "'Matti Aarnio'" <[email-masked]>, <[email-masked]>
Subject: RE: Deliver-qmails-ondemand 
Date: Wed, 29 Oct 2003 09:41:13 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> > 	I may wrong here. Please correct me if I'm.
> > 	When a server comes up, a separate thread would take care
> > 	sending #INVITE message to its neighbours and Parallely
> > 	it can take care other activities.
> 
> Yes, you *could* do that.  The problem is that if you have 
> been down for more than a few hours, having a separate thread 
> that sends ETRN to all your peers will result in your MTA 
> receiving all the several hour's backlog in a few minutes.

	Yes, That is the expected behavior.

> 
> It's not exactly clear how to do proper rate-limiting in this 
> case, or even if it should be attempted at all.  You need a 
> very good predictive function for system load that knows 
> where the "knee" in the performance curve is.  The problem is 
> that said function has to be quite reactive (reflecting the 
> past few seconds of performance and an accurate prediction of 
> the next few) but at the same time it isn't prone to false 
> positives (throttling all inbound mail because of a very 
> short term issue that will be cleared in 5 seconds or so).

	Yes, We should have a intelligent function which does the
	rate control.

> 
> Somebody needs to take all this sort of stuff and publish an 
> Informational RFC on Operational Considerations....  Any takers?
> 

	I'm ready to take up.

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

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

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--

To: Madan Ganesh Velayudham <[email-masked]>
Cc: "'Matti Aarnio'" <[email-masked]>, [email-masked]
Subject: Re: Deliver-qmails-ondemand 
From: [email-masked]
Date: Tue, 28 Oct 2003 14:30:57 -0500
Sender: [email-masked]

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

On Wed, 29 Oct 2003 00:14:22 +0530, Madan Ganesh Velayudham said:

> 	I may wrong here. Please correct me if I'm.
> 	When a server comes up, a separate thread would take care
> 	sending #INVITE message to its neighbours and Parallely
> 	it can take care other activities.

Yes, you *could* do that.  The problem is that if you have been down for more
than a few hours, having a separate thread that sends ETRN to all your peers
will result in your MTA receiving all the several hour's backlog in a few minutes.

It's not exactly clear how to do proper rate-limiting in this case, or even if it
should be attempted at all.  You need a very good predictive function for system
load that knows where the "knee" in the performance curve is.  The problem
is that said function has to be quite reactive (reflecting the past few seconds
of performance and an accurate prediction of the next few) but at the same time
it isn't prone to false positives (throttling all inbound mail because of a very
short term issue that will be cleared in 5 seconds or so).

Somebody needs to take all this sort of stuff and publish an Informational RFC
on Operational Considerations....  Any takers?

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

--==_Exmh_-1518474838P--

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: "'Matti Aarnio'" <[email-masked]>, <[email-masked]>
Subject: RE: Deliver-qmails-ondemand 
Date: Wed, 29 Oct 2003 00:14:22 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

	Thank you for your detailed explantaion.

> On Tue, 28 Oct 2003 19:35:01 +0530, Madan Ganesh Velayudham said:
> 
> > 	Yes, I understand RFC 1985, talks about Server and Client 
> > 	Interaction. And It is not clear when the client should 
> > 	initiate ETRN.
> 
> For SMTP, "client" is always the end starting the connection, 
> and "server" is the end receiving.  This means that the 
> machine you call your "SMTP server" is actually operating in 
> both modes all the time - when it accepts inbound mail it 
> runs in server mode, and (the case you are interested in) 
> when it sends mail out, it's in client mode.
> 
> To avoid this confusion, we usually talk about Mail User 
> Agents (MUAs - the code that actually talks to the user, 
> usually on a desktop/laptop/etc), Message Submission Agents 
> (MSAs - the code that accepts mail from an MUA), Message 
> Transmission Agents (MTAs - the code that moves mail from 
> system to system), and Message Delivery Agents (MDAs - the 
> code that actually gets mail into a user's mailbox).  It is 
> quite common for one piece of software to do multiple parts 
> of this process.

	Yes, I understand them clearly. I take care of MTA/MDA/MUA 
	on HP-UX.

> 
> > 	My comment is about when the SMTP server brings up, it should
> > 	inform its neighbour SMTP servers.
> 
> When your MTA comes up, it may want to connect to its 
> neighbor MTAs in client mode and issue an ETRN to tell them 
> that it is now up, and to initiate a queue run on the 
> neighboring boxes now rather than at the next scheduled time.

	My only concern was I could not get it clearer from the RFC.

> 
> As an operational note, this can be *very* dangerous in 
> high-volume environments if you have multiple neighbors with 
> large queues., particularly with high-speed network 
> connections and SMTP Pipeline enabled at both ends.

	I may wrong here. Please correct me if I'm.
	When a server comes up, a separate thread would take care
	sending #INVITE message to its neighbours and Parallely
	it can take care other activities.

> 
> The basic problem is that most high-volume mail systems are 
> Unix or Linux based, and often they include the system load 
> average in the "am I too busy?" calculation. Unfortunately, 
> said average is time-smoothed, and represents the average 
> load over the last 1/5/15 minutes.  So the server end 
> receives a client connection, which then starts sending the 
> mail *very* quickly (it's possible to get well into the 
> hundreds/second if you try hard), while fork()/exec()ing in 
> the background to do final delivery.  By the time the load 
> average starts reflecting the problem, the server has already 
> done dozens/hundreds/thousands of fork/execs and the load 
> average then proceeds to spike.  I've personally seen an IBM 
> RS6K-250 (1 133mz 601 processor) (our Listserv box at one 
> time) bring a large 8-CPU Sun (our main mail hub) to its 
> knees - the fact that the
> *average* number of recipients per message was in the 
> hundreds didn't help...

	Thank you for your sharings. That was a useful note. 

	+ MG

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

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: "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: Madan Ganesh Velayudham <[email-masked]>
Cc: "'Matti Aarnio'" <[email-masked]>, [email-masked]
Subject: Re: Deliver-qmails-ondemand 
From: [email-masked]
Date: Tue, 28 Oct 2003 10:09:56 -0500
Sender: [email-masked]

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

On Tue, 28 Oct 2003 19:35:01 +0530, Madan Ganesh Velayudham said:

> 	Yes, I understand RFC 1985, talks about Server and Client 
> 	Interaction. And It is not clear when the client should 
> 	initiate ETRN. 

For SMTP, "client" is always the end starting the connection, and "server" is
the end receiving.  This means that the machine you call your "SMTP server" is
actually operating in both modes all the time - when it accepts inbound mail it
runs in server mode, and (the case you are interested in) when it sends mail
out, it's in client mode.

To avoid this confusion, we usually talk about Mail User Agents (MUAs - the
code that actually talks to the user, usually on a desktop/laptop/etc), Message
Submission Agents (MSAs - the code that accepts mail from an MUA),
Message Transmission Agents (MTAs - the code that moves mail from system
to system), and Message Delivery Agents (MDAs - the code that actually gets
mail into a user's mailbox).  It is quite common for one piece of software to
do multiple parts of this process.

> 	My comment is about when the SMTP server brings up, it should
> 	inform its neighbour SMTP servers.

When your MTA comes up, it may want to connect to its neighbor MTAs in client
mode and issue an ETRN to tell them that it is now up, and to initiate a queue
run on the neighboring boxes now rather than at the next scheduled time.

As an operational note, this can be *very* dangerous in high-volume
environments if you have multiple neighbors with large queues., particularly
with high-speed network connections and SMTP Pipeline enabled at both ends.

The basic problem is that most high-volume mail systems are Unix or Linux
based, and often they include the system load average in the "am I too busy?"
calculation. Unfortunately, said average is time-smoothed, and represents the
average load over the last 1/5/15 minutes.  So the server end receives a client
connection, which then starts sending the mail *very* quickly (it's possible to
get well into the hundreds/second if you try hard), while fork()/exec()ing in
the background to do final delivery.  By the time the load average starts
reflecting the problem, the server has already done dozens/hundreds/thousands
of fork/execs and the load average then proceeds to spike.  I've personally
seen an IBM RS6K-250 (1 133mz 601 processor) (our Listserv box at one time)
bring a large 8-CPU Sun (our main mail hub) to its knees - the fact that the
*average* number of recipients per message was in the hundreds didn't help...

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

--==_Exmh_1032802152P--

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., )

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Matti Aarnio'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Deliver-qmails-ondemand
Date: Tue, 28 Oct 2003 19:35:01 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> > 
> > 	Please share your comments on the attached draft.
> 
> First and foremost,  how does this differ from ETRN as is
> defined in RFC 1985   ?

	Yes, I understand RFC 1985, talks about Server and Client 
	Interaction. And It is not clear when the client should 
	initiate ETRN. 
	
	My comment is about when the SMTP server brings up, it should
	inform its neighbour SMTP servers. I also understand, We can
REUSE 
	ETRN also in this place but I believe RFC does not speak about
what 
	I want to convey. If I'm wrong, Please clarify.

	+ MG

> 
> 
> -- 
> /Matti Aarnio	<[email-masked]>
> 

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>

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 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 20:12:46 +0200
From: Matti Aarnio <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked]
Subject: Re: Deliver-qmails-ondemand
Sender: [email-masked]

On Mon, Oct 27, 2003 at 11:07:36PM +0530, Madan Ganesh Velayudham wrote:
> Hi,
> 
> 	I could not complete my draft well before the 
> 	58th IETF deadline. I thought I would send the
> 	overview and seek your comments.
> 
> 	Please share your comments on the attached draft.

First and foremost,  how does this differ from ETRN as is
defined in RFC 1985   ?

> 	Thanks and Regards,
> 	MG
> 
> 	**************************
> 	Madan Ganesh Velayudham
> 	[email-masked]	
> 	+91-80-205-3108
> 	**************************
> 	+HP/STSD/Internet Services
> 	Bangalore, India
> 
> 	Everything is possible

> 		Delivering queued mails on Demand
> 		
> Overview :
> 
> When a mail cannot be sent, the mail is queued for future delivery. In 
> most of the mail server, the server periodically dispatches all of its 
> mails. After an attempt, the mails will be put back to the queue and 
> will be dispatched after the queue timeout period. That is, there is a 
> delay in attempting the next delivery attempt.
> 
> This could call for an mechanism by which the neighbour SMTP servers 
> can invite or inform the mail server that it has come online and ready 
> to receive/relay mails.
> 
> Solution :
> 
> When a SMTP server comes up, it could send an INVITE command to its 
> neighbour SMTP servers inviting that they can dispatch mails addressed 
> to this SMTP server. 
> 
> 250-INVITE
> 
> If neighbour SMTP server does not recognize the INVITE command, it 
> would return 5xx return code. The sending SMTP server can ignore the 
> reply.
> 
> The SMTP servers that can understand and allow INVITE command, can 
> start dispatching mails addressed to the SMTP server, issued INVITE.
> 
> Issues/Security Considerations :
> 
> This draft would discuss about identifying neighbour SMTP servers, 
> could be through the site's MX records.
> 
> This might introduce denial of service or some related issues. The 
> draft would analyze all the issues and solutions.
> 
> 
> 27-Oct-2003						Madan Ganesh V
> 							Hewlett-Packard
> 							[email-masked]
> 

-- 
/Matti Aarnio	<[email-masked]>

From: Arnt Gulbrandsen <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
Subject: Re: [lemonade] Deliver-qmails-ondemand
Cc: "IETF LEMONADE (E-mail)" <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 27 Oct 2003 19:04:20 +0100
Sender: [email-masked]

I believe you'll find RFC 1985 interesting.

--Arnt

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "'Madan Ganesh Velayudham'" <[email-masked]>
Subject: Deliver-qmails-ondemand
Date: Mon, 27 Oct 2003 23:13:05 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C39CDF.E09AFE80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

	I could not complete my draft well before the 
	58th IETF deadline. I thought I would send the
	overview and seek your comments.

	Please share your comments on the attached draft.

	Thanks and Regards,
	MG

	**************************
	Madan Ganesh Velayudham
	[email-masked]	
	+91-80-205-3108
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible

------=_NextPart_000_001F_01C39CDF.E09AFE80
Content-Type: text/plain;
	name="deliver-qmails-ondemand.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="deliver-qmails-ondemand.txt"

		Delivering queued mails on Demand
	=09
Overview :

When a mail cannot be sent, the mail is queued for future delivery. In =
most of the mail server, the server periodically dispatches all of its =
mails. After an attempt, the mails will be put back to the queue and =
will be dispatched after the queue timeout period. That is, there is a =
delay in attempting the next delivery attempt.

This could call for an mechanism by which the neighbour SMTP servers can =
invite or inform the mail server that it has come online and ready to =
receive/relay mails.

Solution :

When a SMTP server comes up, it could send an INVITE command to its =
neighbour SMTP servers inviting that they can dispatch mails addressed =
to this SMTP server.=20

250-INVITE

If neighbour SMTP server does not recognize the INVITE command, it would =
return 5xx return code. The sending SMTP server can ignore the reply.

The SMTP servers that can understand and allow INVITE command, can start =
dispatching mails addressed to the SMTP server, issued INVITE.

Issues/Security Considerations :

This draft would discuss about identifying neighbour SMTP servers, could =
be through the site's MX records.

This might introduce denial of service or some related issues. The draft =
would analyze all the issues and solutions.

27-Oct-2003						Madan Ganesh V
							Hewlett-Packard
							[email-masked]

------=_NextPart_000_001F_01C39CDF.E09AFE80--

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: "'Madan Ganesh Velayudham'" <[email-masked]>
Subject: Deliver-qmails-ondemand
Date: Mon, 27 Oct 2003 23:07:36 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C39CDF.1C8D7AE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

	I could not complete my draft well before the 
	58th IETF deadline. I thought I would send the
	overview and seek your comments.

	Please share your comments on the attached draft.

	Thanks and Regards,
	MG

	**************************
	Madan Ganesh Velayudham
	[email-masked]	
	+91-80-205-3108
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible

------=_NextPart_000_0018_01C39CDF.1C8D7AE0
Content-Type: text/plain;
	name="deliver-qmails-ondemand.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="deliver-qmails-ondemand.txt"

		Delivering queued mails on Demand
	=09
Overview :

When a mail cannot be sent, the mail is queued for future delivery. In =
most of the mail server, the server periodically dispatches all of its =
mails. After an attempt, the mails will be put back to the queue and =
will be dispatched after the queue timeout period. That is, there is a =
delay in attempting the next delivery attempt.

This could call for an mechanism by which the neighbour SMTP servers can =
invite or inform the mail server that it has come online and ready to =
receive/relay mails.

Solution :

When a SMTP server comes up, it could send an INVITE command to its =
neighbour SMTP servers inviting that they can dispatch mails addressed =
to this SMTP server.=20

250-INVITE

If neighbour SMTP server does not recognize the INVITE command, it would =
return 5xx return code. The sending SMTP server can ignore the reply.

The SMTP servers that can understand and allow INVITE command, can start =
dispatching mails addressed to the SMTP server, issued INVITE.

Issues/Security Considerations :

This draft would discuss about identifying neighbour SMTP servers, could =
be through the site's MX records.

This might introduce denial of service or some related issues. The draft =
would analyze all the issues and solutions.

27-Oct-2003						Madan Ganesh V
							Hewlett-Packard
							[email-masked]

------=_NextPart_000_0018_01C39CDF.1C8D7AE0--

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 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>

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: Thu, 23 Oct 2003 09:23:14 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: email standards proposal for 'bulk' mail
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Mon, 20 Oct 2003, Dave Crocker wrote:

    Rules such as "send mass mail as one copy per addressee" have
    significant effects.  Not the least, it causes one to wonder why we
    bothered creating SMTP, since it's original purpose was to permit
    carriage of multiple addressees.

Yes but this rule is a practical requirement.  It is impossible to
manage mailing lists on any significant scale without ensuring that a
returned message can be matched to its subscribed email address.

DSNs could work if sites would properly distinguish between
final-recipient and original-recipient.  Far too many get this wrong for
this to be a practical alternative at this time.

VERPs are the mechanism of choice, which requires one message per
addressee.  Even so, on large lists (over 100,000 subscribers) I find
that as many as 10 returns or so still manage to mangle the failed mail
message in such a way that it can not be automatically processed.  I'm
awe-struck by what people get wrong sometimes....

I will further point out that VERPs are an absolute requirement for my
business these days.  For example, my servers are on AOL's whitelist for
receiving messages.  One of the requirements for being on that whitelist
is receiving notices from them whenever a user clicks the "DO NOT WANT
THIS" button.  I am required to remove such subscribers (without
contacting them) when I receive these notices.  Failing to do so is
tantamount to getting blacklisted.

The notice you get includes the message that was sent but has the
identity of the user masked, almost.  What it doesn't mask is addresses
in Received lines.  So, the only way for me to remove the subscriber is
to ensure the destination address is in a Received line inserted by my
server.  Keep in mind that people often forward messages to their AOL
mailbox, so getting the notice from AOL is not as helpful as you might
think.

And before you comment on the efficacy of such a system AOL knows
exactly what they are doing, i.e., they have consciously chosen to do
things this way.  They don't care whether it's SPAM or not and they are
not the least bit interested in educating users to simply unsubscribe,
even when the unsubscribe link is right there.  You can forget about
changing them.  They do not care.

And AOL is not alone in thinking this way, they're just the biggest and
leading the way.

Finally, it's not possible to have "one-click unsubscribe" at the bottom of
a message unless you send one message per addressee.

So, one message per address is a requirement for my business.

Jim

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Cc: John C Klensin <[email-masked]>, [email-masked], Ned Freed <[email-masked]>, Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt
Date: Thu, 23 Oct 2003 16:10:53 +0900 (JST)
From: [email-masked] (Jun-ichiro itojun Hagino)
Sender: [email-masked]

--NextPart-20031023160824-1162402
Content-Type: Text/Plain; charset=us-ascii

	an updated version of draft-ietf-ngtrans-ipv6-smtp-requirement
	is attached.

	to ADs: it may not reflect all the coments i have received, but anyways
	better than nothing.  i think it should really be integrated into
	update to RFC2821 (instead of being standalone document).
	it is still using "ngtrans" in the name, however, it is suggested that
	the document should be discussed in APP area (there's no email-related
	WG exist at this point).

itojun

--NextPart-20031023160824-1162402
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
 filename="draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt"

Internet Engineering Task Force                        Motonori Nakamura
INTERNET-DRAFT                                          Kyoto University
Expires: April 23, 2004                         Jun-ichiro itojun Hagino
                                                 IIJ Research Laboratory
                                                        October 23, 2003

      SMTP operational experience in mixed IPv4/IPv6 environements
            draft-ietf-ngtrans-ipv6-smtp-requirement-07.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

The internet-draft will expire in 6 months.  The date of expiration will
be April 23, 2004.

Abstract

This document talks about SMTP operational experiences in IPv4/v6 dual
stack environments.  As IPv6-capable SMTP servers are deployed, it has
become apparent that certain configurations are necessary in
IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP
operation.  This document clarifies the problems that exist in the
transition period between IPv4 SMTP and IPv6 SMTP.  It also defines
operational requirements for stable IPv4/v6 SMTP operation.

This document does not define any new protocol.

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 1]
^L

DRAFT                SMTP in dual stack environments        October 2003

1.  Introduction

Deliveries of mail messages to the final mail drop is not always done by
direct IP communication with submiter and final receiver, and there may
be some intermediate hosts to relay the messages.  So it is difficult to
know at message submission (also at receiver side) that all intermediate
relay hosts are properly configured.  It is not so easy to configure all
the system with consistency since mail message delivery system is rather
complex on DNS setting than other Internet services.  For the transition
state from IPv4 to IPv6, both IPv4 and IPv6 interoperability should be
kept more carefully.

There are several technologies defined for the transition from IPv4 to
IPv6.  This document concentrates on SMTP issues in a dual-stack
environment, e.g. delivery of emails from IPv6-only MTA to IPv4-only MTA
is outside of the scope of the document.

IPv6-only MTA to IPv4-only MTA case could use help from IPv6-to-IPv4
translators such as [Hagino, 2001] , however, there are no special SMTP
considerations for translators needed; If there is SMTP traffic from an
IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA
will consider this as a normal IPv4 SMTP traffic.  Protocols like IDENT
[St.Johns, 1993] as well as SMTP HELO/EHLO may require special
consideration when translators are used.

The following sections explain how to make IPv4 SMTP and IPv6 SMTP
coexist in a dual-stack environment.

This document does not discuss the problems encountered when the sending
MTA and the receiving MTA have no common protocol (e.g. the sending MTA
is IPv4-only while the receiving MTA is IPv6-only).  Such a situation
should be resolved by making either side dual-stack or by making either
side use a protocol translator.

2.  Basic DNS resource record definitions for mail routing

Mail messages on the Internet are delivered based on domain name system
generally.  MX RRs are looked up to know destination hosts associated
with domain part of a mail addresse.  Similar to the way RFC's for IPv6
DNS lookup [Thomson, 1995] use IN class for both IPv4 and IPv6, IN MX
records will be used for both IPv4 and IPv6 on mail message routing,
hosts which have IPv6 transport and want to be delivered with the IPv6
transport must define IPv6 IP addresses for the host name as well as
IPv4 IP addresses.

A MX RR have two data, a preference value and the name of destination
host.  IP addresses for the destination host are also looked up to make
SMTP transport [Partridge, 1986] .  In IPv4 environment, IPv4 IP
addresses are defined with A RRs.

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 2]
^L

DRAFT                SMTP in dual stack environments        October 2003

For example, IPv6 only site may have the following DNS definitions:

     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN AAAA 3ffe:501:ffff::1
     mx10.example.org.       IN AAAA 3ffe:501:ffff::2

In transition period from IPv4 to IPv6, there are many IPv4 sites, and
such sites will not have mail interoperability with IPv6 only sites.
For the transition period, all mail domains should have MX records such
that MX targets with IPv4 and IPv6 addresses exist, e.g, for example:

     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN AAAA 3ffe:501:ffff::1
                             IN A    192.0.2.1
     mx10.example.org.       IN AAAA 3ffe:501:ffff::2
                             IN A    192.0.2.2

But, every host may not support dual stack operation, some host entries
may have only IPv4 or IPv6 RRs:

     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN AAAA 3ffe:501:ffff::1
     mx10.example.org.       IN A    192.0.2.1

In the following sections, how sender side operates with IPv4/IPv6
combined RR definitions (section 3), and how receiver side should define
RRs to keep interoperability with both IPv4 and IPv6 Internet (section
4) are considerd.

3.  SMTP sender algorithm in a dual-stack environment

In a dual-stack environment MX records for a domain resemble the
following:

     example.org.            IN MX   1  mx1.example.org.
                             IN MX   10 mx10.example.org.
     mx1.example.org.        IN A    192.0.2.1        ; dual-stack
                             IN AAAA 3ffe:501:ffff::1
     mx10.example.org.       IN AAAA 3ffe:501:ffff::2 ; IPv6 only

For a single MX record there are many possible final states, including:
(a) one or more A records for the IPv4 destination, (b) one or more AAAA
records for the IPv6 destination, (c) a mixture of A and AAAA records.
Because multiple MX records may be defined using different preference
values, multiple addresses based on multiple MX's must be traversed.
Domains without MX records and failure recovery cases must be handled
properly as well.

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 3]
^L

DRAFT                SMTP in dual stack environments        October 2003

The algorithm for an SMTP sender is basically the same as that for an
IPv4-only sender, but it now includes AAAA lookups of MX records for
SMTP-over-IPv6 delivery.  IPv4/v6 dual stack destinations should be
treated just like multihomed destinations as described in RFC2821
[Klensin, 2001] section 5.  When there is no reachable destionation
address record found (for example, the sender MTA is IPv4 only and there
are no A records available) the case should be treated just like MX
records without address records, and deliveries should never fail
because of no known address if other addresses are available related to
other MX records.

     ; if the sender MTA is IPv4 only, email delivery to a.example.org
     ; should fail with the same error as deliveries to b.example.org.
     a.example.org.          IN MX    1  mx1.a.example.org.
     mx1.a.example.org.      IN AAAA  3ffe:501:ffff::1 ; IPv6 only
     b.example.org.          IN MX    1  mx1.b.example.org.
     mx1.b.example.org.      IN HINFO "NO ADDRESS RECORDS"

An algorithm for a dual-stack SMTP sender is as follows:

(1)  Lookup the MX record for the destination domain.  If a CNAME record
     is returned, go to the top of step (1) with replacing the
     destination domain by the query's result.  If any MX records are
     returned, go to step (2) with the query's result (explicit MX).  If
     NO_DATA (i.e.  empty answer with NOERROR(0) RCODE) is returned,
     there is no MX record but the name is valid.  Assume that there is
     a record like "name. IN MX 0 name." (implicit MX) and go to step
     (3).  If HOST_NOT_FOUND (i.e. empty answer with NXDOMAIN(3) RCODE)
     is returned, there is no such domain.  Raise a permanent email
     delivery failure.  Finish.

(2)  Compare each host name in MX records with the name of sending host.
     If there is a record which has the same name, drop MX records which
     have equal to or larger than preference value of the matched MX
     record (including itself).  If multiple MX records remain, sort the
     MX records in ascending order based on their preference values.
     Loop over steps (3) to (9) on each host name in MX records in a
     sequence.  If no MX records remain, the sending host must be the
     primary MX host.  Other routing rule should be applied.  Finish.

(3)  If the sending MTA has IPv4 capability, lookup the A record.  Keep
     the resulting address until step (5).

(4)  If the sending MTA has IPv6 capability, lookup the AAAA record.

     NOTE: IPv6 addresses for hosts defined by MX records may be
     informed in additional information section of DNS querie's result
     as well as IPv4 addresses.  If there is no additional address
     information for the MX hosts, separate queries for A or AAAA
     records should be sent.  There is no way to query A and AAAA
     records at once in current DNS implementation.

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 4]
^L

DRAFT                SMTP in dual stack environments        October 2003

(5)  If there is no A or AAAA record present, try the next MX record (go
     to step (3)).  Note that the next MX record could have the same
     preference.

     NOTE: If one or more address records are found, some MTA
     implementation may sort addresses based on the implementation's
     preference of A or AAAA records.  To encourage the transition from
     IPv4 SMTP to IPv6 SMTP, AAAA records should take precedence.  But
     this type of sorting is optional.

(6)  For each of the addresses, loop over steps (7) to (9).

(7)  Try to make a TCP connection to the destination's SMTP port (25).
     The client needs to follow timeouts documented in RFC2821 section
     4.5.3.2.  If successful, go to step (9).

(8)  If unsuccessful and there is another available address, try the
     next available address.  Go to step (7).  If all addresses are not
     reachable and if a list of MX records is being traversed, try the
     next MX record (go to step (3)).  If there is no list of MX
     records, or if the end of the list of MX records has been reached,
     raise a temporary email delivery failure.  Finish.

(9)  Attempt to deliver the e-mail over the connection established, as
     specified in RFC2821 [Klensin, 2001] .  If a transient failure
     condision reported, try the next MX record (go to step (3)).  If an
     error condition reported, raise a permanent email delivery error,
     and further MX records are not tried.  Finish.  If successful, SMTP
     delivery has succeeded.  Finish.

4.  MX configuration in the recipient domain

4.1.  Ensuring reachability for both protocol versions

If a site has dual-stack reachability, the site SHOULD configure both A
and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the
site).  This will help both IPv4 and IPv6 senders to reach the site
efficiently.

4.2.  Reachability between the primary and secondary MX

When registering MX records in a DNS database in a dual-stack
environment, reachability between MX hosts must be considered carefully.
Suppose all inbound email is to be gathered at the primary MX host,
"mx1.example.org.":

     example.org.    IN MX   1   mx1.example.org.
                     IN MX   10  mx10.example.org.
                     IN MX   100 mx100.example.org.

If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 5]
^L

DRAFT                SMTP in dual stack environments        October 2003

nodes, there is no reachability between the primary MX host and the
other MX hosts.  When email reaches one of the lower MX hosts, it cannot
be relayed to the primary MX host based on MX preferencing mechanism,
therefore mx1.example.org will not be able to collect all the emails
(unless there is another transport mechanism(s) between lower-preference
MX hosts and mx1.example.org).

     ; This configuration is troublesome.
     ; No secondary MX can reach mx1.example.org.
     example.org.    IN MX   1   mx1.example.org.     ; IPv6 only
                     IN MX   10  mx10.example.org.    ; IPv4 only
                     IN MX   100 mx100.example.org.   ; IPv4 only

The easiest possible configuration is to configure the primary MX host
as a dual-stack node.  By doing so, secondary MX hosts will have no
problem reaching the primary MX host.

     ; This configuration works well.
     ; The secondary MX hosts are able to relay email to the primary MX host
     ; without any problems.
     example.org.    IN MX   1   mx1.example.org.     ; dual-stack
                     IN MX   10  mx10.example.org.    ; IPv4 only
                     IN MX   100 mx100.example.org.   ; IPv6 only

It may not be needed that the primary MX host and lower MX hosts reach
directly one another with IPv4 or IPv6 transport.  For example, it is
possible to establish a routing path with UUCP or an IPv4/v6 translator.
It is also possible to drop messages into single mailbox with shared
storage using NFS or something else offered by a dual-stack server.  It
is receiver site's matter that all messages delivered to each MX hosts
must be reached to recipient's mail drop.  In such cases, dual-stack MX
host may not be listed in the MX list.

5.  Operational experience

Many of the existing IPv6-ready MTA's appear to work in the way
documented in section 3.

There were, however, cases where IPv6-ready MTA's were confused by
broken DNS servers.  When attempting to obtain a canonical hostname,
some broken name servers return SERVFAIL (RCODE 2), a temporary failure,
on AAAA record lookups.  Upon this temporary failure, the email is
queued for a later attempt.  In the interest of IPv4/v6
interoperability, these broken DNS servers should be fixed.

6.  Open issues

o How should scoped addresses (i.e. link-local addresses) in email
  addresses be interpreted on MTA's?  We suggest prohibiting the use of
  IPv6 address literals in source routes (Scoped addresses should not

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 6]
^L

DRAFT                SMTP in dual stack environments        October 2003

  appear on the global DNS database).

o The document should really be integrated into RFC2821 [Klensin, 2001]
  (i.e. RFC2821 should talk about IPv6 cases).

7.  Security considerations

It could be problematic if the route-addr email address format is used
across multiple scope zones.  MTA's would need to reject email with
improper route-addr email address formats.

References

Hagino, 2001.
Jun-ichiro Hagino and Hal Snyder, "IPv6 multihoming support at site exit
routers" in RFC3178 (October 2001). ftp://ftp.isi.edu/in-
notes/rfc3178.txt.

St.Johns, 1993.
M. St.Johns, "Identification Protocol" in RFC1413 (January 1993).
ftp://ftp.isi.edu/in-notes/rfc1413.txt.

Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.

Partridge, 1986.
C. Partridge, "Mail routing and the domain system" in RFC974 (January
1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.

Klensin, 2001.
J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April
2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt.

Change history

00 -> 01
     Corrected the email address notation for source-routed emails,
     based on a comment from Gregory Neil Shapiro.

01 -> 02
     Change a reference to refer to RFC2822, not 822.  Used
     "example.org", not "sample.org".  These changes were based on
     comments from Arnt Gulbrandsen.  Added an ``Operational
     experiences'' section.  Clarified the case where an MX record
     points to a CNAME record, based on comments from Mohsen Souissi.

02 -> 03
     In some cases, IPv6-ready MTA's are troubled by incorrect DNS

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 7]
^L

DRAFT                SMTP in dual stack environments        October 2003

     server responses for AAAA queries.  This change was based on
     comments from Gregory Neil Shapiro.

03 -> 04
     Grammar cleanups by JJ Behrens.  More text on the delivery error
     cases.

04 -> 05
     Change title, suggested by Alain Durand.  Limit the scope of the
     document to dual stack environment (interoperation of IPv6-only
     cloud and IPv4-only cloud is out of scope).

05 -> 06
     Section on summary of IPv4 MX operation is deleted (Replaced by
     Introduction).  Clarify on CNAME chain. Cleanups on sender's
     algorithm.  Suggested by Patrik Faltstrom.

06 -> 07
     Site local address is being obsoleted in IPv6 wg, so remove
     reference to site-locals.  Reflect comments from John C Klensin:
     fixes to sending rules, correct route-addr issues.  Reflect
     comments from Michael A. Patton: HELO on connection via translator.
     Reflect comments from Robert Elz.

Acknowledgements

This draft was written based on discussions with Japanese IPv6 users and
help from the WIDE research group.  Here is a (probably incomplete) list
of people who contributed to the draft: Gregory Neil Shapiro, Arnt
Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin, Michael A.
Patton, and Robert Elz.

Author's address

     Motonori NAKAMURA
     Center for Information and Multimedia Studies, Kyoto University
     Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
     Tel: +81-75-753-9063
     Fax: +81-75-753-9056
     Email: [email-masked]

     Jun-ichiro itojun HAGINO
     Research Laboratory, Internet Initiative Japan Inc.
     1-105, Kanda Jinbo-cho,
     Chiyoda-ku,Tokyo 101-0051, JAPAN
     Tel: +81-3-5205-6464
     Fax: +81-3-5205-6466
     Email: [email-masked]

NAKAMURA, HAGINO         Expires: April 23, 2004                [Page 8]
^L

--NextPart-20031023160824-1162402--

Date: Mon, 20 Oct 2003 19:33:25 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: email standards proposal for 'bulk' mail
Sender: [email-masked]

> So I think it would be helpful for this community to formulate some
> concrete suggestions, to augment, correct, guide, or whatever, the work
> Anne's group is doing.

I can suggest two concrete actions:

1. draft a detailed comment on their document.
2. write our own document specifying technical standards for bulk and/or
   mailings.

the hard part about #1 is that we don't really have any process for gaining
consensus on comments to be made to an ad hoc "standards" organization.

I think we should do #2 regardless.  It doesn't necessarily conflict with
the efforts of their organization, but there is some overlap between the
topics.

Date: Mon, 20 Oct 2003 13:32:51 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Paul Hoffman / IMC <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: email standards proposal for 'bulk' mail
Sender: [email-masked]

Paul,

PHI> My suggestion is that we lobby them to turn their proposals into one
PHI> or more Internet Drafts and open their discussion.

1.  As you note, they have been conducting closed discussions, primarily
marked by post-hoc press releases.

2.  In fact I sent Anne a note suggesting something pretty much in line
with your own thinking.  She demured, offering the view that the work
they were doing was not technical.

This does not bode well for their interest in pursuing a public,
technical and operations discussions.  In fact, a reason I forwarded the
original note to this list is to try to recruit a base of support for
encouraging Anne's crew to re-think their perspective.

Rules such as "send mass mail as one copy per addressee" have
significant effects.  Not the least, it causes one to wonder why we
bothered creating SMTP, since it's original purpose was to permit
carriage of multiple addressees.

So I think it would be helpful for this community to formulate some
concrete suggestions, to augment, correct, guide, or whatever, the work
Anne's group is doing.

d/

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

Date: Mon, 20 Oct 2003 19:02:45 -0400
From: Keith Moore <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: email standards proposal for 'bulk' mail
Sender: [email-masked]

> >It seems more than a tad rude for them to try to circumvent IETF
> >in an area (email standards) that is traditionally IETF territory
> 
> Email best practices is not "traditionally IETF territory". 

Email protocols are, and surely the largest concentration of experts
in IETF email protocols is here.  Also, when I've seen other efforts
outside IETF to try to write documents that specify how to use IETF
email standards, they inevitably botch some thing or another.
That's why I think this work should be vetted in IETF.  And the time
to do that is not when the originating group thinks their work is
finished (and cast in quick-hardening concrete) but when they think
they have a general outline of what is desirable and it needs wider
review.  Which, from my reading of their work, seems to be about now.

Date: Mon, 20 Oct 2003 15:38:19 -0400
From: "Richard O. Hammer" <[email-masked]>
To: [email-masked]
Subject: Re: email standards proposal for 'bulk' mail
Sender: [email-masked]

The problem of spam is creating a race, as I see it, between voluntary 
standards of the sort which have governed the Internet to date, and 
government imposed standards of the sort which I expect lawyers, 
legislators, and bureaucrats to favor.

If voluntary organizations (including businesses!) can reduce the 
scale of the problem, to a level where it is not attractive as an 
issue for aspiring politicians, then I hope the lawyers and 
politicians will go foraging elsewhere.

But -- the race is on ...

Rich Hammer
Hillsborough, N.C.

Date: Mon, 20 Oct 2003 11:59:43 -0700
To: Keith Moore <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: email standards proposal for 'bulk' mail
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 2:39 PM -0400 10/20/03, Keith Moore wrote:
>It seems more than a tad rude for them to try to circumvent IETF
>in an area (email standards) that is traditionally IETF territory

Email best practices is not "traditionally IETF territory". The few 
documents that we have published in this realm are widely ignored. I 
doubt that the folks on this mailing list could even name the RFCs 
without help.

>There are some good ideas in their document; there are also some
>seriously dubious ones that at the very least need justification.

Fully agree.

>I'd love to seem them submit Internet-Drafts and open the discussion.

Fully agree.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 20 Oct 2003 14:39:24 -0400
From: Keith Moore <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: email standards proposal for 'bulk' mail
Sender: [email-masked]

> At 1:57 PM -0400 10/20/03, Keith Moore wrote:
> >Dave,
> >
> >Thanks for bringing this to the attention of the list.
> >
> >IMHO, This definitely needs to be taken up in IETF. 
> >Is it too late to get a BOF on this in Minneapolis?
> 
> Maybe. But, regardless, they haven't asked us for one, and none of 
> the principals there are IETF regulars. They have their own 
> closed-door meetings; it seems a tad rude for us to preempt them.

It seems more than a tad rude for them to try to circumvent IETF
in an area (email standards) that is traditionally IETF territory
There are some good ideas in their document; there are also some
seriously dubious ones that at the very least need justification.

> My suggestion is that we lobby them to turn their proposals into one 
> or more Internet Drafts and open their discussion. If they are 
> amenable to that, we can probably move forwards easily. They have 
> another meeting coming up in January; we could shoot for that as a 
> discussion forum.

I'd love to seem them submit Internet-Drafts and open the discussion.

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

Date: Mon, 20 Oct 2003 11:43:41 -0700
To: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: email standards proposal for 'bulk' mail
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 1:57 PM -0400 10/20/03, Keith Moore wrote:
>Dave,
>
>Thanks for bringing this to the attention of the list.
>
>IMHO, This definitely needs to be taken up in IETF. 
>Is it too late to get a BOF on this in Minneapolis?

Maybe. But, regardless, they haven't asked us for one, and none of 
the principals there are IETF regulars. They have their own 
closed-door meetings; it seems a tad rude for us to preempt them.

My suggestion is that we lobby them to turn their proposals into one 
or more Internet Drafts and open their discussion. If they are 
amenable to that, we can probably move forwards easily. They have 
another meeting coming up in January; we could shoot for that as a 
discussion forum.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 20 Oct 2003 13:57:07 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: email standards proposal for 'bulk' mail
Sender: [email-masked]

Dave,

Thanks for bringing this to the attention of the list.

IMHO, This definitely needs to be taken up in IETF.  
Is it too late to get a BOF on this in Minneapolis?

Keith

> There have been some discussions between bulk mail senders, isps, and
> anti-spam folks, with one result being a series of proposals, described
> at:
> 
>    <http://www.isipp.com/standards.php>
> 
> I have suggested that these be brought to an open standards forum.
> Whether they are, or not, I think that the IETF email community should
> review and comment on these.

Date: Fri, 17 Oct 2003 16:02:29 -0400
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: ietf-smtp <[email-masked]>
Subject: email standards proposal for 'bulk' mail
Sender: [email-masked]

(At least one of the draft "standards" pertains to SMTP, so that's the
mailing list I'm choosing.)

There have been some discussions between bulk mail senders, isps, and
anti-spam folks, with one result being a series of proposals, described
at:

   <http://www.isipp.com/standards.php>

I have suggested that these be brought to an open standards forum.
Whether they are, or not, I think that the IETF email community should
review and comment on these.

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-siemborski-rfc2554bis-00.txt
Date: Fri, 10 Oct 2003 15:38:51 -0400
Sender: [email-masked]

--NextPart

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

	Title		: SMTP Service Extension for Authentication
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-rfc2554bis-00.txt
	Pages		: 15
	Date		: 2003-10-10
	
This document defines a Simple Mail Transport Protocol (SMTP)
extension whereby an SMTP client may indicate an authentication
mechanism to the server, perform an authentication protocol
exchange, and optionally negotiate a security layer for subsequent
protocol interactions during this session.	This extension includes
a profile of the Simple Authentication and Security Layer (SASL) for
SMTP.

This document obsoletes RFC 2554 and replaces it as a Proposed
Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-00.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-siemborski-rfc2554bis-00.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-siemborski-rfc2554bis-00.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-siemborski-rfc2554bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-siemborski-rfc2554bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--