Hi Scott, On 20.03.24 05:56, Hollenbeck, Scott wrote:
-----Original Message----- From: Francisco Obispo<fobi...@tucows.com> Sent: Wednesday, March 20, 2024 12:32 AM To: Hollenbeck, Scott<shollenb...@verisign.com> Cc:regext@ietf.org Subject: [EXTERNAL] Re: [regext] EPP Transport Service DiscoveryThis 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
