[Federal Register Volume 60, Number 39 (Tuesday, February 28, 1995)]
[Notices]
[Pages 10832-10835]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 95-4855]



-----------------------------------------------------------------------

DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
[Docket No. 950124027-5027-01]
RIN 0693-AB38


Intent To Develop a Federal Information Processing Standard 
(FIPS) for a Data Standard for Record Description Records--Request for 
Comments

AGENCY: National Institute of Standards and Technology (NIST), 
Commerce.

ACTION: Request for comments.

-----------------------------------------------------------------------

SUMMARY: NIST is considering the development of a Federal Information 
Processing Standard (FIPS) for the data elements which, when taken 
together, will describe information objects of many different kinds, 
both electronic and non-electronic. The standard would apply to a wide 
range of information-creating software products. It would apply also to 
document management and object repository software products. Federal 
agencies would use the standard in specifying many software products 
used to create documents or information objects (e.g., electronic mail 
systems), and also when specifying document or object storage and 
management software products. This notice uses the word ``record'' as a 
broadly-encompassing term to include ``documents'' and ``objects,'' 
regardless of media or application.
    The framework for this proposed FIPS was developed by a working 
group of the interagency Integrated Services Panel, under the Federal 
Information Resources Management Policy Council. NIST solicits comments 
on the scope, purpose, background, and rationale for the proposed 
standard, and on certain technical issues. After analyzing the 
comments, NIST may propose a FIPS for review and comment.

DATES: Comments on this effort must be received on or before May 30, 
1995.


.ADDRESSES: Written comments should be sent to: Director, Computer 
Systems [[Page 10833]] Laboratory, ATTN: Data Standard for Records 
Description, Technology Building, Room B154, National Institute of 
Standards and Technology, Gaithersburg, MD 20899.
    Written comments received in response to this notice will be made 
part of the public record and will be made available for inspection and 
copying in the Central Reference and Inspection Facility, Room 5020, 
Herbert C. Hoover Building, 14th Street between Pennsylvania and 
Constitution Avenues, N.W., Washington, DC 20230.

FOR FURTHER INFORMATION CONTACT:
Mr. Bruce K. Rosen, National Institute of Standards and Technology, 
Technology Building, Room A-266, Gaithersburg, MD 20899, (301) 975-
3246, Internet mail <a href="/cdn-cgi/l/email-protection#f89a8a978b9d96b896918b8cd69f978e"><span class="__cf_email__" data-cfemail="2f4d5d405c4a416f41465c5b01484059">[email protected]</span></a>.

SUPPLEMENTARY INFORMATION: The Computer Systems Laboratory of the 
National Institute of Standards and Technology is considering the 
development of a Federal Information Processing Standard (FIPS) for the 
data elements--their identification, representation, arrangement, and 
object binding--to describe information objects. Such objects include 
but are not limited to electronic mail messages, word processing 
documents, spreadsheets, forms, voice-mail messages, images, and 
publications. This notice refers to all such objects with the single 
term ``record'' as a generic term to encompass documents, messages, and 
information objects of all kinds.
    The set of data elements will constitute a Record Description 
Record (RDR). The RDR will be created whenever e-mail messages, word 
processing documents, image documents, spreadsheet documents, voice-
mail messages, etc., are created, using either commercial-off-the-shelf 
(COTS) software products or non-COTS software. It will accompany those 
information objects when they are passed to a document management 
(storage and retrieval) or object repository product (either COTS or 
non-COTS), or when they are passed to some other software being used to 
store and retrieve them.
    By applying the standard to document management or object 
repository software products, it will become possible to use these 
products to manage non-electronic records stored externally in addition 
to the electronic information objects stored in and under the control 
of the document management or repository products.

Terminology

1. Record

    The computer industry is developing a new class of information 
technology products designed to organize, store, retrieve, and manage 
such electronic expressions of information as textual memos and 
reports, sound recordings, scanned images, and computer software. As a 
group, the information expressions are called ``documents,'' or 
``objects.'' The latter tends to be a broader term, to include computer 
software. Both my include sound recordings, images, and what are being 
called ``compound documents'' and ``multimedia'' documents or objects. 
The products being developed are usually called object repositories or 
document repositories or document management systems or document 
storage and retrieval systems.

2. Record Management System

    Throughout this notice, the term ``record management system'' is 
used broadly to include all software products intended to store, 
retrieve, and manage electronic documents and information objects. It 
is intended to encompass such products as those that are called 
``object repository,'' ``document repository,'' ``document manager,'' 
and ``document storage and retrieval system.'' These products may be 
stand-alone or they may be integrated with other products in an office 
suite. They may have their own directory, or they may share directory 
services with other software products with which they are integrated. 
What distinguishes them is their functionality of receiving documents 
or information objects--what this notice calls ``records'', storing 
them for future retrieval, use, and disposition, and also managing 
their integrity, access, and life-cycles.

