35.240.95 - Internet applications

The present document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session
Initiation Protocol (SIP) and Realtime Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IP
MM services as described by the Recommendations ITU-T H.323 [6] and H.248-1 [i.3].
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 [9] and
ETSI TS 101 671 [1].

IEC 60050-741:2020 provides a definition of Internet of Things along with related terms and definitions. It has the status of a horizontal standard in accordance with IEC Guide 108:2006. This terminology is consistent with the terminology developed in the other specialized parts of the IEV.

This document describes a cybersecurity evaluation methodology, named SESIP, for components of connected ICT products. Security claims in SESIP are made based on the security services offered by those components. Components can be in hardware and software. SESIP aims to support comparability between and reuse of independent security evaluations. SESIP provides a common set of requirements for the security functionality of components which apply to the foundational components of devices that are not application specific. The methodology describes the re-use of evaluation results.

The present document contains a stage 1 description of the interception information in relation to the process of binding a "target identity" to an IP address when providing Internet access and a stage 2 description of when Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain.
The present document includes but is not restricted to IRI based on application of Dynamic Host Configuration Protocol (DHCP) and Remote Authentication Dial-In User Service (RADIUS) technology for binding a "target identity" to an IP address and CC for the intercepted IP packets.
The definition of the Handover Interface 2 (HI2) and Handover Interface 3 (HI3) is outside the scope of the present document. For the handover interface is referred to ETSI TS 102 232-1 [2].

The present document specifies Lawful Interception for an Access Provider that has access to layer 2 session
information and that is not required to have layer 3 information. In this case, the focus of Lawful Interception (LI) for IP
Network Access is on the portion of the network, commonly referred to as "layer 2 interception", that facilitates
subscriber access to the Public IP network.
The present document describes the LI at the interception domain of the access network.
The present document contains:
• a stage 1 description of the Lawful Interception service;
• a stage 2 description of the information flows between the functional entities (including the information
elements involved) and triggering events; and
• a stage 3 description of the protocol and procedures to be used in mapping from stage 2 information flows and
elements to Intercept Related Information (IRI) and Content of Communication (CC).
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
NOTE 1: Layer 3 interception is described in ETSI TS 102 232-3 [12].
NOTE 2: Layer 2 interception is not applicable to the PS domain of the GSM/UMTS networks (ETSI
TS 123 060 [15]).

The present document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks.
The present document:
• specifies the modular approach used for specifying IP based handover interfaces;
• specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;
• specifies protocols for the transfer of IRI and CC across the handover interfaces;
• specifies protocol profiles for the handover interface.
The present document is designed to be used where appropriate in conjunction with other deliverables that define the service-specific IRI data formats (including ETSI TS 102 227 [i.1], ETSI TS 101 909-20-1 [33], ETSI TS 101 909-20-2 [34], ETSI TS 102 232-2 [5], ETSI TS 102 232-3 [6], ETSI TS 102 232-4 [32], ETSI TS 102 232-5 [37], ETSI TS 102 232-6 [36] and ETSI TS 102 232-7 [38]). Where possible, the present document aligns with 3GPP TS 33.108 [9] and ETSI TS 101 671 [4] and supports the requirements and capabilities defined in ETSI TS 101 331 [i.9] and ETSI TR 101 944 [i.4].
For the handover of intercepted data within GSM/UMTS PS and CS domains, the present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 [9] and ETSI TS 101 671 [4].
For the handover of services defined in 3GPP TS 33.128 [46], in the event of conflict between the present document and 3GPP TS 33.128 [46], the terms of 3GPP TS 33.128 [46] apply.

The present document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session
Initiation Protocol (SIP) and Realtime Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IP
MM services as described by the Recommendations ITU-T H.323 [6] and H.248-1 [i.3].
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 [9] and
ETSI TS 101 671 [1].

This document describes a cybersecurity evaluation methodology, named SESIP, for components of connected ICT products. Security claims in SESIP are made based on the security services offered by those components. Components can be in hardware and software. SESIP aims to support comparability between and reuse of independent security evaluations. SESIP provides a common set of requirements for the security functionality of components which apply to the foundational components of devices that are not application specific. The methodology describes the re-use of evaluation results.

