Re: Three new I-Ds re. URL i18n

Hello Gavin,

> Currently, use of frames can lead to many, many failure cases (for 
> example, one frame is in SJIS, but the frame content for the search
> form is in ASCII, which would lead to ISO 2022-JP being sent back).

Thanks for mentionning this. I have added a paragraph to clarify this.
Basically, the spec is written for the client side, because it is
there that implementations have to advance. On the server side,
it's easy to send the charset information along with each document,
and if this is done, then your case cannot occur. This is not a
failure case of the recommendation as such (as is the problem with
transcoding proxies), but a failure case due to wrong use, which
can happen to the best schemes.


> Rather than Query-UTF8,

It should be "Query-UTF-8", and not "Query-UTF8". If I got that
wrong somewhere in the draft, please tell me. Otherwise, please
don't increase variety and confusion.


> I would like to see, as I suggested a long
> time ago, a generic feild added. Somemthing like:
> 
>    Query-Encoding: utf8
>    Query-Encoding: shift-jis
> 
> is preferrable to Query-UTF8.

Of course if you have such an alternative suggestion, you
are wellcome to write an internet-draft, too.

But why should it be preferable? We have discussed this some time
ago. I have argued that upgrading from chaos to labeled chaos
is not a very big step ahead. If we introduce Query-Encoding:,
we will have to carry it on all the time. With Query-UTF-8,
we can get rid of it once everybody uses it. Not that this
will happen that quickly, but maybe faster than we think,
because we clearly send the message: Use UTF-8 if you can.

Ideally, URLs should never have contained anything else
than UTF-8.


> Ideally, URL's should never contain queries anyway.

Thanks for initiating a little bit of philosophical discussion.

Again, thanks for your comments,	Martin.

Received on Thursday, 31 July 1997 16:21:26 UTC