Ira,
I am confused about the messages from PWG concerning media size names in the
Printer MIB and IEEE-ISTO 5101. In particular, in the Printer MIB,
shouldn't prtInputMediaName reference IEEE-ISTO 5101.1 in preference to
Appendix C. And it seems that the Self-Describing Name should be encouraged
as the default MediaName.
Also, please note that the last line of the first paragraph of Appendix B
uses the object name prtMediaDimFeedDir. I believe you mean
prtInputChosenMediaDimFeedDir.
Thanks for pushing the Printer MIB through the process.
Mark Hopkins
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Thursday, January 10, 2002 2:15 PM
To: McDonald, Ira; 'Ron.Bergman at Hitachi-hkis.com'; 'bwijnen at lucent.com'
Cc: 'schoenw at ibr.cs.tu-bs.de'; 'dbh at enterasys.com'; 'harryl at us.ibm.com';
'RCasterline at lhsolutions.com'; 'pmp at pwg.org'
Subject: RE: PMP> Printer MIB draft-11 posted at PWG site (10 January
2002 )
Hi folks,
I just posted the latest version of Printer MIB v2 (draft-11) at the
PWG FTP server - this copy DOES have the formfeeds (page breaks), so
it prints and views better. And I extracted and compiled and verified
the ASN.1 for the MIB.
To the best of our knowledge this version corrects all problems that
Bert Wijnen, David Harrington, and Juergen Schoenwaelder have found.
The editors believe this document is now ready for publication as an RFC.
At the PWG anonymous FTP server in the directory:
ftp://ftp.pwg.org/pub/pwg/pmp/drafts/
in the files:
draft-ietf-printmib-mib-info-11.txt -- full document w/ formfeeds
draft-ietf-printmib-mib-info-11.mib -- extracted ASN.1 for MIB
Cheers,
- Ira McDonald, co-editor of Printer MIB v2
High North Inc
imcdonald at sharplabs.com
-----Original Message-----
From: Ron.Bergman at Hitachi-hkis.com [mailto:Ron.Bergman at Hitachi-hkis.com]
Sent: Monday, January 07, 2002 11:44 AM
To: bwijnen at lucent.com
Cc: schoenw at ibr.cs.tu-bs.de; dbh at enterasys.com; pmp at pwg.org;
IMcDonald at crt.xerox.com; harryl at us.ibm.com; RCasterline at lhsolutions.com
Subject: PMP> RE: Response to Printer MIB Comments of 15 Nov, 2001
Bert,
Our latest version MIB is now *finally* available at:
http://www.ietf.org/internet-drafts/draft-ietf-printmib-mib-info-11.txt
Unfortunately, the posted version is missing form feeds. Ira McDonald has a
version that contains the missing form feeds and is also planning to run it
through David Perkins' "mstrip" tool to extract the MIB. I can send to you
either the version with form feeds and/or the stripped MIB if don't want to
deal with unfriendly version that was posted.
Ron Bergman
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
Sent: Saturday, December 08, 2001 9:08 PM
To: Bergman, Ron; 'bwijnen at lucent.com'
Cc: 'schoenw at ibr.cs.tu-bs.de'; 'dbh at enterasys.com'; 'pmp at pwg.org'; Ira
McDonald (E-mail); Harry Lewis (E-mail); Ray Casterline (E-mail 2)
Subject: RE: Response to Printer MIB Comments of 15 Nov, 2001
I did not yet look at the new rev (too busy preparing for
IETF... and I bet Dave Harington is in same situation).
Why don;t you post the new draft as soon as repository opens up
again and then we'll review.
Bert
> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
> Sent: Tuesday, December 04, 2001 5:03 PM
> To: 'bwijnen at lucent.com'
> Cc: 'schoenw at ibr.cs.tu-bs.de'; 'dbh at enterasys.com'; 'pmp at pwg.org'; Ira
> McDonald (E-mail); Harry Lewis (E-mail); Ray Casterline (E-mail 2)
> Subject: Response to Printer MIB Comments of 15 Nov, 2001
>>> Bert,
>> 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
> issues.
>> 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
>> Bert
>> > -----Original Message-----
> > From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
> > Sent: Thursday, November 15, 2001 9:07 PM
> > To: 'Juergen Schoenwaelder'
> > Cc: bwijnen at lucent.com; dbh at enterasys.com; IMcDonald at crt.xerox.com;
> > Bergman, Ron; harryl at us.ibm.com; RCasterline at crt.xerox.com;
> > pmp at pwg.org;
> > paf at cisco.com; ned.freed at mrochek.com> > 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 [mailto:schoenw at ibr.cs.tu-bs.de]
> > Sent: Thursday, November 15, 2001 1:28 AM
> > To: Ron.Bergman at Hitachi-hkis.com> > Cc: bwijnen at lucent.com; dbh at enterasys.com; IMcDonald at crt.xerox.com;
> > Ron.Bergman at Hitachi-hkis.com; harryl at us.ibm.com;
> > RCasterline at crt.xerox.com; pmp at pwg.org; paf at cisco.com;
> > ned.freed at mrochek.com> > 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
> (1..2147483647).
>> 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.
>> Bert
>