What to do about HTTP?
gtn@ebt.com (Gavin Nicol)
Errors-To: listmaster@www0.cern.ch
Date: Mon, 30 May 1994 16:35:24 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405301432.AA19888@ebt-inc.ebt.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: gtn@ebt.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: gtn@ebt.com (Gavin Nicol)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: What to do about HTTP?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Brian Behlendorf <brian@wired.com> says:
>> A nobel idea. I am sure that you will do a fine job on HTML+.
>> However, I don't feel that any DTD will ever satisfy the needs of
>> everyone. I feel that HTTP needs to be extended to allow for
>> negotiation on DTD's, stylesheets, pay-per-use, encryption, and other
>> things in order for commercial publishers to be really successful.
>
>Well, yes, things do need to be added to the transaction layer, but
>that shouldn't affect too much how the document language should be
>constructed. Pay-per-use (hooray for David Chaum's great keynote
>address at WWW'94!) and encryption belong at the HTTP layer (along
>with server-side and client-side programs), while stylesheets are an
>issue above HTML. Define a strong document language, and the stylesheets
>will be created with ease. As for arbitrary DTDs... aren't they really
>different document types, and thus should have unique MIME types anyways?
I never argued for stylesheets in HTTP, only the negotiation of
stylesheets, and DTD's. One advantage of SGML is that you can have
many different stylesheets for the same document. If you make each DTD
a special mime type, then how do you negotiate for the stylesheets or
DTD's to use? What I am arguing for is something entirely
open-ended...
>Additionally, the level of programming browsers would need to properly
>display arbitrary DTD's would be huge, and these browsers are big enough
>already.
This is not true. Again, I was arguing for some negotiation protocol
on SGML-awareness; the SGML standard itself has levels of conformance
defined. Many light-weight browsers could limit themselves to one
particular DTD, or exclude some features of SGML to simplify parsing,
but even this, I feel will be unnecessary. If someone took SGMLS and
cleaned it up, and connected the output to a rendering system, we
would have a pretty good system, at the cost of probably 250k. Now if
the browsers used only HTTP, a lot of the lower-level protocol layer
could be removed, *removing* 250k. We're even. Other protocol types
*could* be handled outside the browser...
Bo Frese Rasmussen <bfrasmus@eso.org> writes:
>- No you are not missing anything here.... It certainly is a problem
>that the HTTPD server are stateless, and not a problem that are easily
>overcome. - Sure you can make a 'hack', and make something that
>simulates a 'true' interactive session with state information retained
>etc., but HTTPD just wasn't designed to do these things.
>
>In order to truly overcome these problems I think we need to invent a
>new protocol. Something that would allow us to have more detailed
>interaction, like not having to repaint the entire screen each time
>something needs to be represented to the user, etc.. Something along the
>lines of Mosaic<->HTTPD, where you have a generic client that will work
>with whatever services provided on the net, without the need to download
>and install any additional programs. I guess you could view this as a
>higher level X protocol, or a lower level HTTP protocol (closer to the
>HTTP)
I agree that a more "heavyweight" protocol for online odocument
delivery is desired. For a lot of commercial publishers, the
connection time penalty will become a serious problem. However, I do
not think that a lower-level protocol for screen display is needed.
All that is needed is more intelligent renderers. Beside, there are
half a dozen protocols for distributed graphics (NAPLS, RFC??? etc.).
With intelligent renderers, stylesheets, arbitray DTD's, pay-per-use,
and encryption, etc. the WWW will live a long life indeed. Without all
of these, I feel it will never live up to it's full potential.
>The idea is to make a simple HTTP script that works as a dispatcher - that
>is : On first connection it would assign a unique id to the user, and start
What happens when each of these scripts invokes a multi-megabyte
frontend? Every time a connection over HTTP comes in, we reexecute it.
There *are* ways around this, but I think they feel kludgy.
>hallam@dxal18.cern.ch (HALLAM-BAKER Phillip)
>OK first off re keeping the layers separate, very good point. Before we put
>security enhancements or rather enhancements for security into HTML we
>have to put them into the transport layer. Both Dave Ragget and
>myself
I addressed this earlier. All I asked for was a *negotiation*
protocol. Nothing more.
>The issue of style sheets is `defered' we want to look at them but the
>form they take cannot be decided until we have got a few less balls in the
>air. NB DTDs are no damn use as they stand for this purpose. They define
>document structure, not presentation.
Correct, that is why they *are* "damned usable". By defining *only*
structure, they are formatting independent, meaning you can *present*
that data any way you please. The *presentation* is usually defined by
a *style sheet*, bringing us a full circle. One of the *worste* parts
of HTML is that it defines *presentation*, meaning that every document
on the Internet in HTML relies upon the formatting properties of HTML,
and must be updated if those semantics change. You must be pacing
problems now where you have to maintain backward compatibility with
older documents in HTML+. If HTML had defined structure, and a
"default" stylesheet, that problem would not be anywhere near so
great, particularly if the browsers understood arbitrary DTD's, and
stylesheets associated with them. There are a lot of people out there
with *huge* amount of data (800,000 pages is common), and they want to
be able to analyse that data using the structure of SGML (searches are
fast too), you don't get *that* with HTML. My question, as always, is
simply: why go for a restricted solution to a problem, when, with
slightly more work, one could go for a truly general solution? It's
kind of like the story of the doctor in India: She saw a drowning man
in the river, swam out, and brought him to shore, then 2 men came
down the river, she swam out, and saved them too, then 4 men, then 16
men, and she was so busy saving people, she never did manage to stop
the person throwing the men into the river.
>There are some changes required to HTML+ for security. These include the
>use of logos and trademarks in a defined area that does not scroll. We
>also have to support writing "Top Secret" or "Confidential" in this area.
>The linking of DNs to trademarks is an issue.
How about areas of text visible only to those who should see it? Do
you send it across the wire, and use an attribute to tell the browser
to hide it, or do you ask the server not to send it? In the former
case, we need encryption, in the later, SGML aware servers...
>Whenever you get a copy of WiReD you know it is genuine because it has the
>trademark stamped on the front cover. Misuse of a trademark is a criminal
>act in many countries when the intent is counterfeiting.
Do you think this will stop people from copying it? I remember well
the days when most software came with copy protection, and people
spent *weeks* breaking it, and then distributing copies. On a network
of 20,000,000 people, do you think trademarks will work? How about in
countries where there are no laws, or where the government just
doesn't care?
I'm sorry if I come over a bit strong, but I feel the WWW could be one
of the most important things to have ever come along, but I feel that
it is has surpassed anyone's wildest dreams with it's success, and if
some problems aren't fixed soon, we might be stuck with them for
good... it's full of so many possibilities, let's not waste them.
My hat *does* go off to all have have brought the net this far, and it
will be ready for those who take it further.
nick
PS. These are my *personal* views, not EBT's.