daemon@ATHENA.MIT.EDU (Brian Behlendorf) Fri Dec 9 21:22:04 1994
Date: Sat, 10 Dec 1994 03:00:33 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: brian@wired.com
From: Brian Behlendorf <brian@wired.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
(Topic moved to www-talk)
On Fri, 9 Dec 1994, on html-wg@oclc.org Daniel W. Connolly wrote:
> In message <ab0ebed416021004d479@[199.227.1.101]>, Dirk Herr-Hoyman writes:
> >
> >I don't want to get the discussion too far off track here, but this does
> >raise a question as to which IETF WG is responsible for WWW forms.
>
> In the beginning, there was the HTML spec and the HTTP spec. IETF working
> groups have formed around these documents.
>
> A document which has been sorely lacking for a long time is the
> much-alluded-to "browser spec." It doesn't exist; nor does an
> IETF WG to maintain it.
Indeed, we have much the same problem as HTML had before formalizing the
DTD was pursued, which is "well that's how it looks in (Mosaic|Netscape)".
Simply asking that web browsers "conform" to the HTML 2.0 DTD and HTTP
1.0 spec when it arrives isn't enough since there is more to it than
that. Many people mistakenly think that "you can only inline GIFs and
XBMs in HTML, and NetScape's cool because it lets you do JPG too" - in
fact the HTML DTD makes no such declarations. Emacs-W3 lets you inline
MPEG's after all!
Forms is a tricky area that encompasses HTML, HTTP, and CGI (which also needs
a spec!) and URL's (due to METHOD=GET). Since roughly all the same people
are involved in these areas it hasn't been a problem yet, but as we've seen,
it's not always easy to integrate the MIME-ness of HTTP with the SGML-ness of
HTML with the reserved-character restrictions of URL's with the
strightforwardness of CGI. The way I see it, those four areas could pretty
much develop independently if there was a browser spec that essentially tied
them all together: "the browser will represent form elements like THIS (HTML
issue), encode the results like THIS (CGI and URL issue), and transfer them
to the client like THIS (HTTP issue)". All four elements should be
coordinated to some extent, but what ties them together is the user-agent.
> >Since there is a proposal for forms enhancement that was at least submitted
> >to this list, I thought my question would be an appropriate one here.
>
> Since there is no browser spec, the HTML spec is where folks look for
> this info. So you're as on track as you could be, for the time being.
If you're referring to Larry Masinter's spec, the changes required to
HTML were indeed rather minimal, but there were also changes required to
the browser (he submittd diff's for XMosaic) and the server-side
processing (he also submitted a CGI program to parse it).
> It would say things like:
..[good suggestions]
> * Forms are optional. If you do them, here's now they work...
> See RFCXXX for details. (This one doesn't exist, but somebody
> could start on it right away...)
I'd prefer they not be made optional, just like a MIME mail reader has to
be able to display multipart data separately. It's nontrivial to
implement from scratch, but there are public-code implementations.
> Any takers?
I'd be interested in taking this on, sure.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
