Subject: RE: "private" Element Attribute

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 22 Oct 2002 16:26:22 -0400

> Eric provided one. To summary, APPEL can be seen as the "export
> format" of the privacy preferences that you configured in your Web
> browser. They could be sent to the registry in an EPP flow. Then, the
> registry will have a detailed (much more detailed than a binary
> public/private) knowledge of the user's preferences.

As far as I can tell this doesn't get us to element-level preference
specification unless APPEL-like elements are added to _every_ object
element.  That seems unworkable.

I'll have to poke this concept back at Patrik and Randy to see if a
higher-level preference expression like APPEL addresses their concern.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 22 Oct 2002 17:11:18 -0400

Hmm.

	IE	IIS	EPP-C	EPP-S
or
	Mz	Apache	EPP-C	EPP-S

P3P "native" (before we embraced and extended it) sits ONLY on the IIS and
Apache parts of the onward-transport. With our E+O, it now sits between the
C and S, but not elsewhere. We could MANDATE transparency between the EPP-S
and the instance of IIS-or-Apache so the IE-or-Mz browser could evaluate the
EPP-S policy. I think I know how to do that.

APPEL "native" (?) sits ONLY on the IE/Mz parts of the onward-transport
picture. I'm sure that until I re-read the APPEL spec and talk to Marc
that I don't know enough to usefully apply APPEL to reverse direction.

What problem are we trying to solve?

a. Providing a mechanism for users to announce their preferences?

b. Providing a mechanism for collectors to announce their practices?

c. Providing a mechanism for the expression of applicable law?

d. Providing a mechanism for policy expression which is capable of
test, hence enforcement?

e. Other

I was pretty sure we settled on (c), hence (b), and not on (a). Adding
(d) is interesting. Replacing (b), hence (c), with (a) isn't, IMO. I know
at least one contributor prefered (a) to (b).

Eric

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Oct 2002 14:05:03 +0200

On Tue, Oct 22, 2002 at 05:11:18PM -0400,
 Eric Brunner-Williams in Portland Maine <[email-masked]> wrote 
 a message of 39 lines which said:

> I was pretty sure we settled on (c), hence (b), and not on (a). 

I had a very different feeling. I thought we were trying to work
mostly on a) and secondary on b) (BTW, c) is just a subpart of b). d)
is just impossible.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Oct 2002 14:15:20 +0200

On Tue, Oct 22, 2002 at 04:26:22PM -0400,
 Hollenbeck, Scott <[email-masked]> wrote 

> element.  That seems unworkable.

Yes, it is a difficult issue. We should work at a higher level: when
performing a <contact:create>, the user (probably a registrar acting
on behalf of a registrant which sent to the registrar a set of
preferences) adds *one* APPEL element to the EPP flow (not one to
every <contact:something>).

The registry then tries to map the preferences expressed in APPEL to
its own data schema. More realistic, although a bit ambiguous since
EPP-contact-mapping schema may not be the same as the APPEL base
schema (actually, it is the P3P base schema).