INTERNET-DRAFT R. Lutz MFPA Technical Committee Cognisys, Inc. May 6, 2001 R. Bergman Hitachi Koki B. Wagner NETsilicon, Inc. Network Scanner MIB, Version 13.0 Expires October 6, 2001 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) 2000, The Multifunction Products Association (MFPA). 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 May 6, 2000 TABLE OF CONTENTS 1. INTRODUCTION......................................................3 1.1. Terminology for Conformance....................................3 1.2 Network Scanning Environment....................................3 1.3 Scanner Device Overview .........................................5 1.4 Categories of Scanner Information ...............................6 1.4.1 Descriptions.................................................6 1.4.2 Status.......................................................6 1.4.3 Alerts.......................................................6 2. THE SNMP MANGEMENT FRAMEWORK......................................7 3. SCANNER MODEL.....................................................8 3.1 Overview of the Scanner Model...................................8 3.2 Scanner Sub-Units...............................................9 3.2.1 General Scanner.............................................10 3.2.2 Original Document Handler...................................10 3.2.3 Image Sensor................................................11 3.2.4 Communication Channel.......................................11 3.2.5 Scanner Control Interpreter.................................12 3.2.6 Color Space.................................................12 3.3 Read-Write Objects.............................................12 3.4 Enumerations...................................................13 3.4.1 Registering Additional Enumerated Values....................13 4. Objects from other MIB Specifications............................13 5. NETWORK SCANNER MIB SPECIFICATION................................14 -- Textual conventions for this MIB module..........................14 -- The General Scanner Group........................................15 -- The Original Document Handler (ODH) Group........................17 -- The Image Sensor Group...........................................24 -- The Color Space Group............................................30 -- The Data and Control Channel Group...............................31 -- The Control Language Group.......................................38 -- Conformance Information..........................................41 6. SECURITY CONSIDERATIONS..........................................44 7. REFERENCES.......................................................45 8. TERMINOLOGY......................................................46 9. FULL COPYRIGHT STATEMENT.........................................49 10. AUTHORS.........................................................50 11. CHANGE HISTORY..................................................50 Lutz, Bergman, Wagner [Page 2] INTERNET-DRAFT Scanner MIB May 6, 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. Terminology for Conformance The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted per [RFC-2119]. 1.2 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 3] INTERNET-DRAFT Scanner MIB May 6, 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 | | (Optional) | +-------------+ 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 4] INTERNET-DRAFT Scanner MIB May 6, 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.3 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 5] INTERNET-DRAFT Scanner MIB May 6, 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.4 Categories of Scanner Information Information about scanners is classified into three basic categories; descriptions, status, and alerts. 1.4.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.4.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.4.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 6] INTERNET-DRAFT Scanner MIB May 6, 2000 ability to scan. See the Multifunction Product MIB [MFP-MIB] for additional information regarding the design and usage of the Alert Table. 2. THE SNMP MANGEMENT FRAMEWORK The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in Lutz, Bergman, Wagner [Page 7] INTERNET-DRAFT Scanner MIB May 6, 2000 SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. 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 3.1 Overview of the Scanner Model The model has three basic parts: (1) the flow of Job Control data to Lutz, Bergman, Wagner [Page 8] INTERNET-DRAFT Scanner MIB May 6, 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. 3.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 9] INTERNET-DRAFT Scanner MIB May 6, 2000 3.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. 3.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 10] INTERNET-DRAFT Scanner MIB May 6, 2000 data file. 3.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). 3.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 11] INTERNET-DRAFT Scanner MIB May 6, 2000 (stopping the flow of scan data). 3.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. 3.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. 3.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 12] INTERNET-DRAFT Scanner MIB May 6, 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. 3.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). 3.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 "type n enumeration", where n can be 1, 2 or 3 can be found in the various tables. The definitions of these types of enumerations are: Type 1 enumeration All the values are defined in the Scanner MIB specification (RFC for the Scanner MIB). Additional enumerated values require a new RFC. Type 2 enumeration 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. Type 3 enumeration 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. 4. 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 13] INTERNET-DRAFT Scanner MIB May 6, 2000 5. NETWORK SCANNER MIB SPECIFICATION SCANNER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32 Integer32, enterprises FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF HrDeviceIndex FROM HOST-RESOURCES-MIB PrtMediaUnitTC, PrtCapacityUnitTC, PrtSubUnitStatusTC, PrtChannelTypeTC, PrtChannelState FROM PRINTER-MIB MfpColorSpaceTypeTC, MfpImageFormatTC, MfpChannelModeTC FROM MFP-MIB; scannerMIB MODULE-IDENTITY LAST-UPDATED "0105060000Z" ORGANIZATION "MFPA Scanner MIB Working Group" CONTACT-INFO "Raymond Lutz Postal: Multifunction Products 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." ::= { mfpMibs 2 } mfpa OBJECT IDENTIFIER ::= { enterprises 5335 } mfpMibs OBJECT IDENTIFIER ::= { mfpa 1 } -- Textual conventions for this MIB module -- -- -- Control Language Group textual-conventions -- ScnCntrlLangFamilyTC ::= TEXTUAL-CONVENTION -- This value is a type 2 enumeration STATUS current DESCRIPTION "Defines the control languages applicable to scanners." SYNTAX INTEGER { Lutz, Bergman, Wagner [Page 14] INTERNET-DRAFT Scanner MIB May 6, 2000 other(1), unknown(2), scsi(3), twain(4), isis(5), -- AIIM Std MS-61 hpscl(6) } -- Alert Group Textual Conventions ScnAlertGroupTC ::= TEXTUAL-CONVENTION -- This value is a type 1 enumeration for values in the range -- 201 to 229. STATUS current DESCRIPTION "The type of sub-unit within the scanner model related to this alert. Where possible, these enumerations match the sub-identifier that identifies the relevant scanner MIB table." SYNTAX INTEGER { generalScanner(201), scannerODH (202), scannerImageSensor(203), scannerColorSpace(204), scannerChannel(205), scannerControlLanguage(206), scannerDataFormat(207) } -- Scanner MIB Objects scanMIBObjects OBJECT IDENTIFIER ::= { scannerMIB 1 } -- 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 ::= { scanMIBObjects 201 } scnGeneralTable OBJECT-TYPE SYNTAX SEQUENCE OF ScnGeneralEntry 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 Lutz, Bergman, Wagner [Page 15] INTERNET-DRAFT Scanner MIB May 6, 2000 STATUS current DESCRIPTION "Entries define device default settings and device status." INDEX { hrDeviceIndex } ::= { scnGeneralTable 1 } ScnGeneralEntry ::= SEQUENCE { -- Note that not all of the objects in this sequence are in the -- general scanner group. scnODHDefaultIndex Integer32, scnSensorDefaultIndex Integer32, scnColorSpaceDefaultIndex Integer32, scnImageFormatDefaultIndex Integer32, scnGeneralStatus INTEGER } 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 } scnImageFormatDefaultIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current Lutz, Bergman, Wagner [Page 16] INTERNET-DRAFT Scanner MIB May 6, 2000 DESCRIPTION "The value of scnImageFormatIndex corresponding to the default image format configured for the scanner." ::= { scnGeneralEntry 4 } scnGeneralStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), idle(3), pending(4), scanning(5), busy(6), fault(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of this scanner device." ::= { scnGeneralEntry 5 } -- 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 ::= { scanMIBObjects 202 } 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 Lutz, Bergman, Wagner [Page 17] INTERNET-DRAFT Scanner MIB May 6, 2000 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, scnODHIndex } ::= { scnODHTable 1 } ScnODHEntry ::= SEQUENCE { scnODHIndex Integer32, -- 1 scnODHType INTEGER, -- 2 scnODHDimUnit PrtMediaUnitTC, -- 3 scnODHMaxDimFeedDir Integer32, -- 4 scnODHMaxDimXFeedDir 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 scnODHDocumentScanOrder 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 normally 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) Lutz, Bergman, Wagner [Page 18] INTERNET-DRAFT Scanner MIB May 6, 2000 } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of technology employed by the ODH sub-unit." ::= { scnODHEntry 2 } scnODHDimUnit OBJECT-TYPE 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." Lutz, Bergman, Wagner [Page 19] INTERNET-DRAFT Scanner MIB May 6, 2000 ::= { scnODHEntry 5 } scnODHMinDimFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current 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." ::= { scnODHEntry 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." ::= { scnODHEntry 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 20] INTERNET-DRAFT Scanner MIB May 6, 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 21] INTERNET-DRAFT Scanner MIB May 6, 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 Lutz, Bergman, Wagner [Page 22] INTERNET-DRAFT Scanner MIB May 6, 2000 DESCRIPTION "The maximum speed, in media sides per minute, that this ODH can feed input media to the sensor, scan, and then deposit the original in the output bin. A value of (-1) implies 'other' and specifically indicates that this is a manual ODH device. A value of (-2) indicates 'unknown'." ::= { scnODHEntry 13 } scnODHMaxMediaWeight OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum weight of the medium that can be handled by 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 15 } scnODHDocumentScanOrder OBJECT-TYPE -- This value is a type 2 enumeration SYNTAX INTEGER { other(1), unknown(2), firstToLast(3), lastToFirst(4) } MAX-ACCESS read-only Lutz, Bergman, Wagner [Page 23] INTERNET-DRAFT Scanner MIB May 6, 2000 STATUS current 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 (0..32767) 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 mfpGeneralCurrentLocalization." ::= { scnODHEntry 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 ::= { scanMIBObjects 203 } Lutz, Bergman, Wagner [Page 24] INTERNET-DRAFT Scanner MIB May 6, 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 scnSensorXMaxSize Integer32, -- 17 scnSensorYMaxSize Integer32 -- 18 } scnSensorIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current Lutz, Bergman, Wagner [Page 25] INTERNET-DRAFT Scanner MIB May 6, 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 26] INTERNET-DRAFT Scanner MIB May 6, 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 related to this sensor subunit." ::= { 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." Lutz, Bergman, Wagner [Page 27] INTERNET-DRAFT Scanner MIB May 6, 2000 ::= { scnSensorEntry 9 } 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 } -- Image Sensor Dimensions -- | -- V -- +====================================+ ================= -- | original image | Y offset ^ -- | +============================+ = |========= | -- | | / / / / / / / | | ^ | -- | | / / / / / / / | | | leading -- | |/ / / / / / / | | | edge -- | | / / / / / / /| | | -- | | / / / / / / / | | | | -- | | / / scanned image / / | | | direction -- | |/ / / / / / / | | | of scan -- | | / / / / / / /| | | | -- | | / / / / / / / | | | | -- | | / / / / / / / | | | V -- | |/ / / / / / / | | Y size -- | | / / / / / / /| | | -- | | / / / / / / / | | | -- | | / / / / / / / | | | -- | |/ / / / / / / | | | -- | | / / / / / / /| | V -- | +============================+ = |========= -- | | | | -- +================================+ -- | |<========= X size =========>| -- =>| |<= X offset -- |<====== X reference edge -- Lutz, Bergman, Wagner [Page 28] INTERNET-DRAFT Scanner MIB May 6, 2000 scnSensorXOffset OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The offset, in units identified by ScnSensorResolutionUnit, from the X reference edge of the original document to the output scanned image. The X reference edge is 270 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 ScnSensorResolutionUnit, 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 } scnSensorOutputResolFeedDir OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of addressable output image positions in the feed direction per 10000 units of measure specified by ScnSensorResolutionUnit. 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 maximum number of addressable output image positions in the cross feed direction in 10000 units of measure specified by ScnSensorResolutionUnit. A value of (-1) implies 'other' or 'infinite' while a value of (-2) implies 'unknown'." ::= { scnSensorEntry 14 } scnSensorOpticalBitsPerPixel OBJECT-TYPE SYNTAX Integer32 Lutz, Bergman, Wagner [Page 29] INTERNET-DRAFT Scanner MIB May 6, 2000 MAX-ACCESS read-only 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-only 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 } scnSensorXMaxSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum size of the scannned image measured from the scnSensorXOffset in units identified by scnSensorResolutionUnit." ::= { scnSensorEntry 17 } scnSensorYMaxSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum size of the scannned image measured from the scnSensorYOffset in units identified by ResolutionUnit." ::= { scnSensorEntry 18 } -- 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 Sensor. scnColorSpace OBJECT IDENTIFIER ::= { scanMIBObjects 204 } scnColorSpaceTable OBJECT-TYPE SYNTAX SEQUENCE OF ScnColorSpaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of color spaces supported by the Image Sensor." ::= { scnColorSpace 1 } Lutz, Bergman, Wagner [Page 30] INTERNET-DRAFT Scanner MIB May 6, 2000 scnColorSpaceEntry OBJECT-TYPE SYNTAX ScnColorSpaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each color space supported by the Image Sensor." INDEX { hrDeviceIndex, scnColorSpaceIndex } ::= { scnColorSpaceTable 1 } ScnColorSpaceEntry ::= SEQUENCE { scnColorSpaceIndex Integer32, scnColorSpaceType MfpColorSpaceTypeTC } scnColorSpaceIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used to identify this color space. Although these values may change due to a major reconfiguration of the device, values are normally expected to remain stable across successive image processor power cycles." ::= { scnColorSpaceEntry 1 } scnColorSpaceType OBJECT-TYPE SYNTAX MfpColorSpaceTypeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The Color Space types supported by the image sensor." ::= { 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). Lutz, Bergman, Wagner [Page 31] INTERNET-DRAFT Scanner MIB May 6, 2000 -- 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 -- 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 Lutz, Bergman, Wagner [Page 32] INTERNET-DRAFT Scanner MIB May 6, 2000 -- 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 -- 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 ::= { scanMIBObjects 205 } scnChannelTable OBJECT-TYPE SYNTAX SEQUENCE OF ScnChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of supported communication channels." ::= { scnChannel 1 } 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 PrtChannelTypeTC, scnChannelProtocolVersion OCTET STRING, scnChannelMode MfpChannelModeTC, scnChannelCurrentJobCntrlLangIndex Integer32, scnChannelState PrtChannelStateTC, scnChannelIfIndex Integer32, scnChannelStatus PrtSubUnitStatusTC, Lutz, Bergman, Wagner [Page 33] INTERNET-DRAFT Scanner MIB May 6, 2000 scnChannelInformation OCTET STRING } scnChannelIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used by the scanner to identify this data Communication Channel. Although these values may change because of a major reconfiguration of the device, values are normally expected to remain stable across successive scanner power cycles." ::= { scnChannelEntry 1 } scnChannelType OBJECT-TYPE SYNTAX PrtChannelTypeTC 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 MfpChannelModeTC MAX-ACCESS read-only STATUS current DESCRIPTION "The channel may be use for control or data delivery, or both. The channel may also be capable of initiating a connection with a server to obtain Control information or to deliver a data file (client mode operation), or it may accept a connection from a client that presents control information or recovers the data files (server mode operation). ::= { scnChannelEntry 4 } scnChannelCurrentJobCntrlLangIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current Lutz, Bergman, Wagner [Page 34] INTERNET-DRAFT Scanner MIB May 6, 2000 DESCRIPTION "The value of scnCntrlLangIndex 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 or the channel is not used for control communications." ::= { scnChannelEntry 5 } scnChannelState OBJECT-TYPE -- This value is a type 1 enumeration SYNTAX PrtChannelStateTC 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 6 } 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 7 } scnChannelStatus OBJECT-TYPE SYNTAX PrtSubUnitStatusTC MAX-ACCESS read-only STATUS current DESCRIPTION "The current status of the Communication Channel ." ::= { scnChannelEntry 8 } scnChannelInformation OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Auxiliary information to allow a scanning application to use this Communication Channel to setup the scanner or to recover image data. In the case of channels to server functions, scnChannelInformation will include the URL by which the server is addressedm inckuding user name, password Lutz, Bergman, Wagner [Page 35] INTERNET-DRAFT Scanner MIB May 6, 2000 and directory if appropriate. In the case of channels from client functions, scnChannelInformation will include the URI information for the default servers, if any. 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. 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. Lutz, Bergman, Wagner [Page 36] INTERNET-DRAFT Scanner MIB May 6, 2000 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 Mandatory' Multiplicity: 'Single' or 'Multiple' to indicate whether the entry may be present multiple times. Lutz, Bergman, Wagner [Page 37] INTERNET-DRAFT Scanner MIB May 6, 2000 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 9 } -- 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 ::= { scanMIBObjects 206 } -- The Control Language Table -- -- The scnCntrlLangTable is a table representing the -- Control Languages in the scanner. An entry shall be placed in the -- CntrlLang table for each Control Language on the scanner. scnCntrlLangTable OBJECT-TYPE SYNTAX SEQUENCE OF ScnCntrlLangEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table defining the supported scanner control languages." ::= { scnCntrlLang 1 } scnCntrlLangEntry OBJECT-TYPE SYNTAX ScnCntrlLangEntry 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, scnCntrlLangIndex } ::= { scnCntrlLangTable 1 } ScnCntrlLangEntry ::= SEQUENCE { scnCntrlLangIndex Integer32, Lutz, Bergman, Wagner [Page 38] INTERNET-DRAFT Scanner MIB May 6, 2000 scnCntrlLangFamily ScnCntrlLangFamilyTC, scnCntrlLangLevel OCTET STRING, scnCntrlLangVersion OCTET STRING, scnCntrlLangDescription 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 } scnCntrlLangFamily OBJECT-TYPE -- This value is a type 2 enumeration SYNTAX ScnCntrlLangFamilyTC MAX-ACCESS read-only STATUS current DESCRIPTION "The family name of a Scanner Control Language which the scanner can interpret and implement." ::= { scnCntrlLangEntry 2 } scnCntrlLangLevel 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 } 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 4 } scnCntrlLangDescription OBJECT-TYPE Lutz, Bergman, Wagner [Page 39] INTERNET-DRAFT Scanner MIB May 6, 2000 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 } -- The Image Format Group -- An image format defines the data encoding used in the scanned image -- output file. The Image Format table lists the image formats that are -- supported by the Scanner. scnImageFormat OBJECT IDENTIFIER ::= { scanMIBObjects 207 } scnImageFormatTable OBJECT-TYPE SYNTAX SEQUENCE OF ScnImageFormatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of image formats supported by the Scanner." ::= { scnImageFormat 1 } scnImageFormatEntry OBJECT-TYPE SYNTAX ScnImageFormatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries may exist in the table for each image format supported by the Scanner." INDEX { hrDeviceIndex, scnImageFormatIndex } ::= { scnImageFormatTable 1 } ScnImageFormatEntry ::= SEQUENCE { scnImageFormatIndex Integer32, scnImageFormatType MfpImageFormatTC } scnImageFormatIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value used to identify this image format. Although these values may change due to a major reconfiguration of Lutz, Bergman, Wagner [Page 40] INTERNET-DRAFT Scanner MIB May 6, 2000 the device, values are normally expected to remain stable across successive scanner power cycles." ::= { scnImageFormatEntry 1 } scnImageFormatType OBJECT-TYPE SYNTAX MfpImageFormatTC MAX-ACCESS read-only STATUS current DESCRIPTION "The image format types supported by the scanner." ::= { scnImageFormatEntry 2 } -- Notifications and Trapping (reserved for future use) scnMIBNotifications OBJECT IDENTIFIER ::= { scannerMIB 2 } -- Conformance Information scnMIBConformance OBJECT IDENTIFIER ::= { scannerMIB 3 } -- compliance statements scnMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for agents that implement the scanner MIB." MODULE -- this module MANDATORY-GROUPS { scnGeneralGroup, scnODHGroup, scnSensorGroup, scnColorSpaceGroup, scnChannelGroup, scnControlLanguageGroup, scnImageFormatGroup } OBJECT scnODHDefaultIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnSensorDefaultIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnColorSpaceDefaultIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnImageFormatDefaultIndex MIN-ACCESS read-only Lutz, Bergman, Wagner [Page 41] INTERNET-DRAFT Scanner MIB May 6, 2000 DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnODHMaxDimFeedDir MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnODHMaxDimXFeedDir MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnODHInputMaxCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnODHInputCurrentLevel MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnODHOutputMaxCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnODHOutputRemainingCapacity MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnODHMaxMediaWeight MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnSensorColorSpaceIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnSensorImageContrast MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnSensorImageBrightness MIN-ACCESS read-only Lutz, Bergman, Wagner [Page 42] INTERNET-DRAFT Scanner MIB May 6, 2000 DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnChannelCurrentJobCntrlLangIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnChannelState MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" OBJECT scnChannelIfIndex MIN-ACCESS read-only DESCRIPTION "It is conformant to implement this object as read-only" ::= { scnMIBConformance 1 } scnMIBGroups OBJECT IDENTIFIER ::= { scnMIBConformance 2 } scnGeneralGroup OBJECT-GROUP OBJECTS { scnODHDefaultIndex, scnSensorDefaultIndex, scnColorSpaceDefaultIndex, scnImageFormatDefaultIndex, scnGeneralStatus } STATUS current DESCRIPTION "The general scanner group." ::= { scnMIBGroups 1 } scnODHGroup OBJECT-GROUP OBJECTS { scnODHType, scnODHDimUnit, scnODHMaxDimFeedDir, scnODHMaxDimXFeedDir, scnODHMinDimFeedDir, scnODHMinDimXFeedDir, scnODHCapacityUnit, scnODHInputMaxCapacity, scnODHInputCurrentLevel, scnODHOutputMaxCapacity, scnODHOutputRemainingCapacity, scnODHMaxSpeed, scnODHMaxMediaWeight, scnODHSimplexDuplex, scnODHDocumentScanOrder, scnODHInterleaving, scnODHDescription } STATUS current DESCRIPTION "The ODH group." ::= { scnMIBGroups 2 } scnSensorGroup OBJECT-GROUP Lutz, Bergman, Wagner [Page 43] INTERNET-DRAFT Scanner MIB May 6, 2000 OBJECTS { scnSensorTech, scnSensorLifeCount, scnSensorPowerOnCount, scnSensorColorSpaceIndex, scnSensorResolutionUnit, scnSensorOpticalResolFeedDir, scnSensorOpticalResolXFeedDir, scnSensorImageContrast, scnSensorImageBrightness, scnSensorXOffset, scnSensorYOffset, scnSensorOutputResolFeedDir, scnSensorOutputResolXFeedDir, scnSensorOpticalBitsPerPixel, scnSensorOutputBitsPerPixel, scnSensorXMaxSize, scnSensorYMaxSize } STATUS current DESCRIPTION "The Scanner Sensor group." ::= { scnMIBGroups 3 } scnColorSpaceGroup OBJECT-GROUP OBJECTS { scnColorSpaceType } STATUS current DESCRIPTION "The color space group." ::= { scnMIBGroups 4 } scnChannelGroup OBJECT-GROUP OBJECTS { scnChannelType, scnChannelProtocolVersion, scnChannelMode, scnChannelCurrentJobCntrlLangIndex, scnChannelState, scnChannelIfIndex, scnChannelStatus, scnChannelInformation } STATUS current DESCRIPTION "The channel group." ::= { scnMIBGroups 5 } scnControlLanguageGroup OBJECT-GROUP OBJECTS { scnCntrlLangFamily, scnCntrlLangLevel, scnCntrlLangVersion, scnCntrlLangDescription } STATUS current DESCRIPTION "The JobControl group." ::= { scnMIBGroups 6 } scnImageFormatGroup OBJECT-GROUP OBJECTS { scnImageFormatType } STATUS current DESCRIPTION "The JobControl group." ::= { scnMIBGroups 7 } END 6. SECURITY CONSIDERATIONS Lutz, Bergman, Wagner [Page 44] INTERNET-DRAFT Scanner MIB May 6, 2000 There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. REFERENCES [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for Lutz, Bergman, Wagner [Page 45] INTERNET-DRAFT Scanner MIB May 6, 2000 SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [MFP-MIB] Lutz, R. "Multifunction Product MIB", Work in progress. 8. TERMINOLOGY 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. Lutz, Bergman, Wagner [Page 46] INTERNET-DRAFT Scanner MIB May 6, 2000 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. 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. Lutz, Bergman, Wagner [Page 47] INTERNET-DRAFT Scanner MIB May 6, 2000 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. 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 Lutz, Bergman, Wagner [Page 48] INTERNET-DRAFT Scanner MIB May 6, 2000 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. 9. FULL COPYRIGHT STATEMENT Copyright (C) 2000, The Multifunction Products Association (MFPA). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the MFPA or other organizations, except as needed for the purpose of developing related standards in which case the procedures for copyrights must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE MULTIFUNCTION PRODUCTS ASSOCIATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Lutz, Bergman, Wagner [Page 49] INTERNET-DRAFT Scanner MIB May 6, 2000 10. AUTHORS This document was created with significant contributions from the following individuals. Raymond Lutz Cognisys 1010 Old Chase Avenue Suite B El Cajon, CA 92020-7739 Phone: 619-447-3246 Fax: 619-447-6872 Email: raylutz@cognisys.com Ron Bergman (Editor) Hitachi Koki Imaging Solutions 1757 Tapo Canyon Road Simi Valley, CA 93063-3394 Phone: 805-578-4421 Fax: 805-578-4001 Email: rbergma@hitachi-hkis.com William Wagner NETsilicon, INC. 411 Waverley Oaks Road Waltham, MA 02154 Phone: 617-647-1234 Fax: 617-398-4888 Email: wwagner@digprod.com 11. CHANGE HISTORY Version 13.0 - Multiple changes to the MIB format to correct compiler problems. - Added "enterprises" to IMPORTS. - Removed "MfpChannelStateTC" from IMPORTS. - Changed "scanmib" to "scanMIBObjects". - "scanMIBObjects 203" was "scanmib 202". Version 12.0 - Section 3.4.1 "type n enumeration" was "enumeration (n)". (4 places) - Moved scannerMIB into { mibs 2 } in the OID tree. The MFP MIB will use { mibs 1 }. Lutz, Bergman, Wagner [Page 50] INTERNET-DRAFT Scanner MIB May 6, 2000 - In ScnCntrlLangFamilyTC added "hpscl(6)" and removed the issue "Are APIs appropriate here"; agreed to keep all enumerations for now. - Added ScnAlertGroupTC. - Renumbered all MIB Groups: (200 will not be used) The General Scanner Group "scanmib 201" was "scanmib 200" The ODH Group "scanmib 202" was "scanmib 201" The Image Sensor Group "scanmib 203" was "scanmib 202" The Color Space Group "scanmib 204" was "scanmib 203" The Data and Control Channel Group "scanmib 205" was "scanmib 204" The Control Language Group "scanmib 206" was "scanmib 205" - Added text to the DESCRIPTION clause in scnGeneralEntry. - Added scnImageFormatDefaultIndex to the General Scanner Group. - Added scnGeneralStatus to the General Scanner Group. - In scnODHMaxSpeed revised description and removed the issue "What is scans? Is a textual convention needed to define more values? Is other applicable? What about unknown(-2)?" New text: "The maximum speed, in media sides per minute, that this ODH can feed input media to the sensor, scan, and then deposit the original in the output bin. A value of (-1) implies 'other' and specifically indicates that this is a manual ODH device. A value of (-2) indicates 'unknown'." Old text: "The maximum scanning speed of this ODH expressed in scans. A value of (-1) implies 'other'." - Changed "scnInput" to "scnODH" 3 places in the ODH Group. - Changed "scnMediaPathEntry" to "scnODHEntry" in scnODHDescription. - In scnODHSimplexDuplex "scnODHEntry 15" was "scnODHEntry 9" - In scnODHDescription "mfpGeneralCurrentLocalization." Was "scnGeneralCurrentLocalization." Removed the issue "The localization is defined in the MFP MIB, change name." - In Image Sensor Dimensions figure "Y size" was "Y default offset" and "X size" was "X default offset". - In scnSensorOutputResolFeedDir and scnSensorOutputResolFeedDir "read-only" was "read-write" and "...maximum number..." was "...default number..." - In scnSensorOpticalBitsPerPixel and scnSensorOutputBitsPerPixel "read-only" was "read-write". - "scnSensorXMaxSize" was "scnSensorXDefaultSize" - "scnSensorYMaxSize" was "scnSensorYDefaultSize" - In "scnSensorXMaxSize" and "scnSensorYMaxSize" "read-only" was "read- write"; "...maximum size of the scanned image measured..." was "...extent of the active data..."; removed the issue " Do the above default size objects properly represent what is desired for the size demensions? Would scnSensorXSize be a more appropriate name?" - Added scnColorSpaceEntry and corrected the scnColorSpaceTable object. - Added text to the DESCRIPTION clause in scnChannelTable. - Removed the scnChannelOutputFormat object. All subsequent object entries have been renumbered. - Added text to the DESCRIPTION clause in scnCntrlLangTable. - Added Image Format Group (scanmib 207). Lutz, Bergman, Wagner [Page 51] INTERNET-DRAFT Scanner MIB May 6, 2000 - Updated the conformance section. - Resolved numerous compile errors. Version 11.0 - In Module Identity "Multifunction Products Association" was "Multifunction Peripheral Association" - Removed ScnColorSpaceTypeTC, added an import for and replaced references with MfpColorSpaceTypeTC. - Removed ScnChannelModeTC, added an import for and replaced references with MfpChannelModeTC. - Removed ScnChannelStateTC, added an import for and replaced references with MfpChannelStateTC. - Removed ScnChannelTypeTC, added an import for and replaced references with PrtChannelTypeTC. - Removed ScnChannelOutputFormatTC, added an import for and replaced references with MfpImageFormatTC. - Added "isis(5) -- AIIM Std MS-61" to ScnCntrlLangFamilyTC. - In scnODHEntry: scnOdhIndex was scnInputIndex. - In scnODHIndex: "...values are normally expected..." was "...values are expected..." - In scnODHMaxSpeed: Added an issue with 4 questions. - In scnODHMaxMediaWeight: "The maximum weight of the medium that can be handled by this input sub-unit in grams per meter squared." was "The max weight of the medium associated with this input sub-unit in grams / per meter squared." - In scnODHDescription: Added an issue. - In scnSensorResolutionUnit: "The unit of measure of distances related to this sensor subunit." was "The unit of measure of distances." - In scnSensorXOffset, scnSensorYOffset, scnSensorOutoutResolFeedDir, scnSensorOutoutResolXFeedDir: Changed "ResolutionUnit" to "scnSensorResolutionUnit". - In Color Space Group: "Image Sensor" was "image processor Image Processor". - In scnColorSpaceTable: "Entries may exist in the table for each color space supported by the Image Sensor." was "Entries may exist in the table for each device index whose device type is 'image processor'." - In scnColorSpaceIndex: "A unique value used to identify..." was "A unique value used by the image processor to identify..." Also "...values are normally expected..." was "...values are expected..." - In scnColorSpaceType: "image sensor" was "image processor" - Changed "scnChannelCurrentJobCntlLangIndex" to "scnChannelCurrentJobCntrlLangIndex" - In scnChannelIndex: "Although these values may change because..." was "Although these values may because..." Also "...values are normally expected..." was "...values are expected..." - In scnChannelMode "The channel may be use for control or data delivery, or both. The channel may also be capable of initiating a connection with a server to obtain Control information or to deliver a data file (client mode operation), or it may accept a connection from a client that presents control information or recovers the data files (server mode operation)." was "The channel can be for control or data Lutz, Bergman, Wagner [Page 52] INTERNET-DRAFT Scanner MIB May 6, 2000 delivery, or both. The channel can initiate a 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." - In scnChannelCurrentJobCntrlLangIndex "...or the channel is not used for control communications." was "[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" - There were two objects called "scnCntrlLangVersion". The second was deleted and the Description section from the second was moved into the first. Version 10.0: - Changed "Internet Society" to "Multifunction Products Associate" on copyright notice on the cover page and in section 9. Section 9 modified to remove "defined in the Internet Standards process". - Modified figure 1a so that the scanner and colocated workstation appears as a single unit to the walk-up user. - Removed "chAppleTalkPAP(7)", "chPOP3(xx)", and "chIMAP(xx)" from ScnChannelTypeTC. - Added a reference to the leading edge in the "scan offset" figure in the Image Sensor group. - Changed 180 to 270 in "scnSensorXOffset. - In "scnSensorOutputResolFeedDir" and "scnSensorOutputResolXFeedDir", changed "read-only" to "read-write" and "The number of..." to " The default number of..." - Moved enums in scnColorSpaceType to ScnColorSpaceTypeTC. Change "ColorSpacesRGB(4)" to "ColorSpaceSRGB(4)". - Changed "scnChannel1" to "scnChannel 1". - Changed "scnChannelOutputFormatTC" to "ScnChannelOutputFormatTC". - In "scnChannelOutputFormat", changed "The value of scnChannelOutputFormatT code corresponding to..." to "Defines the..." - In "scnCntrlLangLangFamily", changed "ScnCntrlLangLangFamilyTC" to "ScnCntrlLangFamilyTC". - In ScnChannelEntry, changed "ScnSubUnitStatusTC" to "PrtSubUnitStatusTC" and added "PrtSubUnitStatusTC" to the IMPORTS. - Moved "imgSizeXDefault" and "imgSizeYDefault" to the Image Sensor Group and renamed to "scnSensorXDefaultSize" and "scnSensorYDefaultSize". Modified description and changed the scan offsets figure to show these dimensions. Renamed the figure to "Image Sensor Dimensions". Version 9.0: - Added "Table of Contents" - Added "1.1 Terminology for Conformance" - Added "2. THE SNMP MANAGEMENT FRAMEWORK" - Added a "Notifications and Trapping" subtree for possible future use. - Updated the Conformance Information section. - Added "6. SECURITY CONSIDERATIONS" - Added "7. REFERENCES" Lutz, Bergman, Wagner [Page 53] INTERNET-DRAFT Scanner MIB May 6, 2000 - Changed "Appendix A _ Glossary of Terms" to "8. TERMINOLOGY" - Added "9. FULL COPYRIGHT STATEMENT" - Added "10. AUTHORS" - Added proper names to enums in ScnChannelModeTC and ScnChannelStateTC. - Added enums 13-15, 19, 27, 34, 35, 37, 38, 41, 42, chSMTP, chPOP3 and chIMAP to ScnChannelTypeTC. - Revised first paragraph of scnChannelInformation description. - In IMPORTS section, removed experimental, Counter32, TimeTicks, NOTIFICATION-TYPES, OBJECT-IDENTITY, CodedCharSet, Boolean, and Kbytes. - Revised OBJECT tree and modified all group OIDs. - Changed "LangLang" to "Lang" in the Control Language Group. 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. - 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__ Lutz, Bergman, Wagner [Page 54] INTERNET-DRAFT Scanner MIB May 6, 2000 - 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_. - 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. Lutz, Bergman, Wagner [Page 55] INTERNET-DRAFT Scanner MIB May 6, 2000 - 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: - 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. Lutz, Bergman, Wagner [Page 56] INTERNET-DRAFT Scanner MIB May 6, 2000 - 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. 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 57]