Subject: [provreg] contact:disclose clarifications / best practices

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Wed, 23 Jan 2013 11:26:31 +0100

Hi,

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?

2) what dummy values should i use for the required fields,
what is best/common practice?

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?

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.e. fill in name, city, email with an arbitrary token (which one?!)
and fill in cc with an arbitrary, invalid ccType.

thanks,

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Wed, 23 Jan 2013 12:55:38 +0100

> I have questions about contact:disclose.

Note, i assume that in
RFC5733, 3.1.2.  EPP <info> Command
<quote>
-  An OPTIONAL <contact:disclose> element that identifies elements
      that require exceptional server-operator handling to allow or
      restrict disclosure to third parties.
</quote>
third-party include (apart from e.g. the whois service) any registrar
that is not sponsoring that contact.
I.e. a "secondary" registrar in the example below who issued the
quoted info command on the contact sponsored by a "primary" registrar.

thanks,