Working group

The mission of the Service Workers Working Group is to enable Web applications to take advantage of persistent background processing, including hooks to enable bootstrapping of web applications while offline.
 
Web Applications traditionally assume that the network is reachable, which is not always the case. The Working Group will specify event-driven services between the network layer and the application, allowing it to handle network requests gracefully even while offline.

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 Publishing Working Group is to enable all publications—with all their specificities and traditions—to become first-class entities on the Web. The group will provide the necessary technologies on the Open Web Platform to make the combination of traditional publishing and the Web complete in terms of accessibility, usability, portability, distribution, archiving, offline access, and reliable cross referencing.
 
The WG will specify Web Publications and identify what they need the underlying Web platform to provide. It will build upon existing platform technologies specified by other groups, where available, seeking to fill gaps by assuring that the unique requirements of Web Publications are addressed by features (including optional features) or extension points in those specifications.
 
In particular, the WG will make normative Recommendations for Web Publications; Packaged Web Publications; EPUB 4; and DPUB-ARIA 2.0, as described in Deliverables.
 
Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general Web Content Accessibility Guidelines (WCAG) and Web Accessiblity Initiative (WAI) requirements of the W3C as well as requirements for international readers using different scripts and document formats. Profiles of Web Publications may be defined with more stringent accessibility requirements.

The purpose of the OASIS WS-SX TC is to define extensions to OASIS Web Services Security to enable trusted SOAP message exchanges involving multiple message exchanges and to define security policies that govern the formats and tokens of such messages. This work will be carried out through continued refinement of the Web Services SecureConversation, SecurityPolicy and Trust specifications submitted to the TC as referenced in the charter.

Interception techniques need to become more effective and fail-safe as endpoints become inherently more secure. The IETF Captive Portal Interaction (CAPPORT) Working Group will define secure mechanisms and protocols to:

• Allow endpoints to discover that they are in this sort of limited environment.
• Provide a URL to interact with the Captive Portal.
• Allow endpoints to learn about parameters of their confinement.
• Interact with the Captive Portal to obtain information such as status and remaining access time.
• Optionally, advertise a service whereby devices can enable or disable access to the Internet without human interaction. (RFC 7710 may be a full or partial solution to the first two bullets).

The OASIS PMRM TC works to provide a standards-based framework that will help business process engineers, IT analysts, architects, and developers implement privacy and security policies in their operations. PMRM picks up where broad privacy policies leave off. Most policies describe fair information practices and principles but offer little insight into actual implementation. PMRM provides a guideline or template for developing operational solutions to privacy issues. It also serves as an analytical tool for assessing the completeness of proposed solutions and as the basis for establishing categories and groupings of privacy management controls.

The Object Drive TWG was created for the purpose of establishing architectures and standards for disk, solid state and tape drive based functionalities that allow them to be higher level storage nodes in emerging scale out solutions. The TWG creates specifications that enable scale out storage systems to add and remove these nodes incrementally and seamlessly. These specifications are vendor agnostic and support existing and future functionality in drive form factors.
The Object Drive TWG:
 
    Acts as the primary technical entity for the SNIA to identify, develop, and coordinate standards for Object Drives operating as storage nodes in scale out storage solutions.
    Produces a comprehensive set of specifications related to data and control path interfaces and protocols.
    Promotes interoperability among Object Drive software hosting environments

The NVM Programming TWG was created for the purpose of accelerating availability of software enabling NVM (Non-Volatile Memory) hardware.  The TWG creates specifications which provide guidance to operating system, device driver, and application developers. These specifications are vendor agnostic and support all the NVM technologies of member companies.

SNIA's Linear Tape File System (LTFS) Technical Work Group is focusing technical efforts on the development of an architecture that is related to the on-tape format for LTFS. The architecture also produces a comprehensive set of specifications ensuring a consistency of interface standards across LTFS related efforts.

LTFS refers to both the format of data recorded on magnetic tape media and the implementation of specific software that uses this data format to provide a file system interface to data stored on magnetic tape

The primary focus of the I/O Traces, Tools, and Analysis (IOTTA) TWG is to create a worldwide repository for storage-related I/O trace collection and analysis tools, application workloads, I/O traces, and best practices around such topics. That repository is located at http://iotta.snia.org

The I/O traces of interest to the IOTTA TWG include those up at the host (e.g., system call, file system), those involving a file server (e.g., NFS, CIFS) and those at the "transport level" (e.g., SCSI, Fibre Channel). I/O traces of application workloads along with the analysis and definition of common, recommended semantics and formats for I/O traces are also specific areas of focus for the TWG. Standardized I/O trace formats/semantics will enable the development and use of common I/O trace collection and analysis tools as well as facilitate the sharing of the I/O traces themselves.

The IOTTA TWG is for those interested in the use of empirical data/metrics to better understand the actual operation and performance characteristics of storage I/O, especially as they pertain to application workloads. This includes not only storage vendors but also storage users as well as those within the academic community who are performing research related to storage I/O and storage devices.

The Computational Storage TWG was created for the purpose of establishing architectures and software for storage, disk, and solid state device based functionalities that allow them to be integrated with Computation in its many forms. This TWG creates software and standards that enable specific features for these devices that meet the requirements of stakeholders with these computational needs. 

The Cloud Storage TWG acts as the primary technical entity for the SNIA to identify, develop, and coordinate systems standards for Cloud Storage. This group aims to produce a comprehensive set of specifications and drives consistency of interface standards and messages across the various Cloud Storage related efforts. The TWG also documents system-level requirements and shares these with other Cloud Storage standards organizations under the guidance of the SNIA Technical Council and in cooperation with the SNIA Strategic Alliances Committee.