As the About page outlines, a system application is required to use the ARI EPP c++ client tool kit even in Scenario 1 and I call my original design of this a “Cliever”¹ for Client-Server because the application is a server to the Registrar and a client of the Registry.
This base original generic code is © firstname.lastname@example.org, I presume ARI or ICANN own AusReg, and most of the other platform support is general open source, but ownership of a specific application of my design is transferred to the client Registrar, with rights to that in any jurisdiction whatsover³. Because it is specific to the ARI EPP C++ Client Toolkit it is “AusReg Cliever”. A base AusReg Cliever enabling Scenario 1 from the about page will be similar for Registrars of similar size.
However every Registry-Registrar pair and the Registrars specific handling of that defines their distinct derivation as their wholly owned IP without prejudice to my ownership of the commodity intellectual property, closely held to protect the individual competing Registrars.
The Three Gaps
The above is the second gap between perception and reality, after the non-fungibility of the toolkit as a directly usable solution by Registrars. The reality is that the General Transaction Model, other elements of the toolkit still leave it exactly that, a toolkit and not an end solution for implementing a specific Registry-Registrar contract which must be implemented as a custom piece of software for each distinct such contract. Even with a basic executor, a solution is needed that applies Registrar biz rules to the execution of the functions in the toolkit, AusReg Cliever supplies both.
After these first two negative gaps, there is a third and positive one. It’s the positive fact that if the toolkit is built, and the configuration set properly the toolkit will pass its’ some 50 tests confirming its’ function². Registries are not in the business of providing service to do even this though so it is part of this service (EPPP).
Each of the Stages is deeply enmeshed in the Registry-Registrar Contract and the Registrar’s biz rules.
Here are the 5 stages referred to in the image on the About page. The impact of the heading above should be immediately clear. Each Registrar must embody it’s own biz rules and in the terms of my framework develop their own custom Cliever.
Even if the situation with the tests (3rd deceit) were extended to one where a Registry’s client Registrars received service to build and configure the toolkit and supplied the minimum programming needed to establish service (commonly called OTE Certification) and bring them to an operational state corresponding to Scenario 1, custom programming would still needed to drive their biz logic, interface with their database etc.
ARI-TOO-001 Tk General 2008-08-15
ARI-TOO-003 Tk C++ 2008-08-15