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.

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

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.

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

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.

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

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

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.

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.