Subject: PMP> Restructured Port MIB (18 July 2005)

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 18 Jul 2005 20:23:38 -0700

Hi folks,                                          Monday (18 July 2005)

I've just posted an ASN.1-only release of a revised Printer Port Monitor
MIB on the PWG FTP server at:

    ftp://ftp.pwg.org/pub/pwg/pmp/wd/lcrc-pmpportmib10-20050718.mib

Quick agreement on the new MIB structure is needed for the Microsoft and
Apple teams to proceed with their development!

Please see the discussion below on the use of the terms 'input port'
and 'output port' in the PPM MIB context.  Also see change log.

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: [email-masked]
------------------------------------------------------------------------

Input Ports versus Output Ports
-------------------------------

[Refer to the section 'Use Models of PPM MIB' in the current spec]

In all three use models, each ppmPrinterTable entry represents a Print
Service offered _by_ the given network system, and each subordinate
ppmPortTable entry advertises an _input_ path to this Print Service
(for pass-through or local processing).

In both the Network Spooler and External Network Adapter use models,
each ppmPortTable entry advertises an _input_ path to a Print Service
(for pass-through to a downstream Print Device - see the Job attribute
'output-device-assigned' in IPP/1.1, RFC 2911).

In the Network Printer use model, exactly one ppmPrinterTable entry
advertises a Print Service offered _by_ the Network Printer and each
subordinate ppmPortTable entry advertises an _input_ path to that Print
Service (for local processing).

An External Network Adapter does NOT advertise the _output_ paths to its
locally attached printers (serial, USB, etc.) as they are of no interest
to the Client application.

------------------------------------------------------------------------

[Change Log]

18 July 2005 - Prototype Interoperability Test comments

* added 'ppmGeneralNumberOfPrinters' (for 'ppmPrinterTable' below);

* moved 'ppmGeneralPreferredPortIndex' to 'ppmPrinterTable';

* added 'ppmPrinterTable' (to disambiguate the use models for Network
  Spoolers and External Network Adapters) with selected objects moved
  from the former 'ppmPortTable':
  
  ppmPrinterIndex                   - new
  ppmPrinterEnabled                 - new (but like ppmPortEnabled)
  ppmPrinterName                    - new (but like ppmPortName)
  ppmPrinterIEEE1284DeviceId        <-- ppmPortIEEE1284DeviceId
  ppmPrinterNumberOfPorts           - new (port count on THIS printer)
  ppmPrinterPreferredPortIndex      <-- ppmGeneralPreferredPortIndex
  ppmPrinterHrDeviceIndex           <-- ppmPortHrDeviceIndex
  ppmPrinterSnmpCommunityName       <-- ppmPortSnmpCommunityName
  ppmPrinterSnmpQueryEnabled        <-- ppmPortSnmpStatusQueryEnabled

* changed SYNTAX of 'ppmPrinterIEEE1284DeviceID' to 'OCTET STRING',
  increased max length to 1023 octets, and required MANUFACTURER and
  MODEL in first 255 octets, per recent discussion on mailing list;

* revised 'ppmPortTable' and 'ppmPortEntry' to clarify that they model
  only _input_ printer ports (and NOT the outgoing paths to downstream
  print devices).

* revised description of 'ppmPortProtocolTargetPort' to state that it
  SHOULD NOT conflict with the value of 'ppmPortProtocolType', per
  discussion during Prototype Interoperability Test;

* deleted 'ppmPortDescription', because it's redundant with the contents
  of the objects 'ppmPrinterIEEE1284DeviceId', 'ppmPortProtocolType',
  'ppmPortProtocolTargetPort', 'ppmPortServiceNameOrURI' (queue), and
  'ppmPortChannelIndex' (which leads via 'prtChannelIfIndex' in IETF
  Printer MIB to the hardware interface in 'ifTable' in IETF MIB-II).

------------------------------------------------------------------------

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 19 Jul 2005 15:08:13 +0200

Only did a very very quick scan.

Comments.

- ppmPortProtocolTargetPort OBJECT-TYPE
    SYNTAX      Integer32 (0..65535)
  I propose that you use InetPortNumber TC from RFC4001

- ppmPortProtocolType OBJECT-TYPE
    SYNTAX      Integer32 (0..2147483647)

  WHy not use TC PrtChannelTypeTC as the SYNTAX?
  I do see that you want to use zero (meaning not supported).
  But maybe better is to use none(1) in that case, or maybe
  adding an enumeration to the TC of notSupported(xx) ??
  It is now an IANA-maintained TC, so it should not be that
  difficult to get a label added.