The present document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks.
The present document:
• specifies the modular approach used for specifying IP based handover interfaces;
• specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;
• specifies protocols for the transfer of IRI and CC across the handover interfaces;
• specifies protocol profiles for the handover interface.
The present document is designed to be used where appropriate in conjunction with other deliverables that define the
service-specific IRI data formats (including ETSI TS 102 227 [i.1], ETSI TS 101 909-20-1 [33], ETSI
TS 101 909-20-2 [34], ETSI TS 102 232-2 [5], ETSI TS 102 232-3 [6], ETSI TS 102 232-4 [32], ETSI
TS 102 232-5 [37], ETSI TS 102 232-6 [36] and ETSI TS 102 232-7 [38]). Where possible, the present document aligns
with 3GPP TS 33.108 [9] and ETSI TS 101 671 [4] and supports the requirements and capabilities defined in ETSI
TS 101 331 [i.9] and ETSI TR 101 944 [i.4].
For the handover of intercepted data within GSM/UMTS PS and CS domains, the present document does not override
or supersede any specifications or requirements in 3GPP TS 33.108 [9] and ETSI TS 101 671 [4].
For the handover of services defined in 3GPP TS 33.128 [46], in the event of conflict between the present document
and 3GPP TS 33.128 [46], the terms of 3GPP TS 33.128 [46] apply.

The present document contains a stage 1 description of the interception information in relation to the process of binding
a "target identity" to an IP address when providing Internet access and a stage 2 description of when Intercept Related
Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain.
The present document includes but is not restricted to IRI based on application of Dynamic Host Configuration Protocol
(DHCP) and Remote Authentication Dial-In User Service (RADIUS) technology for binding a "target identity" to an IP
address and CC for the intercepted IP packets.
The definition of the Handover Interface 2 (HI2) and Handover Interface 3 (HI3) is outside the scope of the present
document. For the handover interface is referred to ETSI TS 102 232-1 [2]

The present document contains service-specific details for the handover of the lawfully intercepted PSTN/ISDN
Services (including emulated services such as those defined in ETSI ES 282 002 [i.3]) using packet-based techniques as
defined in ETSI TS 102 232-1 [2].

The present document contains a stage 1 description of the interception information in relation to the process of binding
a "target identity" to an IP address when providing Internet access and a stage 2 description of when Intercept Related
Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs to contain.
The present document includes but is not restricted to IRI based on application of Dynamic Host Configuration Protocol
(DHCP) and Remote Authentication Dial-In User Service (RADIUS) technology for binding a "target identity" to an IP
address and CC for the intercepted IP packets.
The definition of the Handover Interface 2 (HI2) and Handover Interface 3 (HI3) is outside the scope of the present
document. For the handover interface is referred to ETSI TS 102 232-1 [2].

The present document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session
Initiation Protocol (SIP) and Realtime Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IP
MM services as described by the Recommendations ITU-T H.323 [6] and H.248-1 [i.3].
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 [9] and
ETSI TS 101 671 [1].

The present document specifies Lawful Interception for an Access Provider that has access to layer 2 session
information and that is not required to have layer 3 information. In this case, the focus of Lawful Interception (LI) for IP
Network Access is on the portion of the network, commonly referred to as "layer 2 interception", that facilitates
subscriber access to the Public IP network.
The present document describes the LI at the interception domain of the access network.
The present document contains:
• a stage 1 description of the Lawful Interception service;
• a stage 2 description of the information flows between the functional entities (including the information
elements involved) and triggering events; and
• a stage 3 description of the protocol and procedures to be used in mapping from stage 2 information flows and
elements to Intercept Related Information (IRI) and Content of Communication (CC).
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
NOTE 1: Layer 3 interception is described in ETSI TS 102 232-3 [12].
NOTE 2: Layer 2 interception is not applicable to the PS domain of the GSM/UMTS networks (ETSI
TS 123 060 [15]).

The present document specifies an approach for the handover of the lawfully-intercepted information that is defined in
the two standards: 3GPP TS 33.108 [3] and 3GPP TS 33.128 [6]. The present document uses the handover techniques
defined in ETSI TS 102 232-1 [2]. In this way, the present document allows additional services to be delivered through
a common interface.
3GPP TS 33.108
The scope of the present document includes the handover of lawfully-intercepted information from the following parts
of 3GPP TS 33.108 [3]:
• Intercept Related Information (IRI) and the Content of Communication (CC) from the mobile circuit-switched
domain (3GPP TS 33.108 [3], clause 5).
• IRI and CC from the mobile packet-switched domain (3GPP TS 33.108 [3], clause 6).
• IRI and CC from the multi-media domain (3GPP TS 33.108 [3], clause 7).
• IRI and CC from the EPS domain (3GPP TS 33.108 [3], clause 10).
• IRI and CC from the IMS Conference domain (3GPP TS 33.108 [3], clause 11).
• IRI and CC from the IMS-based VoIP domain (3GPP TS 33.108 [3], clause 12).
• IRI from the Proximity Services domain (3GPP TS 33.108 [3], clause 13).
• IRI and CC from the Group Communication System Enablers domain (3GPP TS 33.108 [3], clause 14).
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 [3].
3GPP TS 33.128
The scope of the present document includes the handover of lawfully-intercepted information in accordance with 3GPP TS 33.128 [6].

The present document specifies the general aspects of HI2 and HI3 interfaces for handover via IP based networks.
The present document:
• specifies the modular approach used for specifying IP based handover interfaces;
• specifies the header(s) to be added to IRI and CC sent over the HI2 and HI3 interfaces respectively;
• specifies protocols for the transfer of IRI and CC across the handover interfaces;
• specifies protocol profiles for the handover interface.
The present document is designed to be used where appropriate in conjunction with other deliverables that define the
service-specific IRI data formats (including ETSI TS 102 227 [i.1], ETSI TS 101 909-20-1 [33], ETSI
TS 101 909-20-2 [34], ETSI TS 102 232-2 [5], ETSI TS 102 232-3 [6], ETSI TS 102 232-4 [32], ETSI
TS 102 232-5 [37], ETSI TS 102 232-6 [36] and ETSI TS 102 232-7 [38]). Where possible, the present document aligns
with 3GPP TS 33.108 [9] and ETSI TS 101 671 [4] and supports the requirements and capabilities defined in ETSI
TS 101 331 [i.9] and ETSI TR 101 944 [i.4].
For the handover of intercepted data within GSM/UMTS PS and CS domains, the present document does not override
or supersede any specifications or requirements in 3GPP TS 33.108 [9] and ETSI TS 101 671 [4].
For the handover of services defined in 3GPP TS 33.128 [46], in the event of conflict between the present document
and 3GPP TS 33.128 [46], the terms of 3GPP TS 33.128 [46] apply.

The present document contains a stage 1 like description of the interception information in relation to the process of
sending and receiving asynchronous messages. The present document also contains a stage 2 like description of when
Intercept Related Information (IRI) and Content of Communication (CC) need to be sent, and what information it needs
to contain.
Examples of asynchronous messages include email, unified messaging and chat applications.
The definition of handover transport and encoding of HI2 and HI3 is outside the scope of the present document. Refer
to ETSI TS 102 232-1 [3].
The present document is designed to be used where appropriate in conjunction with other deliverables that define the
service specific IRI data formats. The present document aligns with 3GPP TS 33.108 [5], ETSI TS 101 671 [i.3], ETSI
TS 101 331 [1] and ETSI TR 101 944 [i.1].

IEC 62944:2016(E) specifies a set of principles and considerations for digital television products in support of older people and persons with disabilities in addition to mainstream users. The effect of following the principles and considerations as set out in this document is to ensure that the widest range of users can access, understand and use digital television products. These principles and considerations cover four main user profiles such as individuals with hearing impairments, individuals with sight impairments, individuals with mobility impairments and individuals with cognitive impairments.

IEC 60050-741:2020 provides a definition of Internet of Things along with related terms and definitions. It has the status of a horizontal standard in accordance with IEC Guide 108:2006. This terminology is consistent with the terminology developed in the other specialized parts of the IEV.

This European Standard concentrates on control applications for Home and Building HBES Open Communication System and covers any combination of electronic devices linked via a digital transmission network. Home and Building Electronic System as provided by the HBES Open Communication System is a specialized form of automated, decentralised and distributed process control, dedicated to the needs of home and building applications. This European Standard defines the mandatory and optional requirements for the medium independent communication over IP for HBES products and systems, a multi-application bus system where the functions are decentralised, distributed and linked through a common communication process. This European Standard is used as a product family standard. It is not intended to be used as a stand-alone standard. Other parts from the EN 50090 series may apply.

IEC 62766-8:2017(E) defines three example profiles that may be adopted for implementation in suitable devices.

IEC 62766-5-1:2017(E) specifies the Declarative Application Environment (DAE) component of the OIPF terminal function (OITF). The DAE is a declarative language based environment (browser) based on the OIPF web standards TV profile specified in IEC 62766-5-2 for the presentation of user interfaces and including scripting support for interaction with network server-side applications and access to the APIs of the other OITF functions.

IEC 62766-4-1:2017(E) specifies the protocols, which apply to the following reference point interfaces identified in the architecture described in Annex B of IEC 62766-1:2017.
- The UNI interfaces, between the consumer domain and the network or service provider domains.
- The HNI interfaces, between the functional entities in the consumer network domain.
- Interfaces to external systems, which include DLNA networks in the consumer domain.

