> So the interesting part here is not supposed to be querying dns data from the client side of a website, but a new standard for machine readable data in TXT re

> So the interesting part here is not supposed to be querying dns data from the client side of a website, but a new standard for machine readable data in TXT records? Correct > I mean between microdata, rdf, etc there's been a lot of standards for machine readable data storage on the internet. Most fail not for technical reasons, but because there is an incentive mismatch, where the people who have to maintain such data get no benefit out of maintaining it so they don't bother. I'd argue the inconsistent way these standards have been adopted (or not in many cases) is the reason they are not an effective, reliable way for developers to find machine-readable data about _any_ business. Since they are not a reliable way to find data, developers can't build anything with that data and there's little incentive for companies to keep it up to date. Currently, the only reason to adopt these standards is for SEO or to make your website look pretty when you share your website on Facebook / whatever. > In this scheme you can't even google it, so why would a company bother to use this? Google hold a lot of the data we're proposing to publish using NUM (contact data for example). The difference between our approaches is that we're going to make it freely available to developers, Google don't (not really). Google could consume NUM data like anyone else. As far as the protocol is concerned Google is the same as any other developer so it's a level playing field.