Thanks Thomas,
> On 21 Feb 2025, at 13:28, Thomas Corte (TANGO support)
> <thomas.co...@knipp.de> wrote:
>
> Hello,
>
> On 21.02.25 13:24, Gavin Brown wrote:
>
>> I think this could definitely cause issues for EPP clients which expect to
>> only ever see one <rgpStatus> in responses from servers. I suspect (but do
>> not know for certain) that it's rare for EPP clients to validate server
>> responses using the schema,
>
> The (homegrown) XML toolkit we've been using for our EPP client
> implementations usually does perform schema validation, but when we started
> dealing with ccTLDs, we had to introduce a switch for turning it off, as
> there were too many issues with invalid server responses.
>
>> and so any EPP client that does
>> document.getElementsByTagName("rgpStatus").item(0).getAttribute("s") to
>> obtain "the" RGP status for the domain may get tripped up if the first
>> element happens to not have the expected status value.
>
> I'd estimate the chances of two status values actually appearing in a
> real-life scenario pretty low,
> with the example from my previous e-mail being a rather exotic one.
It may be "exotic", but if you have to deal with lots of domains (either as a
registry or a registrar) it will happen. I myself have registered a domain and
then decided to renew it straight afterwards.
The reason why I discovered this issue is that the new RST v2.0 service ICANN
is building (OT&E now available! Email me to get access) does a lot of "exotic"
things. For example: for the EPP <renew> test case, we create a domain solely
so we can then immediately renew it, and then do an <info> command to check for
the "renewPeriod" status. An EPP server that only supports a single RGP status
then has to decide *which* status to return, and it may well return the wrong
one, through no fault of its own.
G.
>> It would be useful to hear from some EPP client implementers who have
>> experience with talking to a wide range of servers, as we know that both
>> models (one vs many) are out there in the wild.
>
> I checked the code of our two major client applications (originating from the
> early 2000s), and realized that (while our toolkit does support reading them)
> we never saw the need to actually evaluate the rgpStatus values in server
> responses. ¯\_(ツ)_/¯
>
> I guess the reason is that certain decisions, i.e. whether or not to grant
> refunds for deletions, had to be implemented way before the RGP extension was
> even available, so we opted for a purely time-based solution ("within 5 days
> of creation?") back then.
>
> 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: supp...@tango-rs.com
> Germany
>
>
> _______________________________________________
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org
--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)
https://www.icann.org
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
