Subject: [idn] URLs on a TV advertisement? On a named card? What IDNA brings into real world???

From: "jw-lin" <[email-masked]>
Date: Fri, 5 Apr 2002 16:30:00 +0800

Dear all:

    Having read so many arguments about URLs in a web page, it seems that
nobody
talked about URLs outside the computer world.
    As IDNA suggests all fields containing ML hostnames should be ACEd, does
it apply
to the real world? For example, a URLs shown on a TV program? printed on a
name
card? broadcasted on a radio program?
    If the answer is yes, why we need a new only-machine-readable nameing
system?

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Apr 2002 07:46:49 -0500

--On Friday, 05 April, 2002 16:30 +0800 jw-lin
<[email-masked]> wrote:

>     Having read so many arguments about URLs in a web page, it
> seems that nobody
>     As IDNA suggests all fields containing ML hostnames should
> be ACEd, does it apply
> to the real world? For example, a URLs shown on a TV program?
> printed on a name
>     If the answer is yes, why we need a new
> only-machine-readable nameing system?

This is actually one of the key issues.  Let me try to summarize
at least one position:  A TV program, an advertisement on a
poster, and similar things (business/name cards may or may not
be a bit different, since one is able to study them, rather than
being expected to absorb or transcribe or remember all
information quickly), are all user interfaces (even if not on
computers).   If they don't display local-language characters,
ordinary users and people will believe that we have either not
internationalized things at all, or have failed at doing so.  If
they do display local characters, the problems of transcription,
look-alike characters, etc., immediately arise.

On a business card, or in a magazine, I would assume that
cautious people would display both the local-langugae form of
the name and the ACE form, just as most organizations with phone
numbers that "spell a name" (I don't know if you see that in
Taiwan) have gradually learned to also include the numbers to
eliminate ambiguity.  But these are not easy problems.

I believe that all of the details of the above, and most or all
of the risks and options for dealing with them, have been
discussed at length in the working group, so I suggest that you
consult the archives before restarting this discussion.

    john

---

From: Martin Duerst <[email-masked]>
Date: Sat, 06 Apr 2002 18:11:37 +0900

At 07:46 02/04/05 -0500, John C Klensin wrote:
>internationalized things at all, or have failed at doing so.

I agree up to here.

>If

In most cases, these problems actually don't appear, or
appear with the same frequency as in ASCII (e.g. 1/I/l, 0/O,...).
There is no reason to think that languages other than English,
and their implementations on computers, and the ways that
people use them, are more prone to transcription/look-alike,...
problems than ASCII/English.

Transcription/look-alike problems can be slightly (or in some
constructed cases significantly) higher for cross-language
cases, but as long as the language context is consistent,
there should be no major problems.

>eliminate ambiguity.  But these are not easy problems.

My assumption is that only overcautious people, and people
without understanding of the human context, will display/print
ACE. What I think will happen for a certain time (upgrade/deployment
period) is that people may print both an ASCII-based transcribed URI
(not ACE!) and an IDN URI. This will be continued in contexts such
as the two-sided namecard even after upgrading/deployment is finished.

Native forms that fail will die out automatically. Nobody would
choose www.b0x.com (with a zero, not an Oh), and if anybody would,
they would just diappear from business because nobody is able to
reach them. Survival of the fittest. The same will happen for IDNs,
and it won't take native people too much time to figure out what
survives.

Regards,    Martin.