Subject: [provreg] Result Codes (Re: Standard Extensions)

From: Wil Tan <[email-masked]>
Date: Tue, 11 Sep 2012 12:38:10 +1000

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-masked]> 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-masked]> wrote:
> Hollenbeck, Scott <[email-masked]> 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.
>

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 10 Sep 2012 19:45:47 -0700

Hi Wil,

I don't think that this solution will prevent people from doing the wrong thing.

The real problem seems like the lack of RFC compliance or even common sense. Registries that are not bound to ICANN regulations (ccTLDs, etc.) will implement their own interfaces/extensions and registrars wanting to deal with them will have to adapt to those cases if they want to sell domain names. Is it optimal? no, but trying to normalize that is similar to try to normalize registry policies across all ccTLDs (or even *TLDs).

One of the things I want to work on, is an EPP RFC compliance tool, which will basically look at the use cases stated in the RFCs, run a test against a server and see if the response makes sense or not. Having such tool should help registries pinpoint implementation problems and hopefully fix them.

If any of you guys feel like a tool such as the one I'm describing is useful, contact me in private to see where it can go.

Francisco

On Sep 10, 2012, at 7:38 PM, Wil Tan <[email-masked]> wrote:

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Michael Young <[email-masked]>
Date: Mon, 10 Sep 2012 23:48:04 -0400

Hi Francisco,

Its pretty common for registry service providers to have an automated basic epp test available for accrediting registrars. They generally run separate test suites for extensions. The basic epp test server can be setup to reflect various TLD policies. 

I think there's likely a great deal of existing work that folks could contribute towards your goal if they are interested in doing so.

Michael Young

M:647-289-1220

---

From: "Ucom.ch - Bernie Hoeneisen" <[email-masked]>
Date: Tue, 11 Sep 2012 10:03:34 +0200 (CEST)

> Furthermore, it would perhaps become apparent if an extension is

This certainly helps, but does not solve the basic issue, which I'd call a 
flaw in the main EPP specs. Those specify a limited set of status codes, 
restricted by XML schema. Any _clean_ extension would require a change in 
a rather core EPP XML schema, which nobody likes to touch (for good 
reasons).

At next revision of EPP core specs, that affected XML shemata should be 
relaxed to allow any 4 digit code as status code. Along with this, 
guidelines should be defined for registration of additional status codes 
with IANA (e.g. Expert Review policy).

Comments?

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Technology

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 11 Sep 2012 13:40:31 -0700

> Its pretty common for registry service providers to have an automated basic epp test available for accrediting registrars. They generally run separate test suites for extensions. The basic epp test…

Yes,

> I think there's likely a great deal of existing work that folks could contribute towards your goal if they are interested in doing so.

This is why I think it will be useful to have a team of people work on it, so that we can reuse some of it.

I'll try to put something together and hopefully we will attract some interest.

Francisco Obispo 
email: [email-masked]