Re: Combining characters (was: Re: [idn] hostname historyhell)

[liana Ye <liana.ydisg@juno.com>]

Have you thought about " Mixed language URLs "
with language tags, for example:

www.zh-china/mo-mogolia/zh-county/mybusiness.com

shall be able to work?

Liana

On Sun, 25 Nov 2001 22:56:02 +0200 <rosenne@spamcop.net> writes:
> From a bidi perspective, URLs are not structured. A present day all
> ASCII URL will be presented left-to-right, because all the 
> non-letters
> contained within it, such as periods and slashes, are neutral and 
> the
> directionality of the surrounding letters, i.e. LTR. Trailing digits
> work out correctly too.
> 
> When the URL, in the future when it is possible, will be entirely in
> Hebrew, it will display correctly with components going from right 
> to
> left.
> 
> Mixed language URLs may cause some unexpected results.
> 
> See http://www.qsm.co.il/Hebrew/HebrewTest/url.htm
> 
> Jony Rosenne
> 
> > -----Original Message-----
> > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] 
> > On Behalf Of Eric A. Hall
> > Sent: Sunday, November 25, 2001 7:43 PM
> > To: liana Ye
> > Cc: idn@ops.ietf.org
> > Subject: Re: Combining characters (was: Re: [idn] hostname 
> > historyhell)
> > 
> > 
> > 
> > liana Ye wrote:
> > 
> > > I'd like to propose a more specific layering of IDN symbols:
> > > 
> > >  From the top where the user input buffer offers:
> > > 
> > >  Layer 3:  label seperators and label order normalizing
> > > 
> > >  Layer 2: Bidi label normalizing (or verticle label normalizing)
> > 
> > What is the current display order for unstructured and 
> > structured data in right-to-left display systems? Does 
> > unstructured data ("the files are on
> > server1") typically flow RTL, while URLs and other structured 
> > data display as LTR?
> > 
> > It seems that these questions are for the structured data 
> > groups to handle when they decide on an output presentation 
> > mechanism. But if URLs and other structured types will 
> > display RTL then that may affect us as well (your Layer 3 
> > label ordering in particular).
> > 
> > >  Layer 1.5: diacritic marks and combining symbol normalizing
> > > 
> > >  Layer 1:  IDN identifier matching or whatever comes out
> > >                of [nameprep].
> > > 
> > > The reason for Layer 1.5 is that these symbols can be
> > > treated in a similar way with Han characters depending on what 
> > > architecture we end up with, and what ACE will be our focus.
> > 
> > -- 
> > Eric A. Hall                                        
> http://www.ehsco.com/
> Internet Core Protocols
> http://www.oreilly.com/catalog/coreprot/
> 
> 
>