RE: "External" hosts in EPP

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: asbjorn.rrp@theglobalname.org
> [mailto:asbjorn.rrp@theglobalname.org]
> Sent: Tuesday, December 18, 2001 11:57 AM
> To: jordyn@register.com
> Cc: ietf-provreg@cafax.se
> Subject: RE: "External" hosts in EPP
> 
> 
> b) If the domain is using an external host that the gaining 
> registrar has not already registered, a copy of the existing 
> host object should be copied into the namespace of the 
> gaining registrar (thus owning the new host object). In 
> addition the domain record needs to refer to the new object 
> instead of the old object[1].

I don't think host copying is such a good idea because it means that a host
object gets created implicitly as a by-product of the <transfer> command
rather than as the result of a <create> command.  The server then has to let
the client know that this happened, and the risk of synchronization error
increases.

As I see it, there are two situations to consider:

1. The requesting client already has a local copy of the external host
object before the <transfer> is requested.  In this situation, the server
has to switch a pointer from the old client's copy to the new client's copy
as part of the transfer, but no new objects get created without the client's
knowledge.

2. The requesting client doesn't have a local copy of the external host
object before the <transfer> is requested.  Suppose we require the client to
create a local copy before they request the transfer?  They can see the name
servers before requesting a transfer, and it should be easy to compare
what's there with the client's local store of external hosts.  Once the new
local copy exists we're in situation #1 as described above, and the client
and server have consistent object views during the transfer process.  If the
transfer doesn't go through, the client can always delete the external host
object as part of their cleanup effort, or they can keep it around for
future use.

My basic point of discomfort is in the server creating objects as part of
something other than a <create> command.  I think the above could work
without the client having to worry about updating their object stores after
a transfer takes place because the server created an object for them that
they might not have expected.

-Scott-