ISO/IEC 29341-15-10:2011

ISO/IEC 29341-15-10
Edition 1.0 2011-09
INTERNATIONAL
STANDARD
colour
inside
Information technology – UPnP device architecture –
Part 15-10: Content Synchronization Device Control Protocol – Synchronization
Service
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: 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
ISO/IEC 29341-15-10
Edition 1.0 2011-09
INTERNATIONAL
STANDARD
colour
inside
Information technology – UPnP device architecture –
Part 15-10: Content Synchronization Device Control Protocol – Synchronization
Service
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
X
ICS 35.200 ISBN 978-2-88912-655-2

29341-15-10 © ISO/IEC:2011(E)
CONTENTS
1  Overview and Scope . 4
1.1  Introduction . 4
1.1.1  ContentSync Function . 6
1.1.2  Media Server Device and ContentDirectory Service . 6
1.2  Notation . 7
1.2.1  Data Types . 8
1.3  Vendor-defined Extensions . 8
1.4  Namespace for ContentSync Service . 8
1.5  References . 8
2  Service Modeling Definitions . 10
2.1  ServiceType . 10
2.2  Terms . 10
2.2.1  Synchronization Object and Pair . 10
2.2.2  Synchronization Data Structure . 11
2.2.3  Synchronization Policy and Behav ior . 12
2.2.4  Minimally Complete Synchronization Relationship Data Structure . 15
2.3  Synchronization Data Structure Management . 16
2.3.1  Synchronization Data Structure Addition . 16
2.3.2  Synchronization Data Structure Modification . 16
2.3.3  Synchronization Data Structure Deletion . 17
2.4  Synchronization Operation (CDS to CDS) . 17
2.5  Synchronization Operation (CDS to non CDS) . 19
2.6  Garbage Colle ction . 20
2.7  State Variables . 20
2.7.1  SyncChange . 21
2.7.2  SyncStatusUpdate . 22
2.7.3  A_ARG_TYPE_ActionCaller . 28
2.7.4  A_ARG_TYPE_SyncData . 28
2.7.5  A_ARG_TYPE_SyncPair . 33
2.7.6  A_ARG_TYPE_SyncID . 33
2.7.7  A_ARG_TYPE_ObjectID . 33
2.7.8  A_ARG_TYPE_SyncStatus . 33
2.7.9  A_ARG_TYPE_ChangeLog . 34
2.7.10  A_ARG_TYPE_Index . 35
2.7.11  A_ARG_TYPE_Count . 35
2.7.12  A_ARG_TYPE_ResetObjectList . 35
2.8  Eventing and Moderation . 36
2.9  Actions . 36
2.9.1  AddSyncData() . 37
2.9.2  ModifySyncData() . 38
2.9.3  DeleteSyncData() . 40
2.9.4  GetSyncData() . 41
2.9.5  ExchangeSyncData() . 42
2.9.6  AddSyncPair() . 43
2.9.7  ModifySyncPair() . 44

