[regext] Re: RFC 8748 (EPP Fee Extension): issue with mixed signals regarding standard prices?

["Gould, James" <[e-mail]>]

Thomas, 

That would be a good topic for IETF-126.  

In thinking about the split of the <fee:class> element and the <fee:command> "standard" attribute with a default value of "false", the <fee:class> element is directly associated with the classification of the domain name at the object-level.  A server may have a list of premium domain names that would not return a <fee:class> of "standard".  The <fee:command> "standard" attribute could be non-standard for a "standard" class domain name to cover cases like a promotion fee for a command and period.  The typical case for a <fee:class> "standard" domain name is returning "true" for all the <fee:command> "standard" attributes, but there are cases where the "standard" attribute is not "true" for a "standard" class domain name.  The server should be careful to be clear to the clients, where there should be no assumption by the class that all billable commands with be "standard" for a "standard" domain name.  I recommend the server returning the "standard" attribute for all of the returned <fee:command> elements and not rely on the XML default value.  

I know that we had some deep discussions on the mailing list about this, so it would be great to hear from other servers on how they handle the <fee:class> element and the <fee:command> "standard" attribute values.

Thanks,

-- 

JG 



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 




On 4/21/26, 1:09 PM, "Thomas Corte (TANGO support)" <[e-mail] <mailto:[e-mail]>> 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,


picking up the discussion I tried to start about this in March (see my full original e-mail below),
I'd like to propose putting this topic on the agenda for the upcoming IETF meeting in Vienna, as 
suggested by Gavin Brown after I discussed this with him.


To summarize, I believe the fee-1.0 EPP extension, as it is now, invites confusion by defining two 
ways of declaring "standard" pricing, namely 1) via the <fee:class> element and 2) via the 
"standard" attribute in the <fee:command> elements or a fee check response.


The problem arises from the fact that the XSD defines the "standard" attribute on <fee:command> as 
defaulting to "false" if not present:


<attribute name="standard" type="boolean" default="0" />


So if this attribute isn't there, a client needs to assume a *non-standard* price for this command.


Now, in many fee-1.0 implementations I've seen (like Radix's or Google's), registries will return 
(for standard domains)


<fee:class>standard</fee:class>


but *omit* the "standard" attribute on the <fee:command> elements, like this:


<fee:chkData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
<fee:currency>USD</fee:currency>
<fee:cd avail="1">
<fee:objID>test456.website</fee:objID>
<fee:class>standard</fee:class>
<fee:command name="create">
<fee:period unit="y">1</fee:period>
<fee:fee description="Domain registration (per year)" refundable="1">20</fee:fee>
</fee:command>
</fee:cd>
</fee:chkData>


A conservative EPP client would therefore have to assume *non-standard* create pricing, which is 
surely not meant here. This leads to needlessly asking customers for price acceptance, just to be on 
the safe side (as they shall not accidentally buy a premium domain).


I guess a simple fix would be to remove the default="0", meaning that the attribute has no default 
and will therefore no longer contradict the object class if omitted (which was probably the original 
intention).


Note that I contacted Google Registry about this issue, and they replied


"Hi Thomas,


Thank you for updating us with the results of your test.


Please be advised that our omission of the standard attribute on the <command> element is 
intentional, since the RFC clearly says it is optional."


So there's evidence for confusion arising from the RFC as currently specified.


Best regards,


Thomas Corte


On 16.03.26 11:45, Thomas Corte (TANGO support) wrote:


> Hello,
> 
> while testing our connection to the upcoming registry migration to Radix's server (e.g. 
> for .website), I've come across an apparent issue with mixed signals regarding standard prices.
> 
> This check
> 
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> <command>
> <check>
> <check xmlns="urn:ietf:params:xml:ns:domain-1.0">
> <name>test456.website</name>
> </check>
> </check>
> <extension>
> <check xmlns="urn:ietf:params:xml:ns:epp:fee-1.0">
> <command name="create">
> <period unit="y">1</period>
> </command>
> </check>
> </extension>
> </command>
> </epp>
> 
> yields:
> 
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> <response>
> <result code="1000">
> <msg>Command completed successfully</msg>
> </result>
> <resData>
> <domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> <domain:cd>
> <domain:name avail="1">test456.website</domain:name>
> </domain:cd>
> </domain:chkData>
> </resData>
> <extension>
> <fee:chkData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
> <fee:currency>USD</fee:currency>
> <fee:cd avail="1">
> <fee:objID>test456.website</fee:objID>
> <fee:class>standard</fee:class>
> <fee:command name="create">
> <fee:period unit="y">1</fee:period>
> <fee:fee description="Domain registration (per year)" refundable="1">20</fee:fee>
> </fee:command>
> </fee:cd>
> </fee:chkData>
> </extension>
> <trID>
> <svTRID>d412f731-84d4-4de5-9c5a-c04d899763ac</svTRID>
> </trID>
> </response>
> </epp>
> 
> Observe that the
> 
> <fee:class>standard</fee:class>
> 
> element indicates standard pricing as defined by RFC 8748:
> 
> "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."
> 
> However, the element
> 
> <fee:command name="create">
> 
> doesn't carry the "standard" attribute, which unfortunately is defined by the RFC as
> 
> "This element MAY have the OPTIONAL "standard" attribute, with a default value of "0" (or
> "false"), which indicates whether the fee is the standard or default fee."
> 
> Now, the <fee:class> element tells an EPP client to regard the price as "standard", however the 
> lacking "standard" attribute (defaulting to false) tells the client that the prices in *not* standard.
> A conservative approach preventing customers from unknowingly buying premium domains would assume 
> non-standard pricing here, which is not what Radix's server wants to express.
> 
> While our own TANGO EPP server would return both <fee:class>standard</fee:class> and <fee:command 
> name="create" standard="true">, I wouldn't call Radix's implementation here faulty per se, as it is 
> allowed by the RFC. But it still confuses diligent clients.
> 
> I think the issue here lies with the RFC, which defines not one but *two* ways to signal standard 
> pricing, and doesn't clearly demand that they need to agree.
> I therefore believe that a correction of the RFC is in order, either by getting rid of one of the 
> signals, or by making one the definitive one (preferably the "standard" boolean attribute, with the 
> <fee:class> class remaining but being purely informational).
> 
> Thoughts?
> 
> Best regards,
> 
> Thomas
> 


-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: [phone]
Martin-Schmeisser-Weg 9 Fax: [phone]
D-44227 Dortmund E-Mail: [e-mail] <mailto:[e-mail]>
Germany




_______________________________________________
regext mailing list -- [e-mail] <mailto:[e-mail]>
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>