Re: [regext] EPP Transport Service Discovery

[[e-mail]]

Hi Scott,

On 20.03.24 05:56, Hollenbeck, Scott wrote:
>> -----Original Message-----
>> From: Francisco Obispo<[e-mail]>
>> Sent: Wednesday, March 20, 2024 12:32 AM
>> To: Hollenbeck, Scott<[e-mail]>
>> Cc:[e-mail]
>> Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery
>>
>>
>> This is a neat idea,
>>
>> Is there a reasoning or use case for such need?
> [SAH] [snip]
>
> During today's WG meeting we discussed three proposals for non-TCP EPP transport. If any of them become standards and are implemented and deployed, a client will not be able to assume that tcp/700 is the only available transport. It will need to discover which transport is supported by every server it communicates with. That's the need.

[PK] I think the registries are pretty good these days in communicating 
such changes to their registrars *at the point in time of new feature 
introduction*. If a registrar would like to switch on a new transport at 
a later stage, when say X registries already offer it, it would have no 
other choice than digging through documentation of all of them 
(including those not yet supporting). So I see some use of a discovery 
at some point.

There is also discovery of other features built in EPP, like extensions 
supported, but I would be interested what is the current practice - 
would registrar automatically start using an extension just because it 
got announced? My past experience is that anyway it is off-band + read 
the doc.

But having a repository to refer to similar to RDAP may be useful for 
the first use case I outlined. But I don't have super strong feelings 
about it. There is no such repository for EPP server addresses and it 
seems to be no problem.

Kind Regards,

Pawel