IEC 62481-3:2010

IEC 62481-3 ®
Edition 1.0 2010-11
INTERNATIONAL
STANDARD
colour
inside
Digital living network alliance (DLNA) home networked device interoperability
guidelines –
Part 3: Link protection
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 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: inmail@iec.ch
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: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
IEC 62481-3 ®
Edition 1.0 2010-11
INTERNATIONAL
STANDARD
colour
inside
Digital living network alliance (DLNA) home networked device interoperability
guidelines –
Part 3: Link protection
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
XB
ICS 33.100; 35.100.06; 35.110 ISBN 978-2-88912-204-2
– 2 – 62481-3 Ó IEC:2010(E)
CONTENTS
FOREW ORD . 5
1 Sc o pe . 7
2 Normative reference . 7
3 Terms, definitions and acronyms . 8
3.1 Terms and definition . 8
3.2 Abbreviation terms . 12
4 DLNA home network architecture . 13
5 DLNA device model . 13
6 Guideline terminology and conventions . 13
6.1 Guideline compliance classifiers . 13
6.2 Standard of specification usage classifiers . 13
6.3 Guideline font usage conventions . 14
6.4 Guideline syntax notation convention . 14
6.5 Guideline normative and informative text conventions . 15
6.6 DLNA XML namespaces and schemas . 15
7 Common link protection guidelines . 15
7.1 General . 15
7.2 Conditions for measuring time in message exchanges . 18
7.3 Networking and connectivity . 18
7.3.1 General . 18
7.3.2 New general capability requirements – Bluetooth NC CP – Power
saving modes . 18
7.4 Device discovery and control . 19
7.5 Media management . 19
7.5.1 Media management – AV media management . 19
7.5.2 AV media management guidelines . 22
7.6 Media transport . 25
7.6.1 General . 25
7.6.2 Media transport protocols . 25
7.6.3 HTTP transport . 27
7.6.4 HTTP media transport for streaming transfer guidelines . 34
7.6.5 HTTP media transport for interactive transfer guidelines . 34
7.6.6 RTP transport . 35
7.7 Content conversion device virtualization . 36
7.8 Media interoperability unit (MIU) . 36
7.9 Link protection technology guidelines requirements . 36
7.9.1 Link protection system – DTCP-IP. 36
7.9.2 Link protection system – Windows media DRM for network devices . 37
8 DTCP-IP link protection system guidelines . 37
8.1 General . 37
8.2 Networking and connectivity . 37
8.2.1 Networking and connectivity – General capability requirements. 37
8.2.2 New DLNAQOS requirements QoS requirement for DTCP-IP traffic . 38
8.2.3 New device requirements – Common NC CP – Wireless security . 38
8.3 Device discovery and control . 38
8.4 Media management . 38

