ISO/IEC 29341-27-1:2017

Information technology — UPnP Device Architecture — Part 27-1: Friendly device control protocol — Friendly information update service

ISO/IEC 29341-27-1:2017 is compliant with the UPnP Device Architecture version 1.0. It defines a service type referred to herein as FriendlyInfoUpdate service . It is scoped to the Device Description Document (DDD) and is a service allowing control points to create orderly updates to the and elements. Once a change has taken place the status of the DDD might not reflect that of the advertised description because the device can not leave the network during ongoing activities. Therefore a state variable is provided to indicate if the DDD contains non-advertised (pending) values. If for any reason the device goes off line, power cycles, or reboots it will most likely advertise its new DDD. If DeviceProtection UPnP DP is implemented on the device then it will support restricting control point actions to control points with specific Roles.

Technologies de l'information — Architecture de dispositif UPnP — Partie 27-1: Protocole de contrôle de dispositif convivial — Service de présence — Service convivial de mise à jour de l'information

General Information

• Status: Published
• Publication Date: 12-Sep-2017
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9093 - International Standard confirmed
• Start Date: 10-May-2025
• Completion Date: 14-Feb-2026

Overview

ISO/IEC 29341-27-1:2017 (part of the ISO/IEC 29341 UPnP Device Architecture series) defines the Friendly information update service of the Friendly Device Control Protocol. Aligned with UPnP Device Architecture 1.0, this standard specifies a service that lets UPnP control points perform orderly, moderated updates to a device’s Device Description Document (DDD) - specifically the device’s human-readable identity fields (for example, the device and ). It addresses the need to indicate pending versus advertised values while a device remains online and may be performing ongoing activities.

Key topics and technical requirements

• Service model and XML description: normative service type and XML service description for the FriendlyInfoUpdate service consistent with UPnP DCP conventions.
• State variables: definitions such as FriendlyNameStatus and FriendlyIconListStatus plus argument data types (e.g., A_ARG_TYPE_NewName, A_ARG_TYPE_IconURI, A_ARG_TYPE_Token).
• Actions: standardized operations for control points, including GetFriendlyName(), GetFriendlyIconList(), SetFriendlyName(), SetFriendlyIconList(), and RestoreFriendlyInfo().
• Eventing and moderation: event notifications and moderation rules to ensure consistent update sequencing and visibility of pending changes in the DDD.
• Security/Access control: support for DeviceProtection (UPnP DP) semantics - the standard identifies restrictable vs non-restrictable actions and allows restricting updates to control points with specific Roles.
• Error handling and state transitions: defined error codes and allowed icon/status transitions to ensure predictable device behavior during updates, reboots or network loss.
• Patent disclosures: the document records patent declarations by multiple technology companies; implementers should review intellectual property statements.

Practical applications

• Ensures consistent, race-free updates of device identity information in networked environments where devices cannot leave the network while changing attributes.
• Useful for smart home hubs, media devices, IoT endpoints, printers, gateways and any UPnP-enabled consumer electronics that advertise human-readable names or icons.
• Enables UX scenarios where remote management tools or provisioning systems update device names/icons while preserving advertised state consistency.

Who should use this standard

• UPnP device manufacturers and firmware developers implementing device description management.
• UPnP stack authors and middleware vendors adding FriendlyInfoUpdate support.
• Systems integrators and OEMs building provisioning or device-management platforms.
• Test labs and certification bodies validating UPnP DDD update behavior and DeviceProtection role-based restrictions.

Related standards

• ISO/IEC 29341 series (UPnP Device Architecture) - base DCP and other device/service parts
• UPnP Device Architecture 1.0 (original UPnP specifications)

Keywords: ISO/IEC 29341-27-1:2017, UPnP, FriendlyInfoUpdate, Device Description Document, DDD, FriendlyNameStatus, SetFriendlyName, SetFriendlyIconList, DeviceProtection, UPnP Device Architecture.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29341-27-1
First edition
2017-09
Information technology — UPnP
Device Architecture —
Part 27-1:
Friendly device control protocol —
Friendly information update service
Technologies de l'information — Architecture de dispositif UPnP —
Partie 27-1: Protocole de contrôle de dispositif convivial — Service de
présence — Service convivial de mise à jour de l'information
Reference number
©
ISO/IEC 2017
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2017 – All rights reserved

