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

Laryy;

> I take it back. The message that started this particular flame war
> belongs here.

No.

The war was once faught here and has concluded.

> First, this doesn't have much to do with "Internationalization". 

Wrong.

The conclusion has been that Internationalized URL is ASCI-only URL.

> It's just a recommendation for the use of character encodings. 

Recomendation of UTF-8 is technically wrong.

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.

It is also impossible to restore ISO-2022-CN encoding from UTF-8,
though distinction between GB and CNS encoding is often essential.

> 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.

Use of %HH must be mandatory.

The only safe recommendation to be compaible with existing
practice is to use ISO 2022.

The section should be:

Use of Character Encodings

   When describing new URL schemes in which the elements of
   the URL are actually representations of sequences of characters,
   it's octet value should be represented by corresponding safe
   ASCII characters or by %HH notation. There is no room of
   unnecessary variety except that even safe ASCII character
   may be represented as %HH.

   Unless there is some compelling reason for a particular scheme
   to do otherwise, translating character sequences into ISO 2022
   comformant ones [RFC 1468, RFC 1554, RFC 1557, RFC 1922] or
   ISO 2022 based scheme assuming initial designation of ASCII to
   G0 and nothing to G1, G2 or G3 is recommended [ISO 2022]. Then
   %HH encoding for unsafe characters MUST be used.

> Avoiding Variants
> 
> If a protocol allows multiple ways to access the same resource,
> e.g., multiple alternative character encodings or byte sequences needed
> to access a particular resource, it is preferable for the URL scheme
> to reduce the variability, even at the cost of introducing a translation
> when mapping from URL to protocol. This will reduce the number
> of alternative URLs for the same resource, and encourage consistency.
> In particular, if a protocol supports multiple charset representations
> for strings and those representations include UTF-8, it would be
> preferable
> to use UTF-8 uniformly in the URL scheme than to allow all 
> protocol-compatible variants.

That's bogus.

When something is already represented by some code, there is no room
of additional translation.

There is no URL issue to be recommended.

						Masataka Ohta