[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Document Status?
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)
>
> 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
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