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

[Robert Burbidge <robert.burbidge@poptel.coop>]

>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