Candidate Standard

Skip to end of metadata
Go to start of metadata
This section of the DDEX Knowledge Base contains version 1.0 of the "US Musical Work Licensing Choreography Standard"

1 Introduction

This standard was developed by the member organisations of the Digital Data Exchange, LLC (DDEX) and provides a suite of messages that give a uniform mechanism for companies such as Record Companies, Digital and Mobile Service Providers (DSPs) and others to request a licence for a Musical Work (or Right Shares thereof) from owners (or agents of owners) of such Work or Right Shares and for the owners (or agents) to provide licences (or rejections) back. This standard can also be used to communicate “intentions to use” to owners (or agents of owners) in the context of controlled composition clauses or where statutory licences are in place and for such owners (or agents of owners) to acknowledge such an intention to use. Finally, this standard provides a mechanism to revoke existing licences.

While this standard can be used by any company as outlined above, it was specifically designed to address to requirements of the US market.

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

 2.1 Introduction
The messages and the choreography defined in this standard provides a mechanism for (potential) Licensees of Musical Works (or Right Shares thereof) such as record companies, DSPs and other companies to:

Furthermore, the messages and the choreography defined in this standard provide  a mechanism for Rights Controllers (usually music publishers or Collective Management Organisations or their agents) to 

  • Reply to such requests for licences by granting or refusing a licence; and
  • Confirm or reject t he acceptance of such “intentions to use”.

 

Finally, this standard provides a uniform mechanism for Licensees or Licensors to revoke a licence.

 2.2 Organisation of the Document
This DDEX Standard has six clauses. Clauses 1 and 2 provide a general introduction and the scope of this standard. Clauses 3 and 4 give a set of normative references as well as terms, definitions and abbreviations that are used in this standard.

 

3 Normative References

 3 Normative References
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
  • 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

 4.1 Terms and Definitions

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.

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

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.

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.

 4.2 Abbreviations
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
MLCMusic Licensing Company
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

5 Musical Work Licensing Choreography for the US Market

 5.1 Overall Choreography

 5.1.1 Direct Communication
The diagrams below depict the choreography defined by this standard.

It should be noted that a prerequisite for an efficient use of the messages in the standard requires that the (potential) Licensee identifies the Rights Controller(s) of the Right Share(s) in the Musical Work(s) it wishes to license. The most efficient way would be to use DDEX’s Musical Work Right Share Notification Choreography Standard for this.

 

Figure 1 – US Musical Work Licensing Choreography (Licensing)


Figure 2 – US Musical Work Licensing Choreography (Revocation)

 

The table below summarises the points in the US Musical Work Licensing Choreography that a message is sent.

Table 1: Messages and Triggers in the US Musical Work Licensing Choreography Standard

Message Name

Initiating Event

1

LicenseRequestMessage

A (potential) Licensee has gathered ownership information with respect to a Musical Work (or Right Share thereof)[1] and wishes to obtain a licence from the relevant Rights Controller (e.g. music publisher or Collective Management Organisation or its agent).

A Licensee has gathered ownership information with respect to a Musical Work and has determined that it already has a licence and it wishes to inform the relevant Rights Controller about its intent to use the Musical Work.

2

LicenseMessage

The Rights Controller of a Musical Work (or Right Share thereof) has received a Licence Request in the form of a LicenseRequestMessage and wishes to grant, or reject, the request.

The Rights Controller of a Musical Work (or Right Share thereof) has received an intention-to-use notification in the form of a LicenseRequestMessage and wishes to inform the Licensee that it accepts (or rejects) the supplementary documentation as evidence for the licence.

3

LicenseRevocationMessage

One of the parties of a l icence for the use of a Musical Work (or Right Share thereof) needs to revoke the licence.

4

ManifestMessage

A party has finished collating messages in accordance with this standard into a Batch and wishes its business partner to commence ingesting it.

5

FtpAcknowledgementMessage

A party receives a Batch of messages in accordance with this standard. The party then acknowledges receipt of each message (this is not an agreement with its content).



[1] By employing DDEX’s Musical Work Right Share Notification Choreography Standard, for example.

 5.1.2 Communication via a Hub

5.1.2.1 Introduction

Licensees and Licensors can exchange the LicenseRequestMessageLicenseMessage and LicenseRevocationMessage with the help of a central Hub. The standard supports two modes:

  1. The Hub acts solely as a router where the Message Sender addresses the message at the ultimate Message Recipient but sends the message, in accordance with Clause 5.2 or 5.3, to a Hub. The Hub then forwards the message to the ultimate Message Recipient, typically without ingesting any of the message content; or
  2. The Hub acts as a message distributor where the Message Sender addresses the message at the Hub, which then determines, from the message content, the ultimate Message Recipient(s) and forwards the message.

