- Created by DDEX Secretariat, last modified on 2020-05-19
1 Introduction
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 https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.
Download Standard (PDF)
Download tables for the Standard (XLS)
Download Samples (ZIP)
XML Schema Definition Files (ZIP)
... for the Recording Data and Rights Choreography Standard (RDR-C, Version 1.0): Message Structure and AVSs
... for the US Letters of Direction Choreography Standard (LoD, Version 1.0): Message Structure and AVSs
... for the Electronic Release Notification Message Suite Standard (ERN, Version 4.2): Message Structure and AVSs
... for the Musical Work Right Share Notification Choreography Standard (MWN. Version 1.2): Message Structure and AVSs
... for the US Musical Work Licensing Choreography Standard (MWL, Version 1.0): Message Structure and AVSs
... for the Standard for the Communication of Media Enrichment and Description Information (MEAD): Message Structure and AVSs
... f or the Standard for communicating links between Resources and Musical Works (Version 1.1)
... for the Recording Data and Rights Standard (Version 1.4)
... for Release Deliveries using SFTP or Web Service (Version 1.7)
... for the Recording Information Notification (Version 1.1)
Older versions of this standard can be accessed here .
2 Scope
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: Data elements and interchange formats – Information interchange – Representation of dates and times. Latest Version.[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
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).
| AMEP | Automated Message Exchange Protocol |
| ACA | Appointed Certification Agency |
| AVS | Allowed Value Set |
| BP | Business 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) |
| CA | Certification Agency |
| CT | Conformance Tester |
| DAW | Digital Audio Workstation |
| DDEX | Digital Data Exchange |
| DSIG | Digital Signature |
| 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 |
| MWL | Musical Works Licensing |
| MWN | Musical Works Notification |
| MRBV | Multi-Record-Block Variant |
| PCA | Private Certification Agency |
| Portable Document Format | |
| REST | REpresentational State Transfer |
| RIN | Recording Information Notification |
| SFTP | Secure FTP |
| SRBV | Single-Record-Block Variant |
| TIS | Territory Information System (a CISAC Standard) |
| TLS | Transport Layer Security |
| UGC | User-generated content |
| URL | Uniform Resource Locator |
| XML | eXtensible Markup Language |
| XSD | XML Schema Definition |
| W3C | World Wide Web Consortium (see w3c.org) |
| WS | Web Service |
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
Message Name | Initiating Event | Sender | Recipient | |
1 |
| 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. | ||||
| 2 | PurgeReleaseMessage | The 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 company | Release Distributor, typically a DSP |
| A Release Creator wishes to completely remove a Release from a DSPs offering. | ||||
6 Message Definition
http://ddex.net/xml/ern/42
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
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.
ReleaseType(of the Main Release);UseType; andCommercialModelType.
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.
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.
- In fields of type xs:string: “
#unknown#” ; - In fields of type xd:date: “
9999-01-01”; - In fields of type xs:datetime: “
9999-01-01T99:01:01”; and - 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.
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.
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. TerritoryCodes is not permitted when communicating TerritoryCodes unless specifically agreed by message sender and message recipient.
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.1 Preview Dates for Releases and TrackReleases
The four preview dates (ReleasePreviewStartDate, TrackListingPreviewStartDate, CoverArtPreviewStartDate 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.
PriceInformation composite within the Deal composite. 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.WholesalePricePerUnitandBulkOrderWholesalePricePerUnitcontain a price that a DSP can use to determine its sales price.
WholesalePricePerUnitandBulkOrderWholesalePricePerUnitmay not be combined with aPriceType.SuggestedRetailPriceis not meant to be used by the DSP to determine price.
PurchaseAsPhysicalProduct is communicated, the use of the following fields is not allowed:BulkOrderWholesalePricePerUnit;CarrierType;PhysicalReturns; andNumberOfProductsPerCarton.
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.
- New deal terms received in an update
NewReleaseMessagecompletely replace all existing deals for the Release, effective on theMessageCreatedDate. - As such, message senders must always supply an explicit list of all valid
Dealsfor each Release in each newNewReleaseMessage. If existing deals remain valid, they must be carried over into thatNewReleaseMessage. - All life cycle changes are communicated for a specific Release or set of Releases.
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:
- 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 previousNewReleaseMessages must also be included, with an active validity period, as this original deal is already applicable in the update message.
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.
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.
The same approach may also be used when a Release Creator wants to permanently remove a Release from the catalogue of a Release Distributor.
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.
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:
- The
isPreorderDealflag in the relevantDealshall be set to true. - The
ReleaseDisplayStartDate/ReleaseDisplayStartDateTime,TrackListingPreviewStartDate/TrackListingPreviewStartDateTime,CoverArtPreviewStartDate/CoverArtPreviewStartDateTimeandClipPreviewStartDate/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
Deal.
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
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 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.
Version 4.2 adds support for
- Session information,
- Genre categories (i.e. genre allowed value sets in addition to free-form genre strings);
- Communication of dialects (such as American English or Swiss-German) where Version 4.1 only allowed to signal a language; and
- The ability to communicate record company personnel that the MessageSender request be granted access to the MessageRecipient’s systems to administer a Release. Version
Version 4.2 also enhances the
- Handling of different encodings of one recording; and
- Communication of relationships between Releases and Resources.
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.