|>On Sun, 29 May 1994, Gavin Nicol wrote:
|>(Quoting Phillip Hallam-Baker)
|>> >Keeping it simple while still allowing powerful expression is the
|>> >objective. It is not our aim to produce a spec that is simple through
|>> >not being functional. We want to be both functional and simple.
|>>
|>> 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.
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
are working on the security side as well as the HTML+ side so we are
aware of the issues, state of play etc.
The issues of authentification etc should be the subject of some RFC proposals
in the near future. For a preview of Shen see :-
http://alephinfo.cern.ch/AL2F01$DKA100/hallam/INFOGEN/SECURITY/REF/security_spec.html
NB the scope of Shen is very much wider than just HTTP or HTML. The
idea is to provide the security support required for non browser
applications.
|>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?
|>Additionally, the level of programming browsers would need to properly
|>display arbitrary DTD's would be huge, and these browsers are big enough
|>already.
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.
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.
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.
|>> For
|>> example: Say Encyclopedia Britannica was online. How could they charge
|>> people for using it?
|>
|>Actually, they are setting up an online service (www.eb.com?). I
|>think the model they are using is to sell the service to institutions
|>(universities, etc) and use access control restricted to
|>*.berkeley.edu, for example. However, if any server in that domain
|>has open proxying supported (as the CERN server does - does NCSA's?)
|>then *anyone* can get that information, as the proxy service is open
|>to anyone (or is it configurable?).
There will be support for prohibit copy, prohibit cache etc.
|> I see this as analogous to the
|>easily-forgeable sendmail problem awhile back, which was solved via
|>the enlightened self-interest of the sendmail authors to enable
|>complete tracing, so that unauthenticated mail could never be fully
|>anonymous.
Errrm sorry, it is quite possible to forge non traceable mail but I'm
not going to let on how.
|> Hopefully a similar solution will become available for
|>proxy servers - the best solution I can think of is to simply pass
|>along the name of the originating host, or perhaps even the complete
|>path. If this is currently in the HTTP spec let me know.
The issue of support for proxying etc is being thought of but we are
not there yet. The big question is about the level of trust you place
in the client. In any copyright protection system you have to put some
faith in the user and client.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.