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

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 <wil@cloudregistry.net> wrote:

> 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 <keith@blacknight.com> 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
> <provreg@contact.dotandco.com> wrote:
>> Hollenbeck, Scott <shollenbeck@verisign.com> 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
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
email: fobispo@isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE