W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1996

Re: draft-holtman-http-safe-00.txt

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Thu, 10 Oct 1996 05:46:28 -0700
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9610100546.aa16762@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1737
> Quoting from section 5.2 of [2] (draft-ietf-html-i18n-05.txt):
>    The best solution is to use the "multipart/form-data" media type
>    ^^^^^^^^^^^^^^^^^
>    described in [RFC1867] with the POST method of form submission.
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Do you disagree with draft-ietf-html-i18n-05.txt, or with my
> interpretation of it?  I can't really tell from your comments.

Yes, I disagree with <draft-ietf-html-i18n-05.txt> and I did so
more than once on the HTML WG list.  I'd rather not discuss it again.

> I have not read all of draft-ietf-html-i18n-05.txt, so I may be
> missing something, but the quote above seems quite clear.  POSTs are
> the route draft-ietf-html-i18n-05.txt seems to be taking, and
> draft-ietf-html-i18n-05.txt is approved as a proposed standard.  

For the particular problem they were discussing, yes.  That particular
problem only occurs under ALL of the conditions I described.  What i18n
did was try to find a theoretically cleaner solution to a problem that
has already been solved in a number of ways in practice.  What they should
have done is just recommend using the existing methods of handling
charset-varying input until such time as there was a new method for GET+body.

> My proposal attempts to identify and clear away an obstacle to the
> deployment of draft-ietf-html-i18n-05.txt.  If you can convince me it
> does not, I will retract my proposal.

What obstacle?  Having the user hit the OK button is an inconvenience.
Given that the conditions under which a charset-sensitive input dialog
is needed is ridiculously low (and no, this has nothing to do with
western vs non-western -- it is only when the input text is in a different
charset than what the server would expect, the charset of the form),
I just don't consider it a worthy justification for yet-another HTTP
control field. [And if it was, the browser community would implement it
long before the standards committee, regardless of other HTTP requirements.]

I don't mind the proposal -- just be sure the justification for it
matches the actual need and doesn't invent problems that don't exist.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Thursday, 10 October 1996 05:56:20 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC