Re: 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).
>
>> 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

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

yes, agree.

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

That is one way to see it, agree.

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