Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?
Hello, On 6/26/20 16:18, Gould, James wrote: > The goal is to cover the case of a client not passing the fee extension at > all, with the assumption that the fee extension would reference the create > command. It's simpler to make the case based on the existence or > non-existence of the fee extension in the check command, but there may be > cases were the renew fee matches the create fee. It's up to the server to > determine whether a particular domain will fail on create without the client > having the correct non-standard fee. I realize that there are corner cases > where the client may know the fee, based on assuming that the create fee > matches the renew fee, or the fees are provided out-of-band to EPP, but to > cover the intent of the RFC the safest approach is to return avail="0" for a > premium domain if the fee extension is not passed in the check command. > > The server MUST return avail="0" in its response to a command > for any object in the command that does not include the > extension for which the server would likewise fail a > domain command when no extension is provided for that > same object. Another clarifying question: the above only needs to happen if the client at least signaled its general understanding of the fee-1.0 extension in the EPP command, correct? Otherwise (i.e., if the server needs to report premiums as unavailable even to clients who are not aware of fee-1.0), this RFC would be asking for a change in a server's behavior just by virtue of introducing support for fee-1.0, which would mean that clients not using any fee extension (or an older version which didn't yet have this requirement) would see an unexpected code-breaking change, no? Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@knipp.de Germany ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Document and Milestone Discussion at IETF108
Listed below are 8 working group documents currently on our task list. Only one has a presentation slot for IETF108 as technical work has progressed and will be discussed. In all cases, the co-Chairs will take the time to open a discussion of the status of each document. As everyone knows, work only moves forward if we agree, as volunteers, to progress the work. Document authors will be given a minute to speak to the following questions about their document. * What work needs to be done before this can be submitted for publication? * Are there implementations or plans for implementations? * Who will be your document shepherd? If you have one you’re all set, if not please find one. * If there is going to be work, what date should be on our milestone list? Please, everyone, document authors and working group participants, consider these questions before the meeting. Please feel free to start a thread regarding your favorite document with answers to 1 or more of the above questions, especially if you aren’t able to attend the meeting but would like your input considered during the discussion. https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/ Roger Carney, Jody Kolker https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/ Scott Hollenbeck https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ Mario Loffredo, Maurizio Martinelli https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/ https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/ Scott Hollenbeck, Andy Newton https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/ James Gould, Rick Wilhelm https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/ Joseph Yee, James Galvin https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/ James Gould, Martin Casanova Thanks to all! See you on Friday, 31 July, at 1100 UTC! Antoin and Jim ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Document Status: draft-ietf-regext-rfc7483bis
* What work needs to be done before this can be submitted for publication? I'm not aware of any open issues. It may be ready to be submitted now. * Are there implementations or plans for implementations? Yes, they are described in the document. * Who will be your document shepherd? If you have one you're all set, if not please find one. Jasdip Singh. * If there is going to be work, what date should be on our milestone list? That depends on whether or not people we think the document needs more work. Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Document Status: draft-ietf-regext-rfc7482bis
* What work needs to be done before this can be submitted for publication? I'm not aware of any open issues. It may be ready to be submitted now. * Are there implementations or plans for implementations? Yes, they are described in the document. * Who will be your document shepherd? If you have one you're all set, if not please find one. Mario Loffredo. * If there is going to be work, what date should be on our milestone list? That depends on whether or not people we think the document needs more work. Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Document Status: draft-ietf-regext-rdap-openid
* What work needs to be done before this can be submitted for publication? I've been waiting for outputs from ICANN's EPDP process to confirm that I have the right set of claims described in Section 3.1.4. We can either adjust the currently described set, declare victory and go with them, or continue to wait. * Are there implementations or plans for implementations? Yes, and they are described in the draft. * Who will be your document shepherd? If you have one you're all set, if not please find one. Zaid AlBanna has agreed to shepherd the document. * If there is going to be work, what date should be on our milestone list? The current March 2021 date is fine unless we decide to not wait for ICANN inputs. Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
