[TUHS] core

Tim Bradshaw tfb at tfeb.org
Tue Jun 19 01:33:57 AEST 2018

> On 18 Jun 2018, at 15:33, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> When you say "if implementation of the specification is too complicated it
> will fail", I think you mean 'the specification is so complex that _any_
> implementation must _necessarily_ be so complex that all the implementations,
> and thus the specification itself, will fail'?

Yes, except that I don't think the specification itself has to be complex, it just needs to require implementations be hard, computationally expensive, or both.  For instance a specification for integer arithmetic in a programming language which required that (a/b)*b be a except where b is zero isn't complicated, I think, but it requires implementations which are either hard, computationally-expensive or both.

> And for "in which case the specification which allowed the simple
> implementation will eventually become a problem", I think that's part of your
> saying 'you get to pick your poison; either the spec is so complicated it
> fails right away, or if it's simple enough to succeed in the short term, it
> will neccessarily fail in the long term'?

Yes, with the above caveat about the spec not needing to be complicated, and I'd say something like 'become limiting in the long term' rather than 'fail in the long term'.

So I think your idea was that, if there's a choice between a do-the-right-thing, future-proof (variable-length-address field) solution  or a will-work-for-now, implementationally-simpler (fixed-length) solution, then you should do the right thing, because if the thing fails it makes no odds and if it succeeds then you will regret the second solution. My caveat is that success (in the sense of wide adoption) is not independent of which solution you pick, and in particular that will-work-for-now solutions are much more likely to succeed than do-the-right-thing ones.

As I said, I don't know whether this applies to IP.


More information about the TUHS mailing list