Contact Info Command

Requests detailed information about a contact person, owned by the client.

This command follows standard EPP Contact mapping, RFC-5733 with a simple extension in the server response.

Client request

Request should contain a single client:id element, containing a client handle. Even if a contact:authInfo element is given, the server ignores it because only a “sponsoring” client is allowed to access details of the contact object.

Example:

<?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"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
  <command>
    <info>
      <contact:info
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd">
        <contact:id>namesu1105-12345</contact:id>
      </contact:info>
    </info>
    <clTRID>uJkhAlqyjSb90AgLexEl</clTRID>
  </command>
</epp>

Server response

Response for sponsoring client

Example of response for sponsoring client, owning the contact:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <resData>
      <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>namesu1105-12345</contact:id>
        <contact:roid>CNT-10011-LVNIC</contact:roid>
        <contact:clID>testuser</contact:clID>
        <contact:voice>+371.12345678</contact:voice>
        <contact:fax>+371.87654321</contact:fax>
        <contact:email>somewhere@snailmail.lv</contact:email>
        <contact:postalInfo type="loc">
          <contact:name>Name Surname</contact:name>
          <contact:addr>
            <contact:street>Longstreet 33-3</contact:street>
            <contact:city>Rīga</contact:city>
            <contact:pc>LV-1122</contact:pc>
            <contact:cc>LV</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:crID>testuser</contact:crID>
        <contact:crDate>2011-05-10T15:18:17+03:00</contact:crDate>
        <contact:upDate>2011-05-10T15:18:17+03:00</contact:upDate>
        <status s="ok"/>
        <contact:authInfo>
          <contact:pw>
            <contact:null/>
          </contact:pw>
        </contact:authInfo>
      </contact:infData>
    </resData>
    <extension/>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <trID>
      <clTRID>uJkhAlqyjSb90AgLexEl</clTRID>
      <svTRID>LVNIC-20110511-5cab0f580d50a346dd2480b2bcd6c3be-2</svTRID>
    </trID>
  </response>
</epp>

Please, note that some differences from RFC-5733 takes place:

• only a single contact:postalInfo element (having type="loc" attribute), corresponding to contact address for private persons and legal address for enterprises and other legal entities.
  • contact:org: present only for legal entities containing their registered name (its presence distinguishes contact object as a legal person)
  • contact:name: for private persons contains name and surname of the person itself, for legal persons - the name and surname of a contact person, working for that organization.
• contact:authInfo is not used with NIC.LV so a <contact:pw><contact:null/></contact:pw> element is returned to satisfy schema.

For contacts whose residence country is Latvia and for contacts - legal persons from EU countries, response may include extension with following elements under <lvcontact:infData> tag:

• lvcontact:regNr, containing:
  • Latvian person code for private persons which are residents of Latvia
  • Registration number, issued by the Latvian Register of Enterprises if contact corresponds to a legal entity registered in Latvia
• lvcontact:vatNr, containing VAT number for legal entities, registered in European Union countries (optionally, may be present also for enterprises based in other countries)

Note

For contact objects, created before launching of the EPP service:

• crID will contain __SERVER__
• contact:voice and contact:fax elements may contain phone numbers in a more relaxed format than required by the standard EPP schema (e.g. “(371) 22-34-56-78”, instead of “+371.22345678”). So, if a client validates the response XML against EPP schema, it may fail.

Response for other registrars

If contact object with requested contact:id is not owned by the caller, only it’s contact:id, contact:roid and contact:clID (EPP client ID of registrar, owning the contact object), are returned.

Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <resData>
      <contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>namesu1105-12334</contact:id>
        <contact:roid>CNT-10011-LVNIC</contact:roid>
        <contact:clID>testuser</contact:clID>
      </contact:infData>
    </resData>
    <extension/>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <trID>
      <clTRID>uJkhAlqyjSb90AgLexEl</clTRID>
      <svTRID>LVNIC-20110511-5cab0f580d50a346dd2480b2bcd6c3be-2</svTRID>
    </trID>
  </response>
</epp>