ISO/IEC 29341-4-2:2011

Information technology - UPnP Device Architecture - Part 4-2: Audio Video Device Control Protocol - Level 2 - Media Renderer Device

ISO/IEC 29341-4-2:2011(E) The MediaRenderer specification defines a general-purpose device template that can be used to instantiate any Consumer Electronics (CE) device that is capable of rendering AV content from the home network. It exposes a set of rendering controls in which a control point can control how the specified AV content is rendered. This includes controlling various rendering features such as brightness, contrast, volume, etc. This device specification is compliant with the Universal Plug and Play Device Architecture version 1.0. It defines a device type referred to herein as MediaRenderer. This International Standard replaces ISO/IEC 29341-4-2, first edition, published in 2008, and constitutes a technical revision.

General Information

• Status: Published
• Publication Date: 14-Sep-2011
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: PPUB - Publication issued
• Start Date: 14-Sep-2011
• Completion Date: 31-Jan-2012

Relations

• Revises: ISO/IEC 29341-4-2:2008 - Information technology - UPnP Device Architecture - Part 4-2: Audio Video Device Control Protocol - Level 2 - Media Renderer Device
• Effective Date: 05-Sep-2023

Overview

ISO/IEC 29341-4-2:2011 specifies the UPnP Audio Video (AV) Device Control Protocol - Level 2 MediaRenderer device. Aligned with the Universal Plug and Play (UPnP) Device Architecture v1.0, this international standard defines a lightweight, general-purpose device template for any Consumer Electronics (CE) device that renders audio/video content from the home network. Typical instances include TVs, stereo systems, MP3 players and Electronic Picture Frames (EPFs). The 2011 edition is a technical revision of the 2008 first edition.

Key topics and technical requirements

• Device model and services
  • Defines the MediaRenderer device type and its internal service relationships.
  • Core services shown in the specification include RenderingControl, ConnectionManager and (optionally) AVTransport for content flow control (play, pause, FF, REW depending on transfer protocol).
• Rendering controls
  • Exposes controls for rendering characteristics such as brightness, contrast, volume and playback flow. Control points can manipulate how AV content is rendered on the device.
• Interoperability and constraints
  • Compliant with UPnP Device Architecture v1.0; uses UPnP and XML Schema data typing conventions.
  • The MediaRenderer does not send AV content to other devices nor retrieve content metadata - it only renders content presented to it.
• Data types and syntax
  • Uses RFC2119 keywords (MUST/SHOULD/MAY) for requirement levels.
  • Specifies conventions for boolean representations (recommended "0"/"1"), CSV escaping rules and EBNF for formal syntax definitions.
  • Addresses XML namespaces, schema versioning and vendor-defined extension mechanisms.
• Implementation scope
  • Designed to be lightweight for low-resource devices yet capable of exposing advanced features on high-end devices.

Applications

• Integrating networked AV functionality into consumer electronics: smart TVs, networked speakers, set-top boxes, digital photo frames and portable media players.
• Home automation and multiroom audio/video systems where a control point (app, hub or media server) needs standardized control of rendering behavior.
• Firmware and middleware development for device manufacturers seeking UPnP interoperability on home networks.

Who uses this standard

• CE device manufacturers and firmware engineers
• UPnP control point and media server developers
• System integrators and home automation platform vendors
• Test labs ensuring compliance and interoperability

Related standards

• UPnP Device Architecture (general UPnP framework)
• Other parts of the ISO/IEC 29341 series covering UPnP AV specifications
• XML Schema specifications and RFC2119 (normative references used in the document)

Keywords: ISO/IEC 29341-4-2:2011, MediaRenderer, UPnP AV, RenderingControl, AVTransport, ConnectionManager, home network, consumer electronics, UPnP Device Architecture.

Standards Content (Sample)

ISO/IEC 29341-4-2
Edition 2.0 2011-09
INTERNATIONAL
STANDARD
colour
inside
Information technology –UPnP device architecture –
Part 4-2: Audio Video Device Control Protocol – Level 2 – Media Renderer Device

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about ISO/IEC copyright or have an enquiry about obtaining additional rights to this
publication, please contact the address below or your local IEC member National Committee for further information.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: [e-mail]
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
 Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
 IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
 Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
 Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: [e-mail]
Tel.: [phone]
Fax: [phone]
ISO/IEC 29341-4-2
Edition 2.0 2011-09
INTERNATIONAL
STANDARD
colour
inside
Information technology –UPnP device architecture –
Part 4-2: Audio Video Device Control Protocol – Level 2 – Media Renderer Device

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
K
ICS 35.200 ISBN 978-2-88912-678-1

29341-4-2 XXX: © IEC:2010 © ISO/IEC:2011(E) — 1 —
CONTENTS
1  Overview and Scope . 2
1.1  Introduction . 2
1.2  Notation . 3
1.2.1  Data Types . 3
1.2.2  Strings Embedded in Other Strings . 3
1.2.3  Extended Backus-Naur Form . 4
1.3  Derived Data Types . 4
1.3.1  Comma Separated Value (CSV) Lists . 5
1.4  Management of XML Namespaces in Standardized DCPs . 6
1.4.1  Namespace Prefix Requirements . 9
1.4.2  Namespace Names, Namespace Versioning and Schema Versioning . 10
1.4.3  Namespace Usage Examples . 12
1.5  Vendor-defined Extensions . 13
1.5.1  Vendor-defined Action Names . 13
1.5.2  Vendor-defined State Variable Names . 13
1.5.3  Vendor-defined XML Elements and attributes . 13
1.5.4  Vendor-defined Property Names . 13
1.6  References . 13
2  Device Definitions . 17
2.1  Device Type . 17
2.2  Device Model . 17
2.2.1  Description of Device Requireme nts . 17
2.2.2  Relationships Between Services . 18
2.3  Theory of Operation . 18
2.3.1  Device Discovery . 19
2.3.2  Preparing to Transfer the Content . 19
2.3.3  Controlling the Transfer of the Co ntent . 19
2.3.4  Controlling How the Content is Rendered . 19
3  XML Device Description . 20
4  Test . . 21

Figure 1 — MediaRenderer Functional Diagram . 2

Table 1-1 — EBNF Operators . 4
Table 1-2 — CSV Examples . 6
Table 1-3 — Namespace Definitions . 8
Table 1-4 — Schema-related Information . 9
Table 1-5 — Default Namespaces for the AV Specifications . 10
Table 2-6 — Device Requirem ents . 17

29341-4-2 © ISO/IEC:2011(E)
INFORMATION TECHNOLOGY –
UPNP DEVICE ARCHITECTURE –
Part 4-2: Audio Video Device Control Protocol –
Level 2 – Media Renderer Device
FOREWORD
1) ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in
the development of International Standards. Their preparation is entrusted to technical committees; any ISO and
IEC member body interested in the subject dealt with may participate in this preparatory work. International
governmental and non-governmental organizations liaising with ISO and IEC also participate in this preparation.
2) In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
3) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested IEC and ISO member bodies.
4) IEC, ISO and ISO/IEC publications have the form of recommendations for international use and are accepted
by IEC and ISO member bodies in that sense. While all reasonable efforts are made to ensure that the
technical content of IEC, ISO and ISO/IEC publications is accurate, IEC or ISO cannot be held responsible for
the way in which they are used or for any misinterpretation by any end user.
5) In order to promote international uniformity, IEC and ISO member bodies undertake to apply IEC, ISO and
ISO/IEC publications transparently to the maximum extent possible in their national and regional publications.
Any divergence between any ISO/IEC publication and the corresponding national or regional publication
should be clearly indicated in the latter.
6) ISO and IEC provide no marking procedure to indicate their approval and cannot be rendered responsible for
any equipment declared to be in conformity with an ISO/IEC publication.
7) All users should ensure that they have the latest edition of this publication.
8) No liability shall attach to IEC or ISO or its directors, employees, servants or agents including individual experts
and members of their technical committees and IEC or ISO member bodies for any personal injury, property
damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees)
and expenses arising out of the publication of, use of, or reliance upon, this ISO/IEC publication or any other IEC,
ISO or ISO/IEC publications.
9) Attention is drawn to the normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
10) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 29341-4-2 was prepared by UPnP Forum Steering
committee , was adopted, under the fast track procedure, by subcommittee 25:
Interconnection of information technology equipment, of ISO/IEC joint technical committee 1:
Information technology.
This International Standard replaces ISO/IEC 29341-4-2, first edition, published in 2008, and
constitutes a technical revision.
The list of all currently available parts of the ISO/IEC 29341 series, under the general title
Information technology – UPnP device architecture, can be found on the IEC web site.
This International Standard has been approved by vote of the member bodies, and the voting
results may be obtained from the address given on the second title page.
—————————
rd
UPnP Forum Steering committee, UPnP Forum, 3855 SW 153 Drive, Beaverton, Oregon 97006 USA. See also
“Introduction”.
29341-4-2 © ISO/IEC:2011(E)
IMPORTANT – The “colour inside” logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this publication using a colour printer.

XXX: © IEC:2010 — 2 — 29341-4-2 © ISO/IEC:2011(E)
1 Overview and Scope
1.1 Introduction
This device specification is compliant with the Universal Plug and Play Device Architecture
version 1.0. It defines a device type referred to herein as MediaRenderer.
The MediaRenderer specification defines a general-purpose device template that can be
used to instantiate any Consumer Electronics (CE) device that is capable of rendering AV
content from the home network. It exposes a set of rendering controls in which a control point
can control how the specified AV content is rendered. This includes controlling various
rendering features such as brightness, contrast, volume, etc.
Example instances of a MediaRenderer include traditional devices such as TVs and stereo
systems. Some more contemporary examples include digital devices such as MP3 players
and Electronic Picture Frames (EPFs). Although most of these examples typically render one
specific type of content (for example, a TV typically renders video content), a MediaRenderer
is able to support a number of different data formats and transfer protocols. For example, a
sophisticated implementation of a TV MediaRenderer could also support MP3 data so that its
speakers could be used to play MP3 audio content.
The MediaRenderer device specification is very lightweight and is easy to implement on low-
resource devices such as an MP3 player. However, it can also be used to expose the high-
end capabilities of devices such as a PC.
A full-featured MediaRenderer exposes the following capabilities:
• Control various rendering characteristics
• Expose the supported transfer protocols and data formats
• Control the flow of the content (for example, FF, REW, etc), if appropriate depending on
the transfer protocol.
•
The MediaRenderer DOES NOT enable control points to:
• Send AV content to another device
• Retrieve any type of meta-data associated with the content
From Network
Content Transfer Format Decoder Rendering
Subsystem Subsystem Hardware
AVTransport ConnectionManager RenderingControl
Service Service Service
(Optional) (Required) (Required)
MediaRenderer
Figure 1 — MediaRenderer Functional Diagram
The un-shaded blocks represent the UPnP services that are contained by a MediaRenderer.
The shaded blocks represent various device-specific modules that the UPnP services might

29341-4-2 XXX: © IEC:2010 © ISO/IEC:2011(E) — 3 —
interact with. However, the internal architecture of a MediaRenderer device is vendor
specific.
1.2 Notation
• In this document, features are described as Required, Recommended, or Optional as
follows:
The keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,”
“SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this specification are to
be interpreted as described in [RFC 2119].
In addition, the following keywords are used in this specification:
PROHIBITED – The definition or behavior is prohibited by this specification. Opposite of
REQUIRED.
CONDITIONALLY REQUIRED – The definition or behavior depends on a condition. If the
specified condition is met, then the definition or behavior is REQUIRED, otherwise it is
PROHIBITED.
CONDITIONALLY OPTIONAL – The definition or behavior depends on a condition. If the
specified condition is met, then the definition or behavior is OPTIONAL, otherwise it is
PROHIBITED.
These keywords are thus capitalized when used to unambiguously specify requirements
over protocol and application features and behavior that affect the interoperability and
security of implementations. When these words are not capitalized, they are meant in
their natural-language sense.
• Strings that are to be taken literally are enclosed in “double quotes”.
• Words that are emphasized are printed in italic.
• Keywords that are defined by the UPnP AV Working Committee are printed using the
character style.
forum
• Keywords that are defined by the UPnP Device Architecture specification are printed
using the arch character style [DEVICE].
• A double colon delimiter, “::”, signifies a hierarchical parent-child (parent::child)
relationship between the two objects separated by the double colon. This delimiter is used
in multiple contexts, for example: Service::Action(), Action()::Argument,
parentProperty::childProperty.
1.2.1 Data Types
This specification uses data type definitions from two different sources. The UPnP Device
Architecture defined data types are used to define state variable and action argument data
types [DEVICE]. The XML Schema namespace is used to define property data types [XML
SCHEMA-2].
For UPnP Device Architecture defined boolean data types, it is strongly RECOMMENDED to
use the value “0” for false, and the value “1” for true. However, when used as input
arguments, the values “false”, “no”, “true”, “yes” may also be encountered and MUST be
accepted. Nevertheless, it is strongly RECOMMENDED that all boolean state variables and
output arguments be represented as “0” and “1”.
For XML Schema defined Boolean data types, it is strongly RECOMMENDED to use the value
“0” for false, and the value “1” for true. However, when used as input properties, the values
“false”, “true” may also be encountered and MUST be accepted. Nevertheless, it is strongly
RECOMMENDED that all properties be represented as “0” and “1”.
1.2.2 Strings Embedded in Other Strings
Some string variables and arguments described in this document contain substrings that
MUST be independently identifiable and extractable for other processing. This requires the

