Re: Requesting comments on draft-cheney-safe-02.txt

["Peter J. Holzer" <[e-mail]>]

On 2009-08-01 09:56:55 +0400, Cheney, Edward A SSG RES USAR USARC wrote:
> > I think you mix up HTTP and client-side scripting. HTTP is only a
> > protocol to send and request data.
> 
> > Therefore I don't think you gain anything by using SMTP instead of
> > HTTP as the transport protocol.
> 
> The problem only exists in the realm of HTTP due to where code actually
> executes for interaction.  HTTP is certainly not part of the problem,
> but it also cannot be a part of the solution due to the simplicity of
> its design.

What aspect of SMTP makes is superior to HTTP in this regard?

> In the WWW all interactive code executes at the user-agent
> software.  This software is written by a stranger to the local user who
> has absolutely no ability to verify the integrity of the code until
> after it has executed.  The user-agent cannot even control if the code
> executes automatically upon rendering of the page except to completely
> disable execution of all client-side code.

The last sentence is wrong (some browsers do implement ways to restrict
client-side codes by different criteria), and in any case that doesn't
seem to have anything to do with the protocol used to fetch the
(executable) contents: Neither HTTP nor SMTP care about the contents,
they just transport a header and a blob of data.

> > What is gained by adding intermediate systems?
> Intermediate systems offer a point of execution for code

You are contradicting yourself:

> 2) The server that owns the code is the exact point of execution for
> that code.

So the code is not executed on one of the intermediate systems but on
the server which hosts the code. The intermediate systems just pass
through messages.


> Technically speaking HTTP is also unidirectional.  HTTP typically
> operates with a GET request

The POST request is also well-known and frequently used.

> for a resource on a server and the server responds with that resource.
> Since logic is not capable of being passed into that GET request HTTP
> is unidirectional as a result.

No, because the POST request exists. It is both possible for the client
to send complex data to the server and for the server to send complex
data to the client. The only thing that is missing is a way for the
server to pass data to the client asynchronously (well, HTTP push
exists, but it was never used much) so the client needs to poll. But
that's only a minor problem which can easily be worked around.

> The solution to HTTP unidirectionality is the XMLHttpRequest object.
> SMTP is also unidirectional.  My solution for SMTP is the XMLSmtpPush
> object.
> 
> > With your model, how would this be handled?
> 
> In your example the code would execute using HTML's onkeyup event.  The
> limitation of this model is that event oriented execution is not
> allowed.

If you don't allow user-triggered events to be processed, what is the
advantage compared to traditional server-side scripting? 

As somebody else already asked: What would be a typical use case for
your protocol?

	hp

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [e-mail]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [e-mail]