* John Stracke wrote:
>Gisle Aas wrote:
>
>> But I don't really understand how IRIs solve any problem if you still
>> can't "use non-ASCII characters in host names".
>>
>> Don't you want to be http://björn.höhrmann.de? :-)
... and björn@höhrmann.de, yes. I must have these addresses, that's what
i18n is all about, isn't it? ;-)
>It's coming; see <http://www.ietf.org/html.charters/idn-charter.html>.
>(There are people trying to jump the gun, but it turns out to be a hard
>problem. For example, should björn.höhrmann.de be equivalent to
>bjorn.hohrmann.de? Or consider Hebrew, where vowels are not letters, and
>often omitted; should two domain names that differ only in the vowels be
>equivalent?)
>
>In the meantime, IRIs let you have non-ASCII in the file names, at least.
Better: in the path, query and fragment component.
IRIs solve a _very_ common problem. Consider a search engine with a
method='get' form. If you use this search engine to search for e.g.
'Björn Höhrmann' how to encode the URI? And if some CGI script receives
the data, how to decode it if one doesn't know what character encoding
was used to encode the characters? There is currently no definition how
to handle this case. Most user agents use the chosen (i.e. in most cases
the encoding of the current (X)HTML document) to encode the characters
but since HTML doesn't define any default encoding, you have still no
clue what happens to your queries.
--
:: no signature today :: in memoriam Douglas Adams ::
