W3C

XMCL - the eXtensible Media Commerce Language

W3C Note 19 September 2002

This version:
http://www.w3.org/TR/2002/NOTE-xmcl-20020919/
Latest version:
http://www.w3.org/TR/xmcl/
Author:
Jeffrey Ayars, RealNetworks, Inc.

Copyright © 2002 RealNetworks, Inc. This document is available under the W3C Document License, see the W3C Intellectual Rights Notices and Disclaimers for additional information.

Abstract

This document specifies XMCL, the eXtensible Media Commerce Language. The language is an interchange format that describes usage rules that apply to multi-media content. It is designed to communicate these rules in an implementation independent manner for interchange between business systems and DRM implementations responsible for enforcing the rules described in the language.

Status of this document

This document is a submission to the World Wide Web Consortium from RealNetworks, Inc. for consideration as a foundation for work on a rights description language. (see Submission Request, W3C Staff Comment). This draft is not complete, where elements or attributes are not fully described, their intended use described as a placeholder. Items in red are editorial notes for the authors/contributors to consider while working on the document. They are not meant to be part of the specification.

This document is a Note made available by W3C for discussion only. This work does not imply endorsement by, or the consensus of the W3C membership, nor that W3C has, is, or will be allocating any resources to the issues addressed by the Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time. For a full list of all acknowledged Submissions, please see Acknowledged Submissions of W3C.

A list of current W3C technical documents can be found at the Technical Reports page.

Table of Contents

1 Introduction
1.1 Conformance conventions
2 XMCL Overview and Examples
2.1 Rental Example
2.2 Ownership Example
3 Processing Rules
4 Core XMCL Syntax
4.1 The <xmcl> element
4.2 The <clientInfo> element
4.2.1 The <param> element
4.3 The <license> element
4.3.1 The <contentInfo> element
4.3.1.1 The <contentID> element
4.3.1.2 The <ds:KeyInfo> element
4.3.1.3 The <key> element
4.3.1.4 The <validPeriod> element
4.3.2 The <usageRights> element
4.3.3 The <copyRights> element
4.3.4 The <transferRights> element
4.3.5 The Rights elements
4.3.5.1 The <useDuration> element
4.3.5.2 The <useCount> element
4.3.5.3 The <require> element
4.3.5.4 The <userInteraction> element
4.3.5.5 The <allowedUse> element
4.3.5.6 The <impRight> element
5 Extension Syntax
5.1 The <revocationList> element
5.1.1 The <revokedItem> element
5.1.2 The <auth> element
6 Definitions
Business system
Trusted system
License
7 References

Introduction

This document specifies the Syntax and Semantics of XMCL, an eXtensible Media Commerce Language. Digital media in a rights management system flows through a number of steps on its journey to a consumer's eyes and ears. The steps are: create, package, publish, distribute, license, and consume. At least a subset of these abstract steps is implemented by all rights management systems today. The service or business owner that manages one or more of these steps varies widely depending on the relationships negotiated for a specific piece of content. However, there is a natural break between the back-end systems for publishing and licensing on one side and the trusted system that packaged the content and enforces the business rules for the content on the other. This division is between the systems that describe the business rules for the content and the specific implementation that enforces those rules.

XML element structure diagram

XMCL is a "rights specification language", as defined by the Association of American Publishers [DRMEBOOKS]. The purpose of XMCL is for interchange of business rules to be applied to media between business systems (e.g. web store fronts, customer tracking and management) and trusted delivery and playback systems (e.g. a DRM implementation that will enforce the rights described in the XMCL document). Through the use of XMCL business systems are completely free of knowledge of specific trusted system implementations. This separation of the business systems and the trusted system allow businesses to support one or more trusted systems and provides the option of changing trusted systems as conditions change without changes to the business systems.

XMCL describes the minimum, self-complete set of business rules under which digital media is licensed for consumer use. These business rules support multiple business models including rental, subscription, ownership, and video on demand/pay-per-view. When a business system authorizes a customer transaction for digital media, it generates a XMCL document that is then acted upon and enforced by a specific trusted system. The generated XMCL document is submitted to the trusted system through the APIs of the trusted system (e.g. HTTP POST, RPC call, API call).

This document does not define interoperability end-to-end, but takes an important first step in that direction. As noted in the summary of the recent W3C Workshop on DRM, none of the standards efforts they evaluated "[deal] with what we think of as the essential first step for the Web: the simple expression and communication of IPR information and policies." [WWWDRM].

Conformance conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions[XSCHEMA-STRUCTURE] unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XMLNAMES] is described as "REQUIRED."

XMCL Overview and Examples

This section provides an overview and examples of XMCL for a few common use cases. This section is informative. Refer to Processing Rules (section 3) and Core XMCL Syntax (section 4) for the normative definition of the language. XMCL documents are intended to be the interchange that bridges between a back end business system and a specific trusted system.

XMCL's XML element structure

The clientInfo section will be specific to each enforcement system. It contains parameters that are required for the trusted system to generate the license (e.g. cryptographic keys, request or response authentication data, etc.). There will be one or more license sections, one for each license that should be granted. The license section describes the specific business rules that should be applied to a specific piece of content. XMCL supports multiple licenses in a single request, which would enable the licensing of some purchased content to include a promotional license to another piece of content. The auth section optional and contains authentication information so the receiver can validate the request is authentic if required. There are a number of business models that feed into the requirements for XMCL. They are rental, subscription, ownership, video on demand/pay per view, promotion, and corporate internal communications. Example XMCL documents for rental, subscription and ownership follows. In the examples, attributes and elements may be omitted, as the intent is simply to get a feel for the language, not provide a definition or guide for the language.

Rental Example

For the rental business model a small set of rules need to be specified that simply describe the rental period. The following is an example XMCL document describing a 24-hour rental license for the movie "First Blood". The rental period begins when the movie is first watched and must occur within a week of purchase. For this example, the XMCL document always follows a template with only information regarding the specific customer and date/time information modified.
  1. <xmcl>
  2.    <license>
  3.      <contentInfo>
  4.        <contentID type="GUID">
  5.            13AC7DE5-8028-42fe-95CE-0DC2221891C7
  6.        </contentID>
  7.        <ds:KeyInfo
  8.            xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  9.          <ds:KeyName>ContentKey</ds:KeyName>
  10.          <ds:KeyValue>
  11.            <key algorithm="urn:nist-gov:tripledes-ede-cbc">
  12.              3812A419C63BE771 AD9F61FEFA20CE63 3812A419C63BE771
  13.            </key>
  14.          </ds:KeyValue>
  15.        </ds:KeyInfo>
  16.        <rdf:RDF xmlns:rdf=
  17.            "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  18.            xmlns:dc="http://purl.org/dc/elements/1.1/">
  19.          <rdf:Description>
  20.            <dc:title>First Blood</dc:title>
  21.            <dc:subject>
  22.                movie, action, adventure
  23.            </dc:subject>
  24.          </rdf:Description>
  25.        </rdf:RDF>
  26.      </contentInfo>
  27.      <validPeriod start="2001614T184300"
  28.          end="2001621T184300"/>
  29.      <usageRights>
  30.        <useDuration length="24h" begin="firstUse"/>
  31.      </usageRights>
  32.    </license>
  33. </xmcl>
This XMCL document contains a single <license> element. The <contentID> element on line 4 defines the unique identifier for the content. The type attribute specifies that the id used is a GUID. The <ds:KeyInfo> element on line 7 specifies the symmetric key for decryption of the content. KeyInfo is borrowed from [XMLDSIG]. Lines 16-25 describe meta information that further defines the content using Dublin Core elements as defined in [DCMES-XML]. The <validPeriod> element on line 27 describes that the license is valid from June 14, 2001 at 18:43 to June 21, 2001 at 18:43. The useDuration element on line 30 says the content is licensed for 24 hours from first use.

2.2 Ownership Example

The following is an example XMCL document describing an ownership license for the song "Bang the Drum Slowly".
  1. <xmcl>
  2.    <license>
  3.      <contentInfo creatorId="Frank LeMedere"
  4.         licensorID="Audiotrax">
  5.        <contentID type="GUID">
  6.         13AC7DE5-2180-42fe-95CE-0D18028891C7
  7.        </contentID>
  8.        <ds:KeyInfo
  9.           xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  10.          <ds:KeyName>ContentKey</ds:KeyName>
  11.          <ds:KeyValue>
  12.            <key algorithm="urn:nist-gov:tripledes-ede-cbc">
  13.             3812A419C63BE771 AD9F61FEFA20CE63 3812A419C63BE771
  14.            </key>
  15.          </ds:KeyValue>
  16.        </ds:KeyInfo>
  17.        <rdf:RDF xmlns:rdf=
  18.           "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  19.           xmlns:dc="http://purl.org/dc/elements/1.1/">
  20.          <rdf:Description>
  21.            <dc:creator>Emmy Lou Harris</dc:creator>
  22.            <dc:title>
  23.              Bang The Drum Slowly
  24.            </dc:title>
  25.            <dc:date>2001</dc:date>
  26.          </rdf:Description>
  27.        </rdf:RDF>
  28.      </contentInfo>
  29.      <validPeriod start="2001614T184300" />
  30.      <usageRights>
  31.        <useDuration length="infinite"/>
  32.      </usageRights>
  33.    </license>
  34. </xmcl>
This XMCL document contains a single <license> element. The <contentID> element on line 5 defines the unique identifier for the content. The type attribute specifies that the id used is a GUID. The <ds:KeyInfo> element on line 8 specifies the symmetric key for decryption of the content. KeyInfo is borrowed from [XMLDSIG]. Lines 17-27 describe meta information that further defines the content using Dublin Core elements as defined in [DCMES-XML]. The <validPeriod> element on line 29 describes that the license is valid starting on June 14th, 2001 at 6:43 PM. The useDuration element on line 31 says the content is licensed for an unlimited duration from issue.

Processing Rules

This section is normative. An implementation MUST parse, understand, and enforce a license described using the core syntax. If an implementation cannot understand or enforce any rules described in the license section, it MUST return an error and fail to return a license. An implementation MUST support at least one <license> element per document. Support for multiple <license> elements is OPTIONAL. An implementation MUST support XML namespaces [XMLNAMES]. Namespace extensions that are not recognized MUST be ignored. If a license if valid without the namespace qualified elements, it MUST be considered to be understood.  If a license is not valid when qualified elements are ignored, an implementation MUST return an error and fail to return a license.

Core XMCL Syntax

The general structure of an XMCL document is described in the XMCL Overview (section 2). This section provides detailed syntax of the core XMCL features. Features described in this section are mandatory to implement unless otherwise indicated.  The XML Schema definitions used are from [XSCHEMA-STRUCTURE]

The <xmcl> element

The xmcl element is the outer structure element in the language. There MUST be only one xmcl element per document. It contains all of the licenses along with any trusted system specific information required to generate or enforce the license.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
children clientInfo license revocationList auth
source 
<xs:element name="xmcl">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="clientInfo" minOccurs="0"/>
      <xs:element ref="license" maxOccurs="unbounded"/>
      <xs:element ref="revocationList" minOccurs="0"/>
      <xs:element ref="auth" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

The <clientInfo> element

The clientInfo element contains any parameters that are needed by a specific trusted system to generate or enforce the license(s) described by the <license> elements. There are no defined attributes for this element at this time. Base XML attributes defined in [XML] SHOULD be allowed. The clientInfo element contains one or more <param> elements.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
children param
used by
element xmcl
source 
<xs:element name="clientInfo">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="param" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

The <param> element

The param element is borrowed from [XHTML] XHTML 1.0 and is used to define name value pairs to convey implement specific parameters to the trusted system.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
used by
element clientInfo
attributes
Name  Type  Use  Default  Fixed  
id  xs:ID        
name  xs:string        
value  xs:string        
valuetype  xs:NMTOKEN        
type  xs:string        
source 
<xs:element name="param">
  <xs:complexType>
    <xs:attribute name="id" type="xs:ID"/>
    <xs:attribute name="name" type="xs:string"/>
    <xs:attribute name="value" type="xs:string"/>
    <xs:attribute name="valuetype" type="xs:NMTOKEN"/>
    <xs:attribute name="type" type="xs:string"/>
  </xs:complexType>
</xs:element>

The <license> element

The license element contains the business rules that the trusted system should use to generate the implementation specific license.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
children contentInfo validPeriod usageRights copyRights transferRights
used by
element xmcl
attributes
Name  Type  Use  Default  Fixed  
numCopies  xs:decimal        
allowTransfer  xs:boolean        
source 
<xs:element name="license">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="contentInfo"/>
      <xs:element ref="validPeriod"/>
      <xs:element ref="usageRights"/>
      <xs:element ref="copyRights" minOccurs="0"/>
      <xs:element ref="transferRights" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="numCopies" type="xs:decimal"/>
    <xs:attribute name="allowTransfer" type="xs:boolean"/>
  </xs:complexType>
</xs:element>

The <contentInfo> element

The contentInfo element identifies and contains information specific to the piece of content being licensed.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
children contentID key
used by
element license
attributes
Name  Type  Use  Default  Fixed  
creatorID  xs:string  required      
licensorID  xs:string  required      
source 
<xs:element name="contentInfo">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="contentID" minOccurs="0"/>
      <xs:element ref="key" minOccurs="0"/>
      <xs:any namespace="dublin core meta element" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="creatorID" type="xs:string" use="required"/>
    <xs:attribute name="licensorID" type="xs:string" use="required"/>
  </xs:complexType>
</xs:element>
The <contentID> element
Contains an identifier for the content. It contains no other elements. The type attribute specifies the type of data contained by the element.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type xs:string
used by
element contentInfo
source 
<xs:element name="contentID" type="xs:string"/>
The <ds:KeyInfo> element
This element is taken from XML Digital Signatures [XMLDSIG] and is used to communicate cryptographic keys from system to system. See XML Digital Signatures [XMLDSIG] for further explanation of the elements semantics.
XML element structure diagram
The <key> element
This spec extends the <ds:KeyValue> [XMLDSIG] element with the key element. The key element opens the algorithm list by providing a container for the key data and the algorithm attribute to identify the algorithm. The algorithm attribute uses the algorithm URI's from XML Encryption [ALGORITHMS].
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type xs:string
used by
element contentInfo
source 
<xs:element name="key" type="xs:string"/>
The <validPeriod> element
The validPeriod element describes the dates during which the license is valid. It takes a start and end attribute. The start and end attributes define the calendar dates and times in the format described in [XSCHEMA-DATATYPES]. The enforcement system should only honor the rights expressed in the license after the date-time specified with the start attribute and until the date specified in the end attribute.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
used by
element license
attributes
Name  Type  Use  Default  Fixed  
start  xs:dateTime  required      
end  xs:dateTime  required      
source 
<xs:element name="validPeriod">
  <xs:complexType>
    <xs:attribute name="start" type="xs:dateTime" use="required"/>
    <xs:attribute name="end" type="xs:dateTime" use="required"/>
  </xs:complexType>
</xs:element>

The <usageRights> element

The usageRights element describes the rights that are granted in the license.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type rights
children useDuration useCount userInteraction require allowedUse impRight
used by
element license
source 
<xs:element name="usageRights" type="rights"/>

The <copyRights> element

The copyRights element describes the rights that are granted in the copy license. If the element is empty, all the rights described in the <usageRights> are copied.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type rights
children useDuration useCount userInteraction require allowedUse impRight
used by
element license
source 
<xs:element name="copyRights" type="rights"/>

The <transferRights> element

The transferRights element describes the rights that are granted in the transfer license. If the element is empty, all the rights described in the <usageRights> are transferred.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type rights
children useDuration useCount userInteraction require allowedUse impRight
used by
element license
source 
<xs:element name="transferRights" type="rights"/>

The Rights elements

The following elements are used to specify rights in the <usageRights>, <copyRights>, and <transferRights> elements. They describe the interoperable right set as well as a generic right element, <impRight>, that can be used to describe rights specific to a particular implementation.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
children useDuration useCount userInteraction require allowedUse impRight
used by
elements copyRights transferRights usageRights
source 
<xs:complexType name="rights">
  <xs:all>
    <xs:element ref="useDuration" minOccurs="0"/>
    <xs:element ref="useCount" minOccurs="0"/>
    <xs:element ref="userInteraction" minOccurs="0"/>
    <xs:element ref="require" minOccurs="0"/>
    <xs:element ref="allowedUse" minOccurs="0"/>
    <xs:element ref="impRight" minOccurs="0"/>
  </xs:all>
</xs:complexType>
The <useDuration> element
The useDuration element specifies a length of time the content can be used after a specific event. The begin attribute specifies when the duration should begin. Its values are "issue" and "firstUse". The "issue" value specifies the duration starts at the issue of the license. The "firstUse" value specifies the duration starts when the content is first used. The length attribute specifies the length of time.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
used by
complexType rights
attributes
Name  Type  Use  Default  Fixed  
begin  xs:NMTOKEN        
length  xs:duration  required      
source 
<xs:element name="useDuration">
  <xs:complexType>
    <xs:attribute name="begin" type="xs:NMTOKEN"/>
    <xs:attribute name="length" type="xs:duration" use="required"/>
  </xs:complexType>
</xs:element>
The <useCount> element
The useCount element specifies the number of times the content can be used. It takes the count attribute and the threshold attribute.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
used by
complexType rights
attributes
Name  Type  Use  Default  Fixed  
count  xs:integer  required      
threshold  xs:duration  optional      
source 
<xs:element name="useCount">
  <xs:complexType>
    <xs:attribute name="count" type="xs:integer" use="required"/>
    <xs:attribute name="threshold" type="xs:duration" use="optional"/>
  </xs:complexType>
</xs:element>
The <require> element
The intent of the require element is to describe conditions that the trusted system are to require for playback. It should include things like employment water marking technology, use of a specific decompressor implementation, etc.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type xs:string
used by
complexType rights
source 
<xs:element name="require" type="xs:string"/>
The <userInteraction> element
The intent of the userInteraction element is to describe something that requires user interaction before use of the licensed content will be allowed. This includes things like accepting a "click-wrap" license agreement at each playback.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type xs:string
used by
complexType rights
source 
<xs:element name="userInteraction" type="xs:string"/>
The <allowedUse> element
The intent of the allowedUse element is to describe things like the content can only be included as a whole vs. included in a larger work.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type xs:string
used by
complexType rights
source 
<xs:element name="allowedUse" type="xs:string"/>
The <impRight> element
The impRight element is a generic extension mechanism that allows inclusion of implementation specific rights in a license. The implementation is identified by the implementationID attribute as a URI [URI].

Ed Note: Should pull in <switch> element and systemRequired element from SMIL 2.0 for this section so a XMCL doc could describe implementation specific rights for multiple implementations and the parsing application could correctly pick the right one.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
children param
used by
complexType rights
attributes
Name  Type  Use  Default  Fixed  
implementationID  xs:NMTOKEN  required      
source 
<xs:element name="impRight">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="param" maxOccurs="unbounded">
        <xs:complexType>
          <xs:attribute name="id" type="xs:ID"/>
          <xs:attribute name="name" type="xs:string"/>
          <xs:attribute name="value" type="xs:string"/>
          <xs:attribute name="valuetype" type="xs:NMTOKEN"/>
          <xs:attribute name="type" type="xs:string"/>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
    <xs:attribute name="implementationID" type="xs:NMTOKEN" use="required"/>
  </xs:complexType>
</xs:element>

Extension Syntax

The elements and attributes listed in this section are not considered part of the core XMCL language. Implementations SHOULD support these extensions.

The <revocationList> element

The purpose of the revocationList element is to provide a standard way to describe revocation certificates. Revocation is a key feature of DRM technology and the opportunity to standardize here seems the same as business rules. It MUST contain one or more <revokedItem> elements.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
children revokedItem
used by
element xmcl
source 
<xs:element name="revocationList">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="revokedItem" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

The <revokedItem> element

The revokedItem element is a non-empty element that describes an item in the trusted system to be revoked. The type attribute describes the type of the data contained in the revokedItem element.
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
type xs:string
used by
element revocationList
source 
<xs:element name="revokedItem" type="xs:string"/>

The <auth> element

The auth element is a is a place holder for digital signatures that can be used to authenticate the party that created the XMCL document
diagram XML element structure diagram
namespace http://namespaces.xmcl.org/xmcl
used by
element xmcl
source 
<xs:element name="auth"/>

Definitions

Business system

A business system is a system comprised of one or more business solution packages like database software, user management software, content/asset management software, and e-commerce software combined into a solution like a web storefront that provides downloadable media purchases.

Trusted system

A trusted system is a digital rights management system implementation that is capable of enforcing the rules described in an XMCL document during end user use of content. It includes the software that accepts requests for licenses, issues the licenses and the client software run by the end user that enforces the license.

License

A license is a set of usage rules that define how an end user is allowed to use a piece of content. It is specific to a piece of content and a specific end user.

References

[DCE11] "Dublin Core Metadata Element Set", Dublin Core Metadata Initiative, July, 1999. Available at http://purl.org/dc/elements/1.1/

[DCUSAGE] "Using Dublin Core", Diane Hillmann, April 2001. Available at http://dublincore.org/documents/usageguide/

[DCMES-XML] "An XML Encoding of Simple Dublin Core Metadata", D. Beckett, E. Miller, D Brickly, December 2000. Available at http://dublincore.org/documents/2000/11/dcmes-xml/

[DRMEBOOKS] "Digital Rights Management for Ebooks: Publisher Requirements Version 1.0" Association of American Publishers, Inc, November, 2000.http://www.publishers.org/home/drm.pdf (see http://www.publishers.org/home/press/ebookpr.htm for more info)

[MM] "MusicBrainz Metadata Initiative", a portable and flexible means of storing and exchanging metadata related to digital audio and video tracks. Work in progress. http://www.musicbrainz.org/MM/

[SMIL20] "Synchronized Multimedia Integration Language (SMIL 2.0)". W3C Proposed Recommendation, work in progress. Available at http://www.w3.org/TR/smil20/

[URI] "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax" T. Berners-Lee, R. Fielding, L. Masinter, August 1998. http://www.ietf.org/rfc/rfc2396.txt

[WWWDRM] "W3C Workshop on Digital Rights Management for the Web: Workshop Report" J. Erickson, R. Iannella, R. Wenning, January, 2001. Workshop Report at http://www.w3.org/2000/12/drm-ws/workshop-report.html

[XML] "Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10 February 1998. Latest version available at: http://www.w3.org/TR/REC-xml

[XMLDSIG] "RFC 3075: XML-Signature Syntax and Processing" (XML Digital Signatures) D. Eastlake, J. Reagle, D. Solo, March 2001. Available at http://www.w3.org/TR/xmldsig-core/

[XMLNAMES] "Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14 January 1999. XML namespaces provide a simple method for qualifying names used in XML documents by associating them with namespaces identified by URI. Latest version available at: http://www.w3.org/TR/REC-xml-names

[XSCHEMA-STRUCTURE] "XML Schema, XML Schema Part 1: Structures". W3C Recommendation 2 May 2001. Available at http://www.w3.org/TR/xmlschema-1/

[XSCHEMA-DATATYPES] "XML Schema Part 2: Datatypes", Paul V. Biron and Ashok Malhotra, eds., W3C, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

[ ALGORITHMS] "XML Encryption Syntax and Processing: 6.1Algorithm Identifiers and Requirements" Available at http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html#_Toc501424263

[XHTML] "The Extensible HyperText Markup Language: A Reformulation of HTML 4.0 in XML 1.0". W3C Recommendation 26 January 2000,
Available at http://www.w3.org/TR/xhtml1/

[KEYWORDS] "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
http://www.ietf.org/rfc/rfc2119.txt

Valid HTML 4.0!