Thomas, I agree that the class is at the domain-level attribute and not at the command-level attribute, that why it's placed as a sibling element of the objID element. The "standard" attribute was added at the command-level to support a mix of standard and non-standard fees for a non-standard domain name, which is the case for your "example.tld" example.
Now the language that you're focused on with " Servers that make use of this element MUST use a <fee:class> element with the value "standard" for all objects that are subject to the standard or default fee" really means that the fee is standard (e.g., standard="true") for all the commands of the domain name. I believe that you should continue to return "premium-1000" for example.tld, which helps the client understand that not all the commands have the standard fee even though they may query for just one of the commands. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/20/24, 6:55 AM, "Thomas Corte (TANGO support)" <thomas.co...@knipp.de <mailto:thomas.co...@knipp.de>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello Ryan, On 20.06.24 00:59, Ryan Jaeb wrote: > Hi, > > The end of section 3.7 says: > > " > Servers that make use of this element MUST use a <fee:class> element > with the value "standard" for all objects that are subject to the > standard or default fee. > " > > Does that forbid a response to a "check' command where > fee:class=standard alongside a fee:fee that is equal to the standard > fee for the TLD? For example, if the standard renewal fee for a > domain is $22 USD, is a "check" command allowed to respond with > something like: > > <extension> > <fee:chkData > xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> > <fee:currency>USD</fee:currency> > <fee:cd avail="0"> > <fee:objID>example.com</fee:objID> > <fee:class>premium</fee:class> > ... > <fee:command name="renew"> > <fee:period unit="y">1</fee:period> > <fee:fee > description="Renewal Fee" > refundable="1" > grace-period="P5D">22.00</fee:fee> > </fee:command> > </fee:cd> > </fee:chkData> > </extension> > > I have a domain where the "fee:class" has been changed from "standard" > to "premium" and I'm trying to understand what impact that has on me > and if it violates any applicable standards. Any input would be > greatly appreciated. In our own implementation of fee-1.0 (for TANGO), we interpreted the <fee:class> element as being the overall premium tier for the domain name, which may affect the fees for *some* operations (like create) but not others (like renew). Hence, it possible in our system to receive responses like <extension> <chkData xmlns="urn:ietf:params:xml:ns:epp:fee-1.0"> <currency>USD</currency> <cd> <objID>example.tld</objID> <class>premium-1000</class> <command name="create" phase="open" standard="false"> <period unit="y">1</period> <fee applied="immediate" description="domain creation in phase 'open'" grace-period="P5D" refundable="true">1000</fee> </command> <command name="renew" phase="open" standard="true"> <period unit="y">1</period> <fee applied="immediate" description="renewal" grace-period="P5D" refundable="true">9</fee> </command> </cd> </chkData> </extension> Where the class for the domain "example.tld" is "premium-1000" because its creation price is "premium" (1000 USD) while the renewal price is standard (9 USD). Registrars can still use the different "standard" boolean attributes in the <command> response elements to determine the individual "premium situation" for each command. It doesn't seem right to return a different <class> for the same domain depending on the command for which fees are inquired. Best regards, Thomas Corte -- 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 <mailto:supp...@tango-rs.com> Germany _______________________________________________ regext mailing list -- regext@ietf.org <mailto:regext@ietf.org> To unsubscribe send an email to regext-le...@ietf.org <mailto:regext-le...@ietf.org> _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
