Re: "private" Element Attribute

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

> I knew I was going to regret reopening this issue, but the IESG hasn't
> bought the "we've been through this and what you see is what we came up
> with" argument.

It could be worse. when I attempted to assist a current and former member
of that august body on a memo on the mechanism for http state management,
their responses were something along the lines of "we don't need help, we
are the IESG", or something significantly less cheritable.

Before we take our first step down this bunny trail we need to know if what
we are creating a mechanism for is a policy assertion by a registrant, or a
registry, or some intermediary, AND, if the policy can be observed in its
instantiation. The exection value of a "Do/Will not give FOO to Martians"
policy claim, wheather by the source of FOO or the sink of FOO is slightly
harder to evaluate than "Do not s/FOO/BAR/", at least in the case where the
source has access to the sink sufficient to detect non-tampering with FOO.

Now I think that adding these to <recipient> are sensible:

	<dns/>	(after all, that was the point, neh?)
	<whois>	(possibly several permutations, ARIN just published theirs
		 today, e.g., :43, uwho, arin, ripe, ++, ...)

I'm open to revisiting the <dcp>, so that it is no longer an announcement
mechanism for data collectors, but something that has manditory error
semantics (if present), e.g.,

	<contact:email private="true">jdoe@example.com</contact:email>

causes a server error condition if the server-registry announced (regardless
of the scope of the announcement, a seperate topic) <dcp> is inconsistent
with the user-registrant asserted (new term) "data surrender policy" <dsp>.

Which default for no <dcp> (it is optional after all) is a choice. It could
mean "do whatever the user asserts", or "ignore asserts". The better choice
may be to make the <dcp> manditory, then deal with <dsp> != <dcp> cases.

I think this is a way to meet this:

	... what is missing is a mechanism for a user/registrant/etc. to
	flag individual elements that need to be protected in accordance
	with some stated policy.

Now we just need to decide if this is the protocol's job with the server
performing detection and enforcment (see error, above), or if the protocol's
job is to transport data which has access control, independent of the server.

	Blanket acceptance of whatever the stated policy might be doesn't
	appear to address their concern.

Error semantics give them what they need.

I'm at a loss to figure out why granularity smaller than the social/technial
split on the contact object is something Randy/Patrik/... are keen on.


Just to keep a straight face on the value of privacy, this isn't a function
that anyone appears willing to invest in. I've made $0.00 in the area since
the bubble burst, it seems to be everyone's violin d'ingres.

Oh well, at least the Silverbacks aren't calling it "Security", so some bit
of forward progress has been made since Pittsburg.

Cheers,
Eric

P.S. In P3P-esse, they are asking for a binding form of APPEL. Hence policy
negociation, or at least error semantics.