As people here are probably aware, there is a BOF for LURK which is to do with some form of remote keying (maybe).
Since the narrowest scope that might be decided for LURK is supporting TLS. I think there is going to be a lot of co-development and co-deployment. So it seems to me that LURK and ACME should look alike as much as possible and allow as much code re-use between the two. For me the consistency should ideally result from the same tool set to build the code. The proposal I have made for the LURK proposal is fairly comprehensive. It has a full text specification, a reference section describing the complete protocol and examples that were produced from running code: https://tools.ietf.org/html/draft-hallambaker-lurk-00 That draft was produced in three days, most of which was spent on the design and writing the prose. Developing specifications this way isn't just quicker, it is a lot less frustrating and error prone. It also helps get to implementations faster. For obvious reasons, I prefer to write in a modern language (C#). But the toolset also generates code for C. Adding a new target language takes about a week and some knowledge of the code synthesis system I am willing to share. So this doesn't just make creating the specification easier, it makes it much easier to get to production code that has to be written in target languages that match what currently exists. Which is why the issue of nested vs flat matters to me quite a lot. Yes, I could rewrite the code synthesizer to support a data format that allows the type of the data structure to appear as a field anywhere inside it. But it would mean creating what is essentially a whole new synthesizer just for ACME. And that would take about as long as writing a backend for a whole new language. And that work would then have to be repeated for every other target language. The nested style imposes fewer development constraints and allows for implementations that are more efficient in both time and memory footprint. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
