Subject: Re: Open issue: requester identifier in DPV response

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Apr 2002 17:27:37 +0200 (MET DST)

> > 
> > The protocol MUST allow to provide to the requestor and/or the
> > responder a means to indicate a textual description indicating for example
> > the natuer or reason of the request/response to appear in the
> > result of the response.
> 
> The text from the client is blindly copied in the response. 
> 
> Your are now asking for a *new* requirement that has not been mentioned
> earlier: the inclusion of an optional text field from the server.
> 
> We do not have such a feature in other protocols, like OCSP. There is also a
> danger to apply different semantics on such a field. So I am not in favour
> of adding it.

I don't agree that the server MUST blindly copy anything.

I don't look at the issue from a procedural standpoint but from
the point of the data being produced. 

- The response may contain a textual indication about the reason etc.

- This text may be created by the server or requested by the client
  or modified by the server. 

- It is NOT:  an opaque token from the client that MUST NOT be inspected
  in whatever way by the server.  

> Since you do not propose any specific text change, this text appears to be
> sufficient and in fact is derived from your initial proposed wording. We
> cannot argue for ever about the wording.

As long as you refuse textual changes (two characters + one word) as in 

" The protocol MUST allow to provide to the requestor and/or the
  responder a means to indicate a textual description indicating for example
  the nature or reason of the request/response pair to appear in the
  result of the response. "

I don't know what else I can do. It is somewhat difficult to
anticipate your reaction of splitting each proposal into several ones
while adding additional contraints to the pieces and provide a
text change to that before having even seen what you propose. 
 
I am not in favour of having a requirement that says that something
MUST be blindly copied. 

I am not in favour that the usages of identififers of the clients
and responders MUST be related to authentication. 

IMO this is an overspecification, and, as Russ turned out, some
uses that do relate this to authentication may create a conflict
with the requirements doc. 

> > > This should close the last issue raised during the last call.
> > >
> > 
> > I propose that we add somewhere in the introduction a statement like:
> > 
> >   A protocol feature proposal MUST not be rejected as out of
> >   scope for the sole reason of not having been mentioned in this
> >   requirements document ".
> 
> I would disagree to place such a requirement. If the protocol would allow,
> for example, to ask for flowers at the same time, :-), then I believed that
> such a feature shall be suppressed.

Please read what I have written. You are turning around the argumentation.
There are probably some arguments not to have a flower service in a DPV 
protocol. But they should be indicated. The text does only prohibity someone 
from saying: "We MUST NOT use this protocol because you can also request
flowers and this has not been specified as a requirement." 
 
Peter

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 26 Apr 2002 17:45:58 +0200

Peter,

> I don't agree that the server MUST blindly copy anything.

Please read again the text: "inclusion of an optional text field from the
server". This text is not copied from a client field but created by the
server.

>   or modified by the server.

No. See above. 

> and responders MUST be related to authentication.

 ... otherwise it is a field that has an undefined or an ambiguous
semantics.

 
> flowers and this has not been specified as a requirement."

 ... and for that exact reason, I would suppress the flower request. 
It is not appropriate to overload the protocol for whatever extra reason.
We are not going to say specifiaclly that flower requests support is
inappropriate, otherwise the list would be endless.

This was one of the problems from RFC 3029 (i.e. Data Certification Server
Protocols) that had too many features.

Denis