Contents
Contents . iii
List of Tables . iv
List of Figures . iv
1 Scope . v
2 Introduction . 1
3 Normative References . 1
4 Terms, definitions, symbols and abbreviated terms . 2
4.1 Provisioning terms . 2
4.1.1 conditionally allowed . 2
4.1.2 conditionally required . 2
4.1.3 not allowed . 2
4.2 Terms . 2
4.2.1 Clean . 2
4.2.2 Pending . 2
4.2.3 Friendly . 2
4.2.4 Non-Restrictable . 2
4.2.5 Restrictable . 2
4.3 Abbreviated terms . 3
4.3.1 3
4.3.2 3
5 Notations and Conventions . 3
5.1.1 Data Types . 3
5.2 Management of XML Namespaces in Standardized DCPs . 3
5.3 Vendor-defined Extensions . 3
6 Service Modeling Definitions (Normative) . 4
6.1 Service Type . 4
6.2 Security Feature . 4
6.2.1 Restrictable and Non-Restrictable actions . 4
6.3 FriendlyInfoUpdate Service Architecture . 5
6.4 State Variables . 5
6.4.1 State Variable Overview . 5
6.4.2 FriendlyNameStatus . 5
6.4.3 FriendlyIconListStatus . 6
6.4.4 A_ARG_TYPE_NewName . 9
6.4.5 A_ARG_TYPE_IconURI . 9
6.4.6 A_ARG_TYPE_UpdateType . 9
6.4.7 A_ARG_TYPE_Token . 9
6.4.8 A_ARG_TYPE_RestoreType . 9
6.5 Eventing and Moderation. 10
6.6 Actions . 10
6.6.1 GetFriendlyName() . 11
6.6.2 GetFriendlyIconList() . 11
6.6.3 SetFriendlyName() . 12
 ISO/IEC 2017 – All rights reserved iii

6.6.4 SetFriendlyIconList() . 13
6.6.5 RestoreFriendlyInfo() . 17
7 Theory of Operation (Informative) . 18
7.1 Changing the device . 18
7.2 Changing the device . 19
8 XML Service Description . 25

List of Tables
Table 6-1:  Assignment of Restrictable/Non-Restrictable Roles . 4
Table 6-2:  State Variables . 5
Table 6-3:  AllowedValueList for A_ARG_TYPE_UpdateType . 9
Table 6-4:  AllowedValueList for A_ARG_TYPE_RestoreType . 10
Table 6-5:  Eventing and Moderation. 10
Table 6-6:  Actions . 10
Table 6-7:  Arguments for GetFriendlyName() . 11
Table 6-8:  Error Codes for GetFriendlyName() . 11
Table 6-9:  Arguments for GetFriendlyIconList() . 12
Table 6-10:  Error Codes for GetFriendlyIconList() . 12
Table 6-11:  Arguments for SetFriendlyName() . 12
Table 6-12:  Error Codes for SetFriendlyName() . 13
Table 6-13:  Specific behavior for SetFriendlyIconList() upon valid input . 14
Table 6-14:  Arguments for SetFriendlyIconList() . 15
Table 2-16:  Error Codes for SetFriendlyIconList() . 16
Table 6-16:  Arguments for RestoreFriendlyInfo() . 17
Table 6-17:  Error Codes for RestoreFriendlyInfo() . 18

List of Figures
Figure 1 - Allowed icon@status transitions . 16

iv   ISO/IEC 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the 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 through technical committees established
by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non‐governmental, in liaison with
ISO and IEC, also take part in the work. In the field of information technology, ISO
and IEC have established a joint technical committee, ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further
maintenance are described in the ISO/IEC Directives, Part 1. In particular the
different approval criteria needed for the different types of document should be
noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see http://www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. ISO and IEC shall not be held responsible for
identifying any or all such patent rights. Details of any patent rights identified
during the development of the document will be in the Introduction and/or on
the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience
of users and does not constitute an endorsement.
For an explanation on the voluntary nature of Standard, the meaning of the ISO
specific terms and expressions related to conformity assessment, as well as
information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword – Supplementary
information
ISO/IEC 29341‐27‐1 was prepared by UPnP Forum and adopted, under the PAS
procedure, by joint technical committee ISO/IEC JTC 1, Information technology, in
parallel with its approval by national bodies of ISO and IEC.
The list of all currently available parts of ISO/IEC 29341 series, under the general
title Information technology — UPnP Device Architecture, can be found on the ISO
web site.
 ISO/IEC 2017 – All rights reserved v

Introduction
ISO and IEC draw attention to the fact that it is claimed that compliance with this document
may involve the use of patents as indicated below.

ISO and IEC take no position concerning the evidence, validity and scope of these patent
rights. The holders of -these patent rights have assured ISO and IEC that they are willing to
negotiate licenses under reasonable and non-discriminatory terms and conditions with
applicants throughout the world. In this respect, the statements of the holders of these patent
rights are registered with ISO and IEC.

Intel Corporation has informed IEC and ISO that it has patent applications or granted
patents.
Information may be obtained from:
Intel Corporation
Standards Licensing Department
5200 NE Elam Young Parkway
MS: JFS-98
USA – Hillsboro, Oregon 97124
Microsoft Corporation has informed IEC and ISO that it has patent applications or
granted patents as listed below:
6101499 / US; 6687755 / US; 6910068 / US; 7130895 / US; 6725281 / US; 7089307 /
US; 7069312 / US; 10/783 524 /US
Information may be obtained from:
Microsoft Corporation
One Microsoft Way
USA – Redmond WA 98052
Philips International B.V. has informed IEC and ISO that it has patent applications or
granted patents.
Information may be obtained from:
Philips International B.V. – IP&S
High Tech campus, building 44 3A21
NL – 5656 Eindhoven
NXP B.V. (NL) has informed IEC and ISO that it has patent applications or granted
patents.
Information may be obtained from:
NXP B.V. (NL)
High Tech campus 60
NL – 5656 AG Eindhoven
Matsushita Electric Industrial Co. Ltd. has informed IEC and ISO that it has patent
applications or granted patents.
Information may be obtained from:
vi   ISO/IEC 2017 – All rights reserved

Matsushita Electric Industrial Co. Ltd.
1-3-7 Shiromi, Chuoh-ku
JP – Osaka 540-6139
Hewlett Packard Company has informed IEC and ISO that it has patent applications
or granted patents as listed below:
5 956 487 / US; 6 170 007 / US; 6 139 177 / US; 6 529 936 / US; 6 470 339 / US; 6
571 388 / US; 6 205 466 / US
Information may be obtained from:
Hewlett Packard Company
1501 Page Mill Road
USA – Palo Alto, CA 94304
Samsung Electronics Co. Ltd. has informed IEC and ISO that it has patent
applications or granted patents.
Information may be obtained from:
Digital Media Business, Samsung Electronics Co. Ltd.
416 Maetan-3 Dong, Yeongtang-Gu,
KR – Suwon City 443-742
Huawei Technologies Co., Ltd. has informed IEC and ISO that it has patent
applications or granted patents.
Information may be obtained from:
Huawei Technologies Co., Ltd.
Administration Building, Bantian Longgang District
Shenzhen – China 518129
Qualcomm Incorporated has informed IEC and ISO that it has patent applications or
granted patents.
Information may be obtained from:
Qualcomm Incorporated
5775 Morehouse Drive
San Diego, CA – USA 92121
Telecom Italia S.p.A.has informed IEC and ISO that it has patent applications or
granted patents.
Information may be obtained from:
Telecom Italia S.p.A.
Via Reiss Romoli, 274
Turin - Italy 10148
Cisco Systems informed IEC and ISO that it has patent applications or granted
patents.
Information may be obtained from:
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA – USA 95134
 ISO/IEC 2017 – All rights reserved vii

Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights other than those identified above. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.

viii   ISO/IEC 2017 – All rights reserved

Original UPnP Document
Reference may be made in this document to original UPnP documents. These
references are retained in order to maintain consistency between the specifications
as published by ISO/IEC and by UPnP Implementers Corporation and later by UPnP
Forum. The following table indicates the original UPnP document titles and the
corresponding part of ISO/IEC 29341:
UPnP Document Title ISO/IEC 29341 Part
UPnP Device Architecture 1.0 ISO/IEC 29341-1:2008
UPnP Device Architecture Version 1.0 ISO/IEC 29341-1:2011
UPnP Device Architecture 1.1 ISO/IEC 29341-1-1:2011
UPnP Device Architecture 2.0 ISO/IEC 29341-1-2
UPnP Basic:1 Device ISO/IEC 29341-2
UPnP AV Architecture:1 ISO/IEC 29341-3-1:2008
UPnP AV Architecture:1 ISO/IEC 29341-3-1:2011
UPnP AVTransport:1 Service ISO/IEC 29341-3-10
UPnP ConnectionManager:1 Service ISO/IEC 29341-3-11
UPnP ContentDirectory:1 Service ISO/IEC 29341-3-12
UPnP RenderingControl:1 Service ISO/IEC 29341-3-13
UPnP MediaRenderer:1 Device ISO/IEC 29341-3-2
UPnP MediaRenderer:2 Device ISO/IEC 29341-3-2:2011
UPnP MediaServer:1 Device ISO/IEC 29341-3-3
UPnP AVTransport:2 Service ISO/IEC 29341-4-10:2008
UPnP AVTransport:2 Service ISO/IEC 29341-4-10:2011
UPnP ConnectionManager:2 Service ISO/IEC 29341-4-11:2008
UPnP ConnectionManager:2 Service ISO/IEC 29341-4-11:2011
UPnP ContentDirectory:2 Service ISO/IEC 29341-4-12
UPnP RenderingControl:2 Service ISO/IEC 29341-4-13:2008
UPnP RenderingControl:2 Service ISO/IEC 29341-4-13:2011
UPnP ScheduledRecording:1 ISO/IEC 29341-4-14
UPnP ScheduledRecording:2 ISO/IEC 29341-4-14:2011
UPnP MediaRenderer:2 Device ISO/IEC 29341-4-2
UPnP MediaServer:2 Device ISO/IEC 29341-4-3
UPnP AV Datastructure Template:1 ISO/IEC 29341-4-4:2008
UPnP AV Datastructure Template:1 ISO/IEC 29341-4-4:2011
UPnP DigitalSecurityCamera:1 Device ISO/IEC 29341-5-1
UPnP DigitalSecurityCameraMotionImage:1 Service ISO/IEC 29341-5-10
UPnP DigitalSecurityCameraSettings:1 Service ISO/IEC 29341-5-11
UPnP DigitalSecurityCameraStillImage:1 Service ISO/IEC 29341-5-12
UPnP HVAC_System:1 Device ISO/IEC 29341-6-1
UPnP ControlValve:1 Service ISO/IEC 29341-6-10
UPnP HVAC_FanOperatingMode:1 Service ISO/IEC 29341-6-11
UPnP FanSpeed:1 Service ISO/IEC 29341-6-12
UPnP HouseStatus:1 Service ISO/IEC 29341-6-13
UPnP HVAC_SetpointSchedule:1 Service ISO/IEC 29341-6-14
UPnP TemperatureSensor:1 Service ISO/IEC 29341-6-15
UPnP TemperatureSetpoint:1 Service ISO/IEC 29341-6-16
 ISO/IEC 2017 – All rights reserved ix

