Protect Revenues, Not Bits: Identify Your Intellectual Property
by Branko Gerovac and Richard J. Solomon
ABSTRACT
Work-in-progress by the television and motion picture community for a digital
imaging header is described. This is not a utopian solution for all media and
applications, but such a header would aid in tracking, auditing, and
particularly identifying imaging bitstreams, an important parameter for
intellectual property protection.
"The New World Order is no longer about bullets,
but about bits." -- the villain in Sneakers. ((c)1992.
Universal Pictures Inc.)
The Sneakers villain missed the whole point of the digital revolution: One
makes money -- lots of it -- not by stealing bits, or by altering them, or by
just moving them around. That's penny ante stuff. Big money is made by
adding value to the bitstream. Until we understand the concept of
value-added, toiling in the minutiae of digital information protection can be
fairly unproductive.
The stored program computer has changed the basic concepts of what intellectual
property is about. Combined with high-speed digital telecommunications,
high-performance computing permits an ease of storage, retrieval, manipulation,
and transmission -- and replication -- completely at odds with our
notions of "copy" rights based on 400 years of the printing press. The idea of
a machine that can program itself to hide its tracks, copy ad infinitum
and effortlessly without introducing a single bit error, and send its output
around the world at the speed of light without consuming the original is
still something that the average person finds difficult to comprehend (despite
widespread and growing use of tens of millions of these devices).
[1]
While other distributive mechanisms have made it more difficult to protect
creative rights over the centuries, computer/communications poses a unique
dilemma because of the increasing scale, speed, and power of digitally-based
network technologies. But before we discuss the subtleties of computer
technology and some potential tools for controlling the flow of digitized
works, it is important to note that the goals of information owners,
distributors, vendors and packagers are as diverse as the implementations and
applications. There is no total "solution," technical or otherwise, to the
intellectual property "problem." Yet, by narrowing our focus we can devise some
useful strategies which would facilitate electronic distribution and still
maintain sufficient income streams to compensate artists, investors, and
network providers.
If we are concerned with money flows -- that is, with whether the intellectual
property owner gets paid or not -- then, as in all successful businesses, the
key is to recognize what generates revenue and what is trivial. However, if we
are concerned with artistic rights, privacy rights, cultural heritage, or
accuracy in presentation, then our goals may be different and the technical
fixes may also be different.
In this paper we describe work in progress by the television and motion picture
community for a digital header. This is not a utopian solution for all media
and applications, but such a header would aid in tracking, auditing, and
particularly identifying imaging bitstreams.
Not that the other goals are not important. It is recognized that digital
information flows not only change the concept of intellectual property, but
change the way the global society works and interacts. For example, it is
obvious that any system for tracking the flow of intellectual property, or the
reverse flows of compensation, creates audit trails of metainformation.
This is an inherent offshoot of tracking value-added bitstreams, and it has
intrinsic value itself. That is, metainformation can be more valuable (to
whomever controls its use) than the information being audited!
Kenneth Phillips deals with the intersection of intellectual property
protection and metainformation in another paper at this workshop.
THE LOCUS OF CONTROL
The concept of copyright is rooted in the technology of print.[2] Until the computer, all other distributive mechanisms were
merely mild disturbances to the idea that property rights could be physically
controlled by control of the press, for the other mechanisms had similar
features to the press in that the device, transmitter, record pressing plant,
film duplicating machinery, etc., could be located in space, time, and
pocketbook. Computer/communications changes all that.
The press pre-dated the idea of a "copy right," and it is not irrelevant to
point out that the recognition that there could be a property right in text,
and a practice of paying royalties[3] emerged when
the printing press reached a stage of development where it threatened the
sovereign's hegemony. King Phillip and Queen Mary of England, in 1557, in an
effort to stop seditious and heretical ideas from being circulated in their
realm, limited the right of printing to members of the Stationers' Company. The
Company was given the right to search for and seize anything printed contrary
to statute or proclamation with draconian measures prescribed for violators and
resistors.[4] By 1565, the Company created a system of copy
rights for their members, thereby both privatizing the state function of
censorship (surely more efficient with a profit motive) and simultaneously
creating a novel monopolistic business practice.
Copyright attorneys tend to dismiss the historical background as a distraction,
yet this misses the critical point of copyrights as an intellectual property
gatekeeper -- determination of the locus of control using a technology
which served as a barrier to entry to the marketplace. Because numerous copies
were made in one place -- on huge and relatively expensive presses -- it was
feasible to identify the source, number, and often the destination of printed
materials by human oversight. So, the printshop, at that time in history, was
the practical point to apply control, whether for profit or against heresy, or
both. Yet, even then "the increasing number of works made it impossible to
acknowledge every sermon, almanac, and ballad."[5] For modes
of reproduction where such an easy locus did not exist, the concept of
copyright was not applied under common law. Until quite recently, copyright was
not applied to conversation, speeches, jokes, or singing of songs, whether in
private or public. (Perhaps we may consider, along with the technologies of
mass replication, that the associated technologies of selective audio and image
capture may have extended the locus of control.) Copyright, until
the modern age, remained a specific protection applied to (or with) a specific
technology; though in democratic and free nations it was rarely used
successfully for censorship, but instead to protect fiduciary and other
rights.
PAPER VS. BITS
The technology which permitted audit and control was not so much the press
itself, but the mechanism of pressing ink to paper media. We have seen the
evolution of technology increasingly strain the use of copyright laws as a
societal device to funnel money back to the property owners, as well as
effective protection against fraud, alteration, etc. First came cheaper
presses, then photographic devices, machine typesetting and the steam-driven
press, audiographs, mimeographs, cinematography, television, xerography, and
then broadband appliances of all types. Each changed the loci, the economics,
and the manipulation of media, making infringements harder to police and even
harder to define.
With the computer and its appliances, if not now, soon we will be able
to seemingly make a perfect duplicate of anything, from the Gutenberg Bible to
the Elgin marbles, without consuming the original. Property rights used to deal
with tangible property; the physical incarnation of a bit may be in tangible
form at some instant in time, but they are volatile, elusive, and the process
that manipulates bits inherently covers up its tracks as it copies the
bits from one register to another, from one part of memory to another, from one
end of a network to another -- that is just the way a von Neumann machine[6] works. In any open network of millions upon billions of
programmable logic devices, an audit path not only is a messy concept, but it
is meaningless except for very tiny slices of time. There is no such thing as
an "original" because all "copies" are originals, as well.
The machine is at once a series of processes, concepts, and syntheses of human
(and maybe machine) intelligence -- so mixed that it is difficult to separate
its parts from the whole. And since the Turing definition of this
stored-program machine still holds, the machine can change its own
instructions, redefining itself, and becoming a new machine in a
twinkling. A network of such machines permitting instantaneous transfer of
digitized information is not what the Stationers' architects had in mind when
they privatized heresy control. The idea of the nationwide -- or global --
"machine room," whereby for some small slice of time in the middle of the
night, every unused processor, PC, and switch on the Gigabit network performs
some part of a virtual process, begs the questions of digital copy rights, much
less finding the control locus for auditing.
What are we to make of this confusion? Basically that we are upon a wonderful
new way to add value, not subtract, steal, or transfer value.
2[32]
The law of geometric increase is the critical publishing idiosyncrasy in the
digital environment. If you electronically mail a copyright article to two
correspondents, and then they each send a copy to two others, ... and if
each recipient retransmits the article, say, every 15 minutes (only a stroke of
a key on a computer terminal) to two others, how long before the whole world
sees it?[7] Two to the thirty-second power is 4.29 billion
(not coincidentally, the same as the address space for a 32-bit central
processor).
How then can we convert the added value of the bitstream into a revenue stream?
The tool that needs to be developed to identify proper use of the revenue
stream can be the same tool used to uncover improper rights infringements.
Small, self-identifying blocks of data in a designated bitstream may work in a
mass media environment if only because to sell, distribute, and create a demand
for mass productions you cannot hide. The SMPTE[8]
header/descriptor is such a tool.
THE SMPTE HEADER/DESCRIPTOR WORK-IN-PROGRESS[9]
Early in the FCC's advanced television selection process there was recognition
that "HDTV is not just about Television."[10] This
eventually prompted a cross-industry harmonization effort to encourage future
ATV/HDTV[11] standards to be interoperable with computer and
telecommunication practices. The issues that we have noted for the protection
of intellectual property, that in digital systems "bits are bits," and that
distinguishing one kind of data from another is key to use of the data, found
their parallels in the HDTV process as well.
It is now accepted by the FCC Advisory Committee on Advanced Television Systems
(ACATS) that in order to share high-resolution image data across systems and
industry boundaries a universal header/descriptor is required. A header
structure also must support digital transmission of video sideband information
(closed captioning and secondary audio programming) as well as potential new
types of information (image coding parameters and digital copyright
signatures). That is, the header must be "extensible" for future needs not
anticipated today. This is easily done by designing a structure without
limiting the contents of the header/descriptor itself.
In 1990, the FCC formally adopted "interoperability" as a ATV selection
criteria; FCC Planning Subcommittee Working Party 4 (PS/WP4) was directed to
establish interoperability criteria and to evaluate HDTV proponent systems
accordingly. In parallel with this formal governmental process, two Society of
Motion Pictures and Television Engineers (SMPTE) task forces were formed: the
Header/Descriptor task force to investigate issues and solutions related to
identification and description of digital video streams, and the SMPTE
Hierarchy task force to investigate scalability and other broader architectural
issues. Membership of the SMPTE task forces was open to anyone in the world,
and numerous trans-oceanic teleconferences for the working meetings were held
in this regard. Electronic mail via the worldwide Internet has been heavily
used to keep all interested parties informed, including non-members of the task
forces. Fax distribution lists supplemented the e-mail; the use of electronics
contributed to speeding up the process.
The SMPTE task forces provided input to PS/WP4 as well as set the stage for
future SMPTE standards and recommended practices. The Header/Descriptor task
force finished its work and produced a final report on January 3rd, 1992, which
appeared in the June issue of the SMPTE Journal. In April, a SMPTE
working group was formed to take the task force report and produce a
standard.
The FCC working party has considered a family of standards with the header
common to all environments. The header plays a central role coordinating
content, transmission methods, and application types.
Headers (and descriptors) are fundamentally data representation objects which
enable exchange and proper interpretation of data in heterogeneous
environments. The proposed SMPTE structure is but a small part of a greater
architectural framework for advanced, digital information systems and networks.
The general structure under study provide guidance for the identification of
digital intellectual property, as well.
The definitions and structures discussed are derived from current practice in
the telecommunications and computer industry. When television standards were
set in the early 1940s and 1950s, the need for such practice was not prevalent
in broadcasting environments, however the introduction of sophisticated tape
editing, digitized capture and storage, and the use of video in many other
areas other than over-the-air broadcasting has created a set of ad hoc
standards that are on the evolutionary path to true interoperability. So things
like the SMPTE time code should be seen as an early element of header
architecture.
HEADER OBJECTIVES
The following objectives form the basis for the Header's design criteria that
drive the definition. 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.
Unambiguous Self Identification
The header should uniquely identify the encoding employed for the body of a
message and thereby indicate how the data is to be interpreted.
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.
Universality
All video (and associated) data streams should incorporate the header.
Ramifications
Compliant Low Cost Receivers. The desire for broad use of video services
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: (a) low cost
implementations must be considered in the header design; (b) all compliant
receiver implementations must recognize the header, and properly interpret
those fields appropriate for its operation; and (c) all compliant data streams
must incorporate the minimal header.
The minimum requirements for a "header compliant receiver" are:
- a minimal implementation must recognize the header length field and
interpret it to determine message length -- a minimal implementation must
recognize the universal identifier field (and subfields) and interpret it to
determine whether the data is appropriate to its operation
- all operations must be specified/specifiable using the header mechanism,
i.e., no out-of-band data streams -- no implementation will incorrectly
interpret header fields
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
streams 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.
Compliant Data Stream. A minimally compliant data stream implementation
should include a properly and fully encoded minimal header designating message
length and identification.
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 relationship to international standards organizations need to be
carefully considered and appropriate allowances made.
Standards Compliance. Universality is enhanced by recognizing the past and
existing work of standards bodies in relation to the design of the header.
Where existing standards and practices are applicable to meeting design
objectives, they should be considered.
Interactive (two-way) and Broadcast (one-way) Communication. The header and
protocol should support both interactive (two-way) and broadcast (one-way)
communication. The major implication here is the need for a control protocol to
manage information exchange in both kinds of environments.
High Bandwidth/Low Latency Application. The header and protocol should
support full motion (e.g., high bandwidth), live action (e.g., low latency), as
well as off-line (e.g., post production and storage) applications.
LONGEVITY
The header should be designed to last for a long time. SMPTE suggests 30-50
years, based on the apparent lifetime of today's TV systems, but if we consider
how many documents used daily in law, religion, literature and general culture
date back hundreds, even thousands of years, we might want to consider the
impact of designing a digital structure that could be at least decoded by our
heirs many generations hence.
Ramifications
Forward Looking Specification Spaces. Longevity has ramifications for 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. Typically, a header will be associated with a frame or
group of frames. (Occasionally, much shorter messages will be used in some
situations for general control and information.) The "length field" must be
able to specify message size appropriate for current uses, yet accommodate
likely advances in technology. The major factors determining message size are:
number of frames, raster size, pixel size, and compression factor. Today,
typical message sizes for imagery are on order of 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 of 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 entails
considerations of universality, longevity, and low cost implementations.
Identifier Registry. To achieve effective harmonization, one or more
organizations need to be the central authority to allocate and catalog standard
identifiers, and/or a well-defined registration process needs to exist. Perhaps
the intellectual property organizations (WIPO, UNESCO) could coordinate this
with the ITU and ISO.[12] Registration procedures are
largely outside the scope of design of the header. However, universality
suggests that attention in the design be 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. It is desirable to provide a
well-defined method to use the header structure 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.
Interoperability
The header should permit optimal sharing of data streams across generation,
carrier, and equipment technologies and services.
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 only then can a user be assured
that equipment and material from a variety of sources can be used
together.
Varied Requirements. Different applications place different requirements on
a video data stream. For example, some applications will require very high
resolution, others not; some applications will require special objective color
spaces; others will simply need to appear nice; some applications will need
multichannel high-quality audio, others will be silent; etc. Such varied
requirements are a major factor in needing to support a large number of
standards identifiers.
Alternate Standards. Several standards setting bodies are developing and
evaluating imaging standards.
Historical Conventions. Several uses/conventions are historically
significant and represent a body of existing material and experience, e.g., 24
Hz (frames per second) film, NTSC/PAL/SECAM video production, synthetic
imaging, computer graphics, animation, special effects, simulation, etc. Though
a header design does not address these specifically, the header 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.
Extensibility
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.
Ramifications
Large Numbering Scheme. To enable longevity, the header design should
provide a large enough numbering scheme to incorporate future unforeseen
alternatives, improvements, and advances in quality, performance, and
functionality: 1) the specification space of the header (the length and
identifier fields) should be big enough to accommodate future expansion; and,
2) extensibility should not obsolete existing compliant equipment and
transports.
Flexibility. Given the variety of applications and transmissions
environments envisioned, the header must be flexible both in its design and
use.
Scalability
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 scalable
encodings.
ABSTRACT SYNTAX NOTATION
The SMPTE Header is derived from an existing ISO/ITU(CCITT) standard in common
use within the computer and telecommunications industries called Abstract
Syntax Notation 1 (ASN.1). ASN.1 is a comprehensive and extensible tool for
describing data interchange in heterogeneous transmission and storage
environments. One of it features is that ASN.1 does not exclude other
standards, but acknowledges existence of alternative methods and provides a
mechanism with which to identify and reference any data, whether defined
in ASN.1 or not.[13]
It is much like a programming language, such as C, Pascal, or PostScript. A
collection of software tools and utilities to support ASN.1 has been developed.
Built in data types include primitives (integer, Boolean, string, etc.), and
constructors (sequence, choice, etc.) that can be used to build arbitrarily
complex data structures. This process is recursive: types can be constructed
from other constructed types. Thus arbitrarily complex structures and
substructures may be defined. Furthermore, components of constructed types may
be optional, allowing for even greater flexibility.
ASN.1 supports the notion of embedding, which allows one or more data
structures to be contained within another. Thus, a sequence of frames can be
embedded within an outer header (or envelope) that labels a program segment.
This can be taken to coarser granularity -- shots, scenes, programs, etc.
Similarly, it can be taken to finer granularity to embed audio tracks, closed
captioning, descriptors, etc. within individual frames.
Two valuable features of ASN.1 include:
- Separation of data description (Abstract Syntax) and data encoding
(Transfer Syntax or Encoding Rules). Data structures are described in a
human-readable syntax and automatically translated into bits and bytes for
transfer. So,
- Deployed ASN.1 compliant systems may interpret new structures without
hardware modification.
The following excerpt is extracted from a tutorial prepared for the SMPTE
header committee:[14]
The SMPTE Header is a compatible subset of the ASN.1 EXTERNAL type. All ASN.1
compliant protocol interpreters can extract and interpret an EXTERNAL without
ambiguity. Its definition is quite flexible, but some components are optional
allowing for a minimal header that is simple, compact, and easily recognized.
The ASN.1 notation for EXTERNAL is formally defined in ISO 8824.
EXTERNAL is a constructed type, meaning a sequence of primitive ASN.1 types,
and is encoded with the same basic tag, length, value format described above.
A tag value of 40 decimal (or 28 hexadecimal) identifies the EXTERNAL type and
indicates the value is defined outside the current ASN.1 context thus the
identifier component indicates what standard to apply in decoding the value.
Length indicates the number of octets (octet is the ASN.1 terminology for an
8-bit byte) occupying the remaining message (total message size less octets
used for EXTERNAL tag and length) and is encoded in the usual manner as
described above.
Thus all SMPTE headers start with the EXTERNAL type tag and length fields. The
EXTERNAL tag and length fields for a 1010 octet EXTERNAL value (a 1000 octet
payload prepended with 10 octets of identifier) would occupy 4 octets with the
following hexadecimal representation:
EXTERNAL tag indicates beginning of the header [ tag ]
| EXTERNAL length occupies the next 2 octets(s) [ length ]
| | EXTERNAL value occupies the next 1010 octets [ ... ]
| | | EXTERNAL value [ value ]
| | | |
28 82 03F2 xx ... xx
The EXTERNAL value is a sequence of three fields: direct-reference,
indirect-reference, and payload. Each field is a primitive ASN.1 type, and is
encoded using the usual tag, length, and value format (see section 3.3). The
direct-reference and indirect- reference fields are optional; A header may
contain one or the other, or both. Tag fields are used to indicate the
inclusion of optional fields:
[ tag= 28 ] [ length ] [ direct ref ]
[ indirect ref ] [ payload ]
direct-reference. The direct-reference option contains the universal
identifier. It is of type OBJECT IDENTIFIER and it uniquely identifies the
payload encoding. Identifiers are registered and administered internationally
by ISO, CCITT, and their constituent organizations. Identifier administration
is described in section 5.
indirect-reference. The indirect-reference option is an integer alias for a
full length identifier. It is a more compact and efficient method of
identifying frequently transmitted data. Identifier-to-integer mappings are
established at the time of transmission, either though bi-directional
negotiation or though implied assignment by including both direct- and
indirect-reference options together in the same header on a periodic
basis.
payload. The payload field is an octet string encoded according to the
method identified in the direct- or indirect-reference fields. The payload
field is the octet-aligned option defined in the formal ASN.1 EXTERNAL type
specification.
DIRECT REFERENCE OPTION
(UNIVERSAL IDENTIFIER)
The header's direct-reference field contains a universal identifier indicating
how the payload is encoded. Identifier values are assigned, registered, and
administered either (1) by CCITT and ISO, or (even WIPO, UNESCO, etc.) in the
course of standards development; or (2) by delegated member bodies, companies,
or national organizations (such as SMPTE, IEEE, etc.), who assume
responsibility for administering a portion of the identifier space.
Identifier Hierarchy
Identifiers are organized in a hierarchy. The root (prefixes) of the identifier
hierarchy is:
Identifier
|
|
|-- CCITT[0]
| |- recommendation[0] : CCITT committees
| |- question[1] : CCITT Study Groups
| |- administration[2] : country PTTs (country code)
| |- network operator[3] : X.121 organizations
|
|-- ISO[1]
| |- standard[0] : ISO standards
| |- registration authority[1] : ISO authorities
| |- member body[2] : member bodies (country code)
| |- identified organization[3] : organizations
| |- ...
| |- SMPTE[52] : delegated to SMPTE
|
`-- joint ISO CCITT[2] : delegated to ANSI
A few prefixes are of particular interest. iso.standard registers all ISO
standards. ccitt.administration and iso.memberbody are assigned to sovereign
bodies (identified by their international telephone country code). Portions of
iso.organization are delegated by ISO to organizations and companies so that
the individual organizations can manage the assignment of their own portion of
the identifier space.
Header Examples
The following examples show two commonly used header configurations. The first
example shows a header for a message containing 1000 octets of Px64 encoded
imagery. Only the direct-reference form of identification is used and the
identifier is 0.0.8.261 (Px64) as shown above. This example puts together many
of the examples shown in previous sections. The complete header is encoded in
14 octets (about 1% of the total message) and has the following hexadecimal
representation:
EXTERNAL tag indicates the header is a constructed ASN.1 sequence
| EXTERNAL length occupies the next 2 octets(s)
| | EXTERNAL value occupies the next 1010 octets
| | | OBJECT IDENTIFIER tag indicates use of direct-reference opt.
| | | | OBJECT IDENTIFIER occupied the next 4 octet(s)
| | | | | OBJECT IDENTIFIER is 0.0.8.261 (Px64)
| | | | | | payload tag
| | | | | | | payload length in next 2 octets
| | | | | | | | payload occupies next 1000 octets
| | | | | | | | |
28 82 03F2 06 04 00088205 81 82 03E8
The next example shows a header for a 100-octet long payload with only the
indirect-reference option used, value (1), could be an alias for a copyright
descriptor. The complete header is encoded in 7 octets (about 7% of the total
message) and has the following hexadecimal representation:
EXTERNAL tag indicates the header is a constructed ASN.1 sequence
| EXTERNAL value occupied next 105 octets
| | INTEGER tag indicates use of indirect-reference option
| | | indirect-reference value in next octet
| | | | indirect-reference value is 1
| | | | | payload tag
| | | | | | payload occupies next 100 octets
| | | | | | |
28 69 02 01 01 81 64
EXAMPLE OF COPYRIGHT NOTATION
Following is a trivial example of how one might describe a copyright notice in
ASN.1. It serves only to elicit formal definition of a universal digital
copyright notice structure by a joint body of intellectual property,
communications, and computing experts:
Copyright ::= SEQUENCE
{
version INTEGER
{
version-0.1(0)
},
years SEQUENCE OF NumericString,
bylines SEQUENCE OF PrintableText,
rights ENUMERATED
{
all-rights-reserved(0)
},
permission PrintableText OPTIONAL,
disclaimer PrintableText OPTIONAL,
payment-method ElectronicPaymentStandard OPTIONAL,
}
NOTES
1. These concepts were outlined in detail for the
Congressional Office of Technology Assessment by one of the authors (Solomon)
as a contractor on their study of intellectual property, published in 1985. See
R. Solomon, "Computers and the Concept of Intellectual Property," in Martin
Greenberger, ed., Electronic Publishing Plus, Knowledge Industry, 1985.
Also see R. Solomon & Jane Yurow, "The New Electronic Technologies and
International Intellectual Property Issues," Office of Technology Assessment ,
U.S. Congress, May 1985; and, R. Solomon, "Intellectual Property and the New
Computer-Based Media," Office of Technology Assessment, U.S. Congress, August
1984.
2. "The right only began to assume importance when the
invention of printing made the multiplication of `copies' of a work infinitely
quicker and cheaper than the painstaking products of monkish scribes, as well
as appreciably more accurate than the compositions of most professional
scriveners." I. Parsons, "Copyright and Society," in A. Briggs, ed., Essays
in the History of Publishing, 1974.
3. Payments to the Crown for the privilege of publishing
via print.
4. Grossman, Bernard A. "Cycles in Copyright," New York
Law School Review, 22:2&3 (1977). G. Blagden, The Stationers'
Company, 1960.
5. Grossman, op. cit., p. 263.
6. Or a Type 4 Turing machine, depending on whom you wish
to give the intellectual credit.
7. R. Solomon, in a paper co-authored with the late Ithiel
de Sola Pool, first described this in a different context for the OECD in a
discussion of transborder data flows. See "Intellectual Property and
Transborder Data Flows", Stanford Journal of International Law, Summer
1980; and The Regulation of Transborder Data Flows", Telecommunications
Policy, September 1979.
We leave it to the reader to calculate how long it takes to reach the whole
world if every 15 minutes the number of recipients doubles.
8. Society of Motion Picture and Television Engineers
(U.S.).
9. The details of the header structure is still work-in-progress which is being
brought to this forum for comment and suggestions. The precise formats, fields,
descriptors, etc., are subject to substantive change as the standardization
process proceeds We invite comments and suggestions.
10. Generally ascribed to Prof. William F. Schreiber of
MIT, circa 1986.
11. Advanced Television and High-Definition Television.
12. World Intellectual Property Organization, United Nations Economic and
Social Commission, International Telecommunication [NO `S'] Union,
International Standards Organization.
13. ASN.1 is derived from work at Xerox Palo Alto Research
Center (PARC) on Courier in the late 1970s. A 1984 version was used in the
first draft of the CCITT X.400 series of recommendations on message handling
systems. ISO and CCITT jointly developed ASN.1 in 1988 for the presentation
layer of the Open Systems Interconnect model.
ASN.1 is now widely used in a range of international standards activities,
including the CCITT X.500 directory service, and both OSI and Internet network
management protocols, the Common Management Information Protocol and Simple
Network Management Protocol respectively. This suggests the possibility that
television systems may be networked devices that may fit into a common network
management framework.
14. For a formal description of ASN.1 refer to ISO
8824/8825 and CCITT X.208/209. A more accessible description can be found in:
Marshall T. Rose, The Open Book: A Practical Perspective on OSI,
Prentice Hall, 1990.
BIOGRAPHY
Branko Gerovac is with the Digital Equipment Corp., Maynard, Mass. and an
associate of the MIT Program on Digital Open High Resolution Systems.
Richard J. Solomon is Associate Director of the MIT DOHRS Program at the Center
for Technology, Policy and Industrial Development, Cambridge, Mass.
