PMP Mail Archive: Re: PMP> Printer MIB status [chIPP]

Re: PMP> Printer MIB status [chIPP]

Ira McDonald (imcdonal@sdsp.mc.xerox.com)
Wed, 7 Jul 1999 12:32:21 -0400

Hi Lloyd, Wednesday (7 July 1999)

Tom Hastings is on vacation for several weeks, so I'll post (here) his
final revision of 'chIPP' for comment. The only change Tom made was to
fix the sentence about the use of explicit ports in 'http:' URIs.

I have just fixed the references to IPP/1.1 to be the current Internet-
Draft specs (two versions newer than before). And I just verified that
the keywords and usage of the channel attributes below still agree with
the latest IPP/1.1 I-Ds.

Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
906-494-2697/2434 (home/office)

PS - I agree with Jay, Angelo, and Matt that a 'second' after a proposal
is a good idea but that further voting needs to be based on NEGATIVE
voting, not on 'show of hands of approval'. People go on vacaction
(like Tom Hastings). People get overwhelmed with email volume (all of
us from time to time).

--------------------------------------------------
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'
--------------------------------------------------
>
>From: lpyoung@lexmark.com
>To: imcdonal@sdsp.mc.xerox.com, harryl@us.ibm.com
>Cc: pmp@pwg.org
>Date: Tue, 6 Jul 1999 14:38:42 -0400
>Subject: Re: PMP> Printer MIB status
>
>Harry and Ira,
>
>I do not have a problem putting the new chIPP and Media
>Path alert changes in the Printer MIB but here is the
>statement that is in the Printer MIB for Type 2 enums
>which both of these are:
>
>enumeration (2) An initial set of values are defined
>in the Printer MIB specification. Additional enumerated
>values are registered after review by this working group.
>The initial versions of the MIB will contain the values
>registered so far. After the MIB is approved, additional
>values will be registered through IANA after approval
>by this working group.
>
>Review and approval by the working group consists more
>than someone identifying a problem. It requires others
>from the working group to indicate on the mailing list
>that they have reviewed and approved the additions. The
>review and approval process does not need to be conducted
>in a face to face meeting, it can be conducted on the mailing
>list. But changes do require the review and approval of
>the working group before they will be included.
>
>As best as I can tell from the PMP mail archives here is the
>mail history for the chIPP and Media Path alert changes:
>
>chIPP Channel addition
>
>- Tom Hastings submitted original proposal 5/11
>- Tom Hastings submitted revised proposal 5/20
>- David Kellerman noted his review and approval, also had
> questions 5/27
>- Ira answered David's questions and noted potential changes
> and/or rewrite to revised proposal 5/27
>
>Media path alert addition
>
>- Harry submitted original proposal 6/3
>- Harry submitted revised proposal 6/3
>
>There has not been any other mail saying that anyone else has
>reviewed or approves these changes.
>
>Lloyd
>