Re: Updated (and hopefully the last) EPP Privacy Proposal

[janusz sienkiewicz <janusz@libertyrms.info>]

"Hollenbeck, Scott" wrote:

> I think I need to add some clarifications to the proposal I sent to the list
> yesterday after reading Joe's and Janusz's comments:
>
> - the IESG has already seen the <doNotDisclose> proposal that I described
> earlier, and they weren't happy with it.  They'd rather see each element
> tagged in some way rather than duplicating elements and/or content in a
> separate structure.
>
> - I should probably have said that "do not disclose" means "do not disclose
> to unauthorized third parties outside the protocol channel".  We already
> have authorization mechanisms in place to deal with query responses; the
> attribute can be just an additional decision point in the server's query
> response policy.
>
> - I'm not suggesting that we get into whois disclosure semantics or any
> other semantics.  The <noWhois> example a provided was just that -- an
> example -- provided to show that application-specific semantics can be
> specified using the extension mechanism that we have in place now.  We're on
> the hook to provide a simple notice that others (like maybe the CRISP WG, in
> the case of whois-like functionality) can use to define application-specific
> semantics.
>
> - XML attributes aren't extensible by design.  Adding semantic meaning can
> be done via extensions.
>
> - If we want to specify a default attribute value for a 'dnd' attribute, it
> MUST be done in the schema because XML Schema requires defaults to be
> specified in the schema.  On the other hand, we could leave the XML
> attribute default out and leave default _behavior_ up to the server operator
> OR we could require that the attribute be present all the time to eliminate
> any ambiguity.  The latter approach might be best to make things perfectly
> clear in case someone who receives the data doesn't know the server's
> default disclosure policy -- like if the optional <dcp> element isn't
> presented.
>

Assuming stateful nature of EPP protocol and planned  changes to the protocol
spec [ds] that are going to make <dcp> element mandatory the first option
brings almost as much clarity as the second one. At the same time the first
option allows simpler XML syntax for default disclosure policy.

[ds]
http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00089.html


>
> Does any of this help make the proposal more clear?  The IESG's concern is
> that we need to specify a simple binary flag -- we don't have to get into
> how that flag should be used by different applications.  They are perfectly
> OK with doing anything beyond the flag in extensions.
>
> -Scott-

Janusz