THIS IS AN OLD VERSION. DDEX RECOMMENDS TO USE THE LATEST VERSION.

Skip to end of metadata
Go to start of metadata

This section of the DDEX Knowledge Base contains Version 1.6.1 of Part 1 of the "ERN Choreography Standard" addressing SFTP Exchanges

 1 Introduction

DDEX has standardised a series of Message Suite Standards that define the syntax and semantics of business metadata exchanged by members of the digital media delivery chain. DDEX has also standardised an automated message exchange protocol that enable the reliable communication of DDEX messages and associated documents such as resource files, using SFTP.

This standard, together with the Release Notification Message Suite Standard and the Release and Business Profile standards, a uniform mechanism for Release Creators to provide Release Distributors with Releases (metadata and Resource files) as well as Deals for making such Releases available.

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 http://dpid.ddex.net.

2 Scope

 2.1 Introduction
This standard provides a standardised means for Release Creators to make Releases available via Release Distributors. It defines two Profiles using SFTP. A separate standard defines a message exchange protocol for web services.

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 Release Creator and Release Distributor), the structure of the SFTP severs 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.

 2.2 Organisation of the Document
This DDEX Standard has ten clauses and two annexes. Clauses 1 and 2 provide a general introduction and the scope of this Standard. Clauses 3, 4 and 5 give a set of normative references as well as terms, definitions and abbreviations that are used in this Standard. Clause 6 then explains the general approach taken by DDEX to message standardisation. 

 Clauses 7 , 8 and 9 then define the two approaches to communicating Releases with SFTP and with the help of hard disks before Clause 10 defines the two messages that support SFTP communication of Release Notifications.

Finally, Annex A provides a list of all allowed-value sets, including their allowed values and respective definitions as used in this Standard, and Annex B provides release notes, indicating the features new to this version of the ERN Message Suite 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
  • DDEX Digital Signature Standard. Latest Version
  • DDEX Electronic Release Notification Message Suet Standard. Latest Version.
  • DDEX ERN Release Profile for Common Release Types. Latest Version
  • DDEX ERN Business Profiles for Common Deal Types. Latest Version
  • IETF. RfC2026. SSH File Transfer Protocol. October 2001
  • W3C: XML Schema Part 1: Structures. Second Edition. 2004
  • W3C: XML Schema Part 2: Data types. Second Edition. 2004

4 Terms and Definitions

 4 Terms and Definitions
 

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.

Message Choreography

A series of message calls and their responses which together communicate a more comprehensive level of meaning between the two business partners.

Non-repudiation

The concept of ensuring that a party cannot repudiate, or refute, the sending or receiving of a message.

Release

A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer for the purpose of distribution to individual consumers, directly or through intermediaries. 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.

 

Release Creator

Release Creator is an organisation which is the owner of copyrights in sound and/or music audiovisual recordings and/or exclusive licensees of copyrights in sound and/or music audiovisual recordings.

Release Family

A set of Releases that are closely related. A typical example of a Release Family is an album communicated as a Main Release plus all the Track Releases whose Resources together form the Album.

Release Distributor

Release Distributor is an organisation, which is duly authorised by a Release Creator to offer Releases manifested in the form of Products to consumers. Release Distributors include Digital Service Providers (DSPs) and Mobile Service Providers (MSPs) as well as other organisations.

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.

 

5 Abbreviations

 5 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

6 Message Design Approach (informative)

 6 Message Design Approach (informative)
All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary. The full namespace for the XML Schema document for this Standard is
http://ddex.net/xml/ern-c-sftp/16

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 a XML Schema Definition file for all of these allowed values. These values are also contained in the DDEX Data Dictionary available from http://ddex.net .


The full namespace for the XML Schema document for the allowed-value sets is

http://ddex.net/xml/avs/avs

DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list are issued on a date later than the date on which this Standard is issued form part of this Standard. Thus the list of allowed-value sets provided Annex A contains the list of allowed-value sets valid on the data of issuance of this Standard.

W3C’s XML Schema Standard has been used to define the structure of the messages and some of the business rules. However, XML Schema alone cannot easily provide a means for complex and conditional validation but XML tools such as eXtensible Stylesheet Language Transformation (XSLT) and XPath could provide a means of developing standard validation modules for each message set.

7 SFTP Release-by-Release Profile

 7.1 Choreography

This clause defines the method how a Release Creator can provide metadata and Resource files, one Release at a time, to a Release Distributor via (i) an SFTP server that is hosted by the Release Creator, (ii) an SFTP server that is hosted by the Release Distributor, (iii) an SFTP server that is hosted by a third party or (iv) a hard disk that is populated by/on behalf of the Release Creator and then shipped to the Release Distributor. This specification does not define on whose hardware the files are being stored; this is for Release Creator and Release Distributor to agree.

