RE: <info> Command and authInfo

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

> -----Original Message-----
> From: Jens-Uwe Gaspar [mailto:jug@schlund.de]
> Sent: Tuesday, January 15, 2002 1:06 PM
> To: ietf-provreg@cafax.se
> Subject: Re: <info> Command and authInfo
> 
> 
> 
> While registering a new object (domain, contact or host), it 
> may happen,
> that in the registry the object was registered, but 
> accidently our database
> will fail (cause of deadlock, DB-maintenance, or whatever).
> Because there's no transaction enclosing registry _and_ 
> registrars actions,
> we must recommence registering the object (dom/contact/host):
> 
>   <check> existence of object;
>   if existing, do <info> to get [sponsoring registrar]:
>     if [sponsoring registrar] not equal to ourselves => we're 
> sad registrar
>        and stop further action for this object
>     else: we're happy registrar and go on with further actions :)
> 
> In practice it stands the test (.INFO/.BIZ) and we would appreciate,
> if that's also be possible in future versions of EPP.

You can achieve exactly the same results without having to determine the
sponsoring client.  Do an <info>, if you're not the sponsor you get back a
"you're not authorized" error code => you're sad.  If you are, <info> works
and you're happy.  It's also less work for the server if you're not the
sponsor as no data has to be retrieved from a local data store to generate
the error response.

With respect to current implementations, while I can appreciate the insights
gained in writing code to the specs, we as WG can't have our focus limited
by code written to I-Ds.  We need to be able to change the specs as issues
are found and explored, even if that means someone might have to change
code.

> Do you want to restrict returning the object data completely, or do you
> allow returning parts (changing minOccurs in the specs)?
> 
> For example, reducing <info> result-data to the output the corresponding
> whois-server list, if requested by a registrar other than the current
> sponsoring one.

This might be a reasonable compromise.  My initial thought was to restrict
it completely, but maybe there's no harm in returning a subset of the info
if the querying client isn't the sponsor and doesn't have the authInfo.

-Scott-