62481-3 Ó IEC:2010(E) – 3 –
8.4.1 Media management – AV media management . 38
8.4.2 MM CP – DTCP-IP URI . 38
8.5 Media transport . 39
8.5.1 HTTP transport . 39
8.5.2 RTP transport . 40
8.6 Content conversion device virtualization . 42
8.7 Media interoperability unit (MIU) . 42
8.8 Media format – DTCP-IP profiling guidelines . 42
8.8.1 General . 42
8.8.2 CP DTCP-IP – Profile . 42
8.8.3 CP DTCP-IP – Profile MIME type definition . 43
8.8.4 CP DTCP-IP – Profile protected and unprotected content portions . 44
8.8.5 CP DTCP-IP – Profile HTTP encapsulation . 45
8.8.6 DTCP-IP profile encapsulation . 45
8.9 General requirements . 47
8.9.1 General . 47
8.9.2 CP DTCP-IP – Requirements. 47
9 WMDRM-ND link protection system guidelines . 47
9.1 General . 47
9.2 General requirements . 48
9.2.1 General . 48
9.2.2 CP WMDRM-ND – Requirements . 48
9.2.3 CP WMDRM-ND – Support for HTTP . 48
9.2.4 CP WMDRM-ND – Support for RTP . 48
9.2.5 CP WMDRM-ND – Registration and revalidation procedures . 49
9.2.6 CP WMDRM-ND – Discovery of content receivers . 49
9.3 Networking and connectivity . 50
9.3.1 Networking and connectivity – General capability requirements. 50
9.3.2 CP WMDRM-ND – QoS requirements . 50
9.4 Device discovery and control . 50
9.4.1 General . 50
9.4.2 CP WMDRM-ND – Additional rules for DMRs . 50
9.5 Media management . 50
9.6 Media transport . 51
9.6.1 HTTP transport . 51
9.6.2 RTP transport . 54
9.7 Content conversion device virtualization . 56
9.8 Media interoperability unit (MIU) . 56
9.9 Media format – WMDRM-ND profiling guidelines . 56
9.9.1 General . 56
9.9.2 CP WMDRM-ND – Identification of content transferred using
WMDRM-ND . 56
9.9.3 CP WMDRM-ND – Media format requirements . 57
9.9.4 CP WMDRM-ND – MIME type . 57
9.9.5 CP WMDRM-ND – Decoder friendly alignment position . 57
9.9.6 CP WMDRM-ND – Media format alignment element . 57
Annex A (informative) An introduction to DLNA seek operations . 58
Bibliography . 67

– 4 – 62481-3 Ó IEC:2010(E)
Figure 1 – Guideline layout and definitions . 16
Figure 2 – Visual map of possible values for the attribute tables . 17
Figure A.1 – UCDAM definitions for seek operations . 59
Figure A.2 – Full random access data availability model . 60
Figure A.3 – Limited random access data availability model mode 0 . 62
Figure A.4 – Limited random access data availability mode 1 . 63
Figure A.5 – Content flow unprotected content . 65
Figure A.6 – Content flow link protected content . 65

Table 1 – DLNA namespace values . 15
Table 2 – Allowed values for change indicator field in attribute table . 17
Table 3 – Normative priorities for dlna traffic types for link protection . 18
Table 4 – Summary of domain elements for full random access data availability mode . 20
Table 5 – Summary of domain elements for limited random access data availability
model . 21
Table 6 – AV media management guideline changes . 22
Table 7 – Recommended metadata properties . 23
Table 8 – Property type and multi value . 23
Table 9 – Updates to existing general media transport guidelines . 26
Table 10 – Updates to existing general HTTP media transport guidelines . 27
Table 11 – Updates to existing general HTTP media transport for streaming transfer
guidelines . 34
Table A.1 – DLNA constructs of full random access data availability mode . 61
Table A.2 – DLNA constructs of limited random access data availability model . 64

62481-3 Ó IEC:2010(E) – 5 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
DIGITAL LIVING NETWORK ALLIANCE (DLNA) HOME
NETWORKED DEVICE INTEROPERABILITY GUIDELINES –

Part 3: Link protection
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC 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 National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees 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, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) 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.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62481-3 has been prepared by technical area 9: Audio, video and
multimedia applications for end-user network, of IEC technical committee 100: Audio, video
and multimedia systems and equipment.
The text of this standard is based on the following documents:
CDV Report on voting
100/1617/CDV 100/1739/RVC
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

– 6 – 62481-3 Ó IEC:2010(E)
A list of all parts of the IEC 62481 series, published under the general title Digital living
network alliance (DLNA) home networked device interoperability guidelines, can be found on
the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

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 document using a
colour printer.
62481-3 Ó IEC:2010(E) – 7 –
DIGITAL LIVING NETWORK ALLIANCE (DLNA) HOME
NETWORKED DEVICE INTEROPERABILITY GUIDELINES –

