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-