Result Codes (Re: Standard Extensions)

I wonder if there's any value in some of us getting together to author
an informational draft documenting existing behaviours surrounding the
use of result codes. Specifically, we could list the error conditions
and the corresponding result codes that are returned by servers "in
the wild". This would help future implementers, both from a client's
and server's perspective, to at least not diverge further.
Furthermore, it would perhaps become apparent if an extension is
needed.

.wil

On Fri, Aug 24, 2012 at 8:03 AM, Keith Gaughan <[email protected]> wrote:

> Or maybe it's the way that some registries return 1001 (pending) as the
> status for a pending transfer and some return 1000 (completed) but with
> the <trStatus> element in the body set to 'pending'. Then there's the
> crapshoot as to whether the registrar supports/allows/requires
> international address types, local address types, or both, which often
> goes undocumented.
>
> There's surprisingly little agreement on the actual meaning of 2201
> (authorisation error) and 2202 (invalid authorisation information),
> when they should be used, and how the registrar should react to them.
> I've even seen 2306 (parameter value policy error) cropping up where
> I'd expect either 2201 or 2202.
>
> Ditto goes for confusion around the use of the 200[1-5] series of status
> codes.
>


Also earlier:


On Wed, Jan 25, 2012 at 11:01 AM, Patrick Mevzek
<[email protected]> wrote:
> Hollenbeck, Scott <[email protected]> 2012-01-24 13:01
>> How many registries are using custom result codes and status values?
>
> Indeed, I rewrote myself saying almost any registry, because I had in
> mind VeriSign which does not need custom codes.
>
> However as an EPP client implementor I've seen registries using their
> own result codes/status values in such ways:
> - either just adding items to the associated lists, breaking the EPP
>   XML Schema validation (for the brave souls doing it live)
> - or adding "sub" values, that is besides standard ones
> - or creating a true EPP extension, in the RFC 3735 sense, with new
>   values.
>
>
> Looking at my code I see at least the following:
> .FR
> .AT / IENUMAT
> .BE
> .EU
> .LU
> .NO
> .NL
> .CA
>
> but I'm not really keeping track of list of specific statuses, so
> there may be some more, maybe some registrars could provide more info.
>
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg