To:
Joseph Reagle <reagle@w3.org>
cc:
"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:
Mon, 07 Apr 2003 20:27:41 -0400
In-Reply-To:
Your message of "Mon, 07 Apr 2003 16:05:53 EDT." <200304071605.53219.reagle@w3.org>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol
Joseph,
> > It's not so much that HTTP was rejected, no one suggested doing it.
>
> Understood.
There is an implementation.
> ACCESS
The vocabulary element(s) in the EPP schema which correspond to the ACCESS
element are not identical to those in the P3P schema.
p3p:nonident - does not collect identified data
epp:null - data is not persistent
The problem-domains are not identical. P3P is concerned with "initial data
collection", EPP is concerned with "onward transport" of data previously
collected.
Comment: Data that moves from one onward-transport node to another may not
be persistent on any particular node. In particular, a registry could sink
part of a data flow (technical data) and discard part of a data flow (social
data).
> DISPUTES
> EPP doesn't support how a dispute can be addressed.
There is no vocabulary element(s) in the EPP schema which correspond to
the DISPUTES-GROUP element, and its child DISPUTES elements.
No requirement in the problem-domain exists.
Comment: There is a regulatory regime that is controlling for a class of
operators, hence of implementors. There is the complement to that class,
which lacks an equivalent single regulatory regime, and may be particular
to each element in that class (ccTLD operators). There is yet another class
for which little activity is present (non-tld operators, non-dns operators,
and non-IANA root dns operatos, if any).
> REMEDIES
> EPP doesn't support this, see question in DISPUTES.
See above.
> NON-IDENTIFIABLE
> EPP doesn't support this, not sure why.
The problem-domains are not identical.
> PURPOSE
> EPP supports p3p:{admin, contact, other} and epp:prov. I can see the PURPOSE
> varying widely across application contexts and I think it makes sense to
> drop and extend from this axes as appropriate.
The comment is not clear.
> REQUIRED
(N.B. An optional child element of PURPOSE. EBW)
1. No requirement in the problem-domain exists for users.
2. No requirement statement for data in the problem-domain is optional.
> RETENTION
> See ACCESS.
See above.
I hope this has helped.
Now for something ... individual.
I advocated the <dcp> construct for this problem domain, because I thought
it the best mechanism to policy the data, and to allow scoped policies.
I've tried to kill whois:43 by several means, stealth, poision, very blunt
instruments (my wit), etc.
Others reject the notion that a protocol with a fixed grammer targeting a
particular application domain, in particular data collection, is of the
slightest use in this problem domain, and insist upon mechanism(s) that
support registrant ("user" in p3p usage) defined access et al models.
As "others" are the IESG, looking at what bits of a data collection vocab
are substantially similar, or dissimilar, across problem domains, may not
be the best use of anyone's time.
I hope this has helped too.
Eric
P.S. It might help to keep things in focus to recall every now and again
just how much, or little, anyone actually pays for "privacy". Indirect
cost recovery models for the internet may be ... historic.