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


To: "'Joe Abley'" <jabley@isc.org>, "'janusz sienkiewicz'" <janusz@libertyrms.info>
Cc: ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Tue, 31 Dec 2002 08:53:29 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Updated (and hopefully the last) EPP Privacy Proposal

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.

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-

Home | Date list | Subject list