UPnP HVAC_UserOperatingMode:1 Service ISO/IEC 29341-6-17
UPnP HVAC_ZoneThermostat:1 Device ISO/IEC 29341-6-2
UPnP BinaryLight:1 Device ISO/IEC 29341-7-1
UPnP Dimming:1 Service ISO/IEC 29341-7-10
UPnP SwitchPower:1 Service ISO/IEC 29341-7-11
UPnP DimmableLight:1 Device ISO/IEC 29341-7-2
UPnP InternetGatewayDevice:1 Device ISO/IEC 29341-8-1
UPnP LANHostConfigManagement:1 Service ISO/IEC 29341-8-10
UPnP Layer3Forwarding:1 Service ISO/IEC 29341-8-11
UPnP LinkAuthentication:1 Service ISO/IEC 29341-8-12
UPnP RadiusClient:1 Service ISO/IEC 29341-8-13
UPnP WANCableLinkConfig:1 Service ISO/IEC 29341-8-14
UPnP WANCommonInterfaceConfig:1 Service ISO/IEC 29341-8-15
UPnP WANDSLLinkConfig:1 Service ISO/IEC 29341-8-16
UPnP WANEthernetLinkConfig:1 Service ISO/IEC 29341-8-17
UPnP WANIPConnection:1 Service ISO/IEC 29341-8-18
UPnP WANPOTSLinkConfig:1 Service ISO/IEC 29341-8-19
UPnP LANDevice:1 Device ISO/IEC 29341-8-2
UPnP WANPPPConnection:1 Service ISO/IEC 29341-8-20
UPnP WLANConfiguration:1 Service ISO/IEC 29341-8-21
UPnP WANDevice:1 Device ISO/IEC 29341-8-3
UPnP WANConnectionDevice:1 Device ISO/IEC 29341-8-4
UPnP WLANAccessPointDevice:1 Device ISO/IEC 29341-8-5
UPnP Printer:1 Device ISO/IEC 29341-9-1
UPnP ExternalActivity:1 Service ISO/IEC 29341-9-10
UPnP Feeder:1.0 Service ISO/IEC 29341-9-11
UPnP PrintBasic:1 Service ISO/IEC 29341-9-12
UPnP Scan:1 Service ISO/IEC 29341-9-13
UPnP Scanner:1.0 Device ISO/IEC 29341-9-2
UPnP QoS Architecture:1.0 ISO/IEC 29341-10-1
UPnP QosDevice:1 Service ISO/IEC 29341-10-10
UPnP QosManager:1 Service ISO/IEC 29341-10-11
UPnP QosPolicyHolder:1 Service ISO/IEC 29341-10-12
UPnP QoS Architecture:2 ISO/IEC 29341-11-1
UPnP QosDevice:2 Service ISO/IEC 29341-11-10
UPnP QosManager:2 Service ISO/IEC 29341-11-11
UPnP QosPolicyHolder:2 Service ISO/IEC 29341-11-12
UPnP QOS v2 Schema Files ISO/IEC 29341-11-2
UPnP RemoteUIClientDevice:1 Device ISO/IEC 29341-12-1
UPnP RemoteUIClient:1 Service ISO/IEC 29341-12-10
UPnP RemoteUIServer:1 Service ISO/IEC 29341-12-11
UPnP RemoteUIServerDevice:1 Device ISO/IEC 29341-12-2
UPnP DeviceSecurity:1 Service ISO/IEC 29341-13-10
UPnP SecurityConsole:1 Service ISO/IEC 29341-13-11
UPnP ContentDirectory:3 Service ISO/IEC 29341-14-12:2011
UPnP MediaServer:3 Device ISO/IEC 29341-14-3:2011
UPnP ContentSync:1 ISO/IEC 29341-15-10:2011
x   ISO/IEC 2017 – All rights reserved

