Re: <info> Command and authInfo

[Jens-Uwe Gaspar <jug@schlund.de>]

"Hollenbeck, Scott" wrote:
> 
> > -----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.

I'm aware of that, but when i follow Bruce Tonkin's note:

  BT> Bear in mind, that in future the use of EPP to talk to the
  BT> registry may not be restricted to entities such as authorised
  BT> registrars [...]

then there maybe

  a) normal users doing an <info> -> "not authorized", maybe because
     client has no access-right to do it, or
  b) registrar doing an <info> -> "not authorized", because not
     current sponsoring registrar,
  c) registrar doing an <info> -> "not authorized", because not allowed
     to do it (of whatever reason there could be: e.g. billing, etc).

I'm not sure, if it's a good idea to use the error code "not authorized"
to indicate that you're not the sponsoring registrar (b), because
then you can't differ it from case (c) stated above.

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

Sure, i only wanted to give an example in which the <info>-data is used.

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

Best regards,

Jens-Uwe Gaspar

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: jug@schlund.de                       Erbprinzenstr. 4 - 12
Tel. +49-721-91374-50                        76133 Karlsruhe, Germany
Fax  +49-721-91374-20                        http://www.schlund.de