On 09Jan25, Edward Lewis apparently wrote: > One option (blue sky again) is to switch to an arrangement where the server, > for > synthetic or tailored responses, reply with a formula (function).
(Haven't we talked about this in previous threads?) I guess my first question is, what constitutes a synthetic answer? If the RRs are pulled from a database, is that synthetic? If the database uses stored procedures to modify the returned rows, is that synthetic? Above and beyond trivial synthesis such as wildcards and reverse query iterations, what constitutes synthetic answers is so broad as to ultimately require the client (I'll use this term to cover anything closer to the edge) to implement a programming language and be able to store data... a lot of data. One very common case is geolocation. How does a client generate the answer without having a fairly complete copy of the geolocation database? Another common case is service availability whereby the response is based on which endpoints can accept more requests. This is fairly dynamic data that all participating clients would need to refresh frequently. A third common case is split horizons which could be considered the primordial form of synthesis. Point being, any broadly useful client synthesis is a huge step up from mere wildcard expansion. In almost every case I can think of, the authoritative response will end up being the moral equivalent of a bundle of javascript and json or maybe an SQL statement and a database. So unless someone can codify a common and meaningful set of synthesis capabilities which a) don't require a lot of dynamic state and b) can be consistently implemented by many participating clients and c) doesn't turn clients into abuse targets for crypto hashing, then I suspect that you could expend a lot of energy defining very constrained client capabilities for very little benefit. On the bright side, end-point selection (which is the ultimate goal of synthesis, right?) is commonly implemented as HTTP redirects, so maybe the HTTP crowd have thoughts since they have far more experience dealing with high-capability clients. Mark. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
