Re: contact:disclose clarifications / best practices

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Bernhard Reutner-Fischer
> Sent: Wednesday, January 23, 2013 10:07 AM
> To: Keith Gaughan
> Cc: [email protected]
> Subject: Re: [provreg] contact:disclose clarifications / best practices
> 
> On 23 January 2013 13:20, Keith Gaughan <[email protected]> wrote:
> > On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer
> wrote:
> >
> >> I have questions about contact:disclose.
> >>
> >> 1) How do i correctly handle non-disclosure of all fields of a
> >> contact:info command from a third party via EPP, especially name,
> >> email, addr (city, cc
> >> therein) etc?
> >
> > Are you talking about a <contact:info> request being made against a
> > contact by a registrar other than the owning registrar, and is a
> > <authInfo> element being provided?
> 
> In my example i do not have an authinfo set in the contact, no.
> 
> >
> >> 2) what dummy values should i use for the required fields, what is
> >> best/common practice?
> >
> > If you omit them, the default registry policy is applied [SS2.9]:
> >
> >    A server operator announces a default disclosure policy when
> establishing a
> >    session with a client. [...] When an object is created or updated,
> the client
> >    can specify contact attributes that require exceptional disclosure
> handling
> >    using an OPTIONAL <contact:disclose> element.
> >
> > [SS2.9] http://tools.ietf.org/html/rfc5733#section-2.9
> >
> > Thus, a good default is to comit the <contact:disclose> block
> entirely
> > unless there are specific fields you wish not to be disclosed.
> 
> right, but that was not my question.
> I was assuming that a contact:info sent in from a non-sponsoring
> registrar for a contact that wants not to disclose it's name, email,
> addr is considered to be from a third party so i would have had to omit
> those affected fields from the reponse. Since the schema neither allows
> to omit e.g. the email nor to have it empty, i would have had to fill
> in some dummy data (see "n/a" in the second response in my initial
> mail).

If the client lacks the appropriate privileges to view the information you can return a 2201 authorization error in response to the query.

Scott
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg