Subject: [ietf-provreg] Unique identifiers for Contact

From: Andre Marais <[email-masked]>
Date: Mon, 05 Apr 2004 11:55:00 +0200

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.
-----------------------------------------------------------------------

---

From: Joe Abley <[email-masked]>
Date: Mon, 5 Apr 2004 10:43:18 -0400

> the server side which would eliminate this type of problem?

Which identifier do you mean?

I think the only identifiers mentioned in the base spec are transaction 
identifiers. Collisions between clTRIDs used by different registrars 
are legal; svTRIDs are generated by the server in all cases, and hence 
making them unique should be straightforward.

Joe

---

From: janusz sienkiewicz <[email-masked]>
Date: Mon, 05 Apr 2004 11:02:31 -0400

> the server side which would eliminate this type of problem?

A small adjustment to EPP protocol would help with the potential
inconvenience. Element <contact:id> in contact create request could be
OPTIONAL. The absence of the element in a contact create request would
indicate that the server should generate contact identifier for the new
contact. The format of contact create response would remain unchanged.
Clients that don't pass values for desired unique identifiers could obtain
server assigned values  from create responses.

Janusz Sienkiewicz

---

From: Andre Marais <[email-masked]>
Date: Mon, 05 Apr 2004 17:37:50 +0200

Hi Joe,

> Which identifier do you mean?

As per the example from draft-ietf-provreg-epp-contact-06:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
  C:     epp-1.0.xsd">
  C:  <command>
  C:    <check>
  C:      <contact:check
  C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
  C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
  C:       contact-1.0.xsd">
  C:        <contact:id>sh8013</contact:id>
  C:        <contact:id>sah8013</contact:id>
  C:        <contact:id>8013sah</contact:id>
  C:      </contact:check>
  C:    </check>
  C:    <clTRID>ABC-12345</clTRID>
  C:  </command>
  C:</epp>

The identifier I was referring to was the contact:id element as shown
above. This field should be server-unique according to the spec, and as
explained could cause problems in high-volume cases.

> making them unique should be straightforward.

Agreed, but see above.

Regards,
Andre

---

From: Andre Marais <[email-masked]>
Date: Mon, 05 Apr 2004 18:02:42 +0200

Hi Janusz,

> server assigned values  from create responses.

Agreed. What are the chances of this being accepted as standard?

Regards,
Andre

---

From: Rick Wesson <[email-masked]>
Date: Mon, 5 Apr 2004 09:50:52 -0700 (PDT)

Pick a namespace for all your contacts, such as FLAME-?????-CT anything
created with that prefix is yours, the likely hood of others creating
contacts within your space seems unlikely.

the handlespace is 16 chars wide (it think) and should have plenty
of unused names.

-rick

---

From: Joe Abley <[email-masked]>
Date: Tue, 6 Apr 2004 14:08:40 -0400

> As per the example from draft-ietf-provreg-epp-contact-06:

Oh, I'm sorry. I thought you were just talking about the base spec.

RFC 3733 describes the contact:id element as enclosing the desired 
server-unique identifier; the corresponding response (on success) 
contains the actual server-unique identifier used.

It has been a while since I looked at the code, but I think in OpenReg 
we ignore the client-supplied contact:id data and generate our own 
server-unique data to be returned in the corresponding response field. 
We don't throw errors if the client-supplied string collides with 
someone existing contact:id -- we just ignore it.

Are there server implementations in the wild which return errors if the 
client-supplied contact:id element is empty, or contains a 
non-server-unique string?

Joe

---

From: janusz sienkiewicz <[email-masked]>
Date: Tue, 06 Apr 2004 16:58:12 -0400

> non-server-unique string?

I think an EPP standard compliant server implementation should return error
response if the client-supplied contact:id element is empty. The XML type
for the element is clIDType and the type has minimum length which is 3.

Assigning a value by the server in case of non-server-unique string could be
very confusing for some clients. It is probably safer to return error code.

Janusz Sienkiewicz

---

From: Joe Abley <[email-masked]>
Date: Tue, 6 Apr 2004 17:07:47 -0400

> for the element is clIDType and the type has minimum length which is 3.

Ah, good point.

> very confusing for some clients. It is probably safer to return error 

The spec seemed fairly clear to me that clients shouldn't expect the 
server-unique string in the response to be the same as the 
server-unique string they suggested, but upon re-reading, it does seem 
reasonable to not make that assumption.

Scott: what did you intend, here?

Janusz: I like your proposal to make <contact:id> optional, too. I wish 
someone had suggested it before last call :-)

Joe

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 7 Apr 2004 13:51:24 +0200

> very confusing for some clients. It is probably safer to return error 
code.

Further, this behaviour makes the operation to lose the property of 
idempotency.

Regards,
Marcos