Part 3: Link protection
1 Scope
This part of IEC 62481 specifies the DLNA link protection guidelines, which are an extension
of the DLNA guidelines. DLNA link protection is defined as the protection of a content stream
between two devices on a DLNA network from illegitimate observation or interception using
the protocols defined within this standard.
Content protection is an important mechanism for ensuring that commercial content is
protected from piracy and illegitimate redistribution. Link protection is a technique that
enables distribution of protected commercial content on a home network, thus resulting in
greater consumer flexibility while still preserving the rights of copyright holders and content
providers.
The guidelines in this standard reference existing technologies for link protection and provide
mechanisms for interoperability between different implementations as well as integration with
the DLNA architecture.
This standard is organized to align with the overall structure of IEC 62481-1 and IEC 62481-2.
2 Normative reference
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
IEC 62481-1:2007, Digital living network alliance (DLNA) home networked device
interoperability guidelines – Part 1: Architecture and protocols
IEC 62481-2:2007, Digital living network alliance (DLNA) home networked device
interoperability guidelines – Part 2: DLNA media formats
ISO/IEC 13818-1:2007, Information technology – Generic coding of moving pictures and
associated audio information: Systems
ISO/IEC 13818-2:2007, Information technology – Generic coding of moving pictures and
associated audio information: Video
ISO/IEC 14496-2:2004 Information technology – Coding of audio-visual objects – Part 2:
Visual
Amendment 1 (2004), Error resilient simple scalable profile
ISO/IEC 29341-3-10:2008, Information technology – UPnP device architecture – Part 3-10:
Audio video device control protocol – Audio video transport service
ISO/IEC 29341-3-11:2008, Information technology – UPnP device architecture – Part 3-11:
Audio video device control protocol – Connection manager service

– 8 – 62481-3 Ó IEC:2010(E)
ISO/IEC 29341-3-12:2008, Information technology – UPnP device architecture – Part 3-12:
Audio video device control protocol – Content directory service
DTCP Volume 1 (informational version), Digital transmission content protection specification
Volume 1, Revision 1.4: February 28, 2005
http://www.dtcp.com/data/info 20050228 dtcp vol 1 1p4.pdf
DTCP Volume 1 Supplement E (informational version)
Mapping DTCP to IP, Revision 1.1: February 28, 2005
http://www.dtcp.com/data/info 20050228 dtcp VISE 1p1.pdf
DTCP Audio Compliance Rules EXHIBIT B-2:
Compliance rules for licensedproducts that receive or transmit commercial audio works,
June 2002
http://www.dtcp.com/data/Compliance_Rules_Audio_020610.pdf
IEEE 802.1Q, IEEE standard for information technology – Telecommunications and
information exchange between systems – IEEE standard for local and metropolitan area
networks – Common specifications – Virtual Bridged Local Area Networks
IEEE 802.11, IEEE standard for information technology – Telecommunications and
information exchange between systems – Local and metropolitan area networks-specific
requirements – Part 11: Wireless LAN Medium, Access Control (MAC) and Physical Layer
(PHY) specifications
3 Terms, definitions and acronyms
For the purposes of this document, the following terms, definitions and acronyms apply.
3.1 Terms and definition
3.1.1
authentication and key exchange
AKE
step in a link protection system where the receiving device is authenticated and given the
correct keys for the content
3.1.2
advanced system format
ASF
media format encapsulation for the transmission of content
3.1.3
audio with video
AV
any media content that contains both moving picture and sound
3.1.4
AV transport
AVT
UPnP service that provides network-based control for common transport operations such as
play, stop, pause, next, previous, and seek, a standard UPnP DCP
3.1.5
cleartext
unencrypted content stream after decryption by the upstream content protection system and
before encryption by the link protection system

