Re: URL internationalization!

Masataka Ohta <[email protected]> Tue, 25 Feb 97 16:23:26 JST
Newsgroups gmane.ietf.url
Message-ID <[email protected]>
> > > A major disadvantage of 2022 is its statefulness.
> > 
> > Can you say bidirectionality?
> > 
> > Could you please explain how you can process Arabic or Hebrew
> > script with ISO 10646 without being stateful?
> > 
> > I know how to treat such script statelessly. But, ISO 10646 can't
> 
> Bidirectionality is indeed a difficult issue for any kind of
> work on full internationalization.

No.

> It is possible to deal with bidirectionality statelessly as
> long as you have a rigid line-based format (e.g. raw text
> email). It is not possible anymore as soon as you have
> automatic formatting of paragraphs.

Sure.

But, for plain English text processing, we don't need automatic formatting either, and lines wrap at the end of a display.

> The Unicode bidirectionality algorithm is designed mainly
> for free text.

The point is that Unicode fails to be stateless, and share
"A major disadvantage" of 2022.

Combining characters is another statefullness of Unicode.

> There are some problems when directly applying
> it to editing the same text with some markup, e.g. HTML or
> LaTeX. For HTML, this has been discussed on the relevant list,

Finite-state bi-directionality, whose state can be encoded in
stateless character code, is necessary at the plain text level
and has nothing to do with HTML.

> And because an average URL
> contains a lot of ASCII parts, it's probably better
> if the components of an URL appear LTR (left-to-right) even
> in otherwise fully RTL (right-to-left) contexts.

What a fair attitude.

> The ftpext working group and the URN working group have also
> chosen UTF-8 as their preferred character encoding.

They are other mistakes of IETF. But, this ML is not the place
to discuss it.

						Masataka Ohta