CARVIEW |
XMCL - the eXtensible Media Commerce Language
W3C Note 19 September 2002
- This version:
- https://www.w3.org/TR/2002/NOTE-xmcl-20020919/
- Latest version:
- https://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 Introduction1.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.

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.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.- <xmcl>
- <license>
- <contentInfo>
- <contentID type="GUID">
- 13AC7DE5-8028-42fe-95CE-0DC2221891C7
- </contentID>
- <ds:KeyInfo
- xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
- <ds:KeyName>ContentKey</ds:KeyName>
- <ds:KeyValue>
- <key algorithm="urn:nist-gov:tripledes-ede-cbc">
- 3812A419C63BE771 AD9F61FEFA20CE63 3812A419C63BE771
- </key>
- </ds:KeyValue>
- </ds:KeyInfo>
- <rdf:RDF xmlns:rdf=
- "https://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:dc="https://purl.org/dc/elements/1.1/">
- <rdf:Description>
- <dc:title>First Blood</dc:title>
- <dc:subject>
- movie, action, adventure
- </dc:subject>
- </rdf:Description>
- </rdf:RDF>
- </contentInfo>
- <validPeriod start="2001614T184300"
- end="2001621T184300"/>
- <usageRights>
- <useDuration length="24h" begin="firstUse"/>
- </usageRights>
- </license>
- </xmcl>
2.2 Ownership Example
The following is an example XMCL document describing an ownership license for the song "Bang the Drum Slowly".- <xmcl>
- <license>
- <contentInfo creatorId="Frank LeMedere"
- licensorID="Audiotrax">
- <contentID type="GUID">
- 13AC7DE5-2180-42fe-95CE-0D18028891C7
- </contentID>
- <ds:KeyInfo
- xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
- <ds:KeyName>ContentKey</ds:KeyName>
- <ds:KeyValue>
- <key algorithm="urn:nist-gov:tripledes-ede-cbc">
- 3812A419C63BE771 AD9F61FEFA20CE63 3812A419C63BE771
- </key>
- </ds:KeyValue>
- </ds:KeyInfo>
- <rdf:RDF xmlns:rdf=
- "https://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:dc="https://purl.org/dc/elements/1.1/">
- <rdf:Description>
- <dc:creator>Emmy Lou Harris</dc:creator>
- <dc:title>
- Bang The Drum Slowly
- </dc:title>
- <dc:date>2001</dc:date>
- </rdf:Description>
- </rdf:RDF>
- </contentInfo>
- <validPeriod start="2001614T184300" />
- <usageRights>
- <useDuration length="infinite"/>
- </usageRights>
- </license>
- </xmcl>
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 | ![]() |
namespace | https://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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
children | param | ||
used by |
|
||
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 | ![]() |
||||||||||||||||||||||||||||||
namespace | https://namespaces.xmcl.org/xmcl | ||||||||||||||||||||||||||||||
used by |
|
||||||||||||||||||||||||||||||
attributes |
|
||||||||||||||||||||||||||||||
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 | ![]() |
|||||||||||||||
namespace | https://namespaces.xmcl.org/xmcl | |||||||||||||||
children | contentInfo validPeriod usageRights copyRights transferRights | |||||||||||||||
used by |
|
|||||||||||||||
attributes |
|
|||||||||||||||
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 | ![]() |
|||||||||||||||
namespace | https://namespaces.xmcl.org/xmcl | |||||||||||||||
children | contentID key | |||||||||||||||
used by |
|
|||||||||||||||
attributes |
|
|||||||||||||||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | xs:string | ||
used by |
|
||
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.
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | xs:string | ||
used by |
|
||
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 | ![]() |
|||||||||||||||
namespace | https://namespaces.xmcl.org/xmcl | |||||||||||||||
used by |
|
|||||||||||||||
attributes |
|
|||||||||||||||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | rights | ||
children | useDuration useCount userInteraction require allowedUse impRight | ||
used by |
|
||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | rights | ||
children | useDuration useCount userInteraction require allowedUse impRight | ||
used by |
|
||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | rights | ||
children | useDuration useCount userInteraction require allowedUse impRight | ||
used by |
|
||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
children | useDuration useCount userInteraction require allowedUse impRight | ||
used by |
|
||
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 | ![]() |
|||||||||||||||
namespace | https://namespaces.xmcl.org/xmcl | |||||||||||||||
used by |
|
|||||||||||||||
attributes |
|
|||||||||||||||
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 | ![]() |
|||||||||||||||
namespace | https://namespaces.xmcl.org/xmcl | |||||||||||||||
used by |
|
|||||||||||||||
attributes |
|
|||||||||||||||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | xs:string | ||
used by |
|
||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | xs:string | ||
used by |
|
||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | xs:string | ||
used by |
|
||
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 | ![]() |
||||||||||
namespace | https://namespaces.xmcl.org/xmcl | ||||||||||
children | param | ||||||||||
used by |
|
||||||||||
attributes |
|
||||||||||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
children | revokedItem | ||
used by |
|
||
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 | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
type | xs:string | ||
used by |
|
||
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 documentdiagram | ![]() |
||
namespace | https://namespaces.xmcl.org/xmcl | ||
used by |
|
||
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 https://purl.org/dc/elements/1.1/
[DCUSAGE] "Using Dublin Core", Diane Hillmann, April 2001. Available at https://dublincore.org/documents/usageguide/
[DCMES-XML] "An XML Encoding of Simple Dublin Core Metadata", D. Beckett, E. Miller, D Brickly, December 2000. Available at https://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.https://www.publishers.org/home/drm.pdf (see https://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. https://www.musicbrainz.org/MM/
[SMIL20] "Synchronized Multimedia Integration Language (SMIL 2.0)". W3C Proposed Recommendation, work in progress. Available at https://www.w3.org/TR/smil20/
[URI] "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax" T. Berners-Lee, R. Fielding, L. Masinter, August 1998. https://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 https://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: https://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 https://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: https://www.w3.org/TR/REC-xml-names
[XSCHEMA-STRUCTURE] "XML Schema, XML Schema Part 1: Structures". W3C Recommendation 2 May 2001. Available at https://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 https://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
[ ALGORITHMS] "XML Encryption Syntax and Processing: 6.1Algorithm Identifiers and Requirements" Available at https://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 https://www.w3.org/TR/xhtml1/
[KEYWORDS]
"RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner.
March 1997.
https://www.ietf.org/rfc/rfc2119.txt