RE: Question regarding contact:disclose behaviour.

"Hollenbeck, Scott" <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <046F43A8D79C794FA4733814869CDF07018CE537@dul1wnexmb01.vcorp.ad.vrsn.com>
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Klaus Malorny
> Sent: Monday, November 06, 2006 3:46 AM
> To: Alexander Mayrhofer
> Cc: [email protected]; Andreas Papst
> Subject: Re: [ietf-provreg] Question regarding 
> contact:disclose behaviour.
> 
> Alexander Mayrhofer wrote:
> > Hi,
> > 
> > we're moving towards EPP enabling .at, but there is an open question
> > regarding how "contact:disclose" should work (we are going 
> to use that for
> > hiding certain elements in a legacy whois service). Section 
> 2.9 of RFC3733
> > contains the following example about "contact:disclose":
> > 
>  > [...]
> > 
> > I'd appreciate feedback on how that was originally 
> intended, and would like
> > to see some clarifying text about this in 3733bis...
> > 
> > Additionally, i'd like to hear from implementors about 
> their currently
> > implemented policy regarding this - i think it would be 
> very confusing to
> > clients if server behave differently...
> > 
> > thanks,
> > 
> > Alex Mayrhofer
> > nic.at / enum.at
> > 
> 
> 
> Hi Alexander,
> 
> an earlier discussion with Scott revealed to me that the 
> current approach does 
> not allow to set the disclosure of one element and the 
> non-disclosure of another 
> element at the same time. Maybe this is the same that puzzled you.

Within the <contact:disclose> element, that is.  The expectation is that
the dcp element specifies the default policy (be it disclose or not),
and <contact:disclose> specifies the exceptions.  It is thus possible,
for example, to specify a non-disclosure policy for postal address info
using the DCP element while allowing disclosure of an email address
using the <contact:disclose> element.

-Scott-
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.