- Created by DDEX Secretariat, last modified on 2020-04-01
1 Introduction
Download Standard (PDF)
Download/Print standard tables (XLS)
XML Schema Definition Files (ZIP)
Older versions of the Works Licensing & Notification standards can be accessed here.
MWN 1.2 is a "Candidate Standard", which is a formal standard approved by DDEX for which DDEX has not had any information about live implementations. Once DDEX has received such input, it is expected that MWN will be promoted to "DDEX Standard".
Before starting an implementation, DDEX recommends to read Starting an Implementation and Licensing DDEX Standards.
... 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)
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.
2 Scope
- Provide to record companies, DSPs and other companies information about ownership of Right Shares in one or more Musical Works in a standardised information flow;
- Exchange with DSPs offering “user-generated content” to consumers information about ownership of Rights Shares in one or more Musical Works.
As user-generated content is often based on musical works, it is essential for the owners of rights in the Musical Work as well as the DSP that the DSP has an accurate picture of the ownership of a Musical Work they want to exploit and monetise. This is particularly important for territories such as the US where licensing is typically de-centralised or on a Work-by-Work basis;
The choreography can also be used for information exchanges regarding Musical Works and/or Right Shares as part of the US Musical Work Licensing Choreography as well as the (forthcoming) US Letters of Direction Choreography.
Furthermore it allows DSPs, record companies and other companies to solicit such information from Works Licensors. Such requests may often include information about the Release(s) and Resource(s) such Works are used in.
Other applications include the provision of lyrics to a lyrics DSP, the provision of information on print rights, cases where a DSP might want to augment writer data they hold in order to improve consumer experience and supplying data to intermediaries who are doing administration on a DSP’s behalf.
Clause 5 then provides the Musical Work Right Share Notification Choreography and two Message Exchange Protocols: FTP and Web Services. Finally, Clause 6 defines the messages for the Musical Work Right Share Notification Choreography.
AvsVersionId
attribute on all message tags optional and changes the data type to xs:string
.Version 1.2 adds support for updating and recalling messages.
Version 1.1 adds support for a Hub-based architecture where a central Hub is used to channel requests for rights share claims as well as Right Share claims between (prospective) Licensees and (prospective) Licensors. This is in addition to the direct information exchange between (prospective) Licensees and (prospective) Licensors. Version 1.1 was not published and only used for internal testing.
Version 1.1 also adds support for Web Services.
3 Normative References
- DDEX Data Dictionary Standard. Latest Version
- DDEX Party Identifier (DPID) Standard. Latest Version
- IFPI: Global Release Identifier (GRid) Standard. Latest Version
- IETF. RfC 2026. SSH File Transfer Protocol. October 2001.
- IETF. RfC 2616. Hypertext Transfer Protocol (HTTP/1.1). 1999
- IETF. RfC 3986. Uniform Resource Identifier (URI): Generic Syntax. 2005
- IETF. RfC 5023. The Atom Publishing Protocol. October 2007
- IETF RfC 5646, Tags for Identifying Languages. Latest Version.
- IETF. RfC 6797. HTTP Strict Transport Security (HSTS). November 2012
- ISO 639-1988, Code for the representation of the names of languages
- ISO 3166-1:1997 Codes for the representation of names of countries and their sub-divisions – Part 1: Country codes
- ISO 3901:2001, Information and documentation – International Standard Recording Code (ISRC)
- ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times[1]
- W3C. XML Schema Part 1: Structures. Second Edition. 2004
- W3C. XML Schema Part 2: Datatypes. Second Edition. 2004
[1] Information on ISO 8601 can be found in Annex D of Part 2 (Datatypes Second Edition) of the XML Schema standard (http://www.w3.org/TR/xmlschema-2/#isoformats).
4 Terms and Abbreviations
Administrator
A Party administrating Rights on behalf of one or more RightsControllers (in the context of this standard a Collecting Publisher).
Batch
A grouping of one or more DDEX Messages to be processed by the recipient together.
Collecting Publisher
A RightsController who is, at the time of assertion, controlling the right to collect royalties for a specific RightsType in a specific Territory for a specific Musical Work. Collecting Publishers may ask Administrators to administer some of their rights. Note that a MusicalWork may have zero, one or many Collecting publishers.
Collective Management Organisation (CMO)
A Party (that is usually owned or controlled by its members and/or organised on a not-for-profit basis) that, as its sole or main purpose, administers copyright or related rights on behalf of at least two Rights Controllers, for the collective benefit of those Rights Contorllers where it is authorised by law or by way of assignment or Licence.
A Collective Management Organisation may also be a Licensor, a Rights Administrator, a Licensing Agent or a Rights Holder.
A Collective Management Organisation may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.
Distribution Share
The proportion of the overall Musical Work that has been assigned to a Collecting Publisher or Administrator. Note that a Writer can have zero, one or many Original Publishers, and hence zero, one or many Distribution Shares.
Hub
A service that acts as a broker for information exchange, typically using DDEX Messages. In the context of the Musical Works Notification, Musical Works Licensing and Letter of Direction Standards defined by DDEX, a Hub acts as an intermediary for information exchange to facilitate sharing of Right Share information. Hubs may also play a role in facilitating licensing processes between (prospective) Licensors and (prospective) Licensees. Hubs may also act as routers and/or provide data caching functionality.
Licensee
A Party that is granted a Licence in respect of rights in one or more Creations, by a Licensor. The Licensee may be a human being or other legal person or corporate entity. The Licensee may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.
Licensor
A Party that grants a Licence in respect of rights in one or more Creations to one or more Licensees in accordance with the authorities it has been granted to do so by one or more Rights Controller(s), Rights Administrator(s) (where applicable), Licensing Agent(s) (where applicable) or Rights Holder(s). The Licensor may be a human being or other legal person or corporate entity. The Licensor may or may not also be the Rights Controller, the Rights Administrator, the Licensing Agent or the Rights Holder in the Creation(s) that are the subject of the Licence granting the rights. The Licensor may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.
Manuscript Share
The proportion of a Musical Work written by a Writer, as agreed between the Writers. Typically represented as a percentage or a fraction. Manuscript Shares may occasionally vary by territory and/or rights type.
Musical Work
A Work intended to be perceivable as a combination of sounds, with or without accompanying text.
Any words that are intended to be expressed with a MusicalWork (often termed Lyrics) form part of that MusicalWork; not all MusicalWorks have Lyrics.
A MusicalWork may be expressed and fixed to become part of a SoundRecording or a Video Recording, or may be used to create notated music (sheet music, scores, instrumental parts) or sound generation codes (such as MIDI files).
In some cases, the MusicalWork comes into existence simultaneously with its expression. This is common in extemporised forms such as jazz music.
Original Publisher
A RightsController who is assigned rights directly by the Writer (as opposed to by another Publisher). Note that a writer may have zero, one or many Original Publishers.
Original Publisher Share
The proportion of the overall Musical Work that a writer has assigned to an Original Publisher. Note that each Writer can have zero, one or many Original Publishers, and hence zero, one or many Original Publisher Shares. As opposed to collection shares, an OriginalPublisherShare does not define a share for the collection of money.
Release
A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.
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.
Right Share
A percentage or fraction of a right for a Musical Work for a particular time and place in which a party claims a controlling interest. Note: controlling interest includes ownership and/or administration.
Rights Controller
A Party that controls rights in one or more Creations in respect of some or all rights for specific territories, time periods, Rights Types, Usage Types and Commercial Model Types (which may be anything up to and including all rights for the world, in perpetuity, for all types of Usage and for all types of Commercial Models). Creations include Musical Works, Sound Recordings and other Resources as well as Releases.
A Rights Controller is in many cases also the Licensor.
A Rights Controller may be a human being or other legal person or corporate entity.
A Rights Controller may or may not also be the Rights Administrator, the Licensing Agent or the Rights Holder.
A Rights Controller may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.
Rights Type
The type of right covered by a RightShare as defined by relevant law. Rights Types vary between territories. Typical rights types include mechanical rights, performing rights and synchronisation rights.
Sound Recording
An audible persistent manifestation of a subject (often but not necessarily of a performance).
Web Service
A modern set of web technologies that allow small pieces of information, typically in the form of XML files, to be exchanged. Augmented with FTP (or other file exchange mechanisms) they can be used to communicate Releases along the music supply chain.
Web Service Call
The sending of an XML document to a port/address on a web server, using HTTP or HTTPS.
Web Service Response
The sending of an XML document in direct response to a Web Service Call, using HTTP or HTTPS.
For the avoidance of doubt: the appropriate response is always the message indicated in the appropriate Choreography.
Writer
A creative creator of the musical or lyrical elements of a Musical Work. Writers include Adapters, Arrangers, Authors, Composers. ComposerLyricists, Librettists, Lyricists, NonLyricAuthors and Translators.
Writer Share
See Manuscript Share.
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 | |
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 |
5 Choreography
This standard supports two approaches to exchanging Right Share information: Either a (prospective) Licensee and a (prospective) Licensor can exchange information directly with one another, or the communication can be communicated via a central Hub which may act as a information routing service and/or as a Right Share information cache.
Figure 1: Direct communication between a (prospective) Licensee and a (prospective) Licensor
Figure 2: Communication between a (prospective) Licensee and a central Hub
Figure 3: Communication between a central Hub and a (prospective) Licensor
The table below summarises the points in the Musical Work Right Share Notification Choreography that a message is sent.
Message Name | Initiating Event | Sender | Recipient | |
1a |
| If a record company, DSP, Hub or other company wishes to receive information about a Musical Work and/or its ownership (e.g. for the purposes of obtaining a licence or to make available or monetise a Release containing a Musical Work) but has no, or insufficient, claims or Right Share information. This also applies when a record company, DSP, Hub or other company wishes to update its request (e.g. because of changes to the writer or publisher information). This is only illustrated in Fig. 1, but also applies to the choreographies involving a Hub (Figs. 2 and 3). | (prospective) Licensee | (prospective) Licensor |
1b | (prospective) Licensee | Central Hub | ||
1c | Central Hub | (prospective) Licensor | ||
2a |
| If a Works Licensor or Hub wishes to inform a DSP or Hub about its own or other companies' claims or Right Share information with respect to Works embodied in a Release [1]
This also applies when a Works Licensor or Hub wishes to update a previously sent | (prospective) Licensor | (prospective) Licensee |
2b | (prospective) Licensor | Central Hub | ||
2c | Central Hub | (prospective) Licensee | ||
3 | MusicalWorkClaimRequestRecallMessage | If a record company, DSP, Hub or other company notices that it no longer requires claim information and wishes to recall its This is only illustrated in Fig. 1, but also applies to the choreographies involving a Hub (Figs. 2 and 3). | (prospective) Licensee | (prospective) Licensor |
(prospective) Licensee | Central Hub | |||
Central Hub | (prospective) Licensor |
The exchange of the information in these messages can be effected by two different message exchange protocols: SFTP and Web Services. Details on these are defined in Clauses 5.2 ad 5.3 respectively.
[1] As indicated, the message can be used by a Licensor to communicate ownership information regarding a Musical Work not owned or controlled by the sender of the message. In that case, the recipient may use the information not as authoritative but solely as “helpful information”.
Message Name | Initiating Event | Sender | Recipient | |
3 | ManifestMessage | A party has finished collating This message is only used when the | Sender of "main" messages | Recipient of "main" messages |
4 | FtpAcknowledgementMessage | A party receives a Batch of messages in accordance with this standard. The party then acknowledges receipt of each message (not agreement with its content). This message is only used when the | Recipient of "main" messages | Sender of "main" messages |
The arrival of the Batch on the SFTP server shall be signified by placing a manifest file (as defined below) at the appropriate location. The manifest file shall refer, indirectly or indirectly to all files that are part of the Batch. The Manifest may only be placed on the SFTP server, once all other files have been completely uploaded.
YYYYMMDDhhmmssnnn
withRRRR_SSSSS.xml
withRRRR
being the role of the message as follows:- "Claim_Request" for the
MusicalWorkClaimRequestMessage
; - "Claim_Notification" for the
MusicalWorkClaimNotificationMessage
;
- "Claim_Request" for the
SSSSS
being a zero padded serial number within that Batch.
FFFF_NNNN.ext
withFFFF
being the file name (without extension) of the file to which supporting information is provided;NNNN
being a serial number; andext
being an extension suitable to the data type (e.g.xml
for an XML file orcsv
for a comma-separated value flat file).
ACK_FFFF.xml
with FFFF
being the file name (without extension) of the message acknowledged.The acknowledgement shall be placed into the same folder as the acknowledged file. Its syntax is defined in Clause 6.
The maximum number of files to be part of a Batch is not limited but may be agreed by Sender and recipient.
The approach to communicating Rights Share claims and requests for Rights Share claims defined in this clause is asymmetric: only one party will need to publish and maintain a Web Service. The other party will need call these Web Services and thus initiate the communication.
As a consequence the party that calls the Web Service determines the speed of the communication. Whenever that party is able or interested to receive information, it can call its business partner’s Web Service. It is then the responsibility of that party to deliver the appropriate information.
This standard defines two Web Service choreographies:
- One where the information is exchanged directly between (prospective) Licensee and (prospective) Licensor; and
- One where the information is exchanged via a central Hub.
In both cases, two Web Service interfaces are defined:
- The Web Service interfaces offered by company that wishes to receive
MusicalWorkRightsClaimRequestMessage
from its business partners; and - The Web Service interfaces offered by company that wishes to receive
MusicalWorkRightsClaimNotificationMessage
from its business partners.
Theses choreographies and interfaces are depicted below. Figures shows the direct communucation between (prospective) Licensee and (prospective) Licensor whereas Figure 5 depicts the Hub-based approach. The individual steps in the choreography are then defined in Clauses 5.3.2 and 5.3.3.
Figure 4: Web Service Choreography – direct communication

It is for instance possible that a (prospective) Licensee requests a the delivery of a MusicalWorkRightsClaimNotificationMessage
based on the information received on an earlier delivery request command – but that that MusicalWorkRightsClaimNotificationMessage
no longer exists at that URL. In that case the response from the (prospective) Licensor’s or hub's Web Service could be a “redirect” with a 301 status code which could trigger the (prospective) Licensee to request the MusicalWorkRightsClaimNotificationMessage
using the information received in that reply.
5.3.2.1 Introduction
The processes of communicating through a Hub comprises the following steps, it should be noted, that the approach to the communication between (prospective) Licensee and a Hub, and the communication between a (prospective) Licensor and the Hub are (virtually) identical:
- Communication between a (prospective) Licensee and a Hub:
- The (prospective) Licensee calls the web service endpoint published by the Hub using the
POST ClaimRequest
call with aMusicalWorkRightsClaimRequestMessage
; - Until the (prospective) Licensee has received claims for all of its claim requests, it regularly calls the Hub's web service with a
GET ClaimNotificationList
call. - The Hub replies to this call with an Atom feed providing URLs for all
MusicalWorkRightsClaimNotificationMessage
s that are ready to be collected; - The (prospective) Licensee can then call the Hub's
GET ClaimNotification
web service endpoint for each URL provided in Step 1c; and - The Hub will respond with the requested
MusicalWorkRightsClaimNotificationMessage
;
- The (prospective) Licensee calls the web service endpoint published by the Hub using the
- Communication between a (prospective) Licensor and a Hub:
- The (prospective) Licensor regularly calls the Hub's web service with a
GET ClaimRequestList
call. - The Hub replies to this call with an Atom feed providing a URL for all
MusicalWorkRightsClaimRequestMessage
s that are ready to be collected; - The (prospective) Licensor can then call the Hub's
GET ClaimRequest
web service endpoint for each URL provided in Step 2b; - The Hub replies to this call with a
MusicalWorkRightsClaimRequestMessage
; and - The (prospective) Licensor then collates the relevant information and calls the Hub's
POST ClaimNotification
end point with aMusicalWorkRightsClaimNotificationMessage
.
- The (prospective) Licensor regularly calls the Hub's web service with a
5.3.2.2 Identification of specific Claim Requests
One crucial aspect for companies making or releasing (or planning to make or release) a sound recording that makes use of a Musical Work is to establish the various applicable Right Shares for said Musical Work. For this, a (prospective) Licensee typically does some research in order to collate a list of companies it believes own or administer (part of) the Musical Work and from whom a licence can be sought. The company would typically then contact all (prospective) Licensors to establish their Shares before attempting to obtain licences.
When obtaining such Right Share information from a Hub, it is essential that the (prospective) Licensee can link right share notifications to its Right Share requests so that it can determine if all of its requests have been replied to (or not). To support this, MusicalWorkRightsClaimRequestMessage
and MusicalWorkRightsClaimNotificationMessage
carry identifiers that a Hub will need to handle appropriately as follows:
Field in the MusicalWorkRightsClaimRequestMessage (as provided by the prospective Licensee to the Hub) |
---|
The //Request/MusicalWorkShareRequest/RightsControllerRequestId contains a proprietary ID of the (prospective) Licensee for the share request with respect to the (possible) Licensor referenced in //Request/MusicalWorkShareRequest/RequestRightsControlleReference |
Field in the MusicalWorkRightsClaimNotificationMessage (as provided by the prospective Hub to the prospective Licensee) |
The field shall be omitted in all other cases. |
5.3.3.1 Only the (prospective) Licensor has published a Web Server
- The (prospective) Licensee calls the Web Service endpoint published by the (prospective) Licensor using the
POST ClaimRequest
call with aMusicalWorkRightsClaimRequestMessage
; - The (prospective) Licensor replies to this call with a
MusicalWorkRightsClaimNotificationMessage
(if it has all information available – not shown in the diagram above) or a holding message which informs the (prospective) Licensee that the information will be provided at a later stage; - The (prospective) Licensee regularly calls the (prospective) Licensor's web service with a
GET ClaimNotificationList
call. - The (prospective) Licensor replies to this with an Atom feed providing a URL for all
MusicalWorkRightsClaimNotificationMessages
that are ready to be collected; - The (prospective) Licensee can then call the (prospective) Licensor's
GET ClaimNotification
Web Service endpoint for each URL provided in Step 4 to which the (prospective) Licensor will respond with the requestedMusicalWorkRightsClaimNotificationMessage
.
5.3.3.2 Only the (prospective) Licensee has published a Web Server
- The (prospective) Licensor calls the Web Service endpoint published by the (prospective) Licensee using the
GET ClaimRequestList
call to which the - The (prospective) Licensee replies to this call with an Atom feed providing a URL for all
MusicalWorkRightsClaimRequestMessages
that are ready to be collected; - The (prospective) Licensor calls the (prospective) Licensee's web service with a
GET ClaimRequest
call for each URL provided in Step 2; - The (prospective) Licensee replies to this call with a
MusicalWorkRightsClaimRequestMessage
; and - The (prospective) Licensor can call the (prospective) Licensee's
POST ClaimNotification
Web Service endpoint with the requestedMusicalWorkRightsClaimNotificationMessage
once it has assembled the information.
5.3.3.3 Both Parties have published a Web Server
- The (prospective) Licensee calls the Web Service endpoint published by the (prospective) Licensor using the
POST ClaimRequest
call with aMusicalWorkRightsClaimRequestMessage
; - The (prospective) Licensor replies to this call with a
MusicalWorkRightsClaimNotificationMessage
(if it has all information available – not shown in the diagram above) or a holding message which informs the (prospective) Licensee that the information will be provided at a later stage; - For each claim request that has not been able to be fulfilled immediately, the (prospective) Licensor can call the (prospective) Licensee's
POST ClaimNotification
Web Service endpoint with the requestedMusicalWorkRightsClaimNotificationMessage
once it has assembled the information.
The approach to Web Service-based information deliveries is based on URLs that are set at the discretion of the provider of the Web Service interface who publishes the Web Service to its business partners to share information with them.
While it can be assumed that many URLs follow a common syntax there is no compulsion to use this approach. Similarly it is not compulsory that all URLs from a particular Web Service provider follow a common syntax.
All a company that wishes to offer a Web Service in accordance with this standard has to do, is to publish the URL for the relevant Web Service end points to its business partner(s) and make sure that the URLs placed in the responses to Web Service Calls are (i) valid and (ii) active.
Wherever this standard only mentions the HTTP protocol, it is to be understood to allow HTTPS communications.
For companies that wish to receive or send Right Share claims it is often essential that the web server of a company knows who is calling one of its Web Services.
This can be done with or without formal authentication (see the next two sub-clauses). The benefit of using formal authentication is that it also allows to make the information exchange secure.
This standard does not define an authentication mechanism for the Web Service-based communication between companies. Should the two parties require their communication to be authenticated, they are free to use any of the existing web-based authentication methods including, but not limited to, Basic Auth, HTTP Digest Authentication, HTTPS Client Authentication, OAUTH, etc.
5.3.8.1.1 Purpose
This command can be used by a (prospective) Licensee to provide a Right Share claim request to a (prospective) Licensor or a Hub.
The (prospective) Licensee will call, after appropriate authentication if needed, the Web Service address previously agreed between (prospective) Licensee and (prospective) Licensor or a Hub with a MusicalWorkRightsClaimRequestMessage
.
5.3.8.1.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 202 (Request accepted);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
- 500 (Internal server error)
Other standard HTTP status codes may be used on bilateral agreement between (prospective) Licensee and (prospective) Licensor or a Hub.
If the HTTP status codes is 200, the web server shall also return to the calling web service client an XML document containing a valid MusicalWorkRightsClaimNotificationMessage
.
5.3.8.2.1 Purpose
This command can be used by a (prospective) Licensee to request a list of Right Share claims from (prospective) Licensor or a Hub.
The (prospective) Licensee will call, after appropriate authentication if needed, the Web Service address previously agreed between (prospective) Licensee and (prospective) Licensor or a Hub.
5.3.8.2.2 Parameters
In order to allow the web service caller to request a specific list of items to be returned in response to this call, the web server shall support the following query syntax defined in RfC 3986. It is permissible to communicate multiple queries separated by ampersands (&). If multiple queries are provided they shall be deemed to be logically AND-combined.
from: Get items older than this time stamp (inclusive). The time stamp shall be provided in ISO 8601 format (yyyy-mm-dd);
to: Get items newer than this time stamp (inclusive). The time stamp shall be provided in 8601 format (yyyy-mm-dd);
offset: Offset into list of the first item to return; and
limit: Maximum number of items to return. If the limit is set to 0 it means "all" items.
The example below requests an Atom feed containing 10 entries starting from the 100th item generated in January 2016:
GET https://www.example.com/base/url?from=2016-01-01&to=2016-01-31&offset=100&limit=10
Other query formats may be used on bilateral agreement between (prospective) Licensee and (prospective) Licensor or Hub.
The GET ClaimNotificationList
command may also be used without any parameters. In that case the web server will decide the items to send in the Atom feed.
5.3.8.2.3 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 406 (Not Acceptable query);
- 414 (Request-URI Too Long);
- 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
- 500 (Internal server error)
Other standard HTTP status codes may be used on bilateral agreement between (prospective) Licensee and (prospective) Licensor or Hub.
The web server shall also return to the calling web service client an Atom feed document that meets any parameters (if provided) as defined in Clause 6.3 .
5.3.8.3.1 Purpose
This command can be used by a (prospective) Licensee to request a Right Share claim notification to a (prospective) Licensor or a Hub.
The (prospective) Licensee will call, after appropriate authentication if needed, a Web Service address provided in response to a GET ClaimNotificationList
call.
5.3.8.3.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 202 (Request accepted);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
- 500 (Internal server error)
Other standard HTTP status codes may be used on bilateral agreement between (prospective) Licensee and (prospective) Licensor or a Hub.
If the HTTP status codes is 200, the Web Server shall also return to the calling web service client an XML document containing a valid MusicalWorkRightsClaimNotificationMessage
.
5.3.8.4.1 Purpose
This command can be used by a (prospective) Licensor to request a list of Right Share claims from (prospective) Licensee or a Hub.
The (prospective) Licensor will call, after appropriate authentication if needed, the Web Service address previously agreed between (prospective) Licensor and (prospective) Licensee or a Hub.
5.3.8.4.2 Parameters
In order to allow the web service caller to request a specific list of items to be returned in response to this call, the web server shall support the following query syntax defined in RfC 3986. It is permissible to communicate multiple queries separated by ampersands (&). If multiple queries are provided they shall be deemed to be logically AND-combined.
from: Get items older than this time stamp (inclusive). The time stamp shall be provided in ISO 8601 format (yyyy-mm-dd);
to: Get items newer than this time stamp (inclusive). The time stamp shall be provided in 8601 format (yyyy-mm-dd);
offset: Offset into list of the first item to return; and
limit: Maximum number of items to return. If the limit is set to 0 it means "all" items.
The example below requests an Atom feed containing 10 entries starting from the 100th item generated in January 2016:
GET https://www.example.com/base/url?from=2016-01-01&to=2016-01-31&offset=100&limit=10
Other query formats may be used on bilateral agreement between (prospective) Licensee and (prospective) Licensor or Hub.
The GET ClaimRequestList
command may also be used without any parameters. In that case the web server will decide the items to send in the Atom feed.
5.3.8.4.3 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 406 (Not Acceptable query);
- 414 (Request-URI Too Long);
- 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
- 500 (Internal server error)
Other standard HTTP status codes may be used on bilateral agreement between (prospective) Licensor and (prospective) Licensee or Hub.
The web server shall also return to the calling web service client an Atom feed document as defined in Clause 6.3 .
5.3.8.5.1 Purpose
This command can be used by a (prospective) Licensor to request a claim Request to a (prospective) Licensee or a Hub.
The (prospective) Licensor will call, after appropriate authentication if needed, a Web Service address provided in response to a GET ClaimRequestList
call.
5.3.8.5.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 202 (Request accepted);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
- 500 (Internal server error)
Other standard HTTP status codes may be used on bilateral agreement between (prospective) Licensor and (prospective) Licensee or a Hub.
If the HTTP status codes is 200, the web server shall also return to the calling web service client an XML document containing a valid MusicalWorkRightsClaimRequestMessage
.
5.3.8.6.1 Purpose
This command can be used by a (prospective) Licensor to provide a Right Claim Notification to a (prospective) Licensee or a Hub.
The (prospective) Licensor will call, after appropriate authentication if needed, the Web Service address previously agreed between (prospective) Licensor and (prospective) Licensee or a Hub with a MusicalWorkRightsClaimNotificationMessage
.
5.3.8.6.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
- 500 (Internal server error)
Other standard HTTP status codes may be used on bilateral agreement between (prospective) Licensor and (prospective) Licensee or a Hub.
6 Message Definition
This Clause contains an overview for each of the two messages in the Musical Work Share Notification Choreography Standard in a tabular form. The full technical specification is includes the XML Schema files accompanying this standard.
The hierarchical structure of the messages is provided through indentation. On the MessageHeader
for example, the PartyName
is a child of Sender
. Thus, a Sender
contains a PartyName
(plus a PartyId
). A second example from the MessageHeader
is the MessageAuditTrail
that contains MessageAuditTrailEvents
which, in turn, contains a MessagingPartyDescriptor
and a DateTime
element. All elements that have sub-elements are printed in bold. The MessageAuditTrailEvents
element also shows a second structural feature of the MessageSummary
: the cardinality. In the case of MessageAuditTrailEvents
the entry "1-n" means that each MessageAuditTrail
contains one or more MessageAuditTrailEvents
.
Other possible cardinality entries are: "1" (for exactly one), "0-1" (for none or one) or "0-n" (for none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the message sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword XmlChoice
. This keyword is not part of the messages; instead exactly one of the “branches” below the XmlChoice
keyword has to be used.
In addition to the tabular description of the message, which should always be read in conjunction with the XML Schema files, additional conformance rules, which go beyond XML Schema validation, are provided where necessary. The general conformance rules for all messages within this Standard are provided in Clause 6.2.
Specific business processes between sender and recipient may require even further conformance rules. These are, however, not part of the standard and will need to be agreed between business partners. Rules relating to the authority of business partners to unilaterally change the message standard in this way are set out in the current version of the Procedures for the Development and Maintenance of DDEX Standards which forms part of the overall governance of the DDEX Standards.
The syntax as well as the semantics of the various elements in the messages is provided in this clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.
6.2.1 Schema Validation
A message is conformant to this specification only when it validates against the set of XML Schema files provided.
6.2.2 Namespace
The full namespace for the XML Schema document for this Standard is
http://ddex.net/xml/mc-notif/121
All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary available from ddex.net.
6.2.3 Allowed Value Lists
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 kb.ddex.net.
http://ddex.net/xml/avs/avs
The full namespace for the XML Schema document for the allowed-value sets is:
DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list issued on a date later than the date on which this standard is issued form part of this standard. This clause contains the list of allowed-value sets valid on the date of issuance of this standard.
6.2.4 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 by MessageSender
and MessageRecipient
.
6.2.5 Character Coding
All messages shall be sent in UTF-8.
The tabular rendering of the messages is provided in a separate document. See the red box here.
The Table of AVSs is provided in a separate document. See the red 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.