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: +49 231 9703-222
Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200
D-44227 Dortmund E-Mail: [email protected]
Germany
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
