RE: WIMS> Counter MIB-Scanner Subunit [scanner technology]

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed May 09 2007 - 14:53:40 EDT

  • Next message: McDonald, Ira: "WIMS> FW: MFD> Proposal for specific Scanner types in Counter MIB"

    Hi,

    On further consideration, I now think:

    (1) We should add the specific Scanner technology types
        (because there is no other MIB source for them)

    (2) We should add 'icSubunitTechType' to 'icSubunitTable'
        to handle all other existing subunits (which maps to
        'prtMarkerMarkTech', 'prtInputType', etc.) as a safe,
        extensible solution that avoids duplicating IANA enums

    Comments?

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Chair - Linux Foundation Open Printing WG
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com

    -----Original Message-----
    From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of
    McDonald, Ira
    Sent: Thursday, May 03, 2007 5:57 PM
    To: wims@pwg.org
    Subject: WIMS> Counter MIB-Scanner Subunit [scanner technology]

    Hi,

    Walt Filbrich has made an excellent suggestion/request
    to distinguish scanner technology (just like we do for
    marker and finisher). The IPP PSX spec enhanced the
    generic subunit type 'finisher(30)' with a specific
    300-series (e.g., 'puncher(308)'). These were already
    added to the Imaging State and Counter MIB (aka Counter
    MIB v2).

    Below I propose adding a corresponding 500-series, so
    that we have the generic subunit type 'scanner(50)'
    and new specific values 'scannerADF(503)' and
    'scannerPlaten(504)' that would map algorithmically to a
    future PWG Scanner MIB with a 'scanDeviceScanTech' object,
    just like 'prtMarkerMarkTech' in Printer MIB (and leaving
    holes for 'other(1)' and 'unknown(2)').

    I also think we should do the equivalent enhancement for
    'marker(10') with a 1000-series, e.g., 'markerPen(1015)'.

    I do NOT think we should do this for input tray, output
    tray, channel, or media path specific types. They're
    too volatile or just not interesting enough to have
    (effectively) dual registries.

    Comments?

    Ira McDonald (Musician / Software Architect)
    Chair - Linux Foundation Open Printing WG
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com

    ---------- Forwarded message ----------
    From: Ira McDonald <blueroofmusic@gmail.com>
    Date: May 3, 2007 5:29 PM
    Subject: Re: Counter MIB-Scanner Subunit
    To: Walter Filbrich <w.filbrich@samsung.com>, Ira McDonald
    <blueroofmusic@gmail.com>

    Hi Walt,

    Well maybe. There's a single generic Scanner subunit that corresponds
    exactly to the generic Marker subunit. The PWG Abstract Imaging
    System Counter spec (PWG 5106.1) and the PWG Subunits schema
    (Candidate Standards approved as part of the WIMS/1.0 protocol)
    lock down the generic subunit types.

    In some (probably far) future PWG Scanner MIB (for the Scan Device),
    there might be an object, e.g., 'scanDeviceScanTech', corresponding
    to the Printer MIB's 'prtMarkerMarkTech' that would distinguish Platen
    versus ADF.

    In current Imaging State and Counter MIB (aka Counter MIB v2), what
    you could do is to have two rows of type 'scanner(50)' with icSubunitInfo
    describing ADF versus Platen.

    However, following the precedent for both generic 'finisher(30)' and
    specific 'stapler(302)', etc., we _could_ define a new '500' series of
    specific scan technologies (scannerADF, scannerPlaten, etc.)
    Actually, I like that idea.

    I'm forwarding this reply to my Sharp Labs email account so that
    I can put this solution up to the WIMS WG mailing list.

    Cheers,
    - Ira

    On 5/3/07, Walter Filbrich <w.filbrich@samsung.com> wrote:
    >
    > Hello Ira,
    >
    > Although we are not implementing "sub-units" in the prototype, I think we
    > should define two new subunits for the scanner, to enable reporting scans
    > from the ADF separately from the platen. Some existing MFD's report the
    > Platen scans and ADF scans separately via their internal Web pages or
    > embedded status pages. If we only have a single subunit for "scanner" then
    > the count associated with the scanner subunit will be the same as the count
    > reported for "Total Scans" for the device. Can we add two new subunit
    > enumerations for "platen" and "ADF" to the IcSubunitTypeTC in the Counter
    > MIB?
    >
    > /Walt
    >
    > Walter Filbrich
    > Principal Engineer
    > Advanced Printing Software Lab
    > Samsung Information Systems America
    > 3345 Michelson Drive, Suite 350
    > Irvine, CA 92612
    >
    > Tel: 949 797 8085
    > Fax: 949 797 8099
    > w.filbrich@samsung.com
    >
    > This message is intended only for the named recipient(s) above and may
    > contain confidential or privileged information or protected attorney work
    > product. If you are not the intended recipient, any review, dissemination,
    > distribution or copying is strictly prohibited. If you have received this
    > message in error, please immediately notify the sender and delete this
    > message and its attachments from your computer and dispose of all other
    > copies or printouts. Thank you.
    >
    >

    --
    Ira McDonald (Musician / Software Architect)
    Chair - Linux Foundation Open Printing WG
    Blue Roof Music / High North Inc
    PO Box 221  Grand Marais, MI  49839
    phone: +1-906-494-2434
    email: blueroofmusic@gmail.com
    

    -- Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: blueroofmusic@gmail.com

    No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.2/785 - Release Date: 5/2/2007 2:16 PM

    No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.6/794 - Release Date: 5/8/2007 2:23 PM



    This archive was generated by hypermail 2.1.4 : Wed May 09 2007 - 14:53:52 EDT