Hello Roger, all, (sorry for the crappy HTML format, my responses tagged below with "Alex>"
A few of the items that we resolved Monday include: * Simplifying the <check> request by removing the <fee:object> from the extension. This is more in line with Option C from last year's discussions. It does eliminate some flexibility that v0.15 provided. But generally everyone agreed that the flexibility was not worth the expense and that it in practice many preferred the simple approach. Alex> I agree to this. It seemed wasteful to have the fee:object there, and in my discussions with registrars i found out there are very few corner cases in which you would do a fees check for just a selected subset of the domains "checked" in the "regular" check section. * Agreement on failing a create when the passed in fee is not equal to or greater than what the server expects. Language will be added. Alex> Yes, please. Allowing a transaction through when the "bid" is not sufficient is plain dangerous. * Agreement that balance information in the <check> response is not desirable. Alex> Fine with me - i understand it can have serious performance impacts in some installations, and i also understand that the balance check and the object check might not be relevant to the same "departments" of a registrar. One topic that was not resolved was around the <check> response when the domain(s) are premium (a label that will require fee data on the <create> command to succeed) and no fee extension data is passed by the client. There were two main thoughts on this: * If a premium domain is available then it should return available if no fee extension data is provided in the request. * Returning unavailable was discussed for a couple reasons. First if no fee data is passed in the <check> and you return available and then the client tries to do the <create> with no fee data (assuming since they did not provide in the <check> they will likely not provide in the <create>), the <create> would fail. Along with this it was discussed that there are and will be many registrars that do/will not participate in premium sales (not using the fee extension). The thought is that returning unavailable will provided a much better backwards compatibility experience. Alex> I'm still for returning "unavailable", because from what i've heard registrars who support the fee extension are typically adding it to each check they do anyways. Which means that only those registrars do *not* add the extension who wouldn't be able to supply the required extension in the subsequent "create" command anyways. Since "available under certain conditions" is not an option, i'd rather tend to "unavailable", with a reason of "fee extension required". Another topic discussed at Monday's session and being discussed on list revolves around the optional fee avail flag and its scope within the <check> response. Currently (v0.15) the optional fee avail flag is at the <fee:command> level. Several have suggested moving this up one level to the <fee:objId> level mostly in order to provide a more efficient way to fail fast. Others like the current (v0.15) solution as it provides more details around the issues causing the false response. I wonder if we provide this optional flag at both levels? 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, Alex
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