62481-3 Ó IEC:2010(E) – 9 –
3.1.6
cleartext byte domain
specification of a byte position in the cleartext content stream for a complete explanation of
seek operations on link protected content, see Annex A
3.1.7
cleartext byte seek request header
used to signify any of those transport layer request headers; implies that the guideline applies
to all uses of any of the request headers
3.1.8
cleartext byte seek response header
used to signify any of those transport layer response headers; implies that the guideline
applies to all uses of any of the request headers
3.1.9
connection manager service
CMS
UPnP service that provides information about the supported transport protocols and media
formats of a UPnP device, a standard UPnP DCP
3.1.10
contributing source
CSRC
source used for the RTP media transport
3.1.11
decoder friendly aligment position
position in the bitstream defined for decoder friendly alignment; always the start of a media
format alignment element that can begin to process data without any other internal state
information about the stream so that the decoder can begin processing at that point and
create a valid output rendering
3.1.12
digital living network alliance
DLNA
organization that originally developed this standard
3.1.13
DLNA link protection
protection, using DLNA protocol elements as defined in these guidelines, of a content stream
between two devices on a DLNA network from illegitimate observation or interception
3.1.14
DLNA QoS user priority
DLNAQOS_UP
DLNA-defined QoS label used to correlate an underlying IEEE 802.1Q user priority and WMM
access category to a DLNA traffic type(s)
3.1.15
digital transmission content protection
DTCP
one of the link protection system
3.1.16
digital transmission content protection over IP networks
DTCP-IP
DTCP as applied IP based network

– 10 – 62481-3 Ó IEC:2010(E)
3.1.17
group of pictures
GOP
defined grouping of information in the MPEG 2 media format
3.1.18
hyper text transfer protocol
HTTP
protocol for transferring files across the Internet
NOTE Requires an HTTP client program on one end, and an HTTP server program on the other end.
3.1.19
link protection alignment element
unit of content carried within a link protected content stream starts with a packet header that
is defined by the link protection system and contains bytes of the link protected stream
3.1.20
link protection
protection of a content stream between two devices on a DLNA network from illegitimate
observation or interception
3.1.21
link protection system
specific collection of technologies with corresponding rules that enable secure content
transfer between two endpoints
3.1.22
media format alignment element
unit of content carried within an unprotected content stream, starts at a decoder friendly
alignment position for the given media format and contains an integral number of units of
content as defined by the media format in use
3.1.23
multipurpose internet mail extension
MIME
standard system for identifying the type of data contained in a file
NOTE MIME is an Internet protocol that allows sending binary files across the Internet as attachments to e-mail
messages. This includes graphics, photos, sound, video files, and formatted text documents.
3.1.24
network byte domain
specification of a byte position in the content stream as it is carried on the network transport
NOTE For content binaries that use a link protection system, this will include encryption and any necessary
headers or padding required by the link protection system.
3.1.25
network connectivity – power saving
NC-PS
power saving modes of operations, as defined in IEC 62481-1
3.1.26
protected content packet
PCP
packet format for DTCP-IP link protected content, as defined in DTCP Volume 1 and DTCP
Volume 1 Supplement E
62481-3 Ó IEC:2010(E) – 11 –
3.1.27
program stream
PS
content binary stream usually in reference to an MPEG-2 AV stream format
3.1.28
real time protocol
RTP
media transport that provides end-to-end network transport functions for transmitting real-time
data, such as AV
NOTE It provides services such as payload type identification, sequence numbering, time-stamping, and delivery
monitoring.
3.1.29
real time streaming protocol
RTSP
protocol within the RTP protocol suite
3.1.30
round trip time
RTT
time between sending a network packet to a remote host and the time that the response is
received
3.1.31
session description protocol
SDP
protocol within the RTP protocol suite
3.1.32
simple object access protocol
SOAP
XML based messaging protocol used to exchange service requests and responses over a
network
3.1.33
time domain
specification of a position in the content stream in time units
3.1.34
transport stream
TS
content binary stream usually in reference to an MPEG-2 AV stream format
3.1.35
uniform client data availability model
UCDAM
model for representing which bytes of a content binary are available on a server for seek
operations
NOTE See 7.5 of IEC 62481-1 for a full definition.
3.1.36
UPnP
architecture for pervasive peer-to-peer network connectivity of devices of all form factors
NOTE 1 See ISO/IEC 29341-1 for architecture description.

