On Fri, Dec 16, 2016 at 9:23 AM, Keith Gaughan <ke...@blacknight.com> wrote: > On 16/12/16 13:48, Andrew Newton wrote: > >> Both I and the IETF have been down the UDP as a domain availability >> service road before. See RFC 5144. Given that it rarely comes up in >> these conversations is probably a good indicator that such an idea is >> not successful. > > That wasn't successful because DCHK and IRIS aren't worth the pain to > implement, not that the idea isn't essentially sound. > > Better would be something akin to Nominet's DAC protocol: > > http://registrars.nominet.uk/namespace/uk/registration-and-domain-management/query-tools/dac/instructions
Again, the IETF has been there and done that. IRIS was originally specified using BEEP (see RFC 3983) to achieve the desire you mention above. BEEP is a multiplexing protocol, and at the time there were a few libraries that implemented it. Many people complained, hence RFC 4992. If there is a lesson to be learned here it is that you shouldn't go around inventing your own application transports unless you have a very large community of developers. I don't think this community counts. > > There's no need to over-engineer this stuff: use a persistent connection > and a simple wire protocol capable of pipelining requests to and > responses from the service, and a few custom request types for querying > the status of the connection and doing keep-alive. > I agree. Don't over engineer. Let's use something we know to have been broadly accepted, and that is HTTP/REST. If you want multiplexing, using HTTP/2. You're far more likely to find workable implementations of HTTP/2 than your own custom app-splicing protocol. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