XXXX: © IEC:2010 — 2 — — 2 — 29341-15-10 © ISO/IEC:2011(E)
2.9.8  DeleteSyncPair() . 45
2.9.9  StartSync() . 47
2.9.10  AbortSync() . 48
2.9.11  GetChangeLog() . 49
2.9.12 49
2.9.13  ResetChangeLog() . 50
2.9.14  ResetStatus() . 51
2.9.15 51
2.9.16  GetSyncStatus() . 52
2.9.17  Non-Standard Actions Implemented by a UPnP Vendor . 53
2.9.18  Common Error Codes . 53
2.10  Theory of Operation . 54
2.10.1  Introduction . 54
2.10.2  CDS Synchronization . 54
2.10.3  Synchronization of a Reference Ob jec t . 72
3  XML Service Description . 77
4  Test . . 82
Annex A (normative) AV Working Committee Properties . 83
A.1  Base Properties Overview . 83
A.1.1  @id . 83
A.2  Resource Encoding Characteristics Properties . 83
A.2.1  res@avcs:syncAllowed . 83
A.2.2  res@avcs:resModified . 83
A.3  Content Synchronization-related Properties . 84
A.3.1  avcs:syncable . 84
A.3.2  avcs:syncInfo . 84
A.3.3  avcs:syncInfo@updateID . 85
A.3.4  avcs:syncInfo::pair . 85
A.3.5  avcs:syncInfo::pair@syncRelationshipID . 85
A.3.6  avcs:syncInfo::pair@partnershipID . 85
A.3.7  avcs:syncInfo::pair@pairGroupID . 86
A.3.8  avcs:syncInfo::pair::remoteObjID . 86
A.3.9  avcs:syncInfo::pair::remoteParentObjID . 86
A.3.10  avcs:syncInfo::pair::virtualRemoteParentObjID . 86
A.3.11  avcs:syncInfo::pair::policy . 86
A.3.12  avcs:syncInfo::pair::status . 87
Annex B (normative) Syncable Objects and Properties . 88
B.1  Deciding Syncability of CDS Object . 88
B.2  Synchronization of CDS object properties (Informative ) . 89

Figure 1 — Content Synchronization Model . 4
Figure 2 — High-level Synchronization Flow Diagram. 5
Figure 3 — Unidirectional Contents Synchronization . 6
Figure 4 — ContentSync F unc tion . 6
Figure 5 — Types of Synchronization Pair . 11
Figure 6 — Synchronization Data Structure . 12
Figure 7 — Interaction Diagram (Synchronization Operation) . 17

29341-15-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 3 — — 3 —
Figure 8 — Synchronization Relationship between two CDSs . 55
Figure 9 — Synchronization Relationship between two CDSs . 73

Table 1-1 — Namespace Definitions . 8
Table 2-1 — State Variables . 20
Table 2-2 — Status Codes of Synchronization Operation . 27
Table 2-3 — Event Moderat ion . 36
Table 2-4 — Actions . 37
Table 2-5 — Arguments for AddSyncData() . 38
Table 2-6 — Error Codes for AddSyncData() . 38
Table 2-7 — Arguments for ModifySyncData() . 39
Table 2-8 — Error Codes for ModifySyncData() . 40
Table 2-9 — Arguments for DeleteSyncData() . 41
Table 2-10 — Error Codes for DeleteSyncData() . 41
Table 2-11 — Arguments for GetSyncData() . 41
Table 2-12 — Error Codes for GetSyncData() . 42
Table 2-13 — Arguments for ExchangeSyncData() . 42
Table 2-14 — Error Codes for ExchangeSyncData() . 42
Table 2-15 — Arguments for AddSyncPair() . 44
Table 2-16 — Error Codes for AddSyncPair() . 44
Table 2-17 — Arguments for ModifySyncPair() . 45
Table 2-18 — Error Codes for ModifySyncPair() . 45
Table 2-19 — Arguments for DeleteSyncPair() . 46
Table 2-20 — Error Codes for DeleteSyncPair() . 46
Table 2-21 — Arguments for StartSync() . 47
Table 2-22 — Error Codes for StartSync() . 48
Table 2-23 — Arguments for AbortSync() . 48
Table 2-24 — Error Codes for AbortSync() . 49
Table 2-25 — Arguments for GetChangeLog() . 50
Table 2-26 — Error Codes for GetChangeLog() . 50
Table 2-27 — Arguments for ResetChangeLog() . 51
Table 2-28 — Error Codes for ResetChangeLog() . 51
Table 2-29 — Arguments for ResetStatus() . 51
Table 2-30 — Error Codes for ResetStatus() . 52
Table 2-31 — Arguments for GetSyncStatus() . 52
Table 2-32 — Error Codes for GetSyncStatus() . 53
Table 2-33 — Common Error Codes . 53
Table 2-34 — Actions for example sequence . 56
Table A.1 — Content Synchronization-related Properties Overview . 84
Table B.1 — Syncability of CDS object cla ss . 88
Table B.2 — Syncability of CDS Object property . 90

