PMP Mail Archive: RE: PMP> Draft MIB comments

RE: PMP> Draft MIB comments

From: Bergman, Ron (Ron.Bergman@rpsa.ricoh.com)
Date: Tue Jan 18 2005 - 13:00:02 EST

  • Next message: Haapanen, Tom: "RE: PMP> Draft MIB comments"

    Ira,

    I don't see this as a major change. We always stated that
    it should be useable with any printing protocol. Also these
    changes provide information that is not in the Printer MIB.

    I would like to hear from Mike and/or Ivan before we reach
    any final conclusions.

            Ron

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Tuesday, January 18, 2005 9:51 AM
    To: Bergman, Ron; Haapanen, Tom; McDonald, Ira; pmp@pwg.org
    Cc: mfenelon@microsoft.com; ivanp@microsoft.com
    Subject: RE: PMP> Draft MIB comments

    Hi Ron,

    Please see my simultaneous reply to Tom. If we go on
    adding protocol-specific objects to the Port MIB, it
    will 'compete' with Printer MIB v2 in a very bad way.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    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: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]
    Sent: Tuesday, January 18, 2005 12:48 PM
    To: Haapanen, Tom; McDonald, Ira; pmp@pwg.org
    Cc: mfenelon@microsoft.com; ivanp@microsoft.com
    Subject: RE: PMP> Draft MIB comments

    Ira,

    This request can be easily accomplished by two small changes to the MIB.

    1) Change the name of ppmPortLprQueueName and then allow it to represent
       the IPP URL or a service name such as the LPR queue name. (propose
       ppmPortServiceName)

    2) Add a new object that indicates if there are no restrictions as to the
       source ports used for LPR. (propose ppmPortLprSourcePorts)

    Since you have strongly stated in the past that this is not a Microsoft
    specific MIB, and now we have a non-Microsoft "customer" for the MIB, we
    should be somewhat receiptive to this request. I hope we can get a quick
    response from Mike and/or Ivan on this subject. Unless they have an
    objection, this should be an easy change and not impact our schedule.

            Ron

    -----Original Message-----
    From: Haapanen, Tom [mailto:tomh@waterloo.equitrac.com]
    Sent: Tuesday, January 18, 2005 9:29 AM
    To: 'McDonald, Ira'; pmp@pwg.org
    Cc: Bergman, Ron
    Subject: RE: PMP> Draft MIB comments

    Ira,

    In my reading of RFC 3805, there is no information in the channel group
    about LPR source ports or LPR queue behaviour. Or did I miss something?

    What is the deadline for the closure on the MIB? Today? This week? This
    month? Something else?

    We are very interested, as is Microsoft, in making better choices in
    connecting to devices. Admittedly, though, Equitrac does not have the clout
    or influence of Microsoft. But I would hope that our input would still
    merit some consideration.

    Tom

    -----Original Message-----
    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Tuesday, 18 January 2005 12:13
    To: 'Haapanen, Tom'; pmp@pwg.org
    Cc: 'Bergman, Ron'
    Subject: RE: PMP> Draft MIB comments

    Hi Tom,

    There's some confusion here.

    The authoritative details for IPP, AppleTalk, and many other print data
    channels are captured in the complementary Printer MIB v2 (RFC 3805) in the
    new 'prtChannelInformation' object.
    The details of what can be described for each protocol type are in the
    'PrtChannelTypeTC' textual convention in the IANA Printer MIB (first
    published also in RFC 3805).

    We should not duplicate information in the simple Port MIB that is already
    present in the main Printer MIB v2.

    While your questions are all valid, they have already been answered (in my
    opinion) in the 'prtChannelInformation'
    object. Note that the details there were largely supplied by the
    responsible vendors (Novell, etc.) or by an implementor with intimate
    experience with each particular print protocol.

    It is VERY important that we come to closure on the contents of this Port
    MIB in the immediate future, so that Microsoft can request vendors to do
    firmware upgrades to include this small MIB in their existing and new
    printers ASAP.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect) 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: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Haapanen, Tom
    Sent: Monday, January 17, 2005 9:24 PM
    To: pmp@pwg.org
    Cc: 'Bergman, Ron'
    Subject: RE: PMP> Draft MIB comments

    The SMB and AppleTalk names were admittedly thrown in just for good measure
    -- but I would definitely like to see the IPP URI in the MIB. Maybe the
    queue name object could be renamed, as you suggest?

    Other than IPP, the other port types we would expect to support with this
    would be NPA (IEEE 1284) and IPDS, but I'll need to verify with our
    engineering team whether we need any additional info for those port types.

    Yes, there are devices that do restrict source ports. Some colour
    controller manufacturers come to mind!

    For the Fiery example, there are hold, print and direct queues, with
    different defined behaviours. Specifically, documents sent to the hold
    queue will not print until explicitly released. The print queue spools
    first, then prints, while the direct queue prints immediately without
    intermediate spooling. (Our secure printing software can provide
    conceptually similar behaviour for specified print queues on a print
    server.)

    I would expect some production devices to have similar queue choices
    available -- Ron, is that true for the Ricoh production systems?

    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]
    Sent: Monday 17 January 2005 21:10
    To: Haapanen, Tom; pmp@pwg.org
    Subject: RE: PMP> Draft MIB comments

    Hi Tom,

    Good questions. See my responses in-line.

            Ron

    -----Original Message-----
    From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Haapanen, Tom
    Sent: Monday, January 17, 2005 5:39 PM
    To: pmp@pwg.org
    Subject: PMP> Draft MIB comments

    Everyone,

    Here is my initial set of comments on the draft Print Port Monitor MIB.
    This is based largely on our experience of developing port monitors (and
    equivalent modules on other platforms) to communicate with a myriad of
    devices.

    So, in no particular order ...

    - Shouldn't the ppmPortTable include a URI object for IPP printers?
    Otherwise there is no way to know how to connect to an IPP device. What
    about SMB share names or AppleTalk names?

    <Ron> The scope was limited to LPR and TCP Sockets since those were the
          protocols in Microsoft's request. Although, in our discussions it
          was agreed that it should be open to all protocols. IPP could be
          reported in the ppmPortProtocolType and the ppmPortProtocolPortNumber
          containing the port used. In discussions, Microsoft did not see a
          a need so it was not described as a possibility.

          The SMB and AppleTalk names are normally broadcast so I am not sure
          why they would be needed, especially since they are now being used
          less and less. Using the ppmPortLprQueueName (with a rename) would
          allow support of these protocols. If you feel strongly about these
          a simple modification and rewrite of the descriptions would provide
          the support.

    - For LPR devices, I would like to see an object that specifies whether the
    device accept source ports outside the RFC range. Most devices, but not
    all, do today, and this can really help throughput with small documents.

    <Ron> Are there printers that do not support any source port? If no,
          this would be a good additional MIB object.

    - What would be the expected behaviour if there are multiple ports of the
    same type? For example, Fiery controllers typically have three LPR queues
    -- would it not be beneficial to be able to publish all three, and to
    describe their behaviour?

    <Ron> There is no limit to the number of ports or queues that can be
          reported in the MIB. It is an SNMP table and supports large
          number of entries. I assume the Fiery controller LPR queues
          each have a unique name.

    Tom



    This archive was generated by hypermail 2b29 : Tue Jan 18 2005 - 13:01:55 EST