10832 Federal Register / Vol. 60, No. 39 / Tuesday, February 28, 1995 / Notices

person who assembles or completes the

merchandise sold in the United States

from the parts or components produced

in the foreign country with respect to

which the order applies; and (C)

whether imports into the United States

of the parts or components produced in

such foreign country have increased

after issuance of such order.

I. Statutory Criteria

Class or Kind, U.S. Assembly From

Components Produced in the Foreign

Country, and Difference In Value

Neither the Committee nor Camesa

challenged our preliminary

determination that the steel wire rope

sold in the United States was of the

same class or kind of merchandise as

that subject to the order and that the

subject steel wire rope was processed in

the United States from steel wire strand

produced in Mexico, the country to

which the antidumping duty order

applies. In addition, neither the

Committee nor Camesa challenged our

preliminary determination, based on the

best information available (BIA), that

the difference between the value of the

wire strand produced in Mexico and the

value of the steel wire rope sold in the

United States is small within the

meaning of section 781(a) of the Tariff

Act. Therefore, we affirm our

preliminary determination regarding

these three criteria.

II. Factors

Subsequent to our preliminary

determination, we did not request

additional information regarding the

pattern of trade, the relationship

between the parties, and the volume of

imports of steel wire strand. Neither

party challenged our preliminary

determination regarding these factors.

Based on our analysis of these factors,

we affirm our preliminary

determinations that (A) the data on the

pattern of trade indicate a shift from

sales in the United States of steel wire

rope produced in Mexico toward sales

of steel wire rope processed in the

United States from steel wire strand

produced in Mexico; (B) respondents

are related parties; and (C) imports of

steel wire strand into the United States

increased subsequent to the issuance of

the antidumping duty order.

Final Affirmative Determination of

Circumvention

Based on the foregoing analysis, we

determine that the respondent, Camesa,

is circumventing the antidumping duty

order on steel wire rope from Mexico.

The merchandise produced in the

United States, steel wire rope, is of the

same class or kind of merchandise as

that subject to the order, and is

completed from an intermediate product

produced in Mexico, the country to

which the order applies. Further, based

on BIA, we determine that the

difference in value between the

imported and finished products is

small. We also determine that the

pattern of trade, increase in imports of

the intermediate product, and

relationship between Grupo Camesa and

Camesa Inc., are consistent with an

affirmative determination of

circumvention. We note that our

analysis of the difference in value and

resulting determination of ‘‘small’’ in

this case are not necessarily

synonymous with such determinations

that the Department will formulate in

future circumvention inquiries since

Congress has directed us to make

determinations regarding the difference

in value on a case-by-case basis.

Based on this final affirmative

determination of circumvention, we

have determined that steel wire strand,

when manufactured in Mexico by

Camesa and imported into the United

States for use in the production of steel

wire rope, falls within the scope of the

antidumping duty order on steel wire

rope from Mexico. We will inform

Customs of this decision, and will

instruct it to continue to suspend

liquidation of, and require cash

deposits, at the applicable rate, on

entries of steel wire strand

manufactured in Mexico by Camesa.

No suspension of liquidation or

collection of cash deposits is required

for steel wire strand produced by other

manufacturers in Mexico. In addition,

no suspension of liquidation or

collection of cash deposits is required

for steel wire strand produced by

Camesa in Mexico that enters with an

end-use certificate certifying that the

steel wire strand will not be used for

processing into steel wire rope.

However, if this documentation is not

presented at the time of entry, the

merchandise produced by Camesa

should be subject to the applicable cash

deposit requirement.

Interested parties should be advised

that data and statements supporting the

exclusion of steel wire strand from this

antidumping duty order are subject to

verification by the United States

Government.

Interested parties may request

disclosure within five days of the date

of publication of this notice.

This notice serves as the only

reminder to parties subject to

administrative protective order (APO) of

their responsibilities concerning the

return or destruction of proprietary

information disclosed under APO in

accordance with 19 CFR 353.34(d).

Failure to comply is a violation of the

APO.

This final affirmative determination of

circumvention is in accordance with

section 781(a) of the Tariff Act (19

U.S.C. 1677j(a)) and 19 CFR 353.29(e).

Dated: February 17, 1995.

Susan G. Esserman,

Assistant Secretary for Import

Administration.

[FR Doc. 95–4900 Filed 2–27–95; 8:45 am]

BILLING CODE 3510–DS–M

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 informationcreating 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
Federal Register / Vol. 60, No. 39 / Tuesday, February 28, 1995 / Notices 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 brosen@nist.gov.

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 nonCOTS), 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 standalone 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 reengineering their programs, missions

and administrative activities to perform

them faster, better, and at less cost. In

