Re: TSA messages for http ?

["todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>]

SNIP --

>
> 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.

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.

>
>
> > > 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.   :)

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

>
>
> > Why don't You want to wait 10-60 seconds? because there
> > 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.

>
> 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...   :)

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.

>
>
> > 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: cristian.marinescu@xxxxxxxxxx
> WWW: www.omicron.at
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.0.2i
>
> iQA/AwUBO/JFy8V5iyNCxCiSEQLCPwCg27ncNaW8pKtaqaWFPYzmmkegKf0AoPF1
> xl9BK9KlawrDX5cy05IPNMOf
> =uG5a
> -----END PGP SIGNATURE-----
>