Thomas, I believe the domain-level availability based on launch phases is a corner case that as you point out is currently supported by the Availability Check Form in draft-ietf-regext-launchphase. Providing trial-and-error probing is sort of the point of the Check Command and its extensions, so I’m not sure whether there is a real problem to solve here. The Availability Check Form of draft-ietf-regext-launchphase extends the Domain Check to qualify which phase the Domain Check should be executed against. There is no extension of the Domain Check Response with the Availability Check Form since the intent is to only provide the target launch phase to execute the availability logic for.
Your proposal is to pass any empty <launch:check> extension element with type=”avail”, to indicate the Availability Check Form, to the Domain Check Command for the server to return the list of launch phases where the domain name is available. What is the expected behavior of the Domain Check Command itself? Is the availability of the domain name based on the current phase? If this is the case, then we’re getting into the territory of merging two commands (availability of domain in current phase and get a list of phases that the domain is available) into one. If such a feature is really needed, I would propose creating another check form (e.g. “Phase Availability Check This Form” with a type value of “phase-avail”) that only returns the list of phases that the domain is available in or a list of all the known phases with an availability flag for each phase. This would define a new Phase Availability Check Command that would return the <launch:chkData> extension of an EPP Response like what is done for the Claims Check Form or the Trademark Check Form. The following is what a Phase Availability Check Command and Response may look like where all of the known phases with an availability flag for each phase is returned: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <check> C: <domain:check C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>domain1.example</domain:name> C: <domain:name>domain2.example</domain:name> C: <domain:name>domain3.example</domain:name> C: </domain:check> C: </check> C: <extension> C: <launch:check C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" C: type="phase-avail"/> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp> S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <launch:chkData S: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"> S: <launch:pd> S: <launch:name>domain1.example</launch:name> S: <launch:phase avail=”1”>sunrise</launch:phase> S: <launch:phase avail=”0” name=”lrp”>claims</launch:phase> S: <launch:phase avail=”1” name=”open”>claims</launch:phase> S: <launch:phase avail=”1”>claims</launch:phase> S: </launch:pd> S: <launch:pd> S: <launch:name>domain2.example</launch:name> S: <launch:phase avail=”0”>sunrise</launch:phase> S: <launch:phase avail=”0” name=”lrp”>claims</launch:phase> S: <launch:phase avail=”0” name=”open”>claims</launch:phase> S: <launch:phase avail=”0”>claims</launch:phase> S: </launch:pd> S: <launch:pd> S: <launch:name>domain3.example</launch:name> S: <launch:phase avail=”1”>sunrise</launch:phase> S: <launch:phase avail=”1” name=”lrp”>claims</launch:phase> S: <launch:phase avail=”1” name=”open”>claims</launch:phase> S: <launch:phase avail=”1”>claims</launch:phase> S: </launch:pd> S: </launch:chkData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp> I question the need for this functionality, since I view the domain-level availability based on launch phases as being already supported by the Availability Check Form in draft-ietf-regext-launchphase, and adding a new check form to draft-ietf-regext-launchphase as meeting the same need in a different way for a corner case. I would like to hear from the registries and registrars of whether this additional functionality is needed. I believe it is not needed. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/4/17, 7:19 AM, "regext on behalf of Thomas Corte" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> wrote: James, On 03/08/2017 18:12, Gould, James wrote: > Roger, > > I believe TLD level EPP policies is relevant, but is best suited for > something outside of the Launch Phase or Registry Fee command-response > extensions. An example policy EPP mapping is the Registry Mapping > (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html) > that does provide launch phase schedule information at the TLD (zone) > level. Something like the Registry Mapping with extensions to define the > features and policies of EPP extensions like the Launch Phase or Registry > Fee extensions is best suited for defining and discovering the features > and policies. This "Registry Mapping" extension seems suitable to discover the more "static" properties of a registry's setup (including the generally supported phases). However, what I'd also like to see is a more "dynamic" phase discovery. In particular, we should cover cases in which a specific domain name may only be available when created in specific launch phases, and provide a way to determine these phases (this functionality was unfortunately removed from the fee extension in draft-ietf-regext-epp-fees-06). To me, such a feature seems closely tied to the "Availability Check Form" defined in the launch phase extension, which is defined exactly for that purpose (from the launch phase extension draft: "Domain names may be made available only in unique launch phases, whilst remaining unavailable for concurrent launch phases."). The only problem is that the "Availability Check Form" forces registrars to perform trial-and-error probing, since it requires the specification of a launch phase and will only tell whether or not that phase is suitable. Registrars need to check all known launch phases in turn until a suitable one is found. The problem of launch phase discovery for specific names could therefore be solved as an extension of the launch phase extension, e.g. by making the specification of the phase for the "Availability Check Form" *optional* and, if not specified, allowing the command to return a list of suitable launch phases for the name. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