XXX: © IEC:2010 — 4 — 29341-4-2 © ISO/IEC:2011(E)
definition of appropriate substring delimiters and an escaping mechanism so that these
delimiters can also appear as ordinary characters in the string and/or its independent
substrings. This document uses embedded strings in two contexts – Comma Separated Value
(CSV) lists (see Clause 1.3.1, “Comma Separated Value (CSV) Lists”) and property values in
search criteria strings. Escaping conventions use the backslash character, “\” (character code
U+005C), as follows:
a) Backslash (“\”) is represented as “\\” in both contexts.
b) Comma (“,”) is
1) represented as “\,” in individual substring entries in CSV lists
2) not escaped in search strings
c) Double quote (“””) is
1) not escaped in CSV lists
2) not escaped in search strings when it appears as the start or end delimiter of a
property value
3) represented as “\”” in search strings when it appears as a character that is part of the
property value
1.2.3 Extended Backus-Naur Form
Extended Backus-Naur Form is used in this document for a formal syntax description of
certain constructs. The usage here is according to the reference [EBNF].
1.2.3.1 Typographic conventions for EBNF
Non-terminal symbols are unquoted sequences of characters from the set of English upper
and lower case letters, the digits “0” through “9”, and the hyphen (“-”). Character sequences
between 'single quotes' are terminal strings and MUST appear literally in valid strings.
Character sequences between (*comment delimiters*) are English language definitions
or supplementary explanations of their associated symbols. White space in the EBNF is used
to separate elements of the EBNF, not to represent white space in valid strings. White space
usage in valid strings is described explicitly in the EBNF. Finally, the EBNF uses the following
operators:
Table 1-1 — EBNF Operators
Operator Semantics
::=
definition – the non-terminal symbol on the left is defined by one or more alternative
sequences of terminals and/or non-terminals to its right.
|
alternative separator – separates sequences on the right that are independently allowed
definitions for the non-terminal on the left.
*
null repetition – means the expression to its left MAY occur zero or more times.
+
non-null repetition – means the expression to its left MUST occur at least once and MAY
occur more times.
[ ]
optional – the expression between the brackets is optional.
( )
grouping – groups the expressions between the parentheses.
-
character range – represents all characters between the left and right character operands
inclusively.
1.3 Derived Data Types
This clause defines a derived data type that is represented as a string data type with special
syntax. This specification uses string data type definitions that originate from two different
sources. The UPnP Device Architecture defined string data type is used to define state
variable and action argument string data types. The XML Schema namespace is used to
define property xsd:string data types. The following definition applies to both string data
types.
29341-4-2 XXX: © IEC:2010 © ISO/IEC:2011(E) — 5 —
1.3.1 Comma Separated Value (CSV) Lists
The UPnP AV services use state variables, action arguments and properties that represent
lists – or one-dimensional arrays – of values. The UPnP Device Architecture, Version 1.0
[DEVICE], does not provide for either an array type or a list type, so a list type is defined
here. Lists MAY either be homogeneous (all values are the same type) or heterogeneous
(values of different types are allowed). Lists MAY also consist of repeated occurrences of
homogeneous or heterogeneous subsequences, all of which have the same syntax and
semantics (same number of values, same value types and in the same order). The data type
of a homogeneous list is string or xsd:string and denoted by CSV (x), where x is the type of
the individual values. The data type of a heterogeneous list is also string or xsd:string and
denoted by CSV (x, y, z), where x, y and z are the types of the individual values. If the
number of values in the heterogeneous list is too large to show each type individually, that
variable type is represented as CSV (heterogeneous), and the variable description includes
additional information as to the expected sequence of values appearing in the list and their
corresponding types. The data type of a repeated subsequence list is string or xsd:string and
denoted by CSV ({x, y, z}), where x, y and z are the types of the individual values in the
subsequence and the subsequence MAY be repeated zero or more times.
• A list is represented as a string type (for state variables and action arguments) or
xsd:string type (for properties).
• Commas separate values within a list.
• Integer values are represented in CSVs with the same syntax as the integer data type
specified in [DEVICE] (that is: optional leading sign, optional leading zeroes, numeric US-
ASCII)
• Boolean values are represented in state variable and action argument CSVs as either “0”
for false or “1” for true. These values are a subset of the defined boolean data type
values specified in [DEVICE]: 0, false, no, 1, true, yes.
• Boolean values are represented in property CSVs as either “0” for false or “1” for true.
These values are a subset of the defined Boolean data type values specified in [XML
SCHEMA-2]: 0, false, 1, true.
• Escaping conventions for the comma and backslash characters are defined in Clause
1.2.2, “Strings Embedded in Other Strings”.
• White space before, after, or interior to any numeric data type is not allowed.
• White space before, after, or interior to any other data type is part of the value.

