DDEX Standard

Skip to end of metadata
Go to start of metadata

 

 

This section of the DDEX Knowledge Base contains Version 4.1.1 of the "Electronic Release Notification Message Suite Standard"

1 Introduction

This standard was developed by the member organisations of the Digital Data Exchange, LLC (DDEX) and provides a suite of messages that give a uniform mechanism to enable Release Creators (usually record companies) to inform DSPs about Releases — whether they are newly created or “back catalogue” — that are available for distribution to consumers.

This standard also enables Release Creators to inform DSPs in a standardised way the terms and conditions under which such Releases can be made available.

Any organisation wishing to implement this (or any other DDEX Standard) is required to apply for an Implementation Licence. The terms of the licence and an application form can be found at http://ddex.net/implementing-ddex-standards


 

2 Scope

 2.1 Introduction
The suite of messages contained in this Standard provides a mechanism for Release Creators (usually record companies) to inform their distribution partners (herein called Digital Service Providers (DSPs) about Releases that can be made available to the public as electronic Products. Such Releases can include, amongst others, Releases for mobile use, Releases for download under pay-as-you-go, advertisement-supported and subscription models, streaming models and audiovisual Releases.

The messages will allow such standardised information flow about the Releases themselves (i.e. Release metadata) as well as information about the commercial terms under which such Releases can be made available.

Sending or receiving a message using this standard cannot be presumed to indicate, however, that all legal obligations are met for the Releases to be legitimately made available.

 2.2 Organisation of the Document
This standard has six clauses and one annex. Clause 1 and 2 provide a general introduction and the scope of this standard. Clauses 3 and 4 give a set of normative references as well as terms, definitions and abbreviations that are used in this Standard.

Clause 5 provides an overall choreography for sending and receiving the messages defined in this standard. Clause 6 then specifies the messages defined in this standard, and their descriptions as they appear in the DDEX Data Dictionary.

Annex A then provides informative notes about this version of the standard, indicating the features new to this version of the Electronic Release Notification Message Suite Standard.

3 Normative References

 3 Normative References
The following normative documents contain provisions, which through reference in this text constitute provisions of this Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
  • DDEX: Data Dictionary Standard. Latest Version.
  • DDEX: Party Identifier (DPID) Standard. Latest Version.
  • IFPI: Global Release Identifier (GRid) Standard. Latest Version.
  • IETF RfC 5646: Tags for Identifying Languages. Latest Version.
  • ISO 639-1988: Code for the representation of the names of languages.
  • ISO 3166-1:1997: Codes for the representation of names of countries and their sub-divisions – Part 1: Country codes.
  • ISO 3901:2001: Information and documentation – International Standard Recording Code (ISRC).
  • ISO 4217:2001: Codes for the representation of currencies and funds.
  • ISO 7064:1983: Data Processing – Check Character Systems.
  • ISO 8601:2004: Data elements and interchange formats – Information interchange – Representation of dates and times.[1]
  • W3C: XML Schema Part 1 - Structures. Second Edition. 2004
  • W3C: XML Schema Part 2 - Datatypes. Second Edition. 2004


[1] Information on ISO 8601 can be found in Annex D of Part 2 (Datatypes Second Edition) of the XML Schema standard (http://www.w3.org/TR/xmlschema-2/#isoformats).

4 Terms and Abbreviations

 4.1 Terms and Definitions

Contractually Mandatory

An entity in a DDEX Message that has the technical cardinality of 0-1 or 0-n but that is mandatory when a DDEX message is sent in a specific commercial context.

Contractually Mandatory fields may, however, be mandatory when a DDEX message is sent in a specific commercial context. In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by Message Sender and Message Recipient.

Digital Service Provider (DSP)

A Digital Service Provider (DSP), a Party making Releases available to Consumers or other DSPs over a public Telecom network. This includes MSPs (Mobile Service Providers) and ISPs (Internet Service Providers). 

Main Release

A Release, communicated in a Release notification that represents the main purpose for sending the NewReleaseMessage. When communicating an album, the Main Release would be said Album Release. A typical NewReleaseMessage contains, besides the Main Release, one or more Track Releases.

Musical Work

A Work intended to be perceivable as a combination of sounds, with or without accompanying text.

Any words that are intended to be expressed with a MusicalWork (often termed Lyrics) form part of that MusicalWork; not all MusicalWorks have Lyrics.
A MusicalWork may be expressed and fixed to become part of a SoundRecording or a Video Recording, or may be used to create notated music (sheet music, scores, instrumental parts) or sound generation codes (such as MIDI files).
In some cases, the MusicalWork comes into existence simultaneously with its expression. This is common in extemporised forms such as jazz music.

Product

A Manifestation of a Release (or another Resource) which is made available to Consumers, by sale, loan or other means. The attributes of a Release in its digital manifestation as a Product may be technical (e.g., the codec or bit rate); a mode of distribution (e.g., downloading or streaming); or a commercial term (e.g., price).

Profile

A subset of a DDEX standard. Profiles define how to use the capabilities of a DDEX standard in a specific commercial context.

Release

A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.

Release Creator

Release Creator is an organisation which is the owner of copyrights in sound and/or music audiovisual recordings and/or exclusive licensees of copyrights in sound and/or music audiovisual recordings.

Release Distributor

Release Distributor is an organisation, which is duly authorised by a Release Creator to offer Releases manifested in the form of Products to consumers. Release Distributors include Digital Service Providers (DSPs) and Mobile Service Providers (MSPs) as well as other organisations.

Resource

A digital fixation of an expression of an abstract Work (such as a sound recording, a video, an image, software or a passage of text). Resources are individual assets that make up a Release. Typical Resources are sound recordings, video clips and cover art images.

Track Release

A Release, communicated in a Release notification that does not represent the main purpose for sending the NewReleaseMessage. When communicating a 10-track album, a typical NewReleaseMessage would contain, besides the Main Release, ten Track Releases (i.e. one for each sound recording that together make up the album).

 4.2 Abbreviations
AMEPAutomated Message Exchange Protocol
ACAAppointed Certification Agency
AVSAllowed Value Set
BPBusiness Profile
CISAC

Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation
DDEX

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol  (HTTP specifically includes HTTPS)
HTTPSSecure Hypertext Transport Protocol
IECInternational Electrotechnical Commission (see iec.ch)
ISOInternational Organisation for Standardisation (see iso.org)
MIMEMultipurpose Internet Mail Extensions
MLCMusic Licensing Company
MWLMusical Works Licensing
MWNMusical Works Notification
MRBV

Multi-Record-Block Variant

PCAPrivate Certification Agency
PDFPortable Document Format
RESTREpresentational State Transfer
RINRecording Information Notification
SFTPSecure FTP
SRBV

Single-Record-Block Variant

TISTerritory Information System (a CISAC Standard)
TLSTransport Layer Security
UGCUser-generated content
URLUniform Resource Locator
XMLeXtensible Markup Language
XSDXML Schema Definition
W3CWorld Wide Web Consortium (see w3c.org)
WSWeb Service

5 Message Choreography

 5 Message Choreography
Figure 1 shows the choreography of the processes that the Electronic Release Notification Message Suite Standard enables. The specific means by which these messages are communicated not defined here.


Figure 1 — Choreography of the Electronic Release Notification Message Suite

 

Table 1 below summarises the point in the release cycle when each message is sent. The table also indicates who sends which message to whom and which of the messages are defined in this Standard.


Table 1 — Messages in the Electronic Release Notification Message Suite

Message Name

Initiating Event

Sender

Recipient

1

NewReleaseMessage

The Release Creator decides to make a Release available to the market and collates all necessary information about the Release. This does not necessarily include information about the commercial conditions under which the Release may be made available.

Release Creator, typically a record company

Release Distributor, typically a DSP

The Release Creator has decided on the commercial conditions under which the Release may be made available.

The Release Creator wishes to communicate updates to the metadata about the Release and/or commercial conditions.
2PurgeReleaseMessageThe Release Creator gains knowledge of a corrupt Release in the systems of a DSP that cannot be taken down simply by using the NewReleaseMessage.Release Creator, typically a record companyRelease Distributor, typically a DSP
A Release Creator wishes to completely remove a Release from a DSPs offering.

6 Message Definition

 6.1 Namespace
The full namespace for the XML Schema document for this standard is
http://ddex.net/xml/ern/411

All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary available from kb.ddex.net.

 6.2 Allowed-value Sets
All messages defined in this standard make intensive use of allowed-value sets. These allowed value sets are shared between all DDEX standards and DDEX provides a XML Schema Definition file for all of these allowed values. These values are also contained in the DDEX Data Dictionary available from kb.ddex.net.

The full namespace for the XML Schema document for the allowed-value sets is

http://ddex.net/xml/avs/avs

DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list are issued on a date later than the date on which this Standard is issued but still may form part of this Standard. Thus the list of allowed-value sets provided Clause 6.6 contains the list of allowed-value sets valid on the data of issuance of this standard.

The allowed values are listed, defined and provided through the DDEX Data Dictionary Standard in accordance with its latest version. Other values are not possible unless by using the mechanism described below.

Some of the allowed value sets contain a provision to either use a User Defined Value instead of a DDEX-defined value (in that case the message sender has to select the value UserDefined from the AVS and provide its own value in the XML attribute UserDefinedValue), or to augment a DDEX-defined value (in that case the message sender may not select the value UserDefined from the AVS but shall provide its additional information in the XML attribute UserDefinedValue). In either case the Namespace attribute shall be used to indicate by whom the UserDefinedValue is defined and where it is maintained.

 

 6.3 Describing Exploitations of Releases
In DDEX messages, message senders can use three allowed value sets to describe how Releases can be (or have been) exploited. They are:
  • ReleaseType (of the Main Release);
  • UseType; and
  • CommercialModelType.

The ReleaseType categorises the Release from the point of view of the Release Creator. For example, a Release Creator may create a Release for use as a ring-back tone on a mobile phone. This is distinct from the UseType which describes what a consumer is allowed to do with a Release. For example, a Release created as a “normal” digital album, might still be used as a ring tone.

The third dimension, the CommercialModel type describes how consumers pay for the Release, whether the transactions are based on subscriptions or whether the consumer pays directly for each Release received.

 6.4 General Conformance Rules

 6.4.1 Schema Validation
A message is conformant to this specification only when it validates against the set of XML Schema files provided.
 6.4.2 Namespace Attributes
The Namespace attributes can be used to enable message parties to use proprietary values or identifiers.

The recommended value to be used for the Namespace attribute of an allowed value set field is the DDEX Party Identifier (as defined in, and administered in accordance with the latest version of the DDEX Party ID Standard) of the party controlling the proprietary allowed value deletion.

The recommended allowed value to be used for the Namespace attribute of a proprietary identifier is the DDEX Party Identifier of the party controlling the proprietary identifier.

 6.4.3 Indicating Unknown Values
When the Message Sender is required to provide a data element but cannot do so, the following values shall be entered:
  1. In fields of type xs:string: “#unknown#” ;
  2. In fields of type xd:date: “9999-01-01”;
  3. In fields of type xs:datetime: “9999-01-01T99:01:01”; and
  4. In fields of type xs:duration: “PT99H01M01S”.

The circumstances under which such behaviour is permissible may be limited in the specific business relationship between message sender and message recipient.

 6.4.4 Contractually Mandatory
The messages defined in this standard contain fields with cardinality “0-1” or “0-n”. Therefore these fields are in respect of this standard itself, optional. Such fields may, however, be mandatory when a DDEX message is sent in a specific commercial context.

In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by message sender and message recipient.

 6.4.5 MessageID
The MessageID element shall be, in combination with the DDEX Party ID of the message sender, globally unique. Thus, a message sender shall never re-use a MessageID.  
 6.4.6 TIS TerritoryCodes
The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes unless specifically agreed by message sender and message recipient.
 6.4.7 Validity periods for Deals
Validity periods for deals can be communicated either with a StartDate and/or EndDate (in which case the Deal starts at midnight at the beginning of the start date end/or ends at midnight at the end of the end date) or as a StartDateTime and/or EndDateTime.  
 6.4.8 Preview Dates

6.4.8.1 Preview Dates for Releases and TrackReleases

The four preview dates (ReleasePreviewStartDateTrackListingPreviewStartDateCoverArtPreviewStartDate and ClipPreviewStartDate) can be linked to an album Release as well as a TrackRelease.

If a preview is provided, for the same Resources, on both album Release as well as a TrackRelease level, the date provided on the TrackRelease level shall prevail.

If, for example, a TrackRelease has a TrackListingPreviewStartDate that is later then the TrackListingPreviewStartDate of the album, then the track corresponding to the TrackRelease, must not appear in the album’s track listing until the TrackRelease’s TrackListingPreviewStartDate has passed. 

The same applies to datetime elements.

6.4.8.2 Album-level Preview Dates for Streaming Deals

To communicate preview dates in a streaming-only scenario (where no Dealis provided for the album Release), the Release Distributor that wishes to display the album Release shall make use of the preview dates from the TrackReleasesfor the Resources that make up that album Release.

If conflicting preview dates for ReleasePreviewStartDate and CoverArtPreviewStartDate are provided, the Release Distributor may use the earliest date.

The same applies to datetime elements.

6.4.8.3 Absence of Preview Dates

If no Deal containing any of the four preview datetimes is found, the Release Distributor shall use the earliest StartDateTime from the Deals for the corresponding country as the relevant preview datetime.

This means that as soon as a Release without any preview datetime may be made available to consumers, all relevant data and all relevant Resources also may be shown to consumers.

The same applies to datetime elements.

 6.4.9 Price Information
Price information shall be communicated via the PriceInformation composite within the Deal composite. The following rules shall be applied:
  1. PriceRangeType is meant to contain rough price band information such as “budget” or “front line”. It is not meant for sending instructions on the price to be used when offering the relevant Releases to consumers. 
  2. WholesalePricePerUnit and BulkOrderWholesalePricePerUnit contain a price that a DSP can use to determine its sales price.

  3. WholesalePricePerUnit and BulkOrderWholesalePricePerUnit may not be combined with a PriceType.

  4. SuggestedRetailPrice is not meant to be used by the DSP to determine price.

 6.4.10 Extra Fields for PurchaseAsPhysicalProduct
Unless a PurchaseAsPhysicalProduct is communicated, the use of the following fields is not allowed:
  1. BulkOrderWholesalePricePerUnit;
  2. CarrierType;
  3. PhysicalReturns; and 
  4. NumberOfProductsPerCarton .
 6.4.11 Generic and specific UseTypes
It is not permitted to combine generic and specific UseTypes (e.g. Stream and InteractiveStream) in a single Deal.

It is not permitted to signal all specific sub-UseTypes (e.g. all *Stream UseTypes) defined by DDEX in a single Deal. In such cases the generic UseType shall be used.

At the same time, message senders are encouraged to only send multiple specific sub-UseTypes if really necessary. The preferred method is to use the generic UseType instead.

 6.5 Release Life Cycle Changes

 6.5.1 Common Rules for Life Cycle Changes
Common rules for life cycle changes are:
  1. New deal terms received in an update NewReleaseMessage completely replace all existing deals for the Release, effective on the MessageCreatedDate.
  2. As such, message senders must always supply an explicit list of all valid Deals for each Release in each new NewReleaseMessage. If existing deals remain valid, they must be carried over into that NewReleaseMessage.
  3. All life cycle changes are communicated for a specific Release or set of Releases.
 6.5.2 Granting Additional Territorial Clearances

This life cycle update applies when a message sender wishes to extend the rights granted to the message recipient on an existing Release or set of Releases to cover additional territories:

  1. The message sender must provide a Deal for the additional territories starting on the date the grant should be applied. The message recipient should apply the grant and make the content available in the new territories in the message on the start date provided. 
  2. The territories covered by the Deals in the previous NewReleaseMessage s must also be included, with an active validity period, as this original deal is already applicable in the update message.
 6.5.3 Take-downs and Reduction of Rights
This life cycle update applies when a message sender wishes to reduce the rights granted to the message recipient. This includes “global take-downs”, “territorial take-downs” and the cancellation of a RightsClaim:

To signal that a Release needs to be taken down it is sufficient for the Release Creator to send a new NewReleaseMessage for that Release, albeit, with no Deal composite. If wanted, the Release Creator may communicate a Deal with an EndDate set in the past.

To signal that some deals for a Release cease to apply (i.e. a reduction in the rights available), the Deal(s) that have ceased to exist may simply be omitted from the new NewReleaseMessage. If wanted, the Release Creator may communicate the ceased Deal(s) with an EndDate set in the past.

 If a take-down or reduction in rights happens in the future, an appropriately end-dated Deal needs to be sent.

 

 6.5.4 Territorial Price Change

If a message sender wishes to permanently change the price within one or more territories they have granted to the message recipient for a Release and its related content it shall issue a price change Deal for the territory with an open period starting on the date the price change should be applied. The message recipient shall apply the price change on the start date provided. A Deal covering the existing prices shall also be supplied with an end date equal to a day before the new price start date.  

Note: if such a territorial price change is communicated on the date the new deal comes into effect, no “bridging” Deal needs to be communicated.

 6.5.5 Purging/Removing a Release
In some cases a Release may become corrupt over time. This may make it complicated for a Release Creator to ask for such a Release to be removed (or "purged") from a Release Distributor's database.

In order for a Release to be removed, the Release Creator shall send a PurgeReleaseMessage and the Release Distributor shall act by ceasing to make this Release available if it can ascertain that the message sender has the rights to ask for a Release to be purged. This may be done by checking that the Release Distributor has received the active Deal(s) from the same message sender.

The same approach may also be used when a Release Creator wants to permanently remove a Release from the catalogue of a Release Distributor.

 6.5.6 Take-down before Street Date
To signal that a Release needs to be taken down before the street date has arrived, it is sufficient for the Release Creator to send a new NewReleaseMessage for that Release, albeit, with no Deal composite. If wanted, the Release Creator may communicate only a Deal with an EndDate set in the past.

The same approach can be used to reduce the rights before a street date. In that case, the Deal that is not to become active may simply be omitted from the new NewReleaseMessage.

 6.5.7 Pre-order Business Models

A pre-order is a product offering by which consumer purchases are permitted prior to release date.

The Release may take the same form as that which is available after the pre-order period or it may have exclusive elements only available as part of the pre-order offering, during the pre-order period. It may also have tracks that are fulfilled upon purchase during the pre-order period, while the rest of the Release is fulfilled on release date at the end of the pre-order period. A pre-order can have a mix of bonus and instant gratification tracks and it is also possible for a track to be both instant gratification and bonus.

Such pre-orders business models, if supported, shall meet the following rules:

  1. The isPreorderDeal flag in the relevant Deal shall be set to true.
  2.  The ReleaseDisplayStartDate/ReleaseDisplayStartDateTime, TrackListingPreviewStartDate/TrackListingPreviewStartDateTime, CoverArtPreviewStartDate/CoverArtPreviewStartDateTime and ClipPreviewStartDate/ClipPreviewStartDateTIme shall be communicated if necessary. Note: if one of these dates needs to be communicated,  all of them need to be communicated.
  3. If only a subset of these four dates or date-times need to be communicated, the others need to contain the start date of the entire Deal.

 6.6 Syntax and Semantics of Messages
The syntax and semantics of the messages defined in this standard are provided in an XML Schema Definition file and in tabular form provided in a separate document. Both, the XSD and the tabular form are an integral part of this standard. They are available from the blue box here. These include the allowed value sets as specified in Clause 6.2.

The hierarchical structure of the messages is provided through indentation. On the MessageHeader for example, the PartyName is a child of Sender. Thus, a Sender contains a PartyName (plus a PartyId). A second example from the MessageHeader is the MessageAuditTrail that contains MessageAuditTrailEvents which, in turn, contains a MessagingPartyDescriptor and a DateTime element. All elements that have sub-elements are printed in bold. The MessageAuditTrailEvents element also shows a second structural feature of the tabular message summary: the cardinality. In the case of MessageAuditTrailEvents the entry "1-n" means that each MessageAuditTrail contains one or more MessageAuditTrailEvents.

Other possible cardinality entries are: "1" (for: exactly one), "0-1" (for none or one) or "0-n" (for none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the message sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword XmlChoice. This keyword is not part of the messages. Instead exactly one of the “branches” below the XmlChoice keyword has to be used.

 

Annexes

 Annex A (informative) Release Notes
Version 4 of the Electronic Release Notification Message Suite Standard offers a significantly simpler way to communicate Release Notifications compared with ERN-3.

Version 4.1 has been developed in response of testing with version 4. It further streamlines the communication of Releases from Release Creators to Release Distributors. The major changes include:

  • Simplified process to the reduction of rights and takedowns (Note: this approach has also been adapted for ERN-3);
  • Support for accompanying a NewReleaseMessage with an additional XML file containing information in addition to what has, traditionally, been sent from a Release Creator's supply chain to support, for instance, voice activated music services;
  • Ability to for a Release Creator so signal to a Release Distributor how it wishes artist information should be displayed as part of a title;
  • Ability to communicate display credits;
  • Ability to provide track sequences using letters; and
  • A series of smaller changes to closer align the NewReleaseMessage with messages defined in other DDEX Standards, particularly RIN and MLC.

Version 4.1.1 corrects a number of small errors in the XSD (ensuring that Synopsis and Keywords are available on Release and TrackRelease, adding a flag to indicate whether a Contributor is a credited artist, aligning the ResourceRightsController and WorkRightsController composites, enabling the communication of label hierarchies, add the ability to differentiate “covers” from “originals”) and adds rules for the communication of Preview Dates.

Evaluation Licence for DDEX Standards

 

 

Subject to your compliance with the terms and conditions of this Agreement, DDEX™ grants you a limited, nonexclusive, non-transferable, non-sublicenseable, royalty-free licence solely to reproduce, distribute within your organisation, and use the DDEX standard specifications (“DDEX Standards”) solely for the purpose of your internal evaluation. You may not make any commercial use of the DDEX Standards under this agreement. No other licences are granted under this agreement.

No representations or warranties (either express or implied) are made or offered by DDEX with regard to the DDEX Standards. In particular, but without limitation, no representations or warranties are made in relation to:

  1. The suitability or fitness of the standards for any particular purpose;
  2. The merchantability of the standards;
  3. The accuracy, completeness, relevance or validity of the standards; or
  4. The non-infringement of any third party intellectual property rights related to the DDEX Standards.

Accordingly, DDEX and/or its members shall not be liable for any direct, indirect, special, consequential or punitive loss or damages howsoever arising out of or in connection with the use of the standards. IN THE EVENT THAT ANY COURT OF COMPETENT JURISDICTION RENDERS JUDGEMENT AGAINST DDEX AND/OR ITS MEMBERS NOTWITHSTANDING THE ABOVE LIMITATION, THE AGGREGATE LIABILITY TO YOU IN CONNECTION WITH THIS AGREEMENT SHALL IN NO EVENT EXCEED THE AMOUNT OF ONE HUNDRED U.S. DOLLARS (US$ 100.00).

Users of the DDEX Standards are cautioned that it is subject to revision. Users are recommended to use the latest versions, which are available at http://www.ddex.net. The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.