SEARCH · Search NASA

Results for “interoperable services”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 271 records · Page 15

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Safety Assurance in NextGen

The generation of minimum operational, safety, performance, and interoperability requirements is an important aspect of safely integrating new NextGen components into the Communication Navigation Surveillance and Air Traffic Management (CNS/ATM) system. These requirements are used as part of the implementation and approval processes. In addition, they provide guidance to determine the levels of design assurance and performance that are needed for each element of the new NextGen procedures, including aircraft, operator, and Air Navigation and Service Provider. Using the enhanced Airborne Traffic Situational Awareness for InTrail Procedure (ATSA-ITP) as an example, this report describes some limitations of the current process used for generating safety requirements and levels of required design assurance. An alternative process is described, as well as the argument for why the alternative can generate more comprehensive requirements and greater safety assurance than the current approach.

HarrisonFleming, Cody↗

NASA NTRS2012

Design and Implementation of a Lunar Communications Satellite and Server for the 2012 SISO Smackdown

Last year, the Simulation Interoperability Standards Organization (SISO) inaugurated the now annual High Level Architecture (HLA) Smackdown at the Spring Simulation Interoperability Workshop (SIW). A primary objective of the Smackdown event is to provide college students with hands-on experience in the High Level Architecture (HLA). The University of Alabama in Huntsville (UAHuntsville) fielded teams in 2011 and 2012. Both the 2011 and 2012 smackdown scenarios were a lunar resupply mission. The 2012 UAHuntsville fielded four federates: a communications network Federate called Lunar Communications and Navigation Satellite Service (LCANServ) for sending and receiving messages, a Lunar Satellite Constellation (LCANSat) to put in place radios needed by the communications network for Line-Of-Sight communication calculations, and 3D graphical displays of the orbiting satellites and a 3D visualization of the lunar surface activities. This paper concentrates on the first two federates by describing the functions, algorithms, the modular FOM, experiences, lessons learned and recommendations for future Smackdown events.

Bulgatz, Dennis↗

NASA NTRS2016

Ontologies for Aviation Data Management

Managing complex aviation data can be a significant challenge for any enterprise – whether a government agency, airline, airframe manufacturer, or aviation service provider. To handle this challenge, data models are typically developed to characterize and manage the data generated, used, and stored by a given enterprise. Unfortunately, different data providers employ qualitatively different data models, and this gives rise to problems exchanging data across organizational boundaries. Over the past decade, these problems have motivated data producers and consumers to look toward standardized data exchange models to address data interoperability. In this paper we examine some of these standardized data exchange models and compare them with a new type of data model based on ontologies. Ontology models have emerged in recent years from a confluence of research in the artificial intelligence, semantic web, and information science communities. This paper introduces ontology models, provides several use cases for ontologies relevant to aviation data management, and summarizes state of the art aviation prototype applications that utilize ontologies.

artificial intelligence↗

NASA NTRS1994

Re-engineering Nascom's network management architecture

The development of Nascom systems for ground communications began in 1958 with Project Vanguard. The low-speed systems (rates less than 9.6 Kbs) were developed following existing standards; but, there were no comparable standards for high-speed systems. As a result, these systems were developed using custom protocols and custom hardware. Technology has made enormous strides since the ground support systems were implemented. Standards for computer equipment, software, and high-speed communications exist and the performance of current workstations exceeds that of the mainframes used in the development of the ground systems. Nascom is in the process of upgrading its ground support systems and providing additional services. The Message Switching System (MSS), Communications Address Processor (CAP), and Multiplexer/Demultiplexer (MDM) Automated Control System (MACS) are all examples of Nascom systems developed using standards such as, X-windows, Motif, and Simple Network Management Protocol (SNMP). Also, the Earth Observing System (EOS) Communications (Ecom) project is stressing standards as an integral part of its network. The move towards standards has produced a reduction in development, maintenance, and interoperability costs, while providing operational quality improvement. The Facility and Resource Manager (FARM) project has been established to integrate the Nascom networks and systems into a common network management architecture. The maximization of standards and implementation of computer automation in the architecture will lead to continued cost reductions and increased operational efficiency. The first step has been to derive overall Nascom requirements and identify the functionality common to all the current management systems. The identification of these common functions will enable the reuse of processes in the management architecture and promote increased use of automation throughout the Nascom network. The MSS, CAP, MACS, and Ecom projects have indicated the potential value of commercial-off-the-shelf (COTS) and standards through reduced cost and high quality. The FARM will allow the application of the lessons learned from these projects to all future Nascom systems.

Drake, Brian C.↗

NASA NTRS1986

