Re: TSP interop update

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Peter,

> > >   "The reqPolicy field, if included, indicates the TSA policy under
> > >    which the TimeStampToken SHOULD be provided."
> >
> > If the server does not support the policy, we cannot force the server to
> > support it, and hence why SHALL cannot be simply substituted. In order
> > to be more explicit we could say:
> >
> >    The reqPolicy field, if included, indicates the TSA policy under
> >    which the TimeStampToken SHALL be issued (provided that policy is
> >    supported by the server).
> >
> Your sentence essentially contains just a substitution of SHOULD by SHALL.
> Your reasoning of why SHOULD cannot be replavced by SHALL doesn't
> make sense, since for example a TSA can always decide not to return a
> token simply because it doesn't like the client or 'time source not available'
> and there are still MUSTs for many othre cases like a nonce for example,
> you cannot "force" a TSA to return a Nonce of 1megaoctets, the text
> concerning nonce still says  'MUST be identical'.
> 
> 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."

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 ? 
Just to annoy the client ?

Denis