IEC 62766-7:2017(E) specifies functions for content protection, service protection, service access protection, user identification, user authentication, and user authorisation.

IEC 62766-5-2:2017(E) specifies a profile of HTML5, CSS and other related web technologies for connected TVs. Its goal is to describe a common profile that can be relied on by content and service providers and implemented by manufacturers. It does not describe extensions or modification to any of the referenced technologies but only tries to define a subset of web standards that are suitable and useful for TV deployments and at the same time stable enough to provide a good degree of confidence that real interoperability can be achieved. It may add clarifications and/or additional constraints where these are needed due to the nature of the target deployment environment.

IEC 62766-6:2017(E) specifies the procedural application environment (PAE) component of the OIPF terminal function (OITF). It also defines the UNI reference point UNIS-12 of the OIPF functional architecture summarised in Annex B of IEC 62766-1:2017.
The PAE is an application environment for IPTV services based on Java. Like other specifications such as OCAP, ACAP and Blu-ray, which are, or include, GEM terminal specifications, this document follows the structure of ETSI TS 102 728.

IEC 62766-1:2017(E) defines general common elements and specifies the structure of the IEC 62766 series, the scopes of, and relationships between the other parts

IEC 62766-4-2:2017(E) provides informative examples of features defined in IEC 62766-4-1.

IEC 62944:2016 specifies a set of principles and considerations for digital television products in support of older people and persons with disabilities in addition to mainstream users. The effect of following the principles and considerations as set out in this document is to ensure that the widest range of users can access, understand and use digital television products. These principles and considerations cover four main user profiles such as individuals with hearing impairments, individuals with sight impairments, individuals with mobility impairments and individuals with cognitive impairments.

IEC 62766-3:2016 specifies the aspects concerning content metadata.

IEC 62766-2-1:2016 specifies formats for the audio/video content provided by IPTV services using fixed line access networks or mobile access networks and voice and video telephony services. It does not apply to the broadcast channel input of hybrid devices except where explicitly specified.It defines formats for the delivery of 3D video. At the present time, delivery to fixed terminals is targeted. It defines the media formats utilised on the UNI reference point UNIT-17 of the Open IPTV Forum functional architecture.

IEC 62766-2-2:2016 specifies media formats for adaptive unicast content streaming over HTTP. Two HTTP adaptive streaming formats are specified. The first is based entirely on MPEG DASH. The second is the OIPF “HTTP adaptive streaming” (HAS) format, which is based upon 3GPP’s release 9 adaptive HTTP streaming (AHS) format, with some profiling and extensions to add the features of media components and support for MPEG-2 transport stream content segment format. The latter format was specified before MPEG DASH had been published. It is retained due to usage in some legacy applications.

The present document specifies interception of Internet Protocol (IP) Multimedia (MM) Services based on the Session
Initiation Protocol (SIP) and Real Time Transport Protocol (RTP) and Message Session Relay Protocol (MSRP) and IP
MM services as described by the Recommendations ITU-T H.323 [6] and H.248 [7].
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
The present document does not override or supersede any specifications or requirements in 3GPP TS 33.108 [9] and
ETSI TS 101 671 [1].

The objective of this Technical Specification is to define a set of criteria on how Web filters shall perform and that shall give Internet users more confidence in choosing a suitable product or service in order to help protecting children online.
NOTE   A product is a software system that is installed by its administrator or its provider. A service is provided without specific installation by the administrator, but by direct provision of the customer by the provider. An example of a product is a software system installed on a personal computer, and an example of a service is an Internet connection filter provided by an Internet Service Provider and added on the Internet access service.
By using a Web filter that complies with the requirements set out in this Technical Specification, a user can be confident that the product or service:
a)   has been specifically designed to meet the needs of parents and carers (administrators of the filter) to protect children from potentially harmful URLs on the Internet;
b)   has been specifically targeted to minors, and is also suited for individuals looking to protect themselves from potentially harmful URLs on the Internet;
c)   delivers a minimum set of features and efficacy that are sufficient to provide the required level of protection;
d)   comes with clear and comprehensive documentation, installation and implementation instructions and available support;
e)   is reasonably secure, i.e. adopts proven measures to prevent bypassing or removal of the filter itself.
This Technical Specification does not cover the following technologies:
f)   any kind of email filtering, including: antispam filtering, antivirus analysis of emails and attachments, anthiphishing filtering;
g)   other Web filtering for the purpose of enterprise or adult Web usage, including: antivirus analysis of Web content, antiphishing filtering;
h)   the analysis and/or filtering of any other application traffic delivered over HTTP/HTTPS/FTP including for instance: instant messaging, peer to peer file (P2P) sharing, VoIP;
i)   the analysis and/or filtering of any other application traffic delivered over non HTTP/HTTPS/FTP protocols including for instance: newsgroups, instant messaging, peer to peer file (P2P) sharing, VoIP and social networking applications.

