PMP Mail Archive: PMP> Response to Printer MIB Comments of 1

PMP Mail Archive: PMP> Response to Printer MIB Comments of 1

PMP> Response to Printer MIB Comments of 15 Nov, 2001

From: Bergman, Ron (
Date: Tue Dec 04 2001 - 11:02:54 EST

  • Next message: "PMP> RE: Response to Printer MIB Comments of 15 Nov, 2001"


    The Working Group has had extensive discussions relating to
    the five points that you presented on November 15. We have
    finally reached an agreement and propose changes for all 5

    Please let me know if you would like an updated draft
    immediately, or would like first to complete your review of
    the previous draft (version 10). I have not seen any
    comments on this version from either yourself or David or
    Juergen. Can we assume there are no further issues?

    Please see the comments from the WG, prefixed by "WG>>".

            Ron Bergman

    Original Message...

    Ron... if you have it complete, maybe you can send us a prelimenary
    copy to quickly check if we are happy with it.

    Juergen, that for checking with your nice little tool/toy.

    More comments inline


    > -----Original Message-----
    > From: Bergman, Ron []
    > Sent: Thursday, November 15, 2001 9:07 PM
    > To: 'Juergen Schoenwaelder'
    > Cc:;;;
    > Bergman, Ron;;;
    > Subject: RE: Print MIB 09
    > Juergen,
    > Thank you again for the comments. I have just about
    > completed the draft, so
    > I should be able to incorporate any changes necessary in
    > version 10. See my
    > comments below prefixed by RB>>.
    > Ron
    > -----Original Message-----
    > From: Juergen Schoenwaelder []
    > Sent: Thursday, November 15, 2001 1:28 AM
    > To:
    > Cc:;;;
    > Subject: Re: Print MIB 09
    > >>>>> Bergman, Ron writes:
    > Ron> I believe that all issues are now resolved and I estimate we will
    > Ron> have a revised MIB by early next week.
    > I did run the MIB through smidiff yesterday (a tool which computes the
    > changes between two MIB versions) and I found some things I wanted to
    > share.
    > - There are some changes which, if you take the rules very strictly,
    > can turn compliant implementations to be non-compliant, even though
    > the document says:
    > This draft supercedes and replaces RFC 1759. However, a compliant

    I would also change "daft" in "document" so the text is still valid when
    it becomes an RFC.

    WG>> This is a very good suggestion and will be changed.

    > implementation of RFC 1759 is also compliant with this draft. The
    > following changes to RFC 1759 are included:
    > For example, prtConsoleLightIndex changed from Integer32 (0..65535)
    > to Integer32 (1..65535). Perhaps this just fixes a typo in the
    > original MIB - but it would be worthwhile to list changes such as
    > this explicitely.
    > RB>> This was definitely a typo, since index values are never zero.
    > I will add this (and two other similar changes) to section 4.
    Such changes would be good to list in the REVISION clause as well

    WG>> We will add as suggested and review the remaining changes to
         determine if any others should also be included.

    > Also, prtInputDefaultIndex changed from Integer32 (1..65535) to
    > Integer32 and prtMarkerColorantValue changed from (SIZE (0..63)) to
    > (SIZE (0..255)).
    > RB>> prtInputDefaultIndex was also a typo, since this object allows
    > -1 per the description clause. This has been corrected.
    It seems to me that maybe it should be:

         Integer32 ( -1 | 1..65535)

    You're no allowing any negative value, are you?

    And how about the size extension?

    WG>> In reviewing this issue we have determined that this is not a
         change compatible with RFC 1759, since the text in the
         description clause that indicates the use of -1 was not in
         RFC 1759. The WG has agreed to remove this added text and
         restore the range to (1..65535) as in RFC 1759.

    > - The prtChannelIndex and prtAlertIndex both have a range
    > (1..2147483647) addded while all the other *Index objects seem to
    > prefer (1..65535). The wider range is from an architectural
    > standpoint better, but for consistency, the smaller range might be
    > better. What did people actually implement?
    > RB>> I will change both to the smaller value to be consistent.
    And the WG explicitly agrees with all this, right?
    If so, then I am OK with that, assuming that this is based on
    implementation experience.

    In RFC1759 there was no limit, so (1..2147483647) was the range of
    valid values there.

    WG>> The range for prtChannelIndex is OK as (1..65535). No printer
         will ever require more than this amount. However, we have found
         a problem with prtAlertIndex and will change this back to

         There is also a compatibility problem with the smaller range for
         prtStorageRefIndex and prtDeviceRefIndex. To agree with RFC 2790
         (HR MIB) these will be changed to (0..2147483647). This change
         will also be noted in the REVISION clause.

    > - Should you not use InterfaceIndexOrZero in prtChannelIfIndex? The
    > description also refers to RFC 1213 where it should refer to the
    > IF-MIB, currently in RFC 2863. This creates a dependency but I think
    > this is fine as the IF-MIB is already at Draft.
    > RB>> Use of RFC 2863 was previously review by the WG and it was felt
    > this was likely to result in too many additional dependencies.
    > Use of InterfaceIndexOrZero also has similar problems. We would
    > prefer to not change since there have not been any implementation
    > problems reported in this area.
    Ron... it seems that InterfaceIndexOrZero is exactly what you want.
    It is the most up to date way on how we specify these things these days.
    The TC is an Integer32 underneath that allows exactly the values that
    you want. And so there is no change on the protocol on the wire or
    on the data types that you send/receive.
    I strongly recommend to use InterfaceIndexOrZero.

    WG>> We have reviewed this issue again and agree to change the SYNTAX
         clause to InterfaceIndexOrZero. Our previous concerns were based
         on this "tied" into RFC 2863. As long as we do not have to
         require RFC 2863, this is acceptable. (Most printer manufactures
         have incorporated purchased IP stacks and the cost and logistics
         of upgrading these stacks would be prohibitive at this time.)

    Right now you agreed to recycle at PS. So it is a good time to do this.
    By the time you ever get to Draft or (full) Standard, MIB II (RFC1213)
    may have gone to historic, and then you need to change anyway.


    This archive was generated by hypermail 2b29 : Tue Dec 04 2001 - 10:54:13 EST