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

["Thomas Corte (TANGO support)" <[e-mail]>]

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]
Germany