- ppmPortPrtChannelIndex has a reference to RFC1213, while I
  think I would reather reference RFC2863 (the current IF-MIB)

Bert

---

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 19 Jul 2005 09:46:27 -0700

Hi Bert,

Thanks for your quick feedback.  My replies inline below.

Cheers,
- Ira

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, July 19, 2005 9:08 AM
> To: McDonald, Ira; [email-masked]'
> Subject: RE: PMP> Restructured Port MIB (18 July 2005)
> 
> 

Won't work, because this port is not limited to Internet Suite
protocols.  The 'service:' URI in ppmPortServiceNameOrURI may
also be for non-Internet suites (AppleTalk, NetWare, etc.).

I'll correct the DESCRIPTION in the MIB and make clear that
(as with the Printer MIB) ports/channels may be from multiple
protocol suites.

>   difficult to get a label added.

Won't work.  PrtChannelTypeTC currently only defines 'other(1)'
and (foolishly) does NOT define 'unknown(2)' (unlike every other
textual convention in the Printer MIB).  Because the Printer MIB
v2 still doesn't define DEFVAL clauses for most objects, this
oversight has not surfaced before.  We could register 'unknown(2)' 
with IANA, but _not_ fast enough (because this MIB's going into OS 
and printer vendor products right now).

>   think I would reather reference RFC2863 (the current IF-MIB)

Agreed.  My mistake from the old Printer MIB (RFC 1759).

I'll correct the references in the MIB.
- Ira

---

From: "Bergman, Ron" <[email-masked]>
Date: Tue, 19 Jul 2005 16:39:50 -0700

Ira,

I am not sure what value ppmPrinterEnabled adds to the MIB.  This appears to be analogous to
On Line/Off Line.  If I want to create a driver for the printer I don't care what the current
state is.  That information is only necessary when I am ready to print and then this MIB is 
not used.

I believe that Bert has a valid point in using ppmPortProtocolType.  It is not a major effort
to add unknown(2) to the IANA registrations.

Otherwise, the changes are inline with our discussions following the test.

	Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of McDonald,
Ira
Sent: Tuesday, July 19, 2005 9:46 AM
To: 'Wijnen, Bert (Bert)'; McDonald, Ira; [email-masked]'
Subject: RE: PMP> Restructured Port MIB (18 July 2005)

Hi Bert,

Cheers,
- Ira

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 20 Jul 2005 08:37:55 -0700

Hi Ron,

Based on previous IPP experience, it will take MONTHS to add one
new enum to the PrtChannelTypeTC with IANA - that would stop the
Port Mon MIB dead in its tracks until it was accepted by IANA.

About ppmPrinterEnabled - same rationale as ppmPortEnabled - keeps
the number of Printer entries STATIC in an implementation - lets
the user see that the one Printer (i.e., hardward output interface)
on an External Network Adapter should presently be ignored. 

Remember that the Port Mon MIB MUST NOT depend on either Host
Resources or Printer MIB, by common concensus - it may only
AUGMENT them, if they are present.

Cheers,
- Ira

> From: Bergman, Ron [mailto:[email-masked]]
> Sent: Tuesday, July 19, 2005 7:40 PM
> To: McDonald, Ira; Wijnen, Bert (Bert); [email-masked]
> I believe that Bert has a valid point in using 
> ppmPortProtocolType.  It is not a major effort

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 20 Jul 2005 20:40:10 +0200

Given that most other TCs in the same IANA maintained MIB module
in fact DO have a enum of: unknown(2)
I can even see it would be very easy to make the case that it was
an error/omission that the PrtChannelTypeTC does not have it.

I do not see why this would need to take more than a few weeks 
in fact. The addition (as far as I can tell) can be made by 
expert review (to be designated by APPS ADs).

Do you want to give it a try?

Bert

> From: McDonald, Ira [mailto:[email-masked]]
> Sent: Wednesday, July 20, 2005 17:38
> To: 'Bergman, Ron'; McDonald, Ira; Wijnen, Bert (Bert); [email-masked]

---

From: "Bergman, Ron" <[email-masked]>
Date: Thu, 21 Jul 2005 17:23:34 -0700

Ira,