– 12 – 62481-3 Ó IEC:2010(E)
NOTE 2 It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged
networks whether in the home, in a small business, public spaces, or attached to the Internet. It is a distributed,
open networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity
networking in addition to control and data transfer among networked devices in the home, office, and public spaces.
3.1.37
uniform resource identifier
URI
W3C's codification of the name and address syntax of present and future objects on the
Internet
NOTE In its most basic form, a URI consists of a scheme name (such as file, http, ftp, news, mailto, gopher)
followed by a colon, followed by a path whose nature is determined by the scheme that precedes it. URI is the
umbrella term for URNs, URLs, and all other uniform resource identifiers.
3.1.38
video object unit
VOBU
defined grouping of information in the MPEG 2 media format
3.1.39
wired equivalency privacy
WEP
wireless privacy standard used in conjunction with IEEE 802.11 networks
3.1.40
Windows media audio
WMA
audio compression binary format
3.1.41
Windows media DRM for network device
WMDRM-ND
one of the link protection system
3.1.42
Windows media video
WMV
AV compression binary format
3.1.43
WiFi protected access
WPA
system to secure a wireless IEEE 802.11 network
3.1.44
WiFi protected access version 2
WPA2
system to secure a wireless IEEE 802.11 network version 2
3.2 Abbreviation terms
BNF Backus Naur Form
LWS Linear WhiteSpace
MPEG-2 Moving Picture Experts Group phase 2
MIU Media Interoperability Unit
MTU Maximum Transmission Unit
62481-3 Ó IEC:2010(E) – 13 –
UCDAM Uniform Content Data Availability Model
UPnP Universal Plug and Play
W3C World Wide Web Consortium
4 DLNA home network architecture
Refer to IEC 62481-1, Clause 4 for detailed descriptions of the DLNA home networking
architecture.
5 DLNA device model
Refer to IEC 62481-1, Clause 5 for detailed descriptions of the DLNA home networking
architecture. This standard extends the existing DLNA devices and system usages to include
link protected content used for the following:
· 2 box pull system usage;
· 2 box push system usage;
· 3 box system usage;
for the transfer and rendering of content items. These are the only system usages that are
currently in scope for the use of DLNA link protection.
6 Guideline terminology and conventions
6.1 Guideline compliance classifiers
Reference [9] provides a description of terminology conventions used in all IETF RFC
documents. The terminology and conventions used by the DLNA home networked device
interoperability guidelines are adapted from this reference. The details of each guideline will
carry a compliance classifier from the following set.
[M]ust, Required, Shall: This is the minimum set of requirements that will ensure
interoperability and/or robust operation between devices. All devices are expected to comply
with these requirements when expressed in unconditional form. A conditional requirement
expressed in the form, "If X, then Y shall be implemented", means that the requirement "Y"
shall be met when the conditional aspect "X" applies to a given implementation.
[S]hould, Recommended: Recommended items are optional items that are strongly
recommended for inclusion in products. The difference between "recommended" items and
"optional" items, see below, is one of priority. When considering features for inclusion in a
product, recommended items should be included first.
[O]ptional, May: Optional items are suggestions for features that will enhance the user
experience or are offered as a less preferred choice relative to another recommended feature.
If optional features are included, they shall comply with the requirement to ensure
interoperability with other implementations.
6.2 Standard of specification usage classifiers
When specifying guideline details, it is often useful to reiterate or clarify certain aspects of a
standard or specification that are often violated or misunderstood. Furthermore, there may be
guideline requirements that intentionally contradict or restrict implementation of certain
___________
Figures in square brackets refer to the Bibliography.

