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