On Monday, July 1, 2024 2:54:55 AM PDT Davey Song wrote:
> Hi Paul,
>
> I’m sending this email off-list to respond to your comment.
in fact you cc'd the mailing list, so i shall do likewise in my reply.
> ... However, the fact is that DNS has been widely used
> as a direction system for a long time with lots of tricks though.
> Individual tricks build walls for interoperability.
sadly, no innovator ever earned equity by adding simplicity to a system. the
continuous result has been a series of negative externalities ("complexity
costs") for the rest of a community or industry.
> Our friend PVM thought
> that DNS could contain not only data but also programs in the future. What
> do you think?
noting that at the time javascript was first prototyped, there were a number of
existing languages intended for precisely this kind of embedding which were
not considered, any of which would have matured faster than javascript has
done. this should inform us that any language encoded into the DNS would be
found not-innovative-enough for some future equity-earner, and that continuous
re-invention will be the result no matter what then exists.
however, your question shows in-clarity in what i wrote earlier. i am in fact
advocating for putting something-like-a-program into the dns, to be consumed
by either recursive dns servers, or stub resolvers, or apps, or all three.
whether this is some kind of policy that describes how to learn load levels of
content mirrors, or how to learn CDN topology, or how to learn other metrics
-- doesn't matter to me. SPF shows a way to express policy as rules, but if
someone insists that it be tiny Lua or TCL or Scheme fragments, i won't treat
it as a proposal to a different need, only a proposal in a different format.
i'll have more to say in my reply to joe.
vixie
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