– 14 – 62481-3 Ó IEC:2010(E)
aspects of a standard or specification in order to ensure interoperability between DLNA
devices. The following classifiers are used in the DLNA home networked device
interoperability guidelines to indicate the relationship of a specific guideline requirement to a
source standard or specification:
[A]dding: A guideline requirement that adds to or supplements a standard or specification to
enhance interoperability. A guideline requirement that does not reference a standard or
specification also uses this classifier.
[C]larifying: A guideline requirement that addresses vague or ambiguous aspects of a
standard or specification.
[F]ixing: A guideline requirement that intentionally supersedes and fixes aspects of a standard
or specification that is incorrect and would otherwise provide a poor user experience or
prevent device interoperability.
[L]imiting: A guideline requirement that narrows or specifies an exact behavior in areas where
a standard or specification provides for greater degrees of latitude in implementation.
[R]epeating: A guideline requirement that repeats what is already in a standard or
specification because of observed and repeated problems with implementations. Whenever a
guideline requirement with this usage classifier seems to be in conflict with the actual
standard, the standard prevails over the guideline requirement.
6.3 Guideline font usage conventions
The following font usage conventions are used within the DLNA home networked device
interoperability guidelines to provide additional clarity.
· Hyperlinks to reference citations are indicated as [number]. For example [1], [20], …
· HTTP headers and methods are always in bold font, such as CACHE-CONTROL.
· UPnP action names are indicated as: [Service acronym]:[action name], such as CDS:
Browse.
· Special terms may be italicized. Sometimes a guideline requirement will define a term for
use within that guideline and the term will be italicized.
6.4 Guideline syntax notation convention
The following are syntax (BNF) notation conventions used within the DLNA home networked
device interoperability guidelines to provide readability.
· Linear whitespace (LWS) characters, such as carriage returns, spaces, tabs, or line feeds,
are not implied anywhere in any of the syntax (BNF) definitions used within the
interoperability guidelines.
· The use of LWS characters is restricted within the DLNA interoperability guideline unless
explicitly specified in any of the syntax definitions with reference to UPnP HTTP
communications.
· By default, text tokens and values have a case-sensitive treatment unless explicitly noted
in the guidelines. This convention also applies to BNF definitions, XML tag names, XML
tag values, capability IDs, and HTTP header values for HTTP headers used by the DLNA
guidelines. One of the exceptions to this rule applies to the names of HTTP headers.
HTTP header names have a case-insensitive treatment. For example
TimeSeekRange.dlna.org is the same as timeseekrange.dlna.org. (See IEC 62481-1,
7.5.5.2.6). Other exceptions are described in each guideline which define BNF syntax.

62481-3 Ó IEC:2010(E) – 15 –
6.5 Guideline normative and informative text conventions
All text that appears in the DLNA interoperability guidelines is to be considered normative
unless explicitly stated otherwise, such as informative references and informative appendices.
Normative text includes introductory text before guideline requirement tables, but testable
requirements are only contained within guideline requirement table entries.
6.6 DLNA XML namespaces and schemas
The DLNA interoperability guidelines make numerous references to XML elements and
attributes that are defined for DLNA device classes and device capabilities. However, these
namespaces are intentionally not defined through a formal DLNA XML schema. This allows
the DLNA interoperability guidelines to define new XML elements and attributes in the future,
without having to define a new namespace or schema definition. DLNA devices classes and
device capabilities are expected to exhibit tolerant behavior when encountering XML elements
or attributes that are defined in the future, as required by existing IEC 62481-1, 7.3.24 and
7.4.1.3.1. Table 1 lists the namespace values that are used by DLNA guidelines and the
context for their usage.
Table 1 – DLNA namespace values
Namespace value Usage context
urn:schemas-dlna-org:device-1-0 Used for XML elements and attributes defined by DLNA
interoperability guidelines for use in UPnP device
description files.
urn:schemas-dlna-org:metadata-1-0/ Used for XML elements and attributes defined by DLNA
interoperability guidelines for use in DIDL-Lite documents
and fragments.
7 Common link protection guidelines
7.1 General
This subclause contains the guidelines that are independent of the underlying link protection
system. Subclauses 7.3 through 7.8 relate to the corresponding Subclauses 7.2 to 7.7 in
IEC 62481-1. Subclause 7.9 contains information not related to that part and should be read
first to provide context for 7.3 through 7.8.
These guidelines are in a clause/subclause format as shown in Figure 1.