XXX: © IEC:2010 — 6 — 29341-4-2 © ISO/IEC:2011(E)
Table 1-2 — CSV Examples
Type refinement of Value Comments
string
“+artist,-date” List of 2 property sort
CSV (string) or
CSV (xsd:string) criteria.
CSV (int) or “1,-5,006,0,+7” List of 5 integers.
CSV (xsd:integer)
CSV (boolean) or “0,1,1,0” List of 4 booleans
CSV (xsd:Boolean)
CSV (string) or “Smith\, Fred,Jones\, Davey” List of 2 names,
CSV (xsd:string) “Smith, Fred” and
“Jones, Davey”
CSV (i4,string,ui2) or “-29837,  string with leading blanks,0” Note that the second value
CSV (xsd:int, is “  string with leading
xsd:string, blanks”
xsd:unsignedShort)
CSV (i4) or “3, 4” Illegal CSV. White space
is not allowed as part of
CSV (xsd:int)
an integer value.
CSV (string) or “,,” List of 3 empty string
values
CSV (xsd:string)
CSV (heterogeneous) “Alice,Marketing,5,Sue,R&D,21,Dave,Finance,7” List of unspecified number
of people and associated
attributes. Each person is
described by 3 elements:
a name string, a
department string and
years-of-service ui2 or a
name xsd:string, a
department xsd:string and
years-of-service
xsd:unsignedShort.
1.4 Management of XML Namespaces in Standardized DCPs
UPnP specifications make extensive use of XML namespaces. This allows separate DCPs,
and even separate components of an individual DCP, to be designed independently and still
avoid name collisions when they share XML documents. Every name in an XML document
belongs to exactly one namespace. In documents, XML names appear in one of two forms:
qualified or unqualified. An unqualified name (or no-colon-name) contains no colon (“:”)
characters. An unqualified name belongs to the document’s default namespace. A qualified
name is two no-colon-names separated by one colon character. The no-colon-name before
the colon is the qualified name’s namespace prefix, the no-colon-name after the colon is the
qualified name’s “local” name (meaning local to the namespace identified by the namespace
prefix). Similarly, the unqualified name is a local name in the default namespace.
The formal name of a namespace is a URI. The namespace prefix used in an XML document
is not the name of the namespace. The namespace name is, or should be, globally unique. It
has a single definition that is accessible to anyone who uses the namespace. It has the same
meaning anywhere that it is used, both inside and outside XML documents. The namespace
prefix, however, in formal XML usage, is defined only in an XML document. It must be locally
unique to the document. Any valid XML no-colon-name may be used. And, in formal XML
usage, no two XML documents are ever required to use the same namespace prefix to refer
to the same namespace. The creation and use of the namespace prefix was standardized by
the W3C XML Committee in [XML-NMSP] strictly as a convenient local shorthand
replacement for the full URI name of a namespace in individual documents.
All AV object properties are represented in XML by element and attribute names, therefore,
all property names belong to an XML namespace.

29341-4-2 XXX: © IEC:2010 © ISO/IEC:2011(E) — 7 —
For the same reason that namespace prefixes are convenient in XML documents, it is
convenient in specification text to refer to namespaces using a namespace prefix. Therefore,
this specification declares a “standard” prefix for all XML namespaces used herein. In
addition, this specification expands the scope where these prefixes have meaning, beyond a
single XML document, to all of its text, XML examples, and certain string-valued properties.
This expansion of scope does not supercede XML rules for usage in documents, it only
augments and complements them in important contexts that are out-of-scope for the XML
specifications. For example, action arguments which refer to CDS properties, such as the
SearchCriteria argument of the Search() action or the Filter argument of the Browse() action,
MUST use the predefined namespace prefixes when referring to CDS properties (“upnp:”,
“dc:”, etc).
All of the namespaces used in this specification are listed in the Tables “ — Namespace
Definitions” and “ — Schema-related Information”. For each such namespace, Table 1-3, “ —
Namespace Definitions” gives a brief description of it, its name (a URI) and its defined
“standard” prefix name. Some namespaces included in these tables are not directly used or
referenced in this document. They are included for completeness to accommodate those
situations where this specification is used in conjunction with other UPnP specifications to
construct a complete system of devices and services. For example, since the Scheduled
Recording Service depends on and refers to the Content Directory Service, the predefined
“srs:” namespace prefix is included. The individual specifications in such collections all use
the same standard prefix. The standard prefixes are also used in Table 1-4, “ — Schema-
related Information”, to cross-reference additional namespace information. This second table
includes each namespace’s valid XML document root element(s) (if any), its schema file
name, versioning information (to be discussed in more detail below), and a links to the entry
in Clause 1.4.3, “Namespace Usage Examples” for its associated schema.
The normative definitions for these namespaces are the documents referenced in Table 1-3.
The schemas are designed to support these definitions for both human understanding and as
test tools. However, limitations of the XML Schema language itself make it difficult for the
UPnP-defined schemas to accurately represent all details of the namespace definitions. As a
result, the schemas will validate many XML documents that are not valid according to the
specifications.
The Working Committee expects to continue refining these schemas after specification
release to reduce the number of documents that are validated by the schemas while violating
the specifications, but the schemas will still be informative, supporting documents. Some
schemas might become normative in future versions of the specifications.

