- Created by DDEX Secretariat, last modified on 2020-10-08
This section of the DDEX Knowledge Base contains the "Recording Data and Rights Choreography Standard"
1 Introduction
This standard, together with the Recording Data and Rights Notification Standard and the Recording Data and Rights Revenue Reporting Standard, is a uniform mechanism for owners of Sound Recordings and Music Licensing Companies to exchange information about rights claims and revenues for such right claims.
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 standard tables (XLS)
Download XML Schema Definition Files (ZIP)
General Index
The general index contains all terms used in the latest AVS (Version 4) as well as all terms from RIN 2.0, MEAD 1.1, PIE 1.0 and RDR-N 1.5. Other standards will be added over time. Clicking on an entry in the general index will take you to the relevant edition of the DDEX Data Dictionary.
Message Editions
... for the Electronic Release Notification (ERN 4.3)
... for Recording Information Notification (RIN 2.0)
... for Media Enrichment and Description (MEAD 1.1)
... for Party Identification and Enrichment (PIE 1.0)
... for the Recording Data and Rights Notification Standard (RDR-N, Version 1.5).
Allowed Value Set Editions
... for the Allowed Value Sets (Version 4)
... for the Allowed Value Sets (Version 3)
... for the Allowed Value Sets (Version 2)
... for the Allowed Value Sets (Version 1)
Data Dictionary editions published before 2022
... 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 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
... for the Musical Work Right Share Notification Choreography Standard (MWN, Version 1.1)
... for 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)
2 Scope
This specification allows for the secure transmission of information and caters for non-repudiation requirements to be met.
While the location and owner of the SFTP server is not defined herein (this is left to be agreed by the owners of Sound Recordings and Music Licensing Companies), the structure of the SFTP servers and names for files are defined by this standard.
At this stage, this standard does not address issues arising from data mismatches detected during the information exchange.
Clauses 7 and 8 then define the two approaches to communicating information with SFTP before Clause 9 defines the two messages that support SFTP communication of information.
3 Normative References
The following normative documents contain provisions, which through reference in this text constitute provisions of this Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
- DDEX Data Dictionary Standard. Latest Version
- DDEX Party Identifier (DPID) Standard. Latest Version
- DDEX Digital Signature Standard. Latest Version
- DDEX Recording Data and Rights Notification Standard. Latest Version
- DDEX Recording Data and Rights Revenue Reporting Standard. Latest Version
- IETF. RfC2026. SSH File Transfer Protocol. October 2001
- W3C: XML Schema Part 1: Structures. Second Edition. 2004
- W3C: XML Schema Part 2: Data types. Second Edition. 2004
4 Terms and Definitions
Batch
A grouping of one or more DDEX Messages to be processed by the 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.
Manifest
An XML message signifying the delivery of a Batch.
Message Choreography
A series of message calls and their responses which together communicate a more comprehensive level of meaning between the two business partners.
Message Recipient
A Party that receives a Message formatted in accordance with a DDEX Standard from a Message Sender. The Message Recipient may also be one or more of a Licensor, a Licensee, a Rights Controller, a Rights Administrator, a Licensing Agent or a Rights Holder.
Message Sender
A Party that sends a Message formatted in accordance with a DDEX Standard to a Message Recipient. The Message Sender may also be one or more of a Licensor, a Licensee, a Rights Controller, a Rights Administrator, a Licensing Agent or a Rights Holder.
Non-repudiation
The concept of ensuring that a party cannot repudiate, or refute, the sending or receiving of a message.
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).
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.
5 Abbreviations
AMEP | Automated Message Exchange Protocol |
ACA | Appointed Certification Agency |
AVS | Allowed Value Set |
BP | Business Profile |
BWARM | Bulk Communication of Work and Recording Metadata |
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) |
MEAD | Media Enrichment And Description |
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 | |
PIE | Party Identification and Enrichment |
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 |
6 Message Design Approach (informative)
http://ddex.net/xml/rdr-c/10
The full namespace for the XML Schema document for the allowed-value sets is:
http://ddex.net/xml/avs/avs
DDEX may regularly extend or amend this list of allowed-value sets. Any such extensions to this list that 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 in Annex A contains the list of allowed-value sets valid on the data of issuance of this Standard.
W3C’s XML Schema Standard has been used to define the structure of the messages and some of the business rules. However, XML Schema alone cannot easily provide a means for complex and conditional validation but XML tools, such as eXtensible Stylesheet Language Transformation (XSLT) and XPath could provide a means of developing standard validation modules for each message set.
7 SFTP Message-by-Message Profile
This clause defines the method by which a company can provide an individual message defined in the Recording Data and Rights Notification Standard and the Recording Data and Rights Revenue Reporting Standard to a business partner via (i) an SFTP server that is hosted by the Message Sender, (ii) an SFTP server that is hosted by the Message Recipient or (iii) an SFTP server that is hosted by a third party. This specification does not therefore define on whose hardware the files are being stored. This is for the Message Sender and the Message Recipient to agree.
The choreography of the FTP Message-by-Message Profile is as depicted below:
RdrAcknowledgementMessage
is defined in Clause 9 of this standard.The file naming conventions for the FTP Message-by-Message Profile are defined in Clauses 7.2 and 7.3 of this standard.
The recipient of the RdrAcknowledgementMessage
may remove an RdrAcknowledgementMessage
from the FTP server after an appropriate and mutually agreed period of time. The default period is one month.
The RdrAcknowledgementMessage
shall be placed into a folder called acknowledgements
/.
To ensure sequential processing, a Message file is identified by its type and date and time of its creation in the form TTTT_YYYYMMDDhhmmssuuunnn
with
TTTT
being the name (root tag) of the Message (for XML messages) orXXX
for the flat file Reporting Message;YYYY
being the year of Message creation;MM
being the month of Message creation;DD
being the day of Message creation;hh
being the hour of Message creation;mm
being the minute of Message creation;ss
being the second of Message creation;uuu
being the millisecond of Message creation; andnnn
being the nanosecond of Message creation.
The file name of the RdrAcknowledgementMessage
for each Message shall be the string ACK_
, followed by the file name that is being acknowledged.
DeclarationOfSoundRecordingRightsClaimMessage_20200310130322000.xml | |
| |
RequestSoundRecordingInformationMessage_20200310130324000.xml | |
acknowledgements/ | |
ACK_DeclarationOfSoundRecordingRightsClaimMessage_20200310130323000.xml |
8 SFTP Batch Profile
The choreography of the FTP Batch Profile is as depicted below:
The trigger to indicate that a Batch is complete is a ManifestMessage
as defined in Clause 9 of this standard.
The RdrAcknowledgementMessage
is defined in this standard and is also defined in Clause 9.
The structure and file naming conventions for the Batched FTP Profile are defined in Clauses 8.3 and 8.4 of this standard.
This standard does not define when the Message Sender shall start or finish to upload subsequent messages. Equally, this standard does not define when the Message Recipient shall start or finish its download.
The recipient of the RdrAcknowledgementMessage
may remove an RdrAcknowledgementMessage
from the FTP server after an appropriate and mutually agreed period of time. The default period is one month.
If the Message Sender wants to have several Batches “open” at the same time, it needs to ensure that no claims with respect to the same Sound Recording are contained in more than one Batch.
The maximum time a Batch may be kept “open” is a matter for the Message Sender and Message Recipient to define in their commercial agreement.
To ensure sequential processing, a Batch is identified by the date and time of its creation in the form YYYYMMDDhhmmssuuunnn
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;uuu
being the millisecond of Message creation; and-
nnn
being the nanosecond of Batch creation.
The Message Sender shall make sure that for each of its Message Recipient this BatchId
is unique.
ManifestMessage
for each Batch shall be the string BatchComplete_
followed by the BatchId
(as defined above) and the .xml
file extension Each message sent in the Batch shall be named as follows: MMMM_SSSSS.xml
with
MMMM
being the name (root tag) of the Message (for XML messages) orXXX
for the flat file Reporting Message; andSSSSS
being a zero padded serial number within that Batch.
The file name of the RdrAcknowledgementMessage
for each Batch shall be the string ACK_
, followed by the BatchId
of the Batch that is being acknowledged. The file shall have an .xml
file extension.
9 Message Definition
The tabular rendering of the messages is provided in a separate document. See the blue box here.
The messages defined in this standard are depicted below.
9.2.1 Schema Validation
A message is conformant to this specification only when it validates against the set of accompanying XML Schema files.
9.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 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 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 where the UserDefinedValue is defined and maintained.
9.2.3 Contractually Mandatory
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 between the Message Sender and Message Recipient.
The Table of AVSs 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:
- 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.