RE: "External" hosts in EPP

[asbjorn.rrp@theglobalname.org]

Scott,

I agree that creating objects without the registrars knowledge is perhaps not a very good idea. :-)

I don't have a problem with doing it as you describe. Are people here happy with that? What if we in the <transfer> command give the user the option whether to copy necessary host objects or not, and the default behaviour is not copying the host objects and potentially fail the transfer.


Asbjorn


On Tue, 18 Dec 2001 13:14:01 -0500 "Hollenbeck, Scott" wrote:
>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-
>


-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.