DNS Based Proposal

[ericlucit]

This proposal allows 1 or more screen registries, and allows a screen owner to decide who and where their screen registry is.

The screen registry provides a discoverable data set of screens that the screen owner wishes to make discoverable

Let's say we have 3 objects

Screen
Screen Owner
Screen Registry

Screen owner decides "who/where" is the screen registry for their screens by creating a special DNS TXT record on their domain that can be queried

This TXT record contains a pointer to the DNS Endpoint of the Screen Registry that maintains the data for their screens

For instance coolooh.com may have a TXT record like OPENOOH_REG=coolooh.myprovider.com/open-ooh-registry

This registry contains a set of interfaces that allow programattic partners to query it for data about coolooh.com's screens

When CoolOOH goes to sign up for Some SSP they simply provide their company DNS name - Based on this, the SSP can query assets for this company

The standard we would then need to develop is

• What are the query interfaces
• What is the format of the data returned?

Then For any screen, they can be namedspaced with the name of the org that owns the screen. com.coolooh.{someUUID}

The other great thing about this is, given any screen id like com.coolooh.{someUUID} an SSP or a DSP can discover information about that screen by querying the TXT record for coolooh.com and finding the Screen Registry service that contains the data

What happens when screen status changes?
We can rely simply on HTTP status codes when you query the service for com.coolooh.{someUUID}

• Moved to another vendor (and now has a new ID?) - 301 Redirect
• 404 screen is gone forever
• 304 not modified if you send an eTag and just want to know whether or not any information about this resource has changed
• 503 could mean that the screen is offline

Etc. ETc.

[ericlucit]

Pros and Cons

Pros

• No central authority - As long as your screen registry provider adheres to the protocols for fetching the data, it can be any provider
• When a screen owner adds new screens, any SSP's they are already integrated with can automatically discover these assets
• Screen registries are automatically discoverable via a DNS query - You don't need to maintain a central database of these -
• Given any screen ID, you can figure out information about that screen by only knowing how to use the protocol
• Screen owners can change registries without issue. - Once they migrate their data, they only need to update their DNS records. Theoretically, there would not be a need to even notify the SSP's that they work with
• Screen registry can implement their software however they want to, they just need to adhere to the required external interfaces
• If a screen changes hands, we have a mechanism for redirect
• We have a mechanism for a middle-tier caching system to query the service to see if any information changed
• No ID collisions because they are namespaced via DNS (which is already guaranteed to be unique)
• Organizations already implement TXT records for lots of things like Email, Google Site Verification, etc. etc. - Adding another TXT record isn't a big hurdle.

Cons

• Technical hurdles to onboarding? -
• Can the information that must be provided by the screen registry be agreed upon? -
  -- Venue Category
  -- Location
  -- Format,
  -- etc.
• Are there concerns about making some information about a vendor`s screens public via the protocol?
• • In other words, does the service that provides screen information have to implement Auth of some kind?
• Without a central authority, we don't have great mechanisms to say "Show me a list of ALL screens within x miles of z"
• • maybe this is OK? - We don't have this today anyway

[jayshao]

My initial thought is... this may be too hard for publishers, especially smaller pubs. I also suspect our larger publishers will have multiple registries - if they are operating in multiple countries for instance, or have different rating agencies based on different types of assets.

While this would be similar to ads.txt and some of the digital standards (which is attractive) I think the difference there is the publishers generally are web publishers (and even there, getting adoption I think has required a lot of education)

I think we might be better off focusing on standards for screen registries... e.g. if I have an id - is there a standard format (a la extended ids from the proposed IAB spec) and/or a standard way to resolve from that id to other metadata, and a core set of schema of what metadata should be available (maybe a super-set of the openrtb fields?)

[ericlucit]

I think we might be better off focusing on standards for screen registries

I agree - Because, the screen registries are the critical cog. And, if you get major companies to set up screen registries, the procedure for the actual operator (media owner) becomes pretty simple actually.

If you just had 8 companies : Lamar, Clear Channel, Outfront, Apparatix, Blip, Billboard Planet, Watchfire and Daktronics to setup registries.... You would cover nearly every Large Format billboard in the US. Because they already have the data..

And then, think about the small screens - If you have to get 75% of them, how many unique companies hold that data currently? -

And since they have the data - The screen registries would essentially be self-updating as media owners add and remove assets in existing tools... (this is the critical part - And why the initial screen registries would have to be deployed by the software company that is the primary source of truth for inventory from the media owner)

Then - Any customer of theirs, simply adds the TXT record as provided by the registry (the media owners already have an ability to update DNS because they do it already for Email, Google Domain Verification, etc. etc.)

And the beaty of it is.....the standard is Open and Discoverable - Meaning...anyone can host a registry - So there is no barrier to innovation from new companies and tech entering the space.

So - Yes, agreeing on an ID format (that provides discoverablity of the asset) coupled with a minimal screen registry standard, you have something that would work worldwide..

Again - using DNS will simplify the process of finding screens and finding the registries - You don't need a central "authority" of screen registries. You just use existing infrastructure and protocols that identify that a company owns an asset.