> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Hollenbeck, Scott > Sent: Thursday, March 21, 2024 1:53 AM > To: g...@algebras.org > Cc: regext@ietf.org > 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. > > > -----Original Message----- > > From: George Michaelson <g...@algebras.org> > > Sent: Wednesday, March 20, 2024 11:00 PM > > To: Hollenbeck, Scott <shollenb...@verisign.com> > > Cc: regext@ietf.org > > 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.
[SAH] Most importantly, we need to remember that while EPP is currently used primarily by the domain name industry, it's not limited to use in that industry. We can't assume that registry-registrar norms are universal. Service discovery is thus part of the price we're going to have to pay if we specify new transport mappings. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext