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


To: "'Stephane Bortzmeyer'" <bortzmeyer@nic.fr>
Cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Tue, 22 Oct 2002 12:56:54 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: "private" Element Attribute

> I suggest instead to rely on a function of EPP: the fact that you can
> include XML elements which are not in the official schema. For
> instance, P3P <URL:http://www.w3.org/TR/P3P/> elements could be added
> in the EPP flow from the registry to the registrar and APPEL elements
> from the registrar to the registry.
> 
> That way, we would build on an existing and documented and recognized
> and quite comprehensive framework (managing its privacy preferences is
> complicated enough that we do not introduce a new framework).

As Eric has already replied, we already have data collection policy elements
in the core protocol.  I'm not familiar with APPEL; could you provide a
pointer?

My biggest concern in reopening this debate is that we don't get bogged down
again in debates about how one jurisdiction's privacy policy has to be
ingrained in the protocol.  I firmly believe that our obligation is to
ensure that the protocol provides functionality that provides flexibility
for the expression of multiple privacy policies and privacy preferences.  I
thought we had that going into the IESG review with the current extension
mechanism (though it might not be explained well (or not at all) in the
current text), but one IESG member initially suggested a need to provide
element-level granularity.  We still have a responsibility to keep the
mechanism as policy-neutral as possible, which is where the proposal I
floated yesterday came from.

-Scott-

Home | Date list | Subject list