[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TSA messages for http ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Peter,
> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx]
> Sent: Mittwoch, 14. November 2001 11:33
> To: Peter.Sylvester@xxxxxxxxxx; st@xxxxxxxxxxxxxxxxxxxxxxx;
> ietf-pkix@xxxxxxxxxxxx; 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: cristian.marinescu@xxxxxxxxxx
WWW: www.omicron.at
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2i
iQA/AwUBO/JFy8V5iyNCxCiSEQLCPwCg27ncNaW8pKtaqaWFPYzmmkegKf0AoPF1
xl9BK9KlawrDX5cy05IPNMOf
=uG5a
-----END PGP SIGNATURE-----