Re: revised "generic syntax" internet draft

>Here's the approaches to i18n I've seen:
>
>(1) US-ASCII only
>
>(2) ISO-8859-1 only
>
>(3) whatever localized character set is in use
>
>(4) Explicit labelling of character set
>
>(5) Unicode derivative.
>----
>(1) Never works because it doesn't satisfy demand.
>
>(2) Never works and is even worse than (1) because not only does it fail
>to satisfy demand, but it uses up the "undefined" codepoints in such a way
>that an interoperable solution *can't* be deployed.
>
>(3) Never works, because it doesn't interoperate.  It results in a bunch
>of islands which can't communicate, except via US-ASCII.

But that is what Martin said he wanted -- the ability of an author to
decide what readership is most important.  Why is it that it is okay
to localize the address, but not to localize the charset?

Will it lead to interoperability problems?  Yes, at least until the world
accepts a common charset on its own accord.

>(4) Works fine, but is very hard to support for ideographic characters.
>Dealing with mapping tables between ISO-2022, Unicode and whatever
>character set is supported by the display system is very hard.
>
>(5) Works fine, and has potential to be easier to support than (4).

Excuse me, but it doesn't work at all unless all systems use the same
charset for encoding URLs.  Since that is not the case today, we would
have to scrap all existing servers and browsers in order for (5) to work.
In other words, it is not an acceptable solution to those of use who
have to implement the specified protocol.

>The status quo in URLs is a mixture of (1), (2), and (3).  This is
>completely unacceptable for an interoperable solution.  We *MUST* move
>towards (4) or (5).  Given that I've heard no proposals along the lines of
>MIME header encoded words, the only solution on the table is (5).

(3) does move toward (5).  It even becomes (5) when people are using UTF-8.

>I will also point out than when a URL contains unencoded 8-bit characters
>and is embedded in a properly charset-labelled document, there are no
>problems as the interpretation is clear.   We do need to deal with the
>interpretation of %-encoded 8-bit characters.  If we're ambitious, we can
>also address the issue of unlabelled unencoded 8-bit characters, but I'd
>be tempted to avoid that rathole.
>
>The biggest failure of HTTP/HTML was choosing (2) above when MIME already
>had a perfectly functional solution (4).

This is totally unrelated, but you seem to be confused.  HTTP has always
defined (4).

....Roy

Received on Tuesday, 15 April 1997 19:19:08 UTC