Hello Roger, On 29/03/2017 16:05, Roger D Carney wrote:
> 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. Sounds good. > · 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. Indeed, the fees themselves should be a perfect match. Our current implementation uses a somewhat fuzzy comparison regarding application time, refundability and grace period though; if the registrar specifies them, any mismatch causes a fail response, otherwise the server assumes that the registrar "doesn't care" and lets the command succeed. > 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. I'd strongly prefer the second option, i.e. returning unavailable if a premium domain is checked without specifying further data. The general rationale here is that a "plain" <domain:check>'s availability result should always match the corresponding "plain" <domain:create>'s result. If a <domain:create> requires special fee-related measures to succeed, then the <domain:check> should require similar measures to return "domain available". > 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? As I wrote in an earlier mail, I don't believe having the avail attribute on both levels is needed. It could be moved to the framing element for each domain; if false, the element would not contain any <command> elements with pricing information, and if true, the element would only contain <command> elements that would have had avail=true in the fee-0.15 version. For example, this fee-0.15 response: S: <chkData xmlns="urn:ietf:params:xml:ns:fee-0.15"> S: <cd> S: <objID>premium-500.example</objID> S: <currency>EUR</currency> S: <command avail="false" name="create" phase="open"> S: <reason>the requested launch phase is not suitable for the domain</reason> S: </command> S: <command name="create" phase="custom" subphase="open-500"> S: <period unit="y">1</period> S: <fee applied="immediate" description="domain creation in phase 'open-500'" grace-period="PT1M" refundable="true">500.00</fee> S: </command> S: </cd> S: </chkData> could look like this instead: S: <fee:chkData S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.xx"> S: <fee:currency>EUR</fee:currency> S: <fee:cd avail="1"> S: <fee:objID>premium-500.example</fee:objID> S: <fee:command name="create" S: phase="custom" subphase="open-500"> S: <fee:period unit="y">1</fee:period> S: <fee:fee applied="immediate" S: description="domain creation in phase 'open-500'" grace-period="PT1M" refundable="true">500.00</fee:fee> S: </fee:command> S: </fee:cd> S: </fee:chkData> 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
