attachment-0001

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PostalCode"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="Street"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="address"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"/>  <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> Ira,<o:p></o:p> <o:p> </o:p> I am clear on the proposal now and I still don’t see the need to maintain the hole at this stage.<o:p></o:p> <o:p> </o:p> Can you clarify this for me…<o:p></o:p> <o:p> </o:p> If I have 2 attached printers each with the same 3 ports, they would be indexed by the Printer and then the Port:<o:p></o:p> .1.1<o:p></o:p> .1.2<o:p></o:p> .1.3<o:p></o:p> .2.1<o:p></o:p> .2.2<o:p></o:p> .2.3<o:p></o:p> <o:p> </o:p> (I don’t know if this is considered one table with 6 entries or 2 tables with 3 entries each.)<o:p></o:p> <o:p> </o:p> So I don’t understand the need for both<o:p></o:p> ppmGeneralNumberOfPorts<o:p></o:p> ppmPrinterNumberOfPorts<o:p></o:p> <o:p> </o:p> If I know the Printer index and number of printer ports, isn’t this enough?<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> <o:p> </o:p> Stuart<o:p></o:p> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> From: thrasher@lexmark.com [mailto:thrasher@lexmark.com] Sent: Thursday, July 28, 2005 8:24 AM To: Stuart Rowley Cc: pmp@pwg.org Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y 2005)<o:p></o:p> </div> <o:p> </o:p> Stuart, Sorry about the error in my request.  I was talking about ppmPrinterenabled, not Portenabled. Jerry <o:p></o:p> <table class=MsoNormalTable border=0 cellpadding=0 width="100%" style='width:100.0%'> <tr> <td valign=top style='padding:.75pt .75pt .75pt .75pt'> <o:p> </o:p> </td> <td valign=top style='padding:.75pt .75pt .75pt .75pt'> Stuart Rowley <Stuart.Rowley@ktd-kyocera.com> Sent by: pmp-owner@pwg.org <o:p></o:p> 07/28/2005 11:19 AM <o:p></o:p> </td> <td valign=top style='padding:.75pt .75pt .75pt .75pt'>                 To:        "'pmp@pwg.org'" <pmp@pwg.org>         cc:        "McDonald, Ira" <imcdonald@sharplabs.com>         Subject:        RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul         y 2005)<o:p></o:p> </td> </tr> </table> <tt>Hi Ira,</tt> <tt>I'm not clear on the proposal.</tt> <tt>Your email said, "Let's delete ppmPrinterEnabled,..."</tt> <tt>Then Jerry's reply said, "...where ppmPortEnabled "used" to be..."</tt> <tt>So is the proposal to keep ppmPrinterEnabled and remove ppmPortEnabled?</tt> <tt>I don't see the need to leave a hole for the removed object at this stage of</tt> <tt>development.</tt> <tt>Thanks,</tt> <tt>Stuart</tt> <tt>Stuart Rowley, Network Product Mgr.</tt> <tt>stuart.rowley@ktd-kyocera.com      925 849-3306     925 849-3399 (fax)</tt> <tt>Kyocera Technology Development Inc.</tt> <st1:Street w:st="on"><st1:address w:st="on"><tt>1855 Gateway Blvd. Suite 400</tt></st1:address></st1:Street> <st1:place w:st="on"><st1:City w:st="on"><tt>Concord</tt></st1:City><tt>, <st1:State w:st="on">CA</st1:State> <st1:PostalCode w:st="on">94520</st1:PostalCode></tt></st1:place> <tt>_____</tt> <tt>From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of McDonald,</tt> <tt>Ira</tt> <tt>Sent: Thursday, July 28, 2005 7:59 AM</tt> <tt>To: 'thrasher@lexmark.com'; McDonald, Ira</tt> <tt>Cc: 'pmp@pwg.org'</tt> <tt>Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y</tt> <tt>2005)</tt> <tt>Hi Jerry,</tt> <tt>There's no such thing as a reserved no-access object, but I'd be happy to</tt> <tt>leave</tt> <tt>the hole (so that the OIDs don't change for any other columnar objects).</tt> <tt>Would</tt> <tt>you prefer that?</tt> <tt>Note that ALL of the columnar objects were cleaned up and reordered (and</tt> <tt>renumbered) in this latest revision, so it would be hard for there to be too</tt> <tt>many</tt> <tt>implementations of the new OIDs already.</tt> <tt>Others - shall I leave the hole and leave the other new OID assignments</tt> <tt>stable?</tt> <tt>Cheers,</tt> <tt>- Ira</tt> <tt>Ira McDonald (Musician / Software Architect)</tt> <tt>Blue Roof Music / High North Inc</tt> <st1:address w:st="on"><st1:Street w:st="on"><tt>PO Box</tt></st1:Street><tt> 221</tt></st1:address><tt>  Grand <st1:place w:st="on"><st1:City w:st="on">Marais</st1:City>, <st1:State w:st="on">MI</st1:State>  <st1:PostalCode w:st="on">49839</st1:PostalCode></st1:place></tt> <tt>phone: +1-906-494-2434</tt> <tt>email: imcdonald@sharplabs.com</tt> <tt>-----Original Message-----</tt> <tt>From: thrasher@lexmark.com [mailto:thrasher@lexmark.com]</tt> <tt>Sent: Thursday, July 28, 2005 10:33 AM</tt> <tt>To: McDonald, Ira</tt> <tt>Subject: RE: PMP> [delete ppmPrinterEnabled] Restructured Port MIB (18 Jul y</tt> <tt>2005)</tt> <tt>Ira,</tt> <tt>Are you just planning on creating a reserved no-access object where</tt> <tt>ppmPortEnabled "used" to be, or are</tt> <tt>you going to delete the entry and shift everything else in the table up.??</tt> <tt>Jerry</tt> <tt>"McDonald, Ira" <imcdonald@sharplabs.com></tt> <tt>07/23/2005 01:56 PM</tt> <tt>To:        "McDonald, Ira" <imcdonald@sharplabs.com>,</tt> <tt>"'thrasher@lexmark.com'" <thrasher@lexmark.com></tt> <tt>cc:        "'pmp@pwg.org'" <pmp@pwg.org>,</tt> <tt>"'Ron.Bergman@rpsa.ricoh.com'" <Ron.Bergman@rpsa.ricoh.com></tt> <tt>Subject:        RE: PMP> [delete ppmPrinterEnabled] Restructured</tt> <tt>Port MIB (18 Jul        y 2005)</tt> <tt>Hi,</tt> <tt>Let's delete ppmPrinterEnabled, because the 'false' is redundant</tt> <tt>with ppmPortEnabled of 'false' for all supported ports.  And</tt> <tt>because otherwise, we must say "ignore ppmPortEnabled of 'true'</tt> <tt>for installation if ppmPrinterEnabled is 'false'".  Which leads</tt> <tt>me to agree that we should delete ppmPrinterEnabled.</tt> <tt>When a Printer is permanently removed from an ENA interface,</tt> <tt>the whole ppmPrinterTable row and all subordinate rows in</tt> <tt>ppmPortTable can just be deleted.</tt> <tt>For 'ppmPortProtocolType' using 'PrtChannelTypeTC', we're working</tt> <tt>to get 'unknown(2)' registered quickly with IANA, so that we can</tt> <tt>do the 'right thing' that Bert Wijnen pointed out.</tt> <tt>Cheers,</tt> <tt>- Ira</tt> <tt>Ira McDonald (Musician / Software Architect)</tt> <tt>Blue Roof Music / High North Inc</tt> <st1:address w:st="on"><st1:Street w:st="on"><tt>PO Box</tt></st1:Street><tt> 221</tt></st1:address><tt>  Grand <st1:place w:st="on"><st1:City w:st="on">Marais</st1:City>, <st1:State w:st="on">MI</st1:State>  <st1:PostalCode w:st="on">49839</st1:PostalCode></st1:place></tt> <tt>phone: +1-906-494-2434</tt> <tt>email: imcdonald@sharplabs.com</tt> <tt>-----Original Message-----</tt> <tt>From: McDonald, Ira</tt> <tt>Sent: Friday, July 22, 2005 1:37 PM</tt> <tt>To: 'thrasher@lexmark.com'; McDonald, Ira</tt> <tt>Cc: pmp@pwg.org; Ron.Bergman@rpsa.ricoh.com</tt> <tt>Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>Hi Jerry,</tt> <tt>I agree that feedback from the clients (Microsoft and Apple) on how they'd</tt> <tt>like this to work would be helpful.</tt> <tt>Remember, that a value of 'ppmPrinterIndex' must NEVER be reassigned</tt> <tt>to a different instance of a Printer at a later date.  While the MIB may</tt> <tt>grow and shrink, the base 'ppmPrinterIndex' should be immutably</tt> <tt>associated with exactly one specific instance of a Printer.  This is both</tt> <tt>correct MIB practice and required by the object definition in the current</tt> <tt>MIB draft.</tt> <tt>Cheers,</tt> <tt>- Ira</tt> <tt>Ira McDonald (Musician / Software Architect)</tt> <tt>Blue Roof Music / High North Inc</tt> <st1:address w:st="on"><st1:Street w:st="on"><tt>PO Box</tt></st1:Street><tt> 221</tt></st1:address><tt>  Grand <st1:place w:st="on"><st1:City w:st="on">Marais</st1:City>, <st1:State w:st="on">MI</st1:State>  <st1:PostalCode w:st="on">49839</st1:PostalCode></st1:place></tt> <tt>phone: +1-906-494-2434</tt> <tt>email: imcdonald@sharplabs.com</tt> <tt>-----Original Message-----</tt> <tt>From: thrasher@lexmark.com [mailto:thrasher@lexmark.com]</tt> <tt>Sent: Friday, July 22, 2005 1:28 PM</tt> <tt>To: McDonald, Ira</tt> <tt>Cc: pmp@pwg.org; Ron.Bergman@rpsa.ricoh.com</tt> <tt>Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>I would think that the usefullness of the ppmPrinterEnabled for an</tt> <tt>ENA would only be for the "transcient" case of the plugging/unplugging</tt> <tt>of the related printer.  However at some point (in the case that the printer</tt> <tt>stays unplugged "permanently") the printer entry and associated protocol</tt> <tt>tables would be removed such that the the MIB could grow and shrink</tt> <tt>over time.....</tt> <tt>For example, an ENA with a USB host interface that supports up to</tt> <tt>128 attached printers, In my opinion, shouldn't need to have 128 printer</tt> <tt>entries</tt> <tt>in the MIB tables from first power on......only the entries that have</tt> <tt>detected (valid 1284ID)</tt> <tt>printers etc. attached.....otherwise you'd end up in most cases with 127</tt> <tt>default printer entries</tt> <tt>with associated port tables that don't actually go anywhere.</tt> <tt>Of course this behaviour is different from the current TCPMON.ini file</tt> <tt>which has static entries.......</tt> <tt>I think maybe the clients should give guidance on how they want it to work.</tt> <tt>Jerry Thrasher</tt> <tt>"McDonald, Ira" <imcdonald@sharplabs.com></tt> <tt>Sent by: pmp-owner@pwg.org</tt> <tt>07/22/2005 12:13 PM</tt> <tt>To:        "'Bergman, Ron'" <Ron.Bergman@rpsa.ricoh.com>, "McDonald,</tt> <tt>Ira" <imcdonald@sharplabs.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,</tt> <tt>pmp@pwg.org</tt> <tt>cc:</tt> <tt>Subject:        RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>Hi Ron,</tt> <tt>If the Printer entry is deleted when an ENA interface</tt> <tt>is disconnected, then all the subordinate Port entries</tt> <tt>MUST be deleted too (because they are indexed by the</tt> <tt>object ppmPrinterIndex).  This is ugly if the local</tt> <tt>printer is promptly plugged _back_ into the interface.</tt> <tt>If the Printer entry is left in place but _not_ clearly</tt> <tt>marked 'disabled', then ppmPrinterIEEE1284DeviceId,</tt> <tt>ppmPrinterHrDeviceIndex and all the other Printer</tt> <tt>columnar objects must be reset (to default values).</tt> <tt>That's why the ppmPrinterEnabled object should be kept.</tt> <tt>The WG concensus was strong that ppmPortEnabled was</tt> <tt>required to keep the port list static (fixed number</tt> <tt>of ports for an interface).  Therefore, I added the</tt> <tt>ppmPrinterEnabled object.</tt> <tt>If others want ppmPrinterEnabled removed, would they</tt> <tt>please speak up soon?</tt> <tt>Cheers,</tt> <tt>- Ira</tt> <tt>PS - Remember that this MIB is supposed to work for</tt> <tt>Network Spoolers too, where the concept of 'the printer</tt> <tt>is removed' is fuzzy.  The 'printer' is just some</tt> <tt>configured downstream network printer that may well</tt> <tt>be administratively disabled _without_ removing the</tt> <tt>configuration at the Network Spooler.</tt> <tt>Ira McDonald (Musician / Software Architect)</tt> <tt>Blue Roof Music / High North Inc</tt> <st1:address w:st="on"><st1:Street w:st="on"><tt>PO Box</tt></st1:Street><tt> 221</tt></st1:address><tt>  Grand <st1:place w:st="on"><st1:City w:st="on">Marais</st1:City>, <st1:State w:st="on">MI</st1:State>  <st1:PostalCode w:st="on">49839</st1:PostalCode></st1:place></tt> <tt>phone: +1-906-494-2434</tt> <tt>email: imcdonald@sharplabs.com</tt> <tt>> -----Original Message-----</tt> <tt>> From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]</tt> <tt>> Sent: Thursday, July 21, 2005 8:24 PM</tt> <tt>> To: McDonald, Ira; Wijnen, Bert (Bert); pmp@pwg.org</tt> <tt>> Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>></tt> <tt>></tt> <tt>> Ira,</tt> <tt>></tt> <tt>> Base on my experience with ENAs, they do not provide a feature to</tt> <tt>> disable an output port unless the printer is removed.  Normally,</tt> <tt>> this is to replace a worn-out unit or upgrade a printer.</tt> <tt>> In this case the old printer is gone forever.  So how does your</tt> <tt>> "STATIC entries" handle this situation?</tt> <tt>></tt> <tt>>         Ron</tt> <tt>></tt> <tt>> -----Original Message-----</tt> <tt>> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]</tt> <tt>> Sent: Wednesday, July 20, 2005 8:38 AM</tt> <tt>> To: Bergman, Ron; McDonald, Ira; Wijnen, Bert (Bert); pmp@pwg.org</tt> <tt>> Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>></tt> <tt>></tt> <tt>> Hi Ron,</tt> <tt>></tt> <tt>> Based on previous IPP experience, it will take MONTHS to add one</tt> <tt>> new enum to the PrtChannelTypeTC with IANA - that would stop the</tt> <tt>> Port Mon MIB dead in its tracks until it was accepted by IANA.</tt> <tt>></tt> <tt>> About ppmPrinterEnabled - same rationale as ppmPortEnabled - keeps</tt> <tt>> the number of Printer entries STATIC in an implementation - lets</tt> <tt>> the user see that the one Printer (i.e., hardward output interface)</tt> <tt>> on an External Network Adapter should presently be ignored.</tt> <tt>></tt> <tt>> Remember that the Port Mon MIB MUST NOT depend on either Host</tt> <tt>> Resources or Printer MIB, by common concensus - it may only</tt> <tt>> AUGMENT them, if they are present.</tt> <tt>></tt> <tt>> Cheers,</tt> <tt>> - Ira</tt> <tt>></tt> <tt>> Ira McDonald (Musician / Software Architect)</tt> <tt>> Blue Roof Music / High North Inc</tt> <tt>> PO Box 221  Grand <st1:place w:st="on"><st1:City w:st="on">Marais</st1:City>, <st1:State w:st="on">MI</st1:State>  <st1:PostalCode w:st="on">49839</st1:PostalCode></st1:place></tt> <tt>> phone: +1-906-494-2434</tt> <tt>> email: imcdonald@sharplabs.com</tt> <tt>></tt> <tt>> > -----Original Message-----</tt> <tt>> > From: Bergman, Ron [mailto:Ron.Bergman@rpsa.ricoh.com]</tt> <tt>> > Sent: Tuesday, July 19, 2005 7:40 PM</tt> <tt>> > To: McDonald, Ira; Wijnen, Bert (Bert); pmp@pwg.org</tt> <tt>> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > Ira,</tt> <tt>> ></tt> <tt>> > I am not sure what value ppmPrinterEnabled adds to the MIB.</tt> <tt>> > This appears to be analogous to</tt> <tt>> > On Line/Off Line.  If I want to create a driver for the</tt> <tt>> > printer I don't care what the current</tt> <tt>> > state is.  That information is only necessary when I am ready</tt> <tt>> > to print and then this MIB is</tt> <tt>> > not used.</tt> <tt>> ></tt> <tt>> > I believe that Bert has a valid point in using</tt> <tt>> > ppmPortProtocolType.  It is not a major effort</tt> <tt>> > to add unknown(2) to the IANA registrations.</tt> <tt>> ></tt> <tt>> > Otherwise, the changes are inline with our discussions</tt> <tt>> > following the test.</tt> <tt>> ></tt> <tt>> >         Ron</tt> <tt>> ></tt> <tt>> > -----Original Message-----</tt> <tt>> > From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf</tt> <tt>> > Of McDonald,</tt> <tt>> > Ira</tt> <tt>> > Sent: Tuesday, July 19, 2005 9:46 AM</tt> <tt>> > To: 'Wijnen, Bert (Bert)'; McDonald, Ira; 'pmp@pwg.org'</tt> <tt>> > Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > Hi Bert,</tt> <tt>> ></tt> <tt>> > Thanks for your quick feedback.  My replies inline below.</tt> <tt>> ></tt> <tt>> > Cheers,</tt> <tt>> > - Ira</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > Ira McDonald (Musician / Software Architect)</tt> <tt>> > Blue Roof Music / High North Inc</tt> <tt>> > <st1:address w:st="on"><st1:Street w:st="on">PO Box</st1:Street> 221</st1:address>  Grand <st1:place w:st="on"><st1:City w:st="on">Marais</st1:City>, <st1:State w:st="on">MI</st1:State>  <st1:PostalCode w:st="on">49839</st1:PostalCode></st1:place></tt> <tt>> > phone: +1-906-494-2434</tt> <tt>> > email: imcdonald@sharplabs.com</tt> <tt>> ></tt> <tt>> > > -----Original Message-----</tt> <tt>> > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]</tt> <tt>> > > Sent: Tuesday, July 19, 2005 9:08 AM</tt> <tt>> > > To: McDonald, Ira; 'pmp@pwg.org'</tt> <tt>> > > Subject: RE: PMP> Restructured Port MIB (18 July 2005)</tt> <tt>> > ></tt> <tt>> > ></tt> <tt>> > > Only did a very very quick scan.</tt> <tt>> > ></tt> <tt>> > > Comments.</tt> <tt>> > ></tt> <tt>> > > - ppmPortProtocolTargetPort OBJECT-TYPE</tt> <tt>> > >     SYNTAX      Integer32 (0..65535)</tt> <tt>> > >   I propose that you use InetPortNumber TC from RFC4001</tt> <tt>> > ></tt> <tt>> ></tt> <tt>> > Won't work, because this port is not limited to Internet Suite</tt> <tt>> > protocols.  The 'service:' URI in ppmPortServiceNameOrURI may</tt> <tt>> > also be for non-Internet suites (AppleTalk, NetWare, etc.).</tt> <tt>> ></tt> <tt>> > I'll correct the DESCRIPTION in the MIB and make clear that</tt> <tt>> > (as with the Printer MIB) ports/channels may be from multiple</tt> <tt>> > protocol suites.</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > > - ppmPortProtocolType OBJECT-TYPE</tt> <tt>> > >     SYNTAX      Integer32 (0..2147483647)</tt> <tt>> > ></tt> <tt>> > >   WHy not use TC PrtChannelTypeTC as the SYNTAX?</tt> <tt>> > >   I do see that you want to use zero (meaning not supported).</tt> <tt>> > >   But maybe better is to use none(1) in that case, or maybe</tt> <tt>> > >   adding an enumeration to the TC of notSupported(xx) ??</tt> <tt>> > >   It is now an IANA-maintained TC, so it should not be that</tt> <tt>> > >   difficult to get a label added.</tt> <tt>> > ></tt> <tt>> ></tt> <tt>> > Won't work.  PrtChannelTypeTC currently only defines 'other(1)'</tt> <tt>> > and (foolishly) does NOT define 'unknown(2)' (unlike every other</tt> <tt>> > textual convention in the Printer MIB).  Because the Printer MIB</tt> <tt>> > v2 still doesn't define DEFVAL clauses for most objects, this</tt> <tt>> > oversight has not surfaced before.  We could register 'unknown(2)'</tt> <tt>> > with IANA, but _not_ fast enough (because this MIB's going into OS</tt> <tt>> > and printer vendor products right now).</tt> <tt>> ></tt> <tt>> ></tt> <tt>> > > - ppmPortPrtChannelIndex has a reference to RFC1213, while I</tt> <tt>> > >   think I would reather reference RFC2863 (the current IF-MIB)</tt> <tt>> > ></tt> <tt>> > > Bert</tt> <tt>> > ></tt> <tt>> ></tt> <tt>> > Agreed.  My mistake from the old Printer MIB (RFC 1759).</tt> <tt>> ></tt> <tt>> > I'll correct the references in the MIB.</tt> <tt>> > - Ira</tt> <tt>> ></tt> <tt>></tt> <o:p></o:p> </div> </body> </html>