Candidate Standard

Skip to end of metadata
Go to start of metadata

This section of the DDEX Knowledge Base contains the "Recording Data and Rights Choreography Standard"

 1 Introduction

DDEX has standardised a series of Message Suite Standards that define the syntax and semantics of business metadata exchanged by members of the digital media delivery chain. DDEX has also standardised an automated message exchange protocol that enables the reliable communication of DDEX messages and associated documents such as resource files, using SFTP.

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.

Essential Reading

Download Standard (PDF)

Download standard tables (XLS)

Download XML Schema Definition Files (ZIP)

 The DDEX Data Dictionary ...

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

... for Work and Share Notifications

... for Works Licensing

2 Scope

 2.1 Introduction

This standard provides a standardised means for owners of Sound Recordings and Music Licensing Companies to efficiently exchange messages defined in the Recording Data and Rights Notification Standard and in the Recording Data and Rights Revenue Reporting Standard.

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.

 2.2 Organisation of the Document

This DDEX Standard has nine clauses. Clauses 1 and 2 provide a general introduction and the scope of this Standard. Clauses 3, 4 and 5 give a set of normative references as well as terms, definitions and abbreviations that are used in this Standard. Clause 6 then explains the general approach taken by DDEX to message standardisation.

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

 Click here to expand...

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

 Click here to expand...

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

 Click here to expand...

AMEPAutomated Message Exchange Protocol
ACAAppointed Certification Agency
AVSAllowed Value Set
BPBusiness 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)

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation
DDEX

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol  (HTTP specifically includes HTTPS)
HTTPSSecure Hypertext Transport Protocol
IECInternational Electrotechnical Commission (see iec.ch)
ISOInternational Organisation for Standardisation (see iso.org)
MIMEMultipurpose Internet Mail Extensions
MWLMusical Works Licensing
MWNMusical Works Notification
MRBV

Multi-Record-Block Variant

PCAPrivate Certification Agency
PDFPortable Document Format
RESTREpresentational State Transfer
RINRecording Information Notification
SFTPSecure FTP
SRBV

Single-Record-Block Variant

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 w3c.org)
WSWeb Service

6 Message Design Approach (informative)

 Click here to expand...

All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary. The full namespace for the XML Schema document for this Standard is:
http://ddex.net/xml/rdr-c/10

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 an XML Schema Definition file for all of these allowed values. These values are also contained in the DDEX Data Dictionary available from http://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 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

 7.1 Choreography

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:

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

 

 7.2 SFTP Server Organisation

All Messages shall be placed into a folder agreed between Message Sender and Message Recipient

The RdrAcknowledgementMessage shall be placed into a folder called acknowledgements/.

 7.3 File Naming Conventions

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) or XXX 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; and
  • nnn 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.

 7.4 Example of Server Organisation and File Naming Convention (Informative)

The example below shows three delivered Messages. The second Message has already been acknowledged by the Message Recipient, the others have not. 
DeclarationOfSoundRecordingRightsClaimMessage_20200310130322000.xml

DeclarationOfSoundRecordingRightsClaimMessage_20200310130323000.xml

RequestSoundRecordingInformationMessage_20200310130324000.xml
acknowledgements/

 ACK_DeclarationOfSoundRecordingRightsClaimMessage_20200310130323000.xml

8 SFTP Batch Profile

 8.1 Choreography

This clause defines the method by which a company can provide Batches of messages 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 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.

 

 8.2 Batch Constraints

The maximum size of a Batch is not defined in this standard but shall be agreed by the Message Sender and Message Recipient before using this Profile. It is not permitted to include claims with respect to the same Sound Recording more than once in a single Batch.

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.

 8.3 SFTP Server Organisation

Each Batch shall be placed into a separate folder of its own. The folder name shall be the BatchId.

The ManifestMessage, shall be placed into the root folder of the Batch.

The RdrAcknowledgementMessage shall be placed into a folder called acknowledgements/.

 

 8.4 File Naming Convention

The file name of the 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) or XXX for the flat file Reporting Message; and

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

 8.5 Example of Server Organisation and File Naming Convention (informative)

The example below shows one delivered Batch with two messages. The Batch is not yet acknowledged.

20200310130322000/

 

DeclarationOfSoundRecordingRightsClaimMessage_01234.xml

 

RequestSoundRecordingInformationMessage_01236.xml 

 

BatchComplete_20200310130322000.xml

acknowledgements/

 

<empty>

9 Message Definition

 9.1 Introduction

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 General Conformance Rules

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.

 

 9.3 Allowed-value Sets

All allowed value sets with their allowed values and definitions that are valid within this standard are set out below. The allowed-value sets are maintained outside of this Standard and DDEX may add to the list below.

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:

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