Base on my experience with ENAs, they do not provide a feature to
disable an output port unless the printer is removed.  Normally, 
this is to replace a worn-out unit or upgrade a printer.
In this case the old printer is gone forever.  So how does your 
"STATIC entries" handle this situation?

	Ron

-----Original Message-----
From: McDonald, Ira [mailto:[email-masked]]
Sent: Wednesday, July 20, 2005 8:38 AM
To: Bergman, Ron; McDonald, Ira; Wijnen, Bert (Bert); [email-masked]
Subject: RE: PMP> Restructured Port MIB (18 July 2005)

Hi Ron,

Cheers,
- Ira

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 22 Jul 2005 09:13:35 -0700

Hi Ron,

If the Printer entry is deleted when an ENA interface
is disconnected, then all the subordinate Port entries
MUST be deleted too (because they are indexed by the
object ppmPrinterIndex).  This is ugly if the local
printer is promptly plugged _back_ into the interface.

If the Printer entry is left in place but _not_ clearly
marked 'disabled', then ppmPrinterIEEE1284DeviceId, 
ppmPrinterHrDeviceIndex and all the other Printer 
columnar objects must be reset (to default values).

That's why the ppmPrinterEnabled object should be kept.

The WG concensus was strong that ppmPortEnabled was 
required to keep the port list static (fixed number 
of ports for an interface).  Therefore, I added the
ppmPrinterEnabled object.

If others want ppmPrinterEnabled removed, would they 
please speak up soon?

Cheers,
- Ira

PS - Remember that this MIB is supposed to work for
Network Spoolers too, where the concept of 'the printer
is removed' is fuzzy.  The 'printer' is just some
configured downstream network printer that may well
be administratively disabled _without_ removing the 
configuration at the Network Spooler.

> Sent: Thursday, July 21, 2005 8:24 PM

---

From: [email-masked]
Date: Fri, 22 Jul 2005 13:27:51 -0400

I would think that the usefullness of the ppmPrinterEnabled for an
ENA would only be for the "transcient" case of the plugging/unplugging
of the related printer.  However at some point (in the case that the 
printer
stays unplugged "permanently") the printer entry and associated protocol
tables would be removed such that the the MIB could grow and shrink
over time.....

For example, an ENA with a USB host interface that supports up to
128 attached printers, In my opinion, shouldn't need to have 128 printer 
entries
in the MIB tables from first power on......only the entries that have 
detected (valid 1284ID)
printers etc. attached.....otherwise you'd end up in most cases with 127 
default printer entries
with associated port tables that don't actually go anywhere. 

Of course this behaviour is different from the current TCPMON.ini file
which has static entries.......

I think maybe the clients should give guidance on how they want it to 
work.

Jerry Thrasher

"McDonald, Ira" <[email-masked]>
Sent by: [email-masked]
07/22/2005 12:13 PM

        To:     "'Bergman, Ron'" <[email-masked]>, "McDonald, Ira" 
<[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, 
[email-masked]
        cc: 
        Subject:        RE: PMP> Restructured Port MIB (18 July 2005)

Hi Ron,

Cheers,
- Ira

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 22 Jul 2005 10:37:10 -0700

Hi Jerry,
 
I agree that feedback from the clients (Microsoft and Apple) on how they'd
like this to work would be helpful.
 
Remember, that a value of 'ppmPrinterIndex' must NEVER be reassigned
to a different instance of a Printer at a later date.  While the MIB may
grow and shrink, the base 'ppmPrinterIndex' should be immutably
associated with exactly one specific instance of a Printer.  This is both
correct MIB practice and required by the object definition in the current
MIB draft.
 
Cheers,
- Ira

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 22, 2005 1:28 PM
To: McDonald, Ira
Cc: [email-masked]; [email-masked]
Subject: RE: PMP> Restructured Port MIB (18 July 2005)

I would think that the usefullness of the ppmPrinterEnabled for an 
ENA would only be for the "transcient" case of the plugging/unplugging 
of the related printer.  However at some point (in the case that the printer

I think maybe the clients should give guidance on how they want it to work. 

Jerry Thrasher 

07/22/2005 12:13 PM 

        To:        "'Bergman, Ron'" <[email-masked]>, "McDonald,
Ira" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>,
[email-masked] 
        cc:         
        Subject:        RE: PMP> Restructured Port MIB (18 July 2005)

Hi Ron,

Cheers,
- Ira