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

From: Roger Castillo Cortazar <[email-masked]>
Date: Tue, 13 Aug 2002 13:12:46 -0500

Hi everybody.

Now that some folks in the list are talking about extensions.

We are working on a protocol extension for nic.mx, and we'll be needing to 
inform our clients about errors related to the features added by the extension.

What if I need to handle an error that is not covered in the core documents ?

Could we define a new category to handle this result codes ? For example ...

x3zz   Data Management
x4zz   Server System
x5zz   Connection Management
x6xx   Extension Related

... and leave it open ? or maybe we need to identify specific errors to be 
added to the core docs using the existing categories?
(I think this is the way the "Action Pending"  result code is going to be 
handled).

Any comments ?

Greetings.

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

---

From: Robert Burbidge <[email-masked]>
Date: Wed, 14 Aug 2002 15:20:26 +0100

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

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.

For what it's worth, we've managed to implement the verification extensions
for dot coop without defining any extra EPP error codes. The existing error
codes are adequate for processing the initial requests, and any subsequent
"error" conditions can be handled using <extension> elements inside <poll>
messages queued by the server. (Your mileage may vary).

Rob Burbidge
Poptel

---

From: Roger Castillo Cortazar <[email-masked]>
Date: Mon, 19 Aug 2002 13:09:19 -0500

I dont see it in the list, so here it goes again.

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

>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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 19 Aug 2002 19:49:36 -0400

> I mean the 1600 and 2600 generic result codes for protocol 
> extensions, as 
> suggested by Scott.
> Any comments ?
> I'd appreciate some some directions if I'm getting off the 
> right track ?

I sent the updated documents off to the I-D administrator earlier today, and
didn't do anything to add new error codes as described above.  There doesn't
seem to be agreement that they're needed; I certainly don't think they are
after giving this some more thought and hearing other people's comments.

When a client does a <login> it selects the extensions it wishes to use
during the session.  If the server then sends back one of those extensions
in a response, the client is obligated to understand it.  The very fact that
the extension is present is enough to tell the client "look in here", so
adding response codes to say "look in the extension" just doesn't seem to
add anything.

-Scott-