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

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> > - 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 ;-).  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?

> > 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?

-Scott-