Re: Apology -- didn't read the critical section (was I18N)

> > I take it back. The message that started this particular flame war
> > belongs here.
> 
> No.
> 
> The war was once faught here and has concluded.

Yes, it belongs here. New players are here, new need. Just because
a matter has been discussed once and has been concluded does not
mean that it should never be taken up again.


> 
> > First, this doesn't have much to do with "Internationalization". 
> 
> Wrong.
> 
> The conclusion has been that Internationalized URL is ASCI-only URL.
Maybe that was the conclusion then. But for many of us that is
NOT an acceptable use of URLs. If we cannot use the non ascii letters
we need for our language, in URLs, the entire idea of WWW and URLs falls
apart as we cannot use it for the entire world. Only for the English
speaking part. I cannot represent my html-files with URLs in ascii (but
I can encode non ascii in ascii for transmission of an URL to somebody
that can only understand ascii).

> 
> > It's just a recommendation for the use of character encodings. 
> 
> Recomendation of UTF-8 is technically wrong.
Much better than many others. The major difficulty with schemes like ISO 2022
is that they forces my system to support an nearly infinite set of
character set codings. With UCS I have one character set coding to deal with.
UCS is not perfect, but much easier to handle than ISO 2022.

> 
> And, it was pointed out several times already.
> 
> For example, it is impossible to restore Big5 from UTF-8, because
> there are duplicated characters in Big5.
If they are duplicated, does it matter which is used?


> 
> > So what about this:
> > 
> > =================
> > Use of Character Encodings
> > 
> > When describing new URL schemes in which the elements of
> > the URL are actually representations of sequences of characters,
> > care should be taken not to introduce unnecessary variety in the 
> > ways in which characters are encoded into octets and then into 
> > URL characters. Unless there is some compelling reason for a 
> > particular scheme to do otherwise, translating character sequences
> > into UTF-8 [RFC 2044] and then subsequently using the %HH encoding
> > for unsafe characters is recommended.
> 
> That's incompatible with the current practice and unacceptable.
So what is current practice? To just send 8-bit bytes of any local
character set?

> 
> Use of %HH must be mandatory.
There is no need for this. The %HH encoding can be used where transport
cannot use all 8 bits in an octet. There is a one to one equivalence
between the %HH value and the binary octet value. If transport media can
handle 8-bits, it is a waste of resources to encode it into 7 bits.
> 
> The only safe recommendation to be compaible with existing
> practice is to use ISO 2022.
Iso 2022 is NOT compatible with current practice!!! I use iso 8859-1
in my URLs (adding to the current chaos) as no character set
is defined for transport of URLs.


> There is no URL issue to be recommended.
> 
Then we had better redefine an URL to be just a very long number
composed of just ascii digits. That would only be slightly worse than
ascii only URLs.

  Dan Oscarsson