The choreography of the SFTP Release-by-Release Profile is as depicted below.

 

The NewReleaseMessage is defined in the latest version of the Electronic Release Notification Message Suite Standard. The structure of the NewReleaseMessage shall follow the Release and Business Profiles agreed as appropriate for the communicated Release(s).

The FtpAcknowledgementMessage is defined in this standard:

The structure and file naming conventions for the SFTP Release-by-Release Profile are defined in Clauses 7.2  and 7.3 of this standard.

This standard does not define when the Release Creator shall start or finish to upload the next NewReleaseMessage (incl. all Resource files). Equally, this standard does not define when the Release Distributor shall start or finish its download.

In addition to the exchanged shown in the diagram above, the recipient of the NewReleaseMessage may use the same message for subsequent status updates (e.g. when, after reporting FileOK after ingestion, closer inspection shows deficiencies not detected previously.

The recipient of the FtpAcknowledgementMessage may remove a FtpAcknowledgementMessage from the SFTP server after an appropriate and mutually agreed period of time. The default period is one month.

 7.2 SFTP Server Organisation
Each Release shall be placed into a separate folder of its own. The folder shall be named with the a priority indicator (see below), followed by an underscore character, the ReleaseId of the Release communicated followed by an underscore character and the date/time of creation in the form YYYYMMDDhhmmssnnn to indicate a sequence with YYYY indicating the year in which the Release is placed on the ftp server while MM and DD indicate the month and day, hhmmss indicate the hour (in 24 hours), minutes and seconds. Finally nnn indicate the millisecond in which the Release is placed on the ftp server.

The value for the priority indicator may be "P" to indicate the Release is deemed to be a priority delivery and "N" to indicate the Release is deemed to be a non-priority delivery. The meaning of priority in this context should be agreed by sender and recipient. Note that mixing non-priority and priority deliveries may cause problems, especially when no acknowledgements are used.

The NewReleaseMessage shall be placed into the same folder. Resource files shall be placed into a subfolder called “resources/”.

If possible, the ReleaseId used should be a GRid as defined in the GRid standard. However, if that is not possible, the Release Creator and Release Distributor shall mutually agree a different unique identifier.

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

 7.3 File Naming Conventions
The NewReleaseMessage shall be named as follows
ReleaseId.Ext

Each Resource file shall be named as follows:

Label_ReleaseId_TechnicalResourceId_ResourceType_Hierarchy.Ext

The FtpAcknowledgement shall be named as follows

ACK_YYYYMMDDhhmmssnnn_ErnMessageId.Ext

With:

  • ReleaseId being the identifier used in the NewReleaseMessage to uniquely identify the Release.
  • Label being an optional, mnemonic token to identify the company compiling the Release. This element is primarily for human intervention and may only contain letters, digits and dashes (“-“)..
  • TechnicalResourceId being an optional string, starting with the letter “T”, that is used in the NewReleaseMesage’s relevant XML tag of the same name to uniquely identify the Resource.
  • ResourceType being an optional element to indicate the type of resource (typically where this is not clear from the Ext element). This may be a generic value such as "SoundRecording" or it may be used to designate a more specific type such as CoverArt or even an abbreviation such as WP for a wallpaper Resource. This element is primarily for human intervention.
  • Hierarchy being an optional element to indicate where, in the hierarchy of the Release the Resource fits. This element should comprise of a sequence of three-digit, zero padded numbers separated by underscores (e.g. 008_015 for the 15th Resource in the 8th Resource Group). This Hierarchy element should correspond to the ResourceGroup composite in the NewReleaseMessage.
  • YYYYMMDDhhmmssnnn being the date and time that the Release is placed on the ftp server.
  • ErnMessageId being the ID used in the ReleaseNotificationMessage being acknowledged.
  • Ext being the typical file extension for the Resource type (or .xml for the NewReleaseMessage or FtpAcknowledgement Message).

Note: The Resource file name in accordance with this clause is only guaranteed to be unique and useful for the duration of the Release delivery (i.e until an acknowledgement has been sent).

This naming convention is not necessary for machine-to-machine communication but adherence to this convention will aid human intervention for cases where such intervention is necessary.

 7.4 Example of Server Organisation and File Naming Convention (Informative)
The example below shows two delivered Releases (both with two Resource files). The first Release has already been acknowledged by the Release Distributor, the second has not. The example does not use the Resource Type component of the file name. Both examples are "normal" deliveries (as opposed to priority ones).

N_A10301A0001887532A_20100517154800000/

 A10301A0001887532A.xml

 

resources/

  

A10301A0001887532A_T1.mp3

 

 

A10301A0001887532A_T2.jpg

N_A10301A00017EG98F_20100517155422000/

 A10301A00017EG98F.xml

 

resources/

  A10301A00017EG98F_T1_001.mp4

 

 

A10301A00017EG98F_T2_2.jpg

acknowledgements/

 ACK_N_20100517154800000_A10301A0001887532A.xml

8 SFTP Batch Profile

 8.1 Choreography
This clause defines the method how a Release Creator can provide Batches of metadata and Resource files to a Release Distributor via (i) an SFTP server that is hosted by the Release Creator, (ii) an SFTP server that is hosted by the Release Distributor, (iii) an SFTP server that is hosted by a third party or (iv) a hard disk that is populated by/on behalf of the Release Creator and then shipped to the Release Distributor. This specification does not define on whose hardware the files are being stored; this is for Release Creator and Release Distributor to agree.

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 10 of this standard. In exceptional circumstances, such as for support human intervention, it is permissible to use a zero-byte semaphore file to indicate the upload is complete. This semaphore has to be used instead of an XML manifest formatted in accordance with Clause 10. The use of such a semaphore file may trigger a flag on the recipient’s side, indicating the manual nature of the override. The message is also depicted below.

The structure of the NewReleaseMessages communicated in this profile shall follow the Release and Business Profiles agreed as appropriate for the communicated Release(s).

The FtpAcknowledgementMessage is defined in this standard; is also depicted in Clause 10.

The structure and file naming conventions for the FTP Release-by-Release Profile are defined in Clauses 8.3 and  8.4 of this standard.

This standard does not define when the Release Creator shall start or finish to upload the next NewReleaseMessage (incl. all Resource files). Equally, this standard does not define when the Release Distributor shall start or finish its download.

In addition to the exchanged shown in the diagram above, the recipient of the NewReleaseMessage may use the same message for subsequent status updates (e.g. when, after reporting FileOK after ingestion, closer inspection shows deficiencies not detected previously.

The recipient of the FtpAcknowledgementMessage may remove a FtpAcknowledgementMessage from the FTP server after an appropriate and mutually agreed period of time. The default period is one month.

 8.2 Batch Constraints
The maximum size of a Batch is not defined in this standard but shall be agreed by Release Creator and Release Distributor before using this Profile. It is not permitted to include the same Release more than once in a single Batch.

If the Release Creator wants to have several Batches “open” at the same time, it needs to ensure that no Release is contained in more than one Batch.

The maximum time a Batch may be kept “open” is a matter for Release Creator and Release Distributor 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 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.

The Release Creator shall make sure that for each of its Release Distributors the BatchId is unique.

 8.3 SFTP Server Organisation
Each Batch shall be placed into a separate folder of its own. The folder shall be named with a priority indicator followed by an underscore character and the BatchId. Each Release within that Batch shall be placed into a separate folder using the ReleaseId of the Release as its name. A NewReleaseMessage for each Release shall be placed into that folder; Resource files shall be placed into a subfolder called “resources/”.

The value for the priority indicator may be "P" to indicate all Releases in the batch are deemed to be a priority delivery, M if some of the Releases are deemed to be a priority delivery whereas others are not, and "N" to indicate the none of the Release is deemed to be a non-priority delivery. The meaning of priority in this context should be agreed by sender and recipient. Note that mixing non-priority and priority deliveries may cause problems, especially when no acknowledgements are used.

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

If possible, the ReleaseId used should be a GRid as defined in the GRid standard. However, if that is not possible, the Release Creator and Release Distributor shall mutually agree a different unique identifier.

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

 8.4 File Naming Convention
The file name of the ManifestMessage for each Batch shall be the string BatchComplete_ followed by the BatchId (as defined above) and the .xml file extension. The same file name applied to the zero-byte semaphore discussed in Clause 8.1.

The file name of the FtpAcknowledgementMessage for each Batch shall be the string ACK_  the date and time that the Batch is placed on the ftp server, followed by an underscore and the ReleaseId. The file shall have an .xml file extension.

The NewReleaseMessages shall be named using the same ErnMessageId as used for the enclosing folder with an .xml file extension.

To aid human intervention, each Resource file should be named as described in Clause 7Clause 7.3.2.

 8.5 Example of Server Organisation and File Naming Convention (informative)
The example below shows one delivered priority Batch with two Releases (both with two Resource files). The Batch is not yet acknowledged.

 

P_20100310130322000/

 A10301A0001887532A/
  A10301A0001887532A.xml

 

 

resources/

   A10301A0001887532A_T1_001.mp3

 

 

 

A10301A0001887532A_T2_001.jpg

 

A10301A00017EG98F/


 

  A10301A00017EG98F.xml

 

 

resources/

   

A10301A00017EG98F_T1_001.mp4

 

 

 

A10301A00017EG98F_T2_002.mp3

 

BatchComplete_20100310130322000.xml

acknowledgements/
 <empty>

9 Hard Disk Delivery

 9.1 Introduction
In order to support the delivery of large numbers of Releases, Release Creators sometimes deliver entire catalogues stored on a hard disk via courier.

The precise way in which such a hard disk delivery is integrated into the technical infrastructure between sender and recipient depends on the agreed profile for the on-going communication between the two parties.

 9.2 Hard disk deliveries as part of a Release-by-Release SFTP Profile
The hard disk shall be organised as defined in Clause 7 with the exception that no acknowledgements can be communicated via the hard disk.

Acknowledgements are to be communicated via the SFTP sever agreed between sender and recipient. The sender of the acknowledgement needs to create the same hierarchy for the acknowledged Release in the SFTP server as was found on the hard disk.

 9.3 Hard disk deliveries as part of a Batched SFTP Profile
The hard disk shall be organised as defined in Clause 8 with the exception that no acknowledgements can be communicated via the hard disk.

Acknowledgements are to be communicated via the SFTP sever agreed between sender and recipient. The sender of the acknowledgement needs to create the same hierarchy for the acknowledged Batch in the SFTP server as was found on the hard disk.

 9.4 Ingestions of Updates
If the sender of the Releases provide an update to a Release already ingested from the hard disk, the normal process for updated applies.

If the sender of the Releases provide an update to a Release not yet ingested from the hard disk, the recipient shall ingest, pet normal protocol, the update; should that update not provide any resource files, the recipient should look for these on the hard disk.

The sender shall not ingest the Release from the hard disk after having received an update via the normal on-going communication channel.

 

10 Message Definition

 10.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 10.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. Rules relating to the authority of business partners to unilaterally change the Message

 10.2 General Conformance Rules

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

12.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 B – 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.

12.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 by MessageSender and Message Recipient.

12.2.4 Schema Version Id

For messages defined directly herein the only valid value for this field is

ERN-C-SFTP/16

 10.3 Syntax and Semantics of Messages

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

Annexes

 Annex A (normative) Allowed-value Sets
Table 13 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.

Table 13 — Allowed-Value-Sets used in the Electronic Release Notification Message Suite Standard

The Table of AVSs is provided in a separate document. See the blue box here.


 Annex B (informative) Release Notes

 

B.1 Changes between Version 1.6.1 and 1.6

Version 1.6.1 fixes a bug with the file naming convention.

 B.2 Changes between Version 1.6 and 1.5

Version 1.6 splits the ERN Choreography into an SFTP variant (defined in this standard) and web service variant (defined elsewhere). The SFTP variant now also supports signalling priority deliveries on file-system level. It also removes the provision to communicate Release Deliveries using (insecure) FTP.

B.3 Changes between Versions 1.4 and 1.5

Version 1.5 introduced small changes to the file naming convention and aligns it with current practice.

B.4 Changes between Versions 1.3 and 1.4

Version 1.4 simplified the process of acknowledging the ingestion of a Release or Batch of Releases using the FTP profiles by providing a simplified acknowledgement message. It also added error codes and makes sending acknowledgements mandatory.

Note, version 1.4 changes the file name convention for acknowledgements to better support the newly introduced limited life-span of acknowledgements.

B.5 Changes between Versions 1.2 and 1.3

Version 1.3 supports hard disk deliveries and corrects the naming convention for the manifest file, indicating that the batch is complete from "Manifest_*" to "batch_complete_*".

B.6 Changes between Versions 1.1 and 1.2

Version 1.2 allows the InformationAboutDeliveredAndAvailableReleasesMessageCall (was: InformationAboutAvailableReleasesMessageCall) to be used by a ReleaseCreator as an audit tool. It also allows error messages be communicated to a web service caller and enables a Release Distributor to ask for the “next Release” without specifying what Release that should be.

Version 1.2 also adds a MessageActionType into the InformationAboutAvailableReleases­ReportMessage and to make the MessageType, in the same composite, optional.

In addition some clarifications were added and unnecessary clauses were removed.

B.7 Changes between Versions 1.0 and 1.1

A few changes have been made to increase the abilities for humans to intervene, when needed, into a feed. Other changes have been made to allow a more streamlined machine-to-machine communication. However, since DDEX is not aware of any implementation of the ECHO version 1.0 standard, the details of these changes are not listed herein.

 

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.