On 16/12/16 14:42, Andrew Newton wrote: > 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.
I remember BEEP, and it had the feel of a solution looking for a problem, even though - late-'90s, early-2000s XML fervour aside - it was a well-designed protocol framework. But it was a solution looking for a problem, and it didn't help that SOAP was around at the time. > Many people complained, hence RFC 4992. Here's a question: was BEEP really the problem, or was the problem really that IRIS itself never got enough traction? Because if IRIS got any traction, we wouldn't have needed RDAP. > 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. I don't disagree, but the protocol needs to serve the needs of the community. IRIS/DCHK didn't get traction because the various layers of it are complex: using it to do domain availability checks was like using a mallet to swat a fly, and all that implies. My point is that layering a DAC on top of something like IRIS or RDAP is overkill and introduces a layer of unnecessary complexity. This was especially a problem with IRIS because you're dealing with XML, and there's a good reason JSON got so much traction: XML is a pain to deal with. In a lot of ways, RDAP is fundamentally IRIS with JSON in place of XML. >> 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. In 99% of circumstances, I'd agree. This is not one of those, and, moreover, I don't think plonking it on top of RDAP helps. The nice thing about Nominet's protocol is that it's trivial to implement and you get pipelining for free if you want it. While it has its issues (a way to get a list of field names would be nice, and headers giving request and response lengths would be preferable to using CRLF as terminators), it fits its purposes very well. > You're far more likely to find workable implementations > of HTTP/2 than your own custom app-splicing protocol. K. -- Keith Gaughan, Development Lead; PGP/GPG key ID: D5FC9D23 Blacknight Internet Solutions Ltd. <http://blacknight.host/> 12A Barrowside Business Park, Carlow, R93 X265, Ireland Registered in Ireland, Company No.: 370845 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
