Thomas, Putting the avail attribute at the level of fee:cd addresses use cases where the domain name is invalid, reserved (without pricing), and the currency is invalid. In these cases, you would not want to return all the commands with an avail=false to indicate that the fee information is not available for the domain. If the server needs to get down to the detail of providing availability at the command level, then the avail attribute could be added there as well, but there is an extra level of complexity to handle it at the command level. If the command is invalid, the period is invalid, having the avail flag only at the fee:cd level would fast-fail to not provide any of the fee information. Although this may not be as functional, it allows the server to fast fail the fee check which is important to keep the availability check more lightweight. I would prefer to fast fail if possible.
— JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 3/28/17, 10:34 AM, "Thomas Corte" <thomas.co...@knipp.de> wrote: 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