Background, Purpose and Rationale

    Like many private sector enterprises, Federal Government agencies 
are re-engineering their programs, missions and administrative 
activities to perform them faster, better, and at less cost. In 
general, this means replacing paper-based processes with electronic, 
computer-based workflows. Examples include the electronic commerce 
programs, and electronic submission of regulatory reports and filings.
    As activities are migrated from paper to electronic workflows, 
transactions, and submissions, information objects pass between 
different software environments. Those records must be identified and 
described not only to support search and retrieval, but also to 
substantiate their trustworthiness in legal proceedings and support 
their transfer to the National Archives should such transfer be 
required.
    Federal Government agencies will be procuring record management 
products, both COTS and non-COTS, some of which will be stand-alone and 
some of which will be integrated with such creation software as word 
processing, e-mail, and workgroup computing. Thus, the possible 
interfaces between the software used to create records and the software 
used to store and retrieve them can very from many different packages 
bought from many different vendors in many different procurements, to a 
single integrated suite of software bought at one time in one 
procurement from one contractor.
    This proposed standard would enable Federal agencies to avoid 
reinventing in every procurement or system installation the 
identification data for messages, letters, images, etc., and the way 
that data is recorded and arranged. It will avoid the necessity for 
suppliers of software products to customize their products differently 
for different Federal agencies, or for Federal agencies to engage 
individually in complex integration efforts and to develop agency-
unique solutions to a requirement common to all.

Issues

1. Basic Architecture and Applicability

    The Record Description Record (RDR) is a set of descriptive 
attribute that are identified, arrange, and bound in a prescribed 
manner to whatever is being described. The attributes are sometimes 
referred to as metadata, because they identify and describe the record, 
and may or may not be a part of it. The RDR is itself called a record 
because it a logically-related set of discrete data elements.
    Whenever a record is created using a computer, the creating 
software would be expected to generate a corresponding RDR. That RDR 
would be passed to a record management system along with the record 
itself. For records created and stored outside the computer 
environment, e.g., non-electronic records or electronic records stored 
``off-line,'' the RDR information may be entered manually into a record 
management system, thereby using the system to manage records in 
general, without restriction as to the record media. In essence, the 
FIPS would be specifying a standard record to be used to describe other 
records of many different kinds.
    The RDR is envisioned as comprising three sets of data elements. 
The first is a small set that wou8ld be mandatory in [[Page 10834]] all 
RDRs and would apply universally to all records, regardless of their 
nature or content. The second is a small set that would be mandatory 
for certain classes of records, or conditions that apply to them. An 
example would be records sent electronically from one party to another, 
as contrasted with those that are printed and communicated by hand, 
mail, messenger, or facsimile. The third is a potentially large set of 
optional data elements to be specified by individual agencies.
    This approach would yield a single RDR standard that would 
prescribe how the data elements are identified, arranged, and 
represented, and how the RDR for an electronic record is to be bound to 
the record it describes. It presents two issues on which public comment 
is desired. One is whether it is reasonable to establish a single RDR 
standard for all applications, e.g., word processing, e-mail, voice-
mail, groupware, etc. The second is whether the three-level 
specification of data elements is appropriate.

2. RDR Binding

    There must be some binding between an electronic record and the RDR 
that describes it. Because of the different ways in which record 
management systems work, the actual RDR contents are likely to be 
handled differently, stored differently, and used differently in the 
various proprietary products. The RDR contains the kind of descriptive 
data that these systems put in their directories, if they have 
directories. To a great degree, the RDR may be viewed as being a 
support to or enhancement of the directory functions of those record 
management systems that have directories.
    Record management systems need to know how the RDRs for electronic 
records will be delivered to them--whether they will come as physically 
separate records, as headers, or as trailers. If this aspect is not 
standardized, then software products that create records would be free 
to create the corresponding RDRs in any way whatsoever. A standard 
approach could be established by which an RDR is bound to what it 
describes, so that record management system products can accept records 
from any source and understand their accompanying RDRs.
    The RDR standard is seen as essential to support a Federal agency's 
mix-and-match of software products from different vendors. However, in 
the case of integrated office suites where the passing of a record from 
the creating software to the storing/retrieving software is handled 
internally or where the record is created and stored in just one place, 
a standard for data element identification and arrangement and for 
object binding may not be needed, and when adopted might not 
necessarily apply. However, the RDR information content would still be 
necessary. When a record is transferred out of a record management 
system, to either another record management system or to the National 
Archives, the accompanying RDR would have to be bound according to the 
standard.
    Both implementors of software products that create records and 
implementors of record management system software products are asked to 
comment on how binding should be accomplished, and why. Prospective 
implementors are invited to propose specification language.

