Re: [ietf-provreg] FYI: EPP implementation by the Polish registry

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

> > > - in other environments, it might be OK for the data owner 
> > to say "this is
> > > what I will allow you as server operator to do with the 
> > data I share with
> > > you".  I thought some of the European contributors have 
> > said this sort of
> > > functionality is required under recent European privacy 
> > laws.  This is
> > > something we don't currently have in the protocol.
> > 
> > Disagree. The <dcp> states the purpose, recipients, 
> > access-right (of the data
> > owner), and retention period, of the policed session in which 
> > some data will
> > conditionally flow. For a server to offer <dcp1> ... <dcpN>, 
> > it need only
> > cycle these through a fairly small value-space to find the 
> > least-restrictive
> > policy to which the client (and presumably the registrant) 
> > are willing to
> > accept. APPEL attempts this, and the P3P WG attempted, and 
> > abandoned for 1.0,
> > a negociation or owner-preference signaling mechanism.
> 
> Remembering our original discussions of your data collection policy proposal
> I know you disagree ;-). 

On selection:

	Assume N instances of the server, each offering a distinct
	<dcp> value, or one, cycling through a set of N distinct
	<dcp> values, or N distinct registries, each offering a single
	distinct <dcp> value.

On agency (who selects):

	EPP defines exchanges between registrars and registries, so
	"data owner" (originator) is not a direct actor.

>                        ...  What I'm trying to understand is why some
> implementers and others (including, apparently, the IESG) don't agree that
> it's sufficient.  What's driving the perceived need for a client-delivered
> "do not publish" notification?  Is the spec not clear enough, or is the
> mechanism inadequate?

The <dcp> mechanism is optional. That might be the burr under some blankets.
Flip that bit and test again.

> > > I'm not sure that this is a "pick one or the other" situation,
> > 
> > Disagree. See above. Manditory beats optional (IESG's point), 
> > regardless of
> > utility.
> 
> Well, I agree with that -- the IESG is saying they want to see some sort of
> "mandatory to implement" functionality.  Should we be trying to convince the
> IESG that the DCP features address their concerns, or do we need to add
> something else?

OK. Lets talk about making the <dcp> M2I, and either leaving it at session
scope, and see if anyone can live with it.

Eric