Transportability, distributability and rehosting experience with a kernel operating system interface set

For the past two years, PRC has been transporting and installing a software engineering environment framework, the Automated Product control Environment (APCE), at a number of PRC and government sites on a variety of different hardware. The APCE was designed using a layered architecture which is based on a standardized set of interfaces to host system services. This interface set called the APCE Interface Set (AIS), was designed to support many of the same goals as the Common Ada Programming Support Environment (APSE) Interface Set (CAIS). The APCE was developed to provide support for the full software lifecycle. Specific requirements of the APCE design included: automation of labor intensive administrative and logistical tasks: freedom for project team members to use existing tools: maximum transportability for APCE programs, interoperability of APCE database data, and distributability of both processes and data: and maximum performance on a wide variety of operating systems. A brief description is given of the APCE and AIS, a comparison of the AIS and CAIS both in terms of functionality and of philosophy and approach and a presentation of PRC's experience in rehosting AIS and transporting APCE programs and project data. Conclusions are drawn from this experience with respect to both the CAIS efforts and Space Station plans.

Blumberg, F. C.↗

NASA NTRS2010

The Evolvable Advanced Multi-Mission Operations System (AMMOS): Making Systems Interoperable

The Advanced Multi-Mission Operations System (AMMOS) provides a common Mission Operation System (MOS) infrastructure to NASA deep space missions. The evolution of AMMOS has been driven by two factors: increasingly challenging requirements from space missions, and the emergence of new IT technology. The work described in this paper focuses on three key tasks related to IT technology requirements: first, to eliminate duplicate functionality; second, to promote the use of loosely coupled application programming interfaces, text based file interfaces, web-based frameworks and integrated Graphical User Interfaces (GUI) to connect users, data, and core functionality; and third, to build, develop, and deploy AMMOS services that are reusable, agile, adaptive to project MOS configurations, and responsive to industrially endorsed information technology standards.

MGSS↗

DOE OSTI2025

Applying the FAIR Principles to computational workflows

Recent trends within computational and data sciences show an increasing recognition and adoption of computational workflows as tools for productivity and reproducibility that also democratize access to platforms and processing know-how. As digital objects to be shared, discovered, and reused, computational workflows benefit from the FAIR principles, which stand for Findable, Accessible, Interoperable, and Reusable. The Workflows Community Initiative’s FAIR Workflows Working Group (WCI-FW), a global and open community of researchers and developers working with computational workflows across disciplines and domains, has systematically addressed the application of both FAIR data and software principles to computational workflows. We present recommendations with commentary that reflects our discussions and justifies our choices and adaptations. These are offered to workflow users and authors, workflow management system developers, and providers of workflow services as guidelines for adoption and fodder for discussion. The FAIR recommendations for workflows that we propose in this paper will maximize their value as research assets and facilitate their adoption by the wider community.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2003

Intelligent Systems Technologies to Assist in Utilization of Earth Observation Data

With the launch of several Earth observing satellites over the last decade, we are now in a data rich environment. From NASA's Earth Observing System (EOS) satellites alone, we are accumulating more than 3 TB per day of raw data and derived geophysical parameters. The data products are being distributed to a large user community comprising scientific researchers, educators and operational government agencies. Notable progress has been made in the last decade in facilitating access to data. However, to realize the full potential of the growing archives of valuable scientific data, further progress is necessary in the transformation of data into information, and information into knowledge that can be used in particular applications. Sponsored by NASA s Intelligent Systems Project within the Computing, Information and Communication Technology (CICT) Program, a conceptual architecture study has been conducted to examine ideas to improve data utilization through the addition of intelligence into the archives in the context of an overall knowledge building system. Potential Intelligent Archive concepts include: 1) Mining archived data holdings using Intelligent Data Understanding algorithms to improve metadata to facilitate data access and usability; 2) Building intelligence about transformations on data, information, knowledge, and accompanying services involved in a scientific enterprise; 3) Recognizing the value of results, indexing and formatting them for easy access, and delivering them to concerned individuals; 4) Interacting as a cooperative node in a web of distributed systems to perform knowledge building (i.e., the transformations from data to information to knowledge) instead of just data pipelining; and 5) Being aware of other nodes in the knowledge building system, participating in open systems interfaces and protocols for virtualization, and collaborative interoperability. This paper presents some of these concepts and identifies issues to be addressed by research in future intelligent systems technology.

Ramapriyan, Hampapuram K.↗

DOE OSTI2026

Aligning NASA Earth Science Data Stewardship with FAIR Principles: Outcomes, Recommendations, and Future Directions

