.. _epp-contacts-mapping:

Contact mapping
===============

Contents:

Informative commands:

.. toctree::
   :maxdepth: 1

   check
   info

Object transform commands:

.. toctree::
   :maxdepth: 1

   create
   update
   delete

Unimplemented commands:

* ``transfer`` command is not implemented for the Contact objects mapping -
  each registrar, having an EPP account, has its own set of contact objects,
  they are never shared between EPP accounts, even if the legal or private person they describe, is the same.

  .. note ::

     Please, do not create multiple contact objects for the same legal entity or a private person -
     instead, a single copy  describing every holder or administrative contact of the managed domain names
     should be maintained and updated accordingly if contact information changes.

* Also, ``renew`` command is not available as contact objects in our data model never expire.

Extends `RFC-5733`_

* Every contact object can be assigned different roles for any domain managed by the registrar.
  Registrant contacts are not special in any way but still, the Registry requires more contact details
  if contact is to be used as a registrant for any domain name.

Properties of a contact object
------------------------------

EPP commands and responses may contain the following properties of a contact object:

* ``contact:id`` contact handle

  .. note ::

     ``contact:id`` is generated automatically for contact objects which were created before the client gained access to EPP account:

     + contact handle for registrar's primary person: ``{account-name}-bill``
     + contact handle for hostmaster contacts: ``{account-name}-adm0``, ``{account-name}-adm1`` etc
     + holder/administrative contacts of managed domains would have handles in form:

     (please, use :ref:`domain:info <epp-domain-info>` to retrieve these handles)


* ``contact:email``
* ``contact:voice``
* ``contact:fax``

* ``contact:postalInfo``

  + ``contact:name``
  + ``contact:org``

  + ``contact:addr``

    - ``contact:street``
    - ``contact:city``
    - ``contact:sp``
    - ``contact:pc`` - a postal code. For Latvian contacts (``contact:cc`` element containing "LV") it's value is supposed to contain four digits, prefixed with "LV-" (e.g. "LV-1001").
      A `Postal Code look-up service <https://www.pasts.lv/en/Category/Postal_Code_Look-up/>`_ may be useful.
    - ``contact:cc``

* ``contact:regNr`` contains either:

  + Latvian enterprise registration number (eleven digits, typically starting with ``4`` or ``5``)
  + personal code for Latvian natural persons in the following format:

    - ``YYMMDD-CNNNN`` where first 6 digits form a birth date of the individual, and the first one after the hyphen, C, stands for a century: ``0`` for XIX, ``1`` for XX and ``2`` for those born in XXI century;
    - ``32NNNN[-]NNNNN``: from July 2017, a new format of personal code became available, containing eleven digits, first two being ``32`` and having an optional ``-`` after the first six digits.

* ``contact:vatNr``


Policy restrictions
-------------------

* for each contact, we distinguish legal entities from private persons
  by the presence or absence of ``contact:org`` element under ``contact:postalInfo``

* ``contact:postalInfo``:

  + only one ``contact:postalInfo`` element is allowed with type ``"loc"`` (Unicode form of postal address);
  + total length of all ``contact:postalAddr`` fields should not exceed 255 characters;
  + all three ``contact:street`` elements are kept together as a single string;
  + if a non-empty ``contact:org`` element is present, contact is considered to be a *legal entity*;
    and value of the ``contact:org`` element as the officially registered name of the legal person:

    - ``contact:name`` then holds the name of its contact person, and ``contact:postalAddr`` - legal address of the contact.

    Otherwise, contact is an *individual* with name as found in ``contact:name`` element
    and ``contact:postalAddr`` contains his/her contact address.

    .. note ::

       Contents of ``contact:name`` element is kept as an opaque string - we do not
       attempt to break it internally into name and surname pairs nor interpret it in some other way.


.. *** include external reference links: ***
.. include:: /ref_links.rst