XXX: © IEC:2010 — 8 — 29341-4-2 © ISO/IEC:2011(E)
Table 1-3 — Namespace Definitions
Standar
d Name-
space Normative Definition
Prefix Namespace Name Namespace Description Document Reference
AV Working Committee defined namespaces
av urn:schemas-upnp-org:av:av Common data types for [AV-XSD]
use in AV schemas
avs urn:schemas-upnp-org:av:avs Common structures for [AVS-XSD]
use in AV schemas
avdt urn:schemas-upnp-org:av:avdt Datastructure Template [AVDT]
avt-event urn:schemas-upnp-org:metadata-1-0/AVT/ Evented LastChange state [AVT]
variable for AVTransport
cds- urn:schemas-upnp-org:av:cds-event Evented LastChange state [CDS]
event variable for
ContentDirectory
didl-lite urn:schemas-upnp-org:metadata-1-0/DIDL- Structure and metadata [CDS]
Lite/ for ContentDirectory
rcs-event urn:schemas-upnp-org:metadata-1-0/RCS/ Evented LastChange state [RCS]
variable for
RenderingControl
srs urn:schemas-upnp-org:av:srs Metadata and structure for [SRS]
ScheduledRecording
srs-event urn:schemas-upnp-org:av:srs-event Evented LastChange state [SRS]
variable for
ScheduledRecording
upnp urn:schemas-upnp-org:metadata-1-0/upnp/ Metadata for [CDS]
ContentDirectory
Externally defined namespaces
dc http://purl.org/dc/elements/1.1/ Dublin Core [DC-TERMS]
xsd http://www.w3.org/2001/XMLSchema XML Schema Language [XML SCHEMA-1]
1.0 [XML SCHEMA-2]
xsi http://www.w3.org/2001/XMLSchema-instance XML Schema Instance Clauses 2.6 & 3.2.7 of
Document schema [XML SCHEMA-1]
xml http://www.w3.org/XML/1998/namespace The “xml:” Namespace [XML-NS]

29341-4-2 XXX: © IEC:2010 © ISO/IEC:2011(E) — 9 —
Table 1-4 — Schema-related Information
Standar
Relative URI and
d Name-
a
space File Name
Prefix ● Form 1, Form 2, Form3 Valid Root Element(s) Schema Reference
AV Working Committee Defined Namespaces
av av-vn-yyyymmdd.xsd n/a [AV-XSD]
av-vn.xsd
av.xsd

avs avs-vn-yyyymmdd.xsd [AVS-XSD]

avs-vn.xsd

avs.xsd

avdt avdt-vn-yyyymmdd.xsd [AVDT]
avdt-vn.xsd
avdt.xsd

avt-event avt-event-vn-yyyymmdd.xsd [AVT-EVENT-XSD]
avt-event-vn.xsd
avt-event.xsd

cds- cds-event-vn-yyyymmdd.xsd [CDS-EVENT-XSD]
event
cds-event-vn.xsd
cds-event.xsd

didl-lite didl-lite-vn-yyyymmdd.xsd [DIDL-LITE-XSD]
didl-lite-vn.xsd
didl-lite.xsd

rcs-event rcs-event-vn-yyyymmdd.xsd [RCS-EVENT-XSD]
rcs-event-vn.xsd
rcs-event.xsd

srs srs-vn-yyyymmdd.xsd [SRS-XSD]
srs-vn.xsd
srs.xsd

srs-event srs-event-vn-yyyymmdd.xsd [SRS-EVENT-XSD]
srs-event-vn.xsd
srs-event.xsd
upnp upnp-vn-yyyymmdd.xsd n/a [UPNP-XSD]
upnp-vn.xsd
upnp.xsd
Externally Defined Namespaces
dc Absolute URL: http://dublincore.org/schemas/xmls/simpledc20021212.xsd [DC-XSD]


xsd n/a [XMLSCHEMA-
XSD]
xsi n/a n/a
xml n/a [XML-XSD]
a
Absolute URIs are generated by prefixing the relative URIs with "http://www.upnp.org/schemas/av/".
1.4.1 Namespace Prefix Requirements
There are many occurrences in this specification of string data types that contain XML names
(property names). These XML names in strings will not be processed under namespace-
aware conditions. Therefore, all occurrences in instance documents of XML names in strings

