Subject: Re: TSP interop update

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jan 2002 18:14:39 +0100 (MET)

> > Anyway:
> > 
> > My question is not answered: Why had a change to force a policy been made in
> > draft 4. 
> 
> Draft 3 was stating: "The reqPolicy field, if included, indicates the policy
> under which the TimeStampToken should be provided."
> 
> Draft 4 was stating: "The reqPolicy field, if included, indicates the policy
> under which the TimeStampToken should be provided."

This is not the text I am refering to: 

draft 3:
"The policy field MUST indicate the TSAs policy under which the response
 was produced.  

draft 4:

"The policy field MUST indicate the TSAs policy under which the response was 
 produced. If a similar field was present in the TimeStampReq, then it MUST 
 have the same value, otherwise an error (badRequest) MUST be returned. "

I would have expected that the statement that You referenced would have
been changed accordingly, something like:

"The reqPolicy field, if included, indicates the policy
 under which the TimeStampToken SHALL be provided."

In draft 9 this line became: 

"The reqPolicy field, if included, indicates the policy
 under which the TimeStampToken SHOULD be provided."
 
> I do not see any difference, so question is meaningless. 
> 
> > There was no announcement, and it was quite easy to overlook this
> > since in two other places requierments for policy had not been changed.
> >
> > I don't think that it is necessary to have an identical policy.
> 
> It is simmple: if a client requests a policy and if the server supports
> that policy, why should the server choose a different policy ? 
Because the policy may have been replaced by a newer one which is
defined as compatible. 

> Just to annoy the client ?

The text says already that the client MAY ignore the policy, and that
it SHOULD check whether it is acceptable. This seems to be an indication
to me that the initial intension was that a TSA can creat a different
value. 

TSA may change their policies and issue 'compatible ones' with a different
id. Why should one annoy the client and ask for an upgrade? 
The possibility of not having a policy may not be possible because
the TSA supports different sets/classes.  

> Denis
Peter

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 31 Jan 2002 18:58:07 +0100

Peter,

This e-mail finally provides the motivation about your request changes 
about the sentence of the policy request and response.

Why didn't you say it sooner ? This would have save time and e-mails.

You would like the following : when a client asks for a specific policy 
he may get back a different one that is supposed to be "equivalent" 
*in the opinion of the server*. 

I wonder if this will be considered as equivalent in the opinion of the
client as well. I am not in favor of supporting such a feature since it
would open endless disputes. In addition, the client would not even be able
to prove that he got the equivalent policy in response to another one 
and thus would not be able to prove that the server is responsible for 
a misuse.

Denis