Subject: [IMA] Updated agenda - no changes

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 01 Nov 2005 16:05:59 +0100

I have uploaded a new agenda to the IETF website at

<http://www3.ietf.org/proceedings/05nov/agenda/iee.html>

The only change is that the downgrade draft is added to the agenda, and 
that the hyperlinks now work.

                   Harald
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 02 Nov 2005 12:33:06 -0000

> that the hyperlinks now work.

Just a couple of remarks concerning the proposed Charter. It says:

This working group will address one basic approach to emai  
internationalization. That approach is based on the use of an SMTP  
extension to enable both the use of UTF-8 in envelope address local-parts  
and the use of UTF-8 in mail headers -- both in address contexts and  
wherever encoded-words are permitted today. ....

Although this work was motivated by the needs of IMA, it has the potential  
to do much more by way of permitting UTF-8 in headers in all sorts of  
other situations. And certainly it has the potential to allow UTF-8 in  
more places than just address contexts and wherever encoded-words are  
permitted. Also, that present wording seems to preclude UTF-8 in envelope  
domains. So I would suggest something more like:

"That approach is based on the use of UTF-8 in mail headers -- not only in  
address contexts but also at least where encoded-words are currently  
permitted-- together with an SMTP extension to enable such headers to be  
transported and UTF-8 to be used in envelope addresses."

Whilst we may well limit the use of UTF-8 to address contexts and  
encoded-words initially, I think it is important to devise a scheme which  
will accomodate UTF-8 extensions in other header contexts later on (the  
use of IRIs in some headers which durrently use URIs is an obvious  
example).

Again, once the principle of UTF-8 in headers has been accepted, that will  
also leave the way open for similar extensions to transports other than  
SMTP.

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Nov 2005 17:04:06 +0100

--On onsdag, november 02, 2005 12:33:06 +0000 Charles Lindsey 
<[email-masked]> wrote:

> Also, that present wording seems to preclude UTF-8 in envelope  domains.

I think that's deliberate. EITHER the sender OR the intermediate node has 
to do the IDN encoding of the domain part of email addresses in the 
envelope before looking them up in the DNS.

Doing it once (at origin) seems sensible to me.

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Nov 2005 12:05:39 -0500

--On Wednesday, 02 November, 2005 17:04 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> I think that's deliberate. EITHER the sender OR the
> intermediate node has to do the IDN encoding of the domain
> part of email addresses in the envelope before looking them up
> in the DNS.
> 

Actually not.   Independent of what the current documents might
seem to say, if the local-part is in UTF-8, who cares whether
the domain-part is in UTF-8 or in punycode?  The only important
requirement from IDNA is that any application that is about to
query the DNS for a label whose semantics are non-ASCII do so
only with  properly nameprepped data in punycode form.

    john

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 03 Nov 2005 19:27:19 -0000

> only with  properly nameprepped data in punycode form.

Indeed so. If the RCPT TO address comes in in UTF-8, then it might as well  
go out in UTF-8 when it gets passed on to the next MTA.

Tranlating to IDNA is only required when you actually want to look up a  
real IP address (or MX) to forward to. What I suspect will probably happen  
before long is that system libraries will soon contain a routine by the  
name of i18ngethostbyname, which will take a domain in UTF-8, put it  
through Nameprep, translate it to punucode, look it up in the DNS, and  
return the IP to you. So MTA writers will hardly have to do anything  
different to what they do now.

Or, if the MTA sees that the incoming message is addressed to its own  
domain, it will probably do no lookup at all, but proceed straight to its  
final delivery mode.

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 4 Nov 2005 11:38:08 +0800

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Nov 2005 23:33:55 -0500

--On Thursday, 03 November, 2005 19:27 +0000 Charles Lindsey
<[email-masked]> wrote:

> Tranlating to IDNA is only required when you actually want to
> look up a  real IP address (or MX) to forward to. What I
> suspect will probably happen  before long is that system
> libraries will soon contain a routine by the  name of
> i18ngethostbyname, which will take a domain in UTF-8, put it
> through Nameprep, translate it to punucode, look it up in the
> DNS, and  return the IP to you. So MTA writers will hardly
> have to do anything  different to what they do now.

Indeed.  And I imagine that i18ngethostbyname will inspect the
string it is given, invoking IDNA only if it encounters a UTF-8
string (as distinct from an ASCII one, punycode or not).  In
8bit-clean environments, I'd expect "gethostbyname" or
equivalent to simply be replaced by a routine that behaves that
way.

In other words, an MTA that needs to resolve a domain will,
probably without looking a it at all, simply pass the domain
part to an enhanced resolver which will know how to take any of
conventional name, punycode, or UTF-8 and return an address.

> Or, if the MTA sees that the incoming message is addressed to
> its own  domain, it will probably do no lookup at all, but
> proceed straight to its  final delivery mode.

Indeed, the more substantive change in the logic of the MTA is
that, today, the MTA needs to know its own name (for a variety
of reasons, including that optimization).  Typically, the
comparison that is made is 
    domain-part-from-address .eq?. FQDN-of-machine.
In an IDN world, a machine whose name has more than one IDN
components will either (i) need to put the entire domain-part
through IDNA (one label at a time, of course) and then make the
above comparison on the punycode strings, or (ii) it will need
to parse the domain-part into labels and then test as
     FOR number-of-labels
      label-from-domain-part .eq?. 
         (label-from-machine-FQDN | 
              punycode(label-from-machine-FQDN)

So, incrementally, getting from the classic "is this me" test to
its IDN version becomes more complex in terms of MTA
implementation than dealing with and looking up an arbitrary
FQDN that might contain IDNs.

    john

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 4 Nov 2005 13:54:41 +0800

pls ignore the last email sent by me, named with "Re: [IMA] Updated agenda - no changes".
it is sent without any comments.
This is due to error operation of my Outlook Express.
Sorry to disturb.
my comments to this email is described below.

----- Original Message ----- 
From: "Charles Lindsey" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 04, 2005 3:27 AM
Subject: Re: [IMA] Updated agenda - no changes

> real IP address (or MX) to forward to. 

Yes, agree.

>What I suspect will probably happen  

hope that scenario appear soon.

> domain, it will probably do no lookup at all, but proceed straight to its  

Yes, agree.

Yao Jiankang
CNNIC