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

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Apr 2002 19:12:01 +0200 (MET DST)

> > 
> > - This text may be created by the server or requested by the client
> >   or modified by the server.
> 
> No. See above. 

Thus, you are restricting a potential protocol feature. If a proposal
will allow a client to propose a text, you would consider this
as in conflict with the requirements doc?

>  
> > I am not in favour that the usages of identififers of the clients
> > and responders MUST be related to authentication.
> 
>  ... otherwise it is a field that has an undefined or an ambiguous
> semantics.
Russ and you have proposed that the ID are derived from authenticated
identifiers, it seems that the main difference is that I prefer that
they are matched against information from authentication.  

You propose: 
  "When the request is authenticated, the requestor SHOULD be able, upon
  request, to indicate an identifier to be included in the response. 

What does mean 'SHOULD be able'?  We are talking about requirements for
a protocol. Either the protocol has a feature that can be optionally be
used or it hasn't. 

Why should even an anonymous requester not be allowed to specify an identifier?
As indicated in the followng sentence, a server can always refuse this
nased on the policy etc. 

  How this identifier is matched with the authenticated identity depends 
  on local server conditions and/or the validation policy. The server 
  MAY choose to refuse to include an identifier in the response, or MAY 
  refuse to create a response."

> > 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."
> 
>  ... and for that exact reason, I would suppress the flower request. 
YOU have proposed the flower feature, not me. 

> It is not appropriate to overload the protocol for whatever extra reason.
"Overloading" or making it too heavy is a judgement that should be
weighted against the argument that would be necessary to support any feature. 

> We are not going to say specifiaclly that flower requests support is
> inappropriate, otherwise the list would be endless.

The list of potential useful additional feature is as endless as the
list of useless features. Since you have not proposed a concreate 
protocol feature in a potential protocol, I don't feel that it is
necessary to talk about this. If nobody presents any probably
useless feature in a protocol, why should be waste our time to
establish a list of what would be 'definitely stupid'?

It seems that you will in the future continue to say:
'This is not a requrement' with a new justification 'this is
not in a requirements document'.

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

RFC 3029 does not allow to explicitely request flowers, too bad :-)

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 26 Apr 2002 19:22:28 +0200

Peter,

> as in conflict with the requirements doc?

This feature has *already* been accepted (at least by myself, hopefully by
the WG). 

 
> Why should even an anonymous requester not be allowed to specify an identifier?

 ...  because in that case it would not be anymore a field that reflects an
identifier, but will be a "blind" field. The same field cannot have two
different or even more meanings.

> list of useless features. 

No. We would not make the effort of writing these requirements if we were
going to allow a protocol that supports many other features that are *not*
required.

Denis

> Since you have not proposed a concreate