Hello James, On 03/05/2017 22:15, Gould, James wrote:
> JG – I don’t see how the fee information is tied to availability. The > only case that has recently come up is returning a non-standard domain as > unavailable when the fee extension is not passed. We’ve debated the > extension of the check command / response, and I agreed to support the > check command / extension; although we need to ensure that the fee > extension does not become too heavyweight. Arguably, in a situation where many TLDs are now offering domains at various pricing tiers (with no further policy requirements), general availability is no longer just a matter of "domain taken/reserved/valid?", but also of "how much is the registrant willing to pay?". >From that point of view, providing fee information in a <check> response seems vital for enabling registrars to offer such domains to their customers. But I agree that it's a matter of how broad the term "availability" should be interpreted. > JG – I agree that inclusion of the fee extension for the SLA monitors is > highly unlikely. My main concern is extending the heaviest hit command > in the registry independent of SLA monitors. Extending the check command > / response should be the exception to the rule and should not be > considered a general conduit for getting information in bulk. I see the > importance of the fee information, so an exception is being made in this > case. As a community we should not set this up as a future pattern of > morphing the check command / response into a bulk info command / > response. Agreed. > JG – This would be the case if it were a true extension of the info > command / response. What is proposed in option #3 is consistent with > extending an empty domain update for the restore command in RFC 3915. Another solution which I've never really liked, but it looks like that ship has sailed. > In this case, if you see an info command with a fee extension, it is routed > to a fee information handler that will return the fee information > independent of the existence of the objects (e.g., domain). Ok, so it would essentially morph the <info> command's semantics into something slightly different, from, as the RFC says, "retrieve information associated with a domain object" to "retrieve information associated with potential domain objects". Acceptable, even though I'd personally still consider this closer to the <check> command's responsibility. > JG – Option #2 is really no different from what you’re requesting. The > main element of option #2 is in how it is described in the draft, but the > XML schema and the makeup of the command and response are the same. The > main difference is that you’re defining a fee check command and response > that includes the availability information instead of the other way > around (an availability check command that includes fee information). > This makes the fee check a sibling of the availability check, which means > that future availability check extensions don’t get automatically latched > onto the fee check. Section 5.1.1. EPP <check> Command could read like > the following if option #2 was taken: > > This extension defines a new command called the Fee Check Command that is > used to determine whether the fee information is available and if so > returns the fee information along with the availability check information. Ok, understood. > …, now include the following use cases in the response: > > 1. Return a 2306 error if the server policy does not support the > <fee:currency> element value specified in the command. > > 2. Return avail=”0” in the <fee:cd> element for any object that > does not have fee data with a <fee:reason> child element that describes > the reason. > > 3. Return avail=”0” in the <fee:command> element for a command that > does not have fee data with a <fee:reason> child element that describes > the reason. > > The only time that avail=”0” would be returned for the <fee:cd> element > is if there is an issue returning fee information for the object, like if > the domain name is invalid. Issues with the commands would be handled at > the command level via the <fee:command> avail attribute. Global errors > like passing an invalid currency based on the server policy would be > handled at the fee check command layer. > > Thoughts? Sounds like a good solution to me, and schema-wise we already have in place what we need for this, i.e. only the description text would need the above clarifications. 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
