IT terminal and other peripheral equipment

The mission of the Second Screen Working Group is to provide specifications that enable web pages to use secondary screens to display web content.
 
The scope of this Working Group is to define an API that allows a web application to request display of web content on a connected display, with a means to communicate with and control the web content from the initiating page and other authorized pages. Pages may become authorized to control the web content by virtue of sharing an origin with the originating page, explicit user permission, or other facilities provided by the user agent. The API will hide the details of the underlying connection technologies and use familiar, common web technologies for messaging between the authorized pages and the web content shown on the secondary display. The web content may comprise HTML documents, web media types such as images, audio, video, or application-specific media, depending on the capabilities of the secondary display for rendering the media. Application-specific media includes that whose type is known to the controlling page and the connected display, but not necessarily a generic HTML user agent.
 
The API will provide a means to identify whether requesting display on second screens is likely to be successful, i.e. whether at least one secondary screen is available for display.
 
The API is agnostic with regard to the display connection used, and also works with display connections that support video only, for example, a TV connected to a laptop with an HDMI connection. In such a usage scenario, the web content displayed on a connected display must be rendered and converted to video before it is sent to a second screen. The user agent may use whatever means the operating system provides to prepare and send the video to a second screen. Any interaction between the authorized web pages and the content displayed on a secondary screen would happen within the bounds of the initiating device since both the pages and the content are rendered on that same device, and only a video representation is sent to the second screen.
 
Alternatively, if the second screen device understands some other means of transmitting content to a display and a means of two-way message passing, the web content can be rendered by the remote device. In this scenario, a URL to the content to be displayed is sent to the secondary display to be rendered there. Because the content is rendered separately from the initiating user agent, pages hosted by other user agents may be authorized to control the remotely rendered content at the same time.
 
For a requested piece of web content, how and by which device the content is rendered is an implementation detail. The user agent is responsible for determining which secondary displays are compatible with the content that is requested to be shown through the API.
 
Sending content to a connected display creates a presentation session. Applications can create multiple presentation sessions to control multiple displays, although synchronization between them is not currently supported by the API.
 
The specifications produced by this Working Group will include security and privacy considerations. Specifically, the user must always be in control of privacy-sensitive information that may be conveyed through the APIs, such as the visibility or access to secondary displays.
 
Members of the Working Group should review other Working Groups' deliverables that are identified as being relevant to the Working Group's mission.

The mission of the Pointer Events Working Group is to provide methods to enable simple device independent input from pointing devices such as mouse, pen, and multi-touch screen.
 
Web browsers can receive input in a variety of ways including mouse, touch, and pen input. A “pointer” is an abstract form of input that can be any point of contact on a input surface made by a mouse cursor, pen, finger, or multiple fingers.
 
Pointer Events provide support for handling mouse, touch, and pen input for web sites and web applications through DOM Events. For example, a content creator using Pointer Events would only have use a single model, rather than separate code paths for mouse events, touch events, and pen-tablet events, making authoring content much more efficient and inclusive.
 
This Working Group seeks to enhance the features delivered in the Pointer Events Level 1 Recommendation by exploring changes, such as:

• Addition of direction-specific values for finer-grained control of panning touch behaviors
• Reduction of hit-testing via implicit capture
• Additional clarifications of API behavior and performance optimizations

The mission of the Immersive Web Working Group is to help bring high-performance Virtual Reality (VR) and Augmented Reality (AR) (collectively known as XR) to the open Web via APIs to interact with XR devices and sensors in browsers.
 
The Immersive Web Working Group will develop standardized APIs to provide access to input and output capabilities commonly associated with XR hardware such as Google’s Daydream, the Oculus Rift, the Samsung GearVR, the HTC Vive, and Windows Mixed Reality headsets and sensors as well as mobile handheld devices and standalone headsets such as the Oculus Go. The WG will develop APIs to enable the creation of XR web experiences that are embeddable in the Web of today, enabling progressive enhancement of existing sites.
 
The scope of the Immersive Web Working Group charter is to define APIs which:

• Detect available XR devices and sensors.
• Query XR devices for device-specific capabilities.
• Receive updated information about the device's position and orientation over time.
• Receive updated information about the device's environment.
• Present imagery to the device at the device's native frame rate, using the device’s position and orientation over time to provide an immersive experience.
• Provide information about XR-specific input, including tracked controller state and hand gesture.
• For augmenting reality on devices which support AR, enable XR sessions that provide real-world display, and provide the ability to hit-test surfaces in the real world.

The initial focus of this Working Group was the development of mechanisms that provide confidentiality and authentication between DNS Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With proposed standard solutions for the client-to-iterative resolvers published, the working group turns its attention to the development of documents focused on: 1) providing confidentiality to DNS transactions between Iterative Resolvers and Authoritative Servers, 2) measuring the efficacy in preserving privacy in the face pervasive monitoring attacks, and 3) defining operational, policy, and security considerations for DNS operators offering DNS privacy services. Some of the results of this working group may be experimental.There are numerous aspects that differ between DNS exchanges with an iterative resolver and exchanges involving DNS root/authoritative servers. The working group will work with
DNS operators and developers (via the DNSOP WG) to ensure that proposed solutions address key requirements.

The Auditorium Security Message (ASM) specification enables interoperable communication of security-critical information (information necessary to ensure security of D-Cinema content) between devices over an intra-theater exhibition network.