ERN messages as a statements of truth

DDEX messages are “Statements of Truth”.

… or, rather, a “statement of truth as known, to the sender, at the time of sending”.

For ERN this means that a sender of a NewReleaseMessage must always include all relevant information in the message, including all metadata and all active and future deals that it has communicated in the past.

This means for a company receiving a NewReleaseMessage that if a message about a specific Release is received, all previously-received information becomes invalid and is replaced by the information in the new NewReleaseMessage.

This also means that if, for example, the metadata for a Release needs updating, all deals need to be re-sent. And, conversely, if a deal is to be added or updated, all Release/resource/party metadata will need to be re-sent.

Exception: communication of binaries

There is one exception to this rule: When updating the information in the NewReleaseMessage there is no need to also send the binaries. More information on sending binaries can be found here.

Reason

When considering different approaches on how a record company should communicate new deals to a DSP, we identified four critical use cases: 

  • A record company may need to add a new deal to the list of deals already communicated (either for a new country, a new use type or even a new price point);

  • A record company may need to replace one or more deals that have already been communicated;

  • A record company may need to revoke one or more deals that have already been communicated;

  • A record company may need to completely take down one or more Releases.

DDEX identified two possible approaches to addressing these four cases:

  1. The record company could always send all deals that are either active at the moment or may become active in the future; or 

  2. The record company and DSP would need to keep track of all deals that have been sent in the past and the standard would need to have the ability to update/cancel/revoke existing deals (e.g. by using some a unique identifier for deals).

DDEX selected the first solution because it is simpler to implement and the problem of losing a message in transit (or because a DSP may have chosen to not ingest a specific ERN message) becomes less of an issue. 

More information on take-downs can be found here and here.

Search