Skip to end of metadata
Go to start of metadata

This page contains a standard that have been superseded by a newer version. DDEX strongly recommends to always implement the latest version of a particular DDEX Standards and to regularly update any implementation to work with the latest version. Please refer to this page for a link to the latest MLC standard.

This section of the DDEX Knowledge Base contains the Public Draft of version 1.2 of the "Music Licensing Company Message Suite and Choreography 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 for the exchange of sound recording, music video and related sales data with and between Music Licensing Companies. The exchange of such data with and between Music Licensing Companies (MLCs) is required to meet the requirements of bilateral agreements between the MLCs that administer the rights of independent producers and performers in several territories.

This standard defines the Music Licensing Companies Message Suite Standard (MLC). DDEX may, over time, develop Profiles of this standard. Messages created in accordance with such Profiles are expected to be largely compatible with standard. 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


2 Scope

 2.1 Introduction
The suite of messages contained in this Standard provides a mechanism for owners of SoundRecordings and Music Licensing Companies (MLC) to claim interest in a SoundRecording to a second MLC and to revoke and request such claim statements. The Standard also allow MLCs to report usage and revenue information to other MLCs and owners of SoundRecordings.
 2.2 Organisation of the Document

This DDEX Standard has eight clauses and two annexes. Clause 1 and 2 provide a general introduction and the scope of this Standard. Clause 3 and 4 give a set of normative references as well as terms, definitions and abbreviations that are used in this Standard. Clause 5 introduces the approach to message design taken by DDEX.

Clause 6 defines the choreography buy which the messages defined in this Standard are to be exchanged. Clauses 7 and 8 then provide the message content: Clause 7 provides an informative overview whereas Clause 7 normatively specifies all elements of all messages within this Standard, and their descriptions as they appear in the DDEX Data Dictionary.

Annex B, contained in a separate document, provides the relevant XML Schema files. The normative clauses of this document, including Annex A, should be read together to form the Music Licensing Company Message Suite Standard.

 2.3 Release Notes

Version 1.2 updates the choreography and adds support for performer societies' data requirements.

Version 1.1 provides support for legacy territories and TIS territory codes as well as the ability to communicate the same richness in performer information as is possible in  the 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 Automated Message Exchange Protocol. Latest Version
  • DDEX Data Dictionary Standard. Latest Version
  • DDEX Party Identifier (DPID) Standard. Latest Version
  • IFPI: Global Release Identifier (GRid) Standard. Latest Version
  • CISAC: Musical Work Licence Identifier (MWLI) Standard. Latest Version
  • IETF RfC 4646, Tags for Identifying Languages. Latest Version
  • ISO 639:1988, Code for the representation of the names of languages
  • ISO 3166: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

 4.1 Terms and Definitions

For the purposes of this Standard, the following terms should be read as having the meanings specified here:


A grouping of one or more DDEX Messages to be processed by a Recipient together.

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.

Music Licensing Company

A company that is duly authorised to issue licences for the use of SoundRecordings and music videos. Music Licensing Companies may issue licences on behalf of phonogram producers, performers or both.

