To:
Daniel Manley <dmanley@tucows.com>
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, 31 Jul 2001 11:24:15 -0400
In-Reply-To:
Your message of "Mon, 30 Jul 2001 12:47:48 EDT." <3B658FB4.5010208@tucows.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: Data Collection Requirements
Dan, I'm glad you took the time to read Scott's note of the 5th, and you've clearly given the issue some thought. If you missed my reply to Scott, also of the 5th, it is in the archives. Just to be clear, Scott proposed changing "data" to "social data", and "policies" to "preferences". Scott also reiterated his belief that data collection policy will be signaled out-of-band, e.g., by contract. Some minor remarks specific to your note: > In terms of web sites, because of ... [baroque richness] > But with registries and the limited (snip) data [leave as "data" for now] Agreed, the P3P schema and vocabulary are a model, not the answer to be applied thoughtlessly. That was part of my purpose in mentioning another protocol which performs onward-transport of consumer social data. I gave the reference in my reply to Scott on this list. > EPP could define a configurable set of policies Yup. Ditto for XRP, ... > Each registry could set defaults ... Yup. > Registrars would be told of the settings ... Yup. Scope is now registry-global. (registrars to resellers to reresellers ...) > (via contracts and published policies of the regsitry) That's one way. Out-of-band announcement. Optional. See your next. > and could attempt to set global preferences on login (maybe with the login > command or a separate command) Yup. Amounts to negociation, over a fairly limited range of discreet values. Scope is now registrar-global. > For the sake of completeness, there could be a (policy):info command. Yup. That's one way. Paren denotes s/preference/policy/ > Each contact would also have privacy (policy) attached because ... Yup. Scope is now registrant. Paren denotes s/preference/policy/ > I just don't think that (snip) data privacy with EPP registries should > be a big black cloud (snip). There's limited data and > controlled audiences (registry/registrars) involved so the policies > surround that should be simple. Yup. I've snip'd out the parts that aren't necessary to the core problem of provisioning policy meta-data. This leaves Scott's two changes, s/data/social &/, and s/policy/preference/. Cheers, Eric