Re: [idn] Re: IDN WG Last Call on two major changes toStringprep

[John C Klensin <klensin@jck.com>]

--On Saturday, 27 July, 2002 07:51 -0700 Mark Davis
<mark@macchiato.com> wrote:

>...
>> During the meeting, I thought that the most straightforward
>> method was
>> to force the periods to be LTR. However, after looking at the
>> results
>> in both a RTL and LTR context, I concluded that Mati's approach
>> would
>> be better. The results both in terms of field order and order
>> within a
>> field would still be determinate. With any complete URL (with
>> http://, ftp://, etc.) it would be easy to recognize the order 
>> in context, since the position of those initial letters would
>> show the order.
>> The
>> only bad case would be where the end of the string reversed
>> because of
>> its surroundings, e.g.:
>> 
>> Memory:         the url http://SOME.LARGE.mixed.CORP.org is
>> the one Display (LTR):  the url
>> http://EGRAL.EMOS.mixed.PROC.org is the one Display (RTL):
>> org is the one.PROC.mixed.EGRAL.EMOS//: the url http
>> 
>> Thus in flowing text, users would be recommended to bracket
>> any BIDI URL with RLM (or embed the URL). E.g.
>...

Mark,

As I understand it, this essentially implies that an IDN, or at
least an IDN that might contain RTL characters, is not
interpretable unambiguously unless it appears as part of a
fully-spelled-out URL.  I can't imagine that being acceptable.  I
can't even imagine it being acceptable to require that IDNs
appear in URLs at all to be valid.

To repeat something I seem to need to say in every talk I give
about these issues,
   "the web is not the net".
This WG is tasked with internationalizing _domain names_, not
URLs. An acceptable URL solution may also be a requirement, but
that is a side-effect.

       john