XXX: © IEC:2010 — 10 — 29341-4-2 © ISO/IEC:2011(E)
MUST use the standard namespace prefixes as declared in Table 1-3. In order to properly
process the XML documents described herein, control points and devices MUST use
namespace-aware XML processors [XML-NMSP] for both reading and writing. As allowed by
[XML-NMSP], the namespace prefixes used in an instance document are at the sole
discretion of the document creator. Therefore, the declared prefix for a namespace in a
document MAY be different from the standard prefix. All devices MUST be able to correctly
process any valid XML instance document, even when it uses a non-standard prefix for
ordinary XML names. However, it is strongly RECOMMENDED that all devices use these
standard prefixes for all instance documents to avoid confusion on the part of both human
and machine readers. These standard prefixes are used in all descriptive text and all XML
examples in this and related UPnP specifications. Also, each individual specification may
assume a default namespace for its descriptive text. In that case, names from that
namespace may appear with no prefix.
The assumed default namespace, if any, for each UPnP AV specification is given in Table 1-
5, “ — Default Namespaces for the AV Specifications”.
Note: all UPnP AV schemas declare attributes to be “unqualified”, so namespace prefixes are
never used with AV Working Committee defined attribute names.
Table 1-5 — Default Namespaces for the AV Specifications
AV Specification Name Default Namespace Prefix
AVTransport avt-event
ConnectionManager n/a
ContentDirectory didl-lite
MediaRenderer n/a
MediaServer n/a
RenderingControl rcs-event
ScheduledRecording srs
1.4.2 Namespace Names, Namespace Versioning and Schema Versioning
The UPnP AV service specifications define several data structures (such as state variables
and action arguments) whose format is an XML instance document that must comply with one
or more specific XML namespaces. Each namespace is uniquely identified by an assigned
namespace name. The namespaces that are defined by the AV Working Committee MUST be
named by a URN. See Table 1-3, “ — Namespace Definitions” for a current list of namespace
names. Additionally, each namespace corresponds to an XML schema document that
provides a machine-readable representation of the associated namespace to enable
automated validation of the XML (state variable or action parameter) instance documents.
Within an XML schema and XML instance document, the name of each corresponding
namespace appears as the value of an xmlns attribute within the root element. Each xmlns
attribute also includes a namespace prefix that is associated with that namespace in order to
disambiguate (a.k.a. qualify) element and attribute names that are defined within different
namespaces. The schemas that correspond to the listed namespaces are identified by URI
values that are listed in the schemaLocation attribute also within the root element. (See
Clause 1.4.3 “Namespace Usage Examples”)
In order to enable both forward and backward compatibility, namespace names are
permanently assigned and MUST NOT change even when a new version of a specification
changes the definition of a namespace. However, all changes to a namespace definition
MUST be backward-compatible. In other words, the updated definition of a namespace
MUST NOT invalidate any XML documents that comply with an earlier definition of that same
namespace. This means, for example, that a namespace MUST NOT be changed so that a
new element or attribute is required. Although namespace names MUST NOT change,
namespaces still have version numbers that reflect a specific set of definitional changes.

29341-4-2 XXX: © IEC:2010 © ISO/IEC:2011(E) — 11 —
Each time the definition of a namespace is changed, the namespace’s version number is
incremented by one.
Each time a new namespace version is created, a new XML schema document (.xsd) is
created and published so that the new namespace definition is represented in a machine-
readable form. Since a XML schema document is just a representation of a namespace
definition, translation errors can occur. Therefore, it is sometime necessary to re-release a
published schema in order to correct typos or other namespace representation errors. In
order to easily identify the potential multiplicity of schema releases for the same namespace,
the URI of each released schema MUST conform to the following format (called Form 1):
Form 1: "http://www.upnp.org/schemas/av/" schema-root-name "-v" ver "-" yyyymmdd
where
• schema-root-name is the name of the root element of the namespace that this schema
represents.
• ver corresponds to the version number of the namespace that is represented by the
schema.
• yyyymmdd is the year, month and day (in the Gregorian calendar) that this schema was
released.
Table 1-4, “ — Schema-related Information” identifies the URI formats for each of the
namespaces that are currently defined by the UPnP AV Working Committee.
As an example, the original schema URI for the “rcs-event” namespace (that was released
with the original publication of the UPnP AV service specifications in the year 2002) was
“http://www.upnp.org/schemas/av/rcs-event-v1-20020625.xsd”. When the UPnP AV service
specifications were subsequently updated in the year 2006, the URI for the updated version
of the “rcs-event” namespace was “http://www.upnp.org/schemas/av/rcs-event-v2-
20060531.xsd”. However, in 2006, the schema URI for the newly created “srs-event”
namespace was “http://www.upnp.org/schemas/av/srs-event-v1-20060531.xsd”. Note the
version field for the “srs-event” schema is “v1” since it was first version of that namespace
whereas the version field for the “rcs-event” schema is “v2” since it was the second version of
that namespace.
In addition to the dated schema URIs that are associated with each namespace, each
namepace also has a set of undated schema URIs. These undated schema URIs have two
distinct formats with slightly different meanings:
Form 2: “http://www.upnp.org/schemas/av/” schema-root-name “-v” ver
where ver is described above.
Form 3: “http://www.upnp.org/schemas/av/” schema-root-name
Form 2 of the undated schema URI is always linked to the most recent release of the schema
that represents the version of the namespace indicated by ver. For example, the undated URI
“…/av/rcs-event-v2.xsd” is linked to the most recent schema release of version 2 of the “rcs-
event” namespace. Therefore, on May 31, 2006 (20060531), the undated schema URI was
linked to the schema that is otherwise known as “…/av/rcs-event-v2-20060531.xsd”.
Furthermore, if the schema for version 2 of the “rcs-event” namespace was ever re-released,
for example to fix a typo in the 20060531 schema, then the same undated schema URI
(“…/av/rcs-event-v2.xsd”) would automatically be updated to link to the updated version 2
schema for the “rcs-event” namespace.
Form 3 of the undated schema URI is always linked to the most recent release of the schema
that represents the highest version of the namespace that has been published. For example,
on June 25, 2002 (20020625), the undated schema URI “…/av/rcs-event.xsd” was linked to
the schema that is otherwise known as “…/av/rcs-event-v1-20020625.xsd”. However, on May