29341-15-10  ISO/IEC:2011(E) – 2 – 29341-15-10 © ISO/IEC:2011(E)
INFORMATION TECHNOLOGY –
UPNP DEVICE ARCHITECTURE –
Part 15-10: Content Synchronization Device Control
Protocol – Synchronization Service
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-15-10 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.
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-15-10 © ISO/IEC:2011(E) – 3 – 29341-15-10  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.

XXXX: © IEC:2010 — 4 — 29341-15-10 © ISO/IEC:2011(E)
1 Overview and Scope
This service definition is compliant with the UPnP Device Architecture version 1.0.
1.1 Introduction
Content Synchronization service enables two or more ContentDirectory services [CDS] to
synchronize content with each other. This service also enables a UPnP control point to
synchronize content with a ContentDirectory service. We refer this service as “CSS” or
“ContentSync service” from hereon. If a CDS wants to support synchronization of objects and
its resources with other CDSs, the implementation MUST enable this ContentSync service
(CSS). CSS keeps change log as part of CDS object property that describe which CDS
objects are added or modified or deleted since it has synchronized last. Since
synchronization enables interaction between ContentSync services, each service has a
Control Point (CP) functionality that invokes actions to other ContentSync service to achieve
synchronization of contents with each other.

Figure 1 — Content Synchronization Model
Figure 1 shows how synchronization is accomplished between two CSSs. In the figure above,
a stand alone control point is managing the synchronization between two CSSs. This includes
management of content synchronization data structure (i.e., creating, browsing and deleting
of synchronization data structure) and invocation of synchronization operation, etc. An
embedded control point in the CSS has the role of performing the actual synchronization of
objects which include retrieving the change log for objects that have changed, monitoring the
status of the other CSS and updating the synchronization data structure when an object is
successfully synchronized etc.
Figure 2 shows a high-level flow diagram of how Content Sync services, ContentDirectory
services and Control Point interact with each other to achieve content synchronization.
Firstly, a stand-alone control point (controlled by a user) creates a synchronization
relationship that describes which devices to participate in the synchronization, which objects

29341-15-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 5 — 29341-15-10 © ISO/IEC:2011(E)
are to be synchronized, and how to resolve conflicts and so on. When the control point
creates a synchronization relationship, it MUST be responsible to define valid information for
the CSS. If the synchronization relationship is successfully created, the CDS implementation
that supports CSS MUST keep track of change log of the objects that are subject to
synchronization. When a synchronization relationship is created between two devices,
identical synchronization data structure information is maintained in both devices.
Once a synchronization relationship is created, a stand-alone control point can trigger a
synchronization operation on either of CSSs. If the CSS is ready to synchronize (i.e.
successfully respond to the trigger from the stand-alone control point), the embedded control
point in the CSS retrieves change log from the other partner device.
After obtaining the change log, the CSS parses and interprets the change log. The CSS then
updates the CDS by retrieving object information from the partner device based on the
change log and the rule defined in this specification. In this step, the CSS notifies the CSS of
the partner device whenever an object in the change log is dealt with regardless of success
or failure. If successful update for an object is notified, the CSS implementation MUST clear
the change log for that object and the CDS must keep track of new change log since this last
synchronization.
Figure 2 — High-level Synchronization Flow Diagram
The ContentSync service also provides a functionality by which a control point can only track
changes of objects that the control point is interested in. This functionality is helpful for
unidirectional synchronization. Figure 3 shows such a scenario. In this scenario, a control
point with its own local storage (not compliant to CDS) can synchronize with a CDS by its
own local policy. In other words, the control point does not follow any policies that are
defined in this specification. The control point creates synchronization relationship
information on a CDS with its interest for the CDS to track some objects. The CDS keeps
change log for the objects the control point is interested. Therefore, an embedded control
point in the CSS is disabled for this type of synchronization. Subclause 2.5 explains in details
how this kind of unidirectional synchronization can be achived.

XXXX: © IEC:2010 — 6 — 29341-15-10 © ISO/IEC:2011(E)

