EN 62676-2-2:2014

Video surveillance systems for use in security applications - Part 2-2: Video transmission protocols - IP interoperability implementation based on HTTP and REST services

IEC 62676-2-2:2013 specifies a compliant IP video protocol based on HTTP and REST services. Video transmission devices are often equipped with web servers that respond to HTTP requests. The HTTP response may contain XML content (for GET actions), XML response information (for SET actions), or various text/binary content (for retrieval of configuration data, etc.). REST is an approach to creating services that expose all information as resources in a uniform way. A video transmission device supporting compliance to the requirements of this standard based on HTTP and REST Services as described in this document is declared as compatible to ´IEC 62676-2 HTTP and REST interoperability.´

Videoüberwachungsanlagen für Sicherungsanwendungen - Teil 2-2: Videoübertragungsprotokolle - IP-Interoperabilität auf Basis von HTTP- und REST-Diensten

Systèmes de vidéosurveillance destinés à être utilisés dans les applications de sécurité - Partie 2-2: Protocoles de transmission vidéo - Mise en oeuvre de l'interopérabilité IP en fonction des services HTPP et REST

La CEI 62676-2-2:2013 spécifie un protocole vidéo IP reposant sur les services HTTP et REST. Les dispositifs de vidéotransmission sont souvent équipés de serveurs web qui répondent aux requêtes HTTP. La réponse HTTP peut posséder un contenu XML (pour les actions GET), des informations de réponse XML (pour les actions SET) ou divers contenus texte/binaire (pour l'extraction de données de configuration, etc.). REST est une approche de création de services qui expose uniformément toutes les informations sous forme de ressources. Un dispositif de vidéotransmission satisfaisant aux exigences de la présente Norme sur la base des services HTTP et REST tel que décrit dans le présent document est déclaré comme étant compatible avec 'l'interopérabilité HTTP et REST de la CEI 62676-2'.

Video nadzorni sistemi za varnostne aplikacije - 2-2. del: Protokoli video prenosa - Medobratovalnost IP, temelječa na storitvah HTTP in REST (IEC 62676-2-2:2013)

General Information

• Status: Published
• Publication Date: 16-Jan-2014
• Withdrawal Date: 11-Dec-2016
• ICS: 13.320 - Alarm and warning systems
• Technical Committee: CLC/TC 79 - Alarm systems
• Drafting Committee: IEC/TC 79 - IEC_TC_79
• Current Stage: 6060 - Document made available - Publishing
• Start Date: 17-Jan-2014
• Completion Date: 17-Jan-2014
• Ref Project: SIST EN 62676-2-2:2014 - Video surveillance systems for use in security applications - Part 2-2: Video transmission protocols - IP interoperability implementation based on HTTP and REST services

Relations

• Replaces: EN 50132-5-2:2011/AC:2012 - Alarm systems - CCTV surveillance systems for use in security applications - Part 5-2: IP Video Transmission Protocols
• Effective Date: 29-Jan-2023

Standards Content (Sample)

SLOVENSKI STANDARD
01-marec-2014
9LGHRQDG]RUQLVLVWHPL]DYDUQRVWQHDSOLNDFLMHGHO3URWRNROLYLGHRSUHQRVD
0HGREUDWRYDOQRVW,3WHPHOMHþDQDVWRULWYDK+773LQ5(67,(&
Video surveillance systems for use in security applications - Part 2-2: Video transmission
protocols - IP interoperability implementation based on HTTP and REST services
Systèmes de video surveillance appliqués à la sécurité -ePartie 2-2: Protocoles de
transmission video sous IP - Implémentation de l’interopérabilité fondée sur les services
http et REST
Ta slovenski standard je istoveten z: EN 62676-2-2:2014
ICS:
13.320 Alarmni in opozorilni sistemi Alarm and warning systems
33.160.40 Video sistemi Video systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 62676-2-2
NORME EUROPÉENNE
January 2014
EUROPÄISCHE NORM
ICS 13.320
English version
Video surveillance systems for use in security applications -
Part 2-2: Video transmission protocols -
IP interoperability implementation based on HTTP and REST services
(IEC 62676-2-2:2013)
Systèmes de vidéosurveillance destinés à Videoüberwachungsanlagen für
être utilisés dans les applications de Sicherungsanwendungen -
sécurité - Teil 2-2: Videoübertragungsprotokolle -
Partie 2-2: Protocoles de transmission IP-Interoperabilität auf Basis von HTTP-
vidéo - und REST-Diensten
Mise en oeuvre de l'interopérabilité IP en (IEC 62676-2-2:2013)
fonction des services HTPP et REST
(CEI 62676-2-2:2013)
This European Standard was approved by CENELEC on 2013-12-12. CENELEC members are bound to comply
with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard
the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the CEN-CENELEC Management Centre or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and notified
to the CEN-CENELEC Management Centre has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus,
the Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

CEN-CENELEC Management Centre: Avenue Marnix 17, B - 1000 Brussels

© 2014 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 62676-2-2:2014 E
Foreword
The text of document 79/436/FDIS, future edition 1 of IEC 62676-2-2, prepared by IEC TC 79 "Alarm and
electronic security systems" was submitted to the IEC-CENELEC parallel vote and approved by
CENELEC as EN 62676-2-2:2014.
The following dates are fixed:
(dop) 2014-09-12
• latest date by which the document has
to be implemented at national level by
publication of an identical national
standard or by endorsement
• latest date by which the national (dow) 2016-12-12
standards conflicting with the

document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such patent
rights.
Endorsement notice
The text of the International Standard IEC 62676-2-2:2013 was approved by CENELEC as a European
Standard without any modification.

- 3 - EN 62676-2-2:2014
Annex ZA
(normative)
Normative references to i nternational publications
with their corresponding European publications

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.

NOTE  When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year

ISO 10918-1 - Information technology - Digital compression - -
and coding of continuous-tone still images:
Requirements and guidelines
ISO/IEC 11172-3 1993 Information technology - Coding of moving - -
pictures and associated audio for digital
storage media at up to about 1,5 Mbit/s -
Part 3: Audio
ISO/IEC 13818-2 - Information technology - Generic coding of - -
moving pictures and associated audio
information -
Part 2: Video
ISO/IEC 14496-2 2004 Information Technology – Coding of audio- - -
visual objects -
Part 2: Visual
ISO/IEC 14496-3 - Information technology - Coding of audio- - -
visual objects -
Part 3: Audio
ISO/IEC 14496-10 2012 Information technology - Coding of audio- - -
visual objects -
Part 10: Advanced Video Coding

IETF RFC 1213 - Management Information Base for Network - -
Management of TCP/IP-based Internets: MIB-
II
IETF RFC 1945 - Hypertext Transfer Protocol – HTTP/1.0, T. - -
Berners-Lee, MIT/LCS, R. Fielding, UC Irvine,
H. Frystyk
IETF RFC 2046 - Multipurpose Internet Mail Extensions (MIME) - -
- Part 2: Media Types
IETF RFC 2250 - RTP Payload Format for MPEG1/MPEG2 - -
Video
IETF RFC 2326 - Real time Streaming protocol (RTSP) - -
IETF RFC 2435 - RTP Payload Format for JPEG-compressed - -
Video
IETF RFC 2616 - Hypertext Transfer Protocol HTTP/1.1. - -
IETF RFC 2617 - HTTP Authentication: Basic and Digest - -
Access Authentication
Publication Year Title EN/HD Year
IETF RFC 2818 - HTTP Over TLS - -

IETF RFC 3016 - RTP Payload Format for MPEG-4 - -
Audio/Visual Streams
IETF RFC 3550 - A Transport Protocol for Real-Time - -
Applications
IETF RFC 3551 - RTP Profile for Audio and Video Conferences - -
with Minimal Control
IETF RFC 3629 - UTF-8, a transformation format of ISO 10646 - -

IETF RFC 3640 - RTP Payload Format for Transport of MPEG-4 - -
Elementary Streams
IETF RFC 3984 - RTP Payload Format for H.264 Video - -
IETF RFC 4566 - SDP: Session Description Protocol - -
ITU-T - 40, 32, 24, 16 kbit/s Adaptive Differential - -
Recommendation Pulse Code Modulation (ADPCM)
G.726
ITU-T - Advanced video coding for generic - -
Recommendation audiovisual services
H.264
ITU-T - Information technology - Digital compression - -
Recommendation and coding of continuous-tone still images -
T.81 Requirements and guidelines

IEC 62676-2-2 ®
Edition 1.0 2013-11
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Video surveillance systems for use in security applications –

Part 2-2: Video transmission protocols – IP interoperability implementation

based on HTTP and REST services

Systèmes de vidéosurveillance destinés à être utilisés dans les applications

de sécurité –
Partie 2-2: Protocoles de transmission vidéo – Mise en œuvre de

l'interopérabilité IP en fonction des services HTTP et REST

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX XF
ICS 13.320 ISBN 978-2-8322-1188-5

– 2 – 62676-2-2  IEC:2013
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Abbreviations . 8
4 Overview . 10
5 Design considerations . 10
5.1 General . 10
5.2 REST overview . 11
5.3 Conformance . 11
5.3.1 General . 11
5.3.2 Minimum API set . 11
5.3.3 XML requirements . 11
5.3.4 Protocol requirements. 12
5.4 HTTP methods and REST . 12
5.5 HTTP status codes and REST . 12
5.6 Unique identifiers . 14
5.7 ID encoding . 14
6 Architecture and namespace . 15
7 System flow . 17
7.1 General . 17
7.2 Service discovery . 18
7.3 Persistent connections . 18
7.4 Authentication . 19
7.5 Access restrictions . 19
7.6 Setting configurations . 20
7.7 Getting configurations . 20
7.8 Getting capabilities . 21
7.9 Uploading data . 22
7.10 Receiving data . 22
7.11 Operations . 22
7.12 Diagnostics . 23
7.13 Response status . 23
7.13.1 General . 23
7.13.2 Status code . 23
7.13.3 Status string . 24
7.13.4 ID . 24
7.14 Processing rules . 24
8 XML modeling . 24
8.1 File format . 24
8.2 Data structures . 24
8.3 Lists . 24
8.4 Capabilities . 24
9 Custom services and resources . 26
10 Interface design . 26
10.1 General . 26

62676-2-2  IEC:2013 – 3 –
10.2 Protocol . 26
10.3 Hostname . 27
10.4 Port . 27
10.5 URI . 27
10.6 Query string . 27
10.7 Resource description . 27
11 Standard resource descriptions . 28
11.1 General . 28
11.2 index . 28
11.3 indexr . 28
11.4 description . 29
11.5 capabilities . 29
11.6 Schemas . 29
11.6.1 General . 29
11.6.2 ResourceDescription . 30
11.6.3 ResourceList . 30
11.6.4 QueryStringParameterList . 30
11.6.5 responseStatus . 30
11.6.6 service.xsd . 31
Annex A (normative) IP Media Device API Specification Version 1.0 . 34
Bibliography . 122

Figure 1 – PSIA service architecture example . 15
Figure A.1 – Motion detection grid with two detection regions . 108

Table 1 – HTTP methods . 12
Table 2 – HTTP status codes and REST . 13
Table 3 – Resource names . 16
Table 4 – Service URLs . 16
Table 5 – HTTP requests . 23
Table 6 – Capability attributes . 25

– 4 – 62676-2-2  IEC:2013
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
VIDEO SURVEILLANCE SYSTEMS FOR USE
IN SECURITY APPLICATIONS –
Part 2-2: Video transmission protocols –
IP interoperability implementation based
on HTTP and REST services
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 62676-2-2 has been prepared by IEC technical committee 79:
Alarm and electronic security systems.
The text of this standard is based on the following documents:
FDIS Report on voting
79/436/FDIS 79/449/RVD
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.

62676-2-2  IEC:2013 – 5 –
A list of all parts in the IEC 62676 series, published under the general title Video surveillance
systems for use in security applications, 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.
– 6 – 62676-2-2  IEC:2013
INTRODUCTION
The IEC Technical Committee 79 in charge of alarm and electronic security systems together
with many governmental organisations, test houses and equipment manufacturers have
defined a common framework for video surveillance transmission in order to achieve
interoperability between products.
The IEC 62676 series of standards on video surveillance system is divided into 4 independent
parts:
Part 1 System requirements
Part 2: Video transmission protocols
Part 3: Analog and digital video interfaces
Part 4 : Application guidelines (to be published)
Each part has its own clauses on scope, references, definitions and requirements
This IEC 62676-2 series consists of 3 subparts, numbered parts 2-1, 2-2 and 2-3 respectively:
IEC 62676-2-1, Video transmission protocols – General requirements
IEC 62676-2-2, Video transmission protocols – IP interoperability implementation based on
HTTP and REST services
IEC 62676-2-3, Video transmission protocols – IP interoperability implementation based on
Web services
This second subpart of this IEC 62676-2 series covers IP interoperability implementation
based on HTTP and REST services. It is based on the requirements for IP video transmission
protocols covered in IEC 62676-2-1, which defines protocol requirements to be fulfilled by any
high-level IP video device interface.

62676-2-2  IEC:2013 – 7 –
VIDEO SURVEILLANCE SYSTEMS FOR USE
IN SECURITY APPLICATIONS –
Part 2-2: Video transmission protocols –
IP interoperability implementation based
on HTTP and REST services
1 Scope
This part of IEC 62676 specifies a compliant IP video protocol based on HTTP and REST
services.
Video transmission devices are often equipped with web servers that respond to HTTP
requests. The HTTP response may contain XML content (for GET actions), XML response
information (for SET actions), or various text/binary content (for retrieval of configuration data,
etc.). REST is an approach to creating services that expose all information as resources in a
uniform way. The ease of using REST is its uniform interface for operations. Since everything
is represented as a resource, create, retrieve, update, and delete (CRUD) operations use the
same URI. This specification leverages the features of HTTP and REST for IP video
transmission.
A video transmission device supporting compliance to the requirements of this standard
based on HTTP and REST Services as described in this document is declared as compatible
to ´IEC 62676-2 HTTP and REST interoperability.´
2 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.
ISO/IEC 10918-1, Information technology – Digital compression and coding of continuous-
tone still images: Requirements and guidelines
ISO/IEC 11172-3:1993, Information technology – Coding of moving pictures and associated
audio for digital storage media at up to about 1,5 Mbit/s – Part 3: Audio
ISO/IEC 13818-2, 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
ISO/IEC 14496-3, Information technology – Coding of audio-visual objects – Part 3: Audio
ISO/IEC 14496-10:2012, Information technology – Coding of audio-visual objects – Part 10:
Advanced video coding
IETF RFC 1213, Management Information Base for Network Management of TCP/IP-based
internets: MIB-II
– 8 – 62676-2-2  IEC:2013
IETF RFC 1945, Hypertext Transfer Protocol – HTTP/1.0
IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
IETF RFC 2250, Format de charge utile RTP pour la video MPEG1/MPEG2
IETF RFC 2326, Real Time Streaming Protocol (RTSP)
IETF RFC 2435, Format de charge utile RTP pour l video JPEG
IETF RFC 2616, Hypertext Transfer Protocol – HTTP/1.1
IETF RFC 2617, HTTP Authentication: Basic and Digest Access Authentication
IETF RFC 2818, HTTP Over TLS
IETF RFC 3016, Format de charge utile RTP pour flux audio/video MPEG-4
IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications
IETF RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control
IETF RFC 3629, UTF-8 un format de transformation de l’ISO 10646
IETF RFC 3640, Format de charge utile RTP pour le transport de flux élémentaires MPEG-4
IETF RFC 3984, Format de charge utile RTP pour video H.264
IETF RFC 4566, SDP: Session Description Protocol
ITU-T Recommendation G.726, 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code
Modulation (ADPCM)
ITU-T Recommendation H.264, Advanced video coding for generic audiovisual services
ITU-T Recommendation T.81, Information technology – Digital compression and coding of
continuous-tone still images – Requirements and guidelines
3 Abbreviations
For the purposes of this document, the following abbreviations apply.
AAC Advanced Audio Coding
API Application Program Interface
AVP Audio/Video Profile
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol over Secure Socket Layer
IETF Internet Engineering Task Force
IO I/O Input/Output
IP Internet Protocol
62676-2-2  IEC:2013 – 9 –
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
ISO International Standards Organization
ITU International telecommunications Union
JFIF JPEG File Interchange Format
JPEG Joint Photographic Expert Group
MPEG Moving Pictures Experts Group
NTP Network Time Protocol
NVS Network Video Storage Device
POSIX Portable Operating System Interface
PTZ Pan / Tilt / Zoom
QoS Quality of Service
REST Representational State Transfer
RFC (Request for comment) IETF Standards Draft
RTCP Real Time Control Protocol.
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SDP Session Description Protocol
SHA Secure Hash Algorithm
SOAP Simple Object Access Protocol
SRTP Secure Real-time Transport Protocol
SSID Service Set ID
SSL Secure Sockets Layer SAML Security Assertion Markup Language
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol / Internet Protocol
TKIP Temporal Key Integrity Protocol
TLS Transport Layer Security
TTL Time-to-live
UDP User Datagram Protocol
UPnP Universal Plug and Play
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTC Universal Time Coordinated
UTF Unicode Transformation Format
UTF-8 8-bit Unicode Transformation Format URN Uniform Resource Name
UUID Universally Unique Identifier
VMS Video management system
VT Video Transmission
VTD Video Transmission device
W3C World Wide Web Consortium
WPA Wi-Fi Protected Access
XML eXtensible Markup Language
Zeroconf Zero Configuration Networking

– 10 – 62676-2-2  IEC:2013
4 Overview
Security and/or network management applications require the ability to change configurations
and control the behaviours of IP video devices – cameras, encoders, decoders, recorders,
etc. This functionality can be achieved by sending a standard HTTP(S) request to the unit.
The basic principle of this IP Interoperability is to specify and define HTTP(S) application
programming interfaces (APIs) for VT devices and their functionality; namely, for
setting/retrieving various configurations, and controlling device behaviours.
The REST Service Model Version 1.1 is intended to assist the IEC working groups in creating
new protocols or converting contributed protocols to a standard service model that will be
common to all endorsed specifications. Adherence to this service model will ensure
interoperability between compliant protocols.
This model is similar in nature to Web services but is geared towards lightweight computing
requirements on devices. As such, these protocols will not use Simple Object Access Protocol
(SOAP) as defined by the W3C-defined Web services but instead will use a simplified XML
schema and/or xml schema documents (.xsd’s).
Unless otherwise noted, all specifications of this clause should treat all configuration and
management aspects as resources utilizing the REpresentational State Transfer (REST)
architecture.
The Service Model is based on a REST architecture. While REST specifies that all interfaces
are defined as resources, in the Model of this standard these resources are grouped by
service. This architecture provides a convenient way to group related resources within a
hierarchical namespace and lends itself to service discovery and future expansion.
Anybody is welcome to add services at any time provided said services adhere to the service
model as defined herein. Every effort should be taken to maintain full backward compatibility
when adding new services. The Service Model is designed to support expansion with
backwards compatibility.
5 Design considerations
5.1 General
Network-attached devices are often equipped with a web server to maintain various web
pages. These pages allow the devices to be configured through an internet browser. It is
natural to reuse this web server and the HTTP protocol in order for external applications to
configure and control the device. Thus, all resources will use a standard HTTP request which
will be processed by the device’s web server.
When possible, IP devices should implement HTTPS to support privacy of data. It is assumed
that the network infrastructure is configured properly with firewall, 802.1x, etc. and other
features to provide basic network level security. Additionally, because IP devices are typically
endpoint devices, HTTPS is assumed to provide sufficient safeguard in combination with the
other features mentioned above.
Some devices are not capable of implementing HTTPS and in certain deployments it may not
be necessary (i.e. closed networks). Additionally, SSL/TLS implies certificate management on
an endpoint which could pose other problems. Embedded devices may not have a “trusted”
certificate without a client explicitly trusting the certificate or uploading a trusted certificate.
Furthermore, certificates may need to be regenerated upon configuration changes (IP
address, etc.).
62676-2-2  IEC:2013 – 11 –
As such, the protocols use the HTTP Get and Post methods as described in “Hypertext
Transfer Protocol -- HTTP/1.0” (RFC 1945) and “Hypertext Transfer Protocol -- HTTP/1.1”
(RFC 2616).
5.2 REST overview
REST is an approach to creating services that expose all information as resources in a
uniform way. This approach is quite different from the traditional Remote Procedure Call
(RPC) mechanism which identifies the functions that an application can call. Put simply, a
REST Web application is noun-driven while an RPC Web application is verb-driven. For
example, if a Web application were to define an RPC API for user management, it might be
written as follows:
GET http://webserver/getUserList
GET http://webserver/getUser?userid=100
POST http://webserver/addUser
POST http://webserver/updateUser
GET http://webserver/deleteUser?userid=100
On the other hand, a REST API for the same operations would appear as follows:
GET http://webserver/users
GET http://webserver/users/user100
POST http://webserver/users
PUT http://webserver/users/user100
DELETE http://webserver/users/user100
Part of the simplicity of REST is its uniform interface for operations. Since everything is
represented as a resource, create, retrieve, update, and delete (CRUD) operations use the
same URI.
5.3 Conformance
5.3.1 General
Every protocol will define one or more compliant REST services. To ensure interoperability,
the following conformance requirements are also implied in each protocol.
5.3.2 Minimum API set
In addition to the service specific mandatory requirements, a system/device shall support all
of the mandatory services.
Each specification may define one or more compliant services. Each service and each
contained resource shall be assigned a scope of either mandatory or optional. Within each
implemented service type, all mandatory resources shall be implemented.
5.3.3 XML requirements
A system/device shall support the syntax as defined by the W3C XML 1.0 specification.
A system/device shall support the UTF-8 character set as described by
http://www.w3.org/International/O-charset
Additionally, XML content shall correspond to the following Schemas as defined in Annex A:
• “ResourceList XML Schema”
• “ResourceDescription XML Schema”
• “QueryStringParameterList XML Schema”
• “ResponseStatus XML Schema”
– 12 – 62676-2-2  IEC:2013
Vendors may optionally extend this standard to include proprietary XML content as long as it
does not conflict with the minimum set of APIs. In this case, it is recommended to use a
vendor-specific XML namespace to avoid conflicting names that may arise with future
revisions.
For example, if vendor XYZ123 Inc intends to extend the XML standard to include a
parameter, it is recommended to use com:configuration:options”> to avoid future namespace conflicts.
5.3.4 Protocol requirements
A system/device shall support transport of XML via either the HTTP/1.0 or HTTP/1.1 protocol
as specified in RFC 1945 and RFC 2616, respectively. It is highly recommended that
HTTP/1.1 is used in order to support key features (persistent connections, HTTPS, etc.).
When HTTP 1.0 is implemented, the client applications shall not issue multiple messages to
the target systems/devices.
5.4 HTTP methods and REST
The CRUD operations are defined by the HTTP method as shown in the table1 below.
Table 1 – HTTP methods
HTTP method Operation
POST Create the resource
GET Retrieve the resource
PUT Update the resource
DELETE Delete the resource
Rules of thumb.
GET calls should never change the system state. They are meant to only return data to the
requestor and not to have any side effects
POST calls should only be used to ADD something that did not already exist.
PUT calls are expected to update an existing resource but if the resource specified does not
already exist, it can be created as well. This will be the assumed default behavior of PUT
calls. If any resource wishes to deviate from this behavior, it should be considered an
exception and this should be noted in the implementation notes of the resource.
5.5 HTTP status codes and REST
The following Table 2 shows how the HTTP status codes map to REST operations along with
the general use case for response headers and bodies. For more information, please see the
table under each REST API.
62676-2-2  IEC:2013 – 13 –
Table 2 – HTTP status codes and REST
HTTP REST meaning POST GET PUT DEL
status
codes
200 “OK” - The request has succeeded.
Header Notes: None
X X
Body notes: The requested resource will be
returned in the body.
201 “Created” - The request has created a new
resource.
Header notes: The Location header contains the
X
URI of the newly created resource.
Body notes: The response returns an entity
describing the newly created resource.
204 “No Content” - The request succeeded, but there
is no data to return.
X X
Header notes: None
Body notes: No body is allowed.
301 “Moved Permanently” - The requested resource
has moved permanently.
Header notes: The Location header contains the
X
URI of the new location.
Body notes: The body may contain the new
resource location.
302 “Found” - The requested resource should be
accessed through this location, but the resource
actually lives at another location. This is typically
used to set up an alias.
X
Header notes: The Location header contains the
URI of the resource.
Body notes: The body may contain the new
resource location.
400 “Bad Request” - The request was badly formed.
This is commonly used for creating or updating a
resource, but the data was incomplete or
incorrect.
Header notes: The Reason-Phrase sent with the
X X
HTTP status header may contain information on
the error.
Body notes: The response may contain more
information of the underlying error that occurred
in addition to the Reason-Phrase.
401 “Unauthorized” - The request requires user
authentication to access this resource. If the
request contains invalid authentication data, this
code is sent.
Header notes: At least one authentication
mechanism shall be specified in the WWW-
X X X X
Authenticate header. The Reason-Phrase sent
with the HTTP status header may contain
information on the error.
Body notes: The response may contain more
information of the underlying error that occurred
in addition to the Reason-Phrase.
403 “Forbidden” - The request is not allowed because
the server is refusing to fill the request. A
common reason for this is that the device does
X X X X
not support the requested functionality.
Header notes: The Reason-Phrase sent with the
HTTP status header may contain information on

– 14 – 62676-2-2  IEC:2013
HTTP REST meaning POST GET PUT DEL
status
codes
the error.
Body notes: The response may contain more
information of the underlying error that occurred
in addition to the Reason-Phrase.
404 “Not Found” - The requested resource does not
exist.
X X X X
Header notes: None
Body notes: None
405 “Method Not Allowed” – The request used an
HTTP method that is not supported for the
resource because the {API Protocol} specification
does not allow this method. If the device does not
support the functionality but it is a valid {API
X X X X
Protocol} operation, then a 403 is returned.
Header notes: The Allow header lists the
supported HTTP methods for this resource.
Body notes: None
500 “Internal Server Error” - An internal server error
has occurred.
X X X X
Header notes: None
Body notes: None
503 “Service Unavailable” – The HTTP server is up,
but the REST service is not available. Typically
this is caused by too many client requests.
X X X X
Header notes: The Retry-After header suggests
to the client when to try resubmitting the request.
Body notes: None
5.6 Unique identifiers
IDs are defined as URL-Valid Strings, as required by REST. The device will create an ID for
all resources that add a resource.
IDs within each type should be unique at least on the channel level, but there is no
requirement for uniqueness across devices. If globally unique IDs are desired, a globally
unique ID should be derived using the method described in RFC 4122.
5.7 ID encoding
Because IDs will occur as part of a URI, there are two ways to encode an ID: either following
RFC 3986 or, for pure binary IDs, as a hex string.
RFC 3986 first converts the URI to UTF and then prints the following unreserved characters in
the URI without any encoding:
• A-Z
• a-z
• 0-9
• -
• .
• _
• ~
62676-2-2  IEC:2013 – 15 –
All non-printable or reserved characters will be encoded as a two digit hex value prefixed by
a %. For example, a space (ASCII value of 32) will be encoded as %20.
Because a pure binary ID can contain values that might interfere with the operation of
browsers and web servers, protocols support hex encoding of the ID. The ID shall begin with
0x (0X is also acceptable) followed by pairs of hex values. Each hex pair represents a single
byte in the ID. For example: 0x3F431245DE67FAC46F9D034CA23AEFD4. The hexadecimal
characters A-F can also be represented by a-f. So 0x3f431245de67fac46f9d034ca23aefd4 is
equivalent to the previous ID.
If readable IDs are desired, it is recommended that IDs are created with unreserved, printable
ASCII characters.
6 Architecture and namespace
In a typical REST-based namespace, every node or object in the tree-structured hierarchy is
considered a resource.
The service model adds a resource sub-class called “Service”. Services are simply nodes
which can contain other nodes. Nodes that do not contain other nodes (other than the
standard node resources of the model) will continue to be called resources, while the term
node will be used to refer to both services and resources.
Viewed as a tree, services are analogous to branches and resources are analogous to leaves.
Figure 1 below provides an example of PSIA service architecture.

System
Reboot
Status
RESTful
resources
Security
SrtpMasterKey
“Services”
DeviceCertificate
“Resources”
IEC  2739/13
Figure 1 – PSIA service architecture example

– 16 – 62676-2-2  IEC:2013
Each node shall contain the following standard resources (see Table 3):
description which will respond to an HTTP GET with a ResourceDescription datablock
index which will respond to an HTTP GET with a Resour
...