Andreas, The point of the fee extension is to return the actual fee values, with the option of including a classification as a hint to the client of the fee schedule being used for the object (domain). There is no concept of a “standard” or “non-standard” fee, but a “standard” or “non-standard” object (domain). What classifications (one, both, or none) would be returned for a renew if there were two “non-standard” classifications (e.g., “gold” and “silver”) with the same renew fee that does not match the “standard” renew fee? There is not a single fee for a command, but a fee for the combination of the command and the supported periods. Defining a classification at the command and period level adds a whole new level of confusion and complexity for the client and the server.
Maybe the concept of fee classification in general is too vague where there is no one fee classification data model on the server-side and there is certainly not a single fee processing model on the client-side to come up with a standard definition and protocol to support it. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/16/17, 4:16 PM, "regext on behalf of Andreas Huber" <regext-boun...@ietf.org on behalf of ahu...@united-domains.de> wrote: Hi all, <fee:class> should be under <fee:command>. I have the same points than Pat. We do not need to know if a price of a single command *COULD* be non-standard. Thats the same as completely skipping <fee:class>. Indeed, what I really need, is to know if a single fee is "standard" or "non-standard" priced, because we do a completely different processing of premium and standard (or promotion) fees. While registries had premium fees for create, renew and transfer, this wasn't a big thing, but since most registries switch to premium create with standard renew fees, we need to differentiate. So, I would suggest to clarify section 3.7 and change it to fee level. To save some bytes in the check response, <fee:class> with "standard" could be assumed as default and therefore optional, but mandatory if non-standard (premium, promotion, etc.). Another solution would be to not transmit standard fees in the fee extension at all. Thanks, Andreas Am 16.11.2017 um 04:44 schrieb Gould, James: > Pat, > > > > I will go back to the definition of the classification, which is an object-level attribute (e.g., “standard” or “premium” domain). Each classification has a fee schedule (commands and periods) that is assigned at the object-level, where the combination of the command and the period has a fee and not a classification. The classification (<fee:class>) should be placed in the location that reflects the definition to remove any confusion, which is under the <fee:cd> element. > > > > — > > > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
