RE: Result codes to handle protocol extension-related errors.

[Roger Castillo Cortazar <castillo@mail.nic.mx>]

At 14/08/2002 09:20 a.m., you wrote:
> >I'd much rather see extensions (including error extensions) left within the
> >boundaries of an <extension> element instead of trying to anticipate
> >extension errors in the core document, we might be able to define two new
> >response codes (like maybe 1600 and 2600) that means either "command
> >succeeded" or "command failed", and "look at the <extension> for details.
> >I'm not sure if there's much value in this, though, since extensions can
> >supplement existing response codes anyway.
>
>I would tend to agree with this.

Me too.It looks good.
In this way, you can deal with features added by protocol extensions, without
going into too much trouble with the core docs.

>The trouble with a code that means "look in the extension" is that a client
>must know how to interpret the extension to find the supplementary error
>information. Since formats will vary from one extension to another, the
>client will have to have built-in knowledge about what elements in extension
>to look at. So why not just return the generic EPP command failure status
>code(s) and let the client look at the extension if it wants to? This allows
>for a fairly smooth degradation in functionality in cases where the
>extension element isn't understood.

Exactly !!! A little bit more ....
The use of extensions have to be with an agreemente between the parts.
IMHO there has to be a previous arrangemente between registry and registrar 
to use
a particular protocol extension. A client must have buitl-in knowledge in order
to use an extension, and a registry may requiere that a registrar 
implements that
knowledge to do bussiness with him.

I'd go with the generic EPP command failure status code(s), to indicate the
client to look in the extension element for details.

Greetings.


Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx
Top Level Domain .MX