PMP Mail Archive: RE: PMP> Printer MIB v2 changes

PMP Mail Archive: RE: PMP> Printer MIB v2 changes

RE: PMP> Printer MIB v2 changes

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Wed Mar 29 2000 - 18:49:01 EST

  • Next message: McDonald, Ira: "RE: PMP> Printer MIB v2 changes - Xerox/Sharp response"

    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@sharplabs.com

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



    This archive was generated by hypermail 2b29 : Wed Mar 29 2000 - 18:55:45 EST