From pwg-announce-owner@pwg.org Sat Jul 01 11:38:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwhYW-00022s-AK; Sat, 01 Jul 2006 11:38:48 -0400 Received: from pwg.org ([192.146.101.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwhYT-0000Kl-0h; Sat, 01 Jul 2006 11:38:48 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k61FcgPG010252; Sat, 1 Jul 2006 11:38:44 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k61FcgNq010249; Sat, 1 Jul 2006 11:38:42 -0400 Received: by pwg.org (bulk_mailer v1.13); Sat, 1 Jul 2006 11:36:21 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k61FaIqa009852 for ; Sat, 1 Jul 2006 11:36:20 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k61FaIT6009849 for pwg-announce-out; Sat, 1 Jul 2006 11:36:18 -0400 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE59@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'pwg-announce@pwg.org'" Subject: PWG-ANNOUNCE> BMLinkS muiltifunction services model Date: Sat, 1 Jul 2006 08:35:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pwg-announce@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi, At Ron Bergman's request, I'm resending to the top-level PWG reflector. BMLinkS (Business Machine Linkage Service) is a project of JBMIA (Japanese Business Machine and Information System Industries Association) - English home page at: http://www.jbmia.or.jp/bmlinks/eng/intro/index.htm The latest BMLinkS specifications are available at: http://www.jbmia.or.jp/bmlinks/eng/downloads/spc_download.htm Read the "BMLinkS Basic Specification" first. There are also specs for Discovery, Job/Device Control, and Data Format. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.8/380 - Release Date: 6/30/2006 From pwg-announce-owner@pwg.org Mon Jul 10 17:20:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G03BL-0002e0-73; Mon, 10 Jul 2006 17:20:43 -0400 Received: from www.pwg.org ([192.146.101.49] helo=pwg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03BI-00088s-OJ; Mon, 10 Jul 2006 17:20:43 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6ALKcWY002209; Mon, 10 Jul 2006 17:20:40 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6ALKbNf002205; Mon, 10 Jul 2006 17:20:38 -0400 Received: by pwg.org (bulk_mailer v1.13); Mon, 10 Jul 2006 17:18:16 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6ALIC5H001765 for ; Mon, 10 Jul 2006 17:18:14 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6ALICej001762 for pwg-announce-out; Mon, 10 Jul 2006 17:18:12 -0400 From: wamwagner@comcast.net To: pwg-announce@pwg.org (PWG announce) Subject: PWG-ANNOUNCE> Reminder - Call for Objections CIM Phase 1 Documents Date: Mon, 10 Jul 2006 21:17:58 +0000 Message-Id: <071020062117.5136.44B2C4060000B6010000141022165514069D0A02090E99030E99@comcast.net> X-Mailer: AT&T Message Center Version 1 (Apr 11 2006) X-Authenticated-Sender: d2Ftd2FnbmVyQGNvbWNhc3QubmV0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_5136_1152566278_0" Sender: owner-pwg-announce@pwg.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 --NextPart_Webmail_9m3u9jl4l_5136_1152566278_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Just a reminder that the call for objections to the remaining proposed Phase 1 changes to DMTF/CIM printing related documents ends 13 July. Bill Wagner ======================================================= In conjunction with the Printer Working Group alliance with the DMTF to update and correct the documentation of printing related classes in the DMTF Common Information Model (CIM), the PWG/CIM Realignment Project of the WIMS WG has been developing PWG descriptive documenrs and DMTF CIM Change Requests. This activity has proceeded with the approach of first identifying and providing a DMTF change request for the Printer Class document, CIM_Printer.mof. These changes were presented to the PWG for objections in March of this year. There were no objections and the Change Request was presented to and essentially accepted by DMTF CIM Core. The PWG/CIM Realignment Project has completed the next set of change documents addressing Phase 1 level changes to additional Printer related classes. This message is to alert the PWG to these documents with a Call for Objections (as defined in the PWG Process document). The PWG CIM Printing Editorial Refresh v1.0 (18 June 2006) document at PWG CIM Printing Refresh working document (ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimscimprint10-20060618.htm) is an explanatory text identifying the problem areas in the CIM Printer related class documents and defining appropriate changes. The following list identifies CIM classes to be changed and drafts of Change Requests (CR) to be submitted to DMTF for changes to the CIM Printer related mof?s in CIMv2.11. Note that content of the changes is completely defined in the PWG CIM Printing Refresh text; the CRs are DMTF documents to be submitted to the DMTF CIM CORE group for review and approval prior to update of the CIM_Printer.mof . -OwningPrintQueue: ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-OwningPrintQueue-060614.htm -PrintJob: ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintJob-060614.htm -PrintQueue: ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintQueue-060616.htm -CPrintSAP: ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintSAP-060619.htm -PrintService: ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintService-060619.htm -PrinterServicingJob: ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-CIM_PrinterServicingJob-060620.htm This Call for Objections announcement is to alert PWG members of the changes that the PWG is requesting to CIM Printer related classes, as well as to provide background for these changes, and to ensure that the PWG membership has the opportunity to voice objections to the requested changes. The Call for Objections will be open until Thursday, 13 July. Please submit any objections to the PWG mailing list (pwg@pwg.org), not to this Announce list. These documents will be discussed at the WIMS/CIM Session of the June 23 face-to-face. William A. Wagner, Chairman WIMS WG/PWG --NextPart_Webmail_9m3u9jl4l_5136_1152566278_0 Content-Type: text/html Content-Transfer-Encoding: 8bit

Just a reminder that the call for objections to the remaining proposed Phase 1 changes to DMTF/CIM printing related documents ends 13 July.

Bill Wagner

=======================================================

In conjunction with the Printer Working Group alliance with the DMTF to update and correct the documentation of printing related classes in the DMTF Common Information Model (CIM), the PWG/CIM Realignment Project of the WIMS WG has been developing PWG descriptive documenrs and DMTF CIM Change Requests. This activity has proceeded with the approach of first identifying and providing a DMTF change request for the Printer Class document, CIM_Printer.mof. These changes were presented to the PWG for objections in March of this year. There were no objections and the Change Request was presented to and essentially accepted by DMTF CIM Core.

The PWG/CIM Realignment Project has completed the next set of change documents addressing Phase 1 level changes to additional Printer related classes. This message is to alert the PWG to these documents with a Call for Objections (as defined in the PWG Process document).

The PWG CIM Printing Editorial Refresh v1.0 (18 June 2006) document at PWG CIM Printing Refresh working document (ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimscimprint10-20060618.htm) is an explanatory text identifying the problem areas in the CIM Printer related class documents and defining appropriate changes.

The following list identifies CIM classes to be changed and drafts of Change Requests (CR) to be submitted to DMTF for changes to the CIM Printer related mof?s in CIMv2.11. Note that content of the changes is completely defined in the PWG CIM Printing Refresh text; the CRs are DMTF documents to be submitted to the DMTF CIM CORE group for review and approval prior to update of the CIM_Printer.mof .

-OwningPrintQueue:
ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-OwningPrintQueue-060614.htm

-PrintJob:
ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintJob-060614.htm

-PrintQueue:
ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintQueue-060616.htm

-CPrintSAP:
ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintSAP-060619.htm

-PrintService:
ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-PrintService-060619.htm

-PrinterServicingJob:
ftp://ftp.pwg.org/pub/pwg/wims/wd/CIMCoreCR-CIM_PrinterServicingJob-060620.htm
This Call for Objections announcement is to alert PWG members of the changes that the PWG is requesting to CIM Printer related classes, as well as to provide background for these changes, and to ensure that the PWG membership has the opportunity to voice objections to the requested changes. The Call for Objections will be open until Thursday, 13 July.

Please submit any objections to the PWG mailing list (pwg@pwg.org), not to this Announce list. These documents will be discussed at the WIMS/CIM Session of the June 23 face-to-face.


William A. Wagner, Chairman WIMS WG/PWG

--NextPart_Webmail_9m3u9jl4l_5136_1152566278_0-- From ipp-owner@pwg.org Mon Jul 17 17:27:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ad3-0006dg-SR for ipp-archive@lists.ietf.org; Mon, 17 Jul 2006 17:27:49 -0400 Received: from pwg.org ([192.146.101.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ad2-0004Zn-Js for ipp-archive@lists.ietf.org; Mon, 17 Jul 2006 17:27:49 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6HLRklw019486 for ; Mon, 17 Jul 2006 17:27:48 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6HLRjeM019483 for ; Mon, 17 Jul 2006 17:27:46 -0400 Received: by pwg.org (bulk_mailer v1.13); Mon, 17 Jul 2006 17:26:42 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6HLQYaP019289 for ; Mon, 17 Jul 2006 17:26:36 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6HLQYfp019286 for ipp-outgoing; Mon, 17 Jul 2006 17:26:34 -0400 Received: from mail2.sharplabs.com (mail2.sharplabs.com [216.65.151.51]) by pwg.org with ESMTP id k6HLQV4L019271 for ; Mon, 17 Jul 2006 17:26:33 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id BCCA21E13F3 for ; Mon, 17 Jul 2006 14:26:30 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Jul 2006 14:26:30 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE7D@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'ipp@pwg.org'" Subject: IPP> Posted draft IPP Printer State Reasons Extensions (17 July 2006) Date: Mon, 17 Jul 2006 14:26:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi folks, Monday (17 July 2006) I've just posted the first draft of the PWG IPP Printer State Reasons Extensions specification on the PWG FTP server at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm This draft is technically complete (to the best of my ability) except for the summary conformance sections (individual sections already have detailed conformance requirements). For immediate review, comment on the IPP WG mailing list (ipp@pwg.org), and discussion at an IPP WG Telecon as soon as possible. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/389 - Release Date: 7/14/2006 From ipp-owner@pwg.org Mon Jul 17 18:31:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2bcX-00036s-0R for ipp-archive@lists.ietf.org; Mon, 17 Jul 2006 18:31:21 -0400 Received: from www.pwg.org ([192.146.101.49] helo=pwg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2bcV-0000T0-Mi for ipp-archive@lists.ietf.org; Mon, 17 Jul 2006 18:31:20 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6HMVHES022964 for ; Mon, 17 Jul 2006 18:31:19 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6HMVHAb022961 for ; Mon, 17 Jul 2006 18:31:17 -0400 Received: by pwg.org (bulk_mailer v1.13); Mon, 17 Jul 2006 18:30:19 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6HMUF2f022763 for ; Mon, 17 Jul 2006 18:30:17 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6HMUFrc022760 for ipp-outgoing; Mon, 17 Jul 2006 18:30:15 -0400 Received: from dns.easysw.com (dns.easysw.com [65.120.94.1]) by pwg.org with SMTP id k6HMUC3S022756 for ; Mon, 17 Jul 2006 18:30:15 -0400 Received: from [192.168.2.102] (gmp-inet23-152.gmpexpress.net [72.9.23.152]) by dns.easysw.com (Postfix) with SMTP id 0594015A1CE; Mon, 17 Jul 2006 18:30:11 -0400 (EDT) Message-ID: <44BC0F72.4030803@easysw.com> Date: Mon, 17 Jul 2006 18:30:10 -0400 From: Michael Sweet Organization: Easy Software Products User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "McDonald, Ira" CC: "'ipp@pwg.org'" Subject: Re: IPP> Posted draft IPP Printer State Reasons Extensions (17 July 2006) References: <789E617C880666438EDEE30C2A3E8D10EE7D@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EE7D@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 McDonald, Ira wrote: > Hi folks, Monday (17 July 2006) > > I've just posted the first draft of the PWG IPP Printer State Reasons > Extensions specification on the PWG FTP server at: > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm > > This draft is technically complete (to the best of my ability) except > for the summary conformance sections (individual sections already have > detailed conformance requirements). > > For immediate review, comment on the IPP WG mailing list (ipp@pwg.org), > and discussion at an IPP WG Telecon as soon as possible. WRT section 5.1.1, CUPS implements the severity suffixes as required by RFC 2911. I don't think we can just do away with them, but defining a mapping from keyword-suffix to keyword would have the equivalent effect without requiring an update of RFC 2911... Also, I know I get "media-tray-empty-error" and other messages from HP printers via IPP, so we're not the only company implementing it... Also, overloading printer-state-message with non-localized alert object data is, IMHO, the wrong approach. Define a printer-alert 1setOf collection that contains all of the prtAlert* objects. CUPS uses printer-state-message to hold the human-readable state message (as defined by RFC 2911), and it would be impossible for CUPS to conform to this spec if you use printer-state-message for this purpose. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com From ipp-owner@pwg.org Tue Jul 18 12:16:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sFi-0000UK-Gk for ipp-archive@lists.ietf.org; Tue, 18 Jul 2006 12:16:54 -0400 Received: from pwg.org ([192.146.101.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2sFh-0003GU-3q for ipp-archive@lists.ietf.org; Tue, 18 Jul 2006 12:16:54 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6IGGott019342 for ; Tue, 18 Jul 2006 12:16:52 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6IGGoD0019339 for ; Tue, 18 Jul 2006 12:16:50 -0400 Received: by pwg.org (bulk_mailer v1.13); Tue, 18 Jul 2006 12:15:46 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6IGFbe9019129 for ; Tue, 18 Jul 2006 12:15:39 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6IGFbuk019126 for ipp-outgoing; Tue, 18 Jul 2006 12:15:37 -0400 Received: from mail2.sharplabs.com (mail2.sharplabs.com [216.65.151.51]) by pwg.org with ESMTP id k6IGFYP7019122 for ; Tue, 18 Jul 2006 12:15:37 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 3FC461E14AB; Tue, 18 Jul 2006 09:15:34 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 Jul 2006 09:15:34 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE7E@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'Michael Sweet'" Cc: "'ipp@pwg.org'" Subject: RE: IPP> Posted draft IPP Printer State Reasons Extensions (17 Ju ly 2006) Date: Tue, 18 Jul 2006 09:15:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Hi Michael, What I've written up, using keyword/value pairs in "printer-state-message", was explicitly approved in the charter for this work by the PWG Steering Committee. My collaborators at Sharp need a solution that does NOT rely on the 'collection' datatype (which is not supported in their IPP implementations nor planned for future support). When the IPP PSX charter was sent out for review, we requested feedback on the approaches - you've made a reasonable case for leaving the severity suffixes alone (some HP printers and CUPS have implemented them) - unfortunately, none of the PWG Steering Committee members were aware of those implementations before - so this is good feedback. We'll see what further review on the mailing list yields, but a 'collection' approach is not going to be acceptable to Sharp (who are funding my work on this project), so other approaches (e.g., a keyword/value encoding in a new simple text attribute) should also be considered. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Michael Sweet [mailto:mike@easysw.com] > Sent: Monday, July 17, 2006 6:30 PM > To: McDonald, Ira > Cc: 'ipp@pwg.org' > Subject: Re: IPP> Posted draft IPP Printer State Reasons > Extensions (17 > July 2006) > > > McDonald, Ira wrote: > > Hi folks, Monday > (17 July 2006) > > > > I've just posted the first draft of the PWG IPP Printer > State Reasons > > Extensions specification on the PWG FTP server at: > > > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm > > > > This draft is technically complete (to the best of my > ability) except > > for the summary conformance sections (individual sections > already have > > detailed conformance requirements). > > > > For immediate review, comment on the IPP WG mailing list > (ipp@pwg.org), > > and discussion at an IPP WG Telecon as soon as possible. > > WRT section 5.1.1, CUPS implements the severity suffixes as required > by RFC 2911. I don't think we can just do away with them, but > defining a mapping from keyword-suffix to keyword would have the > equivalent effect without requiring an update of RFC 2911... Also, > I know I get "media-tray-empty-error" and other messages from HP > printers via IPP, so we're not the only company implementing it... > > Also, overloading printer-state-message with non-localized alert > object data is, IMHO, the wrong approach. Define a printer-alert > 1setOf collection that contains all of the prtAlert* objects. CUPS > uses printer-state-message to hold the human-readable state message > (as defined by RFC 2911), and it would be impossible for CUPS to > conform to this spec if you use printer-state-message for this > purpose. > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mike at easysw dot com > Internet Printing and Publishing Software http://www.easysw.com > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/390 - Release Date: 7/17/2006 From ipp-owner@pwg.org Tue Jul 18 15:25:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vCR-0001LD-Ko for ipp-archive@lists.ietf.org; Tue, 18 Jul 2006 15:25:43 -0400 Received: from pwg.org ([192.146.101.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2vCQ-0002gu-3P for ipp-archive@lists.ietf.org; Tue, 18 Jul 2006 15:25:43 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6IJPdWV024424 for ; Tue, 18 Jul 2006 15:25:41 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6IJPdow024421 for ; Tue, 18 Jul 2006 15:25:39 -0400 Received: by pwg.org (bulk_mailer v1.13); Tue, 18 Jul 2006 15:24:29 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6IJOPjN024219 for ; Tue, 18 Jul 2006 15:24:27 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6IJOPM4024216 for ipp-outgoing; Tue, 18 Jul 2006 15:24:25 -0400 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by pwg.org with ESMTP id k6IJOLxt024212 for ; Tue, 18 Jul 2006 15:24:24 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 18 Jul 2006 13:24:17 -0600 Message-Id: <44BCE106.196D.00A2.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 18 Jul 2006 13:24:12 -0600 From: "Ted Tronson" To: Subject: Re: IPP> Posted draft IPP Printer State Reasons Extensions (17 July 2006) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartE8CD1C4C.0__=" Sender: owner-ipp@pwg.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --=__PartE8CD1C4C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit We also rely upon the severity suffixes and make use them in our iPrint print system as required by RFC 2911. So deprecating them would be bad for us and our installed base. What is wrong with just using the report suffix on these values? We currently don't use the printer-state-message attribute, but it was meant for human readable strings. We would not be inclined to use a collection mechanism for the prtAlert objects. There must be a better way to do this. McDonald, Ira wrote: > Hi folks, Monday (17 July 2006) > > I've just posted the first draft of the PWG IPP Printer State Reasons > Extensions specification on the PWG FTP server at: > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm > > This draft is technically complete (to the best of my ability) except > for the summary conformance sections (individual sections already have > detailed conformance requirements). > > For immediate review, comment on the IPP WG mailing list (ipp@pwg.org), > and discussion at an IPP WG Telecon as soon as possible. WRT section 5.1.1, CUPS implements the severity suffixes as required by RFC 2911. I don't think we can just do away with them, but defining a mapping from keyword-suffix to keyword would have the equivalent effect without requiring an update of RFC 2911... Also, I know I get "media-tray-empty-error" and other messages from HP printers via IPP, so we're not the only company implementing it... Also, overloading printer-state-message with non-localized alert object data is, IMHO, the wrong approach. Define a printer-alert 1setOf collection that contains all of the prtAlert* objects. CUPS uses printer-state-message to hold the human-readable state message (as defined by RFC 2911), and it would be impossible for CUPS to conform to this spec if you use printer-state-message for this purpose. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com Ted Tronson Sr. Software Engineer iPrint Engineering ttronson@novell.com 801-861-3338 --=__PartE8CD1C4C.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML
We also rely upon the severity suffixes and make use them in our iPrint print system as required by RFC 2911.  So deprecating them would be bad for us and our installed base.  What is wrong with just using the report suffix on these values?
 
We currently don't use the printer-state-message attribute, but it was meant for human readable strings.  We would not be inclined to use a collection mechanism for the prtAlert objects.  There must be a better way to do this.
 
 
McDonald, Ira wrote:
> Hi folks,                                          Monday (17 July 2006)
>
> I've just posted the first draft of the PWG IPP Printer State Reasons
> Extensions specification on the PWG FTP server at:
>
>     ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm
>
> This draft is technically complete (to the best of my ability) except
> for the summary conformance sections (individual sections already have
> detailed conformance requirements).
>
> For immediate review, comment on the IPP WG mailing list (ipp@pwg.org),
> and discussion ! at an IPP WG Telecon as soon as possible.
 
WRT section 5.1.1, CUPS implements the severity suffixes as required
by RFC 2911.  I don't think we can just do away with them, but
defining a mapping from keyword-suffix to keyword would have the
equivalent effect without requiring an update of RFC 2911...  Also,
I know I get "media-tray-empty-error" and other messages from HP
printers via IPP, so we're not the only company implementing it...
 
Also, overloading printer-state-message with non-localized alert
object data is, IMHO, the wrong approach.  Define a printer-alert
1setOf collection that contains all of the prtAlert* objects.  CUPS
uses printer-state-message to hold the human-readable state message
(as defined by RFC 2911), and it would be impossible for CUPS to
conform to this spec if you use printer-state-message for this
purpose.
 
--
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com
 
 
Ted Tronson
Sr. Software Engineer
iPrint Engineering
ttronson@novell.com
801-861-3338 --=__PartE8CD1C4C.0__=-- From pwg-announce-owner@pwg.org Tue Jul 18 19:37:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2z80-0003dG-3q; Tue, 18 Jul 2006 19:37:24 -0400 Received: from pwg.org ([192.146.101.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2z7y-0000wt-P3; Tue, 18 Jul 2006 19:37:24 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6INbK9X031237; Tue, 18 Jul 2006 19:37:22 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6INbKdG031234; Tue, 18 Jul 2006 19:37:20 -0400 Received: by pwg.org (bulk_mailer v1.13); Tue, 18 Jul 2006 19:35:03 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6INYxlK030443 for ; Tue, 18 Jul 2006 19:35:01 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6INYxkf030440 for pwg-announce-out; Tue, 18 Jul 2006 19:34:59 -0400 In-Reply-To: To: Cc: wims@pwg.org, pwg-announce@pwg.org Subject: PWG-ANNOUNCE> First PWG WIMS/CIM Change Request accepted by DMTF MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Harry Lewis Date: Tue, 18 Jul 2006 17:34:44 -0600 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 07/18/2006 17:34:46, Serialize complete at 07/18/2006 17:34:46 Content-Type: multipart/alternative; boundary="=_alternative 0081765D872571AF_=" Sender: owner-pwg-announce@pwg.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multipart message in MIME format. --=_alternative 0081765D872571AF_= Content-Type: text/plain; charset="US-ASCII" Congratulations! This required a lot of hard work. Thanks to Rick, Ira, Craig, Bill and all who helped out with review and comment. DMTF CIM continues to strengthen its position as a core semantic repository for distributed systems management and the PWG is playing a key role in realigning the print and imaging model in a controlled, step-wise fashion. ---------------------------------------------- Harry Lewis IBM STSM Chairman - IEEE-ISTO Printer Working Group http://www.pwg.org IBM Printing Systems http://www.ibm.com/printers 303-924-5337 ---------------------------------------------- Sent by: owner-wims@pwg.org 07/17/2006 10:29 AM To cc Subject WIMS> CIM> Our first CR passed the DMTF TC, ta-da! The first PWG CR in the CIM alignment effort has passed the DMTF Technical Committee (5 to 0), and will be incorporated in the next released version of the CIM schema. Congrats to all involved! The next six are in the process cycle, too. Those complete Phase 1. And we are beginning work on the next phase. rick PS: It took weeks for me to discover the results of the TC vote. I have suggested several process improvements to them to speed notification to the originator of the CR. ---------------------- Richard_Landau(at)dell(dot)com, Stds & System Mgt Arch, CTO Office +1-512-728-9023, One Dell Way, RR5-3 MS 8509, Round Rock, TX 78682 --=_alternative 0081765D872571AF_= Content-Type: text/html; charset="US-ASCII"
Congratulations! This required a lot of hard work. Thanks to Rick, Ira, Craig, Bill and all who helped out with review and comment.
DMTF CIM continues to strengthen its position as a core semantic repository for distributed systems management and the PWG is playing a key role in realigning the print and imaging model in a controlled, step-wise fashion.  
----------------------------------------------
Harry Lewis
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems
http://www.ibm.com/printers
303-924-5337
----------------------------------------------


<Richard_Landau@Dell.com>
Sent by: owner-wims@pwg.org

07/17/2006 10:29 AM

To
<wims@pwg.org>
cc
Subject
WIMS> CIM> Our first CR passed the DMTF TC, ta-da!





The first PWG CR in the CIM alignment effort has passed the DMTF Technical Committee (5 to 0), and will be incorporated in the next released version of the CIM schema.  Congrats to all involved!

The next six are in the process cycle, too.  Those complete Phase 1.  And we are beginning work on the next phase.  

rick

PS: It took weeks for me to discover the results of the TC vote.  I have suggested several process improvements to them to speed notification to the originator of the CR.  

----------------------
Richard_Landau(at)dell(dot)com, Stds & System Mgt Arch, CTO Office
+1-512-728-9023, One Dell Way, RR5-3 MS 8509, Round Rock, TX 78682

--=_alternative 0081765D872571AF_=-- From ipp-owner@pwg.org Tue Jul 18 20:43:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G30AD-000139-TV for ipp-archive@lists.ietf.org; Tue, 18 Jul 2006 20:43:45 -0400 Received: from www.pwg.org ([192.146.101.49] helo=pwg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G30AC-0004xt-KK for ipp-archive@lists.ietf.org; Tue, 18 Jul 2006 20:43:45 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6J0hgfE004406 for ; Tue, 18 Jul 2006 20:43:44 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6J0hgfi004403 for ; Tue, 18 Jul 2006 20:43:42 -0400 Received: by pwg.org (bulk_mailer v1.13); Tue, 18 Jul 2006 20:42:42 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6J0gcUM004189 for ; Tue, 18 Jul 2006 20:42:40 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6J0gcLB004186 for ipp-outgoing; Tue, 18 Jul 2006 20:42:38 -0400 Received: from exchange2k.rpsa.ricoh.com (mail.rpsa.ricoh.com [192.101.159.107]) by pwg.org with ESMTP id k6J0gA7w004179 for ; Tue, 18 Jul 2006 20:42:12 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AACC.2B135398" Subject: IPP> Printer State Reasons Teleconference, July 20, 2006, 11:00 AM EDT X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 18 Jul 2006 17:42:09 -0700 Message-ID: <41A3AA9A3516CB418C179FFDEF9E5A82154966@exchange2k.hitachi-ps.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Printer State Reasons Teleconference, July 20, 2006, 11:00 AM EDT Thread-Index: AcaqzCsSZabsepJyR0ixARNSUnW5kA== From: "Bergman, Ron" To: Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AACC.2B135398 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The first IPP Printer State Reasons Teleconference will be held this = Thursday at 11:00 AM EDT (8:00 AM PDT) We will review the first draft of the PWG IPP Printer State Reasons = Extensions specification which can be found at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm =20 To participate in the meeting call: 1-866-365-4406 Passcode: 2635888# Ron Bergman IPP Working Group Chairman ------_=_NextPart_001_01C6AACC.2B135398 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Printer State Reasons Teleconference, July 20, 2006, 11:00 AM = EDT

The first IPP Printer State Reasons = Teleconference will be held this Thursday at 11:00 AM EDT (8:00 AM = PDT)

We will review the first draft of the = PWG IPP Printer State Reasons Extensions specification which can be = found at:

     ftp:= //ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm
 

To participate in the meeting = call:

1-866-365-4406
Passcode: 2635888#

        Ron Bergman
        IPP Working Group Chairman

------_=_NextPart_001_01C6AACC.2B135398-- From ipp-owner@pwg.org Wed Jul 19 14:44:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3H1z-0000Gs-5o for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 14:44:23 -0400 Received: from www.pwg.org ([192.146.101.49] helo=pwg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3H1x-0000xk-Qo for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 14:44:23 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JIiJgR001374 for ; Wed, 19 Jul 2006 14:44:21 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6JIiIan001371 for ; Wed, 19 Jul 2006 14:44:19 -0400 Received: by pwg.org (bulk_mailer v1.13); Wed, 19 Jul 2006 14:43:16 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JIh7oq001176 for ; Wed, 19 Jul 2006 14:43:09 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6JIh7pm001173 for ipp-outgoing; Wed, 19 Jul 2006 14:43:07 -0400 Received: from mail2.sharplabs.com (mail2.sharplabs.com [216.65.151.51]) by pwg.org with ESMTP id k6JIh4O2001168 for ; Wed, 19 Jul 2006 14:43:07 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 2391A1E14E9 for ; Wed, 19 Jul 2006 11:43:04 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Jul 2006 11:43:04 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE82@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'ipp@pwg.org'" Subject: IPP> Four IPP methods for encoding correlated elements Date: Wed, 19 Jul 2006 11:43:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Hi folks, Wednesday (19 July 2006) As background for tomorrow's teleconference reviewing the first draft of PWG IPP Printer State Reasons Extensions, below is a summary of the four available methods in IPP to represent correlated elements (e.g., various columnar object values from a specific 'prtAlertTable' entry). Note that the IPP Printer State Reasons Extensions MUST be practical for easy addition to ALL of the existing IPP implementations, or else such a standardized approach is not cost effective (to specify or implement). Method (1) below was chosen for our first draft IPP PSX spec because it requires NO new IPP atrributes (uses existing "printer-state-reasons" and "printer-state-message") and thus is immediately available in all existing IPP client implementations - this is very important to Sharp. Cheers, - Ira (co-editor of PWG IPP Printer State Reasons Extensions) Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com ------------------------------------------------------------------------ (1) Method: Structured encoding in a single string Example: From IPP Printer Installation Extension (ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/ draft-ietf-ipp-install-04.txt) "client-print-support-files-supported (1setOf octetString(MAX))" Remarks: In practice, localized elements can't be supported with reliable interoperability - but this has no importance for the current IPP PSX spec. (2) Method: Parallel ordered multi-valued attributes Example: From IPP/1.1 Model and Semantics (ftp://ftp.isi.edu/in-notes/ rfc2911.txt) "printer-uri-supported (1setOf uri)" "uri-authentication-supported (1setOf type2 keyword)" "uri-security-supported (1setOf type2 keyword) Remarks: The '1setOf X' datatype (section 4.1.16 of RFC2911) is fragile for interoperability, because IPP/1.1 states: "Sets are normally unordered. However each attribute description of this type may specify that the values MUST be in a certain order for that attribute." In practice, this means that a generic IPP parser MUST NOT be order-preserving, thus the inherent fragility. (3) Method: Members in an IPP 'collection' attribute (per RFC 3382) Example: From IPP Production Printing Attributes - Set1 (ftp://ftp.pwg.org/pub/pwg/candidates/ cs-ippprodprint10-20010212-5100.3.pdf) "media-col (collection)" "media-type (type3 keyword | name(MAX))" "media-info (text(255))" Remarks: The 'collection' datatype is NOT a base IPP/1.1 type, but rather an extension - which has NOT been demonstrated to be interoperable across various IPP parser implementations. The 'collection' datatype is NOT supported in the majority of existing IPP/1.1 implementations from various vendors. There are no known implementations of 'collection' datatype in IPP/1.0 implementations - many network printers ONLY support the protocol/datatypes in IPP/1.0 (RFC 2565/2566). (4) Method: Attributes in a new first-class IPP object Example: From IPP Document Object (ftp://ftp.pwg.org/pub/pwg/candidates/ cs-ippdocobject10-20031031-5100.5.pdf) "document-charset (charset)" "document-format (mimeMediaType)" Remarks: The Document object is the ONLY object that has ever been defined to extend IPP/1.1 - there has never been an IPP bakeoff to demonstrate interoperability of this object. There was a strong resistance among former IPP editors to the definition of new first-class IPP objects - which was the specific justification for the introduction of the 'collection' datatype - this is not a practical approach. ------------------------------------------------------------------------ -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006 From ipp-owner@pwg.org Wed Jul 19 15:40:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Htr-0006bf-Vn for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 15:40:03 -0400 Received: from www.pwg.org ([192.146.101.49] helo=pwg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Htp-0000iU-5j for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 15:40:03 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JJdwEV004582 for ; Wed, 19 Jul 2006 15:40:00 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6JJdwoe004579 for ; Wed, 19 Jul 2006 15:39:58 -0400 Received: by pwg.org (bulk_mailer v1.13); Wed, 19 Jul 2006 15:38:56 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JJcq2a004383 for ; Wed, 19 Jul 2006 15:38:54 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6JJcqfA004380 for ipp-outgoing; Wed, 19 Jul 2006 15:38:52 -0400 Received: from sinclair.provo.novell.com (sinclair.provo.novell.com [137.65.81.169]) by pwg.org with ESMTP id k6JJcn0l004373 for ; Wed, 19 Jul 2006 15:38:51 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 19 Jul 2006 13:38:44 -0600 Message-Id: <44BE35E9.196D.00A2.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 19 Jul 2006 13:38:37 -0600 From: "Ted Tronson" To: "'ipp@pwg.org'" , "Ira McDonald" Subject: Re: IPP> Four IPP methods for encoding correlated elements References: <789E617C880666438EDEE30C2A3E8D10EE82@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EE82@mailsrvnt05.enet.sharplabs.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part3510C22D.0__=" Sender: owner-ipp@pwg.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 --=__Part3510C22D.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I will be unable to attend the meeting tomorrow. But just to give my two cents worth, I would be ok with option 1 or 2 >>> "McDonald, Ira" 7/19/2006 12:43 PM >>> Hi folks, Wednesday (19 July 2006) As background for tomorrow's teleconference reviewing the first draft of PWG IPP Printer State Reasons Extensions, below is a summary of the four available methods in IPP to represent correlated elements (e.g., various columnar object values from a specific 'prtAlertTable' entry). Note that the IPP Printer State Reasons Extensions MUST be practical for easy addition to ALL of the existing IPP implementations, or else such a standardized approach is not cost effective (to specify or implement). Method (1) below was chosen for our first draft IPP PSX spec because it requires NO new IPP atrributes (uses existing "printer-state-reasons" and "printer-state-message") and thus is immediately available in all existing IPP client implementations - this is very important to Sharp. Cheers, - Ira (co-editor of PWG IPP Printer State Reasons Extensions) Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com ------------------------------------------------------------------------ (1) Method: Structured encoding in a single string Example: From IPP Printer Installation Extension (ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/ draft-ietf-ipp-install-04.txt) "client-print-support-files-supported (1setOf octetString(MAX))" Remarks: In practice, localized elements can't be supported with reliable interoperability - but this has no importance for the current IPP PSX spec. (2) Method: Parallel ordered multi-valued attributes Example: From IPP/1.1 Model and Semantics (ftp://ftp.isi.edu/in-notes/ rfc2911.txt) "printer-uri-supported (1setOf uri)" "uri-authentication-supported (1setOf type2 keyword)" "uri-security-supported (1setOf type2 keyword) Remarks: The '1setOf X' datatype (section 4.1.16 of RFC2911) is fragile for interoperability, because IPP/1.1 states: "Sets are normally unordered. However each attribute description of this type may specify that the values MUST be in a certain order for that attribute." In practice, this means that a generic IPP parser MUST NOT be order-preserving, thus the inherent fragility. (3) Method: Members in an IPP 'collection' attribute (per RFC 3382) Example: From IPP Production Printing Attributes - Set1 (ftp://ftp.pwg.org/pub/pwg/candidates/ cs-ippprodprint10-20010212-5100.3.pdf) "media-col (collection)" "media-type (type3 keyword | name(MAX))" "media-info (text(255))" Remarks: The 'collection' datatype is NOT a base IPP/1.1 type, but rather an extension - which has NOT been demonstrated to be interoperable across various IPP parser implementations. The 'collection' datatype is NOT supported in the majority of existing IPP/1.1 implementations from various vendors. There are no known implementations of 'collection' datatype in IPP/1.0 implementations - many network printers ONLY support the protocol/datatypes in IPP/1.0 (RFC 2565/2566). (4) Method: Attributes in a new first-class IPP object Example: From IPP Document Object (ftp://ftp.pwg.org/pub/pwg/candidates/ cs-ippdocobject10-20031031-5100.5.pdf) "document-charset (charset)" "document-format (mimeMediaType)" Remarks: The Document object is the ONLY object that has ever been defined to extend IPP/1.1 - there has never been an IPP bakeoff to demonstrate interoperability of this object. There was a strong resistance among former IPP editors to the definition of new first-class IPP objects - which was the specific justification for the introduction of the 'collection' datatype - this is not a practical approach. ------------------------------------------------------------------------ -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006 --=__Part3510C22D.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML I will be unable to attend the meeting tomorrow.  But just to give my two cents worth, I would be ok with option 1 or 2

>>> "McDonald, Ira" <imcdonald@sharplabs.com> 7/19/2006 12:43 PM >>>
Hi folks,                                       Wednesday (19 July 2006)

As background for tomorrow's teleconference reviewing the first draft of
PWG IPP Printer State Reasons Extensions, below is a summary of the four
available methods in IPP to represent correlated elements (e.g., various
columnar object values from a specific 'prtAlertTable' entry).

Note that the IPP Printer State Reasons Extensions MUST be practical for
easy addition to ALL of the existing IPP implementations, or els! e such a
standardized approach is not cost effective (to specify or implement).

Method (1) below was chosen for our first draft IPP PSX spec because it
requires NO new IPP atrributes (uses existing "printer-state-reasons"
and "printer-state-message") and thus is immediately available in all
existing IPP client implementations - this is very important to Sharp.

Cheers,
- Ira (co-editor of PWG IPP Printer State Reasons Extensions)


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

------------------------------------------------------------------------

(1) Method:  Structured encoding in a single string

    Example: From IPP Printer Installation Extension
               (ftp://ftp.pwg.org! /pub/pwg/ipp/new_DRV/
      &! nbsp;&nb sp;         draft-ietf-ipp-install-04.txt)
             "client-print-support-files-supported (1setOf
               octetString(MAX))"

    Remarks: In practice, localized elements can't be supported with
             reliable interoperability - but this has no importance for
             the current IPP PSX spec.


(2) Method:  Parallel ordered multi-valued attributes

    Example: From IPP/1.1 Model and Semantics
               (ftp://ftp.isi.edu/in-notes/
               &! nbsp; rfc2911.txt)
             "printer-uri-supported (1setOf uri)"
             "uri-authentication-supported (1setOf type2 keyword)"
             "uri-security-supported (1setOf type2 keyword)

    Remarks: The '1setOf X' datatype (section 4.1.16 of RFC2911) is
             fragile for interoperability, because IPP/1.1 states:

               "Sets are normally unordered.  However each attribute
               description of this type may specify that the values
               MUS! T be in a certain order for that attribute."

 &nbs! p;            In practice, this means that a generic IPP parser MUST NOT
             be order-preserving, thus the inherent fragility.


(3) Method:  Members in an IPP 'collection' attribute (per RFC 3382)

    Example: From IPP Production Printing Attributes - Set1
               (ftp://ftp.pwg.org/pub/pwg/candidates/
                 cs-ippprodprint10-20010212-5100.3.pdf)
             "media-col (collection)"
               "media-type (type3 keyword | name(MAX))"
              ! ; "media-info (text(255))"

    Remarks: The 'collection' datatype is NOT a base IPP/1.1 type, but
             rather an extension - which has NOT been demonstrated to be
             interoperable across various IPP parser implementations.
             The 'collection' datatype is NOT supported in the majority
             of existing IPP/1.1 implementations from various vendors.
             There are no known implementations of 'collection' datatype
             in IPP/1.0 implementations - many network printers ONLY
          ! ;   support the protocol/datatypes in IPP/1.0 (RFC 2! 565/2566 ).


(4) Method:  Attributes in a new first-class IPP object

    Example: From IPP Document Object
               (ftp://ftp.pwg.org/pub/pwg/candidates/
                 cs-ippdocobject10-20031031-5100.5.pdf)
             "document-charset (charset)"
             "document-format (mimeMediaType)"

    Remarks: The Document object is the ONLY object that has ever been
             defined to extend IPP/1.1 - there has never been an IPP
             bakeoff to demonstrate interoperability of this object.
  &! nbsp;          There was a strong resistance among former IPP editors to
             the definition of new first-class IPP objects - which was
             the specific justification for the introduction of the
             'collection' datatype - this is not a practical approach.

------------------------------------------------------------------------

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006

--=__Part3510C22D.0__=-- From ipp-owner@pwg.org Wed Jul 19 16:26:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Id2-00016D-N1 for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 16:26:44 -0400 Received: from www.pwg.org ([192.146.101.49] helo=pwg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Icz-0000op-5j for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 16:26:44 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JKQcZE007596 for ; Wed, 19 Jul 2006 16:26:40 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6JKQciI007593 for ; Wed, 19 Jul 2006 16:26:38 -0400 Received: by pwg.org (bulk_mailer v1.13); Wed, 19 Jul 2006 16:25:35 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JKPVha007399 for ; Wed, 19 Jul 2006 16:25:33 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6JKPVCG007396 for ipp-outgoing; Wed, 19 Jul 2006 16:25:31 -0400 Received: from dns.easysw.com (dns.easysw.com [65.120.94.1]) by pwg.org with SMTP id k6JKPSDj007391 for ; Wed, 19 Jul 2006 16:25:30 -0400 Received: from [65.120.94.169] (tango.easysw.com [65.120.94.169]) by dns.easysw.com (Postfix) with ESMTP id 9E1D715A1C4; Wed, 19 Jul 2006 16:25:26 -0400 (EDT) Message-ID: <44BE9536.2040503@easysw.com> Date: Wed, 19 Jul 2006 16:25:26 -0400 From: Michael Sweet Organization: Easy Software Products User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Ted Tronson CC: "'ipp@pwg.org'" , Ira McDonald Subject: Re: IPP> Four IPP methods for encoding correlated elements References: <789E617C880666438EDEE30C2A3E8D10EE82@mailsrvnt05.enet.sharplabs.com> <44BE35E9.196D.00A2.0@novell.com> In-Reply-To: <44BE35E9.196D.00A2.0@novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Ted Tronson wrote: > I will be unable to attend the meeting tomorrow. But just to give my > two cents worth, I would be ok with option 1 or 2 Ditto here, as long as we don't use printer-state-message for this purpose. > >>> "McDonald, Ira" 7/19/2006 12:43 PM >>> > Hi folks, Wednesday (19 July 2006) > > As background for tomorrow's teleconference reviewing the first draft of > PWG IPP Printer State Reasons Extensions, below is a summary of the four > available methods in IPP to represent correlated elements (e.g., various > columnar object values from a specific 'prtAlertTable' entry). > > Note that the IPP Printer State Reasons Extensions MUST be practical for > easy addition to ALL of the existing IPP implementations, or els! e such a > standardized approach is not cost effective (to specify or implement). > > Method (1) below was chosen for our first draft IPP PSX spec because it > requires NO new IPP atrributes (uses existing "printer-state-reasons" > and "printer-state-message") and thus is immediately available in all > existing IPP client implementations - this is very important to Sharp. > > Cheers, > - Ira (co-editor of PWG IPP Printer State Reasons Extensions) > > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > ------------------------------------------------------------------------ > > (1) Method: Structured encoding in a single string > > Example: From IPP Printer Installation Extension > (ftp://ftp.pwg.org! /pub/pwg/ipp/new_DRV/ > &! nbsp;&nb sp; draft-ietf-ipp-install-04.txt) > "client-print-support-files-supported (1setOf > octetString(MAX))" > > Remarks: In practice, localized elements can't be supported with > reliable interoperability - but this has no importance for > the current IPP PSX spec. > > > (2) Method: Parallel ordered multi-valued attributes > > Example: From IPP/1.1 Model and Semantics > (ftp://ftp.isi.edu/in-notes/ > &! nbsp; rfc2911.txt) > "printer-uri-supported (1setOf uri)" > "uri-authentication-supported (1setOf type2 keyword)" > "uri-security-supported (1setOf type2 keyword) > > Remarks: The '1setOf X' datatype (section 4.1.16 of RFC2911) is > fragile for interoperability, because IPP/1.1 states: > > "Sets are normally unordered. However each attribute > description of this type may specify that the values > MUS! T be in a certain order for that attribute." > > &nbs! p; In practice, this means that a generic IPP parser > MUST NOT > be order-preserving, thus the inherent fragility. That's a bit strong; a generic IPP parser MAY NOT be order-preserving, which is probably what you meant... :) > > (3) Method: Members in an IPP 'collection' attribute (per RFC 3382) > > Example: From IPP Production Printing Attributes - Set1 > (ftp://ftp.pwg.org/pub/pwg/candidates/ > cs-ippprodprint10-20010212-5100.3.pdf) > "media-col (collection)" > "media-type (type3 keyword | name(MAX))" > ! ; "media-info (text(255))" > > Remarks: The 'collection' datatype is NOT a base IPP/1.1 type, but > rather an extension - which has NOT been demonstrated to be > interoperable across various IPP parser implementations. > The 'collection' datatype is NOT supported in the majority > of existing IPP/1.1 implementations from various vendors. > There are no known implementations of 'collection' datatype > in IPP/1.0 implementations - many network printers ONLY > ! ; support the protocol/datatypes in IPP/1.0 (RFC 2! > 565/2566 ). > > > (4) Method: Attributes in a new first-class IPP object > > Example: From IPP Document Object > (ftp://ftp.pwg.org/pub/pwg/candidates/ > cs-ippdocobject10-20031031-5100.5.pdf) > "document-charset (charset)" > "document-format (mimeMediaType)" > > Remarks: The Document object is the ONLY object that has ever been > defined to extend IPP/1.1 - there has never been an IPP > bakeoff to demonstrate interoperability of this object. > &! nbsp; There was a strong resistance among former IPP > editors to > the definition of new first-class IPP objects - which was > the specific justification for the introduction of the > 'collection' datatype - this is not a practical approach. > > ------------------------------------------------------------------------ > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006 > -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com From ipp-owner@pwg.org Wed Jul 19 19:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3L8a-0002Pf-JL for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 19:07:28 -0400 Received: from pwg.org ([192.146.101.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3L8Z-0002xQ-9d for ipp-archive@lists.ietf.org; Wed, 19 Jul 2006 19:07:28 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JN7O2c012287 for ; Wed, 19 Jul 2006 19:07:26 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6JN7Oj7012284 for ; Wed, 19 Jul 2006 19:07:24 -0400 Received: by pwg.org (bulk_mailer v1.13); Wed, 19 Jul 2006 19:06:25 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6JN6LSm012090 for ; Wed, 19 Jul 2006 19:06:23 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6JN6LqE012087 for ipp-outgoing; Wed, 19 Jul 2006 19:06:21 -0400 Received: from mail2.sharplabs.com (mail2.sharplabs.com [216.65.151.51]) by pwg.org with ESMTP id k6JN6IpD012083 for ; Wed, 19 Jul 2006 19:06:20 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 224F81E14DC for ; Wed, 19 Jul 2006 16:06:18 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 19 Jul 2006 16:06:18 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE84@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'ipp@pwg.org'" Subject: IPP> Ira calling in away-from-home tomorrow Date: Wed, 19 Jul 2006 16:06:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, Many thanks to Ted Tronson and Michael Sweet for their feedback on the IPP WG mailing list - others, please comment, if possible. I have to take my mom 125 miles to Escanaba early tomorrow. I hope to be able to join the IPP WG telecon at 11am EDT via my brother's cellphone or a borrowed landline at a friend's apartment. If I can't make it, PLEASE carry on without me. Note: I cannot attend a rescheduled telecon next on 27 July (but that would conflict with the P2600 meetings anyway). I currently expect to be able to attend on 3 August. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006 From ipp-owner@pwg.org Sat Jul 29 19:58:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6yh3-0005Mj-Ow for ipp-archive@lists.ietf.org; Sat, 29 Jul 2006 19:58:05 -0400 Received: from www.pwg.org ([192.146.101.49] helo=pwg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6yh1-0001bv-AM for ipp-archive@lists.ietf.org; Sat, 29 Jul 2006 19:58:05 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6TNw0dY028234 for ; Sat, 29 Jul 2006 19:58:02 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6TNvwJJ028231 for ; Sat, 29 Jul 2006 19:58:00 -0400 Received: by pwg.org (bulk_mailer v1.13); Sat, 29 Jul 2006 19:56:48 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6TNudV5028036 for ; Sat, 29 Jul 2006 19:56:41 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6TNudXu028033 for ipp-outgoing; Sat, 29 Jul 2006 19:56:39 -0400 Received: from mail2.sharplabs.com (mail2.sharplabs.com [216.65.151.51]) by pwg.org with ESMTP id k6TNuYRp028028 for ; Sat, 29 Jul 2006 19:56:38 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id B57961E14ED for ; Sat, 29 Jul 2006 16:56:29 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jul 2006 16:56:29 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE93@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'ipp@pwg.org'" Subject: IPP> Details on methods for IPP encoding of alerts Date: Sat, 29 Jul 2006 16:56:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Hi folks, Saturday (29 July 2006) At our last IPP WG teleconference, we tentatively converged on methods (1) and (2) from my previous note (sent Wednesday 19 July) as the best candidates for encoding 'prtAlertTable' objects from the Printer MIB into IPP Printer attributes. As background for our next IPP WG teleconference (Thursday 3 August), below are more detailed examples and discussions of methods (1) and (2). Michael Sweet (CUPS) has argued convincingly that putting non-localized data into "printer-state-message (text(MAX))" is non-conformant and Ted Tronson (Novell) has concurred, so the IPP PSX spec must define one or more new IPP Printer attributes (otherwise generic subunit alerts would be meaningless). Note: A hybrid method (1+) below defines two new IPP attributes: "printer-alert (1setOf octetString(MAX))" "printer-alert-description (1setOf text(MAX))" The problem of IPP Printer and Printer MIB instances in different locales is still be present, but vendors who already place message key prefixes in 'prtAlertDescription' (for use by client software) can preserve that functionality. Cheers, - Ira (co-editor of PWG IPP Printer State Reasons Extensions) Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com ------------------------------------------------------------------------ Method 1: Structured encoding in one attribute Compare: IPP Printer Installation Extension (ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/ draft-ietf-ipp-install-04.txt) "client-print-support-files-supported (1setOf octetString(MAX))" IPP PSX Encoding: "printer-alert (1setOf octetString(MAX))" Example: printer-alert[1] = alert-code=jam;alert-index=22;alert-severity=critical ;alert-group=mediaPath;alert-group-index=4;alert-location=6 printer-alert[2] = alert-code=coverOpen;alert-index=23;alert-severity=critical ;alert-group=cover;alert-group-index=6;alert-location=2 Remarks: (1) Because the IPP datatype '1setOf' does NOT allow an empty array, an empty 'prtAlertTable' MUST be represented by a _missing_ IPP attribute "printer-alert" - an empty attribute would be illegal. (2) Because IPP Printer object and Printer MIB instances MAY be set to different current locales and 'prtAlertDescription' values MUST be server localized (i.e., are NOT machine-readable by client software), localized alert descriptions CANNOT be interoperably supported - but this is currently out-of-scope for the IPP PSX spec. ------------------------------------------------------------------------ Method 1+: Structured encoding plus a paralllel description attribute Compare: See method (1) above and method (2) below IPP PSX Encoding: "printer-alert (1setOf octetString(MAX))" "printer-alert-description (1setOf text(MAX))" Example: printer-alert[1] = alert-code=jam;alert-index=22;alert-severity=critical ;alert-group=mediaPath;alert-group-index=4;alert-location=6 printer-alert[2] = alert-code=coverOpen;alert-index=23;alert-severity=critical ;alert-group=cover;alert-group-index=6;alert-location=2 printer-alert-description[1] = XL1400.MP0036 Critical alert - jam in duplex printing media path printer-alert-description[2] = XL1400.CV0042 Critical alert - top right front cover is open Remarks: (1) Because the IPP datatype '1setOf' does NOT allow an empty array, an empty 'prtAlertTable' MUST be represented by a _missing_ IPP attribute "printer-alert" - an empty attribute would be illegal. (2) The common practice of overloading 'prtAlertLocation' to contain a message key forces vendors to coordinate message catalogs across all models of network printers - not practical. The use of imbedded message keys in 'prtAlertDescription', on the other hand, allows vendors to decentralize message catalogs to product families or individual models - matching current product localization practice. (3) Because IPP Printer object and Printer MIB instances MAY be set to different current locales and 'prtAlertDescription' values MUST be server localized (i.e., are NOT machine-readable by client software), an implementation mechanism like imbedded message keys is still needed for an IPP Printer to convert the locale of alert descriptions without brute force message catalog searches. ------------------------------------------------------------------------ Method 2: Parallel ordered multi-valued attributes Compare: From IPP/1.1 Model and Semantics (ftp://ftp.isi.edu/in-notes/ rfc2911.txt) "printer-uri-supported (1setOf uri)" "uri-authentication-supported (1setOf type2 keyword)" "uri-security-supported (1setOf type2 keyword) IPP PSX Encoding: "printer-alert-code (1setOf keyword)" "printer-alert-code (1setOf integer)" -- not human-readable "printer-alert-index (1setOf integer)" "printer-alert-index (1setOf octetString(MAX))" -- not useful "printer-alert-severity (1setOf keyword)" "printer-alert-severity (1setOf integer)" -- not human-readable "printer-alert-training (1setOf keyword)" "printer-alert-training (1setOf integer)" -- not human-readable "printer-alert-group (1setOf keyword)" "printer-alert-group (1setOf integer)" -- not human-readable "printer-alert-group-index (1setOf integer)" "printer-alert-group-index (1setOf octetString(MAX))" -- not useful "printer-alert-location (1setOf integer)" "printer-alert-location (1setOf octetString(MAX))" -- not useful "printer-alert-time (1setOf integer)" "printer-alert-time (1setOf octetString(MAX))" -- not useful Example (using preferred encodings above): printer-alert-code[1] = jam printer-alert-code[2] = cover-open -- keyword transformed printer-alert-index[1] = 22 printer-alert-index[2] = 23 printer-alert-severity[1] = critical printer-alert-severity[2] = critical printer-alert-group[1] = media-path -- keyword transformed printer-alert-group[2] = cover printer-alert-group-index[1] = 4 printer-alert-group-index[2] = 6 printer-alert-location[1] = 6 printer-alert-location[2] = 2 Remarks: (1) Because the IPP datatype '1setOf' does NOT allow an empty array, an empty 'prtAlertTable' MUST be represented by _missing_ IPP attributes "printer-alert[...]" - empty attributes would be illegal. (2) Parallel '1setOf X' attributes (section 4.1.16 of RFC2911) are fragile for interoperability, because IPP/1.1 (page 90) states: "Sets are normally unordered. However each attribute description of this type may specify that the values MUST be in a certain order for that attribute." In practice, this means that a generic IPP parser MUST NOT be order-preserving, thus the inherent fragility. (3) The best (and human-readable) encoding of Printer MIB enumerations in method (2) as IPP datatype 'keyword' has two problems: (a) Forces cross-registration with IANA for the IPP and Printer MIB enumerations; (b) Forces keyword changes (insertion of hyphens and lowercase only) due to IPP datatype 'keyword' restrictions. (4) Using the IPP 'enum' datatype (section 4.1.4 of RFC 2911) is worse than using 'keyword', because the over-the-wire encoding is integer (and thus not human-readable) and the enumeration tags STILL must be transformed to fit the 'keyword' datatype restrictions - see (3). (5) Using the IPP datatype 'integer' for Printer MIB enumerations would avoid IANA cross-registration, but is NOT human-readable. (6) Using the IPP datatype 'octetString' for Printer MIB enumerations would avoid IANA cross-registration, but argues for method (1/1+). ------------------------------------------------------------------------ -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.5/403 - Release Date: 7/28/2006 From ipp-owner@pwg.org Sat Jul 29 20:07:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6yqY-0006sA-Ga for ipp-archive@lists.ietf.org; Sat, 29 Jul 2006 20:07:54 -0400 Received: from pwg.org ([192.146.101.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6yqX-0002Ix-8U for ipp-archive@lists.ietf.org; Sat, 29 Jul 2006 20:07:54 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6U07o36029945 for ; Sat, 29 Jul 2006 20:07:52 -0400 Received: from localhost (mail@localhost) by pwg.org (8.13.1/8.13.1/Submit) with SMTP id k6U07oab029942 for ; Sat, 29 Jul 2006 20:07:50 -0400 Received: by pwg.org (bulk_mailer v1.13); Sat, 29 Jul 2006 20:06:56 -0400 Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org with ESMTP id k6U06qQM029610 for ; Sat, 29 Jul 2006 20:06:54 -0400 Received: (from majordom@localhost) by pwg.org (8.13.1/8.13.1/Submit) id k6U06qOi029607 for ipp-outgoing; Sat, 29 Jul 2006 20:06:52 -0400 Received: from mail2.sharplabs.com (mail2.sharplabs.com [216.65.151.51]) by pwg.org with ESMTP id k6U06oEx029597 for ; Sat, 29 Jul 2006 20:06:52 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id CCDAD1E151A for ; Sat, 29 Jul 2006 17:06:49 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 29 Jul 2006 17:06:49 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EE94@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'ipp@pwg.org'" Subject: IPP> PSX> Reminder Thu 3 Aug 11am EDT - Next IPP WG teleconference Date: Sat, 29 Jul 2006 17:06:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipp@pwg.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi folks, Reminder of our scheduled IPP WG teleconference this week: Thursday 8 August 11am EDT / 8am PDT Call-in: 1-866-365-4406 Passcode: 2635888# The topics will be continued discussion of various options for encoding 'prtAlertTable' objects into IPP attributes (see my immediately preceding mail note today) and review of the first draft spec at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippstate10-20060717.htm Cheers, - Ira (co-editor of PWG IPP Printer State Reasons Extensions) Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.5/403 - Release Date: 7/28/2006