– 16 – 62481-3 Ó IEC:2010(E)
IEC  2344/10
Figure 1 – Guideline layout and definitions
The following list describes the content of Figure 1.
a) Name: A unique label for the guideline. The label is preceded with a sequentially
increasing number to allow easy lookup.
b) Requirements: The actual description of a guideline. A guideline is preceded with a
sequentially increasing number in each volume to allow easy lookup.
c) Attribute table: A summary of the essential attributes of a requirement. The table is a
single row with the following definitions for the columns.
· Compliance classifier: M/S/O (See 6.1 for the definition of guideline compliance
classifiers).
· The specification usage classifier: A/C/F/L/R: for the guideline. (See 6.2 for the
definition of specification usage classifiers.)
· HND device classes with device capabilities (see Table 2 and Table 3 of IEC 62481-1
for definitions). Device capabilities listed in the HND column of the attribute table.
Device capabilities can also apply equally to the MHD device category but have been
omitted from the MHD column in the attribute table to provide for better readability.
· MHD device classes (see Table 4 of IEC 62481-1 for definitions).
· HID device classes (see Table 5 of IEC 62481-1 for definitions).
· Standards citation: Standards that are referenced by the guideline. Standards citations
are by number and are referenced in Clause 2.
· Guideline unique number: an alpha-numeric string that uniquely identifies a
requirement.
· Change indicator: documents the change in the requirement that occurred since the
last edition of the guideline (see Table 2 for definitions).

62481-3 Ó IEC:2010(E) – 17 –
· Guideline attribute columns that do not have a value have the designation "n/a" (not
applicable). A visual map of possible values for the attribute tables is in Figure 2.
d) Comment: Supplementary information about a guideline such as a justification for the
guideline, the specific interoperability issue that is addressed, etc.
Note that many guidelines do not explicitly list MIU since guidelines which apply to a device
class also apply to the virtualized variants.

IEC  2345/10
Figure 2 – Visual map of possible values for the attribute tables
Table 2 – Allowed values for change indicator field in attribute table
Value Meaning
No changes in the text or figures from the immediately-preceding version of this

requirement.
A Attribute table itself, excluding the change indicator, has changed. E.g. a new device
class was added.
C Changes made to the requirement modify the testing, intent, or other normative
behavior relative to the immediately-preceding version of this requirement.
D Requirement has been deleted. These requirements are moved to the deleted
requirements document. Note that the change indicator for the requirement is marked
deleted only the first time it appears in the deleted requirements’ document; in
subsequent versions of the deleted requirements’ document the change indicator is
reset to blank.
E Changes made that do not modify testable requirements, intent, or other normative
behavior.
– 18 – 62481-3 Ó IEC:2010(E)
7.2 Conditions for measuring time in message exchanges
These guidelines define in certain cases time constraints for the exchange of messages
between two communicating endpoints. These time constraints have been defined as a means
to provide some operational consistency between the two communicating endpoints. However,
in best-effort networks, actual time measurements for exchanging messages show wide
variations depending on perturbations derived from network conditions, traffic, available
bandwidth, and others. For this reason, this subclause includes recommendations for
conditions at the time of making these measurements, as follows.
· The two communicating endpoints should establish communications under Ideal network
conditions.
· Time measurements at a given layer assume that the underlying layers preserve the
communication channel. For example, time measurements at the HTTP layer cannot be
valid if the underlying TCP
...