Subject: RE: TSA messages for http ?

From: Cristian Marinescu <[email-masked]>
Date: Wed, 14 Nov 2001 12:22:05 +0100

Dear Peter,

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Mittwoch, 14. November 2001 11:33
> To: [email-masked]; [email-masked];
> [email-masked]; Cristian Marinescu
> Subject: RE: TSA messages for http ?
> 
> 
> > > 
> > > > another TSA (what is actually quite possible), I would have
> > > > to deal with all the socket-based things like polling,
negative
> > > > reply, etc.
> > > > 
> > > > At the moment, in such cases, I return an error, but well,
> > > > it is not very correct, from my point of view...
> > > IMHO the polling feature in the socket transport protocol is
> > > not a feature of the TSP protocol, if there is a transport
> > > mapper between HTTP and the socket protocol, then the
> > > http server would just waitabit and loop if there are responses
> > > for polling. 
> > > 
> > 
> > Yes, I agree, but this means that a HTTP solution could be
> > quite different from a socket-based solution.
> Not really. In an HTTP transport protocol the client must
> be prepared to handle http error events, location etc. This
> is probably more work that an reaction to a poll request.
> 

Of course, it is possible to hide the polling inside, I am sure,
and I definitively agree, that I should handle just http errors,
location errors, etc.

> > On the other hand, to wait "a little" is no solution.
> > You know exactly that the pollRep and the partialMsgRep include
> > a so-called time to check back. So, at least theoretically,
> > I should wait the specified time (10-20-60 seconds, why not?)
> > and then try again.
> > This doesn't sound like a good solution...
> 
> Aren't you describing a garbage in/garbage out situation? 
> 

Well, don't know, you tell me.   :)

> Why don't You want to wait 10-60 seconds? because there
> may actually be a MIM attack? 

Well, this could be another problem, but at the moment,
I am not so concerned about that. I am more concerned,
because, if I would like to offer a web interface to the
whole thing, the user would get 10-60 seconds a blank screen.
Or a "never ending" progress bar.

Perhaps you are right, perhaps trying to be user-friendly is 
not so important in this case...   :)

> Or, if your HTTP front ends
> policy requires to reply within 10 seconds, then you may 
> want to create an error message saying that the time source is 
> not available.
> 

In fact, I can return an error, but I simply DON'T LIKE
this kind o stuff. You first specify some kind of communication
protocol for socket-based TSP, and than forget about the whole
stuff when it comes to HTTP. Well, I assume that the ideea of the
committee was that a server using HTTP has to return an answer
from the first try, and that's it. Well, in this case, why bother
and do it for the socket-based solution? The developers have to
take such things into account...

> Anyway, if Your TSA that uses the socket protocol has a strange
> behaviour, there is no need to correct this in a HTTP frontend. 
> 

Yeah, right. There is NO strange behaviour, from this point of
view. Well, if you are making such assumptions, let me ask you
something else: why not define a simple, but effective standard,
if we can have a complicated one?   :)
But I think that the discussion won't bring us too much, now
after the standard has been released. So just forget about it.

We have to admit that there are some problems, if we want an HTTP
solution to rely on a socket-based TSA. And there are several
solutions.
The problem is just to choose between them. That's it.

Regards,
Cristian Marinescu

=====================
Dipl-Ing. Cristian Marinescu
Software Developer
OMICRON electronics GmbH
Oberes Ried 1
A-6833 Klaus
AUSTRIA
Tel. +43-5523-507-113
Fax. +43-5523-507-999
E-Mail: [email-masked]
WWW: www.omicron.at

---

From: "todd glassey" <[email-masked]>
Date: Wed, 14 Nov 2001 06:40:36 -0800

SNIP --

> and I definitively agree, that I should handle just http errors,

What about reliable delivery issue? I suggest that over HTTP (TCP) that a
Reliable Delivery Verification Mechanism should also be installed. Look at
what is going on with Syslog-Reliable for more of a model here.

> Well, don't know, you tell me.   :)

Depending on how the TTP is physically connected to the Host, that uses it
this may be true.

> > may actually be a MIM attack?

The real issue with MIM is that if you dont have reliable event completion
and authentication in the transport layer as an evidentiary model there are
lots of holes where an opposing counsel could raise doubt as to the veracity
of the system and the actual completeion of the events. That's why people
like TIBCO had to write their own Middleware transports.

> not so important in this case...   :)

No - User friendly is also important or more importantly USER EXPLAINABLE,
that is some use models needs to be able to be shown to the Users.

> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.0.2i
>
> iQA/AwUBO/JFy8V5iyNCxCiSEQLCPwCg27ncNaW8pKtaqaWFPYzmmkegKf0AoPF1
> xl9BK9KlawrDX5cy05IPNMOf
> =uG5a
> -----END PGP SIGNATURE-----
>