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


To: ross@tucows.com
cc: ietf-provreg@cafax.se, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Tue, 15 Apr 2003 18:52:11 -0400
In-Reply-To: Your message of "Tue, 15 Apr 2003 18:12:27 EDT." <00e701c3039c$195358e0$f80b000a@rraderxp>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] Proposed Text for Contact Mapping Disclosure Elements


I don't mind a mechanism existing for "secrecy", but I do mind calling it
"privacy".

Four years ago, when I started work in this area, not all of it in PROVREG,
some was in the presence-related WGs, some in HTTP, some in the W3C's P3P
Spec WG, and some in CPEx, every knee-jerk half-wit in the IESG said before
a regular-sized sombrero could hit the floor (falling from head-height in
normal gravity and an intellectual vaccum) that "privacy" was part of
"security" (and that if the data was encrypted, why that solved everything).

In the last year I haven't heard that sound-bite, so for all the dreck this
is, there is some progress -- the issue isn't just evesdropping, it is the
use and more that the intended recipients put to the data they acquire.

So, if a mechanism to partition the read-access on a repository is desired,
and general, that part that meets the policy meta-requirement for "privacy"
(and data protection) can be packaged as "privacy" (and dcp). That part that
meets other policy reqiurements can be packaged as "other".

Eric

Home | Date list | Subject list