Figure 3 — Unidirectional Contents Synchronization
1.1.1 ContentSync Function
Figure 4 — ContentSync Function
The Content Sync function is an essential part of the Content Synchronization. This function
is a combination of a ContentSync service and a Content Sync CP in a CSS as shown in
Figure 4.
ContentSync Service:
ContentSync service is responsible for managing synchronization data structure and
performing synchronization operation with a partner CSS.
ContentSync CP:
The ContentSync CP provides Control Point functionality that controls other ContentSync
service running on the network.
The interface between the ContentSync CP and the ContentSync service is device-dependent
and not defined by the UPnP ContentSync Service specifications.
1.1.2 Media Server Device and ContentDirectory Service
Since a ContentSync service provides the functionality to synchronize ContentDirectory
service objects, ContentSync service implementation MUST appear together with
ContentDirectory service implementation and MUST be also deployed on an UPnP Media
Server device [MSD] that supports synchronization. Therefore, a Media Server

29341-15-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 7 — 29341-15-10 © ISO/IEC:2011(E)
implementation MUST expose an XML device description document which contains
description of both ContentSync service and ContentDirectory service when the Media Server
implementation supports synchronization of CDS objects.
The following device type identifies a Media Server device that is compliant with this
specification:
urn:schemas-upnp-org:device:MediaServer:2
The following service type identifies a ContentDirectory service that is compliant with this
specification:
urn:schemas-upnp-org:service:ContentDirectory:2
To enable synchronization of CDS objects, this specification imposes additional requirements
on ContentDirectory:2 service specification. When supporting synchronization of CDS objects,
these additional requirements MUST be implemented on top of ContentDirectory:2 service
implementation. See Annex A for the additional requirements on ContentDirectory:2
service specification (especially CDS properties of ContentDirectory:2 service).
Additionally, since this specification adds extended properties to CDS, the AVCS XML
schema [AVCS-XSD] for those properties is specified in this specification, not in UPnP AV. In
other words, a CDS object expressed by original DIDL-Lite XML document MUST also refer
to the AVCS XML schema when the new properties are added to the object. (The schema of
the DIDL-Lite XML document does not have any reference to the AVCS XML schema). Note
that the schema is informative only and hence the XML data types defined in this
specification take precedence over all the XML schemas.
1.2 Notation
• In this document, features are described as Required, Recommended, or Optional as
follows:
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 [RFC 2119].
In addition, the following keywords are used in this specification:
PROHIBITED – The definition or behavior is an absolute prohibition of 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 ContentSync and AV Working Committee are
printed using the forum character style.
• Keywords that are defined by the UPnP Device Architecture are printed using the arch
character style.
• 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

XXXX: © IEC:2010 — 8 — 29341-15-10 © ISO/IEC:2011(E)
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.
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 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.3 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 in [DEVICE]
1.4 Namespace for ContentSync Service
All data types represented by XML document in this specification MUST use the following
namespaces and XML schemas. Note that this schema is informative only and hence the
XML data types defined in this specification take precedence over the XML schema.
Table 1-1 — Namespace Definitions
Standar Normative
d Name- Definition
space Document
Prefix Namespace Name Namespace Description Reference
cs: urn:schemas-upnp-org:cs Common data types for [CSS-XSD]
use in ContentSync
Reference:
schema
http://www.upnp.org/schemas/cs/cs-v1-
2007xxxx.xsd
avcs: urn:schemas-upnp-org:cs:avcs Metadata for UPnP AV [AVCS-XSD]
CDS
Reference:
http://www.upnp.org/schemas/cs/avcs-v1-
2007xxxx.xsd
1.5 References
[RFC 2119] – IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S.
Bradner, 1997.
[RFC 4122] – IETF RFC 4122, A Universally Unique Identifier (UUID) URN Namespace, P.
Leach, et. al., 2005.
[CDS] – ContentDirectory:2, UPnP Forum, May 31, 2006.

