[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] New protocol proposal: IDNRA



At/Ā 16:23 2000-08-27 +0200, Patrik Fältström you wrote/vous écriviez:
>At 14.22 +0800 00-08-27, James Seng wrote:
>
>I wrote this draft together with Paul just because I feel that the 
>transition period for _applications_ will be extremely long (~10 years or 
>more) so we definitly have to talk about the use of RACE encoded names 
>being used as domainnames on buissness cards etc etc. I presume I (with 
>swedish characters in my name, and therefore probably in future IDN 
>domainnames) will have to have a double-sided buissness card for a 
>looooong time, with proper characters on one side, and race encoded on the 
>other.

yeark! my own personal opinion (without my co-chair hat) is:
- if we choose an ace, i won't put the ace encoding version on my business 
card or on anything. I will prefer to have two equivalent (equivalent for 
me as putting same services for both of them: smtp, http,...) domain names: 
the ascii one (that I already got and keep it and working) and the idn one 
with the real chars shown.
- my take is that an end-user will do the same... imho
- with the gibberish of most ace encoding (well some can be more "readable" 
than others but this should not be a criteria for choosing one), how can 
you make sure that someone will type it correctly. very difficult.

in technical words, I don't think an ace encoding should be shown to the 
user. should be completly transparent to the user. The only case is for 
diagnostics purpose (as written in your draft). Same analogy to me like 
using ip addresses in urls.


>>b) Section 2.1.2:
>>    Is there any particular reason that UTF-8 is used at this level
>>rather
>>    than the more commonly wchar_t for API?
>>
>>    As IDN implementor, i used wchar_t internally as I need not waste
>>    CPU cycle converting UTF-8 char to wchar_t while doing my nameprep.
>
>This can be discussed further, and the best API should be chosen. The 
>important issue for _this_ draft is that the API used is a different than 
>what is currently used.

completly agreed. I proposed one in the idne draft.

Marc.

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.