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
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.
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
- 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.
- W3C: XML Schema Part 1 - Structures. Second Edition. 2004
- W3C: XML Schema Part 2 - Datatypes. Second Edition. 2004
4 Terms and Abbreviations
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).
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.
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.
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).
A subset of a DDEX standard. Profiles define how to use the capabilities of a DDEX standard in a specific commercial context.
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 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 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.
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.
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).
|AMEP||Automated Message Exchange Protocol|
|ACA||Appointed Certification Agency|
|AVS||Allowed Value Set|
Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)
|DAW||Digital Audio Workstation|
Digital Data Exchange
|DSP||Digital Service Provider (incudes Mobile Service Providers)|
|DSR||Digital Sales Reporting|
|ERN||Electronic Release Notification|
|FTP||File Transfer Protocol (FTP specifically includes SFTP)|
|GRid||Global Release Identifier|
|HTTP||Hypertext Transport Protocol (HTTP specifically includes HTTPS)|
|HTTPS||Secure Hypertext Transport Protocol|
|IEC||International Electrotechnical Commission (see iec.ch)|
|ISO||International Organisation for Standardisation (see iso.org)|
|MIME||Multipurpose Internet Mail Extensions|
|MLC||Music Licensing Company|
|MWL||Musical Works Licensing|
|MWN||Musical Works Notification|
|PCA||Private Certification Agency|
|Portable Document Format|
|RIN||Recording Information Notification|
|TIS||Territory Information System (a CISAC Standard)|
|TLS||Transport Layer Security|
|URL||Uniform Resource Locator|
|XML||eXtensible Markup Language|
|XSD||XML Schema Definition|
|W3C||World Wide Web Consortium (see w3c.org)|
5 Message Choreography
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
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
|The Release Creator wishes to communicate updates to the metadata about the Release and/or commercial conditions.|
|2||The Release Creator gains knowledge of a corrupt Release in the systems of a DSP that cannot be taken down simply by using the ||Release Creator, typically a record company||Release Distributor, typically a DSP|
|A Release Creator wishes to completely remove a Release from a DSPs offering.|
6 Message Definition
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.
The full namespace for the XML Schema document for the allowed-value sets is
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.
ReleaseType(of the Main );
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.
Namespaceattributes 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.
- In fields of type xs:string: “
- In fields of type xd:date: “
- In fields of type xs:datetime: “
- In fields of type xs:duration: “
The circumstances under which such behaviour is permissible may be limited in the specific business relationship between message sender and message recipient.
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.
MessageIDelement shall be, in combination with the DDEX Party ID of the message sender, globally unique. Thus, a message sender shall never re-use a
TerritoryCodesis not permitted when communicating
TerritoryCodesunless specifically agreed by message sender and message recipient.
EndDate(in which case the
Dealstarts at midnight at the beginning of the start date end/or ends at midnight at the end of the end date) or as a
184.108.40.206 Preview Dates for Releases and TrackReleases
The four preview dates (
ClipPreviewStartDate) can be linked to an album
Release as well as a
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
TrackListingPreviewStartDate has passed.
The same applies to datetime elements.
220.127.116.11 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
CoverArtPreviewStartDate are provided, the Release Distributor may use the earliest date.
The same applies to datetime elements.
18.104.22.168 Absence of Preview Dates
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.
PriceInformationcomposite within the
Dealcomposite. The following rules shall be applied:
PriceRangeTypeis 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.
BulkOrderWholesalePricePerUnitcontain a price that a DSP can use to determine its sales price.
BulkOrderWholesalePricePerUnitmay not be combined with a
SuggestedRetailPriceis not meant to be used by the DSP to determine price.
PurchaseAsPhysicalProductis communicated, the use of the following fields is not allowed:
InteractiveStream) in a single
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
- New deal terms received in an update
NewReleaseMessagecompletely replace all existing deals for the Release, effective on the
- As such, message senders must always supply an explicit list of all valid
Dealsfor each Release in each new
NewReleaseMessage. If existing deals remain valid, they must be carried over into that
- All life cycle changes are communicated for a specific Release or set of Releases.
- The message sender must provide a
Dealfor 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.
- The territories covered by the
Deals in the previous
NewReleaseMessages must also be included, with an active validity period, as this original deal is already applicable in the update message.
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.
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.
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.
NewReleaseMessagefor that Release, albeit, with no
Dealcomposite. If wanted, the Release Creator may communicate only a
EndDateset 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
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:
isPreorderDealflag in the relevant
Dealshall be set to true.
ClipPreviewStartDateTImeshall be communicated if necessary. Note: if one of these dates needs to be communicated, all of them need to be communicated.
- 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
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
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.
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
NewReleaseMessagewith 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
Keywords are available on
TrackRelease, adding a flag to indicate whether a
Contributor is a credited artist, aligning the
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:
- The suitability or fitness of the standards for any particular purpose;
- The merchantability of the standards;
- The accuracy, completeness, relevance or validity of the standards; or
- 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.