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.

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.

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)

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.  

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.