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


To: Joseph Reagle <reagle@w3.org>
cc: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, Edward Lewis <edlewis@arin.net>, public-p3p-spec@w3.org, ietf-provreg@cafax.se, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Fri, 11 Apr 2003 06:20:59 -0400
In-Reply-To: Your message of "Wed, 09 Apr 2003 17:09:13 EDT." <200304091709.13377.reagle@w3.org>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol

> If the initial data collection had a particular policy (P3P)

This may be a theory-of-foo bump, or it may be a slow moving armidillo, but
data originates at a registrar.

We (epp-hat==1) aren't designing the registrar's UI.

> ... wouldn't it be 
> best to pass on the initial P3P agreed to, with the data, when ...

This is an aside, but (you asked for it). A party interposes on the data
flow between source and sink, and edits the data. Is policy unaffected by
the transform? I gave this a lot of thought before, and after, the joint
WAPF/W3C meeting in Munich (Dec 1999), and concluded that proof of closure
was not trivial.

For the IETFers, take a look at any of the three cache BoF/WGs that came
out two years ago -- there was a reason why Mark Nottingham (co-chair, WEBI)
attended our f2f at IETF-51 (London), and it wasn't just because we were
then both contributors to the W3C's P3P Spec WG.

Of these, only Leslie's considered the possibility that cached content
was policied (in an IRTF-IDRM-esque fashion) before it was transformed
for edge device delivery.

For the P3Pers, consider a nice bit of html with a nice p3p statement in
the usual WKL. It is accessed via a WAP device, and transformed by some
WAP content management cache for "last mile" lower bandwidth link reasons,
and additional operator policy goals ("walled garden"). How does an user's
p3p evaluation engine evaluate the delivered p3p statement(s)?

Anyway, we don't know that there was a p3p statement when the data was
initially collected by the agent/reseller/registrar. What we do know is
that a registrar is surrendering, and possibly retaining, data, and a
registry is collecting, and possibly discarding, data.

> when it is distributed to those with the "same" policies?

But it isn't. There are several adminstrative or jurisdictional policies
that the registrar-collected data might be provisioned (onward-transported)
to, and the registries may be unable, under the distinct operational and/or
policy regimes they operate under, to accept some registrar-collected data,
regardless of the policy under which that data was collected.

...

> I didn't follow this bit.

Assume no one has any use for 95/46/ec, or the OECD Guidelines, or the FTC
rule-of-the-day (generally, policy on collectors), and only wants raw read
and write access on the registries, and a trap on read-requests by other,
to interpose a write (or its static equivalent, some sort of mask), for a
registrant (user), and/or his/her cluefull agency.

Now (epp-hat==1) and (p3p-hat==1) are very, very far apart. Sailing on
different currents altogether, and diverging too.

Fortunately, this [1] shows that the problem is minor. Also, the ICANN
Registrars may be limiting whois (both bulk and :43) more effectively
than we (PROVREG +/- IESG) are.

Cheers,
Eric

[1] http://www.cdt.org/speech/spam/030319spamreport.pdf

Home | Date list | Subject list