29341-15-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 9 — 29341-15-10 © ISO/IEC:2011(E)
[DIDL-LITE-XSD] – XML Schema for ContentDirectory:2 Structure and Metadata (DIDL-Lite),
UPnP Forum, May 31, 2006.
[CSS-XSD] – XML Schema for ContentSync Service:1, UPnP Forum, July 26, 2007.
[AVCS-XSD] – XML Schema for additional CDS Object Properties of ContentSync Service:1,
UPnP Forum, July 26, 2007.
[DEVICE] – UPnP Device Architecture, version 1.0, UPnP Forum, June 13, 2000.
[XML] – Extensible Markup Language (XML) 1.0 (Third Edition), François Yergeau, Tim Bray,
Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, eds., W3C Recommendation, February 4,
2004.
[XML SCHEMA-2] – XML Schema Part 2: Data Types, Second Edition, Paul V. Biron, Ashok
Malhotra, W3C Recommendation, 28 October 2004.
[MSD] – MediaServer:2, UPnP Forum, May 31, 2006.

XXXX: © IEC:2010 — 10 — 29341-15-10 © ISO/IEC:2011(E)
2 Service Modeling Definitions
2.1 ServiceType
The following service type identifies a service that is compliant with this template:
urn:schemas-upnp-org:service:ContentSync:1.
2.2 Terms
2.2.1 Synchronization Object and Pair
A CDS object that is to be synchronized is called a synchronization object.
A synchronization pair represents a binding between a synchronization object in the local
device and a synchronization object in the partner device. This binding information is stored
in the avcs:syncInfo property of the synchronization objects. The avcs:syncInfo property for
an object also keeps information related to which property or resource has been changed for
that object since the object synchronized last with a remote object. This property MUST be
updated whenever there is a change to that object. Therefore, any change to avcs:syncInfo
property MUST not be perceived as object change. See Annex A and Annex B for details
on synchronization object property. It is possible that an object that is new or yet to be
synchronized does not have the corresponding remote object. In that case the remote object
gets created in the partner device during the synchronization operation if specified by the
policy. When creating a synchronization pair for an object, one of the three possible
scenarios as shown in Figure 5 will occur.
• Scenario 1: an (local) object is paired with an existing remote object in the partner device.
• Scenario 2: the local object does not have a corresponding remote object in the partner
device and the remote object gets created under an exsiting container object in the
partner device which is designated by the control point. The existing container object here
is called as Remote Parent Object.
• Scenario 3: This is similar to scenario 2, however the remote parent object under which
the remote object will be created does not exist either and it gets created along with the
remote object during the synchronization operation. In scenario 3, the remote parent
object that will be created MUST be paired with the parent object of the local object which
is called as Virtual Remote Parent Object.

29341-15-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 11 — 29341-15-10 © ISO/IEC:2011(E)

Figure 5 — Types of Synchronization Pair
The avcs:syncInfo property for an object can have multiple synchronization pair information
if the object is paired with multiple remote objects in different devices. In such case, there are
some restrictions that MUST be followed. See 2.9.6 AddSyncPair() action for details.
2.2.2 Synchronization Data Structure
A Synchronization Data Structure consists of the following information.
• Synchronization PairGroup is the data structure that identifies a group of
synchronization pairs where identical synchronization policy will be applied. The actual
synchronization pair information describing which object in the local CDS is paired with an
object in the partner CDS is contained in the object itself as part of object property.
• Synchronization Partnership is the data structure that describes a synchronization
operation between two specific CDSs. These two CDSs are called partners. A
synchronization partnership contains multiple synchronization pairGroups. A
synchronization partnership contains policy information that is applicable to all the
pairGroups contained within that partnership. If a pairGroup has its own policy information
then the pairGroup policy overrides partnership policy for that specific pairGroup.
• Synchronization Relationship is the data structure that describes a synchronization
operation between two or more CDSs. A synchronization relationship is composed of one
or more synchronization partnerships and each partnership is composed of one or more
synchronization pairGroups.
Figure 6 shows an example synchronization data structure with all its components.
The synchronization data structure allows an object in one device to synchronize with an
object in another device. Every syncable object in CDS has synchronization pair information