UPnP Low Power Architecture:1 ISO/IEC 29341-16-1:2011
UPnP LowPowerProxy:1 Service ISO/IEC 29341-16-10:2011
UPnP LowPowerDevice:1 Service ISO/IEC 29341-16-11:2011
UPnP QoS Architecture:3 ISO/IEC 29341-17-1:2011
UPnP QosDevice:3 Service ISO/IEC 29341-17-10:2011
UPnP QosManager:3 Service ISO/IEC 29341-17-11:2011
UPnP QosPolicyHolder:3 Service ISO/IEC 29341-17-12:2011
UPnP QosDevice:3 Addendum ISO/IEC 29341-17-13:2011
UPnP RemoteAccessArchitecture:1 ISO/IEC 29341-18-1:2011
UPnP InboundConnectionConfig:1 Service ISO/IEC 29341-18-10:2011
UPnP RADAConfig:1 Service ISO/IEC 29341-18-11:2011
UPnP RADASync:1 Service ISO/IEC 29341-18-12:2011
UPnP RATAConfig:1 Service ISO/IEC 29341-18-13:2011
UPnP RAClient:1 Device ISO/IEC 29341-18-2:2011
UPnP RAServer:1 Device ISO/IEC 29341-18-3:2011
UPnP RADiscoveryAgent:1 Device ISO/IEC 29341-18-4:2011
UPnP SolarProtectionBlind:1 Device ISO/IEC 29341-19-1:2011
UPnP TwoWayMotionMotor:1 Service ISO/IEC 29341-19-10:2011
UPnP AV Architecture:2 ISO/IEC 29341-20-1
UPnP AVTransport:3 Service ISO/IEC 29341-20-10
UPnP ConnectionManager:3 Service ISO/IEC 29341-20-11
UPnP ContentDirectory:4 Device ISO/IEC 29341-20-12
UPnP RenderingControl:3 Service ISO/IEC 29341-20-13
UPnP ScheduledRecording:2 Service ISO/IEC 29341-20-14
UPnP MediaRenderer:3 Service ISO/IEC 29341-20-2
UPnP MediaServer:4 Device ISO/IEC 29341-20-3
UPnP AV Datastructure Template:1 ISO/IEC 29341-20-4
UPnP InternetGatewayDevice:2 Device ISO/IEC 29341-24-1
UPnP WANIPConnection:2 Service ISO/IEC 29341-24-10
UPnP WANIPv6FirewallControl:1 Service ISO/IEC 29341-24-11
UPnP WANConnectionDevice:2 Service ISO/IEC 29341-24-2
UPnP WANDevice:2 Device ISO/IEC 29341-24-3
UPnP Telephony Architecture:2 ISO/IEC 29341-26-1
UPnP CallManagement:2 Service ISO/IEC 29341-26-10
UPnP MediaManagement:2 Service ISO/IEC 29341-26-11
UPnP Messaging:2 Service ISO/IEC 29341-26-12
UPnP PhoneManagement:2 Service ISO/IEC 29341-26-13
UPnP AddressBook:1 Service ISO/IEC 29341-26-14
UPnP Calendar:1 Service ISO/IEC 29341-26-15
UPnP Presense:1 Service ISO/IEC 29341-26-16
UPnP TelephonyClient:2 Device ISO/IEC 29341-26-2
UPnP TelephonyServer:2 Device ISO/IEC 29341-26-3
UPnP Friendly Info Update:1 Service ISO/IEC 29341-27-1
UPnP MultiScreen MultiScreen Architecture:1
ISO/IEC 29341-28-1
UPnP MultiScreen Application Management:1 Service
ISO/IEC 29341-28-10
UPnP MultiScreen Screen:1 Device
ISO/IEC 29341-28-2
UPnP MultiScreen Application Management:2 Service
ISO/IEC 29341-29-10
 ISO/IEC 2017 – All rights reserved xi

UPnP MultiScreen Screen:2 Device
ISO/IEC 29341-29-2
UPnP IoT Management and Control Architecture Overview:1
ISO/IEC 29341-30-1
UPnP DataStore:1 Service
ISO/IEC 29341-30-10
UPnP IoT Management and Control Data Model:1 Service
ISO/IEC 29341-30-11
UPnP IoT Management and Control Transport Generic:1
Service ISO/IEC 29341-30-12
UPnP IoT Management and Control:1 Device
ISO/IEC 29341-30-2
UPnP Energy Management:1 Service ISO/IEC 29341-31-1
xii   ISO/IEC 2017 – All rights reserved