This choreography does not allow signalling back to the original Message Sender whether the forwarding was successful.

Details for both modes are provided below.

5.1.2.2 Hub as a Router

A prospective Licensee may send a LicenseRequestMessage to a Hub, expecting it to be delivered to a Rights Controller from which the prospective Licensee wishes to obtain a licence. The MessageHeader/MessageRecipent shall therefore contain the PartyId of the Rights Controller.

The Hub shall then forward the LicenseRequestMessage to the identified Rights Controller. If this communication is effected in accordance with this standard, the MessageHeader/MessageSender of the forwarded message shall be the Hub and the MessageHeader/SentOnBehalfOf shall be the sender of the original LicenseRequestMessage.

The same approach would be used for communicating LicenseMessages and LicenseRevocationMessages.

5.1.2.3 Hub as a Message Distributor

A prospective Licensee may also send a LicenseRequestMessage for one or more licences to a Hub addressed to the Hub, i.e. the MessageHeader/MessageRecipent shall contain the PartyId of the Hub.

The Hub shall then determine the appropriate Rights Controller(s) (by evaluating the Right Shares referenced from the LicenseRequest composite in the LicenseRequestMessage) and send new LicenseRequestMessage(s) to the identified Rights Controller(s). If this communication is effected in accordance with this standard, the MessageHeader/MessageSender of the forwarded message shall be the Hub and the MessageHeader/SentOnBehalfOf shall be the sender of the original LicenseRequestMessage.

The same approach would be used for communicating LicenseMessages and LicenseRevocationMessages.

 

 

 5.2 SFTP Choreography

 5.2.1 Introduction
The exchange of messages defined in this standard shall use the SFTP using the naming convention defined in this Clause.

The arrival of the Batch on the SFTP server shall be signified by placing a Manifest file at the appropriate location. The Manifest 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.

 5.2.2 Folder Naming Convention
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.
 5.2.3 XML File Naming Convention
Each message sent in the Batch shall be named as follows: RRRR_SSSSS.xml with
  • RRRR being the role of the message as follows:
    • "License_Request" for the LicenseRequestMessage;
    • "License" for the LicenseMessage; and
    • "License_Revocation" for the LicenserevocationMessage;
  • SSSSS being a zero padded serial number within that Batch.
 5.2.4 Supporting File Naming Convention
Any document supporting a DDEX message in a Batch shall be placed into the same folder as the XML message and be named as follows: FFFF_NNNN.ext with
  1. FFFF being the file name (without extension) of the file to which supporting information is provided;
  2. NNNN being a serial number; and
  3. ext being an extension suitable to the data type (e.g. xml for an XML file or csv for a comma-separated value flat file).
 5.2.5 Manifest
Once the message sender has uploaded all files of the Batch, the sender shall upload a manifest file. The manifest file shall be called manifest.xml and shall be placed into the same folder as all other files.

Its syntax is defined in Clause 6 .

 5.2.6 Acknowledgement
Once the message recipient has downloaded a file from within the Batch, the recipient shall upload an acknowledgement file. The acknowledgement file shall be called 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 .

 5.2.7 Size of Batch
Each file within a Batch should contain up to 500 Musical Works. Sender and recipient may agree other limits.

The maximum number of files to be part of a Batch is not limited but may be agreed by Sender and recipient.

 5.2.8 Hybrid Batches
It is possible to place messages defined in other DDEX Choreography Standards relating to Musical Works in the same Batch as messages defined in accordance with this standard.

 5.3 Web Service Choreography

 5.3.1 Introduction

This standard defines two approaches to communicating Licence requests, intentions to use, Licences, confirmations for intentions to use as well as Licence revocations:

  • Asymmetric where only the (prospective) Licensor needs to publish and maintain a Web Service and where the (prospective) Licensee will need call these Web Services and thus initiate the communication.
  • Symmetric where both the (prospective) Licensor and the (prospective) Licensee publish and maintain a Web Service.

They are described below.

 5.3.2 Symmetric Choreography
The process of symmetric communication between (prospective) Licensee and (prospective) Licensor contains theses steps:
  1. The (prospective) Licensee calls the Web Service endpoint published by the (prospective) Licensor using the POST LicenseRequest call with a LicenseRequestMessage;  
  2. The (prospective) Licensor replies to this call with a LicenseMessage (if it has all information available  – not shown in the diagram) or a HTTP status code which informs the (prospective) Licensee that the information will be provided at a later stage;
  3. For each licence request that has not been fulfilled immediately, the (prospective) Licensor can call the (prospective)  Licensee POST License Web Service endpoint with the requested LicenseMessage once it has assembled the information.
  4. Licensor can call the same Web Service end point to communicate a LicenseRevocationMessage.

 

Theses steps are depicted below.

