Re: contact:disclose clarifications / best practices
Keith Gaughan <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jan 23, 2013 at 04:06:31PM +0100, Bernhard Reutner-Fischer wrote: > 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. Ok, the clarification that it's about a <contact:info> request issued without an <authInfo> element clears things up a lot. > > > >> 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. Thats because I wasn't entirely clear on whether your were talking about its use in <contact:create>/<contact:update> or <contact:info>. The above cleared it up. Behaviour on this varies from registry to registry. Some omit the elements entirely and assume that clients are not validating their responses against the EPP schemata. Others provide empty elements (such as '<contact:voice/>'). Most simply claim that the client has no authorisation to perform the operation and issue a 2201 response (though the actual response code used can vary). From the point of view of a registrar, I can say that I prefer this last option. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. <http://blacknight.com/> 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg