eXtensible rights Markup Language (XrML) Standard Extension 2.1 Specification

20 May 2002

NOTE: To enable interactive browsing of XML, this specification uses an HTML version that leverages the XML access functionality provided by the W3C XPath recommendation. For this reason, you need to view these HTML documents with a browser that supports that recommendation (for example, Internet Explorer Version 6.0).

Copyright © 2001-2002 ContentGuard Holdings, Inc. All rights reserved. "ContentGuard" is a registered trademark and "XrML", "eXtensible rights Markup Language", the XrML logo, and the ContentGuard logo are trademarks of ContentGuard Holdings, Inc. All other trademarks are properties of their respective owners.


XrML 2.1 Specification Terms of Use

READ THESE TERMS OF USE ("AGREEMENT") CAREFULLY BEFORE USING THE XrML 2.1 SPECIFICATION ("SPECIFICATION"). ATTEMPTING TO USE ANY PART OF THE SPECIFICATION WILL INDICATE THAT YOU HAVE READ, UNDERSTOOD, AND ACCEPTED THESE TERMS. DO NOT PROCEED IN ANY SUCH MANNER UNLESS YOU ARE ABLE AND WILLING TO ENTER INTO AND COMPLY WITH THIS AGREEMENT. CONTENTGUARD STRONGLY RECOMMENDS THAT YOU KEEP A COPY OF THIS AGREEMENT IN A SAFE PLACE FOR FUTURE REFERENCE. IF YOU DO NOT AGREE TO THESE TERMS, THEN DO NOT USE OR COPY THE SPECIFICATION AND IMMEDIATELY DESTROY ANY COPY OF THE SPECIFICATION YOU MAY HAVE OBTAINED.

  1. WARRANTY DISCLAIMER. THE XrML SPECIFICATION IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED REGARDING OR RELATING TO THE SPECIFICATION INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  2. LIMITATION OF LIABILITY. CONTENTGUARD SHALL NOT BE LIABLE FOR ANY DAMAGES, DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES (INCLUDING, WITHOUT LIMITATION, LOST PROFITS BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR OTHER INFORMATION OR OTHER LOSS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THIS AGREEMENT, THE USE OR DISTRIBUTION OF THE SPECIFICATIONS OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. CONTENTGUARD SHALL NOT BE LIABLE FOR ANY CLAIM PERTAINING TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN THE SPECIFICATIONS. IN THIS PARAGRAPH "CONTENTGUARD" INCLUDES ITS SUBSIDIARIES, PARENTS, EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, SUBCONTRACTORS, SERVICE PROVIDERS AND SUPPLIERS.
  3. Rights. No rights or licenses are granted expressly, by implication, estoppel or otherwise, to any patent rights, trademarks, trade secrets or other rights in any jurisdiction other than those expressly set forth in this Agreement.
  4. Miscellaneous Provisions. In your use or distribution of the Specification you agree to comply strictly with all applicable import and export laws and regulations of the United States and other countries. The laws of the State of Maryland and the intellectual property laws of the United States shall govern this Agreement.

Abstract

This specification defines the eXtensible rights Markup Language (XrML) Standard Extension, a set of commonly useful extensions to the XrML Core.

Status of this Document

Feedback and suggestions are welcome. Please report errors and provide comments on this document to the current editor at http://www.xrml.org/xrml_comments.asp.

Table of Contents

Your browser does not support automatic table of contents.

Introduction

Scope

This document builds upon the XrML Core 2.1 Specification. It defines a set of concepts that are generally and broadly useful and applicable to XrML2 usage scenarios, but which aren't necessarily at the heart of XrML2 semantics.

These concepts are broadly classified, according to the purpose that they serve, into conditions, payment notions, properties, and revocation extensions.

Keyword Conventions

This document follows the same keyword conventions as the XrML Core 2.1 Specification.

Schema Conventions

This document follows the same schema conventions as the XrML Core 2.1 Specification.

Condition Extensions

The standard extension schema defines several extensions of the type Condition. Of these, six extensions require a notion of state. To facilitate the definition of these extensions, a type StatefulCondition is defined as well. Condition extensions are constructed either by extending the type StatefulCondition or by directly extending the type Condition. What it means for a Condition extension to be satisfied is left to its description.

StatefulCondition

Some Conditions may be tied to a notion of state. For example, the number of times some content may be rendered can be bounded by some value. To cover such usages, standard extension defines a type called StatefulCondition. The type is an extension of the type Condition defined in the core. It includes a child element serviceReference, which indicates a service to be used to manage state. The details of this interaction is necessarily service-specific and so is not discussed here.

Schema representation of StatefulCondition

			

StateReferenceValuePattern

A pattern that identifies a set of ServiceReferences using pattern matching by dereferencing their values.

Schema representation of StateReferenceValuePattern

			

A StateReferenceValuePattern p matches a ServiceReference if and only if it can be determined that the present state of the service can be represented by the children of p. The means for determining this is necessarily service-specific and so is not discussed here.

The element stateReferenceValuePattern is typically used with the obtain element. When the Right to obtain a grant with a StatefulCondition is issued, then (to give the user exercising the obtain Right an idea about the initial state a certain serviceReference will happen to have) a stateReferenceValuePattern is created to make such an indication. This ensures that only serviceReferences in the proper state will appear in the obtained grant.

The ExerciseLimit Condition

Indicates a limit on the number of times that certain exercises may occur.

Schema representation of ExerciseLimit

			

An ExerciseLimit is satisfied if the current exercise is one of n allowed exercises, where these allowed exercises (and hence the number n) are managed by the specified serviceReference.

The SeekApproval Condition

Indicates that the specified service must give its approval for this Condition to be satisfied.

Schema representation of SeekApproval

			

A SeekApproval is satisfied if the specified serviceReference allows it to be.

The TrackReport Condition

Indicates that exercises must be tracked with a designated tracking service.

Schema representation of TrackReport

			

A TrackReport c is satisfied while either

The TrackQuery Condition

Represents a Condition based on some stateful integral value.

Schema representation of TrackQuery

			

A TrackQuery is satisfied if the stateful integral value managed by the specified serviceReference is within the range as specified by the two child elements notMoreThan and notLessThan.

TrackQuery is commonly used to predicate the possibility of one exercise on the occurrence (or non-occurrence) of other exercises. In particular, a trackReport applied to one exercise might cause the value of a trackQuery applied to another exercise to increase by one, thus possibly changing the satisfaction of the trackQuery.

The ValidityIntervalFloating Condition

Represents an interval of allowed exercising that begins with the first exercise.

Schema representation of ValidityIntervalFloating

			

A ValidityIntervalFloating is satisfied during the interval of allowed exercising, where that interval (and hence both its start and duration) are managed by the specified serviceReference.

Other Forms of Validity Intervals

A ValidityIntervalFloating Condition is useful to express floating intervals that become fixed on first use. Often times (either for business model reasons or to minimize the amount of state keeping done by a compact device) it is also useful to be able to express floating intervals that get fixed during some License issuance step. For this reason, the standard extension defines two types for use in conjunction with ValidityInterval (from the core) to accomplish this goal. The ValidityIntervalDurationPattern pattern and ValidityIntervalStartsNow Condition are useful in this respect when placed on a Grant to Issue.

The ValidityIntervalDurationPattern Pattern
Schema representation of ValidityIntervalDurationPattern

			

A ValidityInterval v matches a ValidityIntervalDurationPattern d if the duration of time represented by v is equal to d/duration.

The ValidityIntervalStartsNow Condition
Schema representation of ValidityIntervalStartsNow

			

A ValidityIntervalStartsNow Condition c is said to be satisfied at time t if all of the following hold:

The ValidityTimeMetered Condition

Represents a constraint on the cumulative exercise time over all exercises.

Schema representation of ValidityTimeMetered

			

Unlike ValidityIntervalFloating, ValidityTimeMetered deals with a length of time that is not necessarily contiguous. A ValidityTimeMetered is satisfied at time t if t lies within the intervals of time that make up the cumulative time duration, where those intervals are managed by the specified serviceReference. If the quantum child of a ValidityTimeMetered is specified, it specifies the minimum length that one can expect each such interval to have.

The ValidityTimePeriodic Condition

Indicates a validity time window that recurs periodically. For example, this condition can be used to express time windows such as "every weekend" or "the second week of every month".

Schema representation of ValidityTimePeriodic

			

ValidityTimePeriodic/start

A locally defined element of type xsd:dateTime. Indicates the start of the time, typically date, from which the periods designated in this right become meaningful.

ValidityTimePeriodic/period

A locally defined element of type xsd:duration. This indicates the frequency with which the exercise time window recurs.

ValidityTimePeriodic/phase

A locally defined element of type xsd:duration. This is used to indicate a period of latency before beginning each time window. When this value is positive then it directly specifies the duration of latency. When this value is negative, then the duration of latency is equal to the length of period minus the absolute value specified herein.

ValidityTimePeriodic/duration

A locally defined element of type xsd:duration. This indicates the actual length of the time window.

ValidityTimePeriodic/periodCount

A locally defined element of type xsd:integer. Indicates a bound on the number of time windows. This element is optional.

Satisfaction of the ValidityTimePeriodic Condition

Suppose c is a ValidityTimePeriodic Condition and let

then c is satisfied at time t if s + i*p + h <= t <= s + i*p + h + d for some i satisfying all of the following:

The Fee Condition

Indicates that there is a fee for the exercise.

Schema representation of Fee

			

Fee/paymentAbstract

This element of type paymentAbstract is abstract. It is meant to be substitutable. For more details and examples of extensions see paymentAbstract.

Fee/min

This locally defined optional element contains a paymentAbstract element. It specifies the minimum amount due. If the total amount paid is less than the value of this element, a new payment in the amount of the difference is due.

Fee/max

This locally defined optional element contains a paymentAbstract element. It specifies the maximum amount due. If the total amount paid is greater than the value of this element, a new credit in the amount of the difference is due. If the total amount paid is equal to the value of this element all other payments resulting from this Fee are void until the value of max increases.

Fee/to

This locally defined element is of type AccountPayable. It indicates the party to whom, and the means by which, payment is to be made. To allow for the rare cases where this is discovered from context, this element is left optional.

AccountPayable

AccountPayable is used to identify a party to whom one can transfer a sum of money, along with an identification of the means by which such a transfer is to take place. While there are undoubtedly many ways this can be done, two ways are explicitly defined. The type AccountPayable is defined as a choice between three options. The first, a paymentService, identifies the party to whom the payment is made. The second option, aba, identifies a bank in the US banking system. As a provision to support other forms of banking mechanisms, an option is made for specifying other banking means as well. This is realized by the xsd:any particle.

Schema representation of AccountPayable

			
AccountPayable/paymentService

The locally defined element paymentService contains a serviceReference. This identifies the party to whom the payment is to be made, and the interface to the service indicates the necessary payment mechanism.

AccountPayable/aba

The locally defined element identifies an account within a US banking institution by means of conventions established by the American Banking Association. It defines two child elements, institution and account. The banking institution is identified by its nine-digit banking routing number using the institution. The account within that institution is identified with account.

Using the fee condition

A Grant can predicate an exercise on a Fee. Typically Fees involve a payment and a designation of the party the payment is made to. Options about what form the payment should take (such as periodic or one-time or usage-based or metered) are reflected by the paymentAbstract element. A child element to of type AccountPayable is used to characterize both the payment mechanism and the payee.

There are two other optional elements. The optional min price specification indicates the minimum price to be paid if the right is exercised at all. The optional max price specification refers to the maximum price to be paid. When both max and min price specifications are given, the max price specification dominates.

Suppose that the Fees in paymentAbstract, min, and max independently amount to p, min, and max respectively due for the exercise as defined by their respective paymentAbstract extensions. Then, let x be

Then the Fee Condition is satisfied if and only if the amount x is paid to the entity identified by to for this purpose.

Not all forms of paymentAbstract extensions are directly comparable. For the Fee Condition to be sensibly evaluated, it is necessary that the extensions of the paymentAbstract elements in paymentAbstract, min, and max are comparable. In the standard extension, the paymentAbstract extensions either contain serviceReferences or they do not. Those that do are considered stateful. Stateful paymentAbstract extensions are not comparable with stateless ones, so it is required that the paymentAbstract extensions in paymentAbstract, min, and max are either all stateful or all stateless. The corresponding Fee Conditions are respectively termed as stateful and stateless.

The Territory Condition

Indicates a constraint on the geographic or virtual space where the exercised may occur.

Schema representation of Territory

			

Territory/location

This element defines inline the optional elements region, country, state, city, postalCode and street that designate a physical location.

Territory/location/region

This element designates an ISO 3166 country subdivision.

Territory/location/country

This element designates an ISO 3166 country.

Territory/location/state

This element is a two-letter code for US states.

Territory/location/city

This element designates a city.

Territory/location/postalCode

This element designates a postal code (e.g. a zip code).

Territory/location/street

This element designates a street.

Territory/domain

This element defines inline an element uri to designate a digital location.

Territory/domain/uri

This element, has type xsd:anyUri and can be any URI that designates a digital location.

Satisfaction of the Territory Condition

Since it may be desirable to have an exercise occur in more than one location, physical or digital, the content model for Territory allows for an unbounded number of children.

A Territory is satisfied if the exercise can be shown to be occurring in at least one of the locations or domains.

PaymentAbstract and its Extensions

PaymentAbstract

The notion of payment is abstracted in the Standard Extension. The element paymentAbstract has type PaymentAbstract. Both are conceptually abstract.

In place of PaymentAbstract, more concrete forms of payment (PaymentFlat, BestPriceUnder, CallForPrice, Markup, etc.) are to be used. The standard extension defines seven different kinds of payments. Each of these defines its own notion of when a payment has been made that works toward a Fee Condition being satisfied, as described in the section on Fee.

Schema representation of PaymentAbstract

			

Cash

An amount of money in a designated currency (using ISO 4217).

Schema representation of Cash

			

PaymentFlat

Specifies a payment due upon exercising. The contained serviceReference is used to determine if the fee has already been paid and to keep record of payment. The contained rate specifies the Cash value of the payment to be made.

Schema representation of PaymentFlat

			

PaymentMetered

Specifies a payment due for each time interval during which an exercise occurs. The contained rate and per elements together specify the charge per period. The contained by element indicates the quantum by which time is measured for the computation of the amount. The contained phase element is used for rounding purposes; it indicates what portion of time may elapse before somone is billed for the whole duration defined with by.

Schema representation of PaymentMetered

			

The element phase is used for rounding the units of time that are smaller than the duration described by the by element: a value of zero would have the effect of rounding up while a value equal to the value of by would have the effect of rounding down.

Formally, after normalilzing all of the duration values to seconds, suppose the rate is r, per in seconds is p, by in seconds is b, and phase in seconds is h. Then, if the interval of exercise of the right is t seconds, then the payment due is given by the expression r * (p/b) * ( floor( t/b ) + round ) where round is 1 if t%b is greater than h and is 0 otherwise.

PaymentPerInterval

Specifies a payment due for each time interval during which the ability to exercise is desired. The enclosed serviceReference is used to keep track of the time through which payment has been made. The contained rate and per elements together specify the charge per period.

Schema representation of PaymentPerInterval

			

PaymentPerUse

Specifies a payment due each time a right is exercised. The contained rate and initialNumberOfUses elements together specify the charge per package of uses. If initialNumberOfUses is absent, it defaults to 1. The serviceReference is used to keep track of the number of prepaid uses remaining.

Schema representation of PaymentPerUse

			

BestPriceUnder

Specifies the maximum price that ultimately must be paid without specifying the ultimate price exactly. The ultimate price is determined through a later, unspecified settlement mechanism. While max overrides min if max is less than min, min overrides BestPriceUnder if BestPriceUnder is less than min. If an implementation cannot determine the ultimate price exactly, it is free to voluntarily take the payment contained herein as the ultimate price.

Schema representation of BestPriceUnder

			

CallForPrice

Identifies an entity with whom a price must be negotiated before exercising. Any one of the specified serviceReferences can be used to negotiate a price. Unlike BestPriceUnder, price determination is required for CallForPrice.

Schema representation of CallForPrice

			

Markup

Specifies a fee due each time some other fees are due. The rate element indicates the fractional rate at which markup is calculated.

Schema representation of Markup

			

Let m be a Markup. Then m requires the payment of any m/fees and m/feeForResources which may be present therein. In addition, for each such payment, an additional payment equal to the product of that payment and the value m/rate is due.

The presence of a feeForResource implies a context in which multiple resources are being used simultaneously. The total price for using the specified m/feeForResource/resource t is calculated (and such amount is paid, as defined by any Licenses for that t). The price is then marked up by the m/rate, and the markup is paid as specified by the containing Fee element. If t is not used in conjunction with this exercise, then m is not fulfilled and the containing Fee is not satisfied.

Name Extensions

Name

A property indicating a name from some name space.

Schema representation of Name

			

Name is an extension of the type PropertyAbstract, and, as such, can be used along with the PossessProperty Right to associate a Name with a Principal. (This is useful for modeling the X.509 certificate-like binding of names to principals). Such associations allow (other) Grants to be made to, colloquially speaking, Principals described by their Names.

Both the element name and type Name are conceptually abstract.

EmailName

An Internet email address (per rfc822/rfc2822) associated with the entity.

Schema representation of EmailName

			

DnsName

A name in the DNS name space, with trailing period omitted. For example, "xyz.com"

Schema representation of DnsName

			

CommonName

A name by which an entity is colloquially known. Intended to be used as the CN name part from X400.

Schema representation of CommonName

			

X509SubjectName

The subject name of some X509 certificate associated with the entity. Intended to address legacy interoperability issues involving X509 certificates.

Schema representation of X509SubjectName

			

X509SubjectNamePattern

A pattern that identifies a set of X509 subject names using pattern matching.

Schema representation of X509SubjectNamePattern

			

X509SubjectNamePattern is not a derivation of the type Name. Rather, it is a derivation of the type ResourcePatternAbstract. It matches any X509SubjectName for which it is the root of the X509SubjectName tree. This element can be used to enforce constraints similar to the X509 specification.

Revocation Extensions

Revocable

Identifies a dsig:SignatureValue that can be Revoked. The dsig:SignatureValue can be identified literally or by reference. In the latter case, the result of dereferencing the reference must be of type dsig:SignatureType; the dsig:SignatureValue able to be Revoked is the one dsig:SignatureValue therein.

Schema representation of Revocable

			

A Revocable is a Resource for use with the Revoke Right.

XrML Standard Extension Schema

xrml21-xrml2sx.xsd (normative)

References

eXtensible rights Markup Language (XrML) Core 2.1 Specification.
ContentGuard, Inc. May 20, 2002.
http://www.xrml.org/.
ISO 3166: Codes for the representation of names of countries and their subdivisions.
http://www.iso.org/.
ISO 4217: Codes for the representation of currencies and funds.
http://www.iso.org/.