The FAIR Principles—Findable, Accessible, Interoperable, and Reusable—offer a widely accepted framework for improving the sharing and reuse of digital scientific data by both human and machine users. Following these principles is critical for effective scientific data stewardship, broader scientific collaboration, and compliance with federal and agency data policies. This paper, based on the work of NASA’s Open, Free, and FAIR Working Group (O’FAIR WG) under the Earth Science Data Systems Program, presents an overview of how FAIR is being applied within NASA’s Earth science data landscape. It highlights ongoing progress and challenges, identifies FAIR-enabling resources, and offers recommendations and strategic actions to enhance the FAIRness of NASA-funded open and free Earth science data products. The FAIR-enabling resources identified underscore the vital role of NASA's existing enterprise processes, standards, tools, and infrastructures in supporting FAIR implementation. Our findings show strong performance in making NASA Earth science data more findable and accessible. However, further work is needed—especially in enhancing interoperability, so that different systems and tools can better understand and exchange data. This is especially important for enabling machine-driven discovery and analysis. We emphasize the importance of a balanced strategy that combines a centralized, top-down approach—focused on building enterprise-level capabilities and processes—with a decentralized, bottom-up approach driven by discipline-specific needs and community practices. We advocate for coordinated efforts to enhance (meta)data interoperability to facilitate seamless data and information sharing and exchange of Earth science data both within NASA and across other agencies managing Earth science data.

Data Product↗

NASA NTRSDate not supplied

FAIR Assessments

Presentation on Findable Accessible Interoperable and Reusable (FAIR) Assessment approaches for data.

FAIR↗

NASA NTRSDate not supplied

Lunar Search & Rescue Applications of Lunar GNSS

Accurate lunar navigation and timing knowledge provides for the development of safety-critical services in the cislunar and lunar surface domain. Currently under development, the Goddard Space Flight Center’s (GSFC) Search and Rescue Mission Office is investigating and integrating search and rescue (SAR) capability into planned and future lunar communication and navigation interfaces. Lunar Search and Rescue (LunaSAR) development has a stated end-goal for assured, reliable, and timely indication of distress events for a wide variety of lunar surface users, including government-sponsored, commercial, and international users. LunaSAR performance requirements are modelled after the current terrestrial Cospas-Sarsat distress notification system, leveraging an internationally robust global navigation satellite system (GNSS) ecosystem as a core element of survivor locating capability. This presentation will discuss NASA’s work to develop user-focused distress messaging capabilities including infusion of example sensor data for triggering of automated distress alerts coupled with location-tagging. Additionally, the presentation will examine overall message structures, rotating fields for use in bi-directional distress messaging, and specific use cases based on NASA’s lunar exploration and lunar communication relay architectures. Modelling and simulation of LunaSAR use by individual lunar explorers will be discussed, based on notional industry and government design reference missions and mission considerations. Results from GSFC-funded Internal Research and Development (IRAD) efforts will be detailed, including successful distress message formulation simulating the ingestion of example legacy space suit telemetry fields. Hardware-in-the-loop testing using high-reliability software defined radio (SDR) modules serve as an example of IRAD successes and the framework for technical requirements. Architectural development and technical evolution from 2020 to 2021 included alignment of LunaSAR distress waveforms with ongoing NASA LunaNet interoperability development, as well as engagement with NASA Lunar Spectrum authorities for allocation of UHF-band distress frequencies on the lunar surface. S-Band and UHF-band transmission characteristics will be detailed, along with band-specific applications of each emission type. Additionally, examples of ingestion and formatting of GNSS signals (using historical terrestrial National Marine Electronics Association-formatted GNSS data) will be detailed, underscoring lunar user needs for a common lunar GNSS receiver output message framework. Maturity and ability to support evolving lunar exploration goals has been demonstrated and will be detailed, with maturity gaps such as position, navigation, and timing (PNT) and lunar reference frames identified within the context of distress message generation. Provision of LunaSAR services for lunar surface users represents a new era of ensured safety for lunar explorers and builds off of forty years of the Cospas-Sarsat program, underscoring the importance of lunar GNSS for safety-critical applications and growing interest in safe, reliable lunar surface operations. Enabled by new GNSS systems being developed by government and industry partners, NASA will continue to evolve and integrate lunar GNSS types into distress message generation, with a focus on compact and efficient message transmission over various lunar communication links. When fielded, LunaSAR will be the first dedicated search and rescue notification system employed on another celestial body. Robust lunar navigation and timing services form the core of LunaSAR capabilities, allowing for system syncing with time-dominant sensors, and high-accuracy location of those in distress while engaged in lunar surface activities.

