RE: [idn] IDNs in email message bodies

["Brian W. Spolarich" <briansp@walid.com>]

| -----Original Message-----
| From: Patrik Faltstrom [mailto:paf@cisco.com]
| Sent: Tuesday, March 27, 2001 12:18 AM
| To: Brian W. Spolarich; Adam M. Costello; idn working group
| Subject: RE: [idn] IDNs in email message bodies
| 
| 
| At 17.49 -0500 01-03-26, Brian W. Spolarich wrote:
| >   Meaning that only when you may have to call the 'doDNSOperation'
| >mythical function do you need to worry about the IDN issues.
| 
| No, you have to worry about IDN also when using the domainname as 
| protocol parameter in the application protocol aswell, which include 
| for example when using SMTP. One of the main things in IDNA is that 
| the ace is good because the domainname whenever being a domainname 
| (i.e. not only when you are to use DNS) is encoded in ascii.

  I think my response was unclear.  I stated later that the 
important distinction for IDNs in that those in protocol
elements should be ACE.

| This is one of the differences between IDNA and what Walid have in 
| it's patent by the way -- at least when I read the patent -- because 
| the patent talk about intercepting just the doDNSOperation and do the 
| encoding only in that case.

  What WALID, Inc. is doing today (regardless of the IPR) isn't 
intended as the ultimate solution, but rather something that will
transition well as that solution emerges without breaking things
along the way.  No one would be foolish enough (I hope) to think
they have clarvoyance enough to tackle this problem unilaterally.

  My gut tells me that you're going to need a doDNSOperation-style
interceptor in order to do an effective transition to IDNA. 

| I claim that is not sufficient, and that is why I wrote the IDNA spec 
| the way I did.
| 
| The real problem is when a domainname is not really a domainname in a 
| protocol sense -- which includes when it is inside the mail body.
| 
| And, I really would like to have explicit suggestions for text which 
| I can add to the document which clearifies how to handle this case.

  I'll shut up then and contribute a suggestion in that vein. :-)