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

I take it back. The message that started this particular flame war
belongs here. (The flame war itself probably belongs in the garbage.)
The solution is to remove most of the politicization around the topic.

First, this doesn't have much to do with "Internationalization". 
It's just a recommendation for theuse of character encodings. 
It isn't binding, it is just advice. And this specification is not
a place for a commentary about the status of character encoding
choices in other Internet protocols. We're just recommending what
you should do with URL schemes, in the cases where it is appropriate.

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.

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.