It is also possible to use this choreography in a set-up where the communication between Licensee and Licensor is facilitated by an intermediary. In such cases, the intermediary would communicate with the Licensee as if it were a Licensor. Similarly, the intermediary would communicate with the Licensor as if it were a Licensee.
 5.3.3 Asymmetric Choreography with Atom Feeds
The process of asymmetric communication where only the Licensor publishes and maintains a Web Service between (prospective) Licensee and (prospective) Licensor contains theses steps:
  1. The (prospective) Licensee calls the Web Service endpoint published by the (prospective) Licensor using the POST LicenseRequest call with a LicenseRequestMessage;  
  2. The (prospective) Licensor replies to this call with a simple Acknowledgement.
  3. The (prospective) Licensee regularly calls the Web Service endpoint published by the (prospective) Licensor using the GET LicenseList call;
  4. The (prospective) Licensor replies to this with an Atom feed providing  URLs for all LicenseMessages and LicenseRevocationMessages that are ready to be collected;
  5. The (prospective) Licensee can then call the (prospective) Licensor GET License  Web Service endpoint for each URL provided in Step 4 to which the (prospective) Licensor will respond with the requested LicenseMessage or LicenseRevocationMessage.


Theses steps are depicted below.

It is also possible to use this choreography in a set-up where the communication between Licensee and Licensor is facilitated by an intermediary. In such cases, the intermediary would communicate with the Licensee as if it were a Licensor. Similarly, the intermediary would communicate with the Licensor as if it were a Licensee.

 

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

 5.3.5 Personalising the Feed
For companies that wish to receive or send licences 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.
 5.3.6 Web Server Set-up and Authentication

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 Web Service Commands

 

 5.3.8.1 POST LicenseRequest

5.3.8.1.1   Purpose

This command can be used by a (prospective) Licensee to request a licence from a (prospective) Licensor.

The (prospective) Licensee will call, after appropriate authentication if needed, the Web Service address previously agreed between (prospective) Licensee and (prospective) Licensor with a LicenseRequestMessage.

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.

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

When used in an asymmetric choreography, a HTTP status code of 202 indicates that the Licensor's Web Service will, in due course, be able to communicate a licence via an Atom feed to the Licensee.

Note: the LicenseMessage can communicate both granted licences as well as rejected licences.

 5.3.8.2 POST License

5.3.8.2.1   Purpose

This command can be used by a Licensor to provide a licence or a licence revocation to a Licensee.

The Licensor will call, after appropriate authentication if needed, the Web Service address previously agreed between Licensor and Licensee with a LicenseMessage or a LicenseRevocationMessage.

5.3.8.2.2    Syntax of Reply

The Web Service 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 Licensor and Licensee.

 5.3.8.3 GET LicenseList

5.3.8.3.1    Purpose

This command can be used by a (prospective) Licensee to request a list of licenses (and licence revocations) from a (prospective) Licensor.

The (prospective) Licensee will call, after appropriate authentication if needed, the Web Service address previously agreed between (prospective) Licensee and (prospective) Licensor.

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

  1. from: Get items older than this time stamp (inclusive). The time stamp shall be provided in ISO 8601 format (yyyy-mm-dd);

  2. to: Get items newer than this time stamp (inclusive). The time stamp shall be provided in 8601 format (yyyy-mm-dd);

  3. offset: Offset into list of the first item to return; and

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

Other query formats may be used on bilateral agreement between (prospective) Licensee and (prospective) Licensor.

The  GET LicenseList 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.3.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.

The web server shall also return to the calling web service client an Atom feed document that meets any parameters (if provided) as defined elsewhere in this standard.

 5.3.8.4 GET License

5.3.8.4.1   Purpose

This command can be used by a (prospective) Licensee to request a licence or licence renovation from a (prospective) Licensor.

The (prospective) Licensee will call, after appropriate authentication if needed, a Web Service address provided in response to a GET LicenseList call.

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

If the HTTP status codes is 200, the Web Service shall also return to the calling web service client an XML document containing a valid LicenseMessage or LicenseRevocationMessage.

6 Message Definition

 6.1 Introduction

The hierarchical structure of the messages is provided through indentation in the tables below. In addition to the tabular description of the message, which should always be read in conjunction with Annex A, 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 by the business partners. 

 6.2 General Conformance Rules

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-us-lic/10

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.

 6.3 Definition of Messages

The tabular rendering of the messages  is provided in a separate document. See the red box here.

Editorial Comment
The above link will become active when the standard is published. For the time being the tables are provided as a separate document.

 6.4 Allowed Value Sets

The table below lists all allowed value sets with their allowed values and definitions that are valid within this standard. Note, 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 red box here.

Editorial Comment
The above link will become active when the standard is published. For the time being the AVSs are provided as a separate document.

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.