Re: contact:disclose clarifications / best practices

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?

> 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.

> 3) is it ok to disclose the contact:disclose itself to third-parties?
> I guess it is, also to alleviate determining what fields contain real
> data instead of workaround fill junk?

I can't see any harm in doing so. It's not disallowed. Again, we need to know if
this command is being issued with or without a <contact:authInfo> element.

> Long story:
> Ideally i would have expected to be able to return:
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>   <response>
>     <result code="1000">
>       <msg>Command completed successfully</msg>
>     </result>
>     <resData>
>       <contact:infData xmlns="urn:ietf:params:xml:ns:contact-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
>         <contact:id>dnd018360624626</contact:id>
>         <contact:roid>C0000000704-BOX</contact:roid>
>         <contact:status s="ok"/>
>         <contact:postalInfo type="int">
>           <contact:addr/>
>         </contact:postalInfo>
>         <contact:clID>primary</contact:clID>
>         <contact:crID>primary</contact:crID>
>         <contact:crDate>2013-01-22T18:50:12.160307Z</contact:crDate>
>         <contact:disclose flag="0">
>           <contact:name type="int"/>
>           <contact:org type="int"/>
>           <contact:addr type="int"/>
>           <contact:voice/>
>           <contact:fax/>
>           <contact:email/>
>         </contact:disclose>
>       </contact:infData>
>     </resData>
>     <trID>
>       <clTRID>8DE21C7A-64C4-11E2-BE5E-5148DCA3D1ED</clTRID>
>       <svTRID>20130122195013136028C3-secondary-box</svTRID>
>     </trID>
>   </response>
> </epp>
> 
> But that complains about
> Element '{urn:ietf:params:xml:ns:contact-1.0}clID': This element is not expected. Expected is one of ( {urn:ietf:params:xml:ns:contact-1.0}voice, {urn:ietf:params:xml:ns:contact-1.0}fax, {urn:ietf:params:xml:ns:contact-1.0}email
> 
> The "best" i can come up with would be something like
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>   <response>
>     <result code="1000">
>       <msg>Command completed successfully</msg>
>     </result>
>     <resData>
>       <contact:infData xmlns="urn:ietf:params:xml:ns:contact-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
>         <contact:id>ost005598875483</contact:id>
>         <contact:roid>C0000000724-BOX</contact:roid>
>         <contact:status s="ok"/>
>         <contact:postalInfo type="int">
>           <contact:name>n/a</contact:name>
>           <contact:addr>
>             <contact:city>n/a</contact:city>
>             <contact:cc>n/</contact:cc>
>           </contact:addr>
>         </contact:postalInfo>
>         <contact:email>n/a</contact:email>
>         <contact:clID>primary</contact:clID>
>         <contact:crID>primary</contact:crID>
>         <contact:crDate>2013-01-23T10:00:09.394220Z</contact:crDate>
>         <contact:disclose flag="0">
>           <contact:name type="int"/>
>           <contact:org type="int"/>
>           <contact:addr type="int"/>
>           <contact:voice/>
>           <contact:fax/>
>           <contact:email/>
>         </contact:disclose>
>       </contact:infData>
>     </resData>
>     <trID>
>       <clTRID>ABE135BA-6543-11E2-A06D-7716DCA3D1ED</clTRID>
>       <svTRID>20130123110009545038BB-secondary-box</svTRID>
>     </trID>
>   </response>
> </epp>

I assume the it's a client parser that's giving these errors. If a contact is
being queried with an <authInfo> block, I don't think that disclosure flags
actually apply: if you've got a domain's authorisation code, that implies full
access to linked objects for the purpose of issuing <info> commands.

While this is an assumption on my part, there's good reason for it: transfer.
Say you have the email field set for nondisclosure and somebody was transferring
the domain away from you. The gaining registrar needs to be able to get at the
email so that they can contact the registrant for confirmation, so if the the
email field was set for nondisclosure, they wouldn't be able to deal with the
transfer.

> i.e. fill in name, city, email with an arbitrary token (which one?!)
> and fill in cc with an arbitrary, invalid ccType.

I think the disclosure fields deal more with the likes of what's published in
WHOIS and the likes.

-- 
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