ietf-smtp
[Top] [All Lists]

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

2009-08-01 18:56:23
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.
| |   | hjp(_at_)hjp(_dot_)at         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on 
community(_at_)lists(_dot_)openmoko(_dot_)org

Attachment: signature.asc
Description: Digital signature