Note: Music Licensing Companies were previously referred to as Producers (and/or Performers) Collection Societies (PCSs).


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 Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer for the purpose of distribution to individual consumers, directly or through intermediaries. 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.


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.

 4.2 Abbreviations

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

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

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes Secure FTP, or SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol
IECInternational Electrotechnical Commission (see
ISOInternational Organisation for Standardisation (see
MIMEMultipurpose Internet Mail Extensions
MLCMusic Licensing Company
MWLMusical Works Licensing
MWNMusical Works Notification
PCAPrivate Certification Agency
PDFPortable Document Format
RESTREpresentational State Transfer
RINRecording Information Notification
SHTTPSecure Hypertext Transport Protocol
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
WSWeb Service

5 Message Overview

 5.1 Namespace

The full namespace for the XML Schema document for this Standard is

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

 5.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

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 form part of this Standard. Thus the list of allowed-value sets provided Annex A contains the list of allowed-value sets valid on the data of issuance of this Standard.

6 Message Choreography

 6.1 Message Exchange Protocol

The exchange of messages defined in this standard shall be exchange using the ftp mode defined in Clause 7 of the Automated Message Exchange Protocol Standard. The sender of a message shall place all messages that comprise a Batch into a single folder on the ftp server.

 6.2 Folder Naming Convention

To ensure sequential processing, a Batch is identified by the date and time of its creation in the form YYYYMMDDhhmmssnnn with

  •  YYYY being the year of Batch creation;

  • MM being the month of Batch creation;

  • DD being the day of Batch creation;

  • hh being the hour of Batch creation;

  • mm being the minute of Batch creation;

  • ss being the second of Batch creation; and

  • nnn being the millisecond of Batch creation.

 6.3 File naming Convention

Each message sent in the Batch shall be named as follows: MMMM_SSSSS.xml with

  • MMMM being the name (root tag) of the Message; and

  • SSSSS being a zero padded serial number within that batch.

 6.4 Manifest

Once the Message sender has uploaded all files of the Batch, the sender shall upload a Manifest file. The manifest file shall be called manifest.xml and shall be placed into the same folder as all other files.

Its syntax is defined in Clause 8.8 and shown below:

 6.5 Acknowledgement

Once the Message recipient has downloaded all files of the Batch, the recipient shall upload an Acknowledgement file. The acknowledgement file shall be called acknowledement.xml and shall be placed into the same folder as all other files.

Its syntax is defined in Clause 9.3 of the Automated Message Exchange Protocol Standard and shown below:

 6.6 Triggers

The Table 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.


Message NameInitiating Event
1RequestSoundRecordingInformationMessage A MLC has received sales information about a SoundRecordings but has not received any information, including rights claims, with respect to that SoundRecordings. Such information can be requested.
2 DeclarationOfSoundRecordingRightsClaimMessage

The MLC then forwards information about theses Releases and mandated uses to a second MLC in each mandated territory (however, this message can also be sent proactively, i.e. not in response to a RequestSoundRecordingInformationMessage).

3 RevokeSoundRecordingRightsClaimMessage

Update with the intention that the receiving MLC deletes – or marks inactive – the listed SoundRecordingRightsClaims.

4 SalesReportMessage

After sales of sound carriers or Releases for the mandated territories have been received and processed by a MLC, some sales information needs to be shared with sister MLCs in the mandated territories, for those MLCs that allocate revenues on the basis of unit sales

5 DeclarationOfRevenueMessage

After invoicing the user, payment by the user to the MLC, and the allocation by MLC of the related revenues to SoundRecordings, the MLC declares to another MLC its share in the revenues

Table 1 — Messages in the Main Profile of the Music Licensing Company Message Suite




 6.7 Choreography

Figures 3 and 4 below shows the choreography of processes that the Main Profile of the MLC Message Suite enables. Note the figure does not show the use of manifests or acknowledgements.


Figure 3 — Choreography of the Main Profile of the Music Licensing Company Message Suite (Declaration of Sound Recordings)

Figure 4 — Choreography of the Main Profile of the Music Licensing Company Message Suite (Declaration of Revenues and Sales)

7 Message Content Overview (informative)

 Click here to expand...

Each of the messages defined in this Standard conveys a set of data elements from sender to recipient. The following diagrams show these information elements for the various messages. They allow a rapid overview of the different messages for technicians as well as for business process experts of organisations that are to implement the Standard defined herein. The data element names shown in the diagrams below are not the formal names used in the messages as thediagram is intended to provide a quick overview of the data to be provided within the messages. The diagrams are not normative.

Note that one XML Attribute, LanguageAndScriptCode, is only shown on the top-level (message) composites. This attribute is, in fact, present on all composites or elements that might benefit from being coded in different languages and/0r scripts. If placed on a composite, its value applies to all sub-elements (and, potentially, overrides a different LanguageAndScriptCode “further up”. If placed on an element its value applies only to that element. The LanguageAndScriptCode is provided in accordance with IETF RfC 4646.

Also note that dashed lines represent logical relationships between entities. These relationships are represented not but one entity’s metadata physically including the other entity’s metadata but by referencing — using XML Schema’s xs:ID/xs:IDREF mechanism — the linked entity. The “anchors” for these references are not listed in the diagrams below.

Figure 4 — Information content in the RequestSoundRecordingInformationMessage

 Figure 5 — Information content in the DeclarationOfSoundRecordingRightsClaimMessage

Figure 6 — Information content in the RevokeSoundRecordingRightsClaimMessage

Figure 7 — Information content in the SalesReportMessage

Figure 8 — Information content in the DeclarationOfRevenueMessage

8 Message Definition

 8.1 Introduction

This Clause contains an overview for each of the messages in the Music Licensing Company Message Suite and Choreography Standard. The full technical specification is provided in  the tabluar representation XML Schema files attached to this standard.

The Standard comprises five messages:

  • DeclarationOfRevenueMessage – A Message in the Music Licensing Company Message Suite Standard containing a declaration of Revenue from the Usage of Releases. 
  • DeclarationOfSoundRecordingRightsClaimMessage – A Message in the Music Licensing Company Message Suite Standard containing details of a SoundRecording.
  •  RequestSoundRecordingInformationMessage – A Message in the Music Licensing Company Message Suite Standard containing a request for a declaration of SoundRecordings
  •  RevokeSoundRecordingRightsClaimMessage – A Message in the Music Licensing Company Message Suite Standard in which a claim, typically communicated via a DeclarationOfSoundRecordingRightsClaimMessage, is revoked. 
  • SalesReportMessage – A Message in the Music Licensing Company Message Suite Standard used by one Music Licensing Company to inform a second Music Licensing Company about unit sales of Releases in electronic or physical formats.  

In addition this standard defines a ManifestMessage and re-uses the FtpAcknowledgementMessage defined in DDEX-AMEP.

The hierarchical structure of the messages is provided through indentation. On the Message Header for example, the PartyName is a child of Sender. Thus, a Sender contains a PartyName (plus a PartyId). A second example from the Message Header is the MessageAuditTrail that contains MessageAuditTrailEvents which, in turn, contains a MessagingParty- Descriptor and a DateTime element. All elements that have subelements are printed in bold. The MessageAuditTrailEvents element also shows a second structural feature of the 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. Each branch is indicated by a capital letter A, B, C, ... Each branch may consist of several sub-elements.

In addition to the tabular description of the message, which should always be read in conjunction with Annexes A and B, additional conformance rules, which go beyond XML Schema validation, are provided where necessary. The general conformance rules for all messages within this Standard are provided in Clause 7.1.

Specific business processes between sender and recipient may require even further conformance rules. These are, however, not part of the Standard and will need to be agreed between business partners. Rules relating to the authority of business partners to unilaterally change the Message Standard in this way are set out in the current version of the Procedures for the Development and Maintenance of DDEX Standards which forms part of the overall governance of the DDEX Standards.

The syntax as well as the semantics of the various elements in the messages is provided in this Clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.

 8.2 General Conformance Rules

8.2.1 Schema Validation 

A message is conformant to this specification only when it validates against the set of XML Schema files provided in Annex A.

8.2.2 Allowed Value Lists 

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

This Standard does not explicitly list allowed values. The XML Schema files – as provided in Annex A – contain the allowed values at the time of writing of this Standard. 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 MessageSender 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 MessageSender 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 where the UserDefinedValue is defined and maintained.

8.2.3 Allowed values for Namespace Attributes 

The Namespace attributes can be used to allow message parties to use proprietary value lists.

The allowed value for the Namespace attribute which is recommended to be used is the DDEX Party Identifier of the party controlling the proprietary allowed value, as defined in, and administered in accordance with the latest version of the DDEX Party ID Standard, DDEX-MPID.

8.2.4 Indicating unknown values 

When the sender of a message is required to provide a data element but cannot do so, the following values shall be entered:

  •  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.

8.2.5 Contratually Mandatiory 

The messages defined in this standard contain fields with cardinality “0-1” or “0-n”. Therefore these fields are from the standard’s point of view, 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 MessageSender and MessageRecipient.

8.2.6 Schema Version  

The only valid value for this field is "mlc/12".

 8.3 Syntax and Semantics of Messages

The tabular rendering of the messages  is provided in a separate document. See the blue box here.

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 The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.

Write a comment…