1 Scope
This service definition is compliant with the UPnP Device Architecture version 1.0. It defines a
service type referred to herein as FriendlyInfoUpdate service . It is scoped to the Device
Description Document (DDD) and is a service allowing control points to create orderly
updates to the and elements. Once a change has taken
place the status of the DDD might not reflect that of the advertised description because the
device can not leave the network during ongoing activities. Therefore a state variable is
provided to indicate if the DDD contains non-advertised (pending) values. If for any reason
the device goes off line, power cycles, or reboots it will most likely advertise its new DDD. If
DeviceProtection UPnP DP is implemented on the device then it will support restricting
control point actions to control points with specific Roles.
2 Introduction
The FriendlyInfoUpdate service is a UPnP service that enables control points to update
specific, friendly, elements of a UPnP device’s DDD. The DDD elements updateable by the
service are:


The service also describes how to reset the value to the original factory setting and in the
case of , a method for updating the actual device icon binaries using HTTP
methods. It is assumed that the device, when supporting the updating of icon binaries, will
have the means to manage image binaries, such as determining MIME image type, height,
width and color depth, as well as, negating undesired behavior associated with binary
transfers involving potential malware.
3 Normative References
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
UPnP CDS4, UPnP ContentDirectory Service version 4.0 UPnP Forum, Available
at http://upnp.org/specs/av/UPnP-av-ContentDirectory-v4-Service.pdf .
ISO/IEC 29341-1, UPnP Device Architecture, version 1.0, UPnP Forum.
Available at: http://upnp.org/specs/arch/UPnPDA10_20000613.pdf
Latest version available at: http://www.upnp.org/specs/arch/UPnP-arch-
DeviceArchitecture.pdf
UPnP DP, UPnP DeviceProtection Service, version 1, UPnP Forum. Available
at http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service.pdf .
RFC 2616, IETF RFC 2616, HyperText Transport Protocol – HTTP/1.1, R. Fielding, J. Gettys,
J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999.
Available at: http://www.ietf.org/rfc/rfc2616.txt.
XML-FIS-SCHEMA, XML Schema for FriendlyIconListStatus state variable document.
Available at: http://upnp.org/schemas/fd/fis-events.xsd.
XML-FNS-SCHEMA, – XML Schema for FriendlyNameStatus state variable document.
Available at: http://upnp.org/schemas/fd/fns-events.xsd.
XML SCHEMA-2, XML Schema Part 2: Data Types, Second Edition, Paul V. Biron, Ashok
Malhotra, W3C Recommendation, 28 October 2004.
Available at: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028.
 ISO/IEC 2017 – All rights reserved 1

4 Terms, definitions, symbols and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO/IEC 29341-1
and the following apply.
4.1 Provisioning terms
4.1.1 conditionally allowed
CA
The definition or behavior depends on a condition. If the specified condition is met,
then the definition or behavior is allowed, otherwise it is not allowed.
4.1.2 conditionally required
CR
The definition or behavior depends on a condition. If the specified condition is met,
then the definition or behavior is required, otherwise it is not allowed.
4.1.3 not allowed
The definition or behavior is prohibited by this specification. Opposite of required.
4.2 Terms
4.2.1 Clean
A notional device state scoped to this specification in which all internal states related to the
DDD are identical to its last advertised Device Description Document.
4.2.2 Pending
The pending state is a notional device state scoped to this specification in which one or more
of the internal states related to the DDD are different from its last advertised Device
Description Document.
4.2.3 Friendly
DDD element(s) which can be interpreted as human identifiable and not tied directly to the
device manufacturer information; specifically the and device icons,
defined in the element, are considered friendly.
4.2.4 Non-Restrictable
A category of action, that when the DeviceProtection UPnP DP service is implemented on the
device, cannot be blocked according to the presence or absence of a specific Role attached
to a Control Point Identity or User Identity. See UPnP CDS4 for further explanation of Role,
Control Point Identity and User Identity.
4.2.5 Restrictable
A category of actions that, when the DeviceProtection UPnP DP service is implemented on
the device, can be blocked according to the presence or absence of a specific Role attached
to a Control Point Identity or User Identity.

2  ISO/IEC 2017 – All rights reserved

4.3 Abbreviated terms
4.3.1
A
allowed
4.3.2
DDD
device description document
5 Notations and Conventions
 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 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 in multiple contexts, for example: Service::Action(), Action()::Argument,
parentProperty::childProperty.
5.1.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 ISO/IEC 29341-1. 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. The values “true”, “yes”, “false”, or “no” also
allowed to be used but are not recommended. The values “yes” and “no” are deprecated and
not allowed to be sent out by devices but shall be accepted on input.
For XML Schema defined Boolean data types, it is strongly recommended to use the value “0”
for false, and the value “1” for true. The values “true”, “yes”, “false”, or “no” may also be used
but are not recommended. The values “yes” and “no” are deprecated and not allowed to be
sent out by devices but shall be accepted on input.
5.2 Management of XML Namespaces in Standardized DCPs
This specification shall follow the conventions of the equivalent section of UPnP CDS4
where applicable.
5.3 Vendor-defined Extensions
Whenever vendors create additional vendor-defined state variables, actions or properties,
their assigned names and XML representation shall follow the naming conventions and XML
rules as specified in ISO/IEC 29341-1, Section 2.5, “Description: Non-standard vendor
extensions”.
 ISO/IEC 2017 – All rights reserved 3