This part of IEC 62298 specifies the TeleWeb Hyperteletext profile that allows Web-style text and graphics to be displayed on suitable decoders. A TeleWeb service comprises multimedia data files whose format and attributes are defined by this specification. This standard is backwards compatible with IEC 62298-3 and extends it with features like scripting and style-sheets. The graphical capability is extended with features like frames and forms. For information regarding general information and the transport layer, refer to IEC 62298-1 and IEC 62298-2.

This part of IEC 62298 specifies the TeleWeb Superteletext profile that allows Web-style text and graphics to be displayed on suitable decoders. A TeleWeb service comprises multimedia data files whose format and attributes are defined by this specification. This specification focuses on the presentation layer especially the implementation of TeleWeb HTML. It further defines graphical requirements like colours and fonts and the used content formats. For information regarding general information and the transport layer, refer to IEC 62298-1 and IEC 62298-2.

This part of IEC 62298 gives a general overview of the TeleWeb  application that allows Web-style text and graphics to be  broadcast to and displayed by suitable decoders. TeleWeb  services can be broadcast in a number of different ways, for  example, VBI, DVB, DAB, etc., and to a variety of decoder  types, for example TVs, portable decoders, PCs, etc. These  transmission protocols are described separately.

This part of IEC 62298 specifies the transmission layer of TeleWeb. TeleWeb services can be broadcast in a number of different ways, for example, VBI, DVB, DAB, etc., and to a variety of decoder types, for example, TVs, portable decoders, PCs, etc. This standard specifies the transmission layer for VBI and DVB broadcasts.

This part of IEC 62766 specifies formats for the audio/video content provided by IPTV
services using fixed line access networks or mobile access networks and voice and video
telephony services. It does not apply to the broadcast channel input of hybrid devices except
where explicitly specified.
This part of IEC 62766 defines formats for the delivery of 3D video. At the present time,
delivery to fixed terminals is targeted. No special provision is made for mobile or portable
devices.
This standard defines the media formats utilised on the UNI reference point UNIT-17 of the
Open IPTV Forum functional architecture.

This part of IEC 62766 specifies the aspects concerning content metadata.

This part of IEC 62766 specifies media formats for adaptive unicast content streaming over
HTTP.
Two HTTP adaptive streaming formats are specified. The first is based entirely on MPEG
DASH. The second is the OIPF “HTTP adaptive streaming” (HAS) format, which is based upon
3GPP’s release 9 adaptive HTTP streaming (AHS) format, with some profiling and extensions
to add the features of media components and support for MPEG-2 transport stream content
segment format. The latter format was specified before MPEG DASH had been published. It is
retained due to usage in some legacy applications.

IEC 62766-3:2016 specifies the aspects concerning content metadata.

IEC 62766-2-2:2016 specifies media formats for adaptive unicast content streaming over HTTP. Two HTTP adaptive streaming formats are specified. The first is based entirely on MPEG DASH. The second is the OIPF “HTTP adaptive streaming” (HAS) format, which is based upon 3GPP’s release 9 adaptive HTTP streaming (AHS) format, with some profiling and extensions to add the features of media components and support for MPEG-2 transport stream content segment format. The latter format was specified before MPEG DASH had been published. It is retained due to usage in some legacy applications. Key words: Internet

IEC 62766-2-1:2016 specifies formats for the audio/video content provided by IPTV services using fixed line access networks or mobile access networks and voice and video telephony services. It does not apply to the broadcast channel input of hybrid devices except where explicitly specified.It defines formats for the delivery of 3D video. At the present time, delivery to fixed terminals is targeted. It defines the media formats utilised on the UNI reference point UNIT-17 of the Open IPTV Forum functional architecture.

This European Standard defines the mandatory and optional requirements for the medium independent communication over IP for HBES products and systems, a multi-application bus system where the functions are decentralised, distributed and linked through a common communication process. This European Standard is used as a product family standard. It is not intended to be used as a stand-alone standard. Other parts from the EN 50090 series may apply.