Headers and Descriptors
In the Quest for Interoperability
|
Branko J. Gerovac |
David C. Carver |
|
|
|
Research in Networked Multimedia Information Services
Center for Technology, Policy and Industrial Development
Massachusetts Institute of Technology
MIT E40-218, 1 Amherst Street, Cambridge MA 02139, USA
Table of Contents
The popular, business, and scientific media are full of predictions and promises for the national and global information infrastructures. Information of all sorts (video, audio, pictures, text, and data) in many and varied formats will be composed to benefit personal, social, and business endeavors. What often goes unmentioned is that to achieve these promises requires solving several difficult technical problems.
One key problem is how to enable interoperability in an open communications environment - sharing data and technology across the variety of communications paths, equipment, and services. In digital communications, it is not readily apparent from simple examination what a stream of bits represents - "bits are bits". Headers and descriptors are a labeling mechanism to provide interoperability.
Our work on headers and descriptors is part of a continuing effort to understand and foster the convergence and interplay of computing, communications, and interactive media. The header/descriptor concept, as represented here, began with United States' efforts to define an advanced television system (aka HDTV). Some recognized that HDTV was "not just about television"[1] and needed to be considered in and would ultimately be driven by the broader context of high resolution systems and digital broadband communications. Cross-industry harmonization objectives, especially interoperability with digital computer and telecommunication systems, became formal selection criteria for the FCC's advanced television selection process.
Earlier related work[2] proposed a common header across communications environments (a "universal header"), and an evolving collection of "descriptors" to augment and describe the associated communications stream. In this paper, we explore the objectives and rationale underlying our work on headers and descriptors, and propose specific design concepts for achieving a truly universal header.
The vision and objectives behind this work go well beyond television systems. Digital television, due to its high bandwidth and demanding requirements, provides a fertile ground for investigation. However, easy sharing and preservation of data across heterogeneous systems is of fundamental importance to the formation of an attractive, accessible, and sustainable information infrastructure. Indeed, it is this goal, and not simply the market needs of advanced television that drive our efforts.
The rapid pace of technology overwhelms the traditional exhaustive standards development process. It is becoming critical to identify the few pivotal interfaces that are the foundation for smooth and effective evolution. The Internet Protocol (IP) and the Simple Network Management Protocol (SNMP) are noteworthy examples of this principle. IP is often characterized as the "center of an hourglass"[3], where on either side a variety of systems and services coexist, compete, and evolve. Similarly, SNMP provides a framework for controlling network objects. Since the adoption of SNMP there has been an explosion of activity in developing associated object definitions. Headers are about doing for data exchange, what IP does for transfer and SNMP does for control[4].
Data that is unambiguously self-identified has the characteristic of being recognizable and usable beyond its original context. This is important if your goal is to share data across a variety communications environments that may have little else in common. A header that encapsulates and identifies blocks of data can achieve this goal provided certain conditions are met.
There are alternatives to using a header, two simple ones are: (1) use an external (out-of-band) mechanism to indicate the format of a data stream or (2) adopt a single universal format across all environments. Suffice it to say that a universal format is not likely to be adopted any time soon. Formats, like languages, tend towards maximum expression and while a particular format may be good for some application environments, every attempt to define a universal format has failed. By defining a minimal construct, a header, that stands on its own and is relatively painless to adopt, we hope to approach widespread acceptance.
Identifying data out-of-band requires indicating when or where in a data stream a format transition occurs, i.e., synchronization. For this reason, the format of data within a given stream usually remains fixed. If multiple formats are required, either a single sufficiently expressive "multimedia" format is sought, or multiple streams of different formats are used. There are other liabilities to keeping identifying information separate from the data it identifies. What format is used for exchanging identity information? What if identity information is never transmitted? What if it is lost? Data could be anything and unless its format is discovered, the loss is catastrophic. Making data self-identified avoids these problems.
A header provides a point of commonalty across data formats that permits coexistence, competition, and evolution of applications and services on one side and data transfer systems on the other. It is not a complete answer to the problems of data interchange. It does not, in isolation, ensure interoperability, longevity, etc. It is, however, a building block with a low cost and comparatively high return that accrues over time.
While this paper is primarily concerned with the objectives and design of a universal header, it is important to put into perspective the associated concept of descriptors. There are two distinct notions of what descriptors convey: (1) ancillary application oriented information that improves the usefulness of data to users and applications (e.g., annotations, origination information, digital copyright, etc.), and (2) parametric information necessary for proper interpretation of messages, for example, uniform description of colorimetry or sampling grid parameters across imaging standards.
Rather than defining specific instances of descriptors or specific descriptor formats (which would be unresponsive to our broad description of the problem) our approach is to define a descriptor framework (a collection of conventions, recommended practices, and cornerstone standards) that provides the necessary conditions for a broadbased community effort. Again, a comparison to SNMP is appropriate. SNMP provided a simple framework that launched a major community effort to define a collection network management information objects.
One key objective of a descriptor framework is to enable experts in diverse disciplines to define information objects appropriate to their needs. Further, the approach taken should encourage groups to export objects for use by other groups, and to import and incorporate objects defined elsewhere . It is important to allow the use of conventions, language, and methodology native to a variety of disciplines, and not to burden potential users with new highly technical methodology, e.g., having a group of copyright lawyers negotiating the bit encoding of a digital copyright message is probably not the best use of their time and expertise.
Finally, a relationship between headers and descriptors must be defined. One option is to define descriptors as an extension to the header. In this approach, a message header provides some indication of whether or not a descriptor is present. Defining a special relationship between headers and descriptors provides direct support for associating descriptors with a message. The liability of this approach is that it tends to complicate the header and thereby to complicate acceptance. The alternative, and one we intend to explore further, is to define descriptors as complete messages and for them to have no special relationship to headers. By so doing, headers remain simple and light-weight enough to solve the association problem by structuring (nesting, sequencing, etc.) the data stream. In this approach, descriptors are best thought of as a set of well known, broadly used message types - a construct that directly supports the ability for independent groups to freely define and exchange descriptor definitions.
The following objectives form the basis for design criteria that drive the definition of the header. For each objective, there is its title, a brief statement of the objective, and a discussion of its ramifications and significance to the design of the header.
Many of the objectives are interrelated and/or interdependent. Some objectives are further refinements of other objectives. Design ramifications and implications are sometimes the result of the interaction among two or more objectives. Thus, the descriptions here are to be taken as a whole.
The header should uniquely identify the encoding employed for the body of a message and thereby indicate how the data is to be interpreted.
Description
Unambiguous self identification is a major feature of a header. The header identifier specifies which of possibly many encodings (or standards) is used in the payload of the packet. The identifier needs to be unambiguous in this specification -- there should be no confusion of which encoding is being specified, no additional data should be necessary to determine the specification. A machine that is functionally capable of interpreting the data stream and that knows about the particular standard (among others) need only look at the identifier to determine how to proceed with the next step to interpret/decode the packet.
Ramifications
Uniqueness. Identifiers must be unique both internationally and across industries. When an identifier is extracted from the data stream, there should be no ambiguity as to meaning.
Completeness. The header format must be "fully defined", to avoid ambiguity. Were the format not fully defined, it would not be possible to guarantee the extraction of the identifier.
Sufficiency. Only the identifier should be "necessary and sufficient" to determine how to proceed with interpretation of the payload. A compliant machine may need additional information (or programming) to interpret the payload, but the identifier should fully determine how to proceed. (Note this does allow the use of in-stream parametric data for proper payload interpretation as identified by the format. Such parametric data would be incorporated in a descriptor or embedded in the payload as defined by the referenced format.)
The header should be designed to last a long time, at least 30-50 years. This objective is particularly important in the film and television industries where content and formats created nearly a century ago still have value.
Description
Much of the material that will be generated will have a long useful lifetime -- e.g., entertainment movies, significant news events, and historically important personal, scientific, and business records (among others). It is certainly desirable that a header mechanism used for them will be valid for a long time. The choice of 50 years as a metric of longevity is somewhat arbitrary -- ranges of 30-50 years appears to be consensus. It implies consideration beyond planned technological innovations, yet recognizes that eventually technology may outstrip what can be imagined at any initial definition.
Ramifications
Forward Looking Specification Spaces. Longevity has ramifications to both header length and identifier fields. Both need to be consistent with current needs, yet have large enough "specification spaces" to be appropriate for the future.
Maximum Length. A header could be associated with large datasets. In motion picture applications, for example, a header might be associated with an image or sequence of images. Thus a header must be able to specify message sizes appropriate for current uses, yet accommodate likely advances in technology. Again, for motion pictures, the major factors determining message size are: number of frames, raster size, dynamic range, and compression factor. Today, typical message sizes for imagery are on order 1 MB -- some applications are smaller, some larger. To support resolutions that match high quality film or high resolution wall-size displays may require on order 1 GB.
Number of Unique Identifiers. The number of potential coding schemes to be specified by the identifier field is harder to gauge. Only a relatively small number of coding schemes are often envisioned, perhaps a few hundred, and hopefully, the number of standards will be small. However, technology will permit coding schemes to proliferate. Further, a structured identifier value (rather than a simple numerical ordering) may be helpful in administering and interpreting identifier values.
Identifier Immutability. The value of an identifier and its referenced standard once assigned must be "immutable". Practically, it is not possible to update unambiguously the meaning of an identifier across hundreds of millions of machines during a transition. Mutability also fails considerations of universality, longevity, and low cost implementations.
Identifier Registry. To achieve effective harmonization, some organization(s) needs to be the central authority(ies) to allocate and catalog standard identifiers, and/or a well-defined registration process needs to exist. Universality suggests that an appropriate name space be used and attention given to international standards, standards bodies, and processes. Longevity and unique identification objectives, in combination, indicate that an identifier and its specified encoding once assigned and registered should not be reassigned or redefined.
Experimental and Pre-Standardization Uses. To get around the liabilities of a heavy weight system of identification (as the above points imply), special consideration should be given to experimental and pre-standardization uses. There should be a well-defined method for using the header without preregistering a specific identifier, and thereby, without needlessly littering the identifier name space and without delaying experimental/research activities due to registration processes. Thus, experimental systems would use special identifiers, and thus, would exist in a closed environment for which the particular identifier has meaning. In the open environment, experimental identifiers could contain embedded interpretation information, or an identified source (instead of a registry) could be queried for instruction on how to interpret the payload.
The header should permit optimal sharing of data streams across acquisition, distribution, and presentation technologies, equipment, and services.
Description
A primary motivation for the header (regarding self identification) comes from the realization that material generated for one application will be useful in other contexts -- in whole, in part, or in combination with other material. It will be possible to share material among media, carrier, and equipment technologies and services, including:
* electronic and film image-capture devices
* narrow- and broad-bandwidth transmission media - electromagnetic spectrum (terrestrial, cellular, and direct broadcast satellite) - digital networks (optical fiber, co-axial cable, and twisted pair wire)
* computers and digital signal processing devices
* magnetic and optical mass storage media
* high- and low-resolution display devices
* printing (hard copy) and publishing media
Thus, interoperability refers to:
* the ability for data producer and consumer equipment (e.g., clients and servers) from the largest variety of sources to exchange data
* the ability to exchange data among a variety of uses (i.e., industries and applications)
* the ability to migrate data among production environments (e.g., field capture, studio production, post production, storage, distribution, etc.)
* the ability to transport data via and among a variety of media, terrestrial broadcast, telecommunication networks, computer networks, point to point connection, disk, tape, etc.
* careful selection of data types so as to permit operation in a variety of systems
Ramifications
Well-Formed Public Definition. A header that permits interoperability is well defined and publicly available. Only then can equipment and application producers comply with header requirements, and users be assured that equipment and material from a variety of sources can be used together.
Alternate Standards. Several standards setting bodies are developing and evaluating a variety of data interchange standards. The header needs to provide value to or at least accommodate emerging standards and practices.
Historical Conventions. Several uses/conventions are historically significant and represent a body of existing material and experience, e.g., film and video production, synthetic imaging, computer graphics, animation, special effects, simulation, etc. Though a header does not address these specifically, it should be able to accommodate existing usage.
Transcoding. Given the variety of potential encodings/standards, it will be necessary to translate from one encoding to another. The header should enable transcoding where transcoding is possible, and permit intelligent failure response (e.g., user friendly notification or automated algorithm lookup) when transcoding is not possible.
All data streams should incorporate the header.
Description
With the existence of a universal header, major application areas and uses of video data streams can cross the fundamental hurdle of interoperability. A minimal header of some sort is needed by all video data encodings. A common header permits multiple encodings to exist harmoniously on a single transport data stream and for all equipment to handle (if not interpret) the data stream. Further, individual application areas will gain broad utility by incorporating a universal header (and hopefully, will not see benefit to point solutions).
Ramifications
Compliant Low Cost Receivers. The desire for broad use translates into the need to minimize cost to the user and thus to the user's equipment. Low cost receivers (especially in the near term) may be limited in their ability to handle the full scope and flexibility that the header mechanism will provide. Universality requires that:
* low cost implementations be considered in the header design,
* all compliant receiver implementations recognize the header, and properly interpret those fields appropriate for its operation,
* all operations be specified/specifiable using the header mechanism, i.e., no out-of-band data streams,
* all compliant data streams incorporate the minimal header.
Compliant Data Stream. A minimally compliant data stream implementation should include a properly encoded minimal header designating message length and identification.
Cost/Performance Effectiveness. The minimum header should be straightforward to decode so that low cost equipment (as well as high performance, high quality equipment) can be implemented that recognize and properly interpret the header for their operation. Though all implementations will recognize the header, some may choose not to decode all possible data formats in order to achieve lower cost.
Compactness. Use of the header should incur a relatively small overhead on the underlying data stream. Compactness is a relative requirement. Video data is typically communicated or stored in large messages. Furthermore, as a rule, small messages are either infrequent or aggregated into larger messages. Thus, the requirement for absolute minimum compaction is less severe. However, the less compact the header, the greater is the incentive for users of smaller messages to employ other schemes, thus undermining the objective of universality.
Easy Insertion and Deletion. While header design should be low cost and convenient to incorporate, it is only realistic to assume that there will continue to be environments where the header is not used. Thus, the header design should take into account the ease of removing headers from a data stream upon entering alternative environments and adding them when leaving. This is also important in environments where the format of a data stream is context dependent or negotiated dynamically.
Transfer System Independence. The objectives of interoperability, longevity, and universality all imply that the header should function independently of the underlying data transfer (transmission or storage) system. This makes it easier for data to move across different transfer regimes, reduces the chances that the header design will duplicate and/or conflict with features of the underlying transfer system, and allow for continued improvement in transmission and storage technologies.
Sovereignty. Though it is certainly desirable for universality and interoperability that there be a small number of standards spanning across national boundaries, economic communities, and trade agreements, it is only realistic to assume that there will be political desires for sovereignty in standards designations. Though this is not a technical issue (per se) and cannot be guaranteed by the header design, the structure of the identifier field and its relation to international standards organizations needs to be carefully considered and appropriate allowances made.
Standards Compliance. Universality is enhanced by recognizing the past and ongoing efforts of standards bodies. Where existing standards and practices are applicable to meeting design objectives, they should be considered.
Varied Requirements. Different applications will use different combinations of data formats and place different requirements on the data stream:
* high resolution imagery - high bandwidth and large data sets
* live action/interaction - low latency and rapid capture
* broadcast, interactive, and off-line usage
* annotation and data tagging - editability
Such varied requirements are a major factor in needing to support a large number of data types and formats.
The header should be able to incorporate future unforeseen technological and algorithmic advances and improvements in quality, performance, and functionality without obsoleting existing components and infrastructure.
Description
Development of digital processing for video compression and communications across diverse media is progressing very rapidly. No fixed data encoding (nor small number of standards) will meet longevity requirements.
Ramifications
Large Numbering Scheme. To enable longevity, the header design should provide a large enough numbering scheme. A proliferation of standards, something generally considered undesirable, needs to be anticipated. Administration of the number space is also important. Sparse allocation could lead to fragmentation and a significant reduction in the effectively usable number space.
Flexibility. Given the variety of applications and transmissions environments envisioned, the header must be flexible both in its design and use.
At a given time, uniform generation, transmission, and display characteristics can support a range of quality and cost. Though more a property of the particular data encoding, the header format should permit scaleable encodings.
Description
Scaleability is an objective at several levels. Data streams should scale to accommodate a wide range of transmission and reception conditions (e.g., a scaleable data stream encoding would permit different display devices to extract different raster sizes/resolutions from the same data stream). The cost of equipment should scale according to quality and capability. Services should scale to accommodate an ever increasing number of users without serious degradation in performance.
Ramifications
Negotiation. In two way communications, the receiver could negotiate with the sender for the appropriate video signal quality based on how it is presented -- e.g., lower bandwidth required for lower quality pictures -- thereby maximizing the utility of equipment and communications channels. (Further, communications congestion, transmission cost, transmission errors, etc. also could be handled by negotiated graceful degradation.). The header should enable (provide a basis for) negotiated service characteristics.
Defining a header would seem a simple task, and a solution can seem obvious or the problem even irrelevant in the narrow context of a specific application, communications environment, or engineering discipline. To the contrary, we encountered a number of issues that stem from our attempt to reconcile the objectives described above with standards, practices, and even language used in different industries. Initially, we considered including a discussion of these issues, but decided against it. By letting the objectives stand on their own, we hope to leave the door open to a range of alternatives, even ones that say a header of the sort we propose isn't needed. Whatever your favorite header scheme, we hope this provides a suitable framework for evaluation and comparison across alternatives.
The MIT Research Program on Communications Policy was established in 1974 by the late Professor Ithiel de Sola Pool, a pioneer in conducting research on the interplay of communications technology, policy, and economics. For over 20 years, the program has focused on key issues and events leading to recognition of the information infrastructure and its corresponding societal ramifications. It has become a partnership of industry, government, and academia interested in accelerating development of the information infrastructure. Its multidisciplinary structure combined with MIT's strength as a center of communications technology development, is especially suited to the volatile market and regulatory context in which the National Information Infrastructure (NII) is developing.
Colleagues who graciously agreed to review and comment on this work asked whether or not we could give concrete examples of what we mean by "Headers and Descriptors". We want to satisfy this need, but there is danger in doing so. We see a slippery slope that threatens to undermine the primary contribution we are trying to make or, if you will, bring us down from the high ground we are trying to take. Nevertheless, there are a few of obvious examples, primarily standards, that bear a clear relationship to the header and descriptor concept.
One example is the Multipurpose Internet Mail Extensions (MIME) standard. MIME extends Internet mail message headers to allow for, among other things, non-text message types. MIME is also used in transporting data in the World Wide Web. Another is the ISO MPEG Systems standards. MPEG Systems provides for the multiplexing, encapsulation, and description of MPEG audio and video data. In MPEG-2, the Systems specification allows private and registered data types in addition to MPEG audio and video. MPEG-2 is being adopted for use in digital television transmission systems. A third is the ISO MHEG standard. MHEG defines a comprehensive syntax for composition and transfer of multimedia and hypermedia content. Finally, there is the ISO/ITU Abstract Syntax Notation One (ASN.1) standard. ASN.1 is a general purpose notation for describing data types to be communicated. Associated encoding rule standards are used to encode data types described in ASN.1 into transmittable bit sequences. ASN.1 provides a method for referencing externally defined data types using the ISO/ITU data type registration system. ASN.1 is employed in the ISO MHEG and Internet SNMP standards.
This list is not complete and the examples provided are not mutually exclusive. While each of these clearly attempt to satisfy some of the objectives discussed above, none seem to provide a complete and universal solution.
Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, 1994.
Bosco, P., "Networked Multimedia Information Services," MIT, September 1993
Coding of Moving Pictures and Associated Audio, MPEG-2 Systems, International Standards Organization, Draft International Standard 13818, 1995.
Computer Systems Policy Project, Prospectives on the National Information Infrastructure, Computer Systems Policy Project, Washington D.C., 1993
COHRS, Committee on Open High Resolution Systems, 1990
Council on Competitiveness, Competition Policy: Unlocking The National Information Infrastructure, Council on Competitiveness, Washington D.C., December 1993
Gerovac, B., and Solomon, R.J., "Protect Revenues Not Bits" International Multimedia Association, Cambridge, 1994.
Information Infrastructure Task Force, "What It Takes To Make It Happen: Key Issues For National Information Infrastructure Applications," Committee on Applications and Technology, December, 1993
Information Infrastructure Task Force. "Intellectual Property and the National Information Infrastructure." July 1994.
"Intellectual Property Rights In An Age of Electronics and Information.", U. S. Congress Office of Technology Assessment, Washington D.C., 1986.
Internet Economics Workshop Notes, MIT Research Program on Communications Policy, March 30 & 31, 1995.
"Networked Multimedia Information Services", Massachusetts Institute of Technology, Dartmouth Medical School, Carnegie Mellon University, 1993
Neuman, W. R., "Waiting for the Network to Happen," Testimony before the House Subcommittee on Telecommunications and Finance, October 1989;
Neuman, W. R.; McKnight, Lee; and Solomon, Richard. The Gordian Knot, MIT Press, (forthcoming).
Postel, J. B., "Internet Protocol", Internet RFC0791, September 1981.
"R&D for the NII: Technical Challenges," Report on the Workshop, February 28 & March 1 1994.
Rose, R. T., "The Open Book: A Practical Perspective on OSI", Prentice Hall, Englewood Cliffs, NJ.
Schoffstall, M., Fedor, M., Davin, J., Case, J., "A Simple Network Management Protocol (SNMP)", Internet RFC1157, 10 May 1990.
Schoffstall, M., Fedor, M., Davin, J., Case, J. "Multipurpose Internet Mail Extensions, Part 2", Internet RFC1522, 23 September 1993.
Schrieber, W. F., Fundamentals of Electronic Imaging Systems, 3rd ed, Springer-Verlag, New York New York, 1993.
"SMPTE Task Force on Header/Descriptors, Final Report", SMPTE Journal, June 1992.
Solomon, R.J., "Perspectives on the Implementation of Broadband Infrastructure," in Elton, M., ed., Integrated Broadband Networks, North Holland, 1991.
U.S. Congress, Office of Technology Assessment, Intellectual Property in an Age of Electronics and Information,, Washington, D.C.: U.S. Government Printing Office, 1986.