Subject: Re: Experimental TSA

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Oct 2000 16:56:30 +0200 (MET DST)

> > The TimeStamp protocol  doesn't require to leave the connection open for
> > other possible requests after the first has been processed.

We are not talking about the time stamp protocol, but about transport
protocols that are used to exchange queries and replies. 

> 
> Doesn't require, but doesn't restrain either.
Right.

The question is what happens in clients that have been developped by
the same group that always close a connection. Do these clients just
read the n octects returned and process and then finish, or will they
block, in trying to read data, or?  

> What's more :
>   There is no mandatory transport mechanism for TSA messages in this
>   document.  The mechanisms described below are optional; additional
>   optional mechanisms may be defined in the future.
> 
> > So if you want to send many requests at the time you need to do many connections.
> >
> > We could provide some extension payload to the socket based  protocol
> > to support multiple requests in a single packet (modifying the actual draft, but I
> > do not think this is the right time to do that).
> 
> Nothing restrains the client and the authority to have an agreement to exchange
> several messages in a row in the current proposal.
> The problem is that with the current protocol, the client and the TSA need to agree on
> that out of band.
> 
> This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
> 1.0 to an HTTP 1.1 request and close the connexion.
> 
> The only difference here is that the client has no way to tell explicitly the TSA that
> he wishes to keep the connexion open after the first message.

Note what had been said in 

      draft-ietf-pkix-cmp-transport-protocols-00.txt

1. Motivation

  Section 5 of the [RFC2510] spec specifies sending the DER-encoded
  CMP message directly over various protocols. However, implementors,
  during various interoperability workshops, found the protocol
  lacking in the following respects:

  1.	No clear definition on when the connection is to be closed
	and by whom.
  2.	No version number specified to allow for extensions.
  3.	Error messages cannot be processed by applications.

  Realizing that this could not be achieved in a backward compatible
  way, and acknowledging the changes being made to [RFC2510], the
  decision was made to enhance the protocol now to avoid
  interoperability conflicts later and to pull the transport section
  out in a separate draft. This enhancement tries to keep as much of
  the older protocol as possible, while ensuring that implementations
  using the old protocol will not mistake a new message for a valid
  message in the [RFC2510] format.

At least we have the SAME situation as in 1. here in this discussion. 

> That means a TSA that's able to handle another request on the same connexion, has to
> leave the connexion open after sending the answer and watch if the client decides to
> close it.
It could leave the connexion open for a certain time, just as in a http
keep alive, or actualy one could implement the technique proposed in the
draft mentioned above. 

It was an error anyway not just simply reference 2510. That's history.
 
> The client just has to check if the connexion is still open before sending the second
> message.
This is normal error handling.

> This seems to me to work quite well, even if it's not as elegant as explicitly telling
> whether there will be several messages or not.

This is similar to the question whether for example pipelining would be allowed
in some way or another. Actually a client can also simply open several channels.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 13 Oct 2000 12:00:46 +0200

>   2.    No version number specified to allow for extensions.

You can define new values for the request flag, etc...
But it's not very sure how the server that doesn't understand it, will react (close the
connection, send an error message with flag 6 and leave the connection open, etc...)

>   3.    Error messages cannot be processed by applications.

Answer with flag value "6" is an error message.
The error message can be also in the status.

>   At least we have the SAME situation as in 1. here in this discussion.

About the same. A separate RFC for that would be better of course.

> This is normal error handling.

That's my point.

Most of the "problems" that occurs in that case are things that _could_ also happen if the
protocol did define whether there will be several messages or not.

The only actual difference is that the server has to wait a time-out interval after sending
the answer, so some ressources are used a little more than necessary.
Under normal circumstances , I think this time-out interval could be something around 10 or
20 seconds.
I don't believe this is the performance bottle-neck of the server, if it's properly
configured with a large number of sockets.

I'm not saying the protocol is perfect.

I just think that from the previous discussion it is clear there will be no major chance in
the draft anymore.

Therefore it's more constructive to see if there's a way to work around these problems, and
what should be the best way for that, than to simply complain.