Search and Rescue↗

NASA NTRS2020

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗

NASA NTRS2015

Finding Atmospheric Composition (AC) Metadata

The Atmospheric Composition Portal (ACP) is an aggregator and curator of information related to remotely sensed atmospheric composition data and analysis. It uses existing tools and technologies and, where needed, enhances those capabilities to provide interoperable access, tools, and contextual guidance for scientists and value-adding organizations using remotely sensed atmospheric composition data. The initial focus is on Essential Climate Variables identified by the Global Climate Observing System CH4, CO, CO2, NO2, O3, SO2 and aerosols. This poster addresses our efforts in building the ACP Data Table, an interface to help discover and understand remotely sensed data that are related to atmospheric composition science and applications. We harvested GCMD, CWIC, GEOSS metadata catalogs using machine to machine technologies - OpenSearch, Web Services. We also manually investigated the plethora of CEOS data providers portals and other catalogs where that data might be aggregated. This poster is our experience of the excellence, variety, and challenges we encountered.Conclusions:1.The significant benefits that the major catalogs provide are their machine to machine tools like OpenSearch and Web Services rather than any GUI usability improvements due to the large amount of data in their catalog.2.There is a trend at the large catalogs towards simulating small data provider portals through advanced services. 3.Populating metadata catalogs using ISO19115 is too complex for users to do in a consistent way, difficult to parse visually or with XML libraries, and too complex for Java XML binders like CASTOR.4.The ability to search for Ids first and then for data (GCMD and ECHO) is better for machine to machine operations rather than the timeouts experienced when returning the entire metadata entry at once. 5.Metadata harvest and export activities between the major catalogs has led to a significant amount of duplication. (This is currently being addressed) 6.Most (if not all) Earth science atmospheric composition data providers store a reference to their data at GCMD.

metadata search↗

NASA NTRS2011

A New User Interface for On-Demand Customizable Data Products for Sensors in a SensorWeb

A SensorWeb is a set of sensors, which can consist of ground, airborne and space-based sensors interoperating in an automated or autonomous collaborative manner. The NASA SensorWeb toolbox, developed at NASA/GSFC in collaboration with NASA/JPL, NASA/Ames and other partners, is a set of software and standards that (1) enables users to create virtual private networks of sensors over open networks; (2) provides the capability to orchestrate their actions; (3) provides the capability to customize the output data products and (4) enables automated delivery of the data products to the users desktop. A recent addition to the SensorWeb Toolbox is a new user interface, together with web services co-resident with the sensors, to enable rapid creation, loading and execution of new algorithms for processing sensor data. The web service along with the user interface follows the Open Geospatial Consortium (OGC) standard called Web Coverage Processing Service (WCPS). This presentation will detail the prototype that was built and how the WCPS was tested against a HyspIRI flight testbed and an elastic computation cloud on the ground with EO-1 data. HyspIRI is a future NASA decadal mission. The elastic computation cloud stores EO-1 data and runs software similar to Amazon online shopping.

Mandl, Daniel↗

NASA NTRS2016

GeneLab Phase 2: Integrated Search Data Federation of Space Biology Experimental Data

The GeneLab project is a science initiative to maximize the scientific return of omics data collected from spaceflight and from ground simulations of microgravity and radiation experiments, supported by a data system for a public bioinformatics repository and collaborative analysis tools for these data. The mission of GeneLab is to maximize the utilization of the valuable biological research resources aboard the ISS by collecting genomic, transcriptomic, proteomic and metabolomic (so-called omics) data to enable the exploration of the molecular network responses of terrestrial biology to space environments using a systems biology approach. All GeneLab data are made available to a worldwide network of researchers through its open-access data system. GeneLab is currently being developed by NASA to support Open Science biomedical research in order to enable the human exploration of space and improve life on earth. Open access to Phase 1 of the GeneLab Data Systems (GLDS) was implemented in April 2015. Download volumes have grown steadily, mirroring the growth in curated space biology research data sets (61 as of June 2016), now exceeding 10 TB/month, with over 10,000 file downloads since the start of Phase 1. For the period April 2015 to May 2016, most frequently downloaded were data from studies of Mus musculus (39) followed closely by Arabidopsis thaliana (30), with the remaining downloads roughly equally split across 12 other organisms (each 10 of total downloads). GLDS Phase 2 is focusing on interoperability, supporting data federation, including integrated search capabilities, of GLDS-housed data sets with external data sources, such as gene expression data from NIHNCBIs Gene Expression Omnibus (GEO), proteomic data from EBIs PRIDE system, and metagenomic data from Argonne National Laboratory's MG-RAST. GEO and MG-RAST employ specifications for investigation metadata that are different from those used by the GLDS and PRIDE (e.g., ISA-Tab). The GLDS Phase 2 system will implement a Google-like, full-text search engine using a Service-Oriented Architecture by utilizing publicly available RESTful web services Application Programming Interfaces (e.g., GEO Entrez Programming Utilities) and a Common Metadata Model (CMM) in order to accommodate the different metadata formats between the heterogeneous bioinformatics databases. GLDS Phase 2 completion with fully implemented capabilities will be made available to the general public in September 2017.