XXXX: © IEC:2010 — 12 — 29341-15-10 © ISO/IEC:2011(E)
that describes how the object gets synchronized with another object. See Clause 2.2.3
Synchronization Policy for more details.
A synchronization relationship or a partnership or a pairGroup is identified by a unique ID.
Regardless of disappearance/reappearance of this service on the network, the
implementations that support ContentSync service implementations MUST maintain the same
value for these IDs in the CDS over its life-time. The value once used MUST be never re-
used. In order to make the value of this state variable globally unique, it must be generated
using GUID as defined in [RFC 4122]. A GUID is 128 bits long, and can guarantee
uniqueness across space and time.
Structurally, single synchronization relationship can have multiple partnerships by definition.
However, this version of the specification allows only one partnership within a
synchronization relationship as shown in Figure 6. But, multiple pairGroups within a
partnership are allowed in this version of the specification. For example, the synchronization
relationship, S2, is only effective one in the figure below.

Figure 6 — Synchronization Data Structure

2.2.3 Synchronization Policy and Behavior
A synchronization policy indicates how synchronization partners that are involved in a
synchronization relationship can exchange synchronization objects. In general, a
synchronization policy indicates which device should provide metadata and resources to
which device. There are four types of policies defined which is explained below:
2.2.3.1 “replace” synchronization policy
In “replace” synchronization policy, one of the synchronization partners becomes the source
and the other becomes the sink. The purpose of “replace” synchronization is to make a sink
identical to the source. That is, contents of the sink objects are replaced with the contents of
the source. The terms source and sink are merely conceptual between the synchronization
pair.
The behavior of “replace” synchronization policy is as follows.
• The object added to the source which does not have any corresponding object in the sink
MUST be copied to the sink.
• Any modification, including deletion, to the existing objects in the source will be applied to
the corresponding objects in the sink. To protect an object in the sink from deletion by
synchronization, this object MUST be marked as deletion protected in the synchronization

29341-15-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 13 — 29341-15-10 © ISO/IEC:2011(E)
policy. The protected object will not be deleted after synchronization, and will be excluded
from the relationship.
Note1: There should not be any object in the sink in a relationship that does not have a
corresponding object in the source.
Note2: Any changes in the sink are not useful, as these will be replaced by the source. To
retain changes in an object in the sink, the object should be excluded from the relationship or
it needs to be copied before synchronization.
2.2.3.2 “merge” synchronization policy
The “merge” synchronization policy defines that after synchronization, each partner will end
up with a superset of synchronization objects of all the partners. In other words, the
synchronization objects from all  the partners will be merged according to the following rules:
• An object added to a synchronization partner that does not have any corresponding object
in the other partner will be copied to the other partner.
• Any metadata or resources that are missing on either partner that missing data is copied
to the other partner. If an object and its corresponding object have the same properties
with different values, then the values of properties of the partner with higher precedence
will be copied to the other partner.
2.2.3.3 “blend” synchronization policy
The “blend” synchronization policy defines that after synchronization, each partner will end
up with a superset of synchronization objects of all the partners. In other words, the
synchronization objects from all  the partners will be blended according to the following
rules:
• An object added to a synchronization partner that does not have any corresponding object
in the other partner will be copied to the other partner.
• Any metadata or resources that are missing on either partner that missing data is copied
to the other partner. If an object and its corresponding object have the same properties
with different values, then the values are left as is on both partners.
2.2.3.4 “tracking” synchronization policy
A “tracking” synchronization policy is useful only when synchronizing between a CDS and a
non-CDS device. The actual synchronization operation for this policy is out of the scope of
this specification. In this policy, only the device having a CDS keeps track of the change log
for synchronization objects. The device clears the change log by invocation of the
ResetChangeLog() action and starts keeping new log from that point. The device stops
keeping change log when the synchronization relationship is destroyed.
The behavior of “tracking” synchronization policy is as follows.
• A new object is automatically added to a synchronization pairGroup of its parent object if
the parent object (container) of the newly
...