INTERNET-DRAFT R. Lutz MFPA Technical Committee Cognisys, Inc. January 31, 2000 R. Bergman Hitachi Koki B. Wagner NETsilicon, Inc. Network Scanner MIB, Version 8.0 Expires July 31, 2000 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract The Network Scanner MIB is an industry standard SNMP MIB for the management of networked scanner devices. The Scanner MIB was developed as a solution for multifunction devices, and consequently this MIB covers only the unique scanner related sub-units. However by importing objects from other MIBs, the MIB is equally applicable to stand-alone scanner products. Lutz, Bergman, Wagner [Page 1] INTERNET-DRAFT Scanner MIB January 31, 2000 1. INTRODUCTION This document defines an SNMP Management Information Base (MIB) to provide for the management of the scanner portion of a multifunction device. A full-featured multifunction environment includes functions such as a Printer, Scanner, Facsimile, and Copier, and multiple MIBs are required to completely define the entire system. The Scanner MIB supports the following functional sub-units: -- Scanner General -- Original Document Handler -- Image Sensor -- Color Space -- Communication Channel -- Scanner Control Interpreter 1.1 Network Scanning Environment Scanners have been typically either been vertically integrated into larger systems or have been desktop devices connected directly to a workstation for previewing and transforming the image captured. For this reason, the management of a scanner as an appliance on a network has not received the same attention as other devices that may operate as pure services to a client workstation. As the scanner device becomes more functional, or if you consider the co-located workstation to be part of the scanning solution, then these devices can operate not as services but as a complete client service solution at that location. Other users can establish the settings for their future scan sessions and then provide the original documents when convenient, recovering the settings desired for that session, and storing the resulting information at the desired location on the network. The management of capturing the image of an original document can be divided into two overlapping pieces, the management of scanning and the management of the scanner. Scanning encompasses the entire process of (1) selection of a scanner, (2) choosing scanning properties, (3) sensing an original document to a raw data form, (4) transformation of the raw data to normalize it due to irregularities in the sensing hardware, possibly enhance it in some way (5) compression of the data (6) placing the image data in a known format, (7) storage of the image in a local file store, (8) routing to or notifying the user. Most of the scanning process is outside the scope of the model presented here; only the management of the scanner is covered. Lutz, Bergman, Wagner [Page 2] INTERNET-DRAFT Scanner MIB January 31, 2000 Figure 1a - One Scanner's View of the Network: Scanner with a colocated workstation system scanner asset user user user manager operator manager O O O O O O /|\ /|\ /|\ /|\ /|\ /|\ / \ / \ / \ / \ / \ / \ | | | | | | +---------+ +-------+ +-------+ +-------+ +-----------+ +-----------+ |configur-| |scanner| | asset | |scanner| | user | | user | |ator | |manager| |manager| |browser| |application| |application| +---------+ +-------+ +-------+ +-------+ +-----------+ +-----------+ ^ ^ ^ ^ ^ ^ |R/W |R/W |R |R |R/W |R/W | | | | | | | | | | | | | | | | | | v v | | V V ====================================================================== | ^ ^ |SNMP scan| scan| +-----+ +-------+ control| data| | MIB |<------>| agent | | | +-----+ +-------+ | | |unspecified | | +=============+ +===========+ | | O | | | | +-----------+ | | /|\ ---- | | | Colocated | +-----------+| V | / \ | SCANNER |--|Workstation|--| interface ||<--------+ walk-up | | | (OPTIONAL)| | |+ user | | | | +-----------+ +=============+ +===========+ | +---------+ | Data | | Store | | (Opt'l) | +---------+ NOTE: The interface between the workstation and the scanner is not Specified. The network views the scanner/workstation as a single unit. Lutz, Bergman, Wagner [Page 3] INTERNET-DRAFT Scanner MIB January 31, 2000 Figure 1b - One Scanner's View of the Network: Stand-alone scanner system scanner asset user user user manager operator manager O O O O O O /|\ /|\ /|\ /|\ /|\ /|\ / \ / \ / \ / \ / \ / \ | | | | | | +---------+ +-------+ +-------+ +-------+ +-----------+ +-----------+ |config- | |scanner| | asset | |scanner| | user | | user | | urator | |manager| |manager| |browser| |application| |application| +---------+ +-------+ +-------+ +-------+ +-----------+ +-----------+ ^ ^ ^ ^ ^ ^ |R/W |R/W |R |R |R/W |R/W | | | | | | | | | | | | | | | | | | v v | | V V ====================================================================== | ^ ^ |SNMP scan| |scan +-----+ +-------+ control| |data | MIB |<------>| agent | | | +-----+ +-------+ | | |unspecified | | +=============+ | | O | | +-----------+ | | /|\ ---- | | +-----------+| V | / \ | SCANNER |--| interface ||<-----+-----+ walk-up | | | |+ user | | +-----------+ +=============+ | +---------+ | Data | | Store | | (Opt'l) | +---------+ 1.2 Scanner Device Overview A scanner is the physical device that takes originals from an input source, exposes the original with a light source, detects the color of the original based on the light reflected from the original using photosensitive electronic elements. The image is composed of a rectangular array of pixels, where each is treated as a single uniform color. The photosensitive elements provide a numerical quantity for each pixel, typically compressed to reduce storage space Lutz, Bergman, Wagner [Page 4] INTERNET-DRAFT Scanner MIB January 31, 2000 and bandwidth required to transmit the image. There is typically normalization to account for irregularities in the sensing hardware and color correction steps before the compression occurs. In the management of the physical scanning device, the description, status, and alert information concerning the scanner and its various sub- units is made available to the management application so that it can be reported to the end user or key operator. The information needed in the management of the physical scanner and the management of a scan job overlap highly and many of the tasks in each management area require the same or similar information. Some production-grade scanners may have a marker mechanism that produces marks on the document original media, typically referred to as "endorsing". This marking can be performed either before or after the scan of the document, but typically not both. Marking is typically confined to a small and specific portion of the image area, and it utilized to indicate on the original that it has been scanned into the system, and optionally, also to indicate on the scanned image when it was actually scanned into the system. The marker sub- units and their associated supplies specifically not supported by this standard. This results in a substantial simplification. 1.3 Categories of Scanner Information Information about scanners is classified into three basic categories; descriptions, status, and alerts. 1.3.1 Descriptions Descriptions convey information about the configuration and capabilities of the scanner and its various sub-units. This information is largely static information and does not generally change during the operation of the system but may change as the scanner is repaired, reconfigured or upgraded. The descriptions are one part of the visible state of the scanner where state means the condition of being of the scanner at any point in time. 1.3.2 Status Status is the information regarding the current operating state of the scanner and its various sub-units. A single status value indicates the overall status of the scanner and whether any Alerts are outstanding. Additional information regarding the reason for an Alert can be determined by examining the Alerts table. 1.3.3 Alerts An Alert is the representation of a reportable event in the scanner. An event is a change in the state of the scanner. Some of those state changes are of interest to a management application and are therefore reportable. Typically, these are the events that affect the scanner's Lutz, Bergman, Wagner [Page 5] INTERNET-DRAFT Scanner MIB January 31, 2000 ability to scan. See the Multifunction Product MIB [MFP-MIB] for additional information regarding the design and usage of the Alert Table. 2. Scanner Model In order to accomplish the management of the scanner, an abstract model of the scanner is needed to represent the sub-units composing the scanner. The scanner model shown in figure 2 represents the scanner portion of a multifunction device, as defined in the Multifunction Product MIB [MFP-MIB]. Refer to the MFP MIB for the relationship between the Scanner MIB model and the additional required sub-units to fully define an operational device. Figure 2 - Scanner Block Diagram +------------------------------------+ +------------------------------------+ | | Communication Channel | | | |-+ +------------------------------------+ ^^ ^ || +---------+ | Operator Scan Data +---------+ | Control Control ^^ | Color | | | | || /| Space |-+ | | || / +---------+ V | +----------+-+ +-------------+ | +------------+ | +-------------+ | | | Image | |<------+------| Scanner | | | | Sensor |-+ | | Control | |-----+ +------------+ | | Language |-+ || | +-------------+ || | ^^ | +-----------+ +------++----------------+ | General | +-------+--------+--------+ | | Scanner | | ODH | ODH | ODH | | +-----------+ | Input | Media | Output |-+ | | Path | | +-------+--------+--------+ Original Document Handler 2.1 Overview of the Scanner Model The model has three basic parts: (1) the flow of Job Control data to Lutz, Bergman, Wagner [Page 6] INTERNET-DRAFT Scanner MIB January 31, 2000 the scanner, (2) image data flow of scan data from the scanner, (3) the flow of original documents through the scanner. There are also auxiliary sub-units that control and facilitate the basic flows. Job control data provided by the transport protocol (interface) appears on a channel which is the input to the Job Control Interpreter. The interpreter converts job control information into settings of the scanner for a specific scan job. The job control information for a specific job ("Ticket") is either applied immediately, or stored to be applied to one or more future jobs. The walk-up operator can establish all the settings via the Operator Console (see the Multifunction Product MIB [MFP-MIB]), or he may indicate which previously established Ticket is to be applied. The user inserts original documents into the Original Document Handler (ODH) mechanism which handles the original documents, prior to, during, and after scanning. This mechanism has many design possibilities, including a flatbed glass window, a single sheet feeder, multiple sheet input with separate output bin, or an input bin that is also used as the output bin with mechanism to separate the scanned documents from those already scanned. Image data are derived from the sensor array, normalized, corrected, and converted to a form suitable for storage and transport. Then those data flow through a physical connection on which some form of transport protocol stack is running. The auxiliary sub-units facilitate control of the scanner, inquiry/control of the operator panel, reporting of alerts, and the adaptation of the scanner to various natural languages and characters sets. All the software sub-units run on the System Controller which represents the processor, memory and storage systems of the Scanner. Each of the sub-units is discussed in more detail below. The scanner system may have a partner workstation that will be used for some of the processing that is implied to be in the scanner itself. For example, the scanner mechanism may only provide raw data output to the workstation or network. The partner workstation may then provide the image processing and format transformation functions. For the purposed of the MIB, these functions are treated as if they existed within the scanner itself. 2.2 Scanner Sub-Units The scanner model defines 5 types of sub-units, and the corresponding management data are organized into "groups". The following sections describe the sub-units. Refer to the Multifunction Product MIB [MFP-MIB] for additional sub-units that may be required for specific implementations. Lutz, Bergman, Wagner [Page 7] INTERNET-DRAFT Scanner MIB January 31, 2000 2.2.1 General Scanner The general scanner sub-unit is responsible for the overall control and status of the scanner. There is exactly one general scanner sub- unit in a scanner. The general scanner sub-unit is represented by the General Scanner Group in the model. It provides the overall status of the scanner, allows the scanner to be reset, and is the means to localize messages used in management of the scanner. A major portion of the General Scanner sub-unit is imported from the Multifunction Product MIB [MFP-MIB]. The Scanner MIB General Table contains unique objects that define the default settings for scanner specific features. This includes entries that identify the default Original Document Handler, the default sensor configuration, and the default color space selection. 2.2.2 Original Document Handler A scanner may implement some form of Original Document Handler (ODH), which can feed originals from an input tray or feeder to a given position where a moving sensor is moved across the original, or the original may be moved across the sensor array, and then the document is deposited an output tray. In some cases, the input and output tray may be the same. The ODH mechanism has many design possibilities, including a flatbed glass window, a single sheet feeder, multiple sheet input with separate output bin, or an input bin that is also used as the output bin with mechanism to separate the scanned documents from those already scanned. A single scanner device may offer several ODH options. Although great emphasis is placed here on original paper documents, this does not exclude scanning other original material, such as with scanning slides, transparencies, film, or capturing images directly with a digital camera. There are as many ODH sub-units as there are distinctly selectable ODH "addresses". For example, if an input has an option for manually placing documents on a flat-bed as well as automatically feeding from an automatic document feeder, then two ODH sub-units exist if each can be separately selected and one ODH sub-unit exists if putting an original document on the flat-bed overrides feeding from the automatic document feeder; that is, in the second case there is no way to separately select or address the flat-bed portion. Original Media The input-portion of an ODH sub-unit may hold one or more instances of document originals to be scanned. The ODH Group describes the maximum and minimum supported original media sizes. The document originals may change in size from one original to the next and the size of the original may be indicated as part of the captured image Lutz, Bergman, Wagner [Page 8] INTERNET-DRAFT Scanner MIB January 31, 2000 data file. 2.2.3 Image Sensor An image sensor is the mechanism that detects the surface color of scanned document originals resulting in a set of digital information. The original is illuminated with a light source. The reflected light from the light source is detected by one or more discrete photo- detectors. These detectors may be organized in a variety of physical forms, including a) a linear array parallel to the leading edge of the paper, thereby requiring that paper or the imaging unit be moved along the feeding direction of the paper so that the entire paper is imaged; or b) a complete rectangular array which accepts the image of the paper in a snap-shot fashion; or c) a scanning laser with an associated single photo-detector. The image area is divided in to a rectangular array of square or nearly square "pixels". Each pixel is detected by a single hardware detector or detector set and therefore is treated as a single, uniform color. The color of the pixel is then represented by one or more numbers, each relating to a given set of sensed light frequencies. The value of the number relates to the intensity of the light of that frequency range that reached the detector. The Sensor sub-units are represented by the Sensor Group in the model. A scanner can contain one or more image sensor mechanisms. Some examples of multiple sensor sub-units are: a scanner with separate sensors for front and back-side scanning, or separately treated sensors for various frequency ranges (colors). (However, it is preferred that this arrangement be avoided and treat this as a single sensor mechanism with the capability of detecting multiple light frequency ranges (color ranges). 2.2.4 Communication Channel The channel sub-units identify the independent flow of scan data and scanner control data. As in the Printer MIB, the primary purpose of the channels group in the Scanner MIB is to identify and optionally provide control of the paths that may be used to access the scanner. Unlike the Printer, in which setup/control information and image data are typically sent via the same channel (and sometimes in the same file), scan control and scan data delivery are typically over separate channels. This is because the scanning process must precede data delivery, and therefore the control information must be present before scanning starts. The channel sub-units are represented by the Communciation Channel Group in the Model. Each channel is typically identified by the electronic path and service protocol used to deliver scan data from the scanner, along with a image format. A channel sub-unit may be independently enabled (allowing scan data to flow) or disabled Lutz, Bergman, Wagner [Page 9] INTERNET-DRAFT Scanner MIB January 31, 2000 (stopping the flow of scan data). 2.2.5 Scanner Control Interpreter There is a single Scanner Control Interpreter sub-unit responsible for processing of scanner job control data into the appropriate scanner state. A scanner may support various forms of job control information. The scanner control interpreter sub-unit is represented by the Scanner Control Language Group in the Model. The scanner control interpreter is typically implemented with software running on the System Controller. The Scanner Control Langauge Table has one entry per form of job ticket information supported. 2.2.6 Color Space The color space information is used by the image sensor to determine how to format color values in the output image. The color space information is presented in the Color Space Group in the model. 2.3 Read-Write Objects Some of the objects in the scanner MIB report on the existence of or amount of a given resource used with the scanner, such as the existence of certain ODH units. On some scanners there are sensors that allow these resources to be sensed. Other scanners, however, lack sensors that can detect (all of) the properties of the resource. Because the scanner needs to know of the existence or properties of these resources for the scanner to function properly some other way of providing this information is needed. The chosen way to solve this problem is to allow a management application to write into objects which hold the descriptive or existence values for scanners that cannot sense the values. Thus many of the objects in the MIB are given read-write access, but a scanner implementation might only permit a management operation to change the value if the scanner could not sense the value itself. Therefore, the ability to change the value of a read-write object may depend on the implementation of the agent. Note that even though some objects explicitly state the behavior of conditional ability to change values, any read-write object may act that way. Generally, an object is given read-write access in the Scanner MIB specification if: 1. The object involves installation of a resource that some scanners cannot themselves detect. Therefore, external means are needed to inform the scanner of the installation. (Here external means include using the operator console, or remote management application) and 2. The scanner will behave differently if the installation of the resource is reported than the scanner would if the installation Lutz, Bergman, Wagner [Page 10] INTERNET-DRAFT Scanner MIB January 31, 2000 were not reported; that is, the object is not to be used as a place to put information not used by the scanner. It is an implementation-specific matter as to whether or not MIB object values are persistent across power cycles or cold starts. 2.4 Enumerations Enumerations (enums) are sets of symbolic values defined for use with one or more objects. Some common enumeration sets are assigned a symbolic data type name (textual convention). 2.4.1 Registering Additional Enumerated Values This working group has defined several type of enumerations. These enumerations differ in the method employed to control the addition of new enumerations. Throughout this document, references to "enumeration (n)", where n can be 1, 2 or 3 can be found in the various tables. The definitions of these types of enumerations are: enumeration (1) All the values are defined in the Scanner MIB specification (RFC for the Scanner MIB). Additional enumerated values require a new RFC. enumeration (2) An initial set of values are defined in the Scanner MIB specification. Additional enumerated values are registered after review by this working group. The initial versions of the MIB will contain the values registered so far. After the MIB is approved, additional values will be registered through IANA after approval by this working group. enumeration (3) An initial set of values are defined in the Scanner MIB specification. Additional enumerated values are registered without working group review. The initial versions of the MIB will contain the values registered so far. After the MIB is approved, additional values will be registered through IANA without approval by this working group. 3. Objects from other MIB Specifications The Scanner MIB represents only one functional piece of a complete system. The definition of a product that incorporates a scanner function will require the use of groups from other MIBs. Refer to the Multifunction Product MIB [MFP-MIB] for complete details regarding these requirements. Lutz, Bergman, Wagner [Page 11] INTERNET-DRAFT Scanner MIB January 31, 2000 4. NETWORK SCANNER MIB SPECIFICATION Scanner-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Counter32, Integer32, TimeTicks, NOTIFICATION-TYPE, OBJECT-IDENTITY FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF PrtMediaUnitTC, PrtCapacityUnitTC, CodedCharSet FROM PRINTER-MIB Boolean, Kbytes FROM HOST-RESOURCES MIB; scanmib MODULE-IDENTITY LAST-UPDATED "0031010000Z" ORGANIZATION "MFPA Scanner MIB Working Group" CONTACT-INFO "Raymond Lutz Postal: Multifunction Peripheral Association 1010 Old Chase Ave, STE B El Cajon, CA, 92020 Tel: 619-447-1127 Fax: 619-447-6872 E-mail: raylutz@mfpa.org" DESCRIPTION "The MIB module for management of network scanners." ::= { enterprises mfpa(5335) mibs(1) scannerMIB(1) } -- Textual conventions for this MIB module -- -- Channel Group textual-conventions ScnChannelModeTC ::= TEXTUAL-CONVENTION -- This value is a type 1 enumeration STATUS current DESCRIPTION "The modes in which this scanner communication channel may be used. The value indicates whether control information and/or image data is allowed through this channel. It also indicates whether the channel support server or client mode." SYNTAX INTEGER { other(1), unknown(2), control only, server mode(3), data only, server mode (4), control and data, server mode (5), control only client mode (6), data only, client mode (7), control and data, client mode (8) } Lutz, Bergman, Wagner [Page 12] INTERNET-DRAFT Scanner MIB January 31, 2000 ScnChannelStateTC ::= TEXTUAL-CONVENTION -- This value is a type 1 enumeration STATUS current DESCRIPTION "The state of this scanner communications channel. The value indicates whether control information and/or image data is allowed through this channel." SYNTAX INTEGER { other(1), unknown(2), channel enabed (3) channel disabled(4) } ScnChannelTypeTC ::= TEXTUAL-CONVENTION -- This is a type 2 enumeration. STATUS current DESCRIPTION "This enumeration identifies the type of channel." SYNTAX INTEGER { other(1), chEIA232(3), chParallelPort(4), chIEEE1284Port(5), chSCSIPort(6), chAppleTalkPAP(7), -- AppleTalk Printer -- Access Protocol (PAP) -- -- scnChannelInformation entry: -- -- Printer Name -- Keyword: Name -- Syntax: Name -- Status: Optional -- Multiplicity: Single -- Description: The name of the -- printer within the AppleTalk -- naming scope } -- The General Scanner Group -- The general scanner sub-unit is responsible for the overall -- control and status of the scanner. There is exactly one general -- scanner sub-unit in a scanner. scnGeneral OBJECT IDENTIFIER ::= { scannerMIB 2 } scnGeneralTable OBJECT-TYPE SYNTAX SEQUENCE OF ScnGeneralEntry Lutz, Bergman, Wagner [Page 13] INTERNET-DRAFT Scanner MIB January 31, 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of general information per scanner." ::= { scnGeneral 1 } scnGeneralEntry OBJECT-TYPE SYNTAX ScnGeneralEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { hrDeviceIndex } ::= { scnGeneralTable 1 } ScnGeneralEntry ::= SEQUENCE { -- Note that not all of the objects in this sequence are in the -- general scanner group. scnODHDefaultIndex OCTET STRING, scnSensorDefaultIndex Integer32, scnColorSpaceDefaultIndex Integer32 } scnODHDefaultIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of scnODHIndex corresponding to the default ODH sub-unit." ::= { scnGeneralEntry 1 } scnSensorDefaultIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of scnSensorIndex corresponding to the default sensor sub-unit; that is, this object selects the default sensor." ::= { scnGeneralEntry 2 } scnColorSpaceDefaultIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of scnColorSpaceIndex corresponding to the default sensor color space." ::= { scnGeneralEntry 3 } Lutz, Bergman, Wagner [Page 14] INTERNET-DRAFT Scanner MIB January 31, 2000 -- The Original Document Handler (ODH) Group -- Original Document Handler (ODH) sub-units are managed as a tabular, -- indexed collection of possible devices capable of providing media for -- input to the scanning process, handling of the original media during -- scanning, and depositing the scanned original media in an output bin. -- ODH sub-units typically have a location, a type, an identifier, a set -- of constraints on possible media sizes and potentially other media -- characteristics, and may be capable of indicating current status or -- capacity. -- Implementation of every object in this group is mandatory. scnODH OBJECT IDENTIFIER ::= { scannerMIB 200 } scnODHTable OBJECT-TYPE SYNTAX SEQUENCE OF scnODHEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the devices capable of providing original documents for input to the scanning process, handling those originals during scanning, and depositing the original documents in an output bin." ::= { scnODH 1 } scnODHEntry OBJECT-TYPE SYNTAX ScnODHEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of a Original Document Handler (ODH) device. Entries may exist in the table for each device index whose device type is `scanner'." INDEX { hrDeviceIndex, scnInputIndex } ::= { scnInputTable 1 } ScnODHEntry ::= SEQUENCE { Lutz, Bergman, Wagner [Page 15] INTERNET-DRAFT Scanner MIB January 31, 2000 scnODHIndex Integer32, -- 1 scnODHType INTEGER, -- 2 scnODHDimUnit PrtMediaUnitTC, -- 3 scnODHMaxDimFeedDir Integer32, -- 4 scnODHMaxDimXFeedDirDir Integer32, -- 5 scnODHMinDimFeedDir Integer32, -- 6 scnODHMinDimXFeedDir Integer32, -- 7 scnODHCapacityUnit PrtCapacityUnitTC, -- 8 scnODHInputMaxCapacity Integer32, -- 9 scnODHInputCurrentLevel Integer32, -- 10 scnODHOutputMaxCapacity Integer32, -- 11 scnODHOutputRemainingCapacity Integer32, -- 12 scnODHMaxSpeed Integer32, -- 13 scnODHMaxMediaWeight Integer32, -- 14 scnODHSimplexDuplex INTEGER, -- 15 scnODHScanOrder INTEGER, -- 16 scnODHInterleaving INTEGER, -- 17 scnODHDescription OCTET STRING -- 18 } scnODHIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the scanner to identify this ODH sub- unit. Although these values may change due to a major reconfiguration of the device (e.g. the addition of new ODH sub-units to the scanner), values are expected to remain stable across successive scanner power cycles." ::= { scnODHEntry 1 } scnODHType OBJECT-TYPE -- This value is a type 2 enumeration SYNTAX INTEGER { other(1), unknown(2), automaticDocumentFeeder(3), automaticBookReader(4), flatbedManual(5), sheetFeedManual(6), handScanner(7), digitalCamera(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of technology employed by the ODH sub-unit." ::= { scnODHEntry 2 } scnODHDimUnit OBJECT-TYPE Lutz, Bergman, Wagner [Page 16] INTERNET-DRAFT Scanner MIB January 31, 2000 SYNTAX PrtMediaUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measurement for use calculating and relaying dimensional values for this ODH sub-unit." ::= { scnODHEntry 3 } scnODHMaxDimFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the value of the maximum dimension, in the feed direction, of the original document media that is accepted by this ODH sub-unit. The feed direction is parallel to the direction in which the media moves. This dimension is measured in ODH sub-unit dimensional units (scnODHDimUnit). This is NOT the size of each original. If the scanner is able to sense the size of the original during the scanning process of an individual original document, that information may be provided in the image data. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (-2) indicates unknown." ::= { scnODHEntry 4 } scnODHMaxDimXFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "This object provides the value of the maximum dimension, in the cross feed direction, of the media that is accepted by this input sub-unit. The cross feed direction is ninety degrees relative to direction of media movement associated with this sub-unit. This dimension is measured in ODH sub-unit dimensional units (scnODHDimUnit). This is NOT the size of each original. If the scanner is able to sense the size of the original during the scanning process of an individual original document, that information may be provided in the image data. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (- 2) indicates unknown." ::= { scnODHEntry 5 } scnODHMinDimFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current Lutz, Bergman, Wagner [Page 17] INTERNET-DRAFT Scanner MIB January 31, 2000 DESCRIPTION "This object provides the value of the minimum dimension, in the feed direction, of the media that is accepted by this ODH sub-unit. This dimension is measured in ODH sub-unit dimensional units (scnODHDimUnit). This is NOT the size of each original. If the scanner is able to sense the size of the original during the scanning process of an individual original document, that information may be provided in the image data. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (- 2) indicates unknown." ::= { scnInputEntry 6 } scnODHMinDimXFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides the value of the minimum dimension, in the cross feed direction, of the media that is accepted by this input sub-unit. The cross feed direction is ninety degrees relative to the feed direction associated with this sub-unit. This dimension is measured in ODH sub-unit dimensional units (scnODHDimUnit). This is NOT the size of each original. If the scanner is able to sense the size of the original during the scanning process of an individual original document, that information may be provided in the image data. The value (-1) means other and specifically means that this sub-unit places no restriction on this parameter. The value (- 2) indicates unknown." ::= { scnInputEntry 7 } scnODHCapacityUnit OBJECT-TYPE SYNTAX PrtCapacityUnitTC MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measurement for use in calculating and relaying capacity values for this input sub-unit." ::= { scnODHEntry 8 } scnODHInputMaxCapacity OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current Lutz, Bergman, Wagner [Page 18] INTERNET-DRAFT Scanner MIB January 31, 2000 DESCRIPTION "The claimed maximum capacity of the input portion of the ODH sub-unit in ODH sub-unit capacity units (scnODHCapacityUnit). If this ODH sub-unit can reliably sense this value, the value is sensed by the scanner and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown." ::= { scnODHEntry 9 } scnODHInputCurrentLevel OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The current capacity of the input portion of the ODH sub-unit in ODH sub-unit capacity units (scnODHCapacityUnit). If this ODH sub-unit can reliably sense this value, the value is sensed by the scanner and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. The value (-3) means that the scanner knows that at least one unit remains." ::= { scnODHEntry 10 } -- INPUT MEASUREMENT -- -- _______ | | -- ^ | | -- | | | | -- | |_ _ _ _ _ _ _ _ _ _ _| _________________ |direction -- | | | ^ v -- MaxCapacity | | | -- | | Sheets left in unit | CurrentLevel -- | | | | -- v | | v -- _______ +_____________________+ _______ scnODHOutputMaxCapacity OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current Lutz, Bergman, Wagner [Page 19] INTERNET-DRAFT Scanner MIB January 31, 2000 DESCRIPTION "The claimed maximum capacity of the output portion of the ODH sub-unit in ODH sub-unit capacity units (scnODHCapacityUnit). If this ODH sub-unit can reliably sense this value, the value is sensed by the scanner and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown." ::= { scnODHEntry 11 } scnODHOutputRemainingCapacity OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The remaining capacity of output portion of the ODH sub-unit in ODH sub-unit capacity units (scnODHCapacityUnit). If this ODH sub-unit can reliably sense this value, the value is sensed by the scanner and may not be changed by management requests; otherwise, the value may be written (by a Remote Control Panel or a Management Application). The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown. The value (-3) means that the scanner knows that there remains capacity for at least one unit." ::= { scnODHEntry 12 } -- OUTPUT MEASUREMENT -- -- _______ | | _______ -- ^ | | ^ -- | | | | -- | | | RemainingCapacity -- MaxCapacity | | | -- | | | v ^ -- | |_ _ _ _ _ _ _ _ _ _ _| ___________________ |direction -- | | | | -- | | Sheets in output | -- v | | -- _______ +_____________________+ scnODHMaxSpeed OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum scanning speed of this ODH expressed in scans. A value of (-1) implies 'other'." Lutz, Bergman, Wagner [Page 20] INTERNET-DRAFT Scanner MIB January 31, 2000 ::= { scnODHEntry 13 } scnODHMaxMediaWeight OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The max weight of the medium associated with this input sub- unit in grams / per meter squared. The value (-1) means other and specifically indicates that the sub-unit places no restrictions on this parameter. The value (-2) means unknown." ::= { scnODHEntry 14 } scnODHSimplexDuplex OBJECT-TYPE -- This value is a type 2 enumeration SYNTAX INTEGER { other(1), unknown(2), simplex(3), duplexConcurrent(4), duplexSequential(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of scanning performed by this ODH and sensor combination. Simplex indicates that one side of the original document is sensed. DuplexConcurrent indicates that both sides of the document are imaged at the same time using dual sensors. DuplexSequential indicates that first one side and then the other side is imaged using the same sensor mechanism, with automatic flipping of the original document." ::= { scnODHEntry 9 } scnODHDocumentScanOrder OBJECT-TYPE -- This value is a type 2 enumeration SYNTAX INTEGER { other(1), unknown(2), firstToLast(3), lastToFirst(4) } MAX-ACCESS read-only STATUS current Lutz, Bergman, Wagner [Page 21] INTERNET-DRAFT Scanner MIB January 31, 2000 DESCRIPTION "The order of document traversal performed by this ODH. FirstToLast indicates that the first page of the document is scanned first and the last page is scanned last, which is 'Scanner Order' or 'Fax Order'. LastToFirst indicates that the last page is scanned first and the first page is scanned last. This is 'Copier Order'." ::= { scnODHEntry 16 } scnODHInterleaving OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The number of scans that the duplex pages are offset from each other. (0) indicates that the first side and opposite side are scanned concurrently. (1) indicates that the opposite side is scanned one page after the first side (i.e. 1,2,3. . . order). (2) indicates that the first side leads the opposite side by 2 pages (1,3,2,5,. . . order). (3) indicates that the first side leads the opposite side by 3 pages, and so forth. The value (32767) indicates that the entire first side is imaged prior to the opposite side. The terms 'first side' and 'opposite side' are determined by the scnODHScanOrder attribute." ::= { scnODHEntry 17 } scnODHDescription OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturer-provided description of this ODH in the localization specified by scnGeneralCurrentLocalization." ::= { scnMediaPathEntry 18 } -- The Image Sensor Group -- A sensor is the mechanism that detects surface color on the original -- documents that are scanned. The sensor sub-units are represented by -- the Sensor Group in the model. A scanner can contain one or more -- image sensing mechanisms. Some examples of multiple sensor sub-units -- are: a scanner with separate sensors each side of the document or for -- the detection of light of differing frequency ranges, or 'colors'. -- Each sensor device can have its own set of characteristics such as -- sensing technology, resolution, image area, and bits-per-pixel depth. -- Implementation of every object in this group is mandatory. scnSensor OBJECT IDENTIFIER ::= { scannerMIB 201 } Lutz, Bergman, Wagner [Page 22] INTERNET-DRAFT Scanner MIB January 31, 2000 -- The image area margins as listed below define an area of the -- original media which is guaranteed to be detectable for this -- image sensor. scnSensorTable OBJECT-TYPE SYNTAX SEQUENCE OF scnSensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about the various image sensor sub-units in the scanner." ::= { scnSensor 1 } scnSensorEntry OBJECT-TYPE SYNTAX ScnSensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each device index whose device type is `scanner'." INDEX { hrDeviceIndex, scnSensorIndex } ::= { scnSensorTable 1 } ScnSensorEntry ::= SEQUENCE { scnSensorIndex Integer32, -- 1 scnSensorTech INTEGER, -- 2 scnSensorLifeCount Counter32, -- 3 scnSensorPowerOnCount Counter32, -- 4 scnSensorColorSpaceIndex Integer32, -- 5 scnSensorResolutionUnit INTEGER, -- 6 scnSensorOpticalResolFeedDir Integer32, -- 7 scnSensorOpticalResolXFeedDir Integer32, -- 8 scnSensorImageContrast Integer32, -- 9 scnSensorImageBrightness Integer32, -- 10 scnSensorXOffset Integer32, -- 11 scnSensorYOffset Integer32, -- 12 scnSensorOutputResolFeedDir Integer32, -- 13 scnSensorOutputResolXFeedDir Integer32, -- 14 scnSensorOpticalBitsPerPixel Integer32, -- 15 scnSensorOutputBitsPerPixel Integer32 -- 16 } scnSensorIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current Lutz, Bergman, Wagner [Page 23] INTERNET-DRAFT Scanner MIB January 31, 2000 DESCRIPTION "A unique value used by the scanner to identify this sensing sub-unit. Although these values may change due to a major reconfiguration of the device (e.g. the addition of new marking sub-units to the scanner), values are expected to remain stable across successive scanner power cycles." ::= { scnSensorEntry 1 } scnSensorTech OBJECT-TYPE -- This value is a type 2 enumeration SYNTAX INTEGER { other(1), unknown(2), LinearCCD(3), RectangularCCD(4), ContactImageSensor(5), laserScanner(6) } MAX-ACCESS read-only STATUS current DESCRIPTION _The type of sensing technology used for this sensing sub- unit." ::= { scnSensorEntry 2 } scnSensorLifeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the number of images scanned during the life of scanner." ::= { scnSensorEntry 3 } scnSensorPowerOnCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The count of the number of images scanned since the equipment was most recently powered on." ::= { scnSensorEntry 4 } scnSensorColorSpaceIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of scnColorSpaceIndex that corresponds to the row in the scnColorSpaceTable currently currently enabled for the sensor." Lutz, Bergman, Wagner [Page 24] INTERNET-DRAFT Scanner MIB January 31, 2000 ::= { scnSensorEntry 5 } scnSensorResolutionUnit OBJECT-TYPE -- This value is a type 1 enumeration SYNTAX INTEGER { tenThousandthsOfInches(3), -- .0001 micrometers(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The unit of measure of distances." ::= { scnSensorEntry 6 } scnSensorOpticalResolFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addressable optical sensing positions in the feed direction per 10000 units of measure specified by ResolutionUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'." ::= { scnSensorEntry 7 } scnSensorOpticalResolXFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addressable optical sensing positions in the cross feed direction in 10000 units of measure specified by ResolutionUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'." ::= { scnSensorEntry 8 } scnSensorImageContrast OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "This value indicates the relative sharpness of the image, with 0 being the lowest possible and 100 the highest possible contrast. The value of _1 means other and specifically indicates that the sensor is using an automatic adjustment feature. For sensors where this setting is not continuously variable, a write to this object will set the value to the closest implemented value. For example, a sensor with five possible settings can only achieve 0, 25, 50, 75, and 100. A write value of 30 will result in a read response of 25." ::= { scnSensorEntry 9 } Lutz, Bergman, Wagner [Page 25] INTERNET-DRAFT Scanner MIB January 31, 2000 scnSensorImageBrightness OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "This value indicates the relative brightness of the image, with 0 being the lightest possible and 100 the darkest possible image. The value of _1 means other and specifically indicates that the sensor is using an automatic adjustment feature. For sensors where this setting is not continuously variable, a write to this object will set the value to the closest implemented value. For example, a sensor with five possible settings can only achieve 0, 25, 50, 75, and 100. A write with a value of 30 will result in a read response of 25." ::= { scnSensorEntry 10 } scnSensorXOffset OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The offset, in units identified by ResolutionUnit, from the X reference edge of the original document to the output scanned image. The X reference edge is 180 degrees from the leading edge of the original document, as defined by the direction of the scan. Negative margin values are typical and indicate that extra area is imaged that is never part of the original document. Refer to the scan offsets figure." ::= { scnSensorEntry 11 } scnSensorYOffset OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The offset, in units identified by ResolutionUnit, from the leading edge of the original document, as defined by the direction of the scan, to the output scanned image. Negative margin values are typical and indicate that extra area is imaged that is never part of the original document. Refer to the scan offsets figure." ::= { scnSensorEntry 12 } Lutz, Bergman, Wagner [Page 26] INTERNET-DRAFT Scanner MIB January 31, 2000 -- Scan Offsets -- | -- V -- +------------------------------------+ -------- -- | original image | Y offset -- | +----------------------------+ - |--------- -- | | / / / / / / / | | ^ -- | | / / / / / / / | | | -- | |/ / / / / / / | | -- | | / / / / / / /| | -- | | / / / / / / / | | | -- | | / / scanned image / / | | direction | -- | |/ / / / / / / | | | -- | | / / / / / / /| | of scan | -- | | / / / / / / / | | | -- | | / / / / / / / | | V -- | |/ / / / / / / | | -- | | / / / / / / /| | -- | | / / / / / / / | | -- | | / / / / / / / | | -- | |/ / / / / / / | | -- | | / / / / / / /| | -- | +----------------------------+ | -- | | | -- +------------------------------------+ -- | | -- ->| |<- X offset -- |<------ X reference edge -- scnSensorOutputResolFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addressable output image positions in the feed direction per 10000 units of measure specified by ResolutionUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'." ::= { scnSensorEntry 13 } scnSensorOutputResolXFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addressable output image positions in the cross feed direction in 10000 units of measure specified by ResolutionUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'." Lutz, Bergman, Wagner [Page 27] INTERNET-DRAFT Scanner MIB January 31, 2000 ::= { scnSensorEntry 14 } scnSensorOpticalBitsPerPixel OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of bits used to describe a single pixel, as generated by the sensor in a single frequency range sample." ::= { scnSensorEntry 15 } scnSensorOutputBitsPerPixel OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of bits used to describe a single pixel, as output by the scanner for a single frequency range sample." ::= { scnSensorEntry 16 } -- The Color Space Group -- A color space determines the meaning of color values and their -- relation to each other. The Color Space table lists color spaces -- that are supported by the image processor Image Processor. scnColorSpace OBJECT IDENTIFIER ::= { scannerMIB 202 } scnColorSpaceTable OBJECT-TYPE SYNTAX scnColorSpaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each device index whose device type is `image processor'." INDEX { hrDeviceIndex, scnColorSpaceIndex } ::= { scnColorSpace 1 } ScnColorSpaceEntry ::= SEQUENCE { scnColorSpaceIndex Integer32, scnColorSpaceType INTEGER } scnColorSpaceIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the image processor to identify this color space. Although these values may change due to a major reconfiguration of the device, values are Lutz, Bergman, Wagner [Page 28] INTERNET-DRAFT Scanner MIB January 31, 2000 expected to remain stable across successive image processor power cycles." ::= { scnColorSpaceEntry 1 } scnColorSpaceType OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), ColorSpaceNative(3), ColorSpacesRGB(4), -- sRGB ColorSpaceCIEXYZ(5), -- CIEXYZ ColorSpaceCIELAB(6), ColorSpaceCMYK(7), ColorSpaceBiLevelMinWhite(8), -- Each pixel is a single bit. -- 0 is white. ColorSpaceBiLevelMinBlack(9), -- Each pixel is a single bit. -- 0 is black. ColorSpaceGrayScale(10), -- Each pixel is composed of a -- single gray sample. ColorSpacePallette(11) -- Each pixel indexes into a } -- color mapping table. MAX-ACCESS read-only STATUS current DESCRIPTION "The Color Space types supported by the image processor." ::= { scnColorSpaceEntry 2} -- The Data and Control Channel Group -- Implementation of every object in this group is mandatory. -- The methods and paths of communicating with the scanner are -- significant to scanner management both to identify and manage the -- features of the capability and to let a prospective user know how to -- access the scanner. -- Communication to Scanners for job setup (scanning parameters and job -- delivery instructions) generally occurs at a different time and often -- via a different path than the actual delivery of the scanned data. It -- is therefore necessary to distinguish between Scanner Job Control -- Communications Channels (control channels) and Scanner Job Data -- Delivery Communications Channels (data channels). -- In a given device, the scanner channels are unique to the scanner; -- the channels will use the system interfaces, which may be shared by -- various functions within the system. This imposes a level of detail -- in the scanner communications channel description. For example, -- Ethernet defines an interface that can be used by multiple functions. -- TCP/IP defines a protocol, and FTP a service that also may be used by -- multiple functions. But TCP at a given port number, and FTP at a -- given depth in the file directory can define a Scanner channel. This Lutz, Bergman, Wagner [Page 29] INTERNET-DRAFT Scanner MIB January 31, 2000 -- information about the channel is given in the Channel information -- object of the Scanner Communication Channel group. This object is -- very similar in form to, and is evolved from the Channel information -- object in the Scanner MIB. However, as shown in the textual -- convention coding of entries, there is some difference in the -- required information. -- There are many kinds of Scanner Communication Channels; some of which -- are based on networks and others which are not. A channel can be -- based on a local connection using a EIA232, IEEE1284, or SCSI -- interface; it can be a network raw TCP connection; it can be a -- network application such as FTP, offering transfer services. A -- control channel is often provided from the system console; this may -- be the primary control input mechanism for the scanner. A data -- channel could be effected by a disk drive into which a removable -- medium is inserted to receive the data file. The control panel and -- disk drives, as devices, would be managed via their own groups in the -- MIB, just as the interfaces forming the basis for local and network -- channels are managed via their own MIB. -- The Scanner Communications channel is not determined by the -- characteristics of the interface or media. A control channel must -- provide for the input of job setup, processing and delivery -- information (possible including device setup and management -- information) in a form suitable for input to the controller. A data -- channel must provide for the output of image data. A channel may be -- independently enabled (allowing data to flow) or disabled (stopping -- the flow). A scanner may have one or more Communication Channels. -- Scanner Communication Channels may represent a client application or -- a server application. For example, a scanner FTP data channel can -- either be in a client mode (in which case the scanner will connect to -- a remote server and 'pushes' the file to that server), or it can be -- in a server mode (the end user connects to the scanner and 'pulls' -- the file from the scanner. If a connection can be used in either -- mode, then it must be listed as two channels. -- Scanner Communication Channel management objects are in the Scanner -- Communication Channel Group as represented in the Model diagram. The -- objects are arraigned in tabular fashion, with an equivalent set of -- objects reported for each channel supported. In keeping with the -- objective of providing sufficient information to allow user access to -- the scanner, objects include sufficient information to establish a -- connection and to identify the current job control language and -- output data format for this channel. With these exceptions, the -- Scanner Communication Channel table reflects the capabilities of the -- scanner, not necessarily what is currently in use. -- The first seven items in the Scanner Communication Channel Table -- define the "Communication Channel " itself. Control of a Scanner -- Communication Channel, when supported, is limited to enabling or Lutz, Bergman, Wagner [Page 30] INTERNET-DRAFT Scanner MIB January 31, 2000 -- disabling the flow of information through the channel; this is -- reflected in the "state" object. Most of the specifics of the -- connection are a function of the interface used by the channel, and -- the basic interface is identified. Note that, in some cases, the -- channel aspect is inseparable from the interface; this is more often -- the case with local interfaces. -- The Scanner Communication Channel Table -- The scnChannelTable represents the set of communication capabilities -- supported by the scanner to input control information and output -- image files. -- scnChannel OBJECT IDENTIFIER ::= { scannerMIB 203 } scnChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF ScnChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { scnChannel1 } scnChannelEntry OBJECT-TYPE SYNTAX ScnChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each device index with a device type of 'scanner'." INDEX { hrDeviceIndex, scnChannelIndex } ::= { scnChannelTable 1 } ScnChannelEntry ::= SEQUENCE { scnChannelIndex Integer32, scnChannelType ScnChannelTypeTC, scnChannelProtocolVersion OCTET STRING, scnChannelMode scnChannelModeTC scnChannelCurrentJobCntlLangIndex Integer32, scnChannelOutputFormat scnChannelOutputFormatTC, scnChannelState ScnChannelStateTC, scnChannelIfIndex Integer32, scnChannelStatus ScnSubUnitStatusTC, scnChannelInformation OCTET STRING } scnChannelIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION Lutz, Bergman, Wagner [Page 31] INTERNET-DRAFT Scanner MIB January 31, 2000 "A unique value used by the scanner to identify this data Communication Channel. Although these values may because of a major reconfiguration of the device, values are expected to remain stable across successive scanner power cycles." ::= { scnChannelEntry 1 } scnChannelType OBJECT-TYPE SYNTAX ScnChannelTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the connection or service forming the basis of this scanner Communication Channel." ::= { scnChannelEntry 2 } scnChannelProtocolVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..63)) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the connection or service on this Communication Channel. The format used for version numbering depends on scnChannelType." ::= { scnChannelEntry 3 } scnChannelMode OBJECT-TYPE SYNTAX scnChannelModeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The channel can be for control or data delivery, or both. The channel can initiate connection with a server to obtain Control information or to deliver a data file (client mode operation), or it can accept a connection from a client that presents control information or recovers the data files. ::= { scnChannelEntry 4 } scnChannelCurrentJobCntlLangIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value of scnCntlLangIndex corresponding to the Control Language currently active for this Communication Channel. A value of zero indicates that there is no current Control Language for this Communication Channel. [This assumes that there is a scnCntlLang group, or something equivalent. If there is not, this can just refer to an enumeration in a table of values" ::= { scnChannelEntry 5 } Lutz, Bergman, Wagner [Page 32] INTERNET-DRAFT Scanner MIB January 31, 2000 scnChannelOutputFormat OBJECT-TYPE SYNTAX scnChannelOutputFormatTC MAX-ACCESS read-write STATUS current DESCRIPTION "The value of scnChannelOutputFormatT code corresponding to current image file output format assigned to this Communication Channel. This may be a default value. [note: there can either be a table of formats here, or an index to another group.] ::= { scnChannelEntry 6 } scnChannelState OBJECT-TYPE -- This value is a type 1 enumeration SYNTAX ScnChannelStateTC MAX-ACCESS read-write STATUS current DESCRIPTION "The state of this Communication Channel . The value determines whether this Communication Channel is enabled or whether it is disabled." ::= { scnChannelEntry 7 } scnChannelIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value of ifIndex (in the ifTable; see the interface section of MIB-2/RFC 1213) which corresponds to this Communication Channel. If more than one row of the ifTable is relevant, this is the index of the row representing the topmost layer in the interface hierarchy. A value of zero indicates that no interface is associated with this Communication Channel ." ::= { scnChannelEntry 8 } scnChannelStatus OBJECT-TYPE SYNTAX ScnSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of the Communication Channel ." ::= { scnChannelEntry 9 } scnChannelInformation OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION Lutz, Bergman, Wagner [Page 33] INTERNET-DRAFT Scanner MIB January 31, 2000 "Auxiliary information to allow a scanning application to use this Communication Channel to setup the scanner or to recover image data. scnChannelInformation is not intended to provide a general Communication Channel description, nor to provide information that is available once the control Communication Channel is in use. The encoding and interpretation of the scnChannelInformation object is specific to Communication Channel type. The description of each ScnChannelType enum value for which scnChannelInformation is defined specifies the appropriate encoding and interpretation, including interaction with other objects. For Communication Channel types for which there is no applicable scnChannelInformation value, its value shall be null (0 length). When a new ScnChannelType enumeration value is registered, its accompanying description must specify the encoding and interpretation of the scnChannelInformation value structure for that Communication Channel type. scnChannelInformation semantics for an existing ScnChannelType may be added or amended in the same manner as described for type 2 enumeration values. The scnChannelInformation specifies values for a collection of Communication Channel attributes, represented as text according to the following rules: 1. The scnChannelInformation is not affected by localization. 2. The scnChannelInformation is a list of entries representing the attribute values. Each entry consists of the following items, in order: a. a keyword, composed of alphabetic characters (A-Z, a-z) represented by their NVT ASCII [NVT ASCII] codes, that identifies a Communication Channel attribute b. the NVT ASCII code for an Equals Sign (=) (code 61) to delimit the keyword, c. a data value encoded using rules specific to the ScnChannelType to which the scnChannelInformation applies. The value must in no case include an octet with value 10 (the NVT ASCII Line Feed code), d. the NVT ASCII code for a Line Feed character (code 10) to delimit the data value. No other octets shall be present. Lutz, Bergman, Wagner [Page 34] INTERNET-DRAFT Scanner MIB January 31, 2000 Keywords are case-sensitive. Conventionally, keywords are capitalized (including each word of a multi-word keyword) and since they occupy space in the scnChannelInformation, they are kept short. 3. If a Communication Channel attribute has multiple values, it is represented by multiple entries with the same keyword, each specifying one value. Otherwise, there shall be at most one entry for each attribute. 4. By default, entries may appear in any order. If there are ordering constraints for particular entries, these must be specified in their definitions. 5. The scnChannelInformation value by default consists of text represented by NVT ASCII graphics character codes. However, other representations may be specified: a. In cases where the scnChannelInformation value contains information not normally coded in textual form, whatever symbolic representation is conventionally used for the information should be used for encoding the scnChannelInformation value. (For instance, a binary port value might be represented as a decimal number using NVT ASCII codes.) Such encoding must be specified in the definition of the value. b. The value may contain textual information in a character set other than NVT ASCII graphics characters. (For instance, an identifier might consist of ISO 10646 text encoded using the UTF-8 encoding scheme.) Such a character set and its encoding must be specified in the definition of the value. 6. For each ScnChannelType for which scnChannelInformation entries are defined, the descriptive text associated with the ScnChannelType enumeration value shall specify the following information for each entry: Title: Brief description phrase, e.g.: 'Port name', 'Service Name', etc. Keyword: The keyword value, e.g.: 'Port' or 'Service' Syntax: The encoding of the entry value if it cannot be directly represented by NVT ASCII. Status: 'Mandatory', 'Optional', or 'Conditionally Lutz, Bergman, Wagner [Page 35] INTERNET-DRAFT Scanner MIB January 31, 2000 Mandatory' Multiplicity: 'Single' or 'Multiple' to indicate whether the entry may be present multiple times. Description: Description of the use of the entry, other information required to complete the definition (e.g.: ordering constraints, interactions between entries). Applications that interpret scnChannelInformation should ignore unrecognized entries, so they are not affected if new entry types are added." ::= { scnChannelEntry 10 } ------------------------------------------------------------------- -- -- The Control Language Group -- -- The Control Language sub-units are responsible for setting up -- scanning parameters. A scanner may support one or more -- Control Languages. The Control Language sub-units are -- represented by the Control Language Group in the Model. -- Each Control Language is generally implemented by software -- running on the System Controller sub-unit. The Control -- Language Table has one entry per Control Language. -- -- Implementation of every object in this group is mandatory. scnCntrlLang OBJECT IDENTIFIER ::= { scannerMIB 204 } -- CntrlLang Table -- -- The scnCntrlLangTable is a table representing the -- CntrlLangs in the scanner. An entry shall be placed in the -- CntrlLang table for each CntrlLang on the scanner. scnCntrlLangTable OBJECT-TYPE SYNTAX SEQUENCE OF PrtCntrlLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" ::= { scnCntrlLang 1 } scnCntrlLangEntry OBJECT-TYPE SYNTAX ScnCntrlLangEntry MAX-ACCESS not-accessible Lutz, Bergman, Wagner [Page 36] INTERNET-DRAFT Scanner MIB January 31, 2000 STATUS current DESCRIPTION "Entries may exist in the table for each device index with a device type of 'scanner'." INDEX { hrDeviceIndex, scnCntrlLangIndex } ::= { scnCntrlLangTable 1 } ScnCntrlLangEntry ::= SEQUENCE { scnCntrlLangIndex Integer32, scnCntrlLangLangFamily ScnCntrlLangLangFamilyTC, scnCntrlLangLangLevel OCTET STRING, scnCntrlLangLangVersion OCTET STRING, scnCntrlLangDescription OCTET STRING, scnCntrlLangVersion OCTET STRING, } scnCntrlLangIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value for each control language in the scanner. The value is used to identify this Control Language. Although these values may change due to a major reconfiguration of the device (e.g. the addition of new Control Languages to the scanner), values are expected to remain stable across successive scanner power cycles." ::= { scnCntrlLangEntry 1 } scnCntrlLangLangFamily OBJECT-TYPE -- This value is a type 2 enumeration SYNTAX ScnCntrlLangLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Scanner Control Language which the scanner can interpret and implement." ::= { scnCntrlLangEntry 2 } scnCntrlLangLangLevel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The level of the Control Language which the scanner supports." ::= { scnCntrlLangEntry 3 } scnCntrlLangLangVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only Lutz, Bergman, Wagner [Page 37] INTERNET-DRAFT Scanner MIB January 31, 2000 STATUS current DESCRIPTION "The date code or version of the control language which the scanner supports. ::= { scnCntrlLangEntry 4 } scnCntrlLangDescription OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "A string to identify this Control Language in the localization specified by prtGeneralCurrentLocalization as opposed to the language which is being interpreted. It is anticipated that this string will allow manufacturers to unambiguously identify their Control Languages." ::= { scnCntrlLangEntry 5 } scnCntrlLangVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..31)) MAX-ACCESS read-only STATUS current DESCRIPTION "The date code, version number, or other product specific information tied to this Control Language. This value is associated with the Control Language, rather than with the version of the language which is being interpreted or emulated." ::= { scnCntrlLangEntry 6 } ---------------------------------------------------------------- -- Conformance Information #### Needs to be updated #### scnMIBConformance OBJECT IDENTIFIER ::= { scanmib 2 } -- compliance statements scnMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the scanner MIB." MODULE -- this module MANDATORY-GROUPS { scnGeneralGroup, scnInputGroup, scnOutputGroup, scnSensorGroup, scnConverterGroup, scnChannelGroup, scnInterpreterGroup, scnConsoleGroup, scnAlertTableGroup } OBJECT scnGeneralReset Lutz, Bergman, Wagner [Page 38] INTERNET-DRAFT Scanner MIB January 31, 2000 SYNTAX INTEGER { notResetting(3), resetToNVRAM(5) } DESCRIPTION "It is conformant to implement just these two states in this object. Any additional states are optional." OBJECT scnConsoleOnTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." OBJECT scnConsoleOffTime MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only." the scnResponsiblePartyGroup, scnExtendedInputGroup, scnInputMediaGroup, scnExtendedOutputGroup, scnOutputDimensionsGroup, scnOutputFeaturesGroup, scnMarkerSuppliesGroup, scnMarkerColorantGroup, and the scnAlertTimeGroup are completely optional. ::= { scnMIBConformance 1 } scnMIBGroups OBJECT IDENTIFIER ::= { scnMIBConformance 2 } scnGeneralGroup OBJECT-GROUP OBJECTS { scnGeneralConfigChanges, scnGeneralCurrentLocalization, scnGeneralReset, scnLocalizationLanguage, scnLocalizationCountry, scnLocalizationCharacterSet, scnStorageRefIndex, scnDeviceRefIndex scnGeneralName, scnGeneralVendorName, scnGeneralModel, scnGeneralVersion, scnGeneralSerialNumber, scnGeneralDescription } STATUS current DESCRIPTION "The general scanner group." ::= { scnMIBGroups 1 } scnResponsiblePartyGroup OBJECT-GROUP OBJECTS { scnGeneralCurrentOperator, scnGeneralServicePerson } STATUS current DESCRIPTION "The responsible party group contains contact information for humans responsible for the scanner." ::= { scnMIBGroups 2 } scnODHGroup OBJECT-GROUP Lutz, Bergman, Wagner [Page 39] INTERNET-DRAFT Scanner MIB January 31, 2000 OBJECTS { scnODHDefaultIndex, scnODHType, scnODHDimUnit, scnODHDimFeedDir, scnODHDimXFeedDir, scnODHCapacityUnit, scnODHInputMaxCapacity, scnODHInputCurrentLevel, scnODHMaxMediaWeight, scnODHOutputMaxCapacity, scnODHOutputRemainingCapacity } STATUS current DESCRIPTION "The ODH group." ::= { scnMIBGroups 3 } scnChannelGroup OBJECT-GROUP OBJECTS { scnChannelType, scnChannelProtocolVersion, scnChannelCurrentJobCntlLangIndex, scnChannelDefaultPageDescLangIndex, scnChannelState, scnChannelIfIndex } STATUS current DESCRIPTION "The channel group." ::= { scnMIBGroups 14 } scnJobControlGroup OBJECT-GROUP OBJECTS { scnJobControlType} STATUS current DESCRIPTION "The JobControl group." ::= { scnMIBGroups 15 } scnConsoleGroup OBJECT-GROUP OBJECTS { scnConsoleLocalization, scnConsoleNumberOfDisplayLines, scnConsoleNumberOfDisplayCols, scnConsoleDisable, scnConsoleDisplayBufferData, scnConsoleOnTime, scnConsoleOffTime, scnConsoleColor, scnConsoleDescription } STATUS current DESCRIPTION "The console group." ::= { scnMIBGroups 16 } scnAlertTableGroup OBJECT-GROUP OBJECTS { scnAlertSeverityLevel, scnAlertTrainingLevel, scnAlertGroup, scnAlertGroupIndex, scnAlertLocation, scnAlertCode, scnAlertDescription } STATUS current DESCRIPTION "The alert table group." ::= { scnMIBGroups 17 } END Appendix A - Glossary of Terms Lutz, Bergman, Wagner [Page 40] INTERNET-DRAFT Scanner MIB January 31, 2000 Alert -- a reportable event for which there is an entry in the alert table. Channel -- A term used to describe a single source of data which is presented to a scanner. The model that we use in describing a scanner allows for an arbitrary number of channels. Multiple channels can exist on the same physical port. This is commonly done over Ethernet ports where EtherTalk, TCP/IP, and SPX/IPX protocols can be supplying different data streams simultaneously to a single scanner on the same physical port. Control Language - a data syntax or language for controlling the scanner through the scan data channel. Critical Alert -- an alert triggered by an event which leads to a state in which scanning is no longer possible; the scanner is stopped. Description -- information about the configuration and capabilities of the scanner and its various sub-units. Endorser -- A marking mechanism specifically adapted to print on the scanned originals. The endorsing mechanism must be capable of printing on various original document types, and can occur before or after the scanning process. The endorsement will typically show the time and date of scanning so that the original can be later destroyed or recycled. Event - a state change in the scanner. Group -- a collection of objects that represent a type of sub-unit of the scanner. IANA - Internet Assigned Numbers Authority. See STD 2, RFC 1700. Idempotent -- Idempotence is the property of an operation that results in the same state no matter how many times it is executed (at least once). This is a property that is shared by true databases in which operations on data items only change the state of the data item and do not have other side effects. Because the SNMP data model is that of operations on a database, SNMP MIB objects should be assumed to be idempotent. If a MIB object is defined in a non-idempotent way, the this data model can break in subtle ways when faced with packet loss, multiple managers, and other common conditions. In order to fulfill the common need for actions to result from SNMP Set operations, SNMP MIB objects can be modeled such that the change in state from one state to another has the side effect of causing an action. It is important to note that with this model, an SNMP operation that sets a value equal to its current value will cause no action. This retains the idempotence of a single command, while allowing actions to be initiated by SNMP SET requests. Lutz, Bergman, Wagner [Page 41] INTERNET-DRAFT Scanner MIB January 31, 2000 For example, a switch like the foot switch that changes from high beams to low beams is not idempotent. If the command is received multiple times the result may be different than if the command was received a single time. In the SNMP world preferred commands would be "set lights to high beam" and "set lights to low beam". These commands yield predictable results when executed perhaps multiple times. A command like "press foot toggle switch", is not idempotent because when executed an unknown number of times, it yields an indeterminate result. Input -- a tray or bin from which instances of original documents are obtained for scanning. Localization -- the specification of human language, country, and character set needed to present information to people in their native languages. Management Application (a.k.a. Manager) -- a program which queries and controls one or more managed nodes. Management Station -- a physical computer on which one or more management applications can run. Media Path -- the mechanisms that transport instances of the media from an input, through the marker, possibly through media buffers and duplexing pathways, out to the output. The inputs and outputs are not part of the Media Path. MIB - Management Information Base - the specification for a set of management objects to be managed using SNMP or other management protocol; also an instance of the data for such a set. Non-critical Alert -- an alert triggered by a reportable event which does not lead to a state in which scanning is no longer possible; such an alert may lead to a state from which scanning may no longer be possible in the future, such as the low toner state or the alert may be pure informational, such as a configuration change at the scanner. Object - a data item that has a name, a syntax, and a value. Original Document Handler -- the mechanism which includes the Input, Media Path, and Output and serves to process the original documents for scanning. Output -- a bin or stacker which accepts instances of original documents that have been processed by a scanner. Resolution -- on the sensing unit, the natural separation of the photodetectors combined with the gradient depth of each measurement, in terms of pixels-per-unit dimension in each of the x and y directions combined with bits-per-pixel. Lutz, Bergman, Wagner [Page 42] INTERNET-DRAFT Scanner MIB January 31, 2000 Scanner -- a physical device that takes original documents from an input bin, produces illuminates and detects marks on the surface of the documents creating an image file, and then depositing the original documents in an output bin. In some scanners, the original documents are also 'endorsed' or marked on by the scanner either before or after the scanning process to indicate that the document has been processed. In some scanners, the input and output 'bin' is the same and can be as simple as a flatbed window. Scanning -- the entire process of producing an image file from an original doucment from selection of a scanner, choosing scanning properties, generation of the image file from the original document, and then routing or notifying the user. Reportable event -- an event that is deemed of interest to a management station watching the scanner. Status -- information regarding the current operating state of the scanner and its various sub-units. This is an abstraction of the exact physical condition of the scanner. Sub-mechanism -- a distinguishable part of a sub-unit. Sub-unit -- a part of the scanner which may be a physical part, such as one of the ODHs or a logical part such as the image processor. Visible state -- that portion of the state of the scanner that can be examined by a management application. CHANGE HISTORY Version 8.0: - Changed format for an internet draft. Added ID boiler plate. - Added new paragraph immediately under "1. Introduction". - Revised figure 1 and changed into figure 1a and figure 1b. - Removed most of section 1.3.3 and added reference to the MFP MIB. - Rewrote introductory paragraph is section 2. To refer to the MFP MIB. - Revised figure 2 to show only the scanner block from the MFP MIB. - Added Color Space block to figure 2. - Change figure 2 block names to match rest of MIB. - Minor changes to sections 2.1 and 2.2 introductory paragraph. - Major rewrite of section 2.2.1, most of this text moved to MFP MIB. - Section 2.2.3 no longer has a separate section number. - Section 2.2.4 is now 2.2.3. - Section 2.2.7 is now 2.2.4. - Section 2.2.8 is now 2.2.5. - Deleted sections 2.2.5, 2.2.6, 2.2.9, 2.2.10, and all 2.2.11 sections. - Revised the enumeration names (were just text) for ScnChannelModeTC and ScnChannelStateTC. Lutz, Bergman, Wagner [Page 43] INTERNET-DRAFT Scanner MIB January 31, 2000 - Total rewrite of section 3 and deleted all sub-sections. This text will be incorporated into the MFP MIB. - Removed the alert group definitions and the device type registrations. These items will be added to the MFP MIB. - Removed all entries in the General table that are to be in the MFP MIB and added the scnColorSpaceDefaultIndex. - Removed the scnSensorDropout object. Will be added to the MFP MIB. - Removed the Job Control group. (Has been replaced by the Control Language group.) - Removed the Console group. Will be added to the MFP MIB. - Removed the scnSensorMargin objects (4) and replaced with the scnSensorXOffset and scnSensorXOffset. Added a reference figure. Version 7.0: - Revised section 1.1. _Scanners have been typically either been vertically integrated into larger systems or have been desktop devices connected directly to a workstation__ was _Scanners have been typically a desktop device, connected directly to a workstation__ - Added a paragraph to section 1.3.3 that briefly describes how the Printer MIB is used to provide the Alert Table functionality. - Revised section 2.2.5. _The Scanner Controller sub-unit is the general processing part of the scanner, containing the standard computing components of CPU, memory, instruction store and the software and firmware of the Scanner._ Was _The Scanner Controller sub-unit contains the software and firmware components of the Scanner._ - Major revision of section 2.2.7. - Total rewrite of section 3 to include a better description of how and why other MIBs are to be used with the Scanner MIB. Much of this information was derived from the new Printer MIB. Additional text was added relative to the required use of the Printer MIB for the cover table, localization table, storage reference table, console display buffer table, console light table, and the alert table. - Added the scnColorSpaceTable, which was moved from the MFP MIB. - Deleted the console button table. - Added ScnChannelModeTC, ScnChannelStateTC, and ScnChannelTypeTC. - ISSUE: Should the enums in ScnChannelTypeTC be aligned with the Printer MIB? - ISSUE: Channel types are now different from version 6. - Added PrtAlertGroupTC from the Printer MIB and added new group definitions for use by the Scanner MIB. - Defined the MIB structure as _enterprises mfpa(5335) mibs(1) scannerMIB(1)_. - Changed _MediaUnit_ to _PrtMediaUnitTC_ and _CapacityUnit_ to _PrtCapacityUnitTC_ to align with the new Printer MIB. - Changed source of Boolean and KBytes to _HOST-RESOURCES MIB_, was _PRINTER-MIB_. - Defined an OID for use with hrDeviceType as _scannerMIB scannerMIBTypes(1) scannerDeviceTypes(1). - Changed _scnGeneralIndex_ to _hrDeviceIndex_. Lutz, Bergman, Wagner [Page 44] INTERNET-DRAFT Scanner MIB January 31, 2000 - Removed "scnGeneralCurrentOperator" and "scnGeneralCurrentServicePerson". - Deleted _scnSensorSamplesPerPel_ and _scnSensorBitsPerSample_. - Added "scnSensorImageContrast" and "scnSensorImageBrightness". - Renamed "scnSensorResolutionFeedDir" to "scnSensorOpticalResolFeedDir" (same change to "scnSensorResolutionXFeedDir"). Also added "optical" to text. - Added "scnSensorOutputResolFeedDir" and "scnSensorOutputResolXFeedDir". - Added _scnSensorOpticalBitsPerPixel_ and _scnSensorOutputBitsPerPixel_. - The Channels group is replaced with new text from Bill Wagner. - ISSUE: Should Console Group be moved to the MFP MIB? This MIB can be used to define which devices in a multifunction product have a unique control panel and which share a common panel. - Added _scnSensorColorDropout_ to the scnSensor Group. - ISSUE: Are additional colors possible for _scnSensorColorDropout_ enums. - Changed _scnSensorColors_ to _scnSensorColorSpaceIndex_ to indicate which entry in scnColorSpaceTable is currently used by the scanner sensor. - Added Control Language Group from Bill Wagner - ISSUE: Need to add ScnCntrlLangFamilyTC as referenced by Control Language Group. - NOTE: The Conformance Group has not been updated. Version 6.0: - Removed details of Image Processor subsystem. This avoids most of the "new" structures of the scanner and should expedite completion. Block diagram reduced to single block in this area. Image Processing groups moved to another document. - Merged in channels section as proposed by Ron Bergman. Revised to omit channel status. - Modified Control Language Type to enumeration instead of MIME type. - Added reference to front piece in comments regarding dual console. - OPEN: There is still some trouble with embedded storage. Don Wright suggests that we divorce the scanner mib from the host resources mib. Needs further review. - OPEN: Need to express the maximum size of the file that can result from a single document scan -- perhaps part of the storage section that is brought in from the hr mib. Needs further review. - OPEN: Need to add job submission and workflow to another set of MIB- like definitions. Use SNMP mibs to the extent that default or static configuration and capabilities is concerned, use Job-Submission and WorkFlow structures for job-specific information. - OPEN: Need object of URL of destination location -- this perhaps in job control "ticket" or workflow structure. Version 5.0: Lutz, Bergman, Wagner [Page 45] INTERNET-DRAFT Scanner MIB January 31, 2000 - Changed model in Figure 2 and associated text to reflect unifying input/media path/output into single group "Original Document Handling" and other substantial changes, including adding the Formatter and Image Processor sub-units, and reorganizing the blocks to effectively show the system controller. - Modified the Status approach to avoid the Host Resources MIB and to simplify the status states. - Removed hr.. sections that were pasted on at the end for reference in version 4. - Used imports of textual conventions from RFC1759 instead of repeating them here. - Fixed System Resources Tables since printer MIB needed to deal with some state that was included in the Host Resources MIB, and scanner MIB does not need to do this. - Changed the philosophy regarding the Job Control Group so that only one interpreter would exist that supports various forms of Job Control "Ticket" information. - reduced entries in systems resources tables, eliminating "DeviceRef" which was used to index the hr MIB groups that referenced printers. - Modified the Image Processing group to include the file format, dithering mode, and any barcode recognition mode. - Change console group to include bitmapped display. I am worried about this and would like to consider other options, such as HTML. Also added buttons. - Cleanup of introductory text. - Simplified the Image Processing group and added several contributory tables: Formats, Color, Dither, BarCode, Zoom. Now the Image processing group assumes that the images are only taken from the scanner, and the table of settings will allow us to establish various profiles for different operations, such as scan to disk or scan for fax, which require significantly different image organizations. I imagine we will need some additional tables for other settings, but the basic philosophy is shown here. Version 4.0: Change network model, Figure 1 per 6/18/1999 meeting Change nomenclature of Data Store, Add CO-located workstation Show internal data store Eliminate 'supervisor' Fix arrows to the right direction Change scanner block diagram, Figure 2 per 6/18/1999 meeting Change 'Marker' to 'Media Path' Change 'interpreter' to 'command interpreter' Delete ref. to host MIB. Add internal data store block Remove references to 'Marking Subsystem' and replace with 'Media Path' smartly. Remove reliance on Host Resources MIB -- This was partially attempted but some confusion remains. The Host Resources MIB was appended to the bottom of this file for further discussion of how to incorporate the groups of the HR MIB if it is not included by reference. Lutz, Bergman, Wagner [Page 46] INTERNET-DRAFT Scanner MIB January 31, 2000 The following comment is from Ron Bergman: Remove all references to the Host Resources MIB. Section 2.2.13.2 [Overall Scanner Status](and the two sub-sections) should be "TBD". I recommend that 'hrDeviceIndex' be changed to 'scnDeviceIndex' for now. I can help you with a formal definition later if you are not sure have to define this object. Dependence upon the HR MIB is one of the current weaknesses of the Printer MIB, as was mentioned by Bill Wagner. This was a requirement from the IETF advisors when the Printer MIB was developed. As long as there is no intention of publishing the MIB as an IETF Standards Track document, which would be near impossible anyway, this should not be an issue. The document can still be published as an IETF Informational or Experimental MIB. (In general this status in not important except to the IETF.) The term 'hrDeviceIndex' was changed to 'scnDeviceIndex'. Lutz, Bergman, Wagner [Page 47]