12 Rules for the communication of resource files

The following rules shall apply to the communication of resource files:

1. Resource availability (no pre-order releases)
   When communicating a release for which no pre-order deal is available, the record company or distributor shall ensure that for all resources the location of each resource file is communicated to the DSP before the release is to be made available to consumers.
   For the avoidance of doubt, it is sufficient that the location of each resource file is communicated via a NewReleaseMessage, sufficiently well before the release is to "go live" to allow the DSP to meet the "go live" date.
   It is, however, preferred that the locations of all resources are communicated together.

2. Resource availability (pre-order releases)
   When communicating a release for which a pre-order deal is available, the record company or distributor shall ensure that for all resources the location of each resource file is communicated to the DSP before it is to be made available to consumers as part of the release.
   For the avoidance of doubt, it is sufficient that the location of each resource file is communicated via a NewReleaseMessage, sufficiently well before the resource is to "go live" to allow the DSP to meet the "go live" date.
   It is, however, preferred that the locations of all resources are communicated together.

3. Signalling resource file availability

   1. When communicating that a resource file is available, the record company or distributor shall include a TechnicalDetails composite with the IsProvidedInDelivery flag set to true in the relevant resource composite in the NewReleaseMessage. However, the presence of just a TechnicalDetails composite is not an indication that a resource file is available.

   2. When updating metadata of a resource, the record company or distributor is not obliged to re-send the related resource file. However, if, when updating resource metadata, the IsProvidedInDelivery flag in the TechnicalDetails composite is set to true, this indicates that a new version of the resource file is available.

   3. When the record company or distributor wishes to provide a new version of a resource file, the record company or distributor shall include a TechnicalDetails composite with the IsProvidedInDelivery flag set to true in the relevant Resource composite in the NewReleaseMessage.

   4. While it is permissible to update resource metadata without sending TechnicalDetails, this may lead to existing Deals becoming “orphaned” if they reference a TechnicalDetails composite which does not contain any data.

4. Primary and Secondary Resources

   1. If the record company or distributor needs to provide a new version of one (or more) Primary Resource file(s), all Primary Resource files that have the same SoundRecordingEdition or SoundRecordingType as the file to be updated must also be updated. This does not mean that any Secondary Resource file(s) need to be updated.

   2. If the record company or distributor needs to provide a new version of one (or more) Secondary Resource file(s), all Secondary Resource files must be updated. This does not mean that any Primary Resource file(s) need to be updated.

   3. In the context of a pre-order release, the term “all” in the above sentences is to be understood as all resources that are (or are to be made) available. This may well be a subset of the complete set.

5. Optimising resource delivery (informative)
   The provisions of the rules 1-4 above prioritise simplicity of implementation over reducing data traffic. There are, however, means to reduce the data traffic.
   When a DSP receives a NewReleaseMessage containing a number of TechnicalDetails composites with the IsProvidedInDelivery flag set to true, the DSP knows that for each TechnicalDetails composite, one resource file will be available. Assuming the record company or distributor includes a hash sum for the resource file (as part of File in the TechnicalDetails composite), the DSP can decide whether to ingest the new resource file or to use the resource file it already has received in the past. This is especially useful when the release delivery process is based on web services (rather than cloud-based storage).