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 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 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 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 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
> element value specified in the command.
>
> 2. Return avail=”0” in the element for any object that
> does not have fee data with a child element that describes
> the reason.
>
> 3. Return avail=”0” in the element for a command that
> does not have fee data with a child element that describes
> the reason.
>
> The only time that avail=”0” would be returned for the 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 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
