To:
Andrew Sullivan <andrew@libertyrms.info>
cc:
"'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Tue, 22 Oct 2002 11:18:57 -0400
Content-ID:
<10632.1035299936.1@nic-naa.net>
In-Reply-To:
Your message of "Tue, 22 Oct 2002 10:23:33 EDT." <20021022102333.A4016@mail.libertyrms.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: "private" Element Attribute
Andrew, The <access> element asserts that the collector allows the originator read-access to some datum. Now P3P doesn't actually specify how this is provided, and hence how the originator could detect a policy other than the assertion made in the <access> element, that is, if <all/> were stated, and the originator found that the actual read-access was <none/>, we've no way of knowing, let alone attempting to "enforce" the <all/> assertion. We are graced with <info>, so we actually can use <access> and <info> to enforce data consistency within the EPP provisioning chain. When a registrant changes her contact data, she can <push> that delta on the registry (and possibly registrar) records, so she and not the registry is the authoritative holder of the data, and the upstreams (registrars and registries) simply consistent caches of her contact data. So, unlike P3P for web sites (and cookies and Xforms and ...), we can move beyond announcement to announcment plus evaluation of the truth value of the announcement (for some things), which is necessary to enable any form of protocol-based enforcement (as opposed to dumping lawyers on the target registry from some reasonable altitude). Earlier Dan asked if anyone was implementing <dcp>. I haven't looked at your client code in ages, are you? Eric