Subject: RE: TSA messages for http ?

From: Cristian Marinescu <[email-masked]>
Date: Mon, 12 Nov 2001 09:50:42 +0100

Hello!

I am having the same problem. We have implemented
a socket-based server and client, and now we are
trying to offer some HTTP support, too. The main problem
is that, behind the WWW server (because I would like to
use IIS and Apache), I would definitively forward the
request to the socket-based TSA. The problem is that
in such cases, if I would configure the servlet to use
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...
The standard is not suggesting any answer to this question.
What would you do? (And BTW, Todd, please send me your pdf,
I would be interested...)

Any comments are highly appreciated,
Cristian

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

> -----Original Message-----
> From: S.T. Wong [mailto:[email-masked]]
> Sent: Freitag, 9. November 2001 08:44
> To: [email-masked]
> Subject: TSA messages for http ?
> 
> 
> 
> Hi, there,
> 
> As mentioned in RFC3161, in socket based protocol TCP-based 
> TSA messages,
> which consist of triplet of (length, flag, value), are used 
> to communicate
> between the request initiator and listener.  If functions 
> (like polling 
> requests) are implemented on other protocols (e.g. SMTP, FTP, 
> HTTP, etc), can 
> we simply make use of such TSA message triplets ?    
> 
> Would anyone please advise ?
> Thanks a lot.
> 
> ST Wong
> 
> -- 
> S.T. Wong                               | Email: [email-masked]
>

---

From: Cristian Marinescu <[email-masked]>
Date: Tue, 13 Nov 2001 09:37:18 +0100

Hello!

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Montag, 12. November 2001 16:42
> To: [email-masked]; [email-masked]; Cristian
> Marinescu
> Subject: RE: TSA messages for http ?
> 
> 
> 
> 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. 
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...

<snip>
    pollRep        '01'H    polling reference (32 bits),
                            time-to-check-back (32 bits)
      -- poll response where no TSA message response ready; use
polling
      -- reference value (and estimated time value) for later polling
...
    partialMsgRep  '04'H    next polling reference (32 bits),
                            time-to-check-back (32 bits),
                            DER-encoded TSA message
      -- partial response (receipt) to initial message plus new
polling 
      -- reference (and estimated time value) to use to get next part
of
      -- response
</snip>

Kindly regards,
Cristian

=====================

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 14 Nov 2001 13:18:23 +0100 (MET)

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

Its not me, but someone else :-)

The direct socket protocol has its origin in CMP. It is not
100% clear why it is in TSP. The texts of chapter 5.2 of RFC2510
and 3.3 of RFC3161 are stil quite similar. 

In the general model if TSP you don't have an 'initial TSP message', 
there is just a request/response. I am not convinced
at all that the socket protocol had been added because it
is useful (I can be wrong), but rather to have at least TWO
reasonable transport protocols (HTTP and another one).
There was alomost no discussion about the socket protocol
in the context of TSP. in fact, the protocol itself is 
incompletely defined. You don't know whether and who may
close a connection. 

I don't care about the socket "protocol" on a WAN level, you
may need proxy logics etc. (a CONNECT method for example in clients,
which would turn you almost into an HTTP client.) 

Note also that there is no way to correctly add a 
subjectInformationAccess for that protocol if You don't want to use 
the default port. 

I have the feeling that people are implementing it just because
it is simpler than HTTP to make a "prototype". 
I have seen single threaded implementations of servers, 
I have seen servers that do not time out on connections
and I don't know what else. decoding and coding the two PDUs
is just the small part of a service.

> > 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
I am not making assumptions.

> something else: why not define a simple, but effective standard,
> if we can have a complicated one?   :)
I see You know the shadoks :-)
I tend to agree with You. BUT: You first have to define the
problem, use cases, a problem space, definitions, etc. 
Note for example that there is actually another draft
about 'timestamps'.   

> But I think that the discussion won't bring us too much, now
> after the standard has been released. So just forget about it.
RFC3161 is NOT A STANDARD. It is an RFC with status 'PROPOSED STANDARD'. 
It may well be that one gets rid of inappropriate stuff as a quite
normal activity in the process.

> 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.
So just choose something.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 14 Nov 2001 11:32:56 +0100 (MET)

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

> This doesn't sound like a good solution...

Aren't you describing a garbage in/garbage out situation? 

Why don't You want to wait 10-60 seconds? because there
may actually be a MIM attack? 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.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 12 Nov 2001 16:42:02 +0100 (MET)

---

From: "todd glassey" <[email-masked]>
Date: Sat, 10 Nov 2001 06:21:11 -0800

Has anyone looked at integrating timestamping into XDAS. The XDAS
specification is much more stable that the TSP and would allow any UNIX
System or XDAS Compliant logging infrastructure to use the time stamp call
structures to reinforce the XDAS Logging Content.

This is a real world use model for the TSP (yuk - I am proposing it,
ewwwwww.) Oh well - anyway. For the TSP to really get some use it still
needs a couple of things like a reason for being used in the first place.

One use I would like to propose is as an addition to the OpenGroup's XDAS
Protocol. I have secured formal permission from the OpenGroup to submit that
as a proposed extension to both the xDAS protocol and the TSP.

My gut level feeling is that by bundling the missing pieces of the TSP
proposal together with the TSP itself  (that being some time management
process and an embedded application to use the TSP)  this protocol might get
some traction.

If you would like to see the xDAS draft send me some email and I will blast
off a copy to you. Its a 360kb PDF File at this time.

Todd

----- Original Message -----
From: "S.T. Wong" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 08, 2001 11:44 PM
Subject: TSA messages for http ?

>
> Hi, there,
>
> As mentioned in RFC3161, in socket based protocol TCP-based TSA messages,
> which consist of triplet of (length, flag, value), are used to communicate
> between the request initiator and listener.  If functions (like polling
> requests) are implemented on other protocols (e.g. SMTP, FTP, HTTP, etc),
can