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: imcdonald at sharplabs.com
----------------------------------------
From: lpyoung at lexmark.com
To: pmp at pwg.org
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: lpyoung at lexmark.com Lexington, KY 40550-0001
Phone: (606) 232-5150 Fax: (630) 982-4032
-----Original Message-----
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Tuesday, March 28, 2000 9:30 PM
To: pmp at pwg.org
Cc: rbergma at hitachi-hkis.com; mike.elvers at usa.xerox.com
Subject: PMP> Printer MIB v2 changes
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