Good Morning, We had a very productive meeting at our IETF-98 Monday session.
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. * 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. * Agreement that balance information in the <check> response is not desirable. 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. Please share your thoughts on the premium <check> response when no fee extension data is provided by the client. 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? I have started work on v3 (0.17) of the draft with these changes in mind. Also, please let me know if I missed anything from Monday's discussions. Thanks Roger
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