3. E-Mail Receipt Data

    Just the conduct of electronic commerce and regulatory activities--
let alone intra-agency and inter-agency communications--requires that 
agencies keep data about the origin and receipt of electronic 
transactions and submissions. Much of that data is generated internally 
by e-mail software packages.
    The treatment of e-mail receipt data poses a special binding case. 
An e-mail message may be sent to one or more receivers, who may receive 
it at different times, or not at all. At some point, the e-mail system 
may transfer the message and its accompanying data from its own message 
store to a record management system. If some receipt data for that 
message is generated in the e-mail system after the message to which it 
applies has been transferred out, there is a question about what the e-
mail system should do with that subsequent receipt data. It could, of 
course, be purged by the e-mail system. Alternatively, it could be put 
into an RDR and passed out to the record management system. If put into 
an RDR and passed out, the record management system would need to link 
it to the message to which it applies, and for which one or more RDRs 
already exist.
    Both implementors of e-mail software and implementors of a record 
storage software are asked to comment on how this issue might be 
resolved, and are invited to propose specification language to address 
it.

4. Data Element Identification

    The RDR will be a set of data elements. A standard mechanism must 
be established to identify the elements that are present, because the 
record will be a combination of mandatory and optional data elements. 
If a record management system is receiving records from e-mail, word 
processing, voice-mail, electronic commerce, etc., it will be receiving 
different RDRs depending on which package created the record, and 
perhaps also on the kind of record being stored. Thus, the format of 
the RDR must be standardized in a fashion analogous to a message header 
or a file label. Because there are many possible ways of formatting 
RDRs, the lack of a standard format would result in the creating 
software packages putting out RDRs that record management systems might 
not understand.
    Comments are desired on how the RDR should be formatted, and how 
data elements should be identified and represented, and why. 
Prospective implementors are invited to propose specification language.

5. Universal Mandatory Elements

    In general, these elements will address the questions of (a) what 
kind of record it is, or what software was used to create it; (b) which 
individual or organization created it; (c) when it was created; (d) 
what it deals with; and (e) what unique identifier(s) has been given to 
it. With respect to these and all other data elements, relevant 
existing FIPS for data element representations would be expected to be 
used. Representation standards would be established only for those 
elements for which such Federal standards do not presently exist.
    Comments are solicited on the specific data elements that should be 
considered to be universal and mandatory. Their selection criteria are 
(1) their importance in record identification and description, and (2) 
their applicability across the broad spectrum of software used to 
create records of different kinds.

6. Conditional Mandatory Elements

    Conditional mandatory elements are those that would be prescribed 
for records based on such characteristics as their application of 
origin, their storage media or location, or some statutory or 
regulatory requirement. The condition of greatest immediate concern is 
electronic communication, where the process of communication adds its 
own dimensions of time and place. Examples would be electronic mail, 
file transfer, and the many other applications that exist at the 
application layer of a multi-layer data communications reference model.
    As mentioned above, electronic commerce and electronic submission 
of regulatory reports and filings necessitate the inclusion of 
``transmission'' data in the RDR for an electronic mail message. It is 
expected that these activities will necessitate a comparable 
requirement in [[Page 10835]] such other communications-based 
applications as file transfers and electronic data interchange 
transactions. Thus far, all that is reasonably certain is that some 
data that is generated internally by e-mail systems or created by 
message originators--e.g., the identities of message originators, 
identities of receivers, the date and time of origination, and/or the 
date and time of receipt--must be bound to the message in the RDR. That 
is a relatively small set of data elements. However, two important 
questions surround it. The first is which of those elements should be 
mandatory and which optional, and the second is whether those mandatory 
elements should apply to all applications.
    Comments are desired on both of these questions, as well as on the 
mandatory descriptive elements that should apply to voice-mail, scanned 
image documents, compound documents, and multimedia documents.

7. Optional Elements

    Optional elements may be associated with records such as e-mail 
messages that are common across many Federal agencies, or they may be 
associated with common descriptive characteristics such as case number 
or client number, or they may be unique to a particular agency. Some 
common elements may be candidates for standardization, but that is not 
an issue in this context.
    What is of principal concern with respect to the RDR is the 
production of optional elements by the information creation software, 
and their acceptance by the record management system. The data element 
identification standard discussed above should cover the aspect of 
identifying each optional element that is present in an RDR, but 
questions remain concerning the number of optional elements that a 
record management system must be able to accept, and what 
specifications should apply to information creation software for the 
creation of the optional elements.
    Comments are solicited on these, and any other aspects of optional 
data elements in RDRs.

    Dated: February 22, 1995.
Samuel Kramer,
Associate Director.
[FR Doc. 95-4855 Filed 2-27-95; 8:45 am]
BILLING CODE 3510-CN-M

</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>