> The classification is defined at the object level, where in general a > domain is either a “standard” domain or a non-“standard” domain (e.g., > “premium”, “discount”),
I agree, this was the opinion I raised at the start of this thread. > but there is an issue with non-“standard” > classification objects that is not handled by the <fee:class> element. I am still not convinced by this issue, nor by your solution to it. 2 registrars voiced their concerns on this case, but I would love to hear other opinions, including from registries, to make sure that something new and at the last minute is not bolted into a standard when it does not have widespread need. I am even not convinced that what you propose will help the business case put forward: since the "standard" attribute which is the core of the solution is optional per your suggestion if I read it correctly, registries will be free not to implement it in which case the business case being discussed here will remain without a solution on the field. So we will a protocol with an optional feature for some use case that maybe noone will use. Also, a registry that decides to implement this will have extra work to do for each command (like you said: "This requires the server to compare the “non-standard” classification fee schedule for each specified command against the “standard” classification fee schedule to set the appropriate “standard” attribute.") where maybe no client will be using this attribute (since it is optional, a registrar dealing with multiple registries will need to cope with various cases and know how to behave when the attribute will be absent). In short, I do not see a problem of having a reply with class='notstandard' for a given domain, and then a set of prices associated. Some of the prices there may be the same as some of the prices of a domain with class='standard' (like the case of a setup where creates are at a premium price but not later operations on the domain name). The registrar can make the difference between the two cases, not by comparing prices, but just because the first class will be 'notstandard' meaning that the domain is a premium one in some aspect which is what I understood is the need here. The name of the class could itself convey enough meaning for that. I believe that the extension is clear that the class is per-object and not per-command and hence there is not a standard vs non standard fee, which is clearly what others are attempting to reach. I do not believe you can achieve both goals at the same time. Like you said previously the subject may be too broad and accept multiple representation: I would prefer that we stick to one, which may appeal to some and not to others, instead of trying to accomodate too many disparate or even opposite goals. > If you have another proposal to address this use case, please share it. My proposal is to keep things as is, with the class at the object level. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