Space Biology↗

NASA NTRS1990

OSI in the NASA science internet: An analysis

The Open Systems Interconnection (OSI) protocol suite is a result of a world-wide effort to develop international standards for networking. OSI is formalized through the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). The goal of OSI is to provide interoperability between network products without relying on one particular vendor, and to do so on a multinational basis. The National Institute for Standards and Technology (NIST) has developed a Government OSI Profile (GOSIP) that specified a subset of the OSI protocols as a Federal Information Processing Standard (FIPS 146). GOSIP compatibility has been adopted as the direction for all U.S. government networks. OSI is extremely diverse, and therefore adherence to a profile will facilitate interoperability within OSI networks. All major computer vendors have indicated current or future support of GOSIP-compliant OSI protocols in their products. The NASA Science Internet (NSI) is an operational network, serving user requirements under NASA's Office of Space Science and Applications. NSI consists of the Space Physics Analysis Network (SPAN) that uses the DECnet protocols and the NASA Science Network (NSN) that uses TCP/IP protocols. The NSI Project Office is currently working on an OSI integration analysis and strategy. A long-term goal is to integrate SPAN and NSN into one unified network service, using a full OSI protocol suite, which will support the OSSA user community.

Nitzan, Rebecca↗

DOE OSTI2025

Co-Simulation of PSS/E, OpenDSS, and PSCAD for Power Systems Stability Analysis With Inverter-Based Resources: Preprint

The increasing penetration of inverter-based resources (IBRs) is reshaping the dynamic behavior of power systems. IEEE standard 1547-2018 suggests that distributed energy resources (DERs) should provide grid services such as voltage and frequency supports. On the other hand, dynamic events caused by IBRs such as sub-synchronous oscillation have been reported. These developments necessitate improvement in the current modeling capabilities to better understand the interdependencies within power systems. These include interactions between transmission and distribution systems, among IBRs themselves, and between IBRs and conventional resources. In this paper, we present a co-simulation model integrating PSS/E, OpenDSS, and PSCAD to analyze IBR impacts on the stability of transmission and distribution systems. A key challenge in developing a co-simulation model is ensuring interoperability among different simulators (interfacing and data flow) while maintaining accurate results. Using the developed model, we simulate the impact of IBRs on power systems in two test cases: 1) fault ride through (FRT) capability during a generation trip contingency; 2) IBR-induced sub-synchronous oscillation. The results show the effectiveness of the co-simulation model.

24 POWER TRANSMISSION AND DISTRIBUTION↗

NASA NTRS1997

Study and Simulation of Enhancements for TCP (Transmission Control Protocol) Performance Over Noisy, High-Latency Links

The designers of the TCP/IP protocol suite explicitly included support of satellites in their design goals. The goal of the Internet Project was to design a protocol which could be layered over different networking technologies to allow them to be concatenated into an internet. The results of this project included two protocols, IP and TCP. IP is the protocol used by all elements in the network and it defines the standard packet format for IP datagrams. TCP is the end-to-end transport protocol commonly used between end systems on the Internet to derive a reliable bi-directional byte-pipe service from the underlying unreliable IP datagram service. Satellite links are explicitly mentioned in Vint Cerf's 2-page article which appeared in 1980 in CCR [2] to introduce the specifications for IP and TCP. In the past fifteen years, TCP has been demonstrated to work over many differing networking technologies, including over paths including satellites links. So if satellite links were in the minds of the designers from the beginning, what is the problem? The problem is that the performance of TCP has in some cases been disappointing. A goal of the authors of the original specification of TCP was to specify only enough behavior to ensure interoperability. The specification left a number of important decisions, in particular how much data is to be sent when, to the implementor. This was deliberately' done. By leaving performance-related decisions to the implementor, this would allow the protocol TCP to be tuned and adapted to different networks and situations in the future without the need to revise the specification of the protocol, or break interoperability. Interoperability would continue while future implementations would be allowed flexibility to adapt to needs which could not be anticipated at the time of the original protocol design.

Shepard, Timothy J.↗