Unique identifiers for Contact

Hi All,

When looking at EPP base commands (specifically check) and the contact
mapping specification I could not help but notice the following with
regard to the check command for provisioning contacts within the system.

If a registry wants to provision a contact within the system, it first
needs to poll the systems using contact:check, and only if the unique
identifier (which might be arbitrarily chosen) does not exist, could it
create the identifier with the relevant required information.

Now even though such a scheme would work (initially), what would happen
when you have 10 registrars (or even more) all provisioning within a
single registry, and using any particular identifier generation scheme
(random, range sequential etc) to generate identifiers for provisioned
contact records. As the number of contact records increase (or rather
the number of unique identifiers) and the number of registrars increase,
the probability of unique identifiers clashing increases also.

When these identifier clashes become more frequent, one could expect
that there would be an increase in contact:check command storms together
with a increased latency when processing transactions that requires
contact provisioning.

Shouldn't there be a command that allows for identifier generation on
the server side which would eliminate this type of problem?

If this was discussed before, and a solution was provided, please direct
me so that I could steer clear of digging up old bones.

Regards,
Andre

-- 
Reading, after a certain age, diverts the mind too much from its 
creative pursuits. Any man who read too much and uses his own brain 
too little falls into lazy habits of thinking.
 - Albert Einstein.

-----------------------------------------------------------------------
LEGAL DISCLAIMER:
The views or representations contained in this message, whether express
or implied, are those of the sender only, unless that sender expressly
states them to be the view or representations of an entity or person,
who shall be named by the sender and the sender shall state to
represent. No liability shall otherwise attach to any other entity or
person.
-----------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAcSz0toKu6iM68osRAttJAJ9vQAvS50T62idTyfwzCIDkLiX5GACfUrMP
m8MYdCSzynQmLB+JyjH5usA=
=+WVa
-----END PGP SIGNATURE-----