6 Service Modeling Definitions (Normative)
6.1 Service Type
The following service type identifies a service that is compliant with this specification:
urn:schemas-upnp-org:service:FriendlyInfoUpdate:1
FriendlyInfoUpdate service is used herein to refer to this service type.
6.2 Security Feature
In the specification, if support for the Security Feature is referenced, this indicates that the
device implements the DeviceProtection Service UPnP DP.
6.2.1 Restrictable and Non-Restrictable actions
The FriendlyInfoUpdate service actions defined in this specification have the Restrictable,
Non-Restrictable assignments as indicated in Table 6-1.
Table 6-1: Assignment of Restrictable/Non-Restrictable Roles
Action Name Restrictable/Non-Restrictable to Indicated Role
Public Basic Admin Vendor Defined
GetFriendlyName()
NO NO NO NO
GetFriendlyIconList()
NO NO NO NO
SetFriendlyName()
YES YES NO YES
SetFriendlyIconList()
YES YES NO YES
RestoreFriendlyInfo()
YES YES NO YES
A YES value in the table indicates that the action shall be Restrictable when the Security
Feature is supported and a control point with only the Role indicated shall not have Action
level access, (see UPnP CDS4) and shall receive an error code 606 (see UPnP Device
Architecture ISO/IEC 29341-1) in response to the action invocation.
A NO value in the table indicates that the action shall be Non-Restrictable, meaning that even
if the Security Feature is supported all control points shall have Action level access when
control point invoking the action and shall not receive an error code 606 based on the
Security Feature.
4  ISO/IEC 2017 – All rights reserved

6.3 FriendlyInfoUpdate Service Architecture
This service is provided by UPnP devices to allow UPnP control points to get (read) and set
(write) the value of the  and elements of the UPnP Device
Description Document (DDD). The element is required and its value can
be found in the UPnP Device Description Document made available in the description phase.
The element is only required if one or more elements are included in
the DDD. In most cases, without this service, a UPnP control point is not able to change the
device’s or , however if there are other methods available,
this service also defines how interaction with the FriendlyInfoUpdate service state variables is
handled.
This service enables control points to get the most current and
and set them to more informative and intuitive versions such as “John’s living room TV”
instead of the default “X company Media Renderer model 123”.
The service enforces some basic timing restrictions to prevent race conditions when multiple
updates are requested in quick succession or multiple control points are interacting with the
service.
6.4 State Variables
Note: For first-time reader, it might be more insightful to read the theory of operations
first and then the action definitions before reading the state variable definitions.
6.4.1 State Variable Overview
Table 6-2: State Variables
Variable Name R/A Data Type Reference
FriendlyNameStatus R string See Section 6.4.2
FriendlyIconListStatus CR string See Section 6.4.3
A_ARG_TYPE_NewName R string See Section 6.4.4
A_ARG_TYPE_IconURI CR string See Section 6.4.5
A_ARG_TYPE_UpdateType CR string See Section 6.4.6
See Section 6.4.7
A_ARG_TYPE_Token CR string
A_ARG_TYPE_RestoreType CR See Section 6.4.8
string
R = Required, A = Allowed, CR = Conditionally Required, CA = Conditionally Allowed, X =
Non-standard, add -D when deprecated (e.g., R-D, A-D).
6.4.2 FriendlyNameStatus
This required state variable indicates the status of the DDD element value
relative to changes incurred via the FriendlyInfoUpdate service or any other method. If the
current  element value is different from the last
element value advertised in the DDD then the @status attribute shall
have a value of “DDD”, otherwise it shall have a value of “PENDING”. If the DDD
element value is changed by any other method prior to it being re-
advertised in the DDD then the new value shall also be reflected in the FriendlyNameStatus
state variable with the appropriate @status value.
 ISO/IEC 2017 – All rights reserved 5

The FriendlyNameStatus state variable is a string that contains a FriendlyNameStatus XML
Document. The following example shows a generalized “template” for the
FriendlyNameStatus XML Document. The example shows the elements that need to be filled
out by individual implmentations in the vendor character style. The Schema associated with
the FriendlyNameStatus state variable is can be found at XML-FNS-SCHEMA.

xmlns="urn:schemas-upnp-org:fd:fns-events"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schemas-upnp-org:fd:fns-events
http://www.upnp.org/schemas/fd/fns-events.xsd">

Describes the current or pending value for the DDD friendlyName



Allowed. Case sensitive.

Required. . Shall include a namespace declaration for the FriendlyInfoUpdate service
Common Datastructures Schema (“urn:schemas-upnp-org:fd:fns-events”). This is the base
wrapper element for the state variable. Shall include one of the following elements:


Required. xsd:string. Shall appear one time. The value of this element is the same as
defined in the element as defined in ISO/IEC 29341-1. The value of
this element shall not be empty.

@status
Required. xsd:string. Shall be one of the following values: “DDD“ or “PENDING”.
“DDD“ indicates that the is the same as advertised in the DDD.
“PENDING” indicates that the value has changed and is awaiting
re-advertisement of the DDD.
6.4.3 FriendlyIconListStatus
This conditionally required state variable indicates the status of the DDD
element relative to changes incurred via the FriendlyInfoUpdate service or any other method.
If the device is capable of advertising an element in its DDD then it shall
support this state variable, otherwise it is not allowed. It shall provide the complete internal
relative to the advertised DDD and is allowed to expose
additional resources for creating new icons via an element or
element. If the DDD element value is changed by any other
method prior to being re-advertised in the DDD then the new value shall also be reflected in
the FriendlyIconListStatus state variable. Note that the FriendlyIconListStatus state variable shall
always have an element present and should have at least one element
with element value “image/png” since this is recommended in ISO/IEC
29341-1.
The FriendlyIconListStatus state variable is a string that contains a FriendlyIconListStatus XML
Document. The following example shows a generalized “template” for the
FriendlyIconListStatus XML Document. The example shows the elements that need to be
filled out by individual implementations in the vendor character style. The Schema
associated with the FriendlyIconListStatus state variable is can be found at XML-FIS-SCHEMA.

xmlns="urn:schemas-upnp-org:fd:fis-events"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schemas-upnp-org:fd:fis-events
http://www.upnp.org/schemas/fd/fis-events.xsd">

!-- Describes current, complete internal device .
6  ISO/IEC 2017 – All rights reserved

Includes current DDD icons, pending updates and deletions,
and resources to create new icons -->
maxbyte="maximum size of icon in bytes"
maxheigth="maximum heigth of icon in pixels"
maxwidth="maximum width of icon in pixels"
maxdepth="maximum color depth of icon in bits">
URL to existing, deleted, or pending icon binary
image/format
vertical pixels
horizontal pixels
color depth

a device unique tag used to trigger a device HTTP-GET
of a supplied icon binary resource, only used for replacing
or creating an icon binary


a device unique tag used by a control point to authorize
an HTTP-POST (upload) of an icon binary, only used
for replacing or creating an icon binary





Allowed. Case sensitive.

Required. . Shall include a namespace declaration for the FriendlyInfoUpdate service
Common Datastructures Schema (“urn:schemas-upnp-org:fd:fis-events”). This is the base
wrapper element for the state variable. Shall include one of the following elements:


Required. . Shall appear one time. The contents of this element shall contain
one or more of the following elements:


Required. . Shall appear one or more times. Describes an existing icon (either
clean or pending) and its associated characteristics, a deleted (pending) icon, or a URI
resource where an icon can be created.

@status
Required. xsd:string. Indicates the status of the icon. Shall be one of the
following values: “DDD”, “DELETED”, “PENDING,” “OPEN”.

“DDD“ indicates that the is part of the advertised DDD and the
icon binaries are the same.
“DELETED“ indicates that the is currently part of the advertised
DDD but the and its binary are pending deletion.
“OPEN“ indicates that the is a place holder for the addition of a
new with a new icon binary.
“PENDING“ indicates that the  has been created from a previously
OPEN slot, its binary is available and it is pending advertisement in
the DDD when it is updated.
@maxBytes
Conditionally allowed. xsd:unsignedint. Shall appear zero or one time.
Indicates the maximum size (in bytes) for a new icon binary. The value
should be on a per icon basis especially if the @maxheight, @maxwidth or
@maxdepth attributes are also present. If, on the otherhand, it is a device
level limitation (and not an individual icon limitation) then it should be
uniformly updated across all icons with an @status value of “OPEN“ when
a binary is uploaded. Shall only be present if the parent has
@status attribute value of “OPEN“, otherwise it is not allowed.

@maxHeight
 ISO/IEC 2017 – All rights reserved 7

Conditionally allowed. xsd:unsignedint. Shall appear zero or one time.
Indicates the maximum vertical size (in pixels) for a new icon binary. Shall
only be present if the parent has @status attribute value of
“OPEN“, otherwise it is not allowed.

@maxWidth
Conditionally allowed. xsd:unsignedint. Shall appear zero or one time.
Indicates the maximum horizontal size (in pixels) for a new icon binary.
Shall only be present if the parent has @status attribute value of
“OPEN“, otherwise it is not allowed.

@maxDepth
Conditionally allowed. xsd:unsignedint. Shall appear zero or one time.
Indicates the maximum color depth (in bits) for a new icon binary. Shall
only be present if the parent has @status attribute value of
“OPEN“, otherwise it is not allowe
...