general, this means replacing paperbased 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, email, 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 ‘‘offline,’’ 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
10834 Federal Register / Vol. 60, No. 39 / Tuesday, February 28, 1995 / Notices

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-andmatch 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, voicemail, 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 multilayer 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
Federal Register / Vol. 60, No. 39 / Tuesday, February 28, 1995 / Notices 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

Visiting Committee on Advanced

Technology

AGENCY: National Institute of Standards

and Technology, DOC.

ACTION: Notice of partially closed

meeting.

SUMMARY: Pursuant to the Federal

Advisory Committee Act, 5 U.S.C. app.

2, notice is hereby given that the

National Institute of Standards and

Technology Visiting Committee on

Advanced Technology will meet on

Tuesday, March 14, 1995, from 10:45

a.m. to 5:00 p.m., and on Wednesday,

March 15, 1995, from 8:30 a.m. to 10:00

a.m. The Visiting Committee on

Advanced Technology is composed of

nine members appointed by the Director

of the National Institute of Standards

and Technology who are eminent in

such fields as business, research, new

product development, engineering,

labor, education, management

consulting, environment, and

international relations. The purpose of

this meeting is to review and make

recommendations regarding general

policy for the Institute, its organization,

its budget, and its programs within the

framework of applicable national

policies as set forth by the President and

the Congress. On Tuesday, March 14,

1995, presentations will be given on the

Board on Assessment of NIST Programs’

annual report; the Applied Technology

Program focus report on Materials

Processing for Heavy Manufacturing; the

National Quality Award’s pilot

programs in healthcare and education;

and national and international

standards. A discussion on the

Institute’s budget, including funding of

the Applied Technology Program and

staffing of management positions at

NIST, scheduled to begin at 10:45 a.m.

and to end at 11:45 a.m. on March 14,

1995, will be closed. On Wednesday,

March 15, 1995, the committee members

will tour the molecular measurement

laboratory.

DATES: The meeting will convene March

14, 1995, at 8:30 a.m. and will adjourn

at 10:00 a.m. on March 15, 1995.

ADDRESSES: The meeting will be held in

Lecture Room A, Administration

Building, National Institute of Standards

and Technology, Gaithersburg,

Maryland.

FOR FURTHER INFORMATION CONTACT:

Chris E. Kuyatt, Visiting Committee

Executive Director, National Institute of

Standards and Technology,

Gaithersburg, MD 20899, telephone

number (301) 975–6090.

SUPPLEMENTARY INFORMATION: The

Assistant Secretary for Administration,

with the concurrence of the General

Counsel, formally determined on

February 7, 1995, that portions of the

meeting of the Visiting Committee on

Advanced Technology which involve

examination and discussion of the

budget for the Institute may be closed in

accordance with Section 552(b)(9)(B) of

Title 5, United States Code, since the

meeting is likely to disclose financial

information that may be privileged or

confidential.

Dated: February 22, 1995.

Samuel Kramer,

Associate Director.

[FR Doc. 95–4856 Filed 2–27–95; 8:45 am]

BILLING CODE 3510–13–M

National Oceanic and Atmospheric

Administration

[I.D. 021495C]

New Bedford Harbor Trustee Council;

Scoping Meetings

AGENCIES: National Marine Fisheries

Service (NMFS), National Oceanic and

Atmospheric Administration (NOAA),

Commerce; and Office of Environmental

Policy and Compliance, U.S.

Department of the Interior (DOI).

ACTION: Notice of intent to prepare an

environmental impact statement (EIS);

request for comments.

SUMMARY: NMFS, acting as

Administrative Trustee, and DOI

announce the intention of the New

Bedford Harbor Trustee Council

(Council) to prepare an EIS for a

proposed plan to address the restoration

of natural resources that have been

injured by the release of hazardous

substances, including polychlorinated

biphenyls (PCBs), in the New Bedford

Harbor environment. The Council also

announces its initiation of a public

process to determine the scope of issues

under consideration. The purpose of

this notice is to inform the public of this

process and of the opportunity to

participate in the development of the

restoration plan/EIS. All persons

affected by, or otherwise interested in,

the proposed restoration plan are

invited to participate in determining the

scope of significant issues to be

considered in the EIS by submitting

written comments or by attending

scoping meetings. The scoping process

will identify and prioritize alternatives

for potential restoration activities.

DATES: The Council will hold scoping

meetings in each of the affected

communities within the New Bedford

Harbor environment. The scoping

meetings are scheduled as follows:

1. February 28, 1995, 6:30 p.m.–9

p.m., New Bedford, MA

2. March 1, 1995, 6:30 p.m.–9 p.m.,

North Dartmouth, MA