Lloyd,
Please enter my vote as a YES for this proposal.
Ron Bergman
Hitachi Koki Imaging Solutions
On Wed, 7 Jul 1999, Ira McDonald wrote:
>> 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 at lexmark.com> >To: imcdonal at sdsp.mc.xerox.com, harryl at us.ibm.com> >Cc: pmp at 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
> >
>>