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 https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.
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 8 normatively specifies all elements of all messages within this Standard, and their descriptions as they appear in the DDEX Data Dictionary. Finally, Clause 9 defines two profiles for the MLC standard.
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.
In addition, Version 1.4 contains a new message to allow recipients of
DeclarationOfSoundRecordingRightsClaimMessages to report the status of such rights claims back to the sender of the claim message.
Version 1.4 contains various minor updates, including a better description of artists and contributors and a closer alignment of role codes to ERN and RIN.
Version 1.3.1 corrects a bug that removed essential role coded. These codes have been added back in.
Version 1.3 provides support for VRDB2 communication as well as some other minor enhancements.
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
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
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 the recipient together.
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. 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.
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.
|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|
|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 Overview
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 ddex.net.
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 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 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
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.
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.
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.
manifest.xmland shall be placed into the same folder as all other files.
Its syntax is defined in Clause 8.8 and shown below:
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:
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 Name||Initiating Event|
|1||RequestSoundRecordingInformationMessage||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.|
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).
Update with the intention that the receiving MLC deletes – or marks inactive – the listed SoundRecordingRightsClaims.
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
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
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)
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.
Information content in the RequestSoundRecordingInformationMessage
Information content in the DeclarationOfSoundRecordingRightsClaimMessage
Information content in the RevokeSoundRecordingRightsClaimMessage
Information content in the SalesReportMessage
Information content in the DeclarationOfRevenueMessage
Information content in the RightsClaimStatusUpdateMessage
8 Message Definition
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.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/14".
8.2.7 Character Coding
All messages shall be sent in UTF-8.
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.