[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list