If I can restate the proposed TXT to RR strategy from yesterday (as
best I
understand it): define the MARID data independently of the record
type.
Define a new RR, and permit publishing of the MARID record in both the
new
RR and TXT. Data in the new RR supercedes anything found in TXT. If
this
approach works, then other working groups faced with a similar dilemma
will
have an example to follow. If it fails, they'll know to try a
different
migration strategy, and the Internet community will have learned
something
about how to approach the RR record problem.
A serious concern I have with the above is its testability.
With this approach we'd be asking people to code to an eventuality that
won't show up for years. Query for a new RR type first, and if not
there, query for TXT: the first case will virtually never hit for years
and years to come.
And there's a real cost to asking people to code to this: basically
double the DNS query cost for the foreseeable future. And the benefit to
be gained from paying this cost is what, architectural purity?
Looking back, I find that virtually all my professional life I have been
dealing with extensible and dynamically versioned systems, from OLE/COM
through many other things. And one thing I've learned if I've learned
anything is that, as much as I would wish it were otherwise, if it ain't
tested it doesn't work.
But that's exactly what we're asking people to do here: code to things
they can't really test. Not only that, to double their lookup costs in
the process.
I thus am of the personal opinion that the above articulated approach is
of academic interest only. Perhaps worse, I believe it falsely portrays
a potentiality and an architectural approach to versioning that will
never pragmatically actually be successful, and as such does an
educational disservice to the community.
But at least it's not fatally flawed, only misguided.
Bob