XXX: © IEC:2010 — 12 — 29341-4-2 © ISO/IEC:2011(E)
31, 2006 (20060531), that same undated schema URI was linked to the schema that is
otherwise known as “…/av/rcs-event-v2-20060531.xsd”.
When referencing a schema URI within an XML instance document or a referencing XML
schema document, the following usage rules apply:
• All instance documents, whether generated by a service or a control point, MUST use
Form 3.
• All UPnP AV published schemas that reference other UPnP AV schemas MUST also use
Form 3.
Within an XML instance document, the definition for the schemaLocation attribute comes
from the XML Schema namespace “http://www.w3.org/2002/XMLSchema-instance”. A single
occurrence of the attribute can declare the location of one or more schemas. The
schemaLocation attribute value consists of a whitespace separated list of values that is
interpreted as a namespace name followed by its schema location URL. This pair-sequence
is repeated as necessary for the schemas that need to be located for this instance document.
In addition to the schema URI naming and usage rules described above, each released
schema MUST contain a version attribute in the root element. Its value MUST
correspond to the format:
ver “-” yyyymmdd where ver and yyyymmdd are described above.
The version attribute provides self-identification of the namespace version and release date
of the schema itself. For example, within the original schema released for the “rcs-event”
namespace (…/rcs-event-v2-20020625.xsd), the root element contains the
following attribute: version="2-20020625".
1.4.3 Namespace Usage Examples
The schemaLocation attribute for XML instance documents comes from the XML Schema
instance namespace “http:://www.w3.org/2002/XMLSchema-instance”. A single occurrence of
the attribute can declare the location of one or more schemas. The schemaLocation
attribute value consists of a whitespace separated list of values: namespace name followed
by its schema location URL. This pair-sequence is repeated as necessary for the schemas
that need to be located for this instance document.
Example 1:
Sample DIDL-Lite XML Instance Document. Note that the references to the UPnP AV
schemas do not contain any version or release date information. In other words, the
references follow Form 3 from above. Consequently, this example is valid for all releases of
the UPnP AV service specifications.

xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/
http://www.upnp.org/schemas/av/didl-lite.xsd
urn:schemas-upnp-org:metadata-1-0/upnp/
http://www.upnp.org/schemas/av/upnp.xsd">

...


29341-4-2 XXX: © IEC:2010 © ISO/IEC:2011(E) — 13 —
1.5 Vendor-defined Extensions
Whenever vendors create additional vendor-defined state variables, actions or properties,
their assigned names and XML representation MUST follow the naming conventions and XML
rules as specified below.
1.5.1 Vendor-defined Action Names
Vendor-defined action names MUST begin with “X_”. Additionally, it SHOULD be followed by
an ICANN assigned domain name owned by the vendor followed by the underscore character
(“_”). It MUST then be followed by the vendor-assigned action name. The vendor-assigned
action name MUST NOT contain a hyphen character (“-”, 2D Hex in UTF-8) nor a hash
character (“#”, 23 Hex in UTF-8). Vendor-assigned action names are case sensitive. The first
character of the name MUST be a US-ASCII letter (“A”-“Z”, “a”-“z”), US-ASCII digit (“0”-“9”),
an underscore (“_”), or a non-experimental Unicode letter or digit greater than U+007F.
Succeeding characters MUST be a US-ASCII letter (“A”-“Z”, “a”-“z”), US-ASCII digit (“0”-“9”),
an underscore (“_”), a period (“.”), a Unicode combiningchar, an extender, or a non-
experimental Unicode letter or digit greater than U+007F. The first three letters MUST NOT
be “XML” in any combination of case.
1.5.2 Vendor-defined State Variable Names
Vendor-defined state variable names MUST begin with “X_”
...