Hello, On 2017-03-28 15:09, Gould, James wrote:
> I had an action item from the working session yesterday to describe > the proposal for the extension to the check response that matches > Option C discussed at IETF-95. The “more complex option” outlined in > the list message > https://www.ietf.org/mail-archive/web/eppext/current/msg00883.html > provides an example of the extension to the check command and > response for what was called Option C. Option C included a single > currency and a list of commands that is applied to all the domains in > the availability check. In the case of an invalid currency, the > <fee:cd avail=”false”> with a <fee:reason>Invalid > currency</fee:reason> could be returned for each of the domain names > in the check instead of returning a failure to the availability > check. In this case Option C truly is an extension of the check with > a single set of requested fee information. I like this approach better than the current fee-0.15 solution, which allows/requires restricting the fee checks to a subset of the checked object, and supports a different currency and set of commands for every object. While this may come in handy sometimes, the most common usage would probably select all checked objects and a single currency and set of commands. Most servers will probably only support a single currency anyway. What I don't like is that the "avail" attribute has been moved to the framing <fee:cd> element, while it's an attribute of <fee:command> in the current fee-0.15 draft. The latter has the big advantage of the server being able to report e.g. the availability of a fee (and the domain in general) for different launch phases. For example, with fee-0.15, this response could indicate that the domain premium-500.example is available in the launch phase "custom/open-500", but not in "open". S: <?xml version="1.0"?> S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance";> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:cd> S: <domain:name avail="false">premium-500.example</domain:name> S: <domain:reason>not registrable in this phase</domain:reason> S: </domain:cd> S: </domain:chkData> S: </resData> S: <extension> S: <chkData xmlns="urn:ietf:params:xml:ns:fee-0.15"> S: <cd> S: <objID>premium-500.example</objID> S: <currency>EUR</currency> S: <command avail="false" name="create" phase="open"> S: <reason>the requested launch phase is not suitable for the domain</reason> S: </command> S: <command name="create" phase="custom" subphase="open-500"> S: <period unit="y">1</period> S: <fee applied="immediate" description="domain creation in phase 'open-500'" grace-period="PT1M" refundable="true">500.00</fee> S: </command> S: </cd> S: </chkData> S: </extension> S: <trID> S: <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID> S: <svTRID>1490271424463-9</svTRID> S: </trID> S: </response> S: </epp> I'd like to retain this feature. I'm aware that this somewhat "abuses" the fee extension to determine which launch phase is suitable for a domain (and there is an overlap with the extension's "domain class" concept), but it's not too far from the intended use in my opinion. 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
