Subject: RE: "private" Element Attribute

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 21 Oct 2002 11:00:44 -0400

> -----Original Message-----
> From: janusz sienkiewicz [mailto:[email-masked]]
> Sent: Monday, October 21, 2002 10:59 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: "private" Element Attribute
> 
> 
> Wouldn't it be more convenient to redefine private attribute 
> as enumeration
> versus boolean? For example:
> 
> <contact:email private="true">[email-masked]</contact:email>
> 
> could be replaced by:
> 
> <contact:email access=enumValue>[email-masked]</contact:email>
> 
> Where enumValue could be: private, public, noWhois, etc.
> 
> Among other petential benefits this approach could eliminate 
> the inconvenience
> of using <extension>.

There's no real benefit to an enumeration because to add new elements to the
enumeration we'd have to rev the protocol -- we can't extend enumerations.
using the extension mechanism means we can add new elements, policies, etc.
without having to produce a new version of the protocol.

Plus, we'd have to agree on all of the possible enumeration elements and
then we'd still be left with no room for extension without revising the
protocol.  We tried talking through identification of policy elements some
time ago when we talked about privacy requirements, and we got nowhere.  The
results of that discussion is in the archives somewhere.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 21 Oct 2002 12:22:40 -0400

> Would "private" object elements appear to non-sponsoring entities
> (Registrars) when they issue the "info" command?

If the client has the authInfo I think this is fine.  The restriction would
be better phrased as "do not disclose to unauthorized third parties".

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 23 Oct 2002 08:49:17 -0400

> On Tue, Oct 22, 2002 at 09:50:57AM -0400,
>  Eric Brunner-Williams in Portland Maine <[email-masked]> wrote 
>  a message of 68 lines which said:
> 
> > Please see the discussion of the data collection policy 
> <dcp> element,
> > in the -07 draft. This stuff got formalized for us around the London
> > meeting.
> 
> I was not there and I find nothing in the mailing list archive.

You need to look a little bit deeper.  Here are some pointers:

http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00108.html

http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html

http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00040.html

http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00165.html

There's more, but I'm sure you can find them yourself if you look towards
the end of 2001 more closely.

> <dcp> has exactly the same problem: while it acknowledges the work of
> the P3P WG, it tries to reinvent P3P, instead of using it. At the cost
> of great complexity, EPP uses the whole XML zoo, including the ability
> to add any XML element (not just those specified in EPP) in an EPP
> element. Why not use <POLICY> and not <dcp>?

It's not trying to reinvent P3P at all -- it uses a subset of P3P that makes
sense in a different (that is, not web-based) operating environment.  All of
P3P just isn't appropriate for what we're doing.

"dcp" is an acronym for "Data Collection Policy".  "policy" by itself is too
vague a term to use in this context.

-Scott-