Re: [idn] Document Status?

[Soobok Lee <lsb@postel.co.kr>]

On Wed, Sep 04, 2002 at 09:22:50PM +0900, Soobok Lee wrote:
> On Wed, Sep 04, 2002 at 01:33:21PM +0200, JFC (Jefsey) Morfin wrote:
> > On 06:10 04/09/02, Soobok Lee said:
> > 
> > >Networking is not enough. Applications' need matters
> > 
> > hmmm. ....
> > 
> > 1. are you sure Internet is about networking or about computer remote access
> > 
> > 2. IMHO networking must match applications requirements. Otherwise Networks 
> > are of no use. But networking is allowed to make it smartly the best way 
> > for both. Massaging (namepreparation) IMHO is at the hedge of the 
> > networking since you may want to customize it. But it is stall networking 
> > because it should be neutral to the application. It is not information 
> > processing as it is ancillary service (as per USC definition of 
> > contributing to the data transfer)

Moreover, IDN and ASCII domains names are used as not only mnemonic handles
to numeric IP address for networking but also   identifiers  like email 
addresses. For example, MS Passport membership databases use  email 
addressess as primary key identifiers. We can find similar identifier use
of domain names in server certificates and individual email certificates
that form one component of critical PKI-based authentication framework for
the internet.


> > 
> > Do we agree on that? 
> 
> Networking serves Applications, as SMTP serves to move RFC822-compliant
> messages between two messaging Applicatons. IDN promises to improve the
> presentation layers of most internet applications by facilitating 
> localized access to domain names. So, IDN's inception itself was to be 
> user-oriented/user-friendlier.  To connecting two host machines does not 
> need i18n of domain names nor user-friendliness, Ascii one is enough. 
> IDN goal is closer to Applications.
> 
> IDN's expanded character repoitores introduce various ambiguity/security

s/repoitore/repertoire/

Soobok Lee

> problems into DNS and then into all applications that accepts IDN strings.
> IDN strings should be dealt with additional cares and cautions, 
> but they are moved silently as encoded in trusted ASCII encoding so that
> most applications cannot notice that happens. That's why i call that kind
> of tunneling a troyan horse from the rigorous/conservative security viewpoints.
> And that is the very point where MIME(base64) encoding of Subject: header
> and the ACE-encoding of email addressess divorce far from each other.
> 
> Soobok Lee