Hi Tom,
Of course Equitrac's input merits consideration!!!
Unfortunately I guess you missed the previous drafts
and discussion since last November. Microsoft has
asked to bring this MIB to content closure within
the next month at the latest, in order to move it
into their Longhorn printing planning cycle.
By PWG Process v2.0 rules, we must bring a 'last call'
to closure during a PWG face-to-face (next one in April).
Therefore, we have a pretty hard target of entering
'last call' no later than 1 March 2005 (to allow an
extra long final review period for implementors).
If more info is needed for LPR in 'prtChannelInformation',
then the appropriate fix is to update 'PrtChannelTypeTC'
in the IANA registry with the new keywords and info,
not to expand the 'competition' between the Port MIB and
Printer MIB v2.
Updating the IANA registry is simple and straightforward
(the PWG is the responsible authority for revisions).
I personally regret the LPR-specific info in the Port MIB,
but it was proposed originally and requested by Microsoft
in their prototype last November.
I personally consider that adding more protocol-specific
info to the Port MIB is a very bad idea - it will lead
to inconsistent info with Printer MIB v2 - and it will
lead to confusion in the printing industry, by implying
that it is less important for vendors to correctly and
promply upgrade to Printer MIB v2 (which has other quite
important objects added).
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: Haapanen, Tom [mailto:tomh@waterloo.equitrac.com]
Sent: Tuesday, January 18, 2005 12:29 PM
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 - 12:47:20 EST