yes; and.. dns has always provided a point of indirection that is useful. dynamically rewriting markup might be infeasible.. and many fetch() like things are driven from script where the markup changes are not obvious or perhaps ill fitting.. and of course there are questions of cached content that might like to late bind. so lots to think about; but the markup example is very illustrative of a very conservative way of scoping things. perhaps too conservative. worth exploring. On Tue, Jul 10, 2018 at 11:02 AM, Adam Roach <adam@nostrum.com> wrote: > On 7/10/18 11:34 AM, Joe Abley wrote: > >> On Jul 10, 2018, at 17:22, Adam Roach <adam@nostrum.com> wrote: >> >> Basically, you're describing a solution space that could be realized as >>> something like: >>> >>> <img src="https://example.com/img/f.jpg" ip="192.0.2.1"> >>> >> Ok, interesting. I would suggest considering a richer scheme that >> accommodates address families and multiple addresses with priorities, >> but I see how that kind of thing would allow a client to do so >> certificate matching and resource retrieval without using the DNS. >> >> But this is really equivalent in just about every important way to >>> sending the normal <img src="https://example.com/img/f.jpg"> along with >>> a pushed DNS record that indicates that "example.com" resolves to >>> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >>> scope of the conversation that Patrick is proposing to have. >>> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit. >> > > In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". > > > /a >
Received on Tuesday, 10 July 2018 17:11:01 UTC