7. Contact merger

The purpose of contact merger is to minimize duplicate contacts in the Registry.

The core of the merger is the merge operation which allows to merge a pair of identical and mergeable contacts, from a source contact to a destination contact. If the contacts are linked to other objects, then the source contact(s) is (are) replaced with the destination contact in every linked object. The source contact(s) is (are) then deleted from the Registry.

The Registry operator may choose a pair of duplicate contacts themself and merge just the two of them if the two contacts are mergeable. (See the task Merge a pair of duplicate contacts (manual).)

The other option is to use the automatic merge procedure which can select a whole set of duplicate contacts automatically and merge them into a single destination contact. The destination contact is determined by filtering the set with various criteria (see Selection of the destination contact in an automatic merger), which make the outcome the best possible choice. The other contacts in the set are treated as source contacts. (This task can be set as a periodic task.)

In both cases, the contacts must be managed by the same registrar, however, they are replaced in linked objects even if the linked objects have different registrars.

7.1. Identical contacts

For contacts to be considered identical by the merger, they must have the following attributes identical:

  • current designated registrar: object.clid

  • name: contact.name [1]

  • organization: contact.organization [1]

  • address (permanent): contact.street1, contact.street2, contact.street3, contact.city, contact.stateorprovince, contact.postalcode, contact.country [1]

  • email: contact.email [1]

  • notification email: contact.notifyemail [1]

  • fax: contact.fax [1]

  • telephone: contact.telephone [1]

  • identity document type: contact.ssntype

  • identity document number: contact.ssn [1]

  • VAT: contact.vat [1]

  • disclose flags: contact.disclosename, contact.discloseorganization, contact.discloseaddress, contact.disclosetelephone, contact.disclosefax, contact.discloseemail, contact.disclosevat, contact.discloseident, contact.disclosenotifyemail

  • user’s preference of sending domain expiration letters: contact.warning_letter

  • and for each associated contact address of any type (MAILING, BILLING, SHIPPING, SHIPPING_2, SHIPPING_3):

    • contact_address.company_name [1]

    • contact_address.street1 [1]

    • contact_address.street2 [1]

    • contact_address.street3 [1]

    • contact_address.city [1]

    • contact_address.stateorprovince [1]

    • contact_address.postalcode [1]

    • contact_address.country [1]

7.2. Mergeable contacts

Contacts must be identical and comply with the following conditions:

  • the source contact(s):

    • must not be administratively blocked (serverBlocked status active), and

    • must not have the serverDeleteProhibited status active, and

    • must not belong to a mojeID account (mojeidContact status active), and

    • must not have the contactInManualVerification status active, and

    • must not have the contactFailedManualVerification status active,

  • and the destination contact:

    • must not be administratively blocked (serverBlocked status active), and

    • must not have the contactInManualVerification status active, and

    • must not have the contactFailedManualVerification status active,

  • and registrable objects linked to the source contact:

    • must not have the serverBlocked status active, and

    • must not have the serverUpdateProhibited status active.

Note

The rules for identity and merge-ability are hard-coded.

7.3. Merge operation

The procedure of merging a pair of duplicate contacts performs as follows:

  1. Checks that the contacts are mergeable.

  2. In objects linked to the source contact, replaces the source contact with the destination contact (using update operations).

  3. If the source contact has had the contactPassedManualVerification status active, sets it on the destination contact.

  4. Deletes the source contact from the Registry.

  5. Generates new AuthInfo for the destination contact.

  6. Generates poll messages for changes made in the step 2.

7.4. Selection of the destination contact in an automatic merger

Because the detection of duplicates is automatic, the Registry must also select the destination contact, into which the merge will result and which will be used to replace the duplicate contacts in linked objects.

The contact of the best qualities is selected according to the following criteria evaluated in this order [2]:

  • contact is identified,

  • contact is conditionally identified,

  • contact handle complies with the syntax for mojeID handles,

  • contact has most domains linked (as a holder or administrative contact),

  • contact has most objects linked (domains, name-server sets or key sets),

  • contact has been updated most recently,

  • contact has been created most recently.

The contact that matches the most of the criteria, is the destination contact. If more than one contact meets all of these criteria, the destination contact is chosen from them randomly.