Re: [regext] EPP Transport Service Discovery

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: George Michaelson <[e-mail]>
> Sent: Wednesday, March 20, 2024 11:00 PM
> To: Hollenbeck, Scott <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe.
> 
> I very much tend to believing that SVCB is the way to do this. Not to emebed,
> not to invent, to use the existing mechanisms to find transports with flagging
> to rank server side preferences.
> 
> This also serves to bootstrap TLS and so is a "two birds with one stone"
> solution.
> 
> * its how other applications do it
> * it works
> * it can direct you into a secure transport without the transition through
> insecure state (mostly, as I understand it)

[SAH] Thanks, George. I understand that "word of mouth", or "described in an agreement", information exchange has worked in our current tcp/700-only operating environment. What got me thinking is the possibility of a server operator that supports multiple transports. Which one should a client choose? Is one preferred over the other? A service discovery protocol would allow us to answer those questions in-band. I recognize that the answers will generally remain static, and out-of-band communication may suffice. Since we're now giving serious consideration to additional transport mappings, though, we need to challenge the status quo bias. I'd really like to understand if there are environments in which clients and servers are more loosely coupled, too.

Scott