Subject: PMP> Printer MIB v2 changes

From: [email-masked]
Date: Tue, 28 Mar 2000 22:29:35 -0700

Of the list of enumeration changes that have been debated going from v1 to
v2... here are the ones I agree make sense to "change back" (stated in
their v1 format).

The following are alert coded

coverOpen
interlockOpen
configuratoinChange
jam
powerUp
powerDown
inputMediaSizeChange
inputMediaTypeChange
inputMediaColorChange
interpreterMemoryIncrease
interpreterMemoryDecrease

The following are alert severities

critical
warning

The following is subUnitStatus

atIntendedState

All the other changes appeared to me to have a good purpose. Either they
corrected a misspelled word or resolved some conflict that had been
debated. A good example of this is the change in prtConsoleDisabled enums
from enabled/disabled to operatorConsoleEnabled/operatorConsoleDisabled.
Remember the debate about "enabling the disable"? I do ;-(.

I have already changed the above and am preparing to issue a new draft of
the Printer MIB. Now is the time to comment if you object or have further
observations. I think Mike was first to point out the folly of some of
these changes and my interpretation was that Mike was just asking for some
prudent reservation... I believe the collection, above, represents that.

I need some help on the change of things like prtChannelType to
PrtChannelTypeTC. This type of change occurs a lot and Mike seems to be
suggesting it was unnecessary but it would appear to me to be correcting
an original syntactical oversight.

Harry Lewis
IBM Printing Systems

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 29 Mar 2000 14:10:53 -0800

Hi Harry,

Your reasoning looks sound in principle (for instance,
correcting spelling errors seems appropriate).  

Your note will be addressed tomorrow (Thursday) at the
regular Xerox open management community telecon.  Some
detailed feedback should be available after that.

Of course any symbol (textual convention or enum label)
that changes from RFC 1759 (even for sound reasons)
breaks somebody's existing code (because they have to
modify the code and recompile).  It also breaks the
national language message catalogs in some products
(because the key string changes, where the enum was 
converted back to a label, which is commonly the case).

I'll be glad to work with you on the edits (and on the
verification that the result compiles cleanly on more
than one SMIv2 capable MIB compiler).  By the way, when
testing yourself, remember that both the RFC 144x and
RFC 190x series of SMIv2 specs are OBSOLETE.  The current
specs are RFC 2578/2579/2580 (April 1999).  

Please avoid the temptation to 'fix' LAST-UPDATED clause
of the MODULE-IDENTITY macro at the beginning of the MIB
to use extended UTC time - there are no commercial MIB
compilers in existence that correctly parse four-digit
years in extended UTC time (another year 2000 bug...).

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 28, 2000 9:30 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: PMP> Printer MIB v2 changes

coverOpen
interlockOpen
configuratoinChange
jam
powerUp
powerDown
inputMediaSizeChange
inputMediaTypeChange
inputMediaColorChange

critical
warning

atIntendedState

Harry Lewis
IBM Printing Systems

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 29 Mar 2000 15:49:01 -0800

Hi Harry,                                      Wednesday (29 March 2000)

I searched my old email archives for pending Printer MIB v2 changes and
this is what I found (below).

You also brought up some new 'pull' print channel types but you got
generally shouted down (in my reading of the email) by Don Wright,
Dave Kellerman, and others - the rationale being that a user should
look at an LDAP/SLP directory entry OR look at the IPP Printer object
itself in order to learn additional info about supported features.

NOTE - In the PMP approved updates below:

a)  The 'chIPP' default for 'Version' should be changed to '1.1'
    (which is 'standards track' - IPP/1.0 is 'Experimental').

b)  The references for [IPP-MOD-11] and [IPP-PRO-11] are out-of-date
    (should be '-06' for Model and '-05' for Protocol).

Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

PS - My current contact info (for Printer MIB contributors list):

Ira McDonald
High North Inc
221 Ridge Ave
Grand Marais, MI  49839

Phone: +1 906-494-2434 or +1 906-494-2697
Email: [email-masked]

----------------------------------------
From: [email-masked]
To: [email-masked]
Date: Wed, 21 Jul 1999 18:17:28 -0400
Subject: PMP> Printer MIB Change Proposals

Both Printer MIB change proposals were accepted by a consensus of the
Printer MIB Working Group.

My plan is to have a revised Printer MIB available around August 16th
with these two changes incorporated as well as other minor editorial
changes (including the change of hrPrinterDetectedErrorState back to BITS).

1. In the PrtAlertCodeTC Textual Convention, Media Path Device Group, the
following will be added:
--------------------------------------------------
"cannotDuplexMediaSelected(1304)"
--------------------------------------------------

2. In the PrtChannelTypeTC Textual Convention, the following will be added:
--------------------------------------------------
               chIPP(44),
                 -- Internet Printing Protocol (IPP)
                 -- (IPP/1.0 - see RFC 2565/2566)
                 -- (also applies to all future versions of IPP)
                 --
                 -- IPP Printer URI
                 --   Keyword:        URI
                 --   Syntax:         URI (Unicode UTF-8 per RFC 2396)
                 --   Status:         Mandatory
                 --   Multiplicity:   Single
                 --   Default:        not applicable
                 --   Description: URI of this IPP Printer within the
                 --   Internet naming scope.  Unicode UTF-8 [RFC-2279]
                 --   string with hexadecimal escapes for any non-ASCII
                 --   characters (per RFC 2396).
                 --   Conformance: An IPP Printer shall list all IPP
                 --   URI it supports (one per IPP Channel entry).
                 --   If a URI contains the 'http:' scheme, it MUST
                 --   have an explicit port.
                 --   See: [RFC-2279], [RFC-2396], [RFC-2565],
                 --   [RFC-2566].
                 --
                 -- IPP Printer Client Authentication
                 --   Keyword:        Auth
                 --   Syntax:         Keyword
                 --   Status:         Optional
                 --   Multiplicity:   Single
                 --   Default:        'none'
                 --   Description: A client authentication mechanism
                 --   supported for this IPP Printer URI:
                 --     'none'
                 --       no client authentication mechanism
                 --     'requesting-user-name'
                 --       authenticated user in 'requesting-user-name'
                 --     'basic'
                 --       authenticated user via HTTP Basic mechanism
                 --     'digest'
                 --       authenticated user via HTTP Digest mechanism
                 --     'certificate'
                 --       authenticated user via certificate mechanism
                 --   Conformance: An IPP Printer should list all IPP
                 --   client authentication mechanisms it supports
                 --   (one per IPP Channel entry).
                 --   See: [IPP-MOD-11], [IPP-PRO-11].
                 --
                 -- IPP Printer Security
                 --   Keyword:        Security
                 --   Syntax:         Keyword
                 --   Status:         Optional
                 --   Multiplicity:   Single
                 --   Default:        'none'
                 --   Description: A security mechanism supported for
                 --   this IPP Printer URI:
                 --     'none'
                 --       no security mechanism
                 --     'ssl3'
                 --       SSL3 secure communications channel protocol
                 --     'tls'
                 --       TLS secure communications channel protocol
                 --   Conformance: An IPP Printer should list all IPP
                 --   security mechanisms it supports (one per IPP
                 --   Channel entry).
                 --   See: [RFC-2246], [RFC-2566], [IPP-MOD-11].
                 --
                 -- IPP Printer Protocol Version
                 --   Keyword:        Version
                 --   Syntax:         Keyword
                 --   Status:         Optional
                 --   Multiplicity:   Multiple
                 --   Default:        '1.0'
                 --   Description: All of the IPP protocol versions
                 --   (major.minor) supported for this IPP Printer URI:
                 --     '1.0'
                 --       IPP/1.0 conforming Printer
                 --     '1.1'
                 --       IPP/1.1 conforming Printer
                 --   Conformance: An IPP Printer should list all IPP
                 --   versions it supports (all listed in each IPP
                 --   Channel entry).
                 --   An IPP Client should select the highest numbered
                 --   version that the client supports for use in all
                 --   IPP Requests (for optimum interworking).
                 --   See: [RFC-2566], [IPP-MOD-11].
                 --
                 --   References:
                 --   [RFC-2246] TLS/1.0 Protocol
                 --     section 9 'Mandatory Cipher Suites'
                 --   [RFC-2279] UTF-8 Transform of ISO 10646
                 --     section 2 'UTF-8 Definition'
                 --   [RFC-2396] Generic URI Syntax
                 --     section 2.1 'URI and non-ASCII characters'
                 --   [RFC-2566] IPP/1.0 Model and Semantics
                 --     section 4.1.5 'uri' (attribute syntax)
                 --     section 4.4.1 'printer-uri-supported'
                 --     section 4.4.2 'uri-security-supported'
                 --     section 4.4.14 'ipp-versions-supported'
                 --     section 5 'Conformance'
                 --   [RFC-2565] IPP/1.0 Encoding and Transport
                 --     section 3.3 'Version-number'
                 --     section 5.1 'Using IPP with SSL3'
                 --     section 9 'Appendix A: Protocol Examples'
                 --   [IPP-MOD-11] IPP/1.1 Model and Semantics
                 --     <draft-ietf-ipp-model-v11-04.txt>
                 --     (work-in-progress)
                 --     section 4.4.2 'uri-authentication-supported'
                 --     section 4.4.3 'uri-security-supported'
                 --   [IPP-PRO-11] IPP/1.1 Encoding and Transport
                 --     <draft-ietf-ipp-protocol-v11-03.txt>
                 --     (work-in-progress)
                 --     section 3.3 'Version-number'
                 --     section 5 'IPP URL Scheme'
                 --     section 9 'Appendix A: Protocol Examples'
------------------------------------------------------------
Lloyd Young
Manager, Alliances and Complementary Project Development
Consumer Printer Division         Lexmark International, Inc.
Dept. C88M/Bldg. 005-1            740 New Circle Road NW
email: [email-masked]        Lexington, KY 40550-0001
Phone: (606) 232-5150             Fax: (630) 982-4032
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 28, 2000 9:30 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: PMP> Printer MIB v2 changes

coverOpen
interlockOpen
configuratoinChange
jam
powerUp
powerDown
inputMediaSizeChange
inputMediaTypeChange
inputMediaColorChange

critical
warning

atIntendedState

Harry Lewis
IBM Printing Systems