> From: "Maynard Kang" <[EMAIL PROTECTED]> > To: "FDU - Sung Jae Shim" <[EMAIL PROTECTED]>, > "Harald Alvestrand" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Date: Wed, 13 Dec 2000 10:03:48 +0800 > > Hi Dr Shim, > > I made a comment during your presentation in San Diego, and this is what I > find objectionable: > > > Sung: The code can be as simple as the one shown in the following example. > > One simple coding can be the Unicode of the virtual domain name > represented > > in a local language. A server with a virtual domain name "x.y.z" will > store > > the > > corresponding Unicode of "x.y.z" in the server. A client can verify, when > a > > user types "x.y.z" on the client side, whether it accessed the right > server > > or not by examining the code it retrieved from servers. Since the Unicode > of > > "x.y.z" that user typed on the client can be easily generated, it can be > > compared to the Unicode retrieved from the server, and VIDN can > immediately > > determine whether it hits the correct server or not. > > > > If the pre-assigned code you choose bears some relation to Unicode as you > mention above, it would be best represented by an ACE like RACE or LACE as > they provide the most optimum ASCII representation of 10646 with compression > features. > > So what you propose here would in effect be Phonetic > Transliteration+Pre-Assigned Code=VIDN. If the Pre-Assigned Code is best > represented by ACE, why include the additional overhead of a Phonetic > Transliteration, then, instead of just using plain, simple ACE? > > > Sung: The code does not have to be stored in any specific format, but any > > document format that is supported and understood by both client and > server. > > This means that the code can be embedded in XML, HTML, WML, etc. as long > as > > the client can interpret the retrieved code correctly. Likewise, VIDN does > > not > > require any specific intermediate transport protocol such as TCP/IP. The > > only requirement is that the protocol must be understood among all > > participating clients and servers. > > > > This means that the VIDN solution will have to span several layers - which > is not ideal, as opposed to an IDNA+ACE solution which merely involves the > presentation layer. We all know what happens to monolithic protocols like > X.500 DAP...... > > > Sung: The codes may be administered by a standard body such as IANA. Or > the > > codes for each local language may be administered by a local standard body > > in regions where the local language is widely spoken, for example, KrNIC > for > > Korean language, JpNIC for Japanese language, and so. > > That would make code assignment entirely arbitrary by locale.. which is more > or less localization (and perhaps even in a non-standard manner, *horrors*), > and not internationalization, right? > > maynard > > >
