W3C home > Mailing lists > Public > www-international@w3.org > April to June 1996

Re: Using unicode or MBCS characters in forms

From: Larry Masinter <masinter@parc.xerox.com>
Date: Fri, 21 Jun 1996 22:34:27 PDT
To: gtn@ebt.com
Cc: www-international@w3.org
Message-Id: <96Jun21.223427pdt."2763"@golden.parc.xerox.com>
> Anyway, my statement, I believe, is correct. 

I believe that the intent and consensus of the HTTP working group is
that message bodies are disallowed in GET and HEAD methods, and that
if the HTTP/1.1 spec doesn't spell this out carefully enough, it's an
editorial issue which should be corrected. If you wish to raise this
issue, you should note that HTTP/1.1's been submitted to IESG and is
in "Last Call", and your comments are most productively directed at
the IESG and not the HTTP Working Group.

With regard to UNIFORM resource locators and INTERNATIONAL, you said:

> There are ways of dealing with this (use UTF-7, or MIME
> techniques).  In reality, this layer should largely be transparent to
> users...

Gavin, there *IS* no layer. That's the problem. There's no protocol
layer or implementation layer between "what's printed in the
newspaper" and "what the user types into the keyboard" except wetware.
"See URL", "Type URL". If the URL I see contains "Franc,ois" and the
keyboard I'm sitting at doesn't have a way of entering a "c-cedilla",
then I can't type in the URL. Period. I don't know how you can "deal
with this" or "make it transparent".

So this isn't a problem "for later", unless you mean "when the world's
keyboards are upgraded". Now, that itself might happen for Franc,ois
sometime in the next five years, but not for Akio-san.

Now, again, you might say that some people could type in one way and
other people could type in another way, and that's fine, but now the
URLs are no longer UNIFORM: some people see one URL and other people
see another URL. That's OK, too, but you must be explicit about that,
that you're defining Non-Uniform Resource Locators.


Received on Saturday, 22 June 1996 01:34:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:15 UTC