Alex, The availability of the domain name and the availability of the fee information can be separate. Consider the use case where a client does a check for an existing domain name (e.g., “existing-domain.example”), where the availability check returns “false” but the fee extension could return the fee information, which may be useful if the existing domain name is in pendingDelete. Let me be clear that the fee information for an existing domain name is based strictly off the fee tables and not looking at the fee and credit information of the existing domain itself. The opposite case is sending a check for an available domain name (e.g., “invalid-currency.example”) with an invalid currency. In this case, the availability check would return “true” but the fee extension would return “false” at the object level. It’s best to separate the availability values, where the availability of the object is based on the availability for registration and the availability of the fee is based on the availability of the fee information. I believe it’s best to support a fast-fail at the object level by including the avail attribute at the <fee:objID> level and leave the avail attribute out of the <fee:command> level.
— JG [cid:image001.png@01D2A884.9B48BAB0] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Alexander Mayrhofer <alexander.mayrho...@nic.at> Date: Wednesday, March 29, 2017 at 11:37 AM To: Alexander Mayrhofer <alexander.mayrho...@nic.at>, Roger Carney <rcar...@godaddy.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-fees [ i hate responding to my own message, but i think i need to add something ] I wrote my message under the impression that it was suggested to change the semantics of the “avail” flag, which is currently defined as: The <fee:command> element also has an OPTIONAL "avail" attribute which is a boolean. If the value of this attribute evaluates to false, this indicates that the server cannot calculate the relevant fees, because the object, command, currency, period or class is invalid according to server policy. The key part here is “indicates that the server cannot calculate the relevant fees”. It should *not* imply that the command in question would be available for the given combination. I suggest that we simply truncate that paragraph to The <fee:command> element also has an OPTIONAL "avail" attribute which is a boolean. If the value of this attribute evaluates to false, this indicates that the server cannot calculate the relevant fees. It still has the potential for confusion with the semantics of “this command is available” rather than “we could calculate fees”. We could clear this up by renaming the attribute to “feeavail” (or anything less awkward than that, just something that does not collide with the “regular” avail attribute) ? If we keep it, my preference would be to keep it on the command level, because a registry might be able to calculate fees for one command in the set, but not for another, so it should be specific to a certain combination. Alex Alex> I think we need to be very very clear what the “avail” attribute on either of the levels imply. We should *really* try to stick to the purpose of this extension, which is about *fees*. In detail: - I think it would be highly confusing and redundant to have it at both levels. This would mean we have three instances of “avail” attributes in a check response (including the one from the “regular” check). - As i have said before, “avail” on the command level seems overarching to me, if this is supposed to indicate whether a certain command (with a certain period, a certain phase, and a certain currency?) is available at this point in time. That’s overlaying too many policy engine decisions, and sounds scary to me (besides that it has nothing to do with fees anymore – it’s wrapping in “more stuff”) - Then again, the “avail” attribute on the fee:objID would essentially be a 1:1 copy of the “regular” “avail” attribute – which is redundant too. Adding data to a machine-to-machine protocol just for the purpose of comfort seems weird to me. Therefore, thinking about all that, i suggest that we simply remove the “avail” attribute from the extension *unless* we find a really precise semantic definition of its meaning. We should keep the purpose of this check to *fees*, not make it a generic “policy query oracle” which command is available under which conditions. best, Ale
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
