From ipp-bounces@pwg.org Mon Apr 4 10:37:02 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9498528C110 for ; Mon, 4 Apr 2011 10:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCRLp0l9sH0R for ; Mon, 4 Apr 2011 10:37:01 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 55E0028C108 for ; Mon, 4 Apr 2011 10:37:01 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 6DE11795C2; Mon, 4 Apr 2011 13:38:26 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by pwg.org (Postfix) with ESMTP id 9A5DE795BE for ; Mon, 4 Apr 2011 13:38:12 -0400 (EDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id AEDEF382C9 for ; Mon, 4 Apr 2011 17:38:11 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 4 Apr 2011 17:37:12 +0000 Received: from GVW1155EXB.americas.hpqcorp.net ([16.232.35.139]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Mon, 4 Apr 2011 17:37:11 +0000 From: "Mitchell, Andrew (Solutions Architect)" To: "ipp@pwg.org" Date: Mon, 4 Apr 2011 17:36:46 +0000 Thread-Topic: Draft: IPP USB Specification Thread-Index: Acvy7u3H2p+eU8Y0R6S9iWNuooQbbA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Draft: IPP USB Specification X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 6DE11795C2.A8791 X-pwg-MailScanner-From: ipp-bounces@pwg.org All, I have posted a draft of an IPP USB Specification (aka IPP over USB) that I= (along with a couple others) have been working on onto the PWG FTP site. Y= ou can download it from: ftp://ftp.pwg.org//pub/pwg/ipp/whitepaper/draft-ippusbspecification-2011040= 4.pdf This is meant to be an extension to the current IPP Everywhere work and wil= l be touched on during tomorrow's IPP session. That being said, if you have= any direct comments/questions feel free to ask them here or send them dire= ctly to me. Enjoy! Andrew --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Apr 4 23:28:47 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD9C3A68BC for ; Mon, 4 Apr 2011 23:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJOV7qsKENXZ for ; Mon, 4 Apr 2011 23:28:46 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 93DA33A68B6 for ; Mon, 4 Apr 2011 23:28:46 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A16707956E; Tue, 5 Apr 2011 02:30:13 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by pwg.org (Postfix) with ESMTP id 321B6795B9 for ; Tue, 5 Apr 2011 02:30:02 -0400 (EDT) Received: from G4W3009.americas.hpqcorp.net (g4w3009.houston.hp.com [16.234.35.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id A14D488CE for ; Tue, 5 Apr 2011 06:30:01 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G4W3009.americas.hpqcorp.net (16.234.35.43) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 5 Apr 2011 06:27:17 +0000 Received: from GVW1155EXB.americas.hpqcorp.net ([16.232.35.139]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Tue, 5 Apr 2011 06:27:16 +0000 From: "Mitchell, Andrew (Solutions Architect)" To: "ipp@pwg.org" Date: Tue, 5 Apr 2011 06:27:07 +0000 Thread-Topic: IPP Scan Docs Posted Thread-Index: AcvzWoISYmwYjlIrTzGlp6GLdkYcgA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] IPP Scan Docs Posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: A16707956E.A8192 X-pwg-MailScanner-From: ipp-bounces@pwg.org I have uploaded the Initial Draft of the IPP Scan doc into the IPP WD direc= tory: ftp://ftp.pwg.org//pub/pwg/ipp/wd/wd-ippscan-20110404.pdf ftp://ftp.pwg.org//pub/pwg/ipp/wd/wd-ippscan-20110404.docx Obviously there is still a lot of work to do on this document, based on the= feedback received during todays F2F meeting the document is being publishe= d in its current form. Andrew --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Tue Apr 5 07:39:16 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588023A6803 for ; Tue, 5 Apr 2011 07:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNgLB0MZ5HwL for ; Tue, 5 Apr 2011 07:39:09 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 474B23A693D for ; Tue, 5 Apr 2011 07:39:09 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 64C09795DC; Tue, 5 Apr 2011 10:40:26 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 407C1795C5 for ; Tue, 5 Apr 2011 10:40:10 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ600ANAOPYS1G1@localhost.apple.com> for ipp@pwg.org; Tue, 05 Apr 2011 07:40:09 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-14-4d9b29c9fbe6 Received: from [17.153.49.7] (Unknown_Domain [17.153.49.7]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 97.04.23242.9C92B9D4; Tue, 05 Apr 2011 07:40:09 -0700 (PDT) Subject: Re: [IPP] IPP Scan Docs Posted From: Michael Sweet In-reply-to: Date: Tue, 05 Apr 2011 07:40:09 -0700 Message-id: <3783AECD-F91C-4442-B230-D76F277D3DFE@apple.com> References: To: "Mitchell, Andrew (Solutions Architect)" X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Cc: "ipp@pwg.org" X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 64C09795DC.A7E6E X-pwg-MailScanner-From: ipp-bounces@pwg.org Thanks, Andrew! On Apr 4, 2011, at 11:27 PM, Mitchell, Andrew (Solutions Architect) wrote: > I have uploaded the Initial Draft of the IPP Scan doc into the IPP WD directory: > > ftp://ftp.pwg.org//pub/pwg/ipp/wd/wd-ippscan-20110404.pdf > ftp://ftp.pwg.org//pub/pwg/ipp/wd/wd-ippscan-20110404.docx > > Obviously there is still a lot of work to do on this document, based on the feedback received during todays F2F meeting the document is being published in its current form. > > Andrew > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Tue Apr 5 15:07:54 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24DC3A67EB for ; Tue, 5 Apr 2011 15:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOTlMBV7We-E for ; Tue, 5 Apr 2011 15:07:54 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id D8D3E3A67D2 for ; Tue, 5 Apr 2011 15:07:53 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 8848A795F0; Tue, 5 Apr 2011 18:09:18 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by pwg.org (Postfix) with ESMTP id 5999D795E1 for ; Tue, 5 Apr 2011 18:09:01 -0400 (EDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 15:09:00 -0700 Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.86]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 15:09:00 -0700 From: Justin Hutchings To: "ipp@pwg.org" Thread-Topic: IEEE 1284.4 CompatibleID Thread-Index: Acvz3erTsH1hZ9KdRbW7WVSI1cKwPQ== Date: Tue, 5 Apr 2011 22:08:59 +0000 Message-ID: <15713B46EB868E4FB0CF6D8BFD33617E47DE981D@TK5EX14MBXC116.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] IEEE 1284.4 CompatibleID X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1886516802==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 8848A795F0.A8702 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1886516802== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_15713B46EB868E4FB0CF6D8BFD33617E47DE981DTK5EX14MBXC116r_" --_000_15713B46EB868E4FB0CF6D8BFD33617E47DE981DTK5EX14MBXC116r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the syntax for the compatibleID discussed today: MANUFACTURER:Contoso Manufacturing; COMMAND SET:PCL,PJL,PS,XHTML-Print+xml; MODEL:LaserBeam 9; COMMENT:Anything you like; ACTIVE COMMAND SET:PCL; COMPATIBLEID:CONTOSOClass1 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_15713B46EB868E4FB0CF6D8BFD33617E47DE981DTK5EX14MBXC116r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the syntax for the compatibleID discussed to= day:

MANUFACTURER:Contoso Manufacturing;

COMMAND SET:PCL,PJL,PS,XHTML-Print+xml;

MODEL:LaserBeam 9;

COMMENT:Anything you like;

ACTIVE COMMAND SET:PCL;

COMPATIBLEID:CONTOSOClass1

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_15713B46EB868E4FB0CF6D8BFD33617E47DE981DTK5EX14MBXC116r_-- --===============1886516802== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1886516802==-- From ipp-bounces@pwg.org Tue Apr 5 20:12:15 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE0A3A686C for ; Tue, 5 Apr 2011 20:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnYlPZPidVHF for ; Tue, 5 Apr 2011 20:12:14 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 1B9E73A684E for ; Tue, 5 Apr 2011 20:12:14 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 9AF6C7960A; Tue, 5 Apr 2011 23:13:41 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 9DCF079607 for ; Tue, 5 Apr 2011 23:13:28 -0400 (EDT) MIME-version: 1.0 Received: from relay13.apple.com ([17.128.113.29]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ7009C2NMGG4P1@localhost.apple.com> for ipp@pwg.org; Tue, 05 Apr 2011 20:13:28 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-37-4d9bda578aa4 Received: from [17.151.73.93] (Unknown_Domain [17.151.73.93]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id F8.B9.29082.75ADB9D4; Tue, 05 Apr 2011 20:13:27 -0700 (PDT) From: Michael Sweet Date: Tue, 05 Apr 2011 20:13:27 -0700 To: ipp@pwg.org Message-id: <67B6AA14-3209-416C-8DE4-E76376F2DC24@apple.com> X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Minutes posted for today's face-to-face X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936129255==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 9AF6C7960A.A8981 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1936129255== Content-type: multipart/alternative; boundary="Boundary_(ID_Ba4l9DZNUNLRIRllXx+Zmw)" --Boundary_(ID_Ba4l9DZNUNLRIRllXx+Zmw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I've posted the minutes for today's face-to-face meeting at: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.pdf Action items: Mike to post call for use cases to both ipp and cloud ML Andrew to provide section 4.4 UPNP discovery text ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_Ba4l9DZNUNLRIRllXx+Zmw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

I've posted the minutes for today's face-to-face meeting at:


Action items:

  • Mike to post call for use cases to both ipp and cloud ML
  • Andrew to provide section 4.4 UPNP discovery text

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_Ba4l9DZNUNLRIRllXx+Zmw)-- --===============1936129255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1936129255==-- From ipp-bounces@pwg.org Tue Apr 5 20:31:42 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572043A684F for ; Tue, 5 Apr 2011 20:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca7elv3klVlv for ; Tue, 5 Apr 2011 20:31:41 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 1C0023A684B for ; Tue, 5 Apr 2011 20:31:41 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id EA22F79610; Tue, 5 Apr 2011 23:32:29 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 61A6E7960A; Tue, 5 Apr 2011 23:32:17 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ7002QUOHRXE10@localhost.apple.com>; Tue, 05 Apr 2011 20:32:16 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-00-4d9bdebf2fd2 Received: from [17.151.73.93] (Unknown_Domain [17.151.73.93]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id F9.90.20744.0CEDB9D4; Tue, 05 Apr 2011 20:32:16 -0700 (PDT) From: Michael Sweet Date: Tue, 05 Apr 2011 20:32:15 -0700 Message-id: To: pwg-announce@pwg.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Cc: cloud@pwg.org, ipp@pwg.org Subject: [IPP] Call for use cases X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: EA22F79610.A87D7 X-pwg-MailScanner-From: ipp-bounces@pwg.org All, Based on our discussions during the Cloud Imaging and IPP WG sessions, I am calling for all PWG members to send in a single use case for printing, scanning, or facsimile for Cloud and/or IPP Everywhere. Please be as specific and detailed as you can, and cover everything from the installation/setup of the printer to any status/error/progress. ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From pwg-announce-bounces@pwg.org Tue Apr 5 20:31:42 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C713A684B for ; Tue, 5 Apr 2011 20:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upmYEXlKrebJ for ; Tue, 5 Apr 2011 20:31:42 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id E53CE3A684E for ; Tue, 5 Apr 2011 20:31:41 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7F27779615; Tue, 5 Apr 2011 23:32:30 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 61A6E7960A; Tue, 5 Apr 2011 23:32:17 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJ7002QUOHRXE10@localhost.apple.com>; Tue, 05 Apr 2011 20:32:16 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-00-4d9bdebf2fd2 Received: from [17.151.73.93] (Unknown_Domain [17.151.73.93]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id F9.90.20744.0CEDB9D4; Tue, 05 Apr 2011 20:32:16 -0700 (PDT) From: Michael Sweet Date: Tue, 05 Apr 2011 20:32:15 -0700 Message-id: To: pwg-announce@pwg.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Cc: cloud@pwg.org, ipp@pwg.org Subject: [Pwg-Announce] Call for use cases X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 7F27779615.AA99C X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org All, Based on our discussions during the Cloud Imaging and IPP WG sessions, I am calling for all PWG members to send in a single use case for printing, scanning, or facsimile for Cloud and/or IPP Everywhere. Please be as specific and detailed as you can, and cover everything from the installation/setup of the printer to any status/error/progress. ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce From ipp-bounces@pwg.org Wed Apr 6 08:47:14 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3DA28C0F6 for ; Wed, 6 Apr 2011 08:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S+G-WzWlhHl for ; Wed, 6 Apr 2011 08:47:08 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by core3.amsl.com (Postfix) with ESMTP id 246D33A6819 for ; Wed, 6 Apr 2011 08:47:08 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 81F0679627; Wed, 6 Apr 2011 11:48:16 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by pwg.org (Postfix) with ESMTP id 344F27961A; Wed, 6 Apr 2011 11:47:57 -0400 (EDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Apr 2011 08:47:56 -0700 Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.86]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0270.002; Wed, 6 Apr 2011 08:47:56 -0700 From: Justin Hutchings To: Michael Sweet Subject: RE: [IPP] Call for use cases Thread-Topic: [IPP] Call for use cases Thread-Index: AQHL9Atia5Q8yMMWS0aow0A0QZdc/pRQ93ug Date: Wed, 6 Apr 2011 15:47:56 +0000 Message-ID: <15713B46EB868E4FB0CF6D8BFD33617E47DEA821@TK5EX14MBXC116.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Cc: "cloud@pwg.org" , "ipp@pwg.org" X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1008178586==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 81F0679627.A9D42 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1008178586== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_15713B46EB868E4FB0CF6D8BFD33617E47DEA821TK5EX14MBXC116r_" --_000_15713B46EB868E4FB0CF6D8BFD33617E47DEA821TK5EX14MBXC116r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Here's a first cut at a basic use case for IPP Everywhere. This template is= a bit more verbose than the ones in the specs I've seen so far, but I thin= k it'll help ferret out the assumptions, and help to create use cases that = are understandable, while incorporating the full complexity available in th= e system. Thoughts? Thanks Justin Title Mobile phone user prints to IPP Everywhere printer Description User has a mobile phone connected to the WiFi in her business. The user has= a document to print prior to a meeting, and has it available from her phon= e. User initiates a print from the phone and chooses an IPP Everywhere prin= ter that has been associated with the phone previously. The user configures= the print job, and once the Printer determines that the settings are valid= , the job is printed. The user picks up her job at the device. Goal User obtains a high quality print with good performance from their mobile p= hone Preconditions User's mobile phone is connected to the same LAN the printer is on User's mobile phone can print to IPP Everywhere devices Trigger User initiates a print command from an application that can generate print = content Steps 1. User initiates a print command from an application that can genera= te print content 2. User chooses an available printer from the available devices 3. User configures the print job, setting options like duplexing, and= media sizes 4. User submits the job 5. The system validates the print job using IPP 6. The system submits the job to the printer Alternate flows 5a. The IPP printer could deem the job settings invalid and return the job = to the user for correction. 5b. The IPP printer could deem the job settings invalid and correct them 6a. An error could be encountered, in which case the user would be notified= by the system about how to correct the issue. Postconditions The IPP Everywhere printer has printed the job the user sent. The IPP everywhere printer is available to accept additional print jobs. -----Original Message----- From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael= Sweet Sent: Tuesday, April 05, 2011 8:32 PM To: pwg-announce@pwg.org Cc: cloud@pwg.org; ipp@pwg.org Subject: [IPP] Call for use cases All, Based on our discussions during the Cloud Imaging and IPP WG sessions, I am= calling for all PWG members to send in a single use case for printing, sca= nning, or facsimile for Cloud and/or IPP Everywhere. Please be as specific = and detailed as you can, and cover everything from the installation/setup o= f the printer to any status/error/progress. ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScan= ner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_15713B46EB868E4FB0CF6D8BFD33617E47DEA821TK5EX14MBXC116r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

Here’s a first cut at a basic use case for = IPP Everywhere. This template is a bit more verbose than the ones in the sp= ecs I’ve seen so far, but I think it’ll help ferret out the ass= umptions, and help to create use cases that are understandable, while incorporating the full complexity available in the system.

 

Thoughts?

 

Thanks

Justin

 

Title

Mobile phone user prints to IPP Everywhere printe= r

Description

User has a mobile phone connected to the WiFi in = her business. The user has a document to print prior to a meeting, and has = it available from her phone. User initiates a print from the phone and choo= ses an IPP Everywhere printer that has been associated with the phone previously. The user configures the pri= nt job, and once the Printer determines that the settings are valid, the jo= b is printed. The user picks up her job at the device.

Goal

User obtains a high quality print with good perfo= rmance from their mobile phone

Preconditions

User’s mobile phone is connected to the sam= e LAN the printer is on

User’s mobile phone can print to IPP Everyw= here devices
<Use case: User discovers/pairs/installs IPP Everywhere printer>=

Trigger

User initiates a print command from an applicatio= n that can generate print content

Steps

1.       User initiates a print command from an application = that can generate print content

2.       User chooses an available printer from the availabl= e devices

3.       User configures the print job, setting options like= duplexing, and media sizes

4.       User submits the job

5.       The system validates the print job using IPP

6.       The system submits the job to the printer

Alternate flows

5a. The IPP printer could deem the job settings i= nvalid and return the job to the user for correction.

5b. The IPP printer could deem the job settings i= nvalid and correct them

6a. An error could be encountered, in which case = the user would be notified by the system about how to correct the issue.

Postconditions

The IPP Everywhere printer has printed the job th= e user sent.

The IPP everywhere printer is available to accept= additional print jobs.

<Use case: Billing>

<Use case: Accounting>

 

 

-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael= Sweet
Sent: Tuesday, April 05, 2011 8:32 PM
To: pwg-announce@pwg.org
Cc: cloud@pwg.org; ipp@pwg.org
Subject: [IPP] Call for use cases

 

All,

 

Based on our discussions during the Cloud Imaging= and IPP WG sessions, I am calling for all PWG members to send in a single = use case for printing, scanning, or facsimile for Cloud and/or IPP Everywhe= re. Please be as specific and detailed as you can, and cover everything from the installation/setup of the printe= r to any status/error/progress.

 

_________________________________________________= _______________________

Michael Sweet, Senior Printing System Engineer, P= WG Chair

 

 

--

This message has been scanned for viruses and dan= gerous content by MailScanner, and is believed to be clean.

 

_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.o= rg/mailman/listinfo/ipp

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_15713B46EB868E4FB0CF6D8BFD33617E47DEA821TK5EX14MBXC116r_-- --===============1008178586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1008178586==-- From christen3@gmail.com Sat Apr 9 05:23:46 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@core3.amsl.com Delivered-To: ietfarch-ipp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588D33A6A96 for ; Sat, 9 Apr 2011 05:23:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/alternative | multipart/related | application/zip,.zip,document.zip | .exe,.exe-ms,document.exe X-Spam-Flag: NO X-Spam-Score: 4.971 X-Spam-Level: **** X-Spam-Status: No, score=4.971 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMzhVQwTw3d6 for ; Sat, 9 Apr 2011 05:23:45 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1302351826-18061-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Subject: Express Delivery system notification Received: from l49-14-101.cn.ru (l49-14-101.cn.ru [178.49.14.101]) by core3.amsl.com (Postfix) with ESMTP id AD10D3A6A90 for ; Sat, 9 Apr 2011 05:23:44 -0700 (PDT) Received: from apache by lbnrrgljfecjaemtcmt. with local (Exim 4.63) (envelope-from ) id VLRW9Z-ME6V2K-3H for ; Sat, 9 Apr 2011 18:25:30 +0600 To: Date: Sat, 9 Apr 2011 18:25:30 +0600 From: "Express Delivery" Message-ID: <3BD93CD7DE004CD517D8EF6F68FC6964@lbnrrgljfecjaemtcmt.> X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) This is a multi-part message in MIME format... ------------=_1302351826-18061-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1302351826-18061-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 8bit Content-Description: Original message Received: from l49-14-101.cn.ru (l49-14-101.cn.ru [178.49.14.101]) by core3.amsl.com (Postfix) with ESMTP id AD10D3A6A90 for ; Sat, 9 Apr 2011 05:23:44 -0700 (PDT) Received: from apache by lbnrrgljfecjaemtcmt. with local (Exim 4.63) (envelope-from ) id VLRW9Z-ME6V2K-3H for ; Sat, 9 Apr 2011 18:25:30 +0600 To: Subject: Express Delivery system notification Date: Sat, 9 Apr 2011 18:25:30 +0600 From: "Express Delivery" Message-ID: <3BD93CD7DE004CD517D8EF6F68FC6964@lbnrrgljfecjaemtcmt.> X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------09080300501040603030405" This is a multi-part message in MIME format. --------------09080300501040603030405 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Dear customerThe parcel was sent your home adressAnd it will arrive within 10 business daysMore information and the tracking numberare attached in document below.Thank You© Delivery Express 1995-2011 CJ54ZCY6I0XTBA36KETX8E6517AN6G4T7QV0ZVGG9AF3J12SIPGRMWUMRS6GFUJAL0JNPPRY9Q4Q4Y3QJC21A23437 --------------09080300501040603030405 Content-Type: multipart/related; boundary="------------03020400907090301010508" --------------03020400907090301010508 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="Windows-1252"
Dear customer

The parcel was sent your home adress
And it will arrive within 10 business days

More information and the tracking number
are attached in document below.

Thank You

© Delivery Express 1995-2011

My use-case for cloud printing

 

Title:

 

Student Printing Homework at Friends House.

Description:

 

John, a high-school student, rushes out of the house= on his way to his friend’s (Steve) house and, then, to school. In less than 5 minutes he arrives at Steve house. Steve waves his history report = at John to show him it is done and printed. John reaches in his backpack to realize he has forgotten his printed copy. John tells Steve he has a copy= of his report on his cloud and could he print it at his house. Steve agrees. Steve ask John for his cloud user name and adds John as a ‘friend’ to his cloud aware printer. John promptly logs into = his cloud account and finds his history report. Invoking a print request, John sees that Steve’s printer has been added to this printer list. Selecting Steve’s printer, John prints his report and they are both= off to school.

 

Optional: Steve’s system administrator (dad) d= oes not want the ‘friend’s’ list for the printer to be to l= ong; so, Steve removes John from the ‘friend’s’ list and John see the printer disappear from this printer list.

 

 

Goal:

 

To demonstrate rapid but temporary access to cloud p= rint services and the necessary administrative services

Actors:

 

John, using his cloud account and cloud print servic= e

Steve, using his cloud account and cloud printing administrative service

 

 

Assumptions/

Preconditions:

1. John and Steve both have cloud repositories accou= nts.

2. Steve has at least one cloud print account=

3. Steve has some administrative privileges <= /font>

Process:

Main:

1. Steve logs in to his cloud account<= o:p>

2. Steve adds John to the ‘friend’s̵= 7; list for his home printer

3. The cloud system updates the ‘friend’ access list.

4. The cloud system add the Steve’s home print= er to John’s printer list.

 

1. John logs in to his cloud account

2. John selects his document and request a print.

3. John selects Steve’s home printer from his printer list.

4. The cloud system presents a print dialog using the capabilities for Steve’s home printer.

5. John sets his print options and presses the print button.

6. The print dialog generates a Print-Job-Ticket and records the URI for Steve’s document in the Print-Job-Ticket.

7. The print dialog passes the print request to the cloud repository print client manager.

8. The cloud repository print client manager checks = the status of Steve’s printer.

9. The cloud repository print client manager sends t= he print job to Steve’s printer.

10. The cloud repository print client manager receiv= e a print-complete.

11. The cloud repository print client manager updates John’s print status.

12. The cloud repository print client manager removes the job from its queue.

Process:

Alternative:

1. Steve logs in to his cloud account<= o:p>

2. Steve removes John from Steve’s home printer ‘friend’s’ list.

3. The cloud system remove Steve’s printer from John’s printer list.

Frequency:

Random; 10 or less events in one year period.=

Features:

Rapid and temporary access to a cloud aware printer.=

Administrate rights at a level other than user and administrator.

Issues:

None. Capabilities are within scope of todays or proposed solutions.

 

 

-----Original Message-----
From: pwg-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Tuesday, April 05, 2011 8:32 PM
To: pwg-announce@pwg.org
Cc: cloud@pwg.org; ipp@pwg.org
Subject: [Pwg-Announce] Call for use cases

 

All,

 

Based on our discussions during the Cloud Imaging and IPP WG sessions, I am calli= ng for all PWG members to send in a single use case for printing, scanning, or facsimile for Cloud and/or IPP Everywhere. Please be as specific and detail= ed as you can, and cover everything from the installation/setup of the printer= to any status/error/progress.

 

_______________________________________________________________= _________

Michael Sweet, Senior Printing System Engineer, PWG Chair<= /p>

 

 

--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.

 

_______________________________________________

pwg-announce mailing list

pwg-announce@pwg.org

https://www.pwg.org/mailman/listinfo/pwg-announce


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CBFB8C.F43DDFDB-- --===============0632267016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============0632267016==-- From pwg-announce-bounces@pwg.org Fri Apr 15 09:50:11 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF7E5130043 for ; Fri, 15 Apr 2011 09:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWSY8ycOG2EZ for ; Fri, 15 Apr 2011 09:50:06 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 585C7130050 for ; Fri, 15 Apr 2011 09:50:06 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A22F6794F5; Fri, 15 Apr 2011 12:48:54 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 18C5A794A3; Fri, 15 Apr 2011 12:48:35 -0400 (EDT) Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Apr 2011 09:48:35 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pwg-Announce] Call for use cases Date: Fri, 15 Apr 2011 09:48:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pwg-Announce] Call for use cases Thread-Index: Acv0C1Uk6Oc6dQcZQEiwdI7tXghSmgHgRuRg References: From: "Petrie, Glen" To: X-OriginalArrivalTime: 15 Apr 2011 16:48:35.0145 (UTC) FILETIME=[F6011390:01CBFB8C] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: cloud@pwg.org, ipp@pwg.org X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0709139499==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: A22F6794F5.AD1D3 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org This is a multi-part message in MIME format. --===============0709139499== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBFB8C.F43DDFDB" This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFB8C.F43DDFDB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable My use-case for cloud printing =20 Title: =20 Student Printing Homework at Friends House. Description: =20 John, a high-school student, rushes out of the house on his way to his friend's (Steve) house and, then, to school. In less than 5 minutes he arrives at Steve house. Steve waves his history report at John to show him it is done and printed. John reaches in his backpack to realize he has forgotten his printed copy. John tells Steve he has a copy of his report on his cloud and could he print it at his house. Steve agrees. Steve ask John for his cloud user name and adds John as a 'friend' to his cloud aware printer. John promptly logs into his cloud account and finds his history report. Invoking a print request, John sees that Steve's printer has been added to this printer list. Selecting Steve's printer, John prints his report and they are both off to school. =20 Optional: Steve's system administrator (dad) does not want the 'friend's' list for the printer to be to long; so, Steve removes John from the 'friend's' list and John see the printer disappear from this printer list. =20 =20 Goal: =20 To demonstrate rapid but temporary access to cloud print services and the necessary administrative services Actors: =20 John, using his cloud account and cloud print service Steve, using his cloud account and cloud printing administrative service =20 =20 Assumptions/ Preconditions: 1. John and Steve both have cloud repositories accounts. 2. Steve has at least one cloud print account 3. Steve has some administrative privileges=20 Process:=20 Main: 1. Steve logs in to his cloud account 2. Steve adds John to the 'friend's' list for his home printer 3. The cloud system updates the 'friend' access list. 4. The cloud system add the Steve's home printer to John's printer list. =20 1. John logs in to his cloud account 2. John selects his document and request a print. 3. John selects Steve's home printer from his printer list. 4. The cloud system presents a print dialog using the capabilities for Steve's home printer. 5. John sets his print options and presses the print button. 6. The print dialog generates a Print-Job-Ticket and records the URI for Steve's document in the Print-Job-Ticket. 7. The print dialog passes the print request to the cloud repository print client manager.=20 8. The cloud repository print client manager checks the status of Steve's printer. 9. The cloud repository print client manager sends the print job to Steve's printer. 10. The cloud repository print client manager receive a print-complete. 11. The cloud repository print client manager updates John's print status. 12. The cloud repository print client manager removes the job from its queue. Process: Alternative: 1. Steve logs in to his cloud account 2. Steve removes John from Steve's home printer 'friend's' list. 3. The cloud system remove Steve's printer from John's printer list. Frequency: Random; 10 or less events in one year period. Features: Rapid and temporary access to a cloud aware printer. Administrate rights at a level other than user and administrator. Issues: None. Capabilities are within scope of todays or proposed solutions.=20 =20 =20 -----Original Message----- From: pwg-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org] On Behalf Of Michael Sweet Sent: Tuesday, April 05, 2011 8:32 PM To: pwg-announce@pwg.org Cc: cloud@pwg.org; ipp@pwg.org Subject: [Pwg-Announce] Call for use cases =20 All, =20 Based on our discussions during the Cloud Imaging and IPP WG sessions, I am calling for all PWG members to send in a single use case for printing, scanning, or facsimile for Cloud and/or IPP Everywhere. Please be as specific and detailed as you can, and cover everything from the installation/setup of the printer to any status/error/progress. =20 ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair =20 =20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. =20 _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CBFB8C.F43DDFDB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

My use-case for cloud printing

 

Title:

 

Student Printing Homework at Friends House.

Description:

 

John, a high-school student, rushes out of the house= on his way to his friend’s (Steve) house and, then, to school. In less than 5 minutes he arrives at Steve house. Steve waves his history report = at John to show him it is done and printed. John reaches in his backpack to realize he has forgotten his printed copy. John tells Steve he has a copy= of his report on his cloud and could he print it at his house. Steve agrees. Steve ask John for his cloud user name and adds John as a ‘friend’ to his cloud aware printer. John promptly logs into = his cloud account and finds his history report. Invoking a print request, John sees that Steve’s printer has been added to this printer list. Selecting Steve’s printer, John prints his report and they are both= off to school.

 

Optional: Steve’s system administrator (dad) d= oes not want the ‘friend’s’ list for the printer to be to l= ong; so, Steve removes John from the ‘friend’s’ list and John see the printer disappear from this printer list.

 

 

Goal:

 

To demonstrate rapid but temporary access to cloud p= rint services and the necessary administrative services

Actors:

 

John, using his cloud account and cloud print servic= e

Steve, using his cloud account and cloud printing administrative service

 

 

Assumptions/

Preconditions:

1. John and Steve both have cloud repositories accou= nts.

2. Steve has at least one cloud print account=

3. Steve has some administrative privileges <= /font>

Process:

Main:

1. Steve logs in to his cloud account<= o:p>

2. Steve adds John to the ‘friend’s̵= 7; list for his home printer

3. The cloud system updates the ‘friend’ access list.

4. The cloud system add the Steve’s home print= er to John’s printer list.

 

1. John logs in to his cloud account

2. John selects his document and request a print.

3. John selects Steve’s home printer from his printer list.

4. The cloud system presents a print dialog using the capabilities for Steve’s home printer.

5. John sets his print options and presses the print button.

6. The print dialog generates a Print-Job-Ticket and records the URI for Steve’s document in the Print-Job-Ticket.

7. The print dialog passes the print request to the cloud repository print client manager.

8. The cloud repository print client manager checks = the status of Steve’s printer.

9. The cloud repository print client manager sends t= he print job to Steve’s printer.

10. The cloud repository print client manager receiv= e a print-complete.

11. The cloud repository print client manager updates John’s print status.

12. The cloud repository print client manager removes the job from its queue.

Process:

Alternative:

1. Steve logs in to his cloud account<= o:p>

2. Steve removes John from Steve’s home printer ‘friend’s’ list.

3. The cloud system remove Steve’s printer from John’s printer list.

Frequency:

Random; 10 or less events in one year period.=

Features:

Rapid and temporary access to a cloud aware printer.=

Administrate rights at a level other than user and administrator.

Issues:

None. Capabilities are within scope of todays or proposed solutions.

 

 

-----Original Message-----
From: pwg-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Tuesday, April 05, 2011 8:32 PM
To: pwg-announce@pwg.org
Cc: cloud@pwg.org; ipp@pwg.org
Subject: [Pwg-Announce] Call for use cases

 

All,

 

Based on our discussions during the Cloud Imaging and IPP WG sessions, I am calli= ng for all PWG members to send in a single use case for printing, scanning, or facsimile for Cloud and/or IPP Everywhere. Please be as specific and detail= ed as you can, and cover everything from the installation/setup of the printer= to any status/error/progress.

 

_______________________________________________________________= _________

Michael Sweet, Senior Printing System Engineer, PWG Chair<= /p>

 

 

--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.

 

_______________________________________________

pwg-announce mailing list

pwg-announce@pwg.org

https://www.pwg.org/mailman/listinfo/pwg-announce


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CBFB8C.F43DDFDB-- --===============0709139499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --===============0709139499==-- From ipp-bounces@pwg.org Fri Apr 15 18:42:26 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8BD6E0660 for ; Fri, 15 Apr 2011 18:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUK4sLwQlcxP for ; Fri, 15 Apr 2011 18:42:23 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id D3636E061E for ; Fri, 15 Apr 2011 18:42:22 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 820E57951F; Fri, 15 Apr 2011 21:41:51 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by pwg.org (Postfix) with ESMTP id 8491C7950F for ; Fri, 15 Apr 2011 21:41:29 -0400 (EDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta11.emeryville.ca.mail.comcast.net with comcast id Y0qj1g0021wfjNsAB1hUnd; Sat, 16 Apr 2011 01:41:28 +0000 Received: from WAMNotebook ([205.245.23.20]) by omta23.emeryville.ca.mail.comcast.net with comcast id Y1h81g00T0S0iwD8j1hDgP; Sat, 16 Apr 2011 01:41:26 +0000 From: "William Wagner" To: "'Petrie, Glen'" , References: In-Reply-To: Date: Fri, 15 Apr 2011 21:41:05 -0400 Message-ID: <000001cbfbd7$64213770$2c63a650$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv0C1Uk6Oc6dQcZQEiwdI7tXghSmgHgRuRgABAsMaA= Content-Language: en-us X-pwg-MailScanner: Found to be clean, Found to be clean Cc: cloud@pwg.org, ipp@pwg.org Subject: [IPP] RE: [Cloud] RE: [Pwg-Announce] Call for use cases X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1112716147==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 820E57951F.A9A45 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1112716147== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CBFBB5.DD0F9770" Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CBFBB5.DD0F9770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I like this use case format (Thanks Justin Hutchings). I submit the next two, for Cloud and/or IPP Everywhere. They were observed at a nursing conference I am currently at (with my wife. I haven't changed careers yet) and they are very real and I suspect, not uncommon. Current solutions were inconvenient and time consuming, and the output was not completely satisfactory, Title User of standard application wants to print checks at offsite location. Description The treasurer of a small training company, that is holding a meeting and seminar at a resort, needs to print out 20 checks for training personnel. He uses QuickBooks R for accounting and to print out checks, and he updates the information in this program to reflect latest hours worked, bonuses, etc. The resort site does have 802.11 and does have a printer available for guest use (for a fee). The treasurer has check blanks. Goal Treasurer can submit proper checks with current balances to personnel during closing ceremony at remote site using the same accounting software he uses to track all expenses. Preconditions TBD - to an extent, this is part of solution since at the present time site does not have advanced capabilities that we which to define. However, we can note that security is one of many concerns. Trigger User loads check blanks on printer and initiates a print command from an application that can generate print content Steps 1. User updates his accounting grogram, determines what checks need to be printed and insures that checks amounts, payees and signature are correct. 2. User locates an available printer 3. User ensures that printer is free, locks out other jobs and loads the check blanks. 4. User initiates check printing. (put in a validate job operation?) 5. The system (or the application) submits the job to the printer. 6. Checks are printed and immediately taken off the printer. 7. Cost of printing (not including media) is calculated and sent to treasurer's account. Alternate flows ?? Postconditions The accounting program properly reflects all outstanding checks. The treasurer has a stack of properly printed checks. The Treasurer will be charged for the Us of the printer. Title User wants to print specially formatted text on printer at resort site Description At a seminar located at a country resort, a factotum and general gofer has been asked to provide 80 sets of ten keywords/phrases, clearly printed on 2-inch by 1-inch paper slips for use in a get acquainted exercise. Costs are to be minimized. Gofer has a laptop with a word processer program. Resort has a wi-fi network available to users and a networked MFDat the business centre. Attendant at business center will charge for any printed sheets removed from premises Goal Gofer must provide paper slips of the specified size with legible text, promptly and cheaply Preconditions TBD - to an extent, this is part of solution since at the present time site does not have advanced capabilities that we which to define. However, we can note that security is one of many concerns. Trigger Gofer uses word processer program to lay out the phrases in a table format, adjusting margins, font size and spacing to use landscape format to print five phrases per line and eight lines of phrases per page. The required 80 phrases should be handled in two pages. Steps 1. Gofer creates the page descriptions on his word processor program. 2. Gofer locates an available printer 3. User initiates printing. (put in a validate job operation?) 4. The system (or the application) submits the job to the printer. 5. Two sheets are printed with 80 phrases. User must then use scissors to cut part Alternate flows ?? Postconditions Gofer will be charged for printing two single sided sheets. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_0001_01CBFBB5.DD0F9770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like th= is use case format (Thanks Justin Hutchings). I submit the next two, for Cl= oud and/or IPP Everywhere.  They were observed at a nursing conference=  I am currently at  (with my wife… I haven’t changed= careers yet) and they are very real and I suspect, not uncommon. Current s= olutions were inconvenient and time consuming, and the output was not compl= etely satisfactory,

 

Title

Use= r of standard application wants to print checks at offsite location.

Description

The treasurer of a small training co= mpany, that is holding a meeting and seminar at a resort, needs to print ou= t 20  checks for training personnel.  He uses QuickBooks ® fo= r accounting and to print out checks, and he updates the information in thi= s program to  reflect latest hours worked, bonuses, etc. The resort si= te does have 802.11 and does have a printer available for guest use (for a = fee). The treasurer has check blanks.

Goal

Treasurer can submit proper  checks with current balances to personn= el during closing ceremony at remote site  using the same accounting s= oftware he uses to track all expenses.

Precondi= tions

TBD – to an extent, this is part of solution since at the = present time site does not have advanced capabilities that we which to defi= ne. However, we can note that security is one of many concerns.<= /p>

Trigger

User loads check blanks on printer and initia= tes a print command from an application that can generate print content

Steps

1.   &= nbsp;  User updates his accounting grogram, de= termines what checks need to be printed and insures that checks amounts, pa= yees and signature are correct.

2.      User = locates an available printer

3.      User = ensures that printer is free, locks out other jobs and loads the check blan= ks.

4.  &= nbsp;   User initiates check printing. (p= ut in a validate job operation?)

5.      The = system (or the application) submits the job to the printer.

<= p class=3DMsoPlainText style=3D'margin-left:.5in;text-indent:-.25in;mso-lis= t:l0 level1 lfo1'>6.      <= /span>Checks are printed and immediately taken off the pri= nter.

7.  = ;    Cost of printing  (not inc= luding media) is calculated and sent to treasurer’s account.

Alternate flows

??

Postconditions

The= accounting program properly reflects all outstanding checks. The treasurer= has a stack of properly printed checks.  The Treasurer  will be = charged for the

Us of the printer.

 

 

Title

User wants to print specially fo= rmatted text on printer at resort site

Description

At a semina= r located at a country resort, a factotum and general gofer has been asked = to provide 80 sets of ten keywords/phrases, clearly printed on 2-inch by 1-= inch paper slips for use in a get acquainted exercise. Costs are to be mini= mized. Gofer has a laptop with a word processer program. Resort has a wi-fi= network available to users and a networked MFDat the business centre. Atte= ndant at business center will charge for any printed sheets removed from pr= emises

Goal

Gofer must provide paper slips=  of the specified size with legible  text, promptly and cheaply<= o:p>

Preconditions

TBD – to an extent, th= is is part of solution since at the present time site does not have advance= d capabilities that we which to define. However, we can note that security = is one of many concerns.

Trigger

=

Gofer use= s word processer program to lay out the phrases in  a table format, ad= justing margins, font size and spacing to use landscape format to print fiv= e phrases per line and eight lines of phrases per page. The required 80&nbs= p; phrases should be handled in two pages.

Step= s

1.      Gofer creates the page descriptions on his word processor program. <= o:p>

2.   = ;   Gofer locates an available printer

3.   =    User initiates printing. (put in a val= idate job operation?)

4.      The system (or = the application) submits the job to the printer.

5.      Two sheets are printed with 80 phrases. User must then use sc= issors to cut part

Alternate flows

??=

Postconditi= ons

=

Gofer will be charged for printing  two  = single sided sheets.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_0001_01CBFBB5.DD0F9770-- --===============1112716147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============1112716147==-- From pwg-announce-bounces@pwg.org Fri Apr 15 18:42:38 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ACA51E0660 for ; Fri, 15 Apr 2011 18:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSJ-XE6ksGyA for ; Fri, 15 Apr 2011 18:42:34 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id BA19CE061E for ; Fri, 15 Apr 2011 18:42:34 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id DF1E479517; Fri, 15 Apr 2011 21:41:49 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by pwg.org (Postfix) with ESMTP id 81E9B79501 for ; Fri, 15 Apr 2011 21:41:29 -0400 (EDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Y1e81g0011wfjNsA91hUiF; Sat, 16 Apr 2011 01:41:28 +0000 Received: from WAMNotebook ([205.245.23.20]) by omta23.emeryville.ca.mail.comcast.net with comcast id Y1h81g00T0S0iwD8j1hDgP; Sat, 16 Apr 2011 01:41:26 +0000 From: "William Wagner" To: "'Petrie, Glen'" , References: In-Reply-To: Subject: RE: [Cloud] RE: [Pwg-Announce] Call for use cases Date: Fri, 15 Apr 2011 21:41:05 -0400 Message-ID: <000001cbfbd7$64213770$2c63a650$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv0C1Uk6Oc6dQcZQEiwdI7tXghSmgHgRuRgABAsMaA= Content-Language: en-us X-pwg-MailScanner: Found to be clean, Found to be clean Cc: cloud@pwg.org, ipp@pwg.org X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1859543706==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: DF1E479517.ACD85 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org This is a multi-part message in MIME format. --===============1859543706== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CBFBB5.DD0F9770" Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CBFBB5.DD0F9770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I like this use case format (Thanks Justin Hutchings). I submit the next two, for Cloud and/or IPP Everywhere. They were observed at a nursing conference I am currently at (with my wife. I haven't changed careers yet) and they are very real and I suspect, not uncommon. Current solutions were inconvenient and time consuming, and the output was not completely satisfactory, Title User of standard application wants to print checks at offsite location. Description The treasurer of a small training company, that is holding a meeting and seminar at a resort, needs to print out 20 checks for training personnel. He uses QuickBooks R for accounting and to print out checks, and he updates the information in this program to reflect latest hours worked, bonuses, etc. The resort site does have 802.11 and does have a printer available for guest use (for a fee). The treasurer has check blanks. Goal Treasurer can submit proper checks with current balances to personnel during closing ceremony at remote site using the same accounting software he uses to track all expenses. Preconditions TBD - to an extent, this is part of solution since at the present time site does not have advanced capabilities that we which to define. However, we can note that security is one of many concerns. Trigger User loads check blanks on printer and initiates a print command from an application that can generate print content Steps 1. User updates his accounting grogram, determines what checks need to be printed and insures that checks amounts, payees and signature are correct. 2. User locates an available printer 3. User ensures that printer is free, locks out other jobs and loads the check blanks. 4. User initiates check printing. (put in a validate job operation?) 5. The system (or the application) submits the job to the printer. 6. Checks are printed and immediately taken off the printer. 7. Cost of printing (not including media) is calculated and sent to treasurer's account. Alternate flows ?? Postconditions The accounting program properly reflects all outstanding checks. The treasurer has a stack of properly printed checks. The Treasurer will be charged for the Us of the printer. Title User wants to print specially formatted text on printer at resort site Description At a seminar located at a country resort, a factotum and general gofer has been asked to provide 80 sets of ten keywords/phrases, clearly printed on 2-inch by 1-inch paper slips for use in a get acquainted exercise. Costs are to be minimized. Gofer has a laptop with a word processer program. Resort has a wi-fi network available to users and a networked MFDat the business centre. Attendant at business center will charge for any printed sheets removed from premises Goal Gofer must provide paper slips of the specified size with legible text, promptly and cheaply Preconditions TBD - to an extent, this is part of solution since at the present time site does not have advanced capabilities that we which to define. However, we can note that security is one of many concerns. Trigger Gofer uses word processer program to lay out the phrases in a table format, adjusting margins, font size and spacing to use landscape format to print five phrases per line and eight lines of phrases per page. The required 80 phrases should be handled in two pages. Steps 1. Gofer creates the page descriptions on his word processor program. 2. Gofer locates an available printer 3. User initiates printing. (put in a validate job operation?) 4. The system (or the application) submits the job to the printer. 5. Two sheets are printed with 80 phrases. User must then use scissors to cut part Alternate flows ?? Postconditions Gofer will be charged for printing two single sided sheets. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_0001_01CBFBB5.DD0F9770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like th= is use case format (Thanks Justin Hutchings). I submit the next two, for Cl= oud and/or IPP Everywhere.  They were observed at a nursing conference=  I am currently at  (with my wife… I haven’t changed= careers yet) and they are very real and I suspect, not uncommon. Current s= olutions were inconvenient and time consuming, and the output was not compl= etely satisfactory,

 

Title

Use= r of standard application wants to print checks at offsite location.

Description

The treasurer of a small training co= mpany, that is holding a meeting and seminar at a resort, needs to print ou= t 20  checks for training personnel.  He uses QuickBooks ® fo= r accounting and to print out checks, and he updates the information in thi= s program to  reflect latest hours worked, bonuses, etc. The resort si= te does have 802.11 and does have a printer available for guest use (for a = fee). The treasurer has check blanks.

Goal

Treasurer can submit proper  checks with current balances to personn= el during closing ceremony at remote site  using the same accounting s= oftware he uses to track all expenses.

Precondi= tions

TBD – to an extent, this is part of solution since at the = present time site does not have advanced capabilities that we which to defi= ne. However, we can note that security is one of many concerns.<= /p>

Trigger

User loads check blanks on printer and initia= tes a print command from an application that can generate print content

Steps

1.   &= nbsp;  User updates his accounting grogram, de= termines what checks need to be printed and insures that checks amounts, pa= yees and signature are correct.

2.      User = locates an available printer

3.      User = ensures that printer is free, locks out other jobs and loads the check blan= ks.

4.  &= nbsp;   User initiates check printing. (p= ut in a validate job operation?)

5.      The = system (or the application) submits the job to the printer.

<= p class=3DMsoPlainText style=3D'margin-left:.5in;text-indent:-.25in;mso-lis= t:l0 level1 lfo1'>6.      <= /span>Checks are printed and immediately taken off the pri= nter.

7.  = ;    Cost of printing  (not inc= luding media) is calculated and sent to treasurer’s account.

Alternate flows

??

Postconditions

The= accounting program properly reflects all outstanding checks. The treasurer= has a stack of properly printed checks.  The Treasurer  will be = charged for the

Us of the printer.

 

 

Title

User wants to print specially fo= rmatted text on printer at resort site

Description

At a semina= r located at a country resort, a factotum and general gofer has been asked = to provide 80 sets of ten keywords/phrases, clearly printed on 2-inch by 1-= inch paper slips for use in a get acquainted exercise. Costs are to be mini= mized. Gofer has a laptop with a word processer program. Resort has a wi-fi= network available to users and a networked MFDat the business centre. Atte= ndant at business center will charge for any printed sheets removed from pr= emises

Goal

Gofer must provide paper slips=  of the specified size with legible  text, promptly and cheaply<= o:p>

Preconditions

TBD – to an extent, th= is is part of solution since at the present time site does not have advance= d capabilities that we which to define. However, we can note that security = is one of many concerns.

Trigger

=

Gofer use= s word processer program to lay out the phrases in  a table format, ad= justing margins, font size and spacing to use landscape format to print fiv= e phrases per line and eight lines of phrases per page. The required 80&nbs= p; phrases should be handled in two pages.

Step= s

1.      Gofer creates the page descriptions on his word processor program. <= o:p>

2.   = ;   Gofer locates an available printer

3.   =    User initiates printing. (put in a val= idate job operation?)

4.      The system (or = the application) submits the job to the printer.

5.      Two sheets are printed with 80 phrases. User must then use sc= issors to cut part

Alternate flows

??=

Postconditi= ons

=

Gofer will be charged for printing  two  = single sided sheets.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_0001_01CBFBB5.DD0F9770-- --===============1859543706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --===============1859543706==-- From 8hi3p9@bma.biglobe.ne.jp Sat Apr 16 16:51:45 2011 Return-Path: <8hi3p9@bma.biglobe.ne.jp> X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 075AAE06BA for ; Sat, 16 Apr 2011 16:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.696 X-Spam-Level: X-Spam-Status: No, score=-87.696 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFQnFMzYNDmT for ; Sat, 16 Apr 2011 16:51:44 -0700 (PDT) Received: from telesp.net.br (unknown [187.75.79.229]) by ietfc.amsl.com (Postfix) with ESMTP id 4084AE0661 for ; Sat, 16 Apr 2011 16:51:44 -0700 (PDT) Received: from 187.75.79.229(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MMB9S-2909xy-10 for ; Sat, 16 Apr 2011 20:51:42 -0300 From: To: Subject: Newsletter Sat, 16 Apr 2011 20:51:42 -0300 Date: Sat, 16 Apr 2011 20:51:42 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: lbwqhj_49 Message-ID: <7986667813.IVC4O7NT439924@oioicwxvf.quoihbrjbgnt.biz> Hey!! Do you want a prosperous future, double in money earning power, and the admiration of all? Special offer: We can assist with Diplomas from prestigious universities based on your present knowledge and work experience. Get a Degree in 6 weeks with our program! ~Our program will let EVERYONE with professional experience gain a 100% verified Degree: ~Doctorate ~Bachelors ~Masters - Think about it... - Just follow YOUR Dreams! - Live a much better life by earning or upgrading your degree. This is a nice way to make a right move and receive your due benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time. Contact us NOW to start improving your life! ~CONTACT US~ 1-310-205-2502 You must leave us a voice message with your name and phone number with country code if outside USA and we will contact you asap. It's your decision... Make the right move. Best regards. Do Not Reply to this Email. We do not reply to text inquiries, and our server will reject all response traffic. We apologize for any inconvenience this may have caused you. From ipp-bounces@pwg.org Sun Apr 17 04:09:45 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 06AF1E0664 for ; Sun, 17 Apr 2011 04:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZeAS60S88je for ; Sun, 17 Apr 2011 04:09:43 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id DDCDAE0663 for ; Sun, 17 Apr 2011 04:09:42 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 3F8A7794D7; Sun, 17 Apr 2011 07:09:23 -0400 (EDT) X-Original-To: IPP@pwg.org Delivered-To: ipp@pwg.org Received: from USA7109MR003.ACS-INC.COM (usa7109mr003.acs-inc.com [63.101.151.12]) by pwg.org (Postfix) with ESMTP id 799F2794D1 for ; Sun, 17 Apr 2011 07:09:09 -0400 (EDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4CAHfJqk0Nl9IPkWdsb2JhbACCYZt4AYc2FAEBAQEUEhQlwn6DGYJYBIVijB0 X-IronPort-AV: E=Sophos;i="4.64,227,1301893200"; d="scan'208,217";a="31397004" Received: from usa7061gw002.na.xerox.net ([13.151.210.15]) by USA7109MR003.ACS-INC.COM with ESMTP; 17 Apr 2011 06:09:08 -0500 Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA7061GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Apr 2011 04:09:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 17 Apr 2011 04:08:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3998 errata Thread-Index: Acv879mfzQQk21jOTKesfXAOuRAulw== From: "Zehler, Peter" To: X-OriginalArrivalTime: 17 Apr 2011 11:09:08.0145 (UTC) FILETIME=[DF270210:01CBFCEF] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] RFC3998 errata X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2019215781==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 3F8A7794D7.A9274 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============2019215781== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBFCEF.DF066A6D" This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFCEF.DF066A6D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 There appears to be a cut and paste error in the definition of the "printer-state-reasons" value 'hold-new-jobs' in rfc3998. The current text is: 8.1. 'hold-new-jobs' Value =20 =20 'hold-new-jobs': The operator has issued the Hold-New-Jobs operation (see section 3.3.1 ) or other means, but the output-device(s) are taking an appreciable time to stop. Later, when all output has stopped, the "printer-state" becomes 'stopped', and the 'paused' value replaces the 'moving-to-paused' value in the "printer- state-reasons" attribute. This value MUST be supported if the Hold-New-Jobs operation is supported and the implementation takes significant time to pause a device in certain circumstances. =20 I believe it should be something like: 8.1. 'hold-new-jobs' Value =20 =20 'hold-new-jobs': The operator has issued the Hold-New-Jobs operation (see section 3.3.1 ) or has initiated the holding of new jobs by=20 other means. This value indicates that all Jobs subsequently=20 submitted to the Printer will be placed into the 'pending-held'=20 state. Thus all newly accepted jobs will be automatically held=20 by the Printer. This "printer-state-reasons" value will be removed=20 when the Operator issues the Release-Held-New-Jobs Operation or=20 releases the holding of new jobs by other means.=20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com =20 Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CBFCEF.DF066A6D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,<= /p>

 

There app= ears to be a cut and paste error in the definition of the ”printer-st= ate-reasons” value  ‘hold-new-jobs’ in rfc3998.=

The current text is:

8.1= .  'hold-new-jobs' Value

&=
nbsp;
 
=
   'hold-new-jobs': The operator has issued the Hold-New-Jobs ope=
ration
      (see=
 section 3.3.1=
) or other means, but the output-device(s) are
<= pre style=3D'page-break-before:always'>      taking an appreciable time to stop.=   Later, when all output has
 &n=
bsp;    stopped, the "printer-state" becomes 'stop=
ped', and the 'paused'
   &=
nbsp;  value replaces the 'moving-to-paused' value in the "printe=
r-
      state-re=
asons" attribute.  This value MUST be supported if the=

      Hold-New-Jobs operati=
on is supported and the implementation takes
      significant time to pause a device in cer=
tain circumstances.

 =

I believe it should be something like:<= /o:p>

8.1.&nb= sp; 'hold-new-jobs' Value

 =

 
  =
 'hold-new-jobs': The operator has issued the Hold-New-Jobs operation<=
/o:p>
      (see section 3.3.1) or has=
 initiated the holding of new jobs by 
&nb=
sp;     other means. This value indicates that all Jobs=
 subsequently 
    &nb=
sp; submitted to the Printer will be placed into the ‘pending-held=
217; 
      state=
.  Thus all newly accepted jobs will be automatically held =

      by the Printer. =
 This “printer-state-reasons” value will be removed =

      when the Operator iss=
ues the Release-Held-New-Jobs Operation or 
      releases the holding of new jobs by other =
means.

 

 

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441<= span style=3D'color:#1F497D'>
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'= >Webster NY, 14580-9701

 

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CBFCEF.DF066A6D-- --===============2019215781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --===============2019215781==-- From ipp-bounces@pwg.org Sun Apr 17 04:25:55 2011 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 768C5E066E for ; Sun, 17 Apr 2011 04:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBFqeZucLZwP for ; Sun, 17 Apr 2011 04:25:52 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 67884E065A for ; Sun, 17 Apr 2011 04:25:52 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 9489179516; Sun, 17 Apr 2011 07:25:28 -0400 (EDT) X-Original-To: IPP@pwg.org Delivered-To: ipp@pwg.org Received: from USA7109MR002.ACS-INC.COM (usa7109mr002.acs-inc.com [63.101.151.11]) by pwg.org (Postfix) with ESMTP id 4662979513 for ; Sun, 17 Apr 2011 07:25:07 -0400 (EDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYBAPDMqk0Nh9IPgWdsb2JhbACCYZUvhkkBhzYUAQEWJiXDDIMZglgEhWKMHQ X-IronPort-AV: E=Sophos;i="4.64,227,1301893200"; d="scan'208,217";a="30087620" Received: from usa0300gw002.na.xerox.net ([13.135.210.15]) by USA7109MR002.ACS-INC.COM with ESMTP; 17 Apr 2011 06:25:07 -0500 Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Apr 2011 07:24:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [IPP] RFC3998 errata Date: Sun, 17 Apr 2011 04:24:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPP] RFC3998 errata Thread-Index: Acv88hELRJzavuy2RN6UcpVBPMCO3w== From: "Zehler, Peter" To: "Zehler, Peter" , X-OriginalArrivalTime: 17 Apr 2011 11:24:54.0580 (UTC) FILETIME=[13458740:01CBFCF2] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478617152==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 9489179516.A9985 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============0478617152== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBFCF2.127C0A4F" This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFCF2.127C0A4F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Note that the definition of the Hold-New-Jobs operation states When the Printer completes all the 'pending' and 'processing' jobs, it enters the 'idle' state as usual. An operator monitoring Printer state changes will know when the Printer has completed all current jobs because the Printer enters the 'idle' state. Thus the Printer does not enter the 'stopped' state as currently indicated in the text. It is the Pause-Printer and=20 Pause-Printer-After-Current-Job operations that move the state of the Printer to stopped' and put the 'moving-to-paused' Or 'paused' values into "printer-state-reasons".=20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler, Peter Sent: Sunday, April 17, 2011 7:09 AM To: IPP@pwg.org Subject: [IPP] RFC3998 errata =20 All, =20 There appears to be a cut and paste error in the definition of the "printer-state-reasons" value 'hold-new-jobs' in rfc3998. The current text is: 8.1. 'hold-new-jobs' Value =20 =20 'hold-new-jobs': The operator has issued the Hold-New-Jobs operation (see section 3.3.1 ) or other means, but the output-device(s) are taking an appreciable time to stop. Later, when all output has stopped, the "printer-state" becomes 'stopped', and the 'paused' value replaces the 'moving-to-paused' value in the "printer- state-reasons" attribute. This value MUST be supported if the Hold-New-Jobs operation is supported and the implementation takes significant time to pause a device in certain circumstances. =20 I believe it should be something like: 8.1. 'hold-new-jobs' Value =20 =20 'hold-new-jobs': The operator has issued the Hold-New-Jobs operation (see section 3.3.1 ) or has initiated the holding of new jobs by=20 other means. This value indicates that all Jobs subsequently=20 submitted to the Printer will be placed into the 'pending-held'=20 state. Thus all newly accepted jobs will be automatically held=20 by the Printer. This "printer-state-reasons" value will be removed=20 when the Operator issues the Release-Held-New-Jobs Operation or=20 releases the holding of new jobs by other means.=20 =20 =20 Peter Zehler Xerox Research Center Webster Email: Peter.Zehler@Xerox.com Voice: (585) 265-8755 FAX: (585) 265-7441 US Mail: Peter Zehler Xerox Corp. 800 Phillips Rd. M/S 128-25E Webster NY, 14580-9701=20 =20 --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner , and is believed to be clean.=20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CBFCF2.127C0A4F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

Note that the definition of the Hold-New-Jobs operation sta= tes

   it enters the 'idle' state as usual.  An operator m= onitoring Printer

   state changes will know when the Printer has c= ompleted all current

   jobs because the Printer enters the 'idle' = state.

Thus the Printer does not enter the ‘stopped’ state as curr= ently indicated in the text.  It is the Pause-Printer and <= /span>

Pause-Printer-= After-Current-Job operations that move the state of the Printer to stopped&= #8217; and put the ‘moving-to-paused’

Or ‘paused’ valu= es into “printer-state-reasons”.

 

 

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441US Mail: Peter Zehler
Xerox Corp.
800 Phi= llips Rd.
M/S 128-25E
Webster NY, 14580-9701<= span style=3D'color:#1F497D'>

=

 =

From: ipp-bounces@pwg.org [mailto:ipp-= bounces@pwg.org] On Behalf Of Zehler, Peter
Sent: Sunday, = April 17, 2011 7:09 AM
To: IPP@pwg.org
Subject: [IPP] R= FC3998 errata

&n= bsp;

All,

=  

There appears to be a cut and pas= te error in the definition of the ”printer-state-reasons” value=  ‘hold-new-jobs’ in rfc3998.

The current text is:

8.1.  'hold-n= ew-jobs' Value

 
 
   'hold-new-=
jobs': The operator has issued the Hold-New-Jobs operation
      (see section 3.3.1) or other means, b=
ut the output-device(s) are
  &n=
bsp;   taking an appreciable time to stop.  Later, when all =
output has
<=
span style=3D'font-size:12.0pt;color:black'>      =
stopped, the "printer-state" becomes 'stopped', and the 'paused'<=
o:p>
      value repl=
aces the 'moving-to-paused' value in the "printer-
      state-reasons" attribute.=
  This value MUST be supported if the
      Hold-New-Jobs operation is supported and th=
e implementation takes
   &=
nbsp;  significant time to pause a device in certain circumstances.
 
I believe it should be something like:
8.1.  'hold-new-jobs' Va=
lue
 
 
   'hold-new-jobs': The =
operator has issued the Hold-New-Jobs operation
      (see section 3.3.1) or has initiated the holding=
 of new jobs by 
    &=
nbsp; other means. This value indicates that all Jobs subsequently 
      submitted to the P=
rinter will be placed into the ‘pending-held’ 
      state.  Thus all newly=
 accepted jobs will be automatically held 
      by the Printer.  This “printer-s=
tate-reasons” value will be removed 
      when the Operator issues the Release-Held-N=
ew-Jobs Operation or 
   &n=
bsp;  releases the holding of new jobs by other means. 
 
 
Peter Zehler<=
/span>

Xerox Research Center=
 Webster
Email: Peter=
.Zehler@Xerox.com
Voic=
e: (585) 265-8755
FAX: (58=
5) 265-7441
US Mail: Peter=
 Zehler
Xerox Corp.=

800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 
 =
;

-- 
This message has been scanned for vi=
ruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


------_=_NextPart_001_01CBFCF2.127C0A4F--

--===============0478617152==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0478617152==--

From 6ai@fuyucorp.com  Sun Apr 17 06:15:40 2011
Return-Path: <6ai@fuyucorp.com>
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AA5EDE076B for ; Sun, 17 Apr 2011 06:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.159
X-Spam-Level: 
X-Spam-Status: No, score=-91.159 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5yFu95dKyBW for ; Sun, 17 Apr 2011 06:15:40 -0700 (PDT)
Received: from homeuser207-232.ccl.perm.ru (homeuser207-232.ccl.perm.ru [89.148.207.232]) by ietfc.amsl.com (Postfix) with ESMTP id 0B792E0694 for ; Sun, 17 Apr 2011 06:15:31 -0700 (PDT)
Received: from  89.148.207.232 (account  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 172687623 for ; Sun, 17 Apr 2011 18:15:39 +0500
From: 
To: 
Subject: Newsletter Sun, 17 Apr 2011 18:15:39 +0500
Date: Sun, 17 Apr 2011 18:15:39 +0500
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: 7bit
X-Mailer: njky_94
Message-ID: <4110849388.MS9A1XJM650092@tmcnmtjihlra.abhasemgnsatlqk.va>

Hey bud!!

Do you want a more satisfactory future,  double in money earning power, and the praise of all?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and professional experience.

Get a Degree in 5 weeks with our program! 


~Our program will let ANYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- Just follow YOUR Dreams!
- Live a wonderful life by earning or upgrading your degree.


This is a rare way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


If you want to get better - you must Call 7 days a week! to start improving your life!


~CALL US~


1-310-205-2502



Please leave us a message with your phone number with country code if outside USA and name and we'll get back to you as soon as possible.


It is your chance...
Make the right move.




Best regards.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From p86425@bma.biglobe.ne.jp  Sun Apr 17 09:35:27 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2BAB4E0670; Sun, 17 Apr 2011 09:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -86.932
X-Spam-Level: 
X-Spam-Status: No, score=-86.932 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9gVgyBcQXkO; Sun, 17 Apr 2011 09:35:26 -0700 (PDT)
Received: from telesp.net.br (189-46-208-230.dsl.telesp.net.br [189.46.208.230]) by ietfc.amsl.com (Postfix) with ESMTP id 2022AE066B; Sun, 17 Apr 2011 09:35:25 -0700 (PDT)
Received: from  189.46.208.230 (account , ,  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 932615912 for ; Sun, 17 Apr 2011 13:35:25 -0300
From: , , 
To: , , 
Subject: Newsletter Sun, 17 Apr 2011 13:35:25 -0300
Date: Sun, 17 Apr 2011 13:35:25 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: nqrrnctgwc_33
Message-ID: <9798501904.TRX10NT5544593@nsawihelnvwkos.fcrmiecpjomrp.tv>

Hey bud!!

Do you want an improved future, grow in money earning, and the admiration of all?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will help EVERYONE with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- Just follow YOUR Dreams!
- Live a wonderful life by earning or upgrading your degree.


This is a rare way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


Call us 24 hours to start improving your life!


~CALL US~


1-305-460-2287



You should leave us a message with your name and phone number with country code if outside USA and we will contact you as soon as possible.


It is your chance...
Make the right move.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Sun Apr 17 13:09:52 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BA555E0681 for ; Sun, 17 Apr 2011 13:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.156
X-Spam-Level: 
X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FraiG6du23QO for ; Sun, 17 Apr 2011 13:09:51 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id AACB5E0737 for ; Sun, 17 Apr 2011 13:09:51 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A2DE17952B; Sun, 17 Apr 2011 16:09:34 -0400 (EDT)
X-Original-To: IPP@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id B349079529 for ; Sun, 17 Apr 2011 16:09:19 -0400 (EDT)
MIME-version: 1.0
Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJT00FI2BZ53U10@mail-out.apple.com> for IPP@pwg.org; Sun, 17 Apr 2011 13:09:18 -0700 (PDT)
X-AuditID: 11807136-b7c6bae000004a34-91-4dab48ed08bc
Received: from [17.151.77.176] (Unknown_Domain [17.151.77.176]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay15.apple.com (Apple SCV relay) with SMTP id E4.92.18996.EE84BAD4; Sun, 17 Apr 2011 13:09:18 -0700 (PDT)
Subject: Re: [IPP] RFC3998 errata
From: Michael Sweet 
In-reply-to: 
Date: Sun, 17 Apr 2011 13:09:17 -0700
Message-id: 
References: 
To: "Zehler, Peter" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: IPP@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0623309353=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: A2DE17952B.A94DA
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0623309353==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_02YCBUiXHaDK8XdFBTeg9Q)"


--Boundary_(ID_02YCBUiXHaDK8XdFBTeg9Q)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

On Apr 17, 2011, at 4:08 AM, Zehler, Peter wrote:
> All,
>=20=20
> There appears to be a cut and paste error in the definition of the =94pri=
nter-state-reasons=94 value  =91hold-new-jobs=92 in rfc3998.
> The current text is:
> ...=20
>=20
> I believe it should be something like:
> 8.1.  'hold-new-jobs' Value
>=20
>=20=20
>=20=20
>    'hold-new-jobs': The operator has issued the Hold-New-Jobs operation
>       (see section 3.3.1) or has initiated the holding of new jobs by=20
>       other means. This value indicates that all Jobs subsequently=20
>       submitted to the Printer will be placed into the =91pending-held=92=
=20
>       state.  Thus all newly accepted jobs will be automatically held=20
>       by the Printer.  This =93printer-state-reasons=94 value will be rem=
oved=20
>       when the Operator issues the Release-Held-New-Jobs Operation or=20
>       releases the holding of new jobs by other means.=20
>=20

Agreed, please go ahead and post this at:

	http://www.rfc-editor.org/errata.php

and I think at that point Ira and I will get contacted for confirmation.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_02YCBUiXHaDK8XdFBTeg9Q)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


On Apr 17, 2011, at 4:08 AM, Zehler, Peter wrote:
All,
 
There a=
ppears to be a cut and paste error in the definition of the =94printer-stat=
e-reasons=94 value  =91hold-new-jobs=92 in rfc3998.
The cu=
rrent text is:
... 
I believe=
 it should be something like:
8.1.  'hold-new-jobs' Value
 
 
   'hold-new-jobs': T=
he operator has issued the Hold-New-Jobs operation
<=
pre style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m=
argin-left: 0in; font-size: 10pt; font-family: 'Courier New'; page-break-be=
fore: always; ">  =
;    (see section 3.3.=
1) or has initiated the holding of new jobs by
= 
 &nbs=
p;    other means. This value indicates that all Jobs subseq=
uently 
      submitted to the Printe=
r will be placed into the =91pending-held=92 
  &nbs=
p;   state.  Thus all newly accepted jobs will be automatica=
lly held 
      by the Printer. =
 This =93printer-state-reasons=94 value will be removed <=
/pre>
 =
;     when the Operator issues the Release-Held-New-Job=
s Operation or 
      releases the ho=
lding of new jobs by other means. 


Agreed, please go ahead and post this a=
t:


and I think at th=
at point Ira and I will get contacted for confirmation.



______________________________________________________________________=
__
Michael Sweet, Senior Printing System Engineer, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_02YCBUiXHaDK8XdFBTeg9Q)--

--===============0623309353==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0623309353==--

From n5811230@ms29.hinet.net  Sun Apr 17 18:24:36 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4993EE066C; Sun, 17 Apr 2011 18:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.99
X-Spam-Level: 
X-Spam-Status: No, score=-94.99 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VQVTdoxijww; Sun, 17 Apr 2011 18:24:35 -0700 (PDT)
Received: from anteldata.net.uy (r190-134-166-59.dialup.adsl.anteldata.net.uy [190.134.166.59]) by ietfc.amsl.com (Postfix) with ESMTP id 694A4E0690; Sun, 17 Apr 2011 18:24:34 -0700 (PDT)
Received: from  190.134.166.59 (account ,  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 875790634 for ; Sun, 17 Apr 2011 22:24:34 -0300
From: , 
To: , 
Subject: Newsletter Sun, 17 Apr 2011 22:24:34 -0300
Date: Sun, 17 Apr 2011 22:24:34 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: zqjvqonzg-63
Message-ID: <8299972065.ZZIJUIAB840303@awbdhoqpxdau.nxyuk.su>

Hey bud!!

Do you want a suitable future, grow in money earning power, and brownie points?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will help EVERYONE with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- Just follow YOUR Dreams!
- Live a much better life by earning or upgrading your degree.


This is a good chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


Contact Today to start improving your life!


~CALL US~


1-305-460-2287



You should leave us a message with your phone number with country code if outside USA and name and we'll call you asap.


It is your chance...
Make the right decision.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Sun Apr 17 20:39:40 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C155AE066A for ; Sun, 17 Apr 2011 20:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oalWTlIsRAVR for ; Sun, 17 Apr 2011 20:39:39 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id A1F41E0661 for ; Sun, 17 Apr 2011 20:39:39 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 83E247953C; Sun, 17 Apr 2011 23:39:23 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-wy0-f174.google.com (mail-wy0-f174.google.com [74.125.82.174]) by pwg.org (Postfix) with ESMTP id C4D5B79539 for ; Sun, 17 Apr 2011 23:39:09 -0400 (EDT)
Received: by wya21 with SMTP id 21so4692603wya.5 for ; Sun, 17 Apr 2011 20:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=HdryBDrmwR2C0Mrp6qfNb8KTpSzfIjN0HjjRc1hHPsw=; b=GB0oj0aDnhDO2RbFQgqx/JFwvwsjpK1yBVnRXU9/CEhC2BuPnrXLDvsrEc1Eg2osqC hv446H1rVPLI8gJPmzPj2roZZftelPp3YwdgZLmhMD1DQjvSQzacfNIM7yrcJFwz4ePP O4RrEBrlF0zQ/ahZ4jEniQPV0YfIPQW14jK68=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iS6CjvEsriEWJcf2Ei6rJZKtIMzxKuSFyE2zmtNbZHrPjY3/TVdczCLJWfE2VgaYmf +W0sKl/RqOTg9qZ1uuRKX+t/rDgqIuAsqekjbM/ivCpk0UGi74F8zgfKjWlDhsZTnVu+ yD4GrINZhXB7afhwViel7hTcXcc6xPmUpiRFU=
MIME-Version: 1.0
Received: by 10.227.208.202 with SMTP id gd10mr4638987wbb.23.1303097948663; Sun, 17 Apr 2011 20:39:08 -0700 (PDT)
Received: by 10.227.155.200 with HTTP; Sun, 17 Apr 2011 20:39:08 -0700 (PDT)
Date: Sun, 17 Apr 2011 23:39:08 -0400
Message-ID: 
From: Ira McDonald 
To: ipp@pwg.org, Michael R Sweet , Paul Tykodi , Ira McDonald 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] IPP Agenda - 1pm EDT Monday 18 April 2011
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0512715222=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 83E247953C.A9329
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0512715222==
Content-Type: multipart/alternative; boundary=0015174bde885671a504a1292247


--0015174bde885671a504a1292247
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Our next IPP WG call will be on Monday.

 Monday 18 April 10-11am US PST / 1-2pm US EST

 Call-in toll-free number (US/Canada): 1-866-469-3239
 Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
 Call-in toll number (US/Canada): 1-408-856-9570 (Backup)

 Attendee Access Code: *******#
 Attendee ID Code: # (empty)

If you need the Attendee Access code, please email me a request.


*** Main Objective - Review IPP JPS3 and PWG Raster specs ***

Agenda:

(1) PWG IP Policy and Minute Taker
     - Mike?

(2) Approve IPP minutes from previous meeting
     - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.pdf

(3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (Mike)
     -
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pdf

(4) Review PWG Raster (Mike)
     - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf

(5) Discussion of IPP Everywhere (Mike/Ira)
     - http://pwg-wiki.wikispaces.com/IPP+Everywhere
     - Review use cases from IPP/Cloud Imaging mailing lists

(6) Next Steps
     - IPP WG teleconference on Monday 2 May
     - Review IPP Scan and IPP over USB drafts
     - All - post more use cases to IPP/Cloud Imaging mailing lists

Cheers,
- Ira (IPP WG Co-Chair)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--0015174bde885671a504a1292247
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,


Our next IPP WG call will be on Monday.



=A0Monday 18 April 10-11am US PST / 1-2pm US EST



=A0Call-in toll-free number (US/Canada): 1-866-469-3239

=A0Call-in toll number (US/Canada): 1-650-429-3300 (Primary)

=A0Call-in toll number (US/Canada): 1-408-856-9570 (Backup)



=A0Attendee Access Code: *******#

=A0Attendee ID Code: # (empty)



If you need the Attendee Access code, please email me a request.





*** Main Objective - Review IPP JPS3 and PWG Raster specs ***


Agenda:



(1) PWG IP Policy and Minute Taker

 =A0 =A0=A0 - Mike?



(2) Approve IPP minutes from previous meeting
=A0=A0 =A0 - =
ftp://ftp.pwg.org/=
pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.pdf
















(3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (Mike)














 =A0 =A0=A0 - ftp://ftp.pwg.o=
rg/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pdf

(4) R=
eview PWG Raster (Mike)

=A0 =A0=A0 - ftp://ftp.pwg.org/pub/pwg=
/ipp/wd/wd-ippraster10-20110327-rev.pdf

(5) Discussion of IPP Ev=
erywhere (Mike/Ira)

=A0=A0=A0=A0 - ht=
tp://pwg-wiki.wikispaces.com/IPP+Everywhere=A0=A0=A0=A0 
=A0=A0=A0=
=A0 - Review use cases from IPP/Cloud Imaging mailing lists


(6) Next Steps
=A0=A0=A0=A0 - IPP WG teleconference on Mond=
ay 2 May
=A0=A0=A0=A0 - Review IPP Scan and IPP over USB drafts
=A0=
=A0=A0=A0 - All - post more use cases to IPP/Cloud Imaging mailing lists
Cheers,

- Ira (IPP WG Co-Chair)

Ira McDonald (Mus=
ician / Software Architect)
Chair - Linux Foundation Open Printing WGCo-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desi=
gnated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic<=
/a>
http://sites.google.com/site/highnorth=
inc

mailto:blueroo=
fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S=
aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2=
21=A0 Grand Marais, MI 49839

=A0 906-494-2434





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--0015174bde885671a504a1292247--

--===============0512715222==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0512715222==--

From ipp-bounces@pwg.org  Mon Apr 18 03:29:08 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A57F5E069D for ; Mon, 18 Apr 2011 03:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLWqoOzZN1lg for ; Mon, 18 Apr 2011 03:29:04 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 31942E066A for ; Mon, 18 Apr 2011 03:29:03 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A231279542; Mon, 18 Apr 2011 06:28:38 -0400 (EDT)
X-Original-To: IPP@pwg.org
Delivered-To: ipp@pwg.org
Received: from USA7109MR002.ACS-INC.COM (usa7109mr002.acs-inc.com [63.101.151.11]) by pwg.org (Postfix) with ESMTP id 829C57953F for ; Mon, 18 Apr 2011 06:28:22 -0400 (EDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlUAAJYRrE0Nh9IPmWdsb2JhbACXWo4BFAEBAQEBCAsLBxQliQq6GYMZglgEhWKMHIon
X-IronPort-AV: E=Sophos;i="4.64,231,1301893200"; d="scan'208";a="30356348"
Received: from usa0300gw002.na.xerox.net ([13.135.210.15]) by USA7109MR002.ACS-INC.COM with ESMTP; 18 Apr 2011 05:28:21 -0500
Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 06:28:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 18 Apr 2011 03:28:04 -0700
Message-ID: 
In-Reply-To: <20110418102612.99968E0733@rfc-editor.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Technical Errata Reported] RFC3998 (2783)
Thread-Index: Acv9swxAy6aLF1QEQEOl9IKhKU1maQAAC/Wg
References: <20110418102612.99968E0733@rfc-editor.org>
From: "Zehler, Peter" 
To: 
X-OriginalArrivalTime: 18 Apr 2011 10:28:07.0879 (UTC) FILETIME=[4F21F570:01CBFDB3]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] FW: [Technical Errata Reported] RFC3998 (2783)
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: A231279542.A873F
X-pwg-MailScanner-From: ipp-bounces@pwg.org

The rfc3998 errata has been submitted.


Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

-----Original Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20
Sent: Monday, April 18, 2011 6:26 AM
To: kugler@us.ibm.com; harryl@us.ibm.com; hastings@cp10.es.xerox.com;
presnick@qualcomm.com; alexey.melnikov@isode.com; stpeter@stpeter.im;
carl@manros.com
Cc: Zehler, Peter; rfc-editor@rfc-editor.org
Subject: [Technical Errata Reported] RFC3998 (2783)


The following errata report has been submitted for RFC3998, "Internet
Printing Protocol (IPP): Job and Printer Administrative Operations".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D3998&eid=3D2783

--------------------------------------
Type: Technical
Reported by: Peter Zehler 

Section: 8.1

Original Text
-------------
8.1.  'hold-new-jobs' Value





   'hold-new-jobs': The operator has issued the Hold-New-Jobs operation

      (see section 3.3.1) or other means, but the output-device(s) are

      taking an appreciable time to stop.  Later, when all output has

      stopped, the "printer-state" becomes 'stopped', and the 'paused'

      value replaces the 'moving-to-paused' value in the "printer-

      state-reasons" attribute.  This value MUST be supported if the

      Hold-New-Jobs operation is supported and the implementation takes

      significant time to pause a device in certain circumstances.



Corrected Text
--------------
8.1.  'hold-new-jobs' Value





   'hold-new-jobs': The operator has issued the Hold-New-Jobs operation

      (see section 3.3.1) or has initiated the holding of new jobs by=20

      other means. This value indicates that all Jobs subsequently=20

      submitted to the Printer will be placed into the 'pending-held'=20

      state.  Thus all newly accepted jobs will be automatically held=20

      by the Printer.  This "printer-state-reasons" value will be
removed=20

      when the Operator issues the Release-Held-New-Jobs Operation or=20

      releases the holding of new jobs by other means.=20



Notes
-----
This is a cut and paste error.=20

Note that the definition of the Hold-New-Jobs operation (3.3.1) states:



   "When the Printer completes all the 'pending' and 'processing' jobs,

   it enters the 'idle' state as usual.  An operator monitoring Printer

   state changes will know when the Printer has completed all current

   jobs because the Printer enters the 'idle' state."



Thus the Printer does not enter the 'stopped' state as currently
indicated in the text.  It is the Pause-Printer=20

and Pause-Printer-After-Current-Job operations that move the state of
the Printer to stopped' and put the=20

'moving-to-paused' or 'paused' values into "printer-state-reasons".

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary.=20

--------------------------------------
RFC3998 (draft-ietf-ipp-ops-set2-04)
--------------------------------------
Title               : Internet Printing Protocol (IPP): Job and Printer
Administrative Operations
Publication Date    : March 2005
Author(s)           : C. Kugler, H. Lewis, T. Hastings, Ed.
Category            : PROPOSED STANDARD
Source              : Internet Printing Protocol
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From s326941nn@ms2.hinet.net  Mon Apr 18 04:55:20 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5FA5DE068A; Mon, 18 Apr 2011 04:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.626
X-Spam-Level: 
X-Spam-Status: No, score=-91.626 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ImPaztEB9+a; Mon, 18 Apr 2011 04:55:19 -0700 (PDT)
Received: from host70-208-static.58-217-b.business.telecomitalia.it (host70-208-static.58-217-b.business.telecomitalia.it [217.58.208.70]) by ietfc.amsl.com (Postfix) with ESMTP id A214EE0664; Mon, 18 Apr 2011 04:55:19 -0700 (PDT)
Received: from  217.58.208.70 (account , ,  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 388758252 for ; Mon, 18 Apr 2011 12:55:14 +0100
From: , , 
To: , , 
Subject: Newsletter Mon, 18 Apr 2011 12:55:14 +0100
Date: Mon, 18 Apr 2011 12:55:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: pexuq-27
Message-ID: <4401472854.AL27T83F707657@zofpvreimer.fvsrysl.ru>

Hello!

Do you want an extraordinary future, soar in money earning power, and  pat on the back :)?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and professional experience.

Get a Degree in 4 weeks with our program! 


~Our program will let EVERYONE with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- Realize YOUR Dreams!
- Live a much better life by earning or upgrading your degree.


This is a splendid chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


If you want to get better - you must Call us 24 hours to start improving your life!


~CALL US~


1-305-460-2287



You should leave us a voice message with your name and phone number with country code if outside USA and we'll get back to you asap.


It's your chance...
Make the right move.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Mon Apr 18 05:29:23 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C43E4E0664 for ; Mon, 18 Apr 2011 05:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu9+CQa1YDiA for ; Mon, 18 Apr 2011 05:29:19 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 0B7DAE06F2 for ; Mon, 18 Apr 2011 05:29:18 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id B732879543; Mon, 18 Apr 2011 08:28:49 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from USA7109MR001.ACS-INC.COM (usa7109mr001.acs-inc.com [63.101.151.9]) by pwg.org (Postfix) with ESMTP id 2C03179542 for ; Mon, 18 Apr 2011 08:28:31 -0400 (EDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYAAMUtrE0Nh9IPmWdsb2JhbACCYZR5hkkBhzgUAQEBAQEICwsHFCXDQoMJEIJYBIVijByDSoVh
X-IronPort-AV: E=Sophos;i="4.64,232,1301893200"; d="scan'208,217";a="30796383"
Received: from usa0300gw002.na.xerox.net ([13.135.210.15]) by USA7109MR001.ACS-INC.COM with ESMTP; 18 Apr 2011 07:28:30 -0500
Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 08:28:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] IPP Agenda - Live Meeting Info
Date: Mon, 18 Apr 2011 05:28:15 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] IPP Agenda - Live Meeting Info
Thread-Index: Acv9xBTlKY/5JTTBSaqXPm0Q1ESrbQ==
From: "Zehler, Peter" 
To: "Ira McDonald" , , "Michael R Sweet" , "Paul Tykodi" 
X-OriginalArrivalTime: 18 Apr 2011 12:28:17.0629 (UTC) FILETIME=[187A80D0:01CBFDC4]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1541150619=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: B732879543.A9420
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1541150619==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CBFDC4.177D59B3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CBFDC4.177D59B3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20


LiveMeeting URL:

=20

https://www.livemeeting.com/cc/xerox/join?id=3DPWG-MFD&role=3Dattend&pw=3DL=
etM
eIn

=20

=20

=20

=20

LiveMeeting First Time Users:=20
To save time before the meeting, check your system
 to make sure it is ready
to use Microsoft Office Live Meeting.=20



=20

LiveMeeting Troubleshooting
Unable to join the meeting? Follow these steps:=20

=20

1.    Copy this address and paste it into your web browser:=20
https://www.livemeeting.com/cc/xerox/join=20

2.    Copy and paste the required information:=20
Meeting ID: PWG-MFD=20
Entry Code: LetMeIn=20
Location: https://www.livemeeting.com/cc/xerox=20

=20

=20

=20

=20

=20

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Ira
McDonald
Sent: Sunday, April 17, 2011 11:39 PM
To: ipp@pwg.org; Michael R Sweet; Paul Tykodi; Ira McDonald
Subject: [IPP] IPP Agenda - 1pm EDT Monday 18 April 2011

=20

Hi,

Our next IPP WG call will be on Monday.

 Monday 18 April 10-11am US PST / 1-2pm US EST

 Call-in toll-free number (US/Canada): 1-866-469-3239
 Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
 Call-in toll number (US/Canada): 1-408-856-9570 (Backup)

 Attendee Access Code: *******#
 Attendee ID Code: # (empty)

If you need the Attendee Access code, please email me a request.


*** Main Objective - Review IPP JPS3 and PWG Raster specs ***

Agenda:

(1) PWG IP Policy and Minute Taker
     - Mike?

(2) Approve IPP minutes from previous meeting
     -
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.pdf
=20

(3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (Mike)
     -
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pd
f
=20

(4) Review PWG Raster (Mike)
     - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
=20

(5) Discussion of IPP Everywhere (Mike/Ira)
     - http://pwg-wiki.wikispaces.com/IPP+Everywhere=20=20=20=20=20
     - Review use cases from IPP/Cloud Imaging mailing lists

(6) Next Steps
     - IPP WG teleconference on Monday 2 May
     - Review IPP Scan and IPP over USB drafts
     - All - post more use cases to IPP/Cloud Imaging mailing lists

Cheers,
- Ira (IPP WG Co-Chair)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
=20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CBFDC4.177D59B3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 <=
/o:p>

LiveMeeting URL:
 
https://www.livemeeting.com=
/cc/xerox/join?id=3DPWG-MFD&role=3Dattend&pw=3DLetMeIn
 
 
 <=
o:p>
 
<=
p class=3DMsoNormal style=3D'margin-bottom:12.0pt;text-autospace:none'><=
span style=3D'font-family:"Arial","sans-serif"'>LiveMeeting First Time User=
s: 
To save =
time before the meeting, check your system to make sure it is ready to use Microsoft O=
ffice Live Meeting. 

=
 
LiveMeeting Trouble=
shooting
Una=
ble to join the meeting? Follow these steps: 
 
1.    Copy this address and paste it into your web =
browser: 
https://=
www.livemeeting.com/cc/xerox/join 
2.    Copy and paste the required in=
formation: 
Meeting ID: PWG-MFD 
Entry Code: LetMeIn 
Location: https://www.livemeeting.com/=
cc/xerox 
 <=
/o:p>
 
 
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'> 
 
 
Peter Zehler

Xerox Resea=
rch Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-=
8755
FAX: (585) 265-7441
=
US Mail: Peter Zehler
Xerox Corp.=

800 Phillips Rd.
M/S 128-25E<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'>
Webster NY, 14580-9701 
 
From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf Of Ira McDonald
Sent: Sun=
day, April 17, 2011 11:39 PM
To: ipp@pwg.org; Michael R Sweet; Pa=
ul Tykodi; Ira McDonald
Subject: [IPP] IPP Agenda - 1pm EDT Monda=
y 18 April 2011
 =

Hi,

Our next IPP WG call will be on Monday.=


 Monday 18 April 10-11am US PST / 1-2pm US EST

 Ca=
ll-in toll-free number (US/Canada): 1-866-469-3239
 Call-in toll number (US/Canada): 1-650-429-3300 (Primary)=

 Call-in toll number (US/Canada): 1-408-856-9570 (Backup)

 Attendee Access C=
ode: *******#
 Attendee ID Code: # (empty)

If you need the A=
ttendee Access code, please email me a request.


*** Main Objecti=
ve - Review IPP JPS3 and PWG Raster specs ***

Agenda:

(1) PWG=
 IP Policy and Minute Taker
     - Mike?

(2) Appro=
ve IPP minutes from previous meeting
     - ftp://ftp.pwg.org/pub/pwg/ipp/min=
utes/ippv2-f2f-minutes-20110405.pdf

(3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (M=
ike)
     - ftp:=
//ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pdf

(4) Review PWG Raster (Mike)
     - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20=
110327-rev.pdf

(5) Discussion of IPP Everywhere (Mike/Ira=
)
     - http://pwg-wiki.wikispaces.com/IPP+Everywhere  =
;   
     - Review use cases from IPP/Clou=
d Imaging mailing lists

(6) Next Steps
     -=
 IPP WG teleconference on Monday 2 May
     - Review=
 IPP Scan and IPP over USB drafts
     - All - post =
more use cases to IPP/Cloud Imaging mailing lists

Cheers,
- Ira (=
IPP WG Co-Chair)

Ira McDonald (Musician / Software Archi=
tect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO =
PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP &a=
mp; Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/=
site/blueroofmusic
http://sites.google.co=
m/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through=
 April:
  579 Park Place  Saline, MI  48176
  734=
-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI =
49839
  906-494-2434
 =


-- 
This message has been scanned for=
 viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


------_=_NextPart_001_01CBFDC4.177D59B3--

--===============1541150619==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1541150619==--

From 3dkoike@mail.fukaya-showa.co.jp  Mon Apr 18 07:16:36 2011
Return-Path: <3dkoike@mail.fukaya-showa.co.jp>
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F93EE0700; Mon, 18 Apr 2011 07:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -83.257
X-Spam-Level: 
X-Spam-Status: No, score=-83.257 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgrCONspNXNN; Mon, 18 Apr 2011 07:16:35 -0700 (PDT)
Received: from telesp.net.br (201-42-2-119.dsl.telesp.net.br [201.42.2.119]) by ietfc.amsl.com (Postfix) with ESMTP id 78352E070E; Mon, 18 Apr 2011 07:16:32 -0700 (PDT)
Received: from  201.42.2.119 (account , ,  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 397548205 for ; Mon, 18 Apr 2011 11:16:32 -0300
From: , , 
To: , , 
Subject: Newsletter Mon, 18 Apr 2011 11:16:32 -0300
Date: Mon, 18 Apr 2011 11:16:32 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: ktmedreqzp-91
Message-ID: <5720507846.4PMHL406154025@zozzlqnilejn.gvitoscw.va>

Hey!!

Do you want a pleasant future, go up in earning power, and brownie points?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will help EVERYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- Follow YOUR Dreams!
- Live a wonderful life by earning or upgrading your degree.


This is a best chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


If you want to get better - you must Call 7 days a week! to start improving your life!


~CALL~


1-305-460-2287



Please leave us a voice message with your name and phone number with country code if outside USA and we will call you as soon as possible.


It's your move...
Make the right decision.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Mon Apr 18 08:55:37 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BEF9DE06DD for ; Mon, 18 Apr 2011 08:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIkwL9m1TVsg for ; Mon, 18 Apr 2011 08:55:36 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 1564CE06A2 for ; Mon, 18 Apr 2011 08:55:35 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 1371E79554; Mon, 18 Apr 2011 11:55:18 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 77EE079550 for ; Mon, 18 Apr 2011 11:55:03 -0400 (EDT)
MIME-version: 1.0
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJU00C56UV0HU80@mail-out.apple.com> for ipp@pwg.org; Mon, 18 Apr 2011 08:54:44 -0700 (PDT)
X-AuditID: 11807134-b7c8cae000005108-04-4dac5eac200f
Received: from [17.153.30.58] (Unknown_Domain [17.153.30.58]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id 1D.AE.20744.0CE5CAD4; Mon, 18 Apr 2011 08:54:43 -0700 (PDT)
From: Michael Sweet 
In-reply-to: 
Date: Mon, 18 Apr 2011 08:54:17 -0700
Message-id: 
References: 
To: Ira McDonald 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
Subject: [IPP] Re: IPP Agenda - 1pm EDT Monday 18 April 2011
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============2103672853=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 1371E79554.A915B
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============2103672853==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_9VBErQSTWXOyF2Peb0oEXQ)"


--Boundary_(ID_9VBErQSTWXOyF2Peb0oEXQ)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

Here is my expanded outline for JPS3 and PWG Raster (based on the F2F slide=
s):
IP Policy and Minute Taker
Policy accepted with Mike taking the minutes
Approve IPP minutes from last meeting
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.pdf
JPS3 Review
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pdf
Issue: How should we express an unknown printer-geo-location?
Issue: Need well-known URIs for standard colorspace profiles
Issue: How do we register media-col member attributes with IANA?
Issue: Need to flesh out the conformance requirements for the printer-suppl=
y attribute
PWG Raster Review
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
Issue: Would be nice to have total page count (if known)
Proposal: Add PageCount (integer, 0 to 2^31-1) to page header ("cupsInteger=
[0]" from CUPS Raster), which is already used by several CUPS Raster printe=
r drivers
0 means "I don't know how many pages"
> 0 means "this is how many pages are in the entire document"
Every page gets the same value
Issue: Need coordinate space of image (flip/rotate on back side)
Proposal: Add HorizontalTransform(integer, -1 or 1) and VerticalTransform(i=
nteger, -1 or 1) to the page header (=93cupsInteger[1]=94 and =93cupsIntege=
r[2]=94 from CUPS Raster)
=93Normal=94 pages have values of 1 and 1
=93Rotated=94 pages have values of -1 and -1 (180 degree rotation)
=93Flipped=94 pages have values of 1 and -1 (vertical flip) or -1 and 1 (ho=
rizontal flip)
Issue: Need bounding rectangle of any content to be imaged on the page (Ima=
geBox)
Proposal 1: =95 Use existing ImagingBBox (4 x integer) from page header - s=
imple bounding box in (integer) points
Proposal 2: Add ImageBottom (integer, 0-2^32-1), ImageLeft (integer, 0-2^32=
-1), ImageRight (integer, 0-2^32-1), and ImageTop (integer, 0-2^32-1) to th=
e page header (=93cupsInteger[3]=94 through =93cupsInteger[6]=94 from CUPS =
Raster) - simple bounding box in pixels/lines
Issue: Some confusion about why we need pwg-raster-resolutions-support
Will be adding explanatory text to the definition
Basically supported raster resolutions can be different than supported hard=
ware resolutions
Issue: Some confusion about the compression algorithm
Will be adding examples for 1-bit grayscale and 32-bit CMYK images to clari=
fy
Also have sample raster files available for download
Samples files:
Currently at http://ftp.easysw.com/pub/cups/examples/PWGRasterSamples.zip
40MB download, 80MB worth of data
150dpi files for black-1, cmyk-8, sgray-8, sgray-16, srgb-8, and srgb-16
Representative documents for email, line art, maps, photos, and web pages
Issue: Where to place sample raster files?
On Apr 17, 2011, at 8:39 PM, Ira McDonald wrote:

> Hi,
>=20
> Our next IPP WG call will be on Monday.
>=20
>  Monday 18 April 10-11am US PST / 1-2pm US EST
>=20
>  Call-in toll-free number (US/Canada): 1-866-469-3239
>  Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
>  Call-in toll number (US/Canada): 1-408-856-9570 (Backup)
>=20
>  Attendee Access Code: *******#
>  Attendee ID Code: # (empty)
>=20
> If you need the Attendee Access code, please email me a request.
>=20
>=20
> *** Main Objective - Review IPP JPS3 and PWG Raster specs ***
>=20
> Agenda:
>=20
> (1) PWG IP Policy and Minute Taker
>      - Mike?
>=20
> (2) Approve IPP minutes from previous meeting
>      - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.p=
df
>=20
> (3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (Mike)
>      - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-=
rev.pdf
>=20
> (4) Review PWG Raster (Mike)
>      - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
>=20
> (5) Discussion of IPP Everywhere (Mike/Ira)
>      - http://pwg-wiki.wikispaces.com/IPP+Everywhere=20=20=20=20=20
>      - Review use cases from IPP/Cloud Imaging mailing lists
>=20
> (6) Next Steps
>      - IPP WG teleconference on Monday 2 May
>      - Review IPP Scan and IPP over USB drafts
>      - All - post more use cases to IPP/Cloud Imaging mailing lists
>=20
> Cheers,
> - Ira (IPP WG Co-Chair)
>=20
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> May to Christmas:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_9VBErQSTWXOyF2Peb0oEXQ)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable

Here is my expanded outlin=
e for JPS3 and PWG Raster (based on the F2F slides):
    

  1. IP Po=
licy and Minute Taker
    2. 

      

    1. Polic=
y accepted with Mike taking the minutes
      2. 

    

  2. Appro=
ve IPP minutes from last meeting
    3. 

      

    1. ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.pdf

    

  3. JPS3 =
Review
    4. 

      

    1. ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev=
.pdf
      2. 

    2. Issue=
: How should we express an unknown printer-geo-location?
      3. 

    3. Issue=
: Need well-known URIs for standard colorspace profiles
      4. 

    4. Issue=
: How do we register media-col member attributes with IANA?
      5. 

    5. Issue=
: Need to flesh out the conformance requirements for the printer-supply att=
ribute
      6. 

    

  4. PWG R=
aster Review
    5. 

      

    1. ftp=
://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
      2. 

    2. Issue=
: Would be nice to have total page count (if known)
      3. 

        

      • Propo=
sal: Add PageCount (integer, 0 to 2^31-1) to page header ("cupsInteger[0]" =
from CUPS Raster), which is already used by several CUPS Raster printer dri=
vers
        • 

      • 0 mea=
ns "I don't know how many pages"
        • 

      • > =
0 means "this is how many pages are in the entire document"
        • 

      • Every=
 page gets the same value
        • 

      

    3. Issue=
: Need coordinate space of image (flip/rotate on back side)
      4. 

        

      • Propo=
sal: Add HorizontalTransform(integer, -1 or 1) and VerticalTransform(intege=
r, -1 or 1) to the page header (=93cupsInteger[1]=94 and =93cupsInteger[2]=
=94 from CUPS Raster)
        • 

      • =93No=
rmal=94 pages have values of 1 and 1
        • 

      • =93Ro=
tated=94 pages have values of -1 and -1 (180 degree rotation)
        • 

      • =93Fl=
ipped=94 pages have values of 1 and -1 (vertical flip) or -1 and 1 (horizon=
tal flip)
        • 

      

    4. Issue=
: Need bounding rectangle of any content to be imaged on the page (ImageBox=
)
      5. 

        

      • Propo=
sal 1: =95 Use existing ImagingBBox (4 x integer) from page header - simple=
 bounding box in (integer) points
        • 

      • Propo=
sal 2: Add ImageBottom (integer, 0-2^32-1), ImageLeft (integer, 0-2^32-1), =
ImageRight (integer, 0-2^32-1), and ImageTop (integer, 0-2^32-1) to the pag=
e header (=93cupsInteger[3]=94 through =93cupsInteger[6]=94 from CUPS Raste=
r) - simple bounding box in pixels/lines
        • 

      

    5. Issue=
: Some confusion about why we need pwg-raster-resolutions-support
      6. 

        

      • Will =
be adding explanatory text to the definition
        • 

      • Basic=
ally supported raster resolutions can be different than supported hardware =
resolutions
        • 

      

    6. Issue=
: Some confusion about the compression algorithm
      7. 

        

      • Will =
be adding examples for 1-bit grayscale and 32-bit CMYK images to clarify

      • Also =
have sample raster files available for download
        • 

      

    7. Sampl=
es files:
      8. 

        

      • Curre=
ntly at http://ftp.easysw.com/pub/cups/examples/PWGRasterSamples.zip
        • 

      • 40MB =
download, 80MB worth of data
        • 

      • 150dp=
i files for black-1, cmyk-8, sgray-8, sgray-16, srgb-8, and srgb-16
        • 

      • Repre=
sentative documents for email, line art, maps, photos, and web pages
        • 

      • Issue=
: Where to place sample raster files?
        • 

      

    

On Apr 17, 2011, at 8:39 PM, Ira McDonald wrote:

Hi,


Our next IPP WG call will be on Monday.



 Monday 18 April 10-11am US PST / 1-2pm US EST



 Call-in toll-free number (US/Canada): 1-866-469-3239

 Call-in toll number (US/Canada): 1-650-429-3300 (Primary)

 Call-in toll number (US/Canada): 1-408-856-9570 (Backup)



 Attendee Access Code: *******#

 Attendee ID Code: # (empty)



If you need the Attendee Access code, please email me a request.





*** Main Objective - Review IPP JPS3 and PWG Raster specs ***


Agenda:



(1) PWG IP Policy and Minute Taker

      - Mike?



(2) Approve IPP minutes from previous meeting
   =
  - ftp://ftp=
.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20110405.pdf
















(3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (Mike)














      - ftp://=
ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pdf
=

(4) Review PWG Raster (Mike)

     - ftp://ftp.pwg.or=
g/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf

(5) Discussion =
of IPP Everywhere (Mike/Ira)

     - http://pwg-wiki.wikispaces.com/IPP+Everywhere  &nbs=
p;  
     - Review use cases from IPP/Cloud Ima=
ging mailing lists


(6) Next Steps
     - IPP WG teleconfer=
ence on Monday 2 May
     - Review IPP Scan and IPP =
over USB drafts
     - All - post more use cases to =
IPP/Cloud Imaging mailing lists

Cheers,

- Ira (IPP WG Co-Chair)

Ira McDonald (Mus=
ician / Software Architect)
Chair - Linux Foundation Open Printing WGCo-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desi=
gnated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic<=
/a>
http://sites.google.com/site/highnorth=
inc

mailto:blueroo=
fmusic@gmail.com
Christmas through April:
  579 Park Place&n=
bsp; Saline, MI  48176
  734-944-0094
May to Christmas:
=
  PO Box 221  Grand Marais, MI 49839

  906-494-2434








______________________________________________________________________=
__
Michael Sweet, Senior Printing System Engineer, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_9VBErQSTWXOyF2Peb0oEXQ)--

--===============2103672853==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============2103672853==--

From aftab@youngone.co.kr  Mon Apr 18 09:59:36 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 04A6FE0801; Mon, 18 Apr 2011 09:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -87.795
X-Spam-Level: 
X-Spam-Status: No, score=-87.795 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmJyJCjsdvQy; Mon, 18 Apr 2011 09:59:35 -0700 (PDT)
Received: from brasiltelecom.net.br (unknown [189.73.187.133]) by ietfc.amsl.com (Postfix) with ESMTP id DE281E0694; Mon, 18 Apr 2011 09:59:34 -0700 (PDT)
Received: from  189.73.187.133 (account , ,  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 298757282 for ; Mon, 18 Apr 2011 13:59:31 -0300
From: , , 
To: , , 
Subject: Newsletter Mon, 18 Apr 2011 13:59:31 -0300
Date: Mon, 18 Apr 2011 13:59:31 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: ermxtht-61
Message-ID: <8155039800.AT8NSJKH951506@rnphaf.yqxxwav.va>

Halo!!

Do you want a more satisfactory future, soar in money earning, and the admiration of all?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will let ANYONE with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- Follow YOUR Dreams!
- Live a better life by earning or upgrading your degree.


This is a nice way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


Contact Us to start improving your life!


~CALL US~


1-305-460-2287



You must leave us a message with your name and phone number with country code if outside USA and we'll get back to you asap.


It's your move...
Make the right decision.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Mon Apr 18 11:09:22 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C163E0800 for ; Mon, 18 Apr 2011 11:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heOVYG+mKaSh for ; Mon, 18 Apr 2011 11:09:21 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id C1647E06A2 for ; Mon, 18 Apr 2011 11:09:21 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 35E6179567; Mon, 18 Apr 2011 14:09:05 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 895C079555 for ; Mon, 18 Apr 2011 14:08:52 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV006SR12GSY20@mail-out.apple.com> for ipp@pwg.org; Mon, 18 Apr 2011 11:08:51 -0700 (PDT)
X-AuditID: 11807134-b7c8cae000005108-c7-4dac7e333a0e
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id C5.8B.20744.33E7CAD4; Mon, 18 Apr 2011 11:08:51 -0700 (PDT)
From: Michael Sweet 
Date: Mon, 18 Apr 2011 11:08:51 -0700
To: ipp@pwg.org
Message-id: <139B30A2-E9A6-411D-8F98-F04F43EC8E14@apple.com>
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [IPP] Minutes from today's concall posted
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 35E6179567.A76F6
X-pwg-MailScanner-From: ipp-bounces@pwg.org

All,

I have posted the minutes from today's conference call at:

	ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20110418.pdf

Action items:

	- Justin and Pete to further investigate using WS-Discovery for IPP

Outstanding issues for discussion (beyond the specs themselves - see minutes for details):

JPS3:

	- How should we express an unknown printer-geo-location?
	- Need well-known URIs for standard colorspace profiles
	- How do we register media-col member attributes with IANA?
	- Need to flesh out the conformance requirements for the printer-supply attribute

PWG Raster:

	- Would be nice to have total page count (if known)
	- Need coordinate space of image (flip/rotate on back side)
	- Need bounding rectangle of any content to be imaged on the page (ImageBox)
	- Some confusion about why we need pwg-raster-resolutions-support
	- Some confusion about the compression algorithm
	- Where to place sample raster files?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Mon Apr 18 11:39:34 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54FC0E070A for ; Mon, 18 Apr 2011 11:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDbb6Hi431To for ; Mon, 18 Apr 2011 11:39:32 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id A25ADE0869 for ; Mon, 18 Apr 2011 11:39:32 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id C49B679575; Mon, 18 Apr 2011 14:39:08 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id E27F679571 for ; Mon, 18 Apr 2011 14:38:54 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Apr 2011 11:38:53 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 18 Apr 2011 11:38:52 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: More Discussion on bi-level, mono-chrome and color
Thread-Index: Acv995uy+vjg+qOfQ/2stMc9crkoVw==
From: "Petrie, Glen" 
To: 
X-OriginalArrivalTime: 18 Apr 2011 18:38:53.0957 (UTC) FILETIME=[DE5CE350:01CBFDF7]
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [IPP] More Discussion on bi-level, mono-chrome and color
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0176974375=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: C49B679575.A937C
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0176974375==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CBFDF7.DD43079F"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CBFDF7.DD43079F
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Can we change the required on mono to optional and bi-level be required.

=20

Bi-level           required for any printer

Color               required is color printer

Mono              1 toner - optional=20

Mono              >2 toners - optional

And the other is the table are optional

=20

Basically mono is a dithering of a single-color to produce an output
from saturation to white.  But dithering is a fancy thresholding
(bi-level); so there is no need to actually specify it as required or
optional since it will be encompassed by the printer type (b/w or
color).  For the case where a user wants single toner mono-chrome, it is
should be a capability of the printer that is support that function and
not be mandated that all printers must support it.   In other words it
may be a requirement of the user but not a support capability of a
printer.  That can be said about many printing functionalities.=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CBFDF7.DD43079F
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
















Can we change the required on mono to optional and
bi-level be required.



 



Bi-level        &nb=
sp;  required
for any printer



Color        &=
nbsp;      required
is color printer



Mono        &n=
bsp;     1
toner – optional 



Mono         &=
nbsp;    >2
toners – optional



And the other is the table are optional



 



Basically mono is a dithering of a single-color to pro=
duce
an output from saturation to white.  But dithering is a fancy threshol=
ding
(bi-level); so there is no need to actually specify it as required or optio=
nal since
it will be encompassed by the printer type (b/w or color).  For the ca=
se
where a user wants single toner mono-chrome, it is should be a capability of
the printer that is support that function and not be mandated that all prin=
ters
must support it.   In other words it may be a requirement of the =
user
but not a support capability of a printer.  That can be said about many
printing functionalities. 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CBFDF7.DD43079F--

--===============0176974375==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0176974375==--

From ipp-bounces@pwg.org  Mon Apr 18 13:38:29 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 58750E0896 for ; Mon, 18 Apr 2011 13:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4UGJ3LF15PN for ; Mon, 18 Apr 2011 13:38:28 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 4B84EE0892 for ; Mon, 18 Apr 2011 13:38:27 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 600AE794B0; Mon, 18 Apr 2011 16:38:07 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 4800279484 for ; Mon, 18 Apr 2011 16:37:55 -0400 (EDT)
MIME-version: 1.0
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJV00CZR7XFHUR0@mail-out.apple.com> for ipp@pwg.org; Mon, 18 Apr 2011 13:37:52 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-a0-4daca12000c8
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay16.apple.com (Apple SCV relay) with SMTP id 6A.CB.12552.021ACAD4; Mon, 18 Apr 2011 13:37:52 -0700 (PDT)
Subject: Re: [IPP] More Discussion on bi-level, mono-chrome and color
From: Michael Sweet 
In-reply-to: 
Date: Mon, 18 Apr 2011 13:37:52 -0700
Message-id: <29C6DE28-B8E7-4FBD-9B3D-A97C6C62B9C1@apple.com>
References: 
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1214898913=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 600AE794B0.AA24D
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1214898913==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_WLyjmq3vDPorPkOgsH0XrA)"


--Boundary_(ID_WLyjmq3vDPorPkOgsH0XrA)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

On Apr 18, 2011, at 11:38 AM, Petrie, Glen wrote:
> Can we change the required on mono to optional and bi-level be required.
>=20=20
> Bi-level           required for any printer
> Color               required is color printer
> Mono              1 toner =96 optional
> Mono              >2 toners =96 optional
> And the other is the table are optional
>=20=20
> Basically mono is a dithering of a single-color to produce an output from=
 saturation to white.  But dithering is a fancy thresholding (bi-level);

I don't agree with this. Thresholding is not dithering, which by definition=
 adds noise to the signal (in this case 2D color arrays) in order to more a=
ccurately portray the signal given limited output capabilities. The usage h=
ere is not to describe a particular algorithm but rather to specify intent:=
 high contrast black and white output. You'd use this mode when scanning an=
d printing forms, for example. (Oops - time for another thread...) It is pr=
etty clear I need to convert Table 2 to a list of paragraphs describing the=
 keywords and their meanings in detail.


The current requirements map to use cases - color and grayscale (monochrome=
) printing are required for our current use cases. "Bi-level" is not, altho=
ugh it is something we should consider for the scanned forms use case. We c=
an continue to debate the requirements, but every OS and just about every d=
river for a color printer includes UI to print color as grayscale... If the=
 intent is to allow a limited mobile client to do the same, we need to ask =
the printer to help out, and we can decide whether that means 1-color or pr=
ocess (N-color, N>1) black.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_WLyjmq3vDPorPkOgsH0XrA)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


Can we change the required on mono to=
 optional and bi-level be required.
=
 
Bi-level    &n=
bsp;      required for any printer
Color       &nbs=
p;       required is color printer=

Mono       =
       1 toner =96 optional=

Mono         =
     >2 toners =96 optional=

=
And the other is the table are optional
 
Basically =
mono is a dithering of a single-color to produce an output from saturation =
to white.  But dithering is a fancy thresholding (bi-level);

I don't agree=
 with this. Thresholding is not dithering, which by definition adds noise t=
o the signal (in this case 2D color arrays) in order to more accurately por=
tray the signal given limited output capabilities. The usage here is not to=
 describe a particular algorithm but rather to specify intent: high contras=
t black and white output. You'd use this mode when scanning and printing fo=
rms, for example. (Oops - time for another thread...) It is pretty cle=
ar I need to convert Table 2 to a list of paragraphs describing the keyword=
s and their meanings in detail.


The=
 current requirements map to use cases - color and grayscale (monochrome) p=
rinting are required for our current use cases. "Bi-level" is not, although=
 it is something we should consider for the scanned forms use case. We can =
continue to debate the requirements, but every OS and just about every driv=
er for a color printer includes UI to print color as grayscale... If the in=
tent is to allow a limited mobile client to do the same, we need to ask the=
 printer to help out, and we can decide whether that means 1-color or proce=
ss (N-color, N>1) black.



_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_WLyjmq3vDPorPkOgsH0XrA)--

--===============1214898913==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1214898913==--

From ipp-bounces@pwg.org  Mon Apr 18 13:52:58 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9437FE0701 for ; Mon, 18 Apr 2011 13:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEB+CXsxFE6q for ; Mon, 18 Apr 2011 13:52:57 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id E46C2E06F9 for ; Mon, 18 Apr 2011 13:52:57 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 0068A79561; Mon, 18 Apr 2011 16:52:43 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 15A0C79561 for ; Mon, 18 Apr 2011 16:52:30 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV004QA8LTRG60@mail-out.apple.com> for ipp@pwg.org; Mon, 18 Apr 2011 13:52:30 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-19-4daca48e5ead
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id E7.BD.23242.E84ACAD4; Mon, 18 Apr 2011 13:52:30 -0700 (PDT)
From: Michael Sweet 
Date: Mon, 18 Apr 2011 13:52:30 -0700
To: ipp@pwg.org
Message-id: 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [IPP] "print-color-mode" or "imaging-color-mode"?
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 0068A79561.A917F
X-pwg-MailScanner-From: ipp-bounces@pwg.org

All,

If we consider scanning and printing of forms, the "bi-level" (threshold) mode makes sense for both. Do we want to rename "print-color-mode" to "imaging-color-mode" in anticipation of using is for other MFD services in IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Mon Apr 18 13:57:45 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53E5BE0897 for ; Mon, 18 Apr 2011 13:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gUyz1878upZ for ; Mon, 18 Apr 2011 13:57:42 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 9C115E08A6 for ; Mon, 18 Apr 2011 13:57:42 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 9F8A47958D; Mon, 18 Apr 2011 16:57:21 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 4B0D07958D for ; Mon, 18 Apr 2011 16:57:07 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Apr 2011 13:57:06 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] More Discussion on bi-level, mono-chrome and color
Date: Mon, 18 Apr 2011 13:57:03 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] More Discussion on bi-level, mono-chrome and color
Thread-Index: Acv+CIEhIl5u+l1QRC+ryWvQPVfE5AAAVz8g
References:  <29C6DE28-B8E7-4FBD-9B3D-A97C6C62B9C1@apple.com>
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 18 Apr 2011 20:57:06.0742 (UTC) FILETIME=[2D3F7560:01CBFE0B]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0917007862=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 9F8A47958D.A8F31
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0917007862==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CBFE0B.2B881F2D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CBFE0B.2B881F2D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Ok, we have a differing understanding of some of the image processing
involved in printing.  While I still disagree, I agree to disagree and
will let the group decide the matter.=20

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Monday, April 18, 2011 1:38 PM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] More Discussion on bi-level, mono-chrome and color

=20

On Apr 18, 2011, at 11:38 AM, Petrie, Glen wrote:

=09

	Can we change the required on mono to optional and bi-level be
required.

=09=20

	Bi-level           required for any printer

	Color               required is color printer

	Mono              1 toner - optional

	Mono              >2 toners - optional

	And the other is the table are optional

=09=20

	Basically mono is a dithering of a single-color to produce an
output from saturation to white.  But dithering is a fancy thresholding
(bi-level);

=20

I don't agree with this. Thresholding is not dithering, which by
definition adds noise to the signal (in this case 2D color arrays) in
order to more accurately portray the signal given limited output
capabilities. The usage here is not to describe a particular algorithm
but rather to specify intent: high contrast black and white output.
You'd use this mode when scanning and printing forms, for example. (Oops
- time for another thread...) It is pretty clear I need to convert Table
2 to a list of paragraphs describing the keywords and their meanings in
detail.

=20

=20

The current requirements map to use cases - color and grayscale
(monochrome) printing are required for our current use cases. "Bi-level"
is not, although it is something we should consider for the scanned
forms use case. We can continue to debate the requirements, but every OS
and just about every driver for a color printer includes UI to print
color as grayscale... If the intent is to allow a limited mobile client
to do the same, we need to ask the printer to help out, and we can
decide whether that means 1-color or process (N-color, N>1) black.

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CBFE0B.2B881F2D
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


















Ok, we have a differing understandin=
g of
some of the image processing involved in printing.  While I still
disagree, I agree to disagree and will let the group decide the matter. 



 















From: Michael =
Sweet
[mailto:msweet@apple.com] 

Sent: Monday, April 18, 2011=
 1:38
PM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] More Disc=
ussion
on bi-level, mono-chrome and color






 









On Apr 18, 2011, at 11:38 AM, Petrie, Glen wrote:=
















Can we change the required on mono to optional and
bi-level be required.









 









Bi-level
          required for any pri=
nter









Color        &=
nbsp;     
required is color printer









Mono        &n=
bsp;    
1 toner – optional









Mono
             &g=
t;2
toners – optional









And the other is the table are optional









 









Basically mono is a dithering of a single-color to pro=
duce
an output from saturation to white.  But dithering is a fancy threshol=
ding
(bi-level);

















 









I don't agree with this. Thresholding is not dithering, which by
definition adds noise to the signal (in this case 2D color arrays) in order=
 to
more accurately portray the signal given limited output capabilities. The u=
sage
here is not to describe a particular algorithm but rather to specify intent:
high contrast black and white output. You'd use this mode when scanning and
printing forms, for example. (Oops - time for another thread...) It is
pretty clear I need to convert Table 2 to a list of paragraphs describing t=
he
keywords and their meanings in detail.









 









 









The current requirements map to use cases - color and grayscale
(monochrome) printing are required for our current use cases.
"Bi-level" is not, although it is something we should consider for
the scanned forms use case. We can continue to debate the requirements, but
every OS and just about every driver for a color printer includes UI to pri=
nt
color as grayscale... If the intent is to allow a limited mobile client to =
do
the same, we need to ask the printer to help out, and we can decide whether
that means 1-color or process (N-color, N>1) black.









 















______________=
__________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CBFE0B.2B881F2D--

--===============0917007862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0917007862==--

From ipp-bounces@pwg.org  Mon Apr 18 14:02:06 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 56D69E08AF for ; Mon, 18 Apr 2011 14:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnEuy9el8NBu for ; Mon, 18 Apr 2011 14:02:04 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id B53CEE08A9 for ; Mon, 18 Apr 2011 14:02:04 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 5F4B77959D; Mon, 18 Apr 2011 17:01:51 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 81DD67959E for ; Mon, 18 Apr 2011 17:01:37 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Apr 2011 14:01:37 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Mon, 18 Apr 2011 14:01:35 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Index: Acv+CqA273l00cxySOy+WshQgElHqgAAFEbw
References: 
From: "Petrie, Glen" 
To: "Michael Sweet" , 
X-OriginalArrivalTime: 18 Apr 2011 21:01:37.0051 (UTC) FILETIME=[CE5D56B0:01CBFE0B]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 5F4B77959D.A7C1E
X-pwg-MailScanner-From: ipp-bounces@pwg.org

I still disagree that we, the PWG, are doing "imaging"; that's what
cameras do.  We do print, scan, fax and copy.  In today's world of
computer programming is the amount of space to define
"print-color-color" and "scan-color-mode" that wasteful and having the
two provides more understanding to either a source device or a target
device.=20

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet
Sent: Monday, April 18, 2011 1:53 PM
To: ipp@pwg.org
Subject: [IPP] "print-color-mode" or "imaging-color-mode"?

All,

If we consider scanning and printing of forms, the "bi-level"
(threshold) mode makes sense for both. Do we want to rename
"print-color-mode" to "imaging-color-mode" in anticipation of using is
for other MFD services in IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Mon Apr 18 14:18:12 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F350E06B5 for ; Mon, 18 Apr 2011 14:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmdw1nQIDHn2 for ; Mon, 18 Apr 2011 14:18:10 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id C1BC1E077D for ; Mon, 18 Apr 2011 14:17:45 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A16E5795CA; Mon, 18 Apr 2011 17:17:20 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id B358A795D7 for ; Mon, 18 Apr 2011 17:16:50 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV00M3S9RI6WZ0@mail-out.apple.com> for ipp@pwg.org; Mon, 18 Apr 2011 14:16:46 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-c9-4dacaa3e9ced
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 48.07.23242.E3AACAD4; Mon, 18 Apr 2011 14:16:46 -0700 (PDT)
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
From: Michael Sweet 
In-reply-to: <3e0501cbfe0d$384bc1f0$a8e345d0$@hl.konicaminolta.us>
Date: Mon, 18 Apr 2011 14:16:46 -0700
Message-id: <1D2A6800-FC55-4A2B-A91A-CDF41BFDB669@apple.com>
References:   <3e0501cbfe0d$384bc1f0$a8e345d0$@hl.konicaminolta.us>
To: Tim McCann 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: A16E5795CA.A78EA
X-pwg-MailScanner-From: ipp-bounces@pwg.org

On Apr 18, 2011, at 2:11 PM, Tim McCann wrote:
> Granted, I am still getting up to speed on much of this (so please forgive
> me in advance if I'm stepping into something already covered), but didn't
> Lexmark recently really blur the difference of scan capture and camera
> capture when they put a camera in their Genesis print/mfp device in order to
> capture data as their scanning device?  
> 
> It seems to me that a name like "capture-color-mode" might eliminate the
> scan, scan, fax, and camera issue.

But you aren't "capturing" when you print - "capture" really only works as an adjective when taking something in (scan, fax-in, email-in) while "imaging" covers anything image-related.

I agree with Glen that "imaging" is an unfortunately broad term, however we haven't come up with a suitable replacement word that is limited to printing, facsimile, scanning, copying, transform, etc. in multifunction devices.

> 
> Tim
> 
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie,
> Glen
> Sent: Monday, April 18, 2011 3:02 PM
> To: Michael Sweet; ipp@pwg.org
> Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
> 
> I still disagree that we, the PWG, are doing "imaging"; that's what cameras
> do.  We do print, scan, fax and copy.  In today's world of computer
> programming is the amount of space to define "print-color-color" and
> "scan-color-mode" that wasteful and having the two provides more
> understanding to either a source device or a target device. 
> 
> Glen
> 
> 
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael
> Sweet
> Sent: Monday, April 18, 2011 1:53 PM
> To: ipp@pwg.org
> Subject: [IPP] "print-color-mode" or "imaging-color-mode"?
> 
> All,
> 
> If we consider scanning and printing of forms, the "bi-level"
> (threshold) mode makes sense for both. Do we want to rename
> "print-color-mode" to "imaging-color-mode" in anticipation of using is for
> other MFD services in IPP?
> 
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
> 
> 

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Mon Apr 18 14:19:18 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82B23E06B5 for ; Mon, 18 Apr 2011 14:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOrOgfA2iZTw for ; Mon, 18 Apr 2011 14:19:17 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 93CDFE069A for ; Mon, 18 Apr 2011 14:19:17 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 813F2795B9; Mon, 18 Apr 2011 17:19:02 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id BE031795C6 for ; Mon, 18 Apr 2011 17:18:33 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Apr 2011 14:18:33 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Mon, 18 Apr 2011 14:18:32 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Index: Acv+DXGgQG8V7lugTVivKFxrXgbm3gAADIjQ
References:   <02E8A567-B5B2-4FE3-9977-590409D95AFB@apple.com>
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 18 Apr 2011 21:18:33.0413 (UTC) FILETIME=[2C29DF50:01CBFE0E]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 813F2795B9.A8476
X-pwg-MailScanner-From: ipp-bounces@pwg.org

Thanks Mike.  I hope we can get ahead of the people prototyping so that
we can get more concise terms (and everyone will use them!).


-----Original Message-----
From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Monday, April 18, 2011 2:13 PM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

Glen,

There may in fact be reasons to keep the two attributes separate (e.g.
for copy), but I wanted to mention this now rather than in 6 months when
everyone has prototyped using "print-color-mode"...

On Apr 18, 2011, at 2:01 PM, Petrie, Glen wrote:

> I still disagree that we, the PWG, are doing "imaging"; that's what
> cameras do.  We do print, scan, fax and copy.  In today's world of
> computer programming is the amount of space to define
> "print-color-color" and "scan-color-mode" that wasteful and having the
> two provides more understanding to either a source device or a target
> device.=20
>=20
> Glen
>=20
>=20
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
> Michael Sweet
> Sent: Monday, April 18, 2011 1:53 PM
> To: ipp@pwg.org
> Subject: [IPP] "print-color-mode" or "imaging-color-mode"?
>=20
> All,
>=20
> If we consider scanning and printing of forms, the "bi-level"
> (threshold) mode makes sense for both. Do we want to rename
> "print-color-mode" to "imaging-color-mode" in anticipation of using is
> for other MFD services in IPP?
>=20
>
________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>=20
>=20
> --=20
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>=20
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Mon Apr 18 14:37:18 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E307EE082C for ; Mon, 18 Apr 2011 14:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+4lOonvIwX8 for ; Mon, 18 Apr 2011 14:37:18 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id D6265E07F0 for ; Mon, 18 Apr 2011 14:37:17 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D5E67795A6; Mon, 18 Apr 2011 17:16:20 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 8465E79593 for ; Mon, 18 Apr 2011 17:16:04 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 18 Apr 2011 14:16:03 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Mon, 18 Apr 2011 14:16:02 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Index: AQI/Lq2iLpJpGwdfqTIvGy+5+SE7rgMBdpLtk2WwMtCAAAFyoA==
References:   <3e0501cbfe0d$384bc1f0$a8e345d0$@hl.konicaminolta.us>
From: "Petrie, Glen" 
To: "Tim McCann" , "Michael Sweet" , 
X-OriginalArrivalTime: 18 Apr 2011 21:16:03.0977 (UTC) FILETIME=[D317BF90:01CBFE0D]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: D5E67795A6.A8565
X-pwg-MailScanner-From: ipp-bounces@pwg.org

I like "capture" versus "imaging".  But I believe the IPP team wants a
single work for Print, scan, fax, copy; and, "capture" does not work
well for print.  But if you have other ideas please suggest them.

-----Original Message-----
From: Tim McCann [mailto:tim.mccann@hl.konicaminolta.us]=20
Sent: Monday, April 18, 2011 2:12 PM
To: Petrie, Glen; 'Michael Sweet'; ipp@pwg.org
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

Granted, I am still getting up to speed on much of this (so please
forgive
me in advance if I'm stepping into something already covered), but
didn't
Lexmark recently really blur the difference of scan capture and camera
capture when they put a camera in their Genesis print/mfp device in
order to
capture data as their scanning device?=20=20

It seems to me that a name like "capture-color-mode" might eliminate the
scan, scan, fax, and camera issue.

Tim

-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Petrie,
Glen
Sent: Monday, April 18, 2011 3:02 PM
To: Michael Sweet; ipp@pwg.org
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

I still disagree that we, the PWG, are doing "imaging"; that's what
cameras
do.  We do print, scan, fax and copy.  In today's world of computer
programming is the amount of space to define "print-color-color" and
"scan-color-mode" that wasteful and having the two provides more
understanding to either a source device or a target device.=20

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Michael
Sweet
Sent: Monday, April 18, 2011 1:53 PM
To: ipp@pwg.org
Subject: [IPP] "print-color-mode" or "imaging-color-mode"?

All,

If we consider scanning and printing of forms, the "bi-level"
(threshold) mode makes sense for both. Do we want to rename
"print-color-mode" to "imaging-color-mode" in anticipation of using is
for
other MFD services in IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Mon Apr 18 14:37:19 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 09E85E07F0 for ; Mon, 18 Apr 2011 14:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCyXpy8LeVyf for ; Mon, 18 Apr 2011 14:37:18 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id F0233E0822 for ; Mon, 18 Apr 2011 14:37:17 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D45FD795A9; Mon, 18 Apr 2011 17:13:49 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id A852C795A9 for ; Mon, 18 Apr 2011 17:13:17 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJV00MXW9LK6WY0@mail-out.apple.com> for ipp@pwg.org; Mon, 18 Apr 2011 14:13:16 -0700 (PDT)
X-AuditID: 11807136-b7c6bae000004a34-dc-4daca96cfa2b
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay15.apple.com (Apple SCV relay) with SMTP id 07.9E.18996.C69ACAD4; Mon, 18 Apr 2011 14:13:16 -0700 (PDT)
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
From: Michael Sweet 
In-reply-to: 
Date: Mon, 18 Apr 2011 14:13:16 -0700
Message-id: <02E8A567-B5B2-4FE3-9977-590409D95AFB@apple.com>
References:  
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: D45FD795A9.A8212
X-pwg-MailScanner-From: ipp-bounces@pwg.org

Glen,

There may in fact be reasons to keep the two attributes separate (e.g. for copy), but I wanted to mention this now rather than in 6 months when everyone has prototyped using "print-color-mode"...

On Apr 18, 2011, at 2:01 PM, Petrie, Glen wrote:

> I still disagree that we, the PWG, are doing "imaging"; that's what
> cameras do.  We do print, scan, fax and copy.  In today's world of
> computer programming is the amount of space to define
> "print-color-color" and "scan-color-mode" that wasteful and having the
> two provides more understanding to either a source device or a target
> device. 
> 
> Glen
> 
> 
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
> Michael Sweet
> Sent: Monday, April 18, 2011 1:53 PM
> To: ipp@pwg.org
> Subject: [IPP] "print-color-mode" or "imaging-color-mode"?
> 
> All,
> 
> If we consider scanning and printing of forms, the "bi-level"
> (threshold) mode makes sense for both. Do we want to rename
> "print-color-mode" to "imaging-color-mode" in anticipation of using is
> for other MFD services in IPP?
> 
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Mon Apr 18 15:35:20 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 311A5E07BC for ; Mon, 18 Apr 2011 15:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.723
X-Spam-Level: 
X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH0BMAW2XExm for ; Mon, 18 Apr 2011 15:35:15 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id CC0F6E06E2 for ; Mon, 18 Apr 2011 15:35:15 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id CC87E795A8; Mon, 18 Apr 2011 18:35:00 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com [209.85.161.46]) by pwg.org (Postfix) with ESMTP id C466B7959E for ; Mon, 18 Apr 2011 18:34:46 -0400 (EDT)
Received: by fxm17 with SMTP id 17so4124748fxm.5 for ; Mon, 18 Apr 2011 15:34:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WbyJMqYsg/ac3KwmLB27Jkl1zd8XiYV2dmxRQWMt9GU=; b=rTRCREA+FTU98Lh6F6UGpQES/Rivrd50/pEmRN43cPvbsOjuuSYlNbu0f2BPdaPwq1 TQl2hhNxURiJCO1gklbIG+BSL1R9eKpxyRcMkuAPTEDTZL2S5DfC1L/2kqJZEm9P8fY7 04oWKUPV8tDk1A59BundnkvGKADLCagPZl3TY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DM3ndmuSHplUtxYlHmxnVlRHdRC5Sr5HYbtGuZaWfVEH2hOMu74DryOsw+dwyjOby2 ++7hXjxaf4jNfKiXmG1ZqD0Uy+eygH34QjPUZBClQARB3lXA1YGDQIwv6NWaTms/jHeV 329DASOR+rFilU0n8DRVaOxrt1g3XDG4fpeB4=
MIME-Version: 1.0
Received: by 10.223.76.147 with SMTP id c19mr39824fak.55.1303166085595; Mon, 18 Apr 2011 15:34:45 -0700 (PDT)
Received: by 10.223.120.135 with HTTP; Mon, 18 Apr 2011 15:34:45 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 18 Apr 2011 18:34:45 -0400
Message-ID: 
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
From: Ira McDonald 
To: Michael Sweet , Ira McDonald 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0800116613=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: CC87E795A8.A7F09
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0800116613==
Content-Type: multipart/alternative; boundary=0015174c3fb09d836804a138ff10


--0015174c3fb09d836804a138ff10
Content-Type: text/plain; charset=ISO-8859-1

Hi Mike,

My two cents.

No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.

In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.

Unless almost all Printer attributes *are* applicable, which I begin
to suspect is the case (and have a short table of the exceptions).

I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP
Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet  wrote:

> All,
>
> If we consider scanning and printing of forms, the "bi-level" (threshold)
> mode makes sense for both. Do we want to rename "print-color-mode" to
> "imaging-color-mode" in anticipation of using is for other MFD services in
> IPP?
>
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--0015174c3fb09d836804a138ff10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Mike,

My two cents.

No - let's keep the name "pri=
nt-color-mode" to cohere with the
zillion other print-xxx or printe=
r-xxx attributes.

In the new IPP Scanner and Fax objects lets just g=
lobally apply

most/many existing IPP Printer attributes in big table(s) with
a rationa=
le for why some attributes are not applicable to the
other multifunction=
 objects.

Unless almost all Printer attributes *are* applicable, whi=
ch I begin 

to suspect is the case (and have a short table of the exceptions).

I=
 think we should reserve use of he "imaging-" prefix for only new=

attributes defined first for Scanner, Fax, etc. objects for IPP 

Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation O=
pen Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardco=
py WG

IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High Nort=
h Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc

mailto:blueroo=
fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S=
aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2=
21=A0 Grand Marais, MI 49839

=A0 906-494-2434




On Mon, Apr 18, 2011 at 4:52 PM, Michael=
 Sweet <msweet@app=
le.com> wrote:

All,



If we consider scanning and printing of forms, the "bi-level" (th=
reshold) mode makes sense for both. Do we want to rename "print-color-=
mode" to "imaging-color-mode" in anticipation of using is fo=
r other MFD services in IPP?




________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--0015174c3fb09d836804a138ff10--

--===============0800116613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0800116613==--

From ipp-bounces@pwg.org  Mon Apr 18 16:04:53 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E160E0898 for ; Mon, 18 Apr 2011 16:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Acpdmlp6BDUl for ; Mon, 18 Apr 2011 16:04:52 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 06E30E069C for ; Mon, 18 Apr 2011 16:04:52 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id EC044795B9; Mon, 18 Apr 2011 19:04:33 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by pwg.org (Postfix) with ESMTP id BB650795A8 for ; Mon, 18 Apr 2011 19:04:17 -0400 (EDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Apr 2011 16:04:17 -0700
Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.86]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0289.008; Mon, 18 Apr 2011 16:04:17 -0700
From: Justin Hutchings 
To: "ipp@pwg.org" 
Thread-Topic: PWG Raster intent
Thread-Index: Acv+G4TGtSEynqzyQIinfM07dmCH2g==
Date: Mon, 18 Apr 2011 23:04:16 +0000
Message-ID: <15713B46EB868E4FB0CF6D8BFD33617E47E0ED5E@TK5EX14MBXC116.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
MIME-Version: 1.0
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [IPP] PWG Raster intent
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1730356544=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: EC044795B9.A9496
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1730356544==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_15713B46EB868E4FB0CF6D8BFD33617E47E0ED5ETK5EX14MBXC116r_"


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E0ED5ETK5EX14MBXC116r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,
I brought up in the last face to face that a standard mechanism to express =
intent in PWG Raster is important to ensure that vendor implementations don=
't fork across "dumb" buses like USB and Bluetooth (HCRP). I'd like to have=
 some more discussion of this topic. If we do not create a common definitio=
n, then each vendor will likely create different variants of PWG Raster tha=
t includes intent.

Do we have an existing format that would be easily incorporated into the PW=
G Raster spec? Would it make sense to have some kind of serialized IPP-inte=
nt stream?

Thanks!
Justin

Justin Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printi=
ng and Imaging


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E0ED5ETK5EX14MBXC116r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











All,


I brought up in the last face to face that a standar=
d mechanism to express intent in PWG Raster is important to ensure that ven=
dor implementations don’t fork across “dumb” buses like U=
SB and Bluetooth (HCRP). I’d like to have some more
 discussion of this topic. If we do not create a common definition, then ea=
ch vendor will likely create different variants of PWG Raster that includes=
 intent.



 


Do we have an existing format that would be easily i=
ncorporated into the PWG Raster spec? Would it make sense to have some kind=
 of serialized IPP-intent stream?



 


Thanks!


Justin


 


Justin
Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printi=
ng and Imaging


 




--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.



--_000_15713B46EB868E4FB0CF6D8BFD33617E47E0ED5ETK5EX14MBXC116r_--

--===============1730356544==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1730356544==--

From ipp-bounces@pwg.org  Mon Apr 18 17:03:03 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A293CE0692 for ; Mon, 18 Apr 2011 17:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lawRFAYM7do for ; Mon, 18 Apr 2011 17:03:02 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 9E873E070C for ; Mon, 18 Apr 2011 17:03:02 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 53344795BE; Mon, 18 Apr 2011 20:02:47 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 5E1DD79577 for ; Mon, 18 Apr 2011 20:02:32 -0400 (EDT)
MIME-version: 1.0
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJV00CQ0HDHHUX0@mail-out.apple.com> for ipp@pwg.org; Mon, 18 Apr 2011 17:02:31 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-66-4dacd115aa0f
Received: from [17.153.31.214] (Unknown_Domain [17.153.31.214]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id A9.7E.23242.611DCAD4; Mon, 18 Apr 2011 17:02:31 -0700 (PDT)
Subject: Re: [IPP] PWG Raster intent
From: Michael Sweet 
In-reply-to: <15713B46EB868E4FB0CF6D8BFD33617E47E0ED5E@TK5EX14MBXC116.redmond.corp.microsoft.com>
Date: Mon, 18 Apr 2011 17:02:28 -0700
Message-id: 
References: <15713B46EB868E4FB0CF6D8BFD33617E47E0ED5E@TK5EX14MBXC116.redmond.corp.microsoft.com>
To: Justin Hutchings 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1158795482=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 53344795BE.A9359
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1158795482==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_QsRbkx43/JOY4nF8LaE95Q)"


--Boundary_(ID_QsRbkx43/JOY4nF8LaE95Q)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

On Apr 18, 2011, at 4:04 PM, Justin Hutchings wrote:
> All,
> I brought up in the last face to face that a standard mechanism to expres=
s intent in PWG Raster is important to ensure that vendor implementations d=
on=92t fork across =93dumb=94 buses like USB and Bluetooth (HCRP). I=92d li=
ke to have some more discussion of this topic. If we do not create a common=
 definition, then each vendor will likely create different variants of PWG =
Raster that includes intent.

I'm not convinced that is the case. Every printer vendor already has their =
own PDL(s) to support legacy interfaces and protocols - given the developme=
nt costs associated with adopting a new PDL, why would any vendor choose to=
 do so without a compelling reason? The only useful advantage PWG Raster ha=
s over existing vendor PDLs is the use of client-friendly colorspaces, and =
many vendor PDLs have already made that transition.

The real advantages IPP (and alternate bindings like WS-Print), IPP-over-US=
B, and Bluetooth BPP have over legacy protocols are:

1. Well-defined model, operations, and attributes for printing, status moni=
toring, and control
2. Standard job tickets external to the document format
3. Support for identification and submission of multiple document formats
4. Standard extension mechanisms

The goal of IPP Everywhere is to replace those legacy interfaces with IPP a=
nd adopt one or more standard document formats and discovery mechanisms (in=
 the case of network printers) so that a single "generic" driver can suppor=
t all of the common use cases for printing and multifunction with any print=
er that conforms to the standard. Similarly, vendor-specific drivers can be=
 written and used to support use cases outside of IPP Everywhere while stil=
l using the same core protocols.

I see little point in trying to retrofit support for existing printers when=
 they generally cannot be upgraded in the first place. Moreover, printers t=
hat *can* be upgraded will likely have the resources to support IPP Everywh=
ere since the vendor already invested in flash storage and the other relate=
d hardware necessary to support upgrades. Remember, consumer inkjet printer=
s only recently (2008-2009) started shipping with flashable firmware, and t=
hat practice is still far from common - most still ship with everything har=
dcoded in ASICs and ROMs...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_QsRbkx43/JOY4nF8LaE95Q)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


All,
I brought up in the la=
st face to face that a standard mechanism to express intent in PWG Raster i=
s important to ensure that vendor implementations don=92t fork across =93du=
mb=94 buses like USB and Bluetooth (HCRP). I=92d like to have some more dis=
cussion of this topic. If we do not create a common definition, then each v=
endor will likely create different variants of PWG Raster that includes int=
ent.

I'm not convinced =
that is the case. Every printer vendor already has their own PDL(s) to supp=
ort legacy interfaces and protocols - given the development costs associate=
d with adopting a new PDL, why would any vendor choose to do so without a c=
ompelling reason? The only useful advantage PWG Raster has over existing ve=
ndor PDLs is the use of client-friendly colorspaces, and many vendor PDLs h=
ave already made that transition.

The real advanta=
ges IPP (and alternate bindings like WS-Print), IPP-over-USB, and Bluetooth=
 BPP have over legacy protocols are:

1. Well-defin=
ed model, operations, and attributes for printing, status monitoring, and c=
ontrol
2. Standard job tickets external to the document format
3. Support for identification and submission of multiple document f=
ormats
4. Standard extension mechanisms

=

The goal of IPP Everywhere is to replace those legacy interfaces with =
IPP and adopt one or more standard document formats and discovery mechanism=
s (in the case of network printers) so that a single "generic" driver can s=
upport all of the common use cases for printing and multifunction with any =
printer that conforms to the standard. Similarly, vendor-specific drivers c=
an be written and used to support use cases outside of IPP Everywhere while=
 still using the same core protocols.

I see little=
 point in trying to retrofit support for existing printers when they genera=
lly cannot be upgraded in the first place. Moreover, printers that *can* be=
 upgraded will likely have the resources to support IPP Everywhere since th=
e vendor already invested in flash storage and the other related hardware n=
ecessary to support upgrades. Remember, consumer inkjet printers only recen=
tly (2008-2009) started shipping with flashable firmware, and that practice=
 is still far from common - most still ship with everything hardcoded in AS=
ICs and ROMs...



_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_QsRbkx43/JOY4nF8LaE95Q)--

--===============1158795482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1158795482==--

From andylidd@public.qd.sd.cn  Mon Apr 18 18:07:30 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1FF81E074C; Mon, 18 Apr 2011 18:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -89.775
X-Spam-Level: 
X-Spam-Status: No, score=-89.775 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaVsSPpes7sb; Mon, 18 Apr 2011 18:07:29 -0700 (PDT)
Received: from Broadband-Dynamic-119-235-73-33.connect.com.fj (Broadband-Dynamic-119-235-73-33.connect.com.fj [119.235.73.33]) by ietfc.amsl.com (Postfix) with ESMTP id 57FB7E06ED; Mon, 18 Apr 2011 18:07:26 -0700 (PDT)
Received: from  119.235.73.33 (account ,  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 832697739 for ; Tue, 19 Apr 2011 13:08:35 +1200
From: , 
To: , 
Subject: Newsletter Tue, 19 Apr 2011 13:08:35 +1200
Date: Tue, 19 Apr 2011 13:08:35 +1200
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: 7bit
X-Mailer: ahwtthdyk-06
Message-ID: <6769806996.OYF4I3Z6127000@uoqpxcpsd.dchhabpbbsepfko.su>

Hi!!

Do you want an effective future, soar in money earning power, and the praise of all?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will help ALL with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- Realize YOUR Dreams!
- Live a much better life by earning or upgrading your degree.


This is a best chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


Contact Us to start improving your life!


~CONTACT US~


1-916-484-3795



Please leave us a voice message with your name and phone number with country code if outside USA and we will contact you asap.


It's your decision...
Make the right move.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Tue Apr 19 10:40:55 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ADF34E069C for ; Tue, 19 Apr 2011 10:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j93YY-X+UqgR for ; Tue, 19 Apr 2011 10:40:51 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 70767E0675 for ; Tue, 19 Apr 2011 10:40:48 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 30959795AA; Tue, 19 Apr 2011 13:40:23 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by pwg.org (Postfix) with ESMTP id E13EC795A7 for ; Tue, 19 Apr 2011 13:40:06 -0400 (EDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Apr 2011 10:40:06 -0700
Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.86]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0289.008; Tue, 19 Apr 2011 10:40:06 -0700
From: Justin Hutchings 
To: Michael Sweet 
Subject: RE: [IPP] PWG Raster intent
Thread-Topic: [IPP] PWG Raster intent
Thread-Index: Acv+G4TGtSEynqzyQIinfM07dmCH2gARDmgAABVy1dA=
Date: Tue, 19 Apr 2011 17:40:06 +0000
Message-ID: <15713B46EB868E4FB0CF6D8BFD33617E47E105FF@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <15713B46EB868E4FB0CF6D8BFD33617E47E0ED5E@TK5EX14MBXC116.redmond.corp.microsoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
MIME-Version: 1.0
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0449465527=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 30959795AA.A8C7C
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0449465527==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_15713B46EB868E4FB0CF6D8BFD33617E47E105FFTK5EX14MBXC116r_"


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E105FFTK5EX14MBXC116r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Michael,
I absolutely agree with your point that vendors have their own PDLs today f=
or legacy devices and that it's unlikely that existing devices will be retr=
ofit. But if vendors begin to transition into IPP and PWG raster, they may =
choose to reduce their investments in legacy PDLs in order to focus on new =
technologies. I believe there are some logical conclusions you can draw fro=
m this:


1.       If a vendor adopts IPP Everywhere and PWG raster with it, then wha=
t are the odds they will continue to consume legacy PDLs? The odds of this =
are low for cost constrained devices such as inkjets. Consuming multiple PD=
Ls requires maintaining separate driver and firmware code bases and becomes=
 prohibitively expensive quickly.

2.       If a vendor chooses to only adopt PWG raster as a PDL, but still w=
ishes to target buses that lack an intent protocol, then they will have to =
create a proprietary intent language.

a.       Though smart buses certainly have advantages, not all clients will=
 implement these buses at the same time and some legacy clients may never b=
e updated. There could be many years where vendors are forced to maintain p=
arallel paths in order to reach all clients they wish to target.

3.       Therefore, we can expect that during this transitional period, the=
re could be additional cost/pain for vendors that wish to participate in th=
is space. We can mitigate this by being prescriptive about how to represent=
 intent in a PDL stream.

Do you agree?

Thanks
Justin

From: Michael Sweet [mailto:msweet@apple.com]
Sent: Monday, April 18, 2011 5:02 PM
To: Justin Hutchings
Cc: ipp@pwg.org
Subject: Re: [IPP] PWG Raster intent

On Apr 18, 2011, at 4:04 PM, Justin Hutchings wrote:
All,
I brought up in the last face to face that a standard mechanism to express =
intent in PWG Raster is important to ensure that vendor implementations don=
't fork across "dumb" buses like USB and Bluetooth (HCRP). I'd like to have=
 some more discussion of this topic. If we do not create a common definitio=
n, then each vendor will likely create different variants of PWG Raster tha=
t includes intent.

I'm not convinced that is the case. Every printer vendor already has their =
own PDL(s) to support legacy interfaces and protocols - given the developme=
nt costs associated with adopting a new PDL, why would any vendor choose to=
 do so without a compelling reason? The only useful advantage PWG Raster ha=
s over existing vendor PDLs is the use of client-friendly colorspaces, and =
many vendor PDLs have already made that transition.

The real advantages IPP (and alternate bindings like WS-Print), IPP-over-US=
B, and Bluetooth BPP have over legacy protocols are:

1. Well-defined model, operations, and attributes for printing, status moni=
toring, and control
2. Standard job tickets external to the document format
3. Support for identification and submission of multiple document formats
4. Standard extension mechanisms

The goal of IPP Everywhere is to replace those legacy interfaces with IPP a=
nd adopt one or more standard document formats and discovery mechanisms (in=
 the case of network printers) so that a single "generic" driver can suppor=
t all of the common use cases for printing and multifunction with any print=
er that conforms to the standard. Similarly, vendor-specific drivers can be=
 written and used to support use cases outside of IPP Everywhere while stil=
l using the same core protocols.

I see little point in trying to retrofit support for existing printers when=
 they generally cannot be upgraded in the first place. Moreover, printers t=
hat *can* be upgraded will likely have the resources to support IPP Everywh=
ere since the vendor already invested in flash storage and the other relate=
d hardware necessary to support upgrades. Remember, consumer inkjet printer=
s only recently (2008-2009) started shipping with flashable firmware, and t=
hat practice is still far from common - most still ship with everything har=
dcoded in ASICs and ROMs...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E105FFTK5EX14MBXC116r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Michael,


I absolutely agree with y=
our point that vendors have their own PDLs today for legacy devices and tha=
t it’s unlikely that existing devices will be retrofit.
 But if vendors begin to transition into IPP and PWG raster, they may choos=
e to reduce their investments in legacy PDLs in order to focus on new techn=
ologies. I believe there are some logical conclusions you can draw from thi=
s:


 <=
/p>

1. =
;     
If a vendor adopt=
s IPP Everywhere and PWG raster with it, then what are the odds they will c=
ontinue to consume legacy PDLs? The odds of this are low
 for cost constrained devices such as inkjets. Consuming multiple PDLs requ=
ires maintaining separate driver and firmware code bases and becomes prohib=
itively expensive quickly.



2. =
;     
If a vendor choos=
es to only adopt PWG raster as a PDL, but still wishes to target buses that=
 lack an intent protocol, then they will have to create
 a proprietary intent language. 



a.  &=
nbsp;   
Though smart buse=
s certainly have advantages, not all clients will implement these buses at =
the same time and some legacy clients may never be updated.
 There could be many years where vendors are forced to maintain parallel pa=
ths in order to reach all clients they wish to target.



3. =
;     
Therefore, we can=
 expect that during this transitional period, there could be additional cos=
t/pain for vendors that wish to participate in this space.
 We can mitigate this by being prescriptive about how to represent intent i=
n a PDL stream.



 <=
/p>

Do you agree?<=
/span>


 <=
/p>

Thanks<=
/p>

Justin<=
/p>

 <=
/p>





From: Michael =
Sweet [mailto:msweet@apple.com]


Sent: Monday, April 18, 2011 5:02 PM

To: Justin Hutchings

Cc: ipp@pwg.org

Subject: Re: [IPP] PWG Raster intent






 






On Apr 18, 2011, at 4:04 PM, Justin Hutchings wrote:=











All,






I brought up in the last face to face t=
hat a standard mechanism to express intent in PWG Raster is important to en=
sure that vendor implementations don’t fork across “dumb”
 buses like USB and Bluetooth (HCRP). I’d like to have some more disc=
ussion of this topic. If we do not create a common definition, then each ve=
ndor will likely create different variants of PWG Raster that includes inte=
nt.










 




I'm not convinced that is the case. Every printer ve=
ndor already has their own PDL(s) to support legacy interfaces and protocol=
s - given the development costs associated with adopting a new PDL, why wou=
ld any vendor choose to do so without
 a compelling reason? The only useful advantage PWG Raster has over existin=
g vendor PDLs is the use of client-friendly colorspaces, and many vendor PD=
Ls have already made that transition.






 






The real advantages IPP (and alternate bindings like=
 WS-Print), IPP-over-USB, and Bluetooth BPP have over legacy protocols are:=







 






1. Well-defined model, operations, and attributes fo=
r printing, status monitoring, and control






2. Standard job tickets external to the document for=
mat






3. Support for identification and submission of mult=
iple document formats






4. Standard extension mechanisms






 






The goal of IPP Everywhere is to replace those legac=
y interfaces with IPP and adopt one or more standard document formats and d=
iscovery mechanisms (in the case of network printers) so that a single &quo=
t;generic" driver can support all of the
 common use cases for printing and multifunction with any printer that conf=
orms to the standard. Similarly, vendor-specific drivers can be written and=
 used to support use cases outside of IPP Everywhere while still using the =
same core protocols.






 






I see little point in trying to retrofit support for=
 existing printers when they generally cannot be upgraded in the first plac=
e. Moreover, printers that *can* be upgraded will likely have the resources=
 to support IPP Everywhere since the
 vendor already invested in flash storage and the other related hardware ne=
cessary to support upgrades. Remember, consumer inkjet printers only recent=
ly (2008-2009) started shipping with flashable firmware, and that practice =
is still far from common - most
 still ship with everything hardcoded in ASICs and ROMs...






 








_________________________=
_______________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=







 




--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.



--_000_15713B46EB868E4FB0CF6D8BFD33617E47E105FFTK5EX14MBXC116r_--

--===============0449465527==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0449465527==--

From ipp-bounces@pwg.org  Tue Apr 19 11:46:50 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DEF37E071E for ; Tue, 19 Apr 2011 11:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYoF0wF9Stm5 for ; Tue, 19 Apr 2011 11:46:49 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id A0057E06F2 for ; Tue, 19 Apr 2011 11:46:49 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id C5B7A795C3; Tue, 19 Apr 2011 14:46:34 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by pwg.org (Postfix) with ESMTP id 6E655795BE for ; Tue, 19 Apr 2011 14:46:22 -0400 (EDT)
Received: from FamilyRoom ([unknown] [173.60.197.153]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LJW00CZAXGSAIXL@vms173005.mailsrvcs.net> for ipp@pwg.org; Tue, 19 Apr 2011 13:46:11 -0500 (CDT)
From: "Tom Hastings" 
To: "'Ira McDonald'" , "'Michael Sweet'" 
References:  
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Tue, 19 Apr 2011 11:45:45 -0700
Message-id: <7A180A09B8F54B1FA932DE27E255EB3C@FamilyRoom>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090
Thread-index: Acv+GOOEKPQAqaGTQYCr82G4xU3AUQAI2f2g
In-reply-to: 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: tom.hastings@alum.mit.edu
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0566084463=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: C5B7A795C3.AA39C
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0566084463==
Content-type: multipart/alternative;
	boundary="----=_NextPart_000_017D_01CBFE87.528F6380"

This is a multi-part message in MIME format.

------=_NextPart_000_017D_01CBFE87.528F6380
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I agree with Ira.  On the other hand, one other alternative for the name
would just to drop the "print-" prefix and call it "color-mode".

 

Tom

 

  _____  

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Ira
McDonald
Sent: Monday, April 18, 2011 15:35
To: Michael Sweet; Ira McDonald
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

 

Hi Mike,

My two cents.

No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.

In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.

Unless almost all Printer attributes *are* applicable, which I begin 
to suspect is the case (and have a short table of the exceptions).

I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP 
Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
 
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434





On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet  wrote:

All,

If we consider scanning and printing of forms, the "bi-level" (threshold)
mode makes sense for both. Do we want to rename "print-color-mode" to
"imaging-color-mode" in anticipation of using is for other MFD services in
IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

 


-- 
This message has been scanned for viruses and 
dangerous content by   MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------=_NextPart_000_017D_01CBFE87.528F6380
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
























I agree with Ira.  On the other h=
and,
one other alternative for the name would just to drop the "print-"
prefix and call it "color-mode".



 



Tom



 















From:
ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Ira McDonald

Sent: Monday, April 18, 2011=
 15:35

To: Michael
 Sweet; Ira McDonald

Cc: ipp@pwg.org

Subject: Re: [IPP]
"print-color-mode" or "imaging-color-mode"?






 



Hi Mike,



My two cents.



No - let's keep the name "print-color-mode" to cohere with the

zillion other print-xxx or printer-xxx attributes.



In the new IPP Scanner and Fax objects lets just globally apply

most/many existing IPP Printer attributes in big table(s) with

a rationale for why some attributes are not applicable to the

other multifunction objects.



Unless almost all Printer attributes *are* applicable, which I begin 

to suspect is the case (and have a short table of the exceptions).



I think we should reserve use of he "imaging-" prefix for only ne=
w

attributes defined first for Scanner, Fax, etc. objects for IPP 

Everywhere Second Edition.



Cheers,

- Ira





Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

579 Park Place Saline, MI 48176

734-944-0094

May to Christmas:

PO Box 221
Grand Marais, MI 49839

906-494-2434














On Mon, Apr 18, 2011 at 4:52 PM, Michael
 Sweet <msweet@appl=
e.com>
wrote:



All,



If we consider scanning and printing of forms, the "bi-level"
(threshold) mode makes sense for both. Do we want to rename
"print-color-mode" to "imaging-color-mode" in anticipat=
ion
of using is for other MFD services in IPP?



________________________________________________________________________

Michael Sweet, Senior Printing
System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp






 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------=_NextPart_000_017D_01CBFE87.528F6380--


--===============0566084463==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0566084463==--


From ipp-bounces@pwg.org  Tue Apr 19 12:01:45 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57E51E0869 for ; Tue, 19 Apr 2011 12:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOc2agM02RhF for ; Tue, 19 Apr 2011 12:01:44 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 1EF05E0855 for ; Tue, 19 Apr 2011 12:00:59 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 21264795C9; Tue, 19 Apr 2011 15:00:46 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by pwg.org (Postfix) with ESMTP id 31A8C795BE for ; Tue, 19 Apr 2011 15:00:31 -0400 (EDT)
Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 575A78347; Tue, 19 Apr 2011 19:00:31 +0000 (UTC)
Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 19 Apr 2011 18:59:45 +0000
Received: from GVW1155EXB.americas.hpqcorp.net ([16.232.35.138]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Tue, 19 Apr 2011 18:59:45 +0000
From: "Mitchell, Andrew (Solutions Architect)" 
To: "tom.hastings@alum.mit.edu" , 'Ira McDonald' , 'Michael Sweet' 
Date: Tue, 19 Apr 2011 18:59:41 +0000
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Topic: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Index: Acv+w/KhJsck0jnFSKCjc/QHIUEsSQ==
Message-ID: 
In-Reply-To: <7A180A09B8F54B1FA932DE27E255EB3C@FamilyRoom>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 21264795C9.A9225
X-pwg-MailScanner-From: ipp-bounces@pwg.org

OK, my 2=A2.

We need to decide if naming a NEW attribute that applies to more then just =
print with the print- prefix makes sense. A agree that renaming existing at=
tributes does not make sense, and using the print- attributes in scan (and =
fax) rather then renaming them is logical. But if we are going to say attri=
butes that are originally defined in Scan (or Fax) start with imaging- whil=
e if they first show up in IPP Everywhere (or some other doc like JPS3) we =
name them print- that doesn't seam quite right. My preference would be eith=
er:


 1.  Call everything that is not scan (or fax) specific print-, no matter w=
here it is first defined. For scan or fax specific, call them scan- and fax=
-.
 2.  Start using the imaging- prefix everywhere that the term is NOT print =
specific.

We are going to expand the model which is heavily rooted in print to other =
services, I'd just like to have a consistent naming convention for how we m=
ove forward. 1 seems more confusing to me since it means keeping the print-=
 name moving forward, and we'll have to maintain the table as to what is pr=
int specific and what isn't, but 1 also seems more true to the roots of IPP=
. I however personally vote for 2 since it clearly implies our broader scop=
e of the protocol moving forward.

As for just dropping the print- prefix, while it works for color-mode, I th=
ink we need to take a harder look to make sure it makes sense everywhere. N=
ote that I view this as simply a different way of naming option 2. If we pi=
ck option 2 we need to then pick the naming convention.

OK, so that was a bit more the 2=A2 worth.

Andrew

From: Tom Hastings >
Reply-To: "tom.hastings@alum.mit.edu" >
Date: Tue, 19 Apr 2011 18:45:45 +0000
To: 'Ira McDonald' =
>, 'Michael Sweet' >
Cc: "ipp@pwg.org" >
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

I agree with Ira.  On the other hand, one other alternative for the name wo=
uld just to drop the "print-" prefix and call it "color-mode".

Tom

________________________________
From: ipp-bounces@pwg.org [mailto:ipp-bounces@p=
wg.org] On Behalf Of Ira McDonald
Sent: Monday, April 18, 2011 15:35
To: Michael Sweet; Ira McDonald
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

Hi Mike,

My two cents.

No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.

In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.

Unless almost all Printer attributes *are* applicable, which I begin
to suspect is the case (and have a short table of the exceptions).

I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP
Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434


On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet > wrote:
All,

If we consider scanning and printing of forms, the "bi-level" (threshold) m=
ode makes sense for both. Do we want to rename "print-color-mode" to "imagi=
ng-color-mode" in anticipation of using is for other MFD services in IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Tue Apr 19 12:07:25 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 410A0E07D2 for ; Tue, 19 Apr 2011 12:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK-+BTL5FYWi for ; Tue, 19 Apr 2011 12:07:24 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 0F8FEE0782 for ; Tue, 19 Apr 2011 12:07:24 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 117F6795CF; Tue, 19 Apr 2011 15:07:09 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 0DDD8795BF for ; Tue, 19 Apr 2011 15:06:55 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Apr 2011 12:06:51 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Tue, 19 Apr 2011 12:06:50 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Index: Acv+w/KhJsck0jnFSKCjc/QHIUEsSQAAEiQA
References: 
From: "Petrie, Glen" 
To: "Mitchell, Andrew \(Solutions Architect\)" , , "Ira McDonald" , "Michael Sweet" 
X-OriginalArrivalTime: 19 Apr 2011 19:06:51.0964 (UTC) FILETIME=[F0F22FC0:01CBFEC4]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 117F6795CF.A86C6
X-pwg-MailScanner-From: ipp-bounces@pwg.org

If the "color-mode" refers to the capability (setting) of the scanner or th=
e fax; then I vote for 1. below to clearly denote this.   An image does not=
 have a "color-mode"; it has a color space.  Mode implies functionality not=
 a state.

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Mitchel=
l, Andrew (Solutions Architect)
Sent: Tuesday, April 19, 2011 12:00 PM
To: tom.hastings@alum.mit.edu; 'Ira McDonald'; 'Michael Sweet'
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

OK, my 2=A2.

We need to decide if naming a NEW attribute that applies to more then just =
print with the print- prefix makes sense. A agree that renaming existing at=
tributes does not make sense, and using the print- attributes in scan (and =
fax) rather then renaming them is logical. But if we are going to say attri=
butes that are originally defined in Scan (or Fax) start with imaging- whil=
e if they first show up in IPP Everywhere (or some other doc like JPS3) we =
name them print- that doesn't seam quite right. My preference would be eith=
er:


 1.  Call everything that is not scan (or fax) specific print-, no matter w=
here it is first defined. For scan or fax specific, call them scan- and fax=
-.
 2.  Start using the imaging- prefix everywhere that the term is NOT print =
specific.

We are going to expand the model which is heavily rooted in print to other =
services, I'd just like to have a consistent naming convention for how we m=
ove forward. 1 seems more confusing to me since it means keeping the print-=
 name moving forward, and we'll have to maintain the table as to what is pr=
int specific and what isn't, but 1 also seems more true to the roots of IPP=
. I however personally vote for 2 since it clearly implies our broader scop=
e of the protocol moving forward.

As for just dropping the print- prefix, while it works for color-mode, I th=
ink we need to take a harder look to make sure it makes sense everywhere. N=
ote that I view this as simply a different way of naming option 2. If we pi=
ck option 2 we need to then pick the naming convention.

OK, so that was a bit more the 2=A2 worth.

Andrew

From: Tom Hastings >
Reply-To: "tom.hastings@alum.mit.edu" >
Date: Tue, 19 Apr 2011 18:45:45 +0000
To: 'Ira McDonald' =
>, 'Michael Sweet' >
Cc: "ipp@pwg.org" >
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

I agree with Ira.  On the other hand, one other alternative for the name wo=
uld just to drop the "print-" prefix and call it "color-mode".

Tom

________________________________
From: ipp-bounces@pwg.org [mailto:ipp-bounces@p=
wg.org] On Behalf Of Ira McDonald
Sent: Monday, April 18, 2011 15:35
To: Michael Sweet; Ira McDonald
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

Hi Mike,

My two cents.

No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.

In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.

Unless almost all Printer attributes *are* applicable, which I begin
to suspect is the case (and have a short table of the exceptions).

I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP
Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434


On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet > wrote:
All,

If we consider scanning and printing of forms, the "bi-level" (threshold) m=
ode makes sense for both. Do we want to rename "print-color-mode" to "imagi=
ng-color-mode" in anticipation of using is for other MFD services in IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From amkjhnmt@ms2.hinet.net  Tue Apr 19 12:08:35 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0405AE0776; Tue, 19 Apr 2011 12:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -76.313
X-Spam-Level: 
X-Spam-Status: No, score=-76.313 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCdNzjNLJ83I; Tue, 19 Apr 2011 12:08:34 -0700 (PDT)
Received: from 189-54-59-216-nd.cpe.vivax.com.br (189-54-59-216-nd.cpe.vivax.com.br [189.54.59.216]) by ietfc.amsl.com (Postfix) with ESMTP id 555DEE072D; Tue, 19 Apr 2011 12:08:27 -0700 (PDT)
Received: from 189.54.59.216(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MMBC7-8669rv-TQ for ; Tue, 19 Apr 2011 16:08:32 -0300
From: , 
To: , 
Subject: Newsletter Tue, 19 Apr 2011 16:08:32 -0300
Date: Tue, 19 Apr 2011 16:08:32 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: zvfhxk.04
Message-ID: <8067925850.VPS0GT6I441860@swrpghuzzpckm.qahxkebulihhicr.org>

How are you bud!

Do you want an extraordinary future,  double in money earning power, and the respect of all?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will help ANYONE with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- Just follow YOUR Dreams!
- Live a much better life by earning or upgrading your degree.


This is a exellent way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


Contact us NOW to start improving your life!


~CALL~


1-301-396-3506



Please leave us a message with your name and phone number with country code if outside USA and we will call you back as soon as possible.


It's your way...
Make the right move.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Tue Apr 19 12:49:27 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0506FE069C for ; Tue, 19 Apr 2011 12:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGFZMHNtldGx for ; Tue, 19 Apr 2011 12:49:24 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id BD5CBE0715 for ; Tue, 19 Apr 2011 12:49:24 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 25198795DE; Tue, 19 Apr 2011 15:49:08 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com [209.85.161.46]) by pwg.org (Postfix) with ESMTP id D2411795DE for ; Tue, 19 Apr 2011 15:48:54 -0400 (EDT)
Received: by fxm17 with SMTP id 17so61259fxm.5 for ; Tue, 19 Apr 2011 12:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R535bRuvFqxzBrJuyQA4q5er5izyV1bTQId7CIbSjFA=; b=D08tch4XkD+cKfD9eTWxMH0SfTa/wxrs+yjmRT7F1UgWeNbzxmZoqWELHatuiUJd8F lLDmFi+rr0kZzvz+KWbORQf+SVnqWouwijTmf5FdolkjMlsNOnRtyqD78y/6SvJdBTO6 a3+6DmAdoX+ygn2FoKMfic+4Br5n8z7fHIKKI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wt8kkitxWoS3bYYdUXjkLXkgq473Fq/5wMmqFI5/lD97urAj4U/D4KFioubk6ztfTR 2f9BVPtxNmFnj1rsLTjg0RWxACnw8ca/+k4BUlPKIpY39VIjBZkuO3Gx2GPe7uMKvTAE +SN6VGcUdDreGpm2JvM8H2EJ2PhWp4ahRxOyo=
MIME-Version: 1.0
Received: by 10.223.85.195 with SMTP id p3mr1231687fal.0.1303242533718; Tue, 19 Apr 2011 12:48:53 -0700 (PDT)
Received: by 10.223.120.135 with HTTP; Tue, 19 Apr 2011 12:48:53 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 19 Apr 2011 15:48:53 -0400
Message-ID: 
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
From: Ira McDonald 
To: "Petrie, Glen" , Ira McDonald 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0988515434=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 25198795DE.A99FB
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0988515434==
Content-Type: multipart/alternative; boundary=20cf3054a697474bd504a14acc03


--20cf3054a697474bd504a14acc03
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On reflection, I tend to agree with Andrew that we should
(in general) use the 'imaging-' prefix for our new attributes.

But I *think* we meant the new 'print-color-mode' property
to refer specifically to hardcopy output (print).

I don't think it fits well w/ scan (output image format) or fax.

All - note that we generally *drop* the 'print-' or 'job-' or
whatever prefix in the PWG Semantic Model XML Schema
in order to reuse the "same" (well similar) attribute at more
than one level of the system/service/job/document hierarchy.

Pete - please chime in with your opinion here.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen w=
rote:

> If the "color-mode" refers to the capability (setting) of the scanner or
> the fax; then I vote for 1. below to clearly denote this.   An image does
> not have a "color-mode"; it has a color space.  Mode implies functionality
> not a state.
>
> Glen
>
>
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
> Mitchell, Andrew (Solutions Architect)
> Sent: Tuesday, April 19, 2011 12:00 PM
> To: tom.hastings@alum.mit.edu; 'Ira McDonald'; 'Michael Sweet'
> Cc: ipp@pwg.org
> Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>
> OK, my 2=A2.
>
> We need to decide if naming a NEW attribute that applies to more then just
> print with the print- prefix makes sense. A agree that renaming existing
> attributes does not make sense, and using the print- attributes in scan (=
and
> fax) rather then renaming them is logical. But if we are going to say
> attributes that are originally defined in Scan (or Fax) start with imagin=
g-
> while if they first show up in IPP Everywhere (or some other doc like JPS=
3)
> we name them print- that doesn't seam quite right. My preference would be
> either:
>
>
>  1.  Call everything that is not scan (or fax) specific print-, no matter
> where it is first defined. For scan or fax specific, call them scan- and
> fax-.
>  2.  Start using the imaging- prefix everywhere that the term is NOT print
> specific.
>
> We are going to expand the model which is heavily rooted in print to other
> services, I'd just like to have a consistent naming convention for how we
> move forward. 1 seems more confusing to me since it means keeping the pri=
nt-
> name moving forward, and we'll have to maintain the table as to what is
> print specific and what isn't, but 1 also seems more true to the roots of
> IPP. I however personally vote for 2 since it clearly implies our broader
> scope of the protocol moving forward.
>
> As for just dropping the print- prefix, while it works for color-mode, I
> think we need to take a harder look to make sure it makes sense everywher=
e.
> Note that I view this as simply a different way of naming option 2. If we
> pick option 2 we need to then pick the naming convention.
>
> OK, so that was a bit more the 2=A2 worth.
>
> Andrew
>
> From: Tom Hastings  tom.hastings@verizon.net>>
> Reply-To: "tom.hastings@alum.mit.edu" <
> tom.hastings@alum.mit.edu>
> Date: Tue, 19 Apr 2011 18:45:45 +0000
> To: 'Ira McDonald' >,
> 'Michael Sweet' >
> Cc: "ipp@pwg.org" >
> Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
>
> I agree with Ira.  On the other hand, one other alternative for the name
> would just to drop the "print-" prefix and call it "color-mode".
>
> Tom
>
> ________________________________
> From: ipp-bounces@pwg.org [mailto:
> ipp-bounces@pwg.org] On Behalf Of Ira McDonald
> Sent: Monday, April 18, 2011 15:35
> To: Michael Sweet; Ira McDonald
> Cc: ipp@pwg.org
> Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>
> Hi Mike,
>
> My two cents.
>
> No - let's keep the name "print-color-mode" to cohere with the
> zillion other print-xxx or printer-xxx attributes.
>
> In the new IPP Scanner and Fax objects lets just globally apply
> most/many existing IPP Printer attributes in big table(s) with
> a rationale for why some attributes are not applicable to the
> other multifunction objects.
>
> Unless almost all Printer attributes *are* applicable, which I begin
> to suspect is the case (and have a short table of the exceptions).
>
> I think we should reserve use of he "imaging-" prefix for only new
> attributes defined first for Scanner, Fax, etc. objects for IPP
> Everywhere Second Edition.
>
> Cheers,
> - Ira
>
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> May to Christmas:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>
>
> On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet  msweet@apple.com>> wrote:
> All,
>
> If we consider scanning and printing of forms, the "bi-level" (threshold)
> mode makes sense for both. Do we want to rename "print-color-mode" to
> "imaging-color-mode" in anticipation of using is for other MFD services in
> IPP?
>
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--20cf3054a697474bd504a14acc03
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On reflection, I tend to agree with Andrew that we should
(in=
 general) use the 'imaging-' prefix for our new attributes.

=
But I *think* we meant the new 'print-color-mode' property
to re=
fer specifically to hardcopy output (print).


I don't think it fits well w/ scan (output image format) or fax.
All - note that we generally *drop* the 'print-' or 'job-&=
#39; or
whatever prefix in the PWG Semantic Model XML Schema
in order=
 to reuse the "same" (well similar) attribute at more

than one level of the system/service/job/document hierarchy.


Pete - please chime in with your opinion here.


Cheers,
- Ira

Ira McDonald (Musician / Software=
 Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE=
-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - =
IPP & Printer MIB

Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic<=
/a>
http://sites.google.com/site/highnorth=
inc

mailto:blueroo=
fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S=
aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2=
21=A0 Grand Marais, MI 49839

=A0 906-494-2434




On Tue, Apr 19, 2011 at 3:06 PM, Petrie,=
 Glen <g=
len.petrie@eitc.epson.com> wrote:

If the "color-mode" refers to the capability (setting) of the sca=
nner or the fax; then I vote for 1. below to clearly denote this. =A0 An im=
age does not have a "color-mode"; it has a color space. =A0Mode i=
mplies functionality not a state.




Glen






-----Original Message-----

From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf=
 Of Mitchell, Andrew (Solutions Architect)

Sent: Tuesday, April 19, 2011 12:00 PM

To: tom.hastings@alum.mit.edu<=
/a>; 'Ira McDonald'; 'Michael Sweet'

Cc: ipp@pwg.org

Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode=
"?



OK, my 2=A2.



We need to decide if naming a NEW attribute that applies to more then just =
print with the print- prefix makes sense. A agree that renaming existing at=
tributes does not make sense, and using the print- attributes in scan (and =
fax) rather then renaming them is logical. But if we are going to say attri=
butes that are originally defined in Scan (or Fax) start with imaging- whil=
e if they first show up in IPP Everywhere (or some other doc like JPS3) we =
name them print- that doesn't seam quite right. My preference would be =
either:






=A01. =A0Call everything that is not scan (or fax) specific print-, no matt=
er where it is first defined. For scan or fax specific, call them scan- and=
 fax-.

=A02. =A0Start using the imaging- prefix everywhere that the term is NOT pr=
int specific.



We are going to expand the model which is heavily rooted in print to other =
services, I'd just like to have a consistent naming convention for how =
we move forward. 1 seems more confusing to me since it means keeping the pr=
int- name moving forward, and we'll have to maintain the table as to wh=
at is print specific and what isn't, but 1 also seems more true to the =
roots of IPP. I however personally vote for 2 since it clearly implies our =
broader scope of the protocol moving forward.




As for just dropping the print- prefix, while it works for color-mode, I th=
ink we need to take a harder look to make sure it makes sense everywhere. N=
ote that I view this as simply a different way of naming option 2. If we pi=
ck option 2 we need to then pick the naming convention.




OK, so that was a bit more the 2=A2 worth.



Andrew



From: Tom Hastings <tom.hast=
ings@verizon.net<mailto:=
tom.hastings@verizon.net>>

Reply-To: "tom.hastings@a=
lum.mit.edu<mailto:tom.=
hastings@alum.mit.edu>" <tom.hastings@alum.mit.edu<mailto:tom.hastings@alum.mit.edu>>


Date: Tue, 19 Apr 2011 18:45:45 +0000

To: 'Ira McDonald' <b=
lueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>>, 'Michael Sweet' <msweet@apple.com<mailto:msweet@apple.com>>


Cc: "ipp@pwg.org<mailto:ipp@pwg.org>" <ipp@pwg.org<mailto:ipp@pwg.=
org>>


Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode=
"?



I agree with Ira. =A0On the other hand, one other alternative for the name =
would just to drop the "print-" prefix and call it "color-mo=
de".



Tom



________________________________

From: ipp-bounces@pwg.org<mai=
lto:ipp-bounces@pwg.org> [mai=
lto:ipp-bounces@pwg.org] On Beha=
lf Of Ira McDonald


Sent: Monday, April 18, 2011 15:35

To: Michael Sweet; Ira McDonald

Cc: ipp@pwg.org<mailto:ipp@pwg.org>

Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode=
"?



Hi Mike,



My two cents.



No - let's keep the name "print-color-mode" to cohere with th=
e

zillion other print-xxx or printer-xxx attributes.



In the new IPP Scanner and Fax objects lets just globally apply

most/many existing IPP Printer attributes in big table(s) with

a rationale for why some attributes are not applicable to the

other multifunction objects.



Unless almost all Printer attributes *are* applicable, which I begin

to suspect is the case (and have a short table of the exceptions).



I think we should reserve use of he "imaging-" prefix for only ne=
w

attributes defined first for Scanner, Fax, etc. objects for IPP

Everywhere Second Edition.



Cheers,

- Ira





Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

htt=
p://sites.google.com/site/highnorthinc

mailto:blueroofmusic@gmail.com<mailto:blueroofmusic@gmail=
.com>

Christmas through April:

579 Park Place Saline, MI 48176

734-944-0094

May to Christmas:

PO Box 221 Grand Marais, MI 49839

906-494-2434





On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet <msweet@apple.com<mailto:msweet@apple.com>> wrote:

All,



If we consider scanning and printing of forms, the "bi-level" (th=
reshold) mode makes sense for both. Do we want to rename "print-color-=
mode" to "imaging-color-mode" in anticipation of using is fo=
r other MFD services in IPP?




________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org<mailto:ipp@pwg.org>

http=
s://www.pwg.org/mailman/listinfo/ipp





--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.



--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.




--


This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--20cf3054a697474bd504a14acc03--

--===============0988515434==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0988515434==--

From ipp-bounces@pwg.org  Tue Apr 19 13:06:48 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D5FBE0811 for ; Tue, 19 Apr 2011 13:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH8BmKR2Ifxs for ; Tue, 19 Apr 2011 13:06:39 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 86B62E0809 for ; Tue, 19 Apr 2011 13:06:39 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 0818D795E5; Tue, 19 Apr 2011 16:06:19 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 6265D795C9 for ; Tue, 19 Apr 2011 16:06:00 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Apr 2011 13:05:59 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Tue, 19 Apr 2011 13:05:56 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Index: Acv+yuJKEfoLG2atRaW+yLlMHJ+xlAAABvBw
References:  
From: "Petrie, Glen" 
To: "Ira McDonald" 
X-OriginalArrivalTime: 19 Apr 2011 20:05:59.0966 (UTC) FILETIME=[33B853E0:01CBFECD]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0360108043=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 0818D795E5.A9D92
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0360108043==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CBFECD.319E0AA1"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CBFECD.319E0AA1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ira, I believe the property refers to the functional mode the printer is to=
 use or was used to produce the output.  That is; the printer is printing i=
n or instructed to print in a ""color mode"".   If this property was meant =
to represent the "state" of the output; then for print, and later for scan =
and fax, it should be (have been) called "color-space".   Then it would mak=
e more sense to have used the prefix "image" (versus even the word "imaging=
"); so we have image-color-space (the printed image, the scanned image, the=
 fax image - the key here it is the image and the device functionality or d=
evice capabilities or device mode.).=20

=20

So the device is instructed (or uses) to have a specific

print-color-mode, scan-color-mode or fax-color-mode to produce an (hard or =
electronic) image that has an image-color-space

=20

what about "device-color-mode"

=20

Glen

=20

________________________________

From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
Sent: Tuesday, April 19, 2011 12:49 PM
To: Petrie, Glen; Ira McDonald
Cc: Mitchell, Andrew (Solutions Architect); tom.hastings@alum.mit.edu; Mich=
ael Sweet; ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

=20

Hi,

On reflection, I tend to agree with Andrew that we should
(in general) use the 'imaging-' prefix for our new attributes.

But I *think* we meant the new 'print-color-mode' property
to refer specifically to hardcopy output (print).

I don't think it fits well w/ scan (output image format) or fax.

All - note that we generally *drop* the 'print-' or 'job-' or
whatever prefix in the PWG Semantic Model XML Schema
in order to reuse the "same" (well similar) attribute at more
than one level of the system/service/job/document hierarchy.

Pete - please chime in with your opinion here.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc =20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434





On Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen  =
wrote:

If the "color-mode" refers to the capability (setting) of the scanner or th=
e fax; then I vote for 1. below to clearly denote this.   An image does not=
 have a "color-mode"; it has a color space.  Mode implies functionality not=
 a state.

Glen



-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Mitchel=
l, Andrew (Solutions Architect)
Sent: Tuesday, April 19, 2011 12:00 PM
To: tom.hastings@alum.mit.edu; 'Ira McDonald'; 'Michael Sweet'
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

OK, my 2=A2.

We need to decide if naming a NEW attribute that applies to more then just =
print with the print- prefix makes sense. A agree that renaming existing at=
tributes does not make sense, and using the print- attributes in scan (and =
fax) rather then renaming them is logical. But if we are going to say attri=
butes that are originally defined in Scan (or Fax) start with imaging- whil=
e if they first show up in IPP Everywhere (or some other doc like JPS3) we =
name them print- that doesn't seam quite right. My preference would be eith=
er:


 1.  Call everything that is not scan (or fax) specific print-, no matter w=
here it is first defined. For scan or fax specific, call them scan- and fax=
-.
 2.  Start using the imaging- prefix everywhere that the term is NOT print =
specific.

We are going to expand the model which is heavily rooted in print to other =
services, I'd just like to have a consistent naming convention for how we m=
ove forward. 1 seems more confusing to me since it means keeping the print-=
 name moving forward, and we'll have to maintain the table as to what is pr=
int specific and what isn't, but 1 also seems more true to the roots of IPP=
. I however personally vote for 2 since it clearly implies our broader scop=
e of the protocol moving forward.

As for just dropping the print- prefix, while it works for color-mode, I th=
ink we need to take a harder look to make sure it makes sense everywhere. N=
ote that I view this as simply a different way of naming option 2. If we pi=
ck option 2 we need to then pick the naming convention.

OK, so that was a bit more the 2=A2 worth.

Andrew

From: Tom Hastings >
Reply-To: "tom.hastings@alum.mit.edu" >
Date: Tue, 19 Apr 2011 18:45:45 +0000
To: 'Ira McDonald' =
>, 'Michael Sweet' >
Cc: "ipp@pwg.org" >
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

I agree with Ira.  On the other hand, one other alternative for the name wo=
uld just to drop the "print-" prefix and call it "color-mode".

Tom

________________________________
From: ipp-bounces@pwg.org [mailto:ipp-bounces@p=
wg.org] On Behalf Of Ira McDonald
Sent: Monday, April 18, 2011 15:35
To: Michael Sweet; Ira McDonald
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

Hi Mike,

My two cents.

No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.

In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.

Unless almost all Printer attributes *are* applicable, which I begin
to suspect is the case (and have a short table of the exceptions).

I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP
Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434


On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet > wrote:
All,

If we consider scanning and printing of forms, the "bi-level" (threshold) m=
ode makes sense for both. Do we want to rename "print-color-mode" to "imagi=
ng-color-mode" in anticipation of using is for other MFD services in IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org

https://www.pwg.org/mailman/listinfo/ipp

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CBFECD.319E0AA1
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable























Ira, I believe the property refers to
the functional mode the printer is to use or was used to produce the output=
. =A0That
is; the printer is printing in or instructed to print in a “”co=
lor
mode””. =A0=A0If this property was meant to represent the ̶=
0;state”
of the output; then for print, and later for scan and fax, it should be (ha=
ve
been) called “color-space”. =A0=A0Then it would make more sense=
 to have
used the prefix “image” (versus even the word “imaging=
221;);
so we have image-color-space (the printed image, the scanned image, the fax
image – the key here it is the image and the device functionality or
device capabilities or device mode.). 



 



So the device is instructed (or uses=
) to
have a specific



print-color-mode, scan-color-mode or
fax-color-mode to produce an (hard or electronic) image that has an
image-color-space



 



what about “device-color-mode&=
#8221;



 



Glen






 












From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Tuesday, April 19, 2011
12:49 PM

To: Petrie, Glen; Ira McDona=
ld

Cc: Mitchell, Andrew (Soluti=
ons
Architect); tom.hastings@alum.mit.edu; Michael Sweet; ipp@pwg.org

Subject: Re: [IPP]
"print-color-mode" or "imaging-color-mode"?






 



Hi,



On reflection, I tend to agree with Andrew that we should

(in general) use the 'imaging-' prefix for our new attributes.



But I *think* we meant the new 'print-color-mode' property

to refer specifically to hardcopy output (print).



I don't think it fits well w/ scan (output image format) or fax.



All - note that we generally *drop* the 'print-' or 'job-' or

whatever prefix in the PWG Semantic Model XML Schema

in order to reuse the "same" (well similar) attribute at more

than one level of the system/service/job/document hierarchy.



Pete - please chime in with your opinion here.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box=
 221 
Grand Marais, MI 49839

  906-494-2434














On Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:



If the "color-mode" refers to the capability (setting) of=
 the
scanner or the fax; then I vote for 1. below to clearly denote this.  =
 An
image does not have a "color-mode"; it has a color space.  M=
ode
implies functionality not a state.



Glen













-----Original Message-----

From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf Of
Mitchell, Andrew (Solutions Architect)

Sent: Tuesday, April 19, 2011 12:00 PM

To: tom.hastings@alum.mit.edu<=
/a>;
'Ira McDonald'; 'Michael Sweet'

Cc: ipp@pwg.org

Subject: Re: [IPP] "print-color-mode" or
"imaging-color-mode"?



OK, my 2=A2.



We need to decide if naming a NEW attribute that applies to more then just
print with the print- prefix makes sense. A agree that renaming existing
attributes does not make sense, and using the print- attributes in scan (and
fax) rather then renaming them is logical. But if we are going to say attri=
butes
that are originally defined in Scan (or Fax) start with imaging- while if t=
hey
first show up in IPP Everywhere (or some other doc like JPS3) we name them
print- that doesn't seam quite right. My preference would be either:





 1.  Call everything that is not scan (or fax) specific print-, no
matter where it is first defined. For scan or fax specific, call them scan-=
 and
fax-.

 2.  Start using the imaging- prefix everywhere that the term is =
NOT
print specific.



We are going to expand the model which is heavily rooted in print to other
services, I'd just like to have a consistent naming convention for how we m=
ove
forward. 1 seems more confusing to me since it means keeping the print- name
moving forward, and we'll have to maintain the table as to what is print
specific and what isn't, but 1 also seems more true to the roots of IPP. I
however personally vote for 2 since it clearly implies our broader scope of=
 the
protocol moving forward.



As for just dropping the print- prefix, while it works for color-mode, I th=
ink
we need to take a harder look to make sure it makes sense everywhere. Note =
that
I view this as simply a different way of naming option 2. If we pick option=
 2
we need to then pick the naming convention.



OK, so that was a bit more the 2=A2 worth.



Andrew



From: Tom Hastings <tom.hast=
ings@verizon.net<mailto:tom.hastings@verizon.net>&g=
t;

Reply-To: "tom.hastings@a=
lum.mit.edu<mailto:tom.hastings@alum.mit.edu>=
"
<tom.hastings@alum.mit.edu<=
/a><mailto:tom.hastings@alum.mit.edu>=
>

Date: Tue, 19 Apr 2011 18:45:45 +0000

To: 'Ira McDonald' <blueroofm=
usic@gmail.com<mailto:blueroofmusic@gmail.com>>,
'Michael Sweet' <msweet@apple.com<mailto:msweet@apple.com>>

Cc: "ipp@pwg.org<mailto:ipp@pwg.org>" <ipp@pwg.org<mailto:ipp@pwg.org>>

Subject: RE: [IPP] "print-color-mode" or
"imaging-color-mode"?



I agree with Ira.  On the other hand, one other alternative for the na=
me
would just to drop the "print-" prefix and call it
"color-mode".



Tom



________________________________

From: ipp-bounces@pwg.org<mai=
lto:ipp-bounces@pwg.org> [mailto:ipp-bounces@pwg.org] On Behalf Of I=
ra
McDonald

Sent: Monday, April 18, 2011 15:35

To: Michael Sweet; Ira McDonald

Cc: ipp@pwg.org<mailto:ipp@pwg.org>

Subject: Re: [IPP] "print-color-mode" or
"imaging-color-mode"?



Hi Mike,



My two cents.



No - let's keep the name "print-color-mode" to cohere with the

zillion other print-xxx or printer-xxx attributes.



In the new IPP Scanner and Fax objects lets just globally apply

most/many existing IPP Printer attributes in big table(s) with

a rationale for why some attributes are not applicable to the

other multifunction objects.



Unless almost all Printer attributes *are* applicable, which I begin

to suspect is the case (and have a short table of the exceptions).



I think we should reserve use of he "imaging-" prefix for only ne=
w

attributes defined first for Scanner, Fax, etc. objects for IPP

Everywhere Second Edition.



Cheers,

- Ira





Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

htt=
p://sites.google.com/site/highnorthinc

mailto:blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>

Christmas through April:

579 Park Place Saline, MI 48176

734-944-0094

May to Christmas:

PO Box 221
Grand Marais, MI 49839

906-494-2434





On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet <msweet@apple.com<mailto:msweet@apple.com>> wrote:

All,



If we consider scanning and printing of forms, the "bi-level"
(threshold) mode makes sense for both. Do we want to rename "print-col=
or-mode"
to "imaging-color-mode" in anticipation of using is for other MFD
services in IPP?



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org<mailto:ipp@pwg.org>

http=
s://www.pwg.org/mailman/listinfo/ipp





--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.



--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.









--






This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org











 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CBFECD.319E0AA1--

--===============0360108043==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0360108043==--

From ipp-bounces@pwg.org  Tue Apr 19 13:17:30 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C7F5AE085D for ; Tue, 19 Apr 2011 13:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level: 
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNM+YTPW0bPn for ; Tue, 19 Apr 2011 13:17:29 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 9050EE0717 for ; Tue, 19 Apr 2011 13:17:29 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E939B795E5; Tue, 19 Apr 2011 16:17:15 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 6DD1F795E3 for ; Tue, 19 Apr 2011 16:17:03 -0400 (EDT)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJX00E571KK10S0@mail-out.apple.com> for ipp@pwg.org; Tue, 19 Apr 2011 13:16:43 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-78-4dadeda9965a
Received: from [17.151.73.2] (Unknown_Domain [17.151.73.2]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay16.apple.com (Apple SCV relay) with SMTP id 4B.9C.12552.AADEDAD4; Tue, 19 Apr 2011 13:16:42 -0700 (PDT)
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
From: Michael Sweet 
In-reply-to: 
Date: Tue, 19 Apr 2011 13:16:41 -0700
Content-transfer-encoding: quoted-printable
Message-id: 
References: 
To: "Mitchell, Andrew (Solutions Architect)" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: E939B795E5.A8BD9
X-pwg-MailScanner-From: ipp-bounces@pwg.org

All,

I've done some research (mainly going back through the MFD Scan and Model d=
ocuments) and both define the ColorEntry job ticket element to control the =
corollary of print-color-mode for scanning. So, for purposes of IPP Scan I =
would opt to use color-entry and the corresponding mapped keywords from the=
 MFD Scan/Model specs.

In general I think we can stick with the existing names. If something new a=
pplies to multiple services and doesn't have a logical prefix of its own, a=
dd "imaging-" to the front. If something is service-specific, put the servi=
ce name on the front..

All that said, here is another wrinkle: copy, which has input and output jo=
b ticket elements...  I'm thinking we just use collections, but we have tim=
e to discuss the actual binding...

On Apr 19, 2011, at 11:59 AM, Mitchell, Andrew (Solutions Architect) wrote:

> OK, my 2=A2.
>=20
> We need to decide if naming a NEW attribute that applies to more then jus=
t print with the print- prefix makes sense. A agree that renaming existing =
attributes does not make sense, and using the print- attributes in scan (an=
d fax) rather then renaming them is logical. But if we are going to say att=
ributes that are originally defined in Scan (or Fax) start with imaging- wh=
ile if they first show up in IPP Everywhere (or some other doc like JPS3) w=
e name them print- that doesn't seam quite right. My preference would be ei=
ther:
>=20
>=20
> 1.  Call everything that is not scan (or fax) specific print-, no matter =
where it is first defined. For scan or fax specific, call them scan- and fa=
x-.
> 2.  Start using the imaging- prefix everywhere that the term is NOT print=
 specific.
>=20
> We are going to expand the model which is heavily rooted in print to othe=
r services, I'd just like to have a consistent naming convention for how we=
 move forward. 1 seems more confusing to me since it means keeping the prin=
t- name moving forward, and we'll have to maintain the table as to what is =
print specific and what isn't, but 1 also seems more true to the roots of I=
PP. I however personally vote for 2 since it clearly implies our broader sc=
ope of the protocol moving forward.
>=20
> As for just dropping the print- prefix, while it works for color-mode, I =
think we need to take a harder look to make sure it makes sense everywhere.=
 Note that I view this as simply a different way of naming option 2. If we =
pick option 2 we need to then pick the naming convention.
>=20
> OK, so that was a bit more the 2=A2 worth.
>=20
> Andrew
>=20
> From: Tom Hastings >
> Reply-To: "tom.hastings@alum.mit.edu" <=
tom.hastings@alum.mit.edu>
> Date: Tue, 19 Apr 2011 18:45:45 +0000
> To: 'Ira McDonald' >, 'Michael Sweet' >
> Cc: "ipp@pwg.org" >
> Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
>=20
> I agree with Ira.  On the other hand, one other alternative for the name =
would just to drop the "print-" prefix and call it "color-mode".
>=20
> Tom
>=20
> ________________________________
> From: ipp-bounces@pwg.org [mailto:ipp-bounces=
@pwg.org] On Behalf Of Ira McDonald
> Sent: Monday, April 18, 2011 15:35
> To: Michael Sweet; Ira McDonald
> Cc: ipp@pwg.org
> Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>=20
> Hi Mike,
>=20
> My two cents.
>=20
> No - let's keep the name "print-color-mode" to cohere with the
> zillion other print-xxx or printer-xxx attributes.
>=20
> In the new IPP Scanner and Fax objects lets just globally apply
> most/many existing IPP Printer attributes in big table(s) with
> a rationale for why some attributes are not applicable to the
> other multifunction objects.
>=20
> Unless almost all Printer attributes *are* applicable, which I begin
> to suspect is the case (and have a short table of the exceptions).
>=20
> I think we should reserve use of he "imaging-" prefix for only new
> attributes defined first for Scanner, Fax, etc. objects for IPP
> Everywhere Second Edition.
>=20
> Cheers,
> - Ira
>=20
>=20
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> May to Christmas:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>=20
>=20
> On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet > wrote:
> All,
>=20
> If we consider scanning and printing of forms, the "bi-level" (threshold)=
 mode makes sense for both. Do we want to rename "print-color-mode" to "ima=
ging-color-mode" in anticipation of using is for other MFD services in IPP?
>=20
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>=20
>=20
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>=20
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>=20
>=20
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>=20
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Tue Apr 19 13:19:47 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1838DE0670 for ; Tue, 19 Apr 2011 13:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, WEIRD_QUOTING=1.396]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gU56mlE+dGh for ; Tue, 19 Apr 2011 13:19:38 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id A338FE0717 for ; Tue, 19 Apr 2011 13:19:38 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id EE59B795F7; Tue, 19 Apr 2011 16:19:11 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id C70BA795F8 for ; Tue, 19 Apr 2011 16:18:40 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Apr 2011 13:18:39 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Tue, 19 Apr 2011 13:18:38 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] "print-color-mode" or "imaging-color-mode"?
Thread-Index: Acv+yuJKEfoLG2atRaW+yLlMHJ+xlAAABvBwAACk/LA=
References:  
From: "Petrie, Glen" 
To: "Petrie, Glen" , "Ira McDonald" 
X-OriginalArrivalTime: 19 Apr 2011 20:18:39.0878 (UTC) FILETIME=[F8A9B260:01CBFECE]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1876239158=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: EE59B795F7.A9B5C
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1876239158==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CBFECE.F7FAF9F0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CBFECE.F7FAF9F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ira, if by chance, the prefix "print" was meant to be a verb versus denotin=
g the device (printer, scanner, fax) does it really change the idea that it=
 is still referring to the device ""color-mode"".   The prefix "imaging", I=
 assume, is being used verb as a verb; but still, I believe it leads to amb=
iguity about the attribute while the prefix's scan and fax are clear and co=
ncise.=20=20

=20

glen

=20

________________________________

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie,=
 Glen
Sent: Tuesday, April 19, 2011 1:06 PM
To: Ira McDonald
Cc: ipp@pwg.org
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

=20

Ira, I believe the property refers to the functional mode the printer is to=
 use or was used to produce the output.  That is; the printer is printing i=
n or instructed to print in a ""color mode"".   If this property was meant =
to represent the "state" of the output; then for print, and later for scan =
and fax, it should be (have been) called "color-space".   Then it would mak=
e more sense to have used the prefix "image" (versus even the word "imaging=
"); so we have image-color-space (the printed image, the scanned image, the=
 fax image - the key here it is the image and the device functionality or d=
evice capabilities or device mode.).=20

=20

So the device is instructed (or uses) to have a specific

print-color-mode, scan-color-mode or fax-color-mode to produce an (hard or =
electronic) image that has an image-color-space

=20

what about "device-color-mode"

=20

Glen

=20

________________________________

From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
Sent: Tuesday, April 19, 2011 12:49 PM
To: Petrie, Glen; Ira McDonald
Cc: Mitchell, Andrew (Solutions Architect); tom.hastings@alum.mit.edu; Mich=
ael Sweet; ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

=20

Hi,

On reflection, I tend to agree with Andrew that we should
(in general) use the 'imaging-' prefix for our new attributes.

But I *think* we meant the new 'print-color-mode' property
to refer specifically to hardcopy output (print).

I don't think it fits well w/ scan (output image format) or fax.

All - note that we generally *drop* the 'print-' or 'job-' or
whatever prefix in the PWG Semantic Model XML Schema
in order to reuse the "same" (well similar) attribute at more
than one level of the system/service/job/document hierarchy.

Pete - please chime in with your opinion here.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc =20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

=20

On Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen  =
wrote:

If the "color-mode" refers to the capability (setting) of the scanner or th=
e fax; then I vote for 1. below to clearly denote this.   An image does not=
 have a "color-mode"; it has a color space.  Mode implies functionality not=
 a state.

Glen



-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Mitchel=
l, Andrew (Solutions Architect)
Sent: Tuesday, April 19, 2011 12:00 PM
To: tom.hastings@alum.mit.edu; 'Ira McDonald'; 'Michael Sweet'
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

OK, my 2=A2.

We need to decide if naming a NEW attribute that applies to more then just =
print with the print- prefix makes sense. A agree that renaming existing at=
tributes does not make sense, and using the print- attributes in scan (and =
fax) rather then renaming them is logical. But if we are going to say attri=
butes that are originally defined in Scan (or Fax) start with imaging- whil=
e if they first show up in IPP Everywhere (or some other doc like JPS3) we =
name them print- that doesn't seam quite right. My preference would be eith=
er:


 1.  Call everything that is not scan (or fax) specific print-, no matter w=
here it is first defined. For scan or fax specific, call them scan- and fax=
-.
 2.  Start using the imaging- prefix everywhere that the term is NOT print =
specific.

We are going to expand the model which is heavily rooted in print to other =
services, I'd just like to have a consistent naming convention for how we m=
ove forward. 1 seems more confusing to me since it means keeping the print-=
 name moving forward, and we'll have to maintain the table as to what is pr=
int specific and what isn't, but 1 also seems more true to the roots of IPP=
. I however personally vote for 2 since it clearly implies our broader scop=
e of the protocol moving forward.

As for just dropping the print- prefix, while it works for color-mode, I th=
ink we need to take a harder look to make sure it makes sense everywhere. N=
ote that I view this as simply a different way of naming option 2. If we pi=
ck option 2 we need to then pick the naming convention.

OK, so that was a bit more the 2=A2 worth.

Andrew

From: Tom Hastings >
Reply-To: "tom.hastings@alum.mit.edu" >
Date: Tue, 19 Apr 2011 18:45:45 +0000
To: 'Ira McDonald' =
>, 'Michael Sweet' >
Cc: "ipp@pwg.org" >
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

I agree with Ira.  On the other hand, one other alternative for the name wo=
uld just to drop the "print-" prefix and call it "color-mode".

Tom

________________________________
From: ipp-bounces@pwg.org [mailto:ipp-bounces@p=
wg.org] On Behalf Of Ira McDonald
Sent: Monday, April 18, 2011 15:35
To: Michael Sweet; Ira McDonald
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

Hi Mike,

My two cents.

No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.

In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.

Unless almost all Printer attributes *are* applicable, which I begin
to suspect is the case (and have a short table of the exceptions).

I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP
Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434


On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet > wrote:
All,

If we consider scanning and printing of forms, the "bi-level" (threshold) m=
ode makes sense for both. Do we want to rename "print-color-mode" to "imagi=
ng-color-mode" in anticipation of using is for other MFD services in IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org

https://www.pwg.org/mailman/listinfo/ipp

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is=20
believed to be clean.=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CBFECE.F7FAF9F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable























Ira, if by chance, the prefix “=
;print”
was meant to be a verb versus denoting the device (printer, scanner, fax) d=
oes
it really change the idea that it is still referring to the device “&=
#8221;color-mode””.
=A0=A0The prefix “imaging”, I assume, is being used verb as a v=
erb; but
still, I believe it leads to ambiguity about the attribute while the prefix=
’s
scan and fax are clear and concise. =A0



 



glen



 















From:
ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie, Glen

Sent: Tuesday, April 19, 201=
1 1:06
PM

To: Ira McDonald

Cc: ipp@pwg.org

Subject: RE: [IPP]
"print-color-mode" or "imaging-color-mode"?






 



Ira, I believe the property refers to
the functional mode the printer is to use or was used to produce the output.
 That is; the printer is printing in or instructed to print in a
“”color mode””.   If this property was me=
ant
to represent the “state” of the output; then for print, and lat=
er
for scan and fax, it should be (have been) called “color-space”.
  Then it would make more sense to have used the prefix
“image” (versus even the word “imaging”); so we have
image-color-space (the printed image, the scanned image, the fax image R=
11;
the key here it is the image and the device functionality or device
capabilities or device mode.). 



 



So the device is instructed (or uses=
) to
have a specific



print-color-mode, scan-color-mode or=
 fax-color-mode
to produce an (hard or electronic) image that has an image-color-space=




 



what about
“device-color-mode”



 



Glen






 












From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Tuesday, April 19, 2011
12:49 PM

To: Petrie, Glen; Ira McDona=
ld

Cc: Mitchell, Andrew (Soluti=
ons
Architect); tom.hastings@alum.mit.edu; Michael Sweet; ipp@pwg.org

Subject: Re: [IPP]
"print-color-mode" or "imaging-color-mode"?






 



Hi,



On reflection, I tend to agree with Andrew that we should

(in general) use the 'imaging-' prefix for our new attributes.



But I *think* we meant the new 'print-color-mode' property

to refer specifically to hardcopy output (print).



I don't think it fits well w/ scan (output image format) or fax.



All - note that we generally *drop* the 'print-' or 'job-' or

whatever prefix in the PWG Semantic Model XML Schema

in order to reuse the "same" (well similar) attribute at more

than one level of the system/service/job/document hierarchy.



Pete - please chime in with your opinion here.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box=
 221 
Grand Marais, MI 49839

  906-494-2434



 =







On Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:



If the "color-mode" refers to the capability (setting) of=
 the
scanner or the fax; then I vote for 1. below to clearly denote this.  =
 An
image does not have a "color-mode"; it has a color space.  M=
ode
implies functionality not a state.



Glen













-----Original Message-----

From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf Of
Mitchell, Andrew (Solutions Architect)

Sent: Tuesday, April 19, 2011 12:00 PM

To: tom.hastings@alum.mit.edu<=
/a>;
'Ira McDonald'; 'Michael Sweet'

Cc: ipp@pwg.org

Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode=
"?



OK, my 2=A2.



We need to decide if naming a NEW attribute that applies to more then just
print with the print- prefix makes sense. A agree that renaming existing
attributes does not make sense, and using the print- attributes in scan (and
fax) rather then renaming them is logical. But if we are going to say
attributes that are originally defined in Scan (or Fax) start with imaging-
while if they first show up in IPP Everywhere (or some other doc like JPS3)=
 we
name them print- that doesn't seam quite right. My preference would be eith=
er:





 1.  Call everything that is not scan (or fax) specific print-, no
matter where it is first defined. For scan or fax specific, call them scan-=
 and
fax-.

 2.  Start using the imaging- prefix everywhere that the term is =
NOT
print specific.



We are going to expand the model which is heavily rooted in print to other
services, I'd just like to have a consistent naming convention for how we m=
ove
forward. 1 seems more confusing to me since it means keeping the print- name
moving forward, and we'll have to maintain the table as to what is print
specific and what isn't, but 1 also seems more true to the roots of IPP. I
however personally vote for 2 since it clearly implies our broader scope of=
 the
protocol moving forward.



As for just dropping the print- prefix, while it works for color-mode, I th=
ink
we need to take a harder look to make sure it makes sense everywhere. Note =
that
I view this as simply a different way of naming option 2. If we pick option=
 2
we need to then pick the naming convention.



OK, so that was a bit more the 2=A2 worth.



Andrew



From: Tom Hastings <tom.hast=
ings@verizon.net<mailto:tom.hastings@verizon.net>&g=
t;

Reply-To: "tom.hastings@a=
lum.mit.edu<mailto:tom.hastings@alum.mit.edu>=
"
<tom.hastings@alum.mit.edu<=
/a><mailto:tom.hastings@alum.mit.edu>=
>

Date: Tue, 19 Apr 2011 18:45:45 +0000

To: 'Ira McDonald' <blueroofm=
usic@gmail.com<mailto:blueroofmusic@gmail.com>>,
'Michael Sweet' <msweet@apple.com<mailto:msweet@apple.com>>

Cc: "ipp@pwg.org<mailto:ipp@pwg.org>" <ipp@pwg.org<mailto:ipp@pwg.org>>

Subject: RE: [IPP] "print-color-mode" or
"imaging-color-mode"?



I agree with Ira.  On the other hand, one other alternative for the na=
me
would just to drop the "print-" prefix and call it
"color-mode".



Tom



________________________________

From: ipp-bounces@pwg.org<mai=
lto:ipp-bounces@pwg.org> [mailto:ipp-bounces@pwg.org] On Behalf Of I=
ra
McDonald

Sent: Monday, April 18, 2011 15:35

To: Michael Sweet; Ira McDonald

Cc: ipp@pwg.org<mailto:ipp@pwg.org>

Subject: Re: [IPP] "print-color-mode" or
"imaging-color-mode"?



Hi Mike,



My two cents.



No - let's keep the name "print-color-mode" to cohere with the

zillion other print-xxx or printer-xxx attributes.



In the new IPP Scanner and Fax objects lets just globally apply

most/many existing IPP Printer attributes in big table(s) with

a rationale for why some attributes are not applicable to the

other multifunction objects.



Unless almost all Printer attributes *are* applicable, which I begin

to suspect is the case (and have a short table of the exceptions).



I think we should reserve use of he "imaging-" prefix for only ne=
w

attributes defined first for Scanner, Fax, etc. objects for IPP

Everywhere Second Edition.



Cheers,

- Ira





Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

htt=
p://sites.google.com/site/highnorthinc

mailto:blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>

Christmas through April:

579 Park Place Saline, MI 48176

734-944-0094

May to Christmas:

PO Box 221
Grand Marais, MI 49839

906-494-2434





On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet <msweet@apple.com<mailto:msweet@apple.com>> wrote:

All,



If we consider scanning and printing of forms, the "bi-level"
(threshold) mode makes sense for both. Do we want to rename
"print-color-mode" to "imaging-color-mode" in anticipat=
ion
of using is for other MFD services in IPP?



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org<mailto:ipp@pwg.org>

http=
s://www.pwg.org/mailman/listinfo/ipp





--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.



--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.









--






This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org











 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CBFECE.F7FAF9F0--

--===============1876239158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1876239158==--

From ipp-bounces@pwg.org  Tue Apr 19 13:22:48 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18909E0872 for ; Tue, 19 Apr 2011 13:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2wxY0KlioHz for ; Tue, 19 Apr 2011 13:22:46 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 82DC9E087D for ; Tue, 19 Apr 2011 13:22:41 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BFCFC79607; Tue, 19 Apr 2011 16:22:13 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by pwg.org (Postfix) with ESMTP id 53B35795F3 for ; Tue, 19 Apr 2011 16:21:36 -0400 (EDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id ZYAT1g0021uE5Es56YMcGA; Tue, 19 Apr 2011 20:21:36 +0000
Received: from VistaBusiness ([24.61.240.234]) by omta16.westchester.pa.mail.comcast.net with comcast id ZYMb1g00x548CT43cYMbeY; Tue, 19 Apr 2011 20:21:36 +0000
From: "William Wagner" 
To: "'Petrie, Glen'" , "'Mitchell, Andrew \(Solutions Architect\)'" ,  , "'Ira McDonald'" , "'Michael Sweet'" 
References:  
In-Reply-To: 
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
Date: Tue, 19 Apr 2011 16:21:34 -0400
Message-ID: <000001cbfecf$613eebb0$23bcc310$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acv+w/KhJsck0jnFSKCjc/QHIUEsSQAAEiQAAAD04NA=
Content-Language: en-us
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: BFCFC79607.A8C9D
X-pwg-MailScanner-From: ipp-bounces@pwg.org

All,

First, I agree that "imaging" is an poor term for us to use, although for me
it is because it invokes too board a spectrum (e.g., MRI's and conceptual
imaging) rather than being photographic specific. I liked "Hardcopy", since
that reasonably covers the MFD services, but I understand that some envision
PWG activity to extend to non-hardcopy devices, as it has to an extent with
the projector group. And we have been using "Imaging" for a while in other
PWG activities. However, I suggest that, if someone can come up with a
different, good inclusive term, we consider using it in this envisioned
extension of IPP to other services. One problem I see is that we have not
defined what services we intend IPP to extent to beyond the MFD "Hardcopy"
services, and I think this open-ended applicability is going to create
confusion.

Second, I would be inclined to prefer Andrew's option 2 (if indeed "imaging"
is the best term) except that I wonder if we always understand whether a
term is service specific, at least in its details if not in the board sense.
The idea of preceding everything with "print", or whatever service with
which it was first identified, regardless of the service it is being applied
to is a recipe for confusion, if indeed that is what is being  suggested. In
the MFD approach, command names are preceded by the service to which they
apply. I would have assumed that the same would apply to attributes, which
would allow distinctions to be made between  "print-color-mode",
"scan-color-mode", "copy-color-mode" etc., if such distinctions were
necessary (or later because necessary). Not including any prefix but
understanding the service from context would also work, but might make
defining the differences depending on service more cumbersome and would be
inconsistent with the current "print" prefixed terms.

Thanks,=20
Bill Wagner

=20=20=20=20=20=20=20=20=20=20=20=20=20
-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie,
Glen
Sent: Tuesday, April 19, 2011 3:07 PM
To: Mitchell, Andrew (Solutions Architect); tom.hastings@alum.mit.edu; Ira
McDonald; Michael Sweet
Cc: ipp@pwg.org
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

If the "color-mode" refers to the capability (setting) of the scanner or the
fax; then I vote for 1. below to clearly denote this.   An image does not
have a "color-mode"; it has a color space.  Mode implies functionality not a
state.

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Mitchell, Andrew (Solutions Architect)
Sent: Tuesday, April 19, 2011 12:00 PM
To: tom.hastings@alum.mit.edu; 'Ira McDonald'; 'Michael Sweet'
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

OK, my 2=A2.

We need to decide if naming a NEW attribute that applies to more then just
print with the print- prefix makes sense. A agree that renaming existing
attributes does not make sense, and using the print- attributes in scan (and
fax) rather then renaming them is logical. But if we are going to say
attributes that are originally defined in Scan (or Fax) start with imaging-
while if they first show up in IPP Everywhere (or some other doc like JPS3)
we name them print- that doesn't seam quite right. My preference would be
either:


 1.  Call everything that is not scan (or fax) specific print-, no matter
where it is first defined. For scan or fax specific, call them scan- and
fax-.
 2.  Start using the imaging- prefix everywhere that the term is NOT print
specific.

We are going to expand the model which is heavily rooted in print to other
services, I'd just like to have a consistent naming convention for how we
move forward. 1 seems more confusing to me since it means keeping the print-
name moving forward, and we'll have to maintain the table as to what is
print specific and what isn't, but 1 also seems more true to the roots of
IPP. I however personally vote for 2 since it clearly implies our broader
scope of the protocol moving forward.

As for just dropping the print- prefix, while it works for color-mode, I
think we need to take a harder look to make sure it makes sense everywhere.
Note that I view this as simply a different way of naming option 2. If we
pick option 2 we need to then pick the naming convention.

OK, so that was a bit more the 2=A2 worth.

Andrew

From: Tom Hastings
>
Reply-To: "tom.hastings@alum.mit.edu"
>
Date: Tue, 19 Apr 2011 18:45:45 +0000
To: 'Ira McDonald'
>, 'Michael Sweet'
>
Cc: "ipp@pwg.org" >
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?

I agree with Ira.  On the other hand, one other alternative for the name
would just to drop the "print-" prefix and call it "color-mode".

Tom

________________________________
From: ipp-bounces@pwg.org
[mailto:ipp-bounces@pwg.org] On Behalf Of Ira McDonald
Sent: Monday, April 18, 2011 15:35
To: Michael Sweet; Ira McDonald
Cc: ipp@pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?

Hi Mike,

My two cents.

No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.

In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.

Unless almost all Printer attributes *are* applicable, which I begin
to suspect is the case (and have a short table of the exceptions).

I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP
Everywhere Second Edition.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434


On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet
> wrote:
All,

If we consider scanning and printing of forms, the "bi-level" (threshold)
mode makes sense for both. Do we want to rename "print-color-mode" to
"imaging-color-mode" in anticipation of using is for other MFD services in
IPP?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Tue Apr 19 13:24:25 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DFE6E0678 for ; Tue, 19 Apr 2011 13:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.681
X-Spam-Level: 
X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGFVEsdooG8g for ; Tue, 19 Apr 2011 13:24:23 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id C6178E0670 for ; Tue, 19 Apr 2011 13:24:22 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 35D077961C; Tue, 19 Apr 2011 16:22:55 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com [209.85.161.46]) by pwg.org (Postfix) with ESMTP id D034779620 for ; Tue, 19 Apr 2011 16:20:02 -0400 (EDT)
Received: by fxm17 with SMTP id 17so82175fxm.5 for ; Tue, 19 Apr 2011 13:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QG02HAWHG4+0qCahq6YYgqh26saBif0rts3Ud9eUV38=; b=S5QuKo/2mAk+qPDI9zJ9tX6DIINxpbD11/f+qYs/gBiGkewQrFUlv8Pq93GTti+NR9 4f9igIZhh9L/200t442O52EC9p1SOHlrL6Q03lfxcVys/v2CNS7cUiuGvpvYF6ZFCVzO WWSs39PvEJTfFNq+eTUxDxQVeTyBnCG/HC+P8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NCMjXKYaGEGVHNPQOXjFq/aiGauRBc+wTyHTOHytSLNwPFXBuc2RyioEkXJM1WaHpQ diMpn6s7+nZHRu6ndC/T+MVsCVl1SBcM5/nyxlPyq28nDUtadwYM7d3MLJ5pENgwDXOV EZ4leTCEBe/yH38hnEQXpHBRGJ2DhSPR1lC5o=
MIME-Version: 1.0
Received: by 10.223.6.11 with SMTP id 11mr1262453fax.93.1303244400580; Tue, 19 Apr 2011 13:20:00 -0700 (PDT)
Received: by 10.223.120.135 with HTTP; Tue, 19 Apr 2011 13:20:00 -0700 (PDT)
In-Reply-To: 
References:    
Date: Tue, 19 Apr 2011 16:20:00 -0400
Message-ID: 
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
From: Ira McDonald 
To: "Petrie, Glen" , Ira McDonald 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0227096592=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 35D077961C.A9B75
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0227096592==
Content-Type: multipart/alternative; boundary=00151747849e8d5dc304a14b3bd8


--00151747849e8d5dc304a14b3bd8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Glen,

I think we're looking at the name of this attribute too literally.

The *function* of this attribute was strictly meant to decide
to do specific image processing before printing on media.

Conflating this 'xxx-color-mode' with 'xxx-color-space' (with
a disjoint set of keywords and usage) wouldn't be good.

Having just read Mike's reply about 'color-entry', it may apply
to scan and fax, but I don't think we should lump it with this
'print-color-mode'.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Tue, Apr 19, 2011 at 4:05 PM, Petrie, Glen w=
rote:

>  Ira, I believe the property refers to the functional mode the printer is
> to use or was used to produce the output.  That is; the printer is printi=
ng
> in or instructed to print in a =93=94color mode=94=94.   If this property=
 was meant
> to represent the =93state=94 of the output; then for print, and later for=
 scan
> and fax, it should be (have been) called =93color-space=94.   Then it wou=
ld make
> more sense to have used the prefix =93image=94 (versus even the word =93i=
maging=94);
> so we have image-color-space (the printed image, the scanned image, the f=
ax
> image =96 the key here it is the image and the device functionality or de=
vice
> capabilities or device mode.).
>
>
>
> So the device is instructed (or uses) to have a specific
>
> print-color-mode, scan-color-mode or fax-color-mode to produce an (hard or
> electronic) image that has an image-color-space
>
>
>
> what about =93device-color-mode=94
>
>
>
> Glen
>
>
>  ------------------------------
>
> *From:* Ira McDonald [mailto:blueroofmusic@gmail.com]
> *Sent:* Tuesday, April 19, 2011 12:49 PM
> *To:* Petrie, Glen; Ira McDonald
> *Cc:* Mitchell, Andrew (Solutions Architect); tom.hastings@alum.mit.edu;
> Michael Sweet; ipp@pwg.org
>
> *Subject:* Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>
>
>
> Hi,
>
> On reflection, I tend to agree with Andrew that we should
> (in general) use the 'imaging-' prefix for our new attributes.
>
> But I *think* we meant the new 'print-color-mode' property
> to refer specifically to hardcopy output (print).
>
> I don't think it fits well w/ scan (output image format) or fax.
>
> All - note that we generally *drop* the 'print-' or 'job-' or
> whatever prefix in the PWG Semantic Model XML Schema
> in order to reuse the "same" (well similar) attribute at more
> than one level of the system/service/job/document hierarchy.
>
> Pete - please chime in with your opinion here.
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> May to Christmas:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434
>
>
>
>  On Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen 
> wrote:
>
> If the "color-mode" refers to the capability (setting) of the scanner or
> the fax; then I vote for 1. below to clearly denote this.   An image does
> not have a "color-mode"; it has a color space.  Mode implies functionality
> not a state.
>
> Glen
>
>
>
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
> Mitchell, Andrew (Solutions Architect)
> Sent: Tuesday, April 19, 2011 12:00 PM
> To: tom.hastings@alum.mit.edu; 'Ira McDonald'; 'Michael Sweet'
> Cc: ipp@pwg.org
> Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>
> OK, my 2=A2.
>
> We need to decide if naming a NEW attribute that applies to more then just
> print with the print- prefix makes sense. A agree that renaming existing
> attributes does not make sense, and using the print- attributes in scan (=
and
> fax) rather then renaming them is logical. But if we are going to say
> attributes that are originally defined in Scan (or Fax) start with imagin=
g-
> while if they first show up in IPP Everywhere (or some other doc like JPS=
3)
> we name them print- that doesn't seam quite right. My preference would be
> either:
>
>
>  1.  Call everything that is not scan (or fax) specific print-, no matter
> where it is first defined. For scan or fax specific, call them scan- and
> fax-.
>  2.  Start using the imaging- prefix everywhere that the term is NOT print
> specific.
>
> We are going to expand the model which is heavily rooted in print to other
> services, I'd just like to have a consistent naming convention for how we
> move forward. 1 seems more confusing to me since it means keeping the pri=
nt-
> name moving forward, and we'll have to maintain the table as to what is
> print specific and what isn't, but 1 also seems more true to the roots of
> IPP. I however personally vote for 2 since it clearly implies our broader
> scope of the protocol moving forward.
>
> As for just dropping the print- prefix, while it works for color-mode, I
> think we need to take a harder look to make sure it makes sense everywher=
e.
> Note that I view this as simply a different way of naming option 2. If we
> pick option 2 we need to then pick the naming convention.
>
> OK, so that was a bit more the 2=A2 worth.
>
> Andrew
>
> From: Tom Hastings  tom.hastings@verizon.net>>
> Reply-To: "tom.hastings@alum.mit.edu" <
> tom.hastings@alum.mit.edu>
> Date: Tue, 19 Apr 2011 18:45:45 +0000
> To: 'Ira McDonald' >,
> 'Michael Sweet' >
> Cc: "ipp@pwg.org" >
> Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
>
> I agree with Ira.  On the other hand, one other alternative for the name
> would just to drop the "print-" prefix and call it "color-mode".
>
> Tom
>
> ________________________________
> From: ipp-bounces@pwg.org [mailto:
> ipp-bounces@pwg.org] On Behalf Of Ira McDonald
> Sent: Monday, April 18, 2011 15:35
> To: Michael Sweet; Ira McDonald
> Cc: ipp@pwg.org
> Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>
> Hi Mike,
>
> My two cents.
>
> No - let's keep the name "print-color-mode" to cohere with the
> zillion other print-xxx or printer-xxx attributes.
>
> In the new IPP Scanner and Fax objects lets just globally apply
> most/many existing IPP Printer attributes in big table(s) with
> a rationale for why some attributes are not applicable to the
> other multifunction objects.
>
> Unless almost all Printer attributes *are* applicable, which I begin
> to suspect is the case (and have a short table of the exceptions).
>
> I think we should reserve use of he "imaging-" prefix for only new
> attributes defined first for Scanner, Fax, etc. objects for IPP
> Everywhere Second Edition.
>
> Cheers,
> - Ira
>
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> May to Christmas:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>
>
> On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet  msweet@apple.com>> wrote:
> All,
>
> If we consider scanning and printing of forms, the "bi-level" (threshold)
> mode makes sense for both. Do we want to rename "print-color-mode" to
> "imaging-color-mode" in anticipation of using is for other MFD services in
> IPP?
>
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
>
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
>
> https://www.pwg.org/mailman/listinfo/ipp
>
>
>

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--00151747849e8d5dc304a14b3bd8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Glen,

I think we're looking at the name of this attribute too=
 literally.

The *function* of this attribute was strictly meant to d=
ecide
to do specific image processing before printing on media.


Conflating this 'xxx-color-mode' with 'xxx-color-space' (wi=
th
a disjoint set of keywords and usage) wouldn't be good.

Ha=
ving just read Mike's reply about 'color-entry', it may apply <=
br>
to scan and fax, but I don't think we should lump it with this
'=
print-color-mode'.

Cheers,
- Ira


Ira McDonald (Mus=
ician / Software Architect)
Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desig=
nated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
<=
a href=3D"http://sites.google.com/site/blueroofmusic" target=3D"_blank">htt=
p://sites.google.com/site/blueroofmusic

http://sites.google.com/site/highnorthinc=

mailto:blu=
eroofmusic@gmail.com

Christmas through April:
=A0 579 Park Place=A0 Saline, MI=A0 48176
=
=A0 734-944-0094
May to Christmas:
=A0 PO Box 221=A0 Grand Marais, MI=
 49839
=A0 906-494-2434






On Tue, Apr 19, 2011 at 4:05 PM, Petrie,=
 Glen <g=
len.petrie@eitc.epson.com> wrote:
























Ira, I believe=
 the property refers to
the functional mode the printer is to use or was used to produce the output=
. =A0That
is; the printer is printing in or instructed to print in a =93=94color
mode=94=94. =A0=A0If this property was meant to represent the =93state=94
of the output; then for print, and later for scan and fax, it should be (ha=
ve
been) called =93color-space=94. =A0=A0Then it would make more sense to have
used the prefix =93image=94 (versus even the word =93imaging=94);
so we have image-color-space (the printed image, the scanned image, the fax
image =96 the key here it is the image and the device functionality or
device capabilities or device mode.). 



=A0



So the device =
is instructed (or uses) to
have a specific



print-color-mo=
de, scan-color-mode or
fax-color-mode to produce an (hard or electronic) image that has an
image-color-space



=A0



what about =93=
device-color-mode=94



=A0



Glen






=A0












From: Ira McDonald
[mailto:bluero=
ofmusic@gmail.com] 

Sent: Tuesday, April 19, 2011
12:49 PM

To: Petrie, Glen; Ira McDona=
ld

Cc: Mitchell, Andrew (Soluti=
ons
Architect); =
tom.hastings@alum.mit.edu; Michael Sweet; ipp@pwg.org




Subject: Re: [IPP]
"print-color-mode" or "imaging-color-mode"?






=A0



Hi,



On reflection, I tend to agree with Andrew that we should

(in general) use the 'imaging-' prefix for our new attributes.



But I *think* we meant the new 'print-color-mode' property

to refer specifically to hardcopy output (print).



I don't think it fits well w/ scan (output image format) or fax.



All - note that we generally *drop* the 'print-' or 'job-' =
or

whatever prefix in the PWG Semantic Model XML Schema

in order to reuse the "same" (well similar) attribute at more

than one level of the system/service/job/document hierarchy.



Pete - please chime in with your opinion here.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/=
site/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

=A0 579 Park Place=A0
 Saline, MI=A0
 48176

=A0 7=
34-944-0094

May to Christmas:

=A0 PO Box 221=A0
Grand Marais, MI 49839

=A0 9=
06-494-2434














On Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen <glen.petrie@e=
itc.epson.com>
wrote:



If the "color-mode" refers to the capabili=
ty (setting) of the
scanner or the fax; then I vote for 1. below to clearly denote this. =A0 An
image does not have a "color-mode"; it has a color space. =A0Mode
implies functionality not a state.



Glen













-----Original Message-----

From: ipp-bounces@=
pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Mitchell, Andrew (Solutions Architect)

Sent: Tuesday, April 19, 2011 12:00 PM

To: tom.hast=
ings@alum.mit.edu;
'Ira McDonald'; 'Michael Sweet'

Cc: ipp@pwg.org

Subject: Re: [IPP] "print-color-mode" or
"imaging-color-mode"?



OK, my 2=A2.



We need to decide if naming a NEW attribute that applies to more then just
print with the print- prefix makes sense. A agree that renaming existing
attributes does not make sense, and using the print- attributes in scan (and
fax) rather then renaming them is logical. But if we are going to say attri=
butes
that are originally defined in Scan (or Fax) start with imaging- while if t=
hey
first show up in IPP Everywhere (or some other doc like JPS3) we name them
print- that doesn't seam quite right. My preference would be either:





=A01. =A0Call everything that is not scan (or fax) specific print-, no
matter where it is first defined. For scan or fax specific, call them scan-=
 and
fax-.

=A02. =A0Start using the imaging- prefix everywhere that the term is NOT
print specific.



We are going to expand the model which is heavily rooted in print to other
services, I'd just like to have a consistent naming convention for how =
we move
forward. 1 seems more confusing to me since it means keeping the print- name
moving forward, and we'll have to maintain the table as to what is print
specific and what isn't, but 1 also seems more true to the roots of IPP=
. I
however personally vote for 2 since it clearly implies our broader scope of=
 the
protocol moving forward.



As for just dropping the print- prefix, while it works for color-mode, I th=
ink
we need to take a harder look to make sure it makes sense everywhere. Note =
that
I view this as simply a different way of naming option 2. If we pick option=
 2
we need to then pick the naming convention.



OK, so that was a bit more the 2=A2 worth.



Andrew



From: Tom Hastings <tom.hastings@verizon.net<mailto:tom.hastings@verizon.net>><=
br>
Reply-To: "tom.hastings@alum.mit.edu<mailto:tom.hastings@alum.mit.edu>"
<tom.hast=
ings@alum.mit.edu<mailto:tom.hastings@alum.mit.edu>>

Date: Tue, 19 Apr 2011 18:45:45 +0000

To: 'Ira McDonald' <blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com>>=
;,
'Michael Sweet' <msweet@apple.com<mailto:msweet@apple.com>>

Cc: "ipp@pwg.org&=
lt;mailto:ipp@pwg.org&=
gt;" <ipp@pwg.org<=
/a><mailto:ipp@pwg.org<=
/a>>>


Subject: RE: [IPP] "print-color-mode" or
"imaging-color-mode"?



I agree with Ira. =A0On the other hand, one other alternative for the name
would just to drop the "print-" prefix and call it
"color-mode".



Tom



________________________________

From: ipp-bounces@=
pwg.org<mailto:ipp-bounces@pwg.org> [mailto:ipp-bounces@pwg.org] On Behalf Of Ira
McDonald

Sent: Monday, April 18, 2011 15:35

To: Michael Sweet; Ira McDonald

Cc: ipp@pwg.org<mai=
lto:ipp@pwg.org>

Subject: Re: [IPP] "print-color-mode" or
"imaging-color-mode"?



Hi Mike,



My two cents.



No - let's keep the name "print-color-mode" to cohere with th=
e

zillion other print-xxx or printer-xxx attributes.



In the new IPP Scanner and Fax objects lets just globally apply

most/many existing IPP Printer attributes in big table(s) with

a rationale for why some attributes are not applicable to the

other multifunction objects.



Unless almost all Printer attributes *are* applicable, which I begin

to suspect is the case (and have a short table of the exceptions).



I think we should reserve use of he "imaging-" prefix for only ne=
w

attributes defined first for Scanner, Fax, etc. objects for IPP

Everywhere Second Edition.



Cheers,

- Ira





Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

htt=
p://sites.google.com/site/highnorthinc

mailto:blueroo=
fmusic@gmail.com<mailto:blueroofmusic@gmail.com>

Christmas through April:

579 Park Place Saline, MI 48176

734-9=
44-0094

May to Christmas:

PO Box 221
Grand Marais, MI 49839

906-4=
94-2434





On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet <msweet@apple.com<mailto:msweet@apple.com>> wrote:=



All,



If we consider scanning and printing of forms, the "bi-level"
(threshold) mode makes sense for both. Do we want to rename "print-col=
or-mode"
to "imaging-color-mode" in anticipation of using is for other MFD
services in IPP?



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org<mailto:=
ipp@pwg.org>

http=
s://www.pwg.org/mailman/listinfo/ipp





--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.



--

This message has been scanned for viruses and

dangerous content by MailScanner<http://www.mailscanner.info/>, and is

believed to be clean.









--






This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org











=A0













--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--00151747849e8d5dc304a14b3bd8--

--===============0227096592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0227096592==--

From ipp-bounces@pwg.org  Tue Apr 19 14:16:46 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 30EA4E086D for ; Tue, 19 Apr 2011 14:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.488
X-Spam-Level: 
X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK+y+QaRLeDq for ; Tue, 19 Apr 2011 14:16:44 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id A76C5E0828 for ; Tue, 19 Apr 2011 14:16:42 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D3C6679605; Tue, 19 Apr 2011 17:16:25 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 2AB4179603 for ; Tue, 19 Apr 2011 17:16:13 -0400 (EDT)
MIME-version: 1.0
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJX007IY4CA90K1@mail-out.apple.com> for ipp@pwg.org; Tue, 19 Apr 2011 14:16:13 -0700 (PDT)
X-AuditID: 11807134-b7c8cae000005108-ba-4dadfb9b08cf
Received: from [17.151.73.2] (Unknown_Domain [17.151.73.2]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id 82.4A.20744.C9BFDAD4; Tue, 19 Apr 2011 14:16:13 -0700 (PDT)
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
From: Michael Sweet 
In-reply-to: <7A180A09B8F54B1FA932DE27E255EB3C@FamilyRoom>
Date: Tue, 19 Apr 2011 14:16:11 -0700
Message-id: 
References:   <7A180A09B8F54B1FA932DE27E255EB3C@FamilyRoom>
To: tom.hastings@alum.mit.edu
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1536583203=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: D3C6679605.A9FD6
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1536583203==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_KmI7CAQiugibeUyAJzdDvA)"


--Boundary_(ID_KmI7CAQiugibeUyAJzdDvA)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

Given that we have another attribute for scan (ColorEntry) that has slightly different semantics than print-color-mode, I'm thinking we should keep the print attribute named "print-color-mode".

On Apr 19, 2011, at 11:45 AM, Tom Hastings wrote:

> I agree with Ira.  On the other hand, one other alternative for the name would just to drop the "print-" prefix and call it "color-mode".
>  
> Tom
>  
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Ira McDonald
> Sent: Monday, April 18, 2011 15:35
> To: Michael Sweet; Ira McDonald
> Cc: ipp@pwg.org
> Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
>  
> Hi Mike,
> 
> My two cents.
> 
> No - let's keep the name "print-color-mode" to cohere with the
> zillion other print-xxx or printer-xxx attributes.
> 
> In the new IPP Scanner and Fax objects lets just globally apply
> most/many existing IPP Printer attributes in big table(s) with
> a rationale for why some attributes are not applicable to the
> other multifunction objects.
> 
> Unless almost all Printer attributes *are* applicable, which I begin 
> to suspect is the case (and have a short table of the exceptions).
> 
> I think we should reserve use of he "imaging-" prefix for only new
> attributes defined first for Scanner, Fax, etc. objects for IPP 
> Everywhere Second Edition.
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> May to Christmas:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
> 
> 
> 
> On Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet  wrote:
> All,
> 
> If we consider scanning and printing of forms, the "bi-level" (threshold) mode makes sense for both. Do we want to rename "print-color-mode" to "imaging-color-mode" in anticipation of using is for other MFD services in IPP?
> 
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>  
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_KmI7CAQiugibeUyAJzdDvA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

Given that we have another attribute for scan (ColorEntry) that has slightly different semantics than print-color-mode, I'm thinking we should keep the print attribute named "print-color-mode".

On Apr 19, 2011, at 11:45 AM, Tom Hastings wrote:

















I agree with Ira.  On the other hand,
one other alternative for the name would just to drop the "print-"
prefix and call it "color-mode".
 
Tom
 












From:
ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Ira McDonald

Sent: Monday, April 18, 2011 15:35

To: Michael
 Sweet; Ira McDonald

Cc: ipp@pwg.org

Subject: Re: [IPP]
"print-color-mode" or "imaging-color-mode"?



 
Hi Mike,



My two cents.



No - let's keep the name "print-color-mode" to cohere with the

zillion other print-xxx or printer-xxx attributes.



In the new IPP Scanner and Fax objects lets just globally apply

most/many existing IPP Printer attributes in big table(s) with

a rationale for why some attributes are not applicable to the

other multifunction objects.



Unless almost all Printer attributes *are* applicable, which I begin 

to suspect is the case (and have a short table of the exceptions).



I think we should reserve use of he "imaging-" prefix for only new

attributes defined first for Scanner, Fax, etc. objects for IPP 

Everywhere Second Edition.



Cheers,

- Ira





Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.com/site/blueroofmusic

http://sites.google.com/site/highnorthinc

mailto:blueroofmusic@gmail.com

Christmas through April:

579 Park Place Saline, MI 48176

734-944-0094

May to Christmas:

PO Box 221
Grand Marais, MI 49839

906-494-2434








On Mon, Apr 18, 2011 at 4:52 PM, Michael
 Sweet <msweet@apple.com>
wrote:
All,



If we consider scanning and printing of forms, the "bi-level"
(threshold) mode makes sense for both. Do we want to rename
"print-color-mode" to "imaging-color-mode" in anticipation
of using is for other MFD services in IPP?



________________________________________________________________________

Michael Sweet, Senior Printing
System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.org/mailman/listinfo/ipp



 


-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 













________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair





-- 

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_KmI7CAQiugibeUyAJzdDvA)--

--===============1536583203==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1536583203==--

From aasaka-kinji@aist.go.jp  Tue Apr 19 15:43:01 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC5D3E071B; Tue, 19 Apr 2011 15:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -87.696
X-Spam-Level: 
X-Spam-Status: No, score=-87.696 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkRfHiPL-LHw; Tue, 19 Apr 2011 15:43:01 -0700 (PDT)
Received: from telesp.net.br (unknown [189.110.221.70]) by ietfc.amsl.com (Postfix) with ESMTP id EB041E0673; Tue, 19 Apr 2011 15:43:00 -0700 (PDT)
Received: from 189.110.221.70(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MMKGO-2785pq-C2 for ; Tue, 19 Apr 2011 19:42:59 -0300
From: , 
To: , 
Subject: Newsletter Tue, 19 Apr 2011 19:42:59 -0300
Date: Tue, 19 Apr 2011 19:42:59 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: aaphcapyx.10
Message-ID: <2260148806.VQMOO7I6864695@ldsfitgka.tmfxqzhgasfpxpk.ru>

How are you bud!

Do you want an effective future, increase in  money, and the recognition of all?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and professional experience.

Get a Degree in 4 weeks with our program! 


~Our program will help EVERYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- You can realize YOUR Dreams!
- Live a better life by earning or upgrading your degree.


This is a good chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


Contact us 24 hours a day and 7 days a week! to start improving your life!


~CALL~


1-916-484-3795



You should leave us a message with your phone number with country code if outside USA and name and we will call you as soon as possible.


It is your way...
Make the right move.




Yours sincerely.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Tue Apr 19 16:45:27 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D742FE0755 for ; Tue, 19 Apr 2011 16:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.51
X-Spam-Level: 
X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS49SxjFWrJQ for ; Tue, 19 Apr 2011 16:45:26 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 98A41E0715 for ; Tue, 19 Apr 2011 16:45:26 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id DD5747960E; Tue, 19 Apr 2011 19:45:09 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 42AA77960C for ; Tue, 19 Apr 2011 19:44:57 -0400 (EDT)
MIME-version: 1.0
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJX009OHB93X0A1@mail-out.apple.com> for ipp@pwg.org; Tue, 19 Apr 2011 16:44:56 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-47-4dae1e77989e
Received: from [17.151.74.198] (Unknown_Domain [17.151.74.198]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay16.apple.com (Apple SCV relay) with SMTP id D2.D3.12552.87E1EAD4; Tue, 19 Apr 2011 16:44:56 -0700 (PDT)
Subject: Re: [IPP] PWG Raster intent
From: Michael Sweet 
In-reply-to: <15713B46EB868E4FB0CF6D8BFD33617E47E105FF@TK5EX14MBXC116.redmond.corp.microsoft.com>
Date: Tue, 19 Apr 2011 16:44:57 -0700
Message-id: <5A0D897D-FFC2-456A-89DB-3B43E9D968D1@apple.com>
References: <15713B46EB868E4FB0CF6D8BFD33617E47E0ED5E@TK5EX14MBXC116.redmond.corp.microsoft.com>  <15713B46EB868E4FB0CF6D8BFD33617E47E105FF@TK5EX14MBXC116.redmond.corp.microsoft.com>
To: Justin Hutchings 
X-Mailer: Apple Mail (2.1217)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1911383624=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: DD5747960E.AA56E
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1911383624==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_STWrXpw3leDBB6xXoowkNw)"


--Boundary_(ID_STWrXpw3leDBB6xXoowkNw)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

On Apr 19, 2011, at 10:40 AM, Justin Hutchings wrote:
> Michael,
> I absolutely agree with your point that vendors have their own PDLs today=
 for legacy devices and that it=92s unlikely that existing devices will be =
retrofit. But if vendors begin to transition into IPP and PWG raster, they =
may choose to reduce their investments in legacy PDLs in order to focus on =
new technologies. I believe there are some logical conclusions you can draw=
 from this:
>=20=20
> 1.       If a vendor adopts IPP Everywhere and PWG raster with it, then w=
hat are the odds they will continue to consume legacy PDLs? The odds of thi=
s are low for cost constrained devices such as inkjets. Consuming multiple =
PDLs requires maintaining separate driver and firmware code bases and becom=
es prohibitively expensive quickly.

Agreed.

> 2.       If a vendor chooses to only adopt PWG raster as a PDL, but still=
 wishes to target buses that lack an intent protocol, then they will have t=
o create a proprietary intent language.
> a.       Though smart buses certainly have advantages, not all clients wi=
ll implement these buses at the same time and some legacy clients may never=
 be updated. There could be many years where vendors are forced to maintain=
 parallel paths in order to reach all clients they wish to target.

PWG Raster *is* based on CUPS Raster, so there is ample room for job ticket=
 information in the page header. We don't use it for IPP Everywhere because=
 it is based on the PostScript page device dictionary, but it has been used=
 successfully for years in CUPS and in some printers to support embedded jo=
b ticket information.

> 3.       Therefore, we can expect that during this transitional period, t=
here could be additional cost/pain for vendors that wish to participate in =
this space. We can mitigate this by being prescriptive about how to represe=
nt intent in a PDL stream.

I am not opposed to expanding the language in the current PWG Raster spec c=
oncerning the page header and why we choose to not use it as a source of em=
bedded job ticket information, e.g. "the CUPS Raster page header contains m=
any embedded job ticket attributes derived from the PostScript page device =
dictionary, however ..." That should provide enough hints to vendors that w=
ant to go down that road to use it for legacy stuff.

However, I do not think it is appropriate to make implementation recommenda=
tions for interfaces/protocols/buses that are out-of-scope for IPP Everywhe=
re, particularly when those paths do not support the PWG semantic model.

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_STWrXpw3leDBB6xXoowkNw)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


Michael,
I absolut=
ely agree with your point that vendors have their own PDLs today for legacy=
 devices and that it=92s unlikely that existing devices will be retrofit. B=
ut if vendors begin to transition into IPP and PWG raster, they may choose =
to reduce their investments in legacy PDLs in order to focus on new technol=
ogies. I believe there are some logical conclusions you can draw from this:=

 
1.    &nb=
sp;  <=
/span>If a vendor adopts IPP Everywhere and PWG raster wi=
th it, then what are the odds they will continue to consume legacy PDLs? Th=
e odds of this are low for cost constrained devices such as inkjets. Consum=
ing multiple PDLs requires maintaining separate driver and firmware code ba=
ses and becomes prohibitively expensive quickly.

Agreed.

2.       If=
 a vendor chooses to only adopt PWG raster as a PDL, but still wishes to ta=
rget buses that lack an intent protocol, then they will have to create a pr=
oprietary intent language.
a.       T=
hough smart buses certainly have advantages, not all clients will implement=
 these buses at the same time and some legacy clients may never be updated.=
 There could be many years where vendors are forced to maintain parallel pa=
ths in order to reach all clients they wish to target.

PWG Raster *is* based on CUPS Raster=
, so there is ample room for job ticket information in the page header. We =
don't use it for IPP Everywhere because it is based on the PostScript page =
device dictionary, but it has been used successfully for years in CUPS and =
in some printers to support embedded job ticket information.

=

3.    =
   Therefore, we can expect that during this transi=
tional period, there could be additional cost/pain for vendors that wish to=
 participate in this space. We can mitigate this by being prescriptive abou=
t how to represent intent in a PDL stream.
<=
/blockquote>

I am not opposed to expanding the language=
 in the current PWG Raster spec concerning the page header and why we choos=
e to not use it as a source of embedded job ticket information, e.g. "the C=
UPS Raster page header contains many embedded job ticket attributes derived=
 from the PostScript page device dictionary, however ..." That should provi=
de enough hints to vendors that want to go down that road to use it for leg=
acy stuff.

However, I do not think it is appropriate to =
make implementation recommendations for interfaces/protocols/buses that are=
 out-of-scope for IPP Everywhere, particularly when those paths do not supp=
ort the PWG semantic model.



_______________________________________=
___________
Michael Sweet, Senior Printing System Engineer, =
PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_STWrXpw3leDBB6xXoowkNw)--

--===============1911383624==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1911383624==--

From ipp-bounces@pwg.org  Wed Apr 20 10:47:14 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45BA9E0695 for ; Wed, 20 Apr 2011 10:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEfTse6s04WW for ; Wed, 20 Apr 2011 10:47:10 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 7D6F3E0737 for ; Wed, 20 Apr 2011 10:47:07 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7B8BF79553; Wed, 20 Apr 2011 13:46:40 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by pwg.org (Postfix) with ESMTP id AD01A79195 for ; Wed, 20 Apr 2011 13:46:24 -0400 (EDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Apr 2011 10:46:23 -0700
Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.86]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0289.008; Wed, 20 Apr 2011 10:46:23 -0700
From: Justin Hutchings 
To: Michael Sweet 
Subject: RE: [IPP] PWG Raster intent
Thread-Topic: [IPP] PWG Raster intent
Thread-Index: Acv+G4TGtSEynqzyQIinfM07dmCH2gARDmgAABVy1dAAHDspgAAW49hg
Date: Wed, 20 Apr 2011 17:46:22 +0000
Message-ID: <15713B46EB868E4FB0CF6D8BFD33617E47E14271@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <15713B46EB868E4FB0CF6D8BFD33617E47E0ED5E@TK5EX14MBXC116.redmond.corp.microsoft.com>  <15713B46EB868E4FB0CF6D8BFD33617E47E105FF@TK5EX14MBXC116.redmond.corp.microsoft.com> <5A0D897D-FFC2-456A-89DB-3B43E9D968D1@apple.com>
In-Reply-To: <5A0D897D-FFC2-456A-89DB-3B43E9D968D1@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.78]
MIME-Version: 1.0
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1558866985=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 7B8BF79553.A8A02
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1558866985==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_15713B46EB868E4FB0CF6D8BFD33617E47E14271TK5EX14MBXC116r_"


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E14271TK5EX14MBXC116r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think expanding the language in the PWG Raster spec would be very appropr=
iate. Can you take that action item? I'm happy to review/work with you on t=
ext for the section.

I agree that the IPP everywhere spec should focus on IPP implementations an=
d talking about legacy buses muddies the water.

From: Michael Sweet [mailto:msweet@apple.com]
Sent: Tuesday, April 19, 2011 4:45 PM
To: Justin Hutchings
Cc: ipp@pwg.org
Subject: Re: [IPP] PWG Raster intent

On Apr 19, 2011, at 10:40 AM, Justin Hutchings wrote:
Michael,
I absolutely agree with your point that vendors have their own PDLs today f=
or legacy devices and that it's unlikely that existing devices will be retr=
ofit. But if vendors begin to transition into IPP and PWG raster, they may =
choose to reduce their investments in legacy PDLs in order to focus on new =
technologies. I believe there are some logical conclusions you can draw fro=
m this:

1.       If a vendor adopts IPP Everywhere and PWG raster with it, then wha=
t are the odds they will continue to consume legacy PDLs? The odds of this =
are low for cost constrained devices such as inkjets. Consuming multiple PD=
Ls requires maintaining separate driver and firmware code bases and becomes=
 prohibitively expensive quickly.

Agreed.


2.       If a vendor chooses to only adopt PWG raster as a PDL, but still w=
ishes to target buses that lack an intent protocol, then they will have to =
create a proprietary intent language.
a.       Though smart buses certainly have advantages, not all clients will=
 implement these buses at the same time and some legacy clients may never b=
e updated. There could be many years where vendors are forced to maintain p=
arallel paths in order to reach all clients they wish to target.

PWG Raster *is* based on CUPS Raster, so there is ample room for job ticket=
 information in the page header. We don't use it for IPP Everywhere because=
 it is based on the PostScript page device dictionary, but it has been used=
 successfully for years in CUPS and in some printers to support embedded jo=
b ticket information.

3.       Therefore, we can expect that during this transitional period, the=
re could be additional cost/pain for vendors that wish to participate in th=
is space. We can mitigate this by being prescriptive about how to represent=
 intent in a PDL stream.

I am not opposed to expanding the language in the current PWG Raster spec c=
oncerning the page header and why we choose to not use it as a source of em=
bedded job ticket information, e.g. "the CUPS Raster page header contains m=
any embedded job ticket attributes derived from the PostScript page device =
dictionary, however ..." That should provide enough hints to vendors that w=
ant to go down that road to use it for legacy stuff.

However, I do not think it is appropriate to make implementation recommenda=
tions for interfaces/protocols/buses that are out-of-scope for IPP Everywhe=
re, particularly when those paths do not support the PWG semantic model.

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E14271TK5EX14MBXC116r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I think expanding the lan=
guage in the PWG Raster spec would be very appropriate. Can you take that a=
ction item? I’m happy to review/work with you on text for
 the section. 


 <=
/p>

I agree that the IPP ever=
ywhere spec should focus on IPP implementations and talking about legacy bu=
ses muddies the water.



 <=
/p>





From: Michael =
Sweet [mailto:msweet@apple.com]


Sent: Tuesday, April 19, 2011 4:45 PM

To: Justin Hutchings

Cc: ipp@pwg.org

Subject: Re: [IPP] PWG Raster intent






 






On Apr 19, 2011, at 10:40 AM, Justin Hutchings wrote=
:










Michael,






I absolutely agree with y=
our point that vendors have their own PDLs today for legacy devices and tha=
t it’s unlikely that existing devices will be retrofit.
 But if vendors begin to transition into IPP and PWG raster, they may choos=
e to reduce their investments in legacy PDLs in order to focus on new techn=
ologies. I believe there are some logical conclusions you can draw from thi=
s:






 <=
/p>





1.  &nbs=
p;    If
 a vendor adopts IPP Everywhere and PWG raster with it, then what are the o=
dds they will continue to consume legacy PDLs? The odds of this are low for=
 cost constrained devices such as inkjets. Consuming multiple PDLs requires=
 maintaining separate driver and
 firmware code bases and becomes prohibitively expensive quickly.










 




Agreed.

















2.  &nbs=
p;    If
 a vendor chooses to only adopt PWG raster as a PDL, but still wishes to ta=
rget buses that lack an intent protocol, then they will have to create a pr=
oprietary intent language.






a.  &nbs=
p;    Though
 smart buses certainly have advantages, not all clients will implement thes=
e buses at the same time and some legacy clients may never be updated. Ther=
e could be many years where vendors are forced to maintain parallel paths i=
n order to reach all clients they
 wish to target.








 




PWG Raster *is* based on CUPS Raster, so there is am=
ple room for job ticket information in the page header. We don't use it for=
 IPP Everywhere because it is based on the PostScript page device dictionar=
y, but it has been used successfully
 for years in CUPS and in some printers to support embedded job ticket info=
rmation.






 












3.  &nbs=
p;    Therefore,
 we can expect that during this transitional period, there could be additio=
nal cost/pain for vendors that wish to participate in this space. We can mi=
tigate this by being prescriptive about how to represent intent in a PDL st=
ream.










 






I am not opposed to expanding the language in the cu=
rrent PWG Raster spec concerning the page header and why we choose to not u=
se it as a source of embedded job ticket information, e.g. "the CUPS R=
aster page header contains many embedded
 job ticket attributes derived from the PostScript page device dictionary, =
however ..." That should provide enough hints to vendors that want to =
go down that road to use it for legacy stuff.




 






However, I do not think it is appropriate to make im=
plementation recommendations for interfaces/protocols/buses that are out-of=
-scope for IPP Everywhere, particularly when those paths do not support the=
 PWG semantic model.




 






_________________________=
_________________________






Michael Sweet, Senior Pri=
nting System Engineer, PWG Chair






 








--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.



--_000_15713B46EB868E4FB0CF6D8BFD33617E47E14271TK5EX14MBXC116r_--

--===============1558866985==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1558866985==--

From ipp-bounces@pwg.org  Wed Apr 20 10:54:06 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BF292E0695 for ; Wed, 20 Apr 2011 10:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqaC6bTwaKp3 for ; Wed, 20 Apr 2011 10:54:05 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 6FEF7E0677 for ; Wed, 20 Apr 2011 10:54:05 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 67F83795FE; Wed, 20 Apr 2011 13:53:30 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 74AB9795FE for ; Wed, 20 Apr 2011 13:53:05 -0400 (EDT)
MIME-version: 1.0
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LJY001F8PK22PB0@mail-out.apple.com> for ipp@pwg.org; Wed, 20 Apr 2011 10:53:04 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-b7-4daf1d804511
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 41.10.23242.08D1FAD4; Wed, 20 Apr 2011 10:53:04 -0700 (PDT)
Subject: Re: [IPP] PWG Raster intent
From: Michael Sweet 
In-reply-to: <15713B46EB868E4FB0CF6D8BFD33617E47E14271@TK5EX14MBXC116.redmond.corp.microsoft.com>
Date: Wed, 20 Apr 2011 10:53:04 -0700
Message-id: <69D54BDE-893E-45DE-A4C7-9300A35B84DC@apple.com>
References: <15713B46EB868E4FB0CF6D8BFD33617E47E0ED5E@TK5EX14MBXC116.redmond.corp.microsoft.com>  <15713B46EB868E4FB0CF6D8BFD33617E47E105FF@TK5EX14MBXC116.redmond.corp.microsoft.com> <5A0D897D-FFC2-456A-89DB-3B43E9D968D1@apple.com> <15713B46EB868E4FB0CF6D8BFD33617E47E14271@TK5EX14MBXC116.redmond.corp.microsoft.com>
To: Justin Hutchings 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1244439459=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 67F83795FE.A88FD
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1244439459==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_G4NYZwKbma661knq41dcmw)"


--Boundary_(ID_G4NYZwKbma661knq41dcmw)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

Justin,

I'll include that in the comments for the next review of PWG Raster (next t=
elecon) and incorporate the changes in the followup draft.

Thanks!


On Apr 20, 2011, at 10:46 AM, Justin Hutchings wrote:

> I think expanding the language in the PWG Raster spec would be very appro=
priate. Can you take that action item? I=92m happy to review/work with you =
on text for the section.
>=20=20
> I agree that the IPP everywhere spec should focus on IPP implementations =
and talking about legacy buses muddies the water.
>=20=20
> From: Michael Sweet [mailto:msweet@apple.com]=20
> Sent: Tuesday, April 19, 2011 4:45 PM
> To: Justin Hutchings
> Cc: ipp@pwg.org
> Subject: Re: [IPP] PWG Raster intent
>=20=20
> On Apr 19, 2011, at 10:40 AM, Justin Hutchings wrote:
> Michael,
> I absolutely agree with your point that vendors have their own PDLs today=
 for legacy devices and that it=92s unlikely that existing devices will be =
retrofit. But if vendors begin to transition into IPP and PWG raster, they =
may choose to reduce their investments in legacy PDLs in order to focus on =
new technologies. I believe there are some logical conclusions you can draw=
 from this:
>=20=20
> 1.       If a vendor adopts IPP Everywhere and PWG raster with it, then w=
hat are the odds they will continue to consume legacy PDLs? The odds of thi=
s are low for cost constrained devices such as inkjets. Consuming multiple =
PDLs requires maintaining separate driver and firmware code bases and becom=
es prohibitively expensive quickly.
>=20=20
> Agreed.
>=20
>=20
> 2.       If a vendor chooses to only adopt PWG raster as a PDL, but still=
 wishes to target buses that lack an intent protocol, then they will have t=
o create a proprietary intent language.
> a.       Though smart buses certainly have advantages, not all clients wi=
ll implement these buses at the same time and some legacy clients may never=
 be updated. There could be many years where vendors are forced to maintain=
 parallel paths in order to reach all clients they wish to target.
>=20=20
> PWG Raster *is* based on CUPS Raster, so there is ample room for job tick=
et information in the page header. We don't use it for IPP Everywhere becau=
se it is based on the PostScript page device dictionary, but it has been us=
ed successfully for years in CUPS and in some printers to support embedded =
job ticket information.
>=20=20
> 3.       Therefore, we can expect that during this transitional period, t=
here could be additional cost/pain for vendors that wish to participate in =
this space. We can mitigate this by being prescriptive about how to represe=
nt intent in a PDL stream.
>=20=20
> I am not opposed to expanding the language in the current PWG Raster spec=
 concerning the page header and why we choose to not use it as a source of =
embedded job ticket information, e.g. "the CUPS Raster page header contains=
 many embedded job ticket attributes derived from the PostScript page devic=
e dictionary, however ..." That should provide enough hints to vendors that=
 want to go down that road to use it for legacy stuff.
>=20=20
> However, I do not think it is appropriate to make implementation recommen=
dations for interfaces/protocols/buses that are out-of-scope for IPP Everyw=
here, particularly when those paths do not support the PWG semantic model.
>=20=20
> __________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>=20=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_G4NYZwKbma661knq41dcmw)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


<=
span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb=
(31, 73, 125); ">I think expanding the language in the PWG Raster spec woul=
d be very appropriate. Can you take that action item? I=92m happy to review=
/work with you on text for the section.
 
I agree that the =
IPP everywhere spec should focus on IPP implementations and talking about l=
egacy buses muddies the water.
 
From: Michael Sweet [mailto:msweet@apple.com] 
Sent: Tuesday, April 19, 2011 4:45 PM
To: Justin Hutchings
Cc:=
 ipp@pwg.org<=
br>Subject: Re: [I=
PP] PWG Raster intent
 =

On Apr 19, 2011, at 10:40 AM, Justin Hutchings wrote:=

Michael,
=

I absolutely agree with your point that vendors have the=
ir own PDLs today for legacy devices and that it=92s unlikely that existing=
 devices will be retrofit. But if vendors begin to transition into IPP and =
PWG raster, they may choose to reduce their investments in legacy PDLs in o=
rder to focus on new technologies. I believe there are some logical conclus=
ions you can draw from this:
 
1.      =
 If a vendor adopts IPP Everywhere and PWG raster with it, then what are th=
e odds they will continue to consume legacy PDLs? The odds of this are low =
for cost constrained devices such as inkjets. Consuming multiple PDLs requi=
res maintaining separate driver and firmware code bases and becomes prohibi=
tively expensive quickly.
<=
div>
 
Agreed.

=

2.       If a vendor choose=
s to only adopt PWG raster as a PDL, but still wishes to target buses that =
lack an intent protocol, then they will have to create a proprietary intent=
 language.
<=
div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m=
argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; te=
xt-indent: -0.25in; ">a.       Though=
 smart buses certainly have advantages, not all clients will implement thes=
e buses at the same time and some legacy clients may never be updated. Ther=
e could be many years where vendors are forced to maintain parallel paths i=
n order to reach all clients they wish to target.
 
PWG Raster *is* based on CUPS=
 Raster, so there is ample room for job ticket information in the page head=
er. We don't use it for IPP Everywhere because it is based on the PostScrip=
t page device dictionary, but it has been used successfully for years in CU=
PS and in some printers to support embedded job ticket information.
 
3.      =
 Therefore, we can expect that during this transitional period, there could=
 be additional cost/pain for vendors that wish to participate in this space=
. We can mitigate this by being prescriptive about how to represent intent =
in a PDL stream.
 
I am not opposed to expanding the language =
in the current PWG Raster spec concerning the page header and why we choose=
 to not use it as a source of embedded job ticket information, e.g. "the CU=
PS Raster page header contains many embedded job ticket attributes derived =
from the PostScript page device dictionary, however ..." That should provid=
e enough hints to vendors that want to go down that road to use it for lega=
cy stuff.
 
However,=
 I do not think it is appropriate to make implementation recommendations fo=
r interfaces/protocols/buses that are out-of-scope for IPP Everywhere, part=
icularly when those paths do not support the PWG semantic model.=

__________________=
________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
 
=



_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_G4NYZwKbma661knq41dcmw)--

--===============1244439459==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1244439459==--

From aackhwjdd@ms2.hinet.net  Wed Apr 20 21:41:00 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9E72E069A for ; Wed, 20 Apr 2011 21:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -84.838
X-Spam-Level: 
X-Spam-Status: No, score=-84.838 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VqALrNABSxf for ; Wed, 20 Apr 2011 21:41:00 -0700 (PDT)
Received: from bzq-84-110-5-118.red.bezeqint.net (bzq-84-110-5-118.red.bezeqint.net [84.110.5.118]) by ietfc.amsl.com (Postfix) with ESMTP id 06997E067E for ; Wed, 20 Apr 2011 21:40:59 -0700 (PDT)
Received: from 84.110.5.118(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MMKG8-2620tv-K1 for ; Thu, 21 Apr 2011 06:40:58 +0200
From: "Sandra" 
To: 
Subject: Newsletter Thu, 21 Apr 2011 06:40:58 +0200
Date: Thu, 21 Apr 2011 06:40:58 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: hdvkanj-72
Message-ID: <9949677316.1WWAL0GN199583@tnvab.krxgaqhbshpamfh.biz>

Hey bud!!

Do you want a good future, step up in  money, and brownie points?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and professional experience.

Get a Degree in 6 weeks with our program! 


~Our program will help ALL with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- You can realize YOUR Dreams!
- Live a better life by earning or upgrading your degree.


This is a good way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


If you want to get better - you must Call us 24 hours a day and 7 days a week! to start improving your life!


~CALL~


1-301-396-3506



You must leave us a voice message with your name and phone number with country code if outside USA and we will call you as soon as possible.


It is your decision...
Make the right decision.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From affector@ms29.hinet.net  Wed Apr 20 23:19:06 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6CD66E06DB for ; Wed, 20 Apr 2011 23:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.467
X-Spam-Level: 
X-Spam-Status: No, score=-95.467 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v61iZWZP-pG6 for ; Wed, 20 Apr 2011 23:19:05 -0700 (PDT)
Received: from leased-line-60-103.telecom.by (leased-line-60-103.telecom.by [217.21.60.103]) by ietfc.amsl.com (Postfix) with ESMTP id 1C51AE0713 for ; Wed, 20 Apr 2011 23:19:05 -0700 (PDT)
Received: from 217.21.60.103(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MMO06-7441lp-RI for ; Thu, 21 Apr 2011 08:19:03 +0200
From: "Tempest" 
To: 
Subject: Newsletter Thu, 21 Apr 2011 08:19:03 +0200
Date: Thu, 21 Apr 2011 08:19:03 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: lwlbp-49
Message-ID: <8241102266.495Q31CK156346@zfldbsqa.lvkuxyjmn.tv>

Hey!!

Do you want an effective future, grow in money earning power, and the praise of all?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 4 weeks with our program! 


~Our program will help EVERYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- Realize YOUR Dreams!
- Live a wonderful life by earning or upgrading your degree.


This is a splendid chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


Contact us 24 hours a day and 7 days a week! to start improving your life!


~CALL US~


1-916-484-3795



You should leave us a message with your name and phone number with country code if outside USA and we will call you as soon as possible.


It is your decision...
Make the right decision.




Yours sincerely.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From 2c8bd71@bridgestone.co.jp  Fri Apr 22 03:48:42 2011
Return-Path: <2c8bd71@bridgestone.co.jp>
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0771E067C for ; Fri, 22 Apr 2011 03:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.124
X-Spam-Level: 
X-Spam-Status: No, score=-96.124 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_PBL=0.905, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amgc4X+yUmVt for ; Fri, 22 Apr 2011 03:48:42 -0700 (PDT)
Received: from dyn-173-224.fttb.kis.ru (dyn-173-224.fttb.kis.ru [212.92.173.224]) by ietfc.amsl.com (Postfix) with ESMTP id C9307E068B for ; Fri, 22 Apr 2011 03:48:41 -0700 (PDT)
Received: from  212.92.173.224 (account  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 202222384 for ; Fri, 22 Apr 2011 13:48:40 +0300
From: "Goneril" 
To: 
Subject: Newsletter Fri, 22 Apr 2011 13:48:40 +0300
Date: Fri, 22 Apr 2011 13:48:40 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: asyfee 03
Message-ID: <0173898720.1HB1TA35536446@cvjashmev.fxabxgzfa.biz>

Hello!

Do you want a suitable future, go up in money earning, and the admiration of all?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 5 weeks with our program! 


~Our program will help ALL with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- You can realize YOUR Dreams!
- Live a better life by earning or upgrading your degree.


This is a best way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


If you want to get better - you must Contact Today to start improving your life!


~CALL~


1-301-396-3506



You should leave us a message with your name and phone number with country code if outside USA and we will call you as soon as possible.


It is your decision...
Make the right move.




Yours sincerely.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Fri Apr 22 07:35:58 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 677C2E071E for ; Fri, 22 Apr 2011 07:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DDERgyxlnCq for ; Fri, 22 Apr 2011 07:35:54 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id EE05CE06AB for ; Fri, 22 Apr 2011 07:35:53 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id EAD5879603; Fri, 22 Apr 2011 10:35:29 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 46E64795E4 for ; Fri, 22 Apr 2011 10:35:13 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Apr 2011 07:35:12 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 22 Apr 2011 07:35:10 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Requested Additions to PWG Raster
Thread-Index: AcwA+i7pCZWuOUM6RV+DFMQ71iNnKg==
From: "Petrie, Glen" 
To: 
X-OriginalArrivalTime: 22 Apr 2011 14:35:12.0875 (UTC) FILETIME=[7D2BD3B0:01CC00FA]
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [IPP] Requested Additions to PWG Raster
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0411063006=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: EAD5879603.A9FA6
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0411063006==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC00FA.7BFD176C"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC00FA.7BFD176C
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I would like to request two additional optional fields be added to the
PWG Raster.  Since they are new to even CUPS raster they would need to
be reserved in the field known as "cupsInteger".  So, while the fields
would be optional to fill in, the fields need to be reserved in the
header definition .

=20

I have found that is useful to have the size of the raster data and to
have the raster data that is uncompressed (, at least temporarily); thus
a compressed state flag is useful.

=20

Once the PWG Raster is used by clients and printer, it will most likely
be used more universally by transforms and other processes (previews,
etc.) .  Currently is difficult to navigate the PWG Raster pages because
the size of the (compressed) raster is unknown; therefore, therefore,
the entire raster file must be serially decompressed to move from one
page to the next.  While I realize, for some resource limited device, it
is not possible to know the size of the (compressed) raster before
sending the data, it is very useful for both navigation and check if the
size of the (compressed) raster is known.   Being optional, if the size
information is not known then the field has value of zero.

=20

For most (all) processing, the raster data needs to be decompressed.
(For transport it should also be compressed.)   Therefore, it convenient
to have the raster page data to be uncompressed; versus decompressing
and compressing between processes.    To denote this, a state flag is
needed.   This is also an optional field and the value of zero (0) means
the data is compressed.   I would not waste a whole integer on a flag,
therefore, I would propose that one of the cupsInteger be reserved for
flags

=20

=20

=20

cupsInteger[0:0] =3D Compressed (0)/Decompressed(1) raster data

cupsInteger[1]    =3D PageCount (as proposed by Michael Sweet below)

cupsInteger[2]    =3D Size, in bytes, of a (this) raster data (compressed
or uncompressed size)

=20

glen

=20

=20

=3D=3D=3D=3D

Lasted additions posted by Michael Sweet

1.	PWG Raster Review=20

	a.
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf=20
	b.	Issue: Would be nice to have total page count (if known)


		*	Proposal: Add PageCount (integer, 0 to 2^31-1)
to page header ("cupsInteger[0]" from CUPS Raster), which is already
used by several CUPS Raster printer drivers=20
		*	0 means "I don't know how many pages"=20
		*	> 0 means "this is how many pages are in the
entire document"=20
		*	Every page gets the same value=20

	c.	Issue: Need coordinate space of image (flip/rotate on
back side)=20

		*	Proposal: Add HorizontalTransform(integer, -1 or
1) and VerticalTransform(integer, -1 or 1) to the page header
("cupsInteger[1]" and "cupsInteger[2]" from CUPS Raster)=20
		*	"Normal" pages have values of 1 and 1=20
		*	"Rotated" pages have values of -1 and -1 (180
degree rotation)=20
		*	"Flipped" pages have values of 1 and -1
(vertical flip) or -1 and 1 (horizontal flip)=20

	d.	Issue: Need bounding rectangle of any content to be
imaged on the page (ImageBox)=20

		*	Proposal 1: * Use existing ImagingBBox (4 x
integer) from page header - simple bounding box in (integer) points=20
		*	Proposal 2: Add ImageBottom (integer, 0-2^32-1),
ImageLeft (integer, 0-2^32-1), ImageRight (integer, 0-2^32-1), and
ImageTop (integer, 0-2^32-1) to the page header ("cupsInteger[3]"
through "cupsInteger[6]" from CUPS Raster) - simple bounding box in
pixels/lines=20

	e.	Issue: Some confusion about why we need
pwg-raster-resolutions-support=20

		*	Will be adding explanatory text to the
definition=20
		*	Basically supported raster resolutions can be
different than supported hardware resolutions=20

	f.	Issue: Some confusion about the compression algorithm=20

		*	Will be adding examples for 1-bit grayscale and
32-bit CMYK images to clarify=20
		*	Also have sample raster files available for
download=20

	g.	Samples files:=20

		*	Currently at
http://ftp.easysw.com/pub/cups/examples/PWGRasterSamples.zip=20
		*	40MB download, 80MB worth of data=20
		*	150dpi files for black-1, cmyk-8, sgray-8,
sgray-16, srgb-8, and srgb-16=20
		*	Representative documents for email, line art,
maps, photos, and web pages=20
		*	Issue: Where to place sample raster files?=20

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC00FA.7BFD176C
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
















I would like to request two additional optional fields=
 be
added to the PWG Raster.  Since they are new to even CUPS raster they
would need to be reserved in the field known as “cupsInteger”. =
 So,
while the fields would be optional to fill in, the fields need to be reserv=
ed in
the header definition .



 



I have found that is useful to have the size of the ra=
ster
data and to have the raster data that is uncompressed (, at least temporari=
ly);
thus a compressed state flag is useful.



 



Once the PWG Raster is used by clients and printer, it
will most likely be used more universally by transforms and other processes=
 (previews,
etc.) .  Currently is difficult to navigate the PWG Raster pages becau=
se
the size of the (compressed) raster is unknown; therefore, therefore, the
entire raster file must be serially decompressed to move from one page to t=
he
next.  While I realize, for some resource limited device, it is not po=
ssible
to know the size of the (compressed) raster before sending the data, it is =
very
useful for both navigation and check if the size of the (compressed) raster=
 is known.
  Being optional, if the size information is not known then the f=
ield
has value of zero.



 



For most (all) processing, the raster data needs to be
decompressed.  (For transport it should also be compressed.)  &nb=
sp;Therefore,
it convenient to have the raster page data to be uncompressed; versus
decompressing and compressing between processes.    To denote
this, a state flag is needed.   This is also an optional field and
the value of zero (0) means the data is compressed.   I would not
waste a whole integer on a flag, therefore, I would propose that one of the
cupsInteger be reserved for flags



 



 



 



cupsInteger[0:0] =3D Compressed (0)/Decompressed(1) ra=
ster
data



cupsInteger[1]    =3D PageCount (as pro=
posed
by Michael Sweet below)



cupsInteger[2]    =3D Size, in bytes, o=
f a
(this) raster data (compressed or uncompressed size)



 



glen



 



 



=3D=3D=3D=3D



Lasted additions posted by Michael Sweet



    
 
  1. PWG Raster Review =

    2. 
 
      
  
    1. ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
      
      2. 
  
    2. I=
ssue:
      Would be nice to have total page count (if known) <=
/font>
      3. 
  
        
   
      • =
Proposal:
       Add PageCount (integer, 0 to 2^31-1) to page header
       ("cupsInteger[0]" from CUPS Raster), which is already used=
 by
       several CUPS Raster printer drivers 
        • 
   
      • =
0 means
       "I don't know how many pages" 
   
      • =
> 0
       means "this is how many pages are in the entire document" =

        • 
   
      • =
Every
       page gets the same value 
        • 
  
      
  
    3. I=
ssue:
      Need coordinate space of image (flip/rotate on back side) =

      4. 
  
        
   
      • =
Proposal:
       Add HorizontalTransform(integer, -1 or 1) and VerticalTransform(inte=
ger,
       -1 or 1) to the page header (“cupsInteger[1]” and
       “cupsInteger[2]” from CUPS Raster) 
        • 
   
      • =
“Normal”
       pages have values of 1 and 1 
        • 
   
      • =
“Rotated”
       pages have values of -1 and -1 (180 degree rotation) 
        • 
   
      • =
“Flipped”
       pages have values of 1 and -1 (vertical flip) or -1 and 1 (horizontal
       flip) 
        • 
  
      
  
    4. I=
ssue:
      Need bounding rectangle of any content to be imaged on the page
      (ImageBox) 
      5. 
  
        
   
      • =
Proposal
       1: • Use existing ImagingBBox (4 x integer) from page header -
       simple bounding box in (integer) points 
   
      • =
Proposal
       2: Add ImageBottom (integer, 0-2^32-1), ImageLeft (integer, 0-2^32-1=
),
       ImageRight (integer, 0-2^32-1), and ImageTop (integer, 0-2^32-1) to =
the
       page header (“cupsInteger[3]” through
       “cupsInteger[6]” from CUPS Raster) - simple bounding box=
 in
       pixels/lines 
        • 
  
      
  
    5. I=
ssue:
      Some confusion about why we need pwg-raster-resolutions-support =

      6. 
  
        
   
      • =
Will be
       adding explanatory text to the definition <=
/li>
   
      • =
Basically
       supported raster resolutions can be different than supported hardware
       resolutions 
        • 
  
      
  
    6. I=
ssue:
      Some confusion about the compression algorithm 
      7. 
  
        
   
      • =
Will be
       adding examples for 1-bit grayscale and 32-bit CMYK images to clarif=
y 
        • 
   
      • =
Also
       have sample raster files available for download 
        • 
  
      
  
    7. S=
amples
      files: 
      8. 
  
        
   
      • =
Currently
       at http://ftp.easysw.com/pub/cups/examples/PWGRasterSamples.zip
       
        • 
   
      • =
40MB
       download, 80MB worth of data 
        • 
   
      • =
150dpi
       files for black-1, cmyk-8, sgray-8, sgray-16, srgb-8, and srgb-16 
        • 
   
      • =
Representative
       documents for email, line art, maps, photos, and web pages 
        • 
   
      • =
Issue:
       Where to place sample raster files? 
        • 
  
      
 
    




 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC00FA.7BFD176C--

--===============0411063006==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0411063006==--

From ipp-bounces@pwg.org  Fri Apr 22 09:04:09 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 134F8E07A1 for ; Fri, 22 Apr 2011 09:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WchbRdWs2vO2 for ; Fri, 22 Apr 2011 09:04:06 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id B7416E0768 for ; Fri, 22 Apr 2011 09:04:06 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D2EA67961B; Fri, 22 Apr 2011 12:03:51 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 47D0B795FF for ; Fri, 22 Apr 2011 12:03:39 -0400 (EDT)
MIME-version: 1.0
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LK2006I79W9HK40@mail-out.apple.com> for ipp@pwg.org; Fri, 22 Apr 2011 09:03:39 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-4b-4db1a6da4eac
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay16.apple.com (Apple SCV relay) with SMTP id 02.5B.12552.BD6A1BD4; Fri, 22 Apr 2011 09:03:39 -0700 (PDT)
Subject: Re: [IPP] Requested Additions to PWG Raster
From: Michael Sweet 
In-reply-to: 
Date: Fri, 22 Apr 2011 09:03:41 -0700
Message-id: <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>
References: 
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1461084364=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: D2EA67961B.A9F8C
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1461084364==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_CRCjyU4+n9n+NhIpLKoRiA)"


--Boundary_(ID_CRCjyU4+n9n+NhIpLKoRiA)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Apr 22, 2011, at 7:35 AM, Petrie, Glen wrote:
> ... 
> Once the PWG Raster is used by clients and printer, it will most likely be used more universally by transforms and other processes (previews, etc.) .  Currently is difficult to navigate the PWG Raster pages because the size of the (compressed) raster is unknown; therefore, therefore, the entire raster file must be serially decompressed to move from one page to the next.  While I realize, for some resource limited device, it is not possible to know the size of the (compressed) raster before sending the data, it is very useful for both navigation and check if the size of the (compressed) raster is known.   Being optional, if the size information is not known then the field has value of zero.

However, cupsInteger is a 32-bit unsigned integer and thus can only represent sizes up to 2^32-1. It is very easy to go over 4GB with large format printers, e.g., for a 44" wide Stylus Pro printer, 24-bit sRGB at 720dpi would hit the 4GB limit at 63 inches in length for uncompressed data, maybe you'd get 100 inches with compression for a photographic print.

Now, we could use two cupsInteger slots for this (to provide a 64-bit length), however based on your following comments it sounds like you expect raster processing to happen with uncompressed data, for which you can calculate the length from the page header anyways. Also, you can expect that most, if not all implementations will *not* generate this information since the point of a streamable raster format is to not need to buffer up a whole lot of data...

> For most (all) processing, the raster data needs to be decompressed.  (For transport it should also be compressed.)   Therefore, it convenient to have the raster page data to be uncompressed; versus decompressing and compressing between processes.    To denote this, a state flag is needed.   This is also an optional field and the value of zero (0) means the data is compressed.   I would not waste a whole integer on a flag, therefore, I would propose that one of the cupsInteger be reserved for flags

I would actually prefer to flag the file as version 3 which is an uncompressed CUPS Raster with the version 2 page header. And in the case of local processing, you'll likely want to use native word order (another feature of CUPS Raster that we are not bringing along for PWG Raster...)

(In order words, we already have a way to specify an uncompressed raster)

Would it be sufficient to document an uncompressed version of PWG Raster (with the "RAS3" file header) and then mark the native word order support as out-of-scope for the spec but something that might be used internally?


________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_CRCjyU4+n9n+NhIpLKoRiA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


... 
Once the PWG Raster is used by=
 clients and printer, it will most likely be used more universally by trans=
forms and other processes (previews, etc.) .  Currently is difficult t=
o navigate the PWG Raster pages because the size of the (compressed) raster=
 is unknown; therefore, therefore, the entire raster file must be serially =
decompressed to move from one page to the next.  While I realize, for =
some resource limited device, it is not possible to know the size of the (c=
ompressed) raster before sending the data, it is very useful for both navig=
ation and check if the size of the (compressed) raster is known.  &nbs=
p;Being optional, if the size information is not known then the field has v=
alue of zero.

<=
/div>However, cupsInteger is a 32-bit unsigned integer and thus can only re=
present sizes up to 2^32-1. It is very easy to go over 4GB with large forma=
t printers, e.g., for a 44" wide Stylus Pro printer, 24-bit sRGB at 72=
0dpi would hit the 4GB limit at 63 inches in length for uncompressed data, =
maybe you'd get 100 inches with compression for a photographic print.
=


Now, we could use two cupsInteger slots for this (to pr=
ovide a 64-bit length), however based on your following comments it sounds =
like you expect raster processing to happen with uncompressed data, for whi=
ch you can calculate the length from the page header anyways. Also, you can=
 expect that most, if not all implementations will *not* generate this info=
rmation since the point of a streamable raster format is to not need to buf=
fer up a whole lot of data...

=

<=
span style=3D"font-size: 12pt; font-family: Cambria; ">For most (all) proce=
ssing, the raster data needs to be decompressed.  (For transport it sh=
ould also be compressed.)   Therefore, it convenient to have the =
raster page data to be uncompressed; versus decompressing and compressing b=
etween processes.    To denote this, a state flag is needed.=
   This is also an optional field and the value of zero (0) means=
 the data is compressed.   I would not waste a whole integer on a=
 flag, therefore, I would propose that one of the cupsInteger be reserved f=
or flags

=
I would actually prefer to flag the file as version 3 which is an uncompres=
sed CUPS Raster with the version 2 page header. And in the case of local pr=
ocessing, you'll likely want to use native word order (another feature of C=
UPS Raster that we are not bringing along for PWG Raster...)

=

(In order words, we already have a way to specify an uncompresse=
d raster)

Would it be sufficient to document an un=
compressed version of PWG Raster (with the "RAS3" file header) and then mar=
k the native word order support as out-of-scope for the spec but something =
that might be used internally?



_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_CRCjyU4+n9n+NhIpLKoRiA)--

--===============1461084364==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1461084364==--

From ipp-bounces@pwg.org  Fri Apr 22 09:35:13 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E2D8E071B for ; Fri, 22 Apr 2011 09:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UrEo2jVOcIe for ; Fri, 22 Apr 2011 09:35:10 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 11BDAE06C0 for ; Fri, 22 Apr 2011 09:35:10 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 372507962F; Fri, 22 Apr 2011 12:34:45 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 76F847962D for ; Fri, 22 Apr 2011 12:34:31 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Apr 2011 09:34:30 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Fri, 22 Apr 2011 09:34:30 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] Requested Additions to PWG Raster
Thread-Index: AcwBBtnDXdX6mKHgQgWxp/cZZAMSXQAAdCfQ
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 22 Apr 2011 16:34:30.0939 (UTC) FILETIME=[27B5B6B0:01CC010B]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0548979461=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 372507962F.AA167
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0548979461==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC010B.272D2889"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC010B.272D2889
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

However, cupsInteger is a 32-bit unsigned integer and thus can only
represent sizes up to 2^32-1. It is very easy to go over 4GB with large
format printers, e.g., for a 44" wide Stylus Pro printer, 24-bit sRGB at
720dpi would hit the 4GB limit at 63 inches in length for uncompressed
data, maybe you'd get 100 inches with compression for a photographic
print.

=20

[gwp] I guess I was not considering LFP's.=20=20

=20

Now, we could use two cupsInteger slots for this (to provide a 64-bit
length), however based on your following comments it sounds like you
expect raster processing to happen with uncompressed data, for which you
can calculate the length from the page header anyways. Also, you can
expect that most, if not all implementations will *not* generate this
information since the point of a streamable raster format is to not need
to buffer up a whole lot of data...

=20

[gwp] The important case is the size of the compressed raster data. The
decompressed size is recorded only if the raster is uncompressed.=20

[gwp] I agree that some (a few or a lot) of implementation may not
provide the information but as I said, I am requesting that the
assignment be made and those who can (want to) may record the size
information.=20





For most (all) processing, the raster data needs to be decompressed.
(For transport it should also be compressed.)   Therefore, it convenient
to have the raster page data to be uncompressed; versus decompressing
and compressing between processes.    To denote this, a state flag is
needed.   This is also an optional field and the value of zero (0) means
the data is compressed.   I would not waste a whole integer on a flag,
therefore, I would propose that one of the cupsInteger be reserved for
flags

=20

I would actually prefer to flag the file as version 3 which is an
uncompressed CUPS Raster with the version 2 page header. And in the case
of local processing, you'll likely want to use native word order
(another feature of CUPS Raster that we are not bringing along for PWG
Raster...)

=20

[gwp] Do you mean big/little-endian?  I am nothing requesting the word
ordering flag (value) be used.  The current specification is ok.

=20

(In order words, we already have a way to specify an uncompressed
raster)

=20

Would it be sufficient to document an uncompressed version of PWG Raster
(with the "RAS3" file header) and then mark the native word order
support as out-of-scope for the spec but something that might be used
internally?

=20

[gwp] I believe the RAS3 is for the entire PWG Raster file.  I am
requesting a flags (value) for individual pages.=20=20

=20

Glen

=20

=20

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC010B.272D2889
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable























 






However, cupsInteger is a 32-bit unsigned integer and thus can only
represent sizes up to 2^32-1. It is very easy to go over 4GB with large for=
mat
printers, e.g., for a 44" wide Stylus Pro printer, 24-bit sRGB at
720dpi would hit the 4GB limit at 63 inches in length for uncompressed data,
maybe you'd get 100 inches with compression for a photographic print.<=
/o:p>









<=
span
style=3D'font-size:12.0pt;color:blue'> 



[gwp] I guess I was not considering =
LFP’s.
 



 









Now, we could use two cupsInteger slots for this (to provide a 64-b=
it
length), however based on your following comments it sounds like you expect
raster processing to happen with uncompressed data, for which you can calcu=
late
the length from the page header anyways. Also, you can expect that most, if=
 not
all implementations will *not* generate this information since the point of=
 a
streamable raster format is to not need to buffer up a whole lot of data...=










<=
span
style=3D'font-size:12.0pt;color:blue'> 



[gwp] The important case is the size=
 of
the compressed raster data. The decompressed size is recorded only if the
raster is uncompressed. 



[gwp] I agree that some (a few or a =
lot)
of implementation may not provide the information but as I said, I am
requesting that the assignment be made and those who can (want to) may reco=
rd
the size information. 



















For most (all) processing, the raster data needs to be
decompressed.  (For transport it should also be compressed.)
  Therefore, it convenient to have the raster page data to be
uncompressed; versus decompressing and compressing between processes. 
  To denote this, a state flag is needed.   This is als=
o an
optional field and the value of zero (0) means the data is compressed.
  I would not waste a whole integer on a flag, therefore, I would
propose that one of the cupsInteger be reserved for flags














 






I would actually prefer to flag the file as version 3 which is an
uncompressed CUPS Raster with the version 2 page header. And in the case of
local processing, you'll likely want to use native word order (another feat=
ure
of CUPS Raster that we are not bringing along for PWG Raster...)=










<=
span
style=3D'font-size:12.0pt;color:blue'> 



[gwp] Do you mean big/little-endian?=
  I
am nothing requesting the word ordering flag (value) be used.  The cur=
rent
specification is ok.



 









(In order words, we already have a way to specify an uncompressed
raster)









 









Would it be sufficient to document an uncompressed version of PWG
Raster (with the "RAS3" file header) and then mark the native word
order support as out-of-scope for the spec but something that might be used
internally?



 



[gwp] I believe the RAS3 is for the
entire PWG Raster file.  I am requesting a flags (value) for individual
pages.  



 



Glen



 



 









 












__________________________=
______________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC010B.272D2889--

--===============0548979461==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0548979461==--

From ipp-bounces@pwg.org  Fri Apr 22 10:20:21 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DB01E0680 for ; Fri, 22 Apr 2011 10:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsD+WWGO1MTL for ; Fri, 22 Apr 2011 10:20:20 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 200D2E065A for ; Fri, 22 Apr 2011 10:20:20 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 5F2C879637; Fri, 22 Apr 2011 13:20:00 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id D02EB79636 for ; Fri, 22 Apr 2011 13:19:46 -0400 (EDT)
MIME-version: 1.0
Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK2004SVDD84Q40@mail-out.apple.com> for ipp@pwg.org; Fri, 22 Apr 2011 10:19:46 -0700 (PDT)
X-AuditID: 1180711d-b7c70ae00000719a-ae-4db1b8b182d5
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay13.apple.com (Apple SCV relay) with SMTP id CA.A1.29082.1B8B1BD4; Fri, 22 Apr 2011 10:19:45 -0700 (PDT)
Subject: Re: [IPP] Requested Additions to PWG Raster
From: Michael Sweet 
In-reply-to: 
Date: Fri, 22 Apr 2011 10:19:45 -0700
Message-id: 
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com> 
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0842191959=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 5F2C879637.A95DF
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0842191959==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_yhd79MOaP02/7jxBQoAdJA)"


--Boundary_(ID_yhd79MOaP02/7jxBQoAdJA)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:
> ... 
> [gwp] The important case is the size of the compressed raster data. The decompressed size is recorded only if the raster is uncompressed.
> [gwp] I agree that some (a few or a lot) of implementation may not provide the information but as I said, I am requesting that the assignment be made and those who can (want to) may record the size information.

It really isn't a matter of "may not provide", in most cases clients (and printers) simply can't buffer hundreds of megabytes of raster data. I can add the field, but since most producers of PWG Raster will not be able to supply the compressed size of the raster no printer will be able to depend on it anyways, so IMHO it is best to have the printer, if it is going to do any local processing of full page images, use its own optimal internal storage format than try to gerry-rig something into the format that just won't work.

> ... 
> I would actually prefer to flag the file as version 3 which is an uncompressed CUPS Raster with the version 2 page header. And in the case of local processing, you'll likely want to use native word order (another feature of CUPS Raster that we are not bringing along for PWG Raster...)
>  
> [gwp] Do you mean big/little-endian?  I am nothing requesting the word ordering flag (value) be used.  The current specification is ok.

My main point was that if you are concerned about having a standard representation for intermediate data, CUPS Raster already provides that. If you are trying to tweak PWG Raster for use as an internal representation format then I'd rather not put that in the standard since internal formats are OOS for any PWG standard.

> Would it be sufficient to document an uncompressed version of PWG Raster (with the "RAS3" file header) and then mark the native word order support as out-of-scope for the spec but something that might be used internally?
>  
> [gwp] I believe the RAS3 is for the entire PWG Raster file.  I am requesting a flags (value) for individual pages.  

Since the format does not support this, I would be opposed to adding something that would be used only for an internal representation of a PWG Raster file.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_yhd79MOaP02/7jxBQoAdJA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


... 
[gwp] The important case i=
s the size of the compressed raster data. The decompressed size is recorded=
 only if the raster is uncompressed.
[gwp] I agree that some (a few or a lot) of im=
plementation may not provide the information but as I said, I am requesting=
 that the assignment be made and those who can (want to) may record the siz=
e information.

It really isn't a matter of "may not provide", in most cases cl=
ients (and printers) simply can't buffer hundreds of megabytes of raster da=
ta. I can add the field, but since most producers of PWG Raster will not be=
 able to supply the compressed size of the raster no printer will be able t=
o depend on it anyways, so IMHO it is best to have the printer, if it is go=
ing to do any local processing of full page images, use its own optimal int=
ernal storage format than try to gerry-rig something into the format that j=
ust won't work.

... 
<=
div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m=
argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; ">I woul=
d actually prefer to flag the file as version 3 which is an uncompressed CU=
PS Raster with the version 2 page header. And in the case of local processi=
ng, you'll likely want to use native word order (another feature of CUPS Ra=
ster that we are not bringing along for PWG Raster...)
 =

=
[gwp] Do you mean big/little-end=
ian?  I am nothing requesting the word ordering flag (value) be used. =
 The current specification is ok.

My main point was that if you are conce=
rned about having a standard representation for intermediate data, CUPS Ras=
ter already provides that. If you are trying to tweak PWG Raster for use as=
 an internal representation format then I'd rather not put that in the stan=
dard since internal formats are OOS for any PWG standard.

Would it be suf=
ficient to document an uncompressed version of PWG Raster (with the "RAS3" =
file header) and then mark the native word order support as out-of-scope fo=
r the spec but something that might be used internally?
[gwp] I believe the RAS3 is =
for the entire PWG Raster file.  I am requesting a flags (value) for i=
ndividual pages.  

Since the format does not support this, I would be opp=
osed to adding something that would be used only for an internal representa=
tion of a PWG Raster file.



_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_yhd79MOaP02/7jxBQoAdJA)--

--===============0842191959==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0842191959==--

From ipp-bounces@pwg.org  Fri Apr 22 10:33:47 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B57FBE06B0 for ; Fri, 22 Apr 2011 10:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-QrU1coRlBT for ; Fri, 22 Apr 2011 10:33:44 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 31727E0655 for ; Fri, 22 Apr 2011 10:33:44 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D8B7E79637; Fri, 22 Apr 2011 13:33:21 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id A853979636 for ; Fri, 22 Apr 2011 13:33:07 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Apr 2011 10:33:06 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Fri, 22 Apr 2011 10:33:05 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] Requested Additions to PWG Raster
Thread-Index: AcwBEXudyPnODO4USgqcmUyVuJkoSgAABkOg
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>  
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 22 Apr 2011 17:33:07.0004 (UTC) FILETIME=[5772A7C0:01CC0113]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0412433542=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: D8B7E79637.A9D6D
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0412433542==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0113.568D7F5E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0113.568D7F5E
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

As stated below, I do understand objection to adding the field.  I would
to hear from other PWG members on the addition of these fields.

=20

Glen

=20

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Friday, April 22, 2011 10:20 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:

=09

	...=20

	[gwp] The important case is the size of the compressed raster
data. The decompressed size is recorded only if the raster is
uncompressed.

	[gwp] I agree that some (a few or a lot) of implementation may
not provide the information but as I said, I am requesting that the
assignment be made and those who can (want to) may record the size
information.

=20

It really isn't a matter of "may not provide", in most cases clients
(and printers) simply can't buffer hundreds of megabytes of raster data.
I can add the field, but since most producers of PWG Raster will not be
able to supply the compressed size of the raster no printer will be able
to depend on it anyways, so IMHO it is best to have the printer, if it
is going to do any local processing of full page images, use its own
optimal internal storage format than try to gerry-rig something into the
format that just won't work.

=20

[gwp] As I stated in my original request, I am not worried about the
printer, it will accept the streaming input just fine.  I want the size
information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging anything.
I do not understand your comment "that just won't work".  It works fine.
In fact, I wrote a routine that will find the size-only of compressed
page by running the compression routine without storing the compressed
data.  I don't understand your objection to assigning the field.

=09=20

	...=20

	I would actually prefer to flag the file as version 3 which is
an uncompressed CUPS Raster with the version 2 page header. And in the
case of local processing, you'll likely want to use native word order
(another feature of CUPS Raster that we are not bringing along for PWG
Raster...)

=09=20

	[gwp] Do you mean big/little-endian?  I am nothing requesting
the word ordering flag (value) be used.  The current specification is
ok.

=20

My main point was that if you are concerned about having a standard
representation for intermediate data, CUPS Raster already provides that.
If you are trying to tweak PWG Raster for use as an internal
representation format then I'd rather not put that in the standard since
internal formats are OOS for any PWG standard.





Would it be sufficient to document an uncompressed version of PWG Raster
(with the "RAS3" file header) and then mark the native word order
support as out-of-scope for the spec but something that might be used
internally?

=20

[gwp] I believe the RAS3 is for the entire PWG Raster file.  I am
requesting a flags (value) for individual pages.=20=20

=20

Since the format does not support this, I would be opposed to adding
something that would be used only for an internal representation of a
PWG Raster file.

=20

[gwp] Again, I do not understand your objection.=20

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0113.568D7F5E
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


















As stated below, I do understand
objection to adding the field.  I would to hear from other PWG members=
 on
the addition of these fields.



 



Glen



 



 















From: Michael =
Sweet
[mailto:msweet@apple.com] 

Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster






 









On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:<=
/font>





















... 

















[gwp] The important case is the size=
 of
the compressed raster data. The decompressed size is recorded only if the
raster is uncompressed.









[gwp] I agree that some (a few or a =
lot)
of implementation may not provide the information but as I said, I am
requesting that the assignment be made and those who can (want to) may reco=
rd
the size information.




















 






It really isn't a matter of "may not provide", in most ca=
ses
clients (and printers) simply can't buffer hundreds of megabytes of raster
data. I can add the field, but since most producers of PWG Raster will not =
be
able to supply the compressed size of the raster no printer will be able to=
 depend
on it anyways, so IMHO it is best to have the printer, if it is going to do=
 any
local processing of full page images, use its own optimal internal storage
format than try to gerry-rig something into the format that just won't work=
.









<=
span
style=3D'font-size:12.0pt;color:blue'> 



[gwp] As I stated in my original req=
uest,
I am not worried about the printer, it will accept the streaming input just
fine.  I want the size information for navigation of a many page raster
without having to decompress pages in a serial manor.   I am not =
jerry-rigging
anything.  I do not understand your comment “that just won’=
;t
work”.  It works fine.  In fact, I wrote a routine that will
find the size-only of compressed page by running the compression routine
without storing the compressed data.  I don’t understand your
objection to assigning the field.
























 



... 














I would actually prefer to flag the file as version 3 which is an
uncompressed CUPS Raster with the version 2 page header. And in the case of
local processing, you'll likely want to use native word order (another feat=
ure
of CUPS Raster that we are not bringing along for PWG Raster...)















<=
span
style=3D'font-size:12.0pt;color:blue'> 









[gwp] Do you mean big/little-endian?
 I am nothing requesting the word ordering flag (value) be used.  =
;The
current specification is ok.


















 








My main point was that if you are concerned about having a standard
representation for intermediate data, CUPS Raster already provides that. If=
 you
are trying to tweak PWG Raster for use as an internal representation format
then I'd rather not put that in the standard since internal formats are OOS=
 for
any PWG standard.




























Would it be sufficient to document an uncompressed version of PWG
Raster (with the "RAS3" file header) and then mark the native word
order support as out-of-scope for the spec but something that might be used
internally?









 









[gwp] I believe the RAS3 is for the
entire PWG Raster file.  I am requesting a flags (value) for individual
pages.  














 









Since the format does not support this, I would be opposed to adding
something that would be used only for an internal representation of a PWG
Raster file.



 



[gwp] Again, I do not understand your
objection. 









 












______________=
__________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0113.568D7F5E--

--===============0412433542==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0412433542==--

From ipp-bounces@pwg.org  Fri Apr 22 11:52:22 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2A71E072A for ; Fri, 22 Apr 2011 11:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level: 
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gm4jefz+Xj6 for ; Fri, 22 Apr 2011 11:52:20 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 5CCAEE0655 for ; Fri, 22 Apr 2011 11:52:20 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 0AA6579641; Fri, 22 Apr 2011 14:52:07 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com [209.85.161.46]) by pwg.org (Postfix) with ESMTP id 18E1C7963C for ; Fri, 22 Apr 2011 14:51:52 -0400 (EDT)
Received: by fxm17 with SMTP id 17so671643fxm.5 for ; Fri, 22 Apr 2011 11:51:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gpa55Odvp5y5FBndZXwuv96wnspHMoKE01EqCROTn3E=; b=vX+VK7/aNZDBPidUsKX0iizes0pvn9JoLSSnZ3oFkM2cIuVbZXtnUoAIiABQePrKzg yOdaRebYeRaSt3TyD6kngZkjO3/wpR7IYrKTFCk4AWHClJI4A0zMBYtTSKzAezc8tcfH NFdEoZs8BWYzsY2/hToGkFfXYy0aAyEJyvk/k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=snYtH4GgzlKbUf0Sb1UpJvh3oAEaYan7d3xt8hHPB6JgDTlbik6eWfhJZXwvmB185t /kKzKkEJSmR2acTLNVdEX9xxlyJHN7oHErQSuopFYGier8tUV88nKBl0w66b0eD5ZdBF Su9yEcgdfPgGclSuRZMYOXDSutVT843+qXlTk=
MIME-Version: 1.0
Received: by 10.223.2.205 with SMTP id 13mr1481311fak.138.1303498311997; Fri, 22 Apr 2011 11:51:51 -0700 (PDT)
Received: by 10.223.37.19 with HTTP; Fri, 22 Apr 2011 11:51:51 -0700 (PDT)
In-Reply-To: 
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>   
Date: Fri, 22 Apr 2011 14:51:51 -0400
Message-ID: 
Subject: Re: [IPP] Requested Additions to PWG Raster
From: Ira McDonald 
To: "Petrie, Glen" , Ira McDonald 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0184146059=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 0AA6579641.A9D0E
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0184146059==
Content-Type: multipart/alternative; boundary=20cf3054a8efda1a3304a1865961


--20cf3054a8efda1a3304a1865961
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Glen,

I agree with Mike here in objecting to registering these fields.

PWG standards are supposed to only contain fields/attributes
that *could* be tested in an interoperability event.  It's not
plausible that a typical streaming client would know the size
when it's very large (when the feature's useful), so such a
feature's not interoperable or verifiable.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen w=
rote:

>  As stated below, I do understand objection to adding the field.  I would
> to hear from other PWG members on the addition of these fields.
>
>
>
> Glen
>
>
>
>
>  ------------------------------
>
> *From:* Michael Sweet [mailto:msweet@apple.com]
> *Sent:* Friday, April 22, 2011 10:20 AM
> *To:* Petrie, Glen
> *Cc:* ipp@pwg.org
> *Subject:* Re: [IPP] Requested Additions to PWG Raster
>
>
>
> On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:
>
>   ...
>
> [gwp] The important case is the size of the compressed raster data. The
> decompressed size is recorded only if the raster is uncompressed.
>
> [gwp] I agree that some (a few or a lot) of implementation may not provide
> the information but as I said, I am requesting that the assignment be made
> and those who can (want to) may record the size information.
>
>
>
> It really isn't a matter of "may not provide", in most cases clients (and
> printers) simply can't buffer hundreds of megabytes of raster data. I can
> add the field, but since most producers of PWG Raster will not be able to
> supply the compressed size of the raster no printer will be able to depend
> on it anyways, so IMHO it is best to have the printer, if it is going to =
do
> any local processing of full page images, use its own optimal internal
> storage format than try to gerry-rig something into the format that just
> won't work.
>
>
>
> [gwp] As I stated in my original request, I am not worried about the
> printer, it will accept the streaming input just fine.  I want the size
> information for navigation of a many page raster without having to
> decompress pages in a serial manor.   I am not jerry-rigging anything.  I=
 do
> not understand your comment =93that just won=92t work=94.  It works fine.=
  In
> fact, I wrote a routine that will find the size-only of compressed page by
> running the compression routine without storing the compressed data.  I
> don=92t understand your objection to assigning the field.
>
>
>
> ...
>
> I would actually prefer to flag the file as version 3 which is an
> uncompressed CUPS Raster with the version 2 page header. And in the case =
of
> local processing, you'll likely want to use native word order (another
> feature of CUPS Raster that we are not bringing along for PWG Raster...)
>
>
>
> [gwp] Do you mean big/little-endian?  I am nothing requesting the word
> ordering flag (value) be used.  The current specification is ok.
>
>
>
> My main point was that if you are concerned about having a standard
> representation for intermediate data, CUPS Raster already provides that. =
If
> you are trying to tweak PWG Raster for use as an internal representation
> format then I'd rather not put that in the standard since internal formats
> are OOS for any PWG standard.
>
>
>
>    Would it be sufficient to document an uncompressed version of PWG
> Raster (with the "RAS3" file header) and then mark the native word order
> support as out-of-scope for the spec but something that might be used
> internally?
>
>
>
> [gwp] I believe the RAS3 is for the entire PWG Raster file.  I am
> requesting a flags (value) for individual pages.
>
>
>
> Since the format does not support this, I would be opposed to adding
> something that would be used only for an internal representation of a PWG
> Raster file.
>
>
>
> [gwp] Again, I do not understand your objection.
>
>
>
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--20cf3054a8efda1a3304a1865961
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Glen,

I agree with Mike here in objecting to registering these fi=
elds.

PWG standards are supposed to only contain fields/attributesthat *could* be tested in an interoperability event.=A0 It's not

plausible that a typical streaming client would know the size 
when it&#=
39;s very large (when the feature's useful), so such a
feature's=
 not interoperable or verifiable.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Op=
en Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcop=
y WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/H=
igh North Inc

ht=
tp://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc

mailto:blueroo=
fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S=
aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2=
21=A0 Grand Marais, MI 49839

=A0 906-494-2434




On Fri, Apr 22, 2011 at 1:33 PM, Petrie,=
 Glen <g=
len.petrie@eitc.epson.com> wrote:



















As stated belo=
w, I do understand
objection to adding the field. =A0I would to hear from other PWG members on
the addition of these fields.



=A0



Glen



=A0



=A0















From: Michael Sweet
[mailto:msweet@apple.=
com] 

Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster






=A0









On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:





















...=A0


















[gwp] The impo=
rtant case is the size of
the compressed raster data. The decompressed size is recorded only if the
raster is uncompressed.









[gwp] I agree =
that some (a few or a lot)
of implementation may not provide the information but as I said, I am
requesting that the assignment be made and those who can (want to) may reco=
rd
the size information.




















=A0






It really isn't a matter of "may not provid=
e", in most cases
clients (and printers) simply can't buffer hundreds of megabytes of ras=
ter
data. I can add the field, but since most producers of PWG Raster will not =
be
able to supply the compressed size of the raster no printer will be able to=
 depend
on it anyways, so IMHO it is best to have the printer, if it is going to do=
 any
local processing of full page images, use its own optimal internal storage
format than try to gerry-rig something into the format that just won't =
work.









=A0



[gwp] As I sta=
ted in my original request,
I am not worried about the printer, it will accept the streaming input just
fine. =A0I want the size information for navigation of a many page raster
without having to decompress pages in a serial manor. =A0=A0I am not jerry-=
rigging
anything.=A0 I do not understand your comment =93that just won=92t
work=94. =A0It works fine.=A0 In fact, I wrote a routine that will
find the size-only of compressed page by running the compression routine
without storing the compressed data. =A0I don=92t understand your
objection to assigning the field.
























=
=A0



.=
..=A0














I would actually prefer to flag the file as version =
3 which is an
uncompressed CUPS Raster with the version 2 page header. And in the case of
local processing, you'll likely want to use native word order (another =
feature
of CUPS Raster that we are not bringing along for PWG Raster...)















=A0









[gwp] Do you m=
ean big/little-endian?
=A0I am nothing requesting the word ordering flag (value) be used. =A0The
current specification is ok.


















=A0








My main point was that if you are concerned about ha=
ving a standard
representation for intermediate data, CUPS Raster already provides that. If=
 you
are trying to tweak PWG Raster for use as an internal representation format
then I'd rather not put that in the standard since internal formats are=
 OOS for
any PWG standard.




























Would it be sufficient to document an uncompressed v=
ersion of PWG
Raster (with the "RAS3" file header) and then mark the native word
order support as out-of-scope for the spec but something that might be used
internally?









=A0









[gwp] I believ=
e the RAS3 is for the
entire PWG Raster file.=A0 I am requesting a flags (value) for individual
pages. =A0














=A0









Since the format does not support this, I would be o=
pposed to adding
something that would be used only for an internal representation of a PWG
Raster file.



=A0



[gwp] Ag=
ain, I do not understand your
objection. 









=A0












=
________=
________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair









=A0






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.





_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--20cf3054a8efda1a3304a1865961--

--===============0184146059==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0184146059==--

From ipp-bounces@pwg.org  Fri Apr 22 12:09:21 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86B98E076D for ; Fri, 22 Apr 2011 12:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level: 
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tepKlV4DFFjE for ; Fri, 22 Apr 2011 12:09:16 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 2AB7CE06E8 for ; Fri, 22 Apr 2011 12:09:16 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E00FC79641; Fri, 22 Apr 2011 15:08:48 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 8EC3B7963E for ; Fri, 22 Apr 2011 15:08:30 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 22 Apr 2011 12:08:30 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Fri, 22 Apr 2011 12:08:27 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] Requested Additions to PWG Raster
Thread-Index: AcwBHl+YuqzIY7p+RM+fNrQAYKkn0gAAdwJQ
References: <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com> 
From: "Petrie, Glen" 
To: "Ira McDonald" 
X-OriginalArrivalTime: 22 Apr 2011 19:08:30.0383 (UTC) FILETIME=[AAD8FBF0:01CC0120]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1530743459=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: E00FC79641.AAADE
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1530743459==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0120.A8F690C9"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0120.A8F690C9
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Uncle !!!!!!!!!

=20

It is an optional field and completely testable in an interoperability
test.

=20

Glen

=20

=20

________________________________

From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
Sent: Friday, April 22, 2011 11:52 AM
To: Petrie, Glen; Ira McDonald
Cc: Michael Sweet; ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

Hi Glen,

I agree with Mike here in objecting to registering these fields.

PWG standards are supposed to only contain fields/attributes
that *could* be tested in an interoperability event.  It's not
plausible that a typical streaming client would know the size=20
when it's very large (when the feature's useful), so such a
feature's not interoperable or verifiable.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
=20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434





On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen
 wrote:

As stated below, I do understand objection to adding the field.  I would
to hear from other PWG members on the addition of these fields.

=20

Glen

=20

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Friday, April 22, 2011 10:20 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:

=09

	...=20

	[gwp] The important case is the size of the compressed raster
data. The decompressed size is recorded only if the raster is
uncompressed.

	[gwp] I agree that some (a few or a lot) of implementation may
not provide the information but as I said, I am requesting that the
assignment be made and those who can (want to) may record the size
information.

=20

It really isn't a matter of "may not provide", in most cases clients
(and printers) simply can't buffer hundreds of megabytes of raster data.
I can add the field, but since most producers of PWG Raster will not be
able to supply the compressed size of the raster no printer will be able
to depend on it anyways, so IMHO it is best to have the printer, if it
is going to do any local processing of full page images, use its own
optimal internal storage format than try to gerry-rig something into the
format that just won't work.

=20

[gwp] As I stated in my original request, I am not worried about the
printer, it will accept the streaming input just fine.  I want the size
information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging anything.
I do not understand your comment "that just won't work".  It works fine.
In fact, I wrote a routine that will find the size-only of compressed
page by running the compression routine without storing the compressed
data.  I don't understand your objection to assigning the field.

=09=20

	...=20

	I would actually prefer to flag the file as version 3 which is
an uncompressed CUPS Raster with the version 2 page header. And in the
case of local processing, you'll likely want to use native word order
(another feature of CUPS Raster that we are not bringing along for PWG
Raster...)

=09=20

	[gwp] Do you mean big/little-endian?  I am nothing requesting
the word ordering flag (value) be used.  The current specification is
ok.

=20

My main point was that if you are concerned about having a standard
representation for intermediate data, CUPS Raster already provides that.
If you are trying to tweak PWG Raster for use as an internal
representation format then I'd rather not put that in the standard since
internal formats are OOS for any PWG standard.

=20

Would it be sufficient to document an uncompressed version of PWG Raster
(with the "RAS3" file header) and then mark the native word order
support as out-of-scope for the spec but something that might be used
internally?

=20

[gwp] I believe the RAS3 is for the entire PWG Raster file.  I am
requesting a flags (value) for individual pages.=20=20

=20

Since the format does not support this, I would be opposed to adding
something that would be used only for an internal representation of a
PWG Raster file.

=20

[gwp] Again, I do not understand your objection.=20

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0120.A8F690C9
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable























Uncle !!!!!!!!!



 



It is an optional field and complete=
ly
testable in an interoperability test.



 



Glen



 



 















From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Friday, April 22, 2011=
 11:52
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.o=
rg

Subject: Re: [IPP] Requested
Additions to PWG Raster






 



Hi Glen,



I agree with Mike here in objecting to registering these fields.



PWG standards are supposed to only contain fields/attributes

that *could* be tested in an interoperability event.  It's not

plausible that a typical streaming client would know the size 

when it's very large (when the feature's useful), so such a

feature's not interoperable or verifiable.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box=
 221 
Grand Marais, MI 49839

  906-494-2434














On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:









As stated below, I do understand objection to adding the field.
 I would to hear from other PWG members on the addition of these field=
s.



 



Glen



 



 















From: Michael Sweet [mailto:msweet@apple.com] 
Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster









 









On Apr 2=
2, 2011,
at 9:34 AM, Petrie, Glen wrote:





















... 


















[gwp] The important case is the size of the compressed raster d=
ata.
The decompressed size is recorded only if the raster is uncompressed.









[gwp] I agree that some (a few or a lot) of implementation may =
not
provide the information but as I said, I am requesting that the assignment =
be
made and those who can (want to) may record the size information.




















 






It reall=
y isn't a
matter of "may not provide", in most cases clients (and printers)
simply can't buffer hundreds of megabytes of raster data. I can add the fie=
ld,
but since most producers of PWG Raster will not be able to supply the
compressed size of the raster no printer will be able to depend on it anywa=
ys,
so IMHO it is best to have the printer, if it is going to do any local
processing of full page images, use its own optimal internal storage format
than try to gerry-rig something into the format that just won't work.<=
/o:p>












 



[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to dec=
ompress
pages in a serial manor.   I am not jerry-rigging anything. =
 I
do not understand your comment “that just won’t work”. &n=
bsp;It works
fine.  In fact, I wrote a routine that will find the size-only of
compressed page by running the compression routine without storing the
compressed data.  I don’t understand your objection to assigning=
 the
field.



























 



... 












I would =
actually
prefer to flag the file as version 3 which is an uncompressed CUPS Raster w=
ith
the version 2 page header. And in the case of local processing, you'll like=
ly
want to use native word order (another feature of CUPS Raster that we are n=
ot
bringing along for PWG Raster...)















 









[gwp] Do you mean big/little-endian?  I am nothing request=
ing
the word ordering flag (value) be used.  The current specification is =
ok.


















 






My main =
point was
that if you are concerned about having a standard representation for
intermediate data, CUPS Raster already provides that. If you are trying to
tweak PWG Raster for use as an internal representation format then I'd rath=
er
not put that in the standard since internal formats are OOS for any PWG
standard.









&nb=
sp;














Would it=
 be
sufficient to document an uncompressed version of PWG Raster (with the
"RAS3" file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?=










 









[gwp] I believe the RAS3 is for the entire PWG Raster file.&nbs=
p; I
am requesting a flags (value) for individual pages.  














 















Since th=
e format
does not support this, I would be opposed to adding something that would be
used only for an internal representation of a PWG Raster file.



 






[gwp] Again, I do not understand your objection. =













 












____________________________________________________=
____________________

Michael Sweet, Senior Printing System Engineer, PWG Chair











 














-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 











_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp






 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0120.A8F690C9--

--===============1530743459==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1530743459==--

From alanbrownelln@versaquest.com  Fri Apr 22 12:59:58 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8DE6E07CB for ; Fri, 22 Apr 2011 12:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -88.598
X-Spam-Level: 
X-Spam-Status: No, score=-88.598 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fka7amYFpAAi for ; Fri, 22 Apr 2011 12:59:58 -0700 (PDT)
Received: from brasiltelecom.net.br (189-11-163-39.bnut3700.dsl.brasiltelecom.net.br [189.11.163.39]) by ietfc.amsl.com (Postfix) with ESMTP id CB680E07A5 for ; Fri, 22 Apr 2011 12:59:57 -0700 (PDT)
Received: from  189.11.163.39 (account  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 309681672 for ; Fri, 22 Apr 2011 16:59:56 -0300
From: 
To: 
Subject: Newsletter Fri, 22 Apr 2011 16:59:56 -0300
Date: Fri, 22 Apr 2011 16:59:56 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: pltpaai.23
Message-ID: <6100758146.E3PB8190417828@smeiqhkg.gjlsyqtbppslm.va>

Hi!!

Do you want a good future, go up in earning power, and the recognition of all?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and professional experience.

Get a Degree in 6 weeks with our program! 


~Our program will help EVERYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- Follow YOUR Dreams!
- Live a better life by earning or upgrading your degree.


This is a exellent way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


Contact 7 days a week! to start improving your life!


~CALL US~


1-301-396-3506



Please leave us a voice message with your name and phone number with country code if outside USA and we'll call you asap.


It is your decision...
Make the right decision.




Yours sincerely.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Fri Apr 22 16:28:24 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3F631E0669 for ; Fri, 22 Apr 2011 16:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S28tKheaJY7M for ; Fri, 22 Apr 2011 16:28:18 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id ED457E065F for ; Fri, 22 Apr 2011 16:28:17 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 64D3679642; Fri, 22 Apr 2011 19:27:58 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by pwg.org (Postfix) with ESMTP id AC57779640 for ; Fri, 22 Apr 2011 19:27:41 -0400 (EDT)
Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p3MNReGR030021 for ; Fri, 22 Apr 2011 19:27:40 -0400
Authentication-Results: cm-omr11 smtp.user=ptykodi@tykodi.com; auth=pass (LOGIN)
X-Authenticated-UID: ptykodi@tykodi.com
Received: from [65.96.244.16] ([65.96.244.16:33726] helo=TCS2010LAPTOP) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 4E/38-05067-BEE02BD4; Fri, 22 Apr 2011 19:27:40 -0400
From: "Paul Tykodi" 
To: "'Petrie, Glen'" 
References: <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>	 
In-Reply-To: 
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Fri, 22 Apr 2011 19:27:42 -0400
Organization: Tykodi Consulting Services LLC
Message-ID: <000001cc0144$e1149c50$a33dd4f0$@tykodi.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLFuyzq+wsk6228T9B9XCf5xj24gQHaN4n9AtLobE8CkFSXfQFMCqlaAekFzLgCHglk65ISjKbg
Content-Language: en-us
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ptykodi@tykodi.com
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1562922819=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 64D3679642.AA677
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multipart message in MIME format.

--===============1562922819==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01CC0123.5A056D50"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0001_01CC0123.5A056D50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Glen,

 

Where we are currently reaching out to some printer manufacturers who have
previously not participated in PWG activities (portable printer
manufacturers, thermal transfer-direct thermal printer manufacturers) to let
them know about the IPP Anywhere project and the PWG Raster Format, I am in
favor of waiting for a little while to see if we get some interest from the
reach out activities before making a final decision on your request.

 

If we do get some participation from the printer manufacturers outlined
above, they might also find some value in the feature you are requesting so
I believe it is a little premature to reject the idea of adding the field at
this time.

 

Best Regards,

 

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  ptykodi@tykodi.com
WWW:    http://www.tykodi.com

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie,
Glen
Sent: Friday, April 22, 2011 3:08 PM
To: Ira McDonald
Cc: ipp@pwg.org
Subject: RE: [IPP] Requested Additions to PWG Raster

 

Uncle !!!!!!!!!

 

It is an optional field and completely testable in an interoperability test.

 

Glen

 

 

  _____  

From: Ira McDonald [mailto:blueroofmusic@gmail.com] 
Sent: Friday, April 22, 2011 11:52 AM
To: Petrie, Glen; Ira McDonald
Cc: Michael Sweet; ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

 

Hi Glen,

I agree with Mike here in objecting to registering these fields.

PWG standards are supposed to only contain fields/attributes
that *could* be tested in an interoperability event.  It's not
plausible that a typical streaming client would know the size 
when it's very large (when the feature's useful), so such a
feature's not interoperable or verifiable.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
 
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

 

On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen 
wrote:

As stated below, I do understand objection to adding the field.  I would to
hear from other PWG members on the addition of these fields.

 

Glen

 

 

  _____  

From: Michael Sweet [mailto:msweet@apple.com] 
Sent: Friday, April 22, 2011 10:20 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

 

On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:

... 

[gwp] The important case is the size of the compressed raster data. The
decompressed size is recorded only if the raster is uncompressed.

[gwp] I agree that some (a few or a lot) of implementation may not provide
the information but as I said, I am requesting that the assignment be made
and those who can (want to) may record the size information.

 

It really isn't a matter of "may not provide", in most cases clients (and
printers) simply can't buffer hundreds of megabytes of raster data. I can
add the field, but since most producers of PWG Raster will not be able to
supply the compressed size of the raster no printer will be able to depend
on it anyways, so IMHO it is best to have the printer, if it is going to do
any local processing of full page images, use its own optimal internal
storage format than try to gerry-rig something into the format that just
won't work.

 

[gwp] As I stated in my original request, I am not worried about the
printer, it will accept the streaming input just fine.  I want the size
information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging anything.  I do
not understand your comment "that just won't work".  It works fine.  In
fact, I wrote a routine that will find the size-only of compressed page by
running the compression routine without storing the compressed data.  I
don't understand your objection to assigning the field.

 

... 

I would actually prefer to flag the file as version 3 which is an
uncompressed CUPS Raster with the version 2 page header. And in the case of
local processing, you'll likely want to use native word order (another
feature of CUPS Raster that we are not bringing along for PWG Raster...)

 

[gwp] Do you mean big/little-endian?  I am nothing requesting the word
ordering flag (value) be used.  The current specification is ok.

 

My main point was that if you are concerned about having a standard
representation for intermediate data, CUPS Raster already provides that. If
you are trying to tweak PWG Raster for use as an internal representation
format then I'd rather not put that in the standard since internal formats
are OOS for any PWG standard.

 

Would it be sufficient to document an uncompressed version of PWG Raster
(with the "RAS3" file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?

 

[gwp] I believe the RAS3 is for the entire PWG Raster file.  I am requesting
a flags (value) for individual pages.  

 

Since the format does not support this, I would be opposed to adding
something that would be used only for an internal representation of a PWG
Raster file.

 

[gwp] Again, I do not understand your objection. 

 

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 


-- 
This message has been scanned for viruses and 
dangerous content by   MailScanner, and is 
believed to be clean. 


_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

 


-- 
This message has been scanned for viruses and 
dangerous content by   MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------=_NextPart_000_0001_01CC0123.5A056D50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 

-- 
This message has been scanned for viruses and <=
br>dangerous content by MailSca=
nner, and is 
believed to be clean. 

-=
-=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


------=_NextPart_000_0001_01CC0123.5A056D50--


--===============1562922819==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1562922819==--


From p.sparks@ms2.hinet.net  Fri Apr 22 19:18:42 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6804E06C0 for ; Fri, 22 Apr 2011 19:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -86.86
X-Spam-Level: 
X-Spam-Status: No, score=-86.86 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZz95Ro1+i+c for ; Fri, 22 Apr 2011 19:18:42 -0700 (PDT)
Received: from telesp.net.br (201-27-181-152.dsl.telesp.net.br [201.27.181.152]) by ietfc.amsl.com (Postfix) with ESMTP id 0B600E065C for ; Fri, 22 Apr 2011 19:18:42 -0700 (PDT)
Received: from  201.27.181.152 (account  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 013289950 for ; Fri, 22 Apr 2011 23:18:40 -0300
From: 
To: 
Subject: Newsletter Fri, 22 Apr 2011 23:18:40 -0300
Date: Fri, 22 Apr 2011 23:18:40 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: 7bit
X-Mailer: kcpiuw-37
Message-ID: <0599390903.1ONTYR3X191767@utfsj.ckhivqoomhnww.com>

Hi!!

Do you want a more satisfactory future, grow in money earning, and the respect of all?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will help ANYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- Just follow YOUR Dreams!
- Live a wonderful life by earning or upgrading your degree.


This is a best chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


If you want to get better - you must Call Today to start improving your life!


~CALL US~


1-305-460-2287



Please leave us a voice message with your name and phone number with country code if outside USA and we'll contact you asap.


It is your move...
Make the right move.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From o.jittravinee@3d-thaiexcell.com  Sat Apr 23 10:38:34 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE0CAE071B for ; Sat, 23 Apr 2011 10:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -84.412
X-Spam-Level: 
X-Spam-Status: No, score=-84.412 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCf52XMNzV49 for ; Sat, 23 Apr 2011 10:38:34 -0700 (PDT)
Received: from telesp.net.br (201-1-27-78.dsl.telesp.net.br [201.1.27.78]) by ietfc.amsl.com (Postfix) with ESMTP id D7BF0E06C8 for ; Sat, 23 Apr 2011 10:38:33 -0700 (PDT)
Received: from  201.1.27.78 (account  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 873396150 for ; Sat, 23 Apr 2011 14:38:32 -0300
From: 
To: 
Subject: Newsletter Sat, 23 Apr 2011 14:38:32 -0300
Date: Sat, 23 Apr 2011 14:38:32 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: 7bit
X-Mailer: lqqb.12
Message-ID: <0873078442.XHL1QFNN848169@sipdmareh.baujqlawevxfz.tv>

Hey bud!!

Do you want an effective future, step up in money earning, and the respect of all?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 5 weeks with our program! 


~Our program will let ANYONE with professional experience
get a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- You can realize YOUR Dreams!
- Live a wonderful life by earning or upgrading your degree.


This is a splendid chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


If you want to get better - you must Call Us 24/7 to start improving your life!


~CALL~


1-916-484-3795



You must leave us a message with your phone number with country code if outside USA and name and we'll contact you as soon as possible.


It's your way...
Make the right decision.




Sincerely.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From 46c9aa60.5050103@3season.co.jp  Sat Apr 23 16:46:02 2011
Return-Path: <46c9aa60.5050103@3season.co.jp>
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7AC28E06A5 for ; Sat, 23 Apr 2011 16:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -76.313
X-Spam-Level: 
X-Spam-Status: No, score=-76.313 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9uR0ioxIflf for ; Sat, 23 Apr 2011 16:46:02 -0700 (PDT)
Received: from 189-54-123-237-nd.cpe.vivax.com.br (189-54-123-237-nd.cpe.vivax.com.br [189.54.123.237]) by ietfc.amsl.com (Postfix) with ESMTP id B825FE0613 for ; Sat, 23 Apr 2011 16:46:00 -0700 (PDT)
Received: from 189.54.123.237(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MM1A5-3379dq-95 for ; Sat, 23 Apr 2011 20:45:59 -0300
From: 
To: 
Subject: Newsletter Sat, 23 Apr 2011 20:45:59 -0300
Date: Sat, 23 Apr 2011 20:45:59 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: gpqhwunkh.09
Message-ID: <8546914510.QLJIFQ40155012@shgxa.axzaz.ua>

Hi there!

Do you want a prosperous future, go up in money earning, and brownie points?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and professional experience.

Get a Degree in 5 weeks with our program! 


~Our program will help ALL with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- You can realize YOUR Dreams!
- Live a better life by earning or upgrading your degree.


This is a splendid way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a short time.


Contact us 24 hours to start improving your life!


~CONTACT US~


1-310-205-2502



You must leave us a message with your name and phone number with country code if outside USA and we'll contact you asap.


It is your decision...
Make the right decision.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From f844197d@ms2.hinet.net  Sun Apr 24 06:42:19 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1F918E06A9 for ; Sun, 24 Apr 2011 06:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -89.682
X-Spam-Level: 
X-Spam-Status: No, score=-89.682 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBw9ktTZr4h1 for ; Sun, 24 Apr 2011 06:42:18 -0700 (PDT)
Received: from gvt.net.br (201.86.200.126.dynamic.adsl.gvt.net.br [201.86.200.126]) by ietfc.amsl.com (Postfix) with ESMTP id 05DDDE06A7 for ; Sun, 24 Apr 2011 06:42:17 -0700 (PDT)
Received: from 189.27.230.111(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MMZAU-8809nl-07 for ; Sun, 24 Apr 2011 10:42:16 -0300
From: 
To: 
Subject: Newsletter Sun, 24 Apr 2011 10:42:16 -0300
Date: Sun, 24 Apr 2011 10:42:16 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: dytzn.62
Message-ID: <1857846956.4QI2ZMLY844083@rsewejre.lofazaraq.info>

How are you bud!

Do you want a superior future, go up in money earning power, and the praise of all?

Special offer:
We can assist with Diplomas from prestigious universities based on your present knowledge and professional experience.

Get a Degree in 5 weeks with our program! 


~Our program will let EVERYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- Just follow YOUR Dreams!
- Live a much better life by earning or upgrading your degree.


This is a nice way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


If you want to get better - you must Call Today to start improving your life!


~CALL US~


1-916-484-3795



Please leave us a voice message with your name and phone number with country code if outside USA and we will call you asap.


It is your move...
Make the right move.




Best regards.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ambitpte.comchetanchopra@ambitpte.com  Sun Apr 24 12:14:08 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 39E5EE06AB for ; Sun, 24 Apr 2011 12:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -89.656
X-Spam-Level: 
X-Spam-Status: No, score=-89.656 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYczwxeZcURB for ; Sun, 24 Apr 2011 12:14:07 -0700 (PDT)
Received: from telesp.net.br (unknown [187.57.92.137]) by ietfc.amsl.com (Postfix) with ESMTP id 67F40E06A3 for ; Sun, 24 Apr 2011 12:14:07 -0700 (PDT)
Received: from 187.57.92.137(helo=megatron.ietf.org) by megatron.ietf.org with esmtpa (Exim 4.69) (envelope-from ) id 1MMPEO-3836un-EK for ; Sun, 24 Apr 2011 16:14:07 -0300
From: 
To: 
Subject: Newsletter Sun, 24 Apr 2011 16:14:07 -0300
Date: Sun, 24 Apr 2011 16:14:07 -0300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: mrbx-68
Message-ID: <4554851270.KBAGL7YR585255@pevrwpnlqpim.tgsqmldflfmz.biz>

How are you bud!

Do you want a prosperous future, soar in money earning power, and  pat on the back :)?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 6 weeks with our program! 


~Our program will let ANYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Just think about it... 
- Just follow YOUR Dreams!
- Live a wonderful life by earning or upgrading your degree.


This is a rare chance to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


Contact us NOW to start improving your life!


~CALL~


1-305-460-2287



You must leave us a voice message with your name and phone number with country code if outside USA and we'll contact you as soon as possible.


It is your chance...
Make the right move.




Best regards.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From 203-351-6152scott.gerschwer@itchu.com  Mon Apr 25 04:11:23 2011
Return-Path: <203-351-6152scott.gerschwer@itchu.com>
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68158E06B8 for ; Mon, 25 Apr 2011 04:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.557
X-Spam-Level: 
X-Spam-Status: No, score=-92.557 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49YVSbKAdi6I for ; Mon, 25 Apr 2011 04:11:22 -0700 (PDT)
Received: from broadband.pool1-252.lb.com (unknown [119.235.2.252]) by ietfc.amsl.com (Postfix) with ESMTP id C36AEE06A4 for ; Mon, 25 Apr 2011 04:11:20 -0700 (PDT)
Received: from  119.235.2.252 (account  HELO megatron.ietf.org) by megatron.ietf.org (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 300574727 for ; Mon, 25 Apr 2011 03:11:21 -0800
From: 
To: 
Subject: Newsletter Mon, 25 Apr 2011 03:11:21 -0800
Date: Mon, 25 Apr 2011 03:11:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: 7bit
X-Mailer: kckgtxt_45
Message-ID: <5955405399.EL7N50KT702187@oplkqvop.tognoyu.info>

Hi!!

Do you want a good future, grow in  money, and the recognition of all?

Today only:
We can assist with Diplomas from prestigious universities based on your present knowledge and work experience.

Get a Degree in 4 weeks with our program! 


~Our program will let ANYONE with professional experience
gain a 100% verified Degree:


~Doctorate
~Bachelors
~Masters


- Think about it... 
- Just follow YOUR Dreams!
- Live a much better life by earning or upgrading your degree.


This is a exellent way to make a right move and receive your due
benefits... if you are qualified but are lacking that piece of paper. Get one from us in a fraction of the time.


If you want to get better - you must Contact Us 24/7 to start improving your life!


~CALL~


1-301-396-3506



You must leave us a voice message with your phone number with country code if outside USA and name and we'll call you back as soon as possible.


It's your move...
Make the right decision.




Best wishes.



Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.

From ipp-bounces@pwg.org  Mon Apr 25 06:29:07 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CF5D1E073A for ; Mon, 25 Apr 2011 06:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level: 
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtBmKu084o-X for ; Mon, 25 Apr 2011 06:29:01 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 07609E0728 for ; Mon, 25 Apr 2011 06:29:00 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 080B879528; Mon, 25 Apr 2011 09:28:29 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 8D9507951B for ; Mon, 25 Apr 2011 09:28:11 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 25 Apr 2011 06:28:09 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Mon, 25 Apr 2011 06:28:07 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] Requested Additions to PWG Raster
Thread-Index: AQLFuyzq+wsk6228T9B9XCf5xj24gQHaN4n9AtLobE8CkFSXfQFMCqlaAekFzLgCHglk65ISjKbggAQOCkA=
References: <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>	  <000001cc0144$e1149c50$a33dd4f0$@tykodi.com>
From: "Petrie, Glen" 
To: 
X-OriginalArrivalTime: 25 Apr 2011 13:28:09.0282 (UTC) FILETIME=[9E298220:01CC034C]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0148191426=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 080B879528.A9A62
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0148191426==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC034C.9CDB02FF"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC034C.9CDB02FF
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Paul,

=20

I would like to change my request to the following

=20

I would like to request that that 16 integer, 16 floating point and 16
string that are denoted in CUPS raster as driver-defined be added to the
PWG raster.

=20

I realize it is a mute point for this request since the data elements
are already reserved in CUPS raster and, as such, are by defacto,
inherited by the PWG raster (even if in the shadow or not specifically
declared) as long as the PWG raster maintains 100% compatible with CUPS
raster.

=20

These fields do not jerry-rig additions to either the CUPS or PWG raster
since they are already defined by CUPS.

These fields do not cause any interpretability testing issues since they
are driver specific information.

=20

Glen

=20

=20

________________________________

From: Paul Tykodi [mailto:ptykodi@tykodi.com]=20
Sent: Friday, April 22, 2011 4:28 PM
To: Petrie, Glen
Cc: ipp@pwg.org; 'Ira McDonald'; msweet@apple.com
Subject: RE: [IPP] Requested Additions to PWG Raster

=20

Hi Glen,

=20

Where we are currently reaching out to some printer manufacturers who
have previously not participated in PWG activities (portable printer
manufacturers, thermal transfer-direct thermal printer manufacturers) to
let them know about the IPP Anywhere project and the PWG Raster Format,
I am in favor of waiting for a little while to see if we get some
interest from the reach out activities before making a final decision on
your request.

=20

If we do get some participation from the printer manufacturers outlined
above, they might also find some value in the feature you are requesting
so I believe it is a little premature to reject the idea of adding the
field at this time.

=20

Best Regards,

=20

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  ptykodi@tykodi.com
WWW:  http://www.tykodi.com =20

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Petrie, Glen
Sent: Friday, April 22, 2011 3:08 PM
To: Ira McDonald
Cc: ipp@pwg.org
Subject: RE: [IPP] Requested Additions to PWG Raster

=20

Uncle !!!!!!!!!

=20

It is an optional field and completely testable in an interoperability
test.

=20

Glen

=20

=20

________________________________

From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
Sent: Friday, April 22, 2011 11:52 AM
To: Petrie, Glen; Ira McDonald
Cc: Michael Sweet; ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

Hi Glen,

I agree with Mike here in objecting to registering these fields.

PWG standards are supposed to only contain fields/attributes
that *could* be tested in an interoperability event.  It's not
plausible that a typical streaming client would know the size=20
when it's very large (when the feature's useful), so such a
feature's not interoperable or verifiable.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
=20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

=20

On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen
 wrote:

As stated below, I do understand objection to adding the field.  I would
to hear from other PWG members on the addition of these fields.

=20

Glen

=20

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Friday, April 22, 2011 10:20 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:

	...=20

	[gwp] The important case is the size of the compressed raster
data. The decompressed size is recorded only if the raster is
uncompressed.

	[gwp] I agree that some (a few or a lot) of implementation may
not provide the information but as I said, I am requesting that the
assignment be made and those who can (want to) may record the size
information.

=20

It really isn't a matter of "may not provide", in most cases clients
(and printers) simply can't buffer hundreds of megabytes of raster data
I can add the field, but since most producers of PWG Raster will not be
able to supply the compressed size of the raster no printer will be able
to depend on it anyways, so IMHO it is best to have the printer, if it
is going to do any local processing of full page images, use its own
optimal internal storage format than try to gerry-rig something into the
format that just won't work.

=20

[gwp] As I stated in my original request, I am not worried about the
printer, it will accept the streaming input just fine.  I want the size
information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging anything.
I do not understand your comment "that just won't work".  It works fine.
In fact, I wrote a routine that will find the size-only of compressed
page by running the compression routine without storing the compressed
data.  I don't understand your objection to assigning the field.

=09=20

	...=20

	I would actually prefer to flag the file as version 3 which is
an uncompressed CUPS Raster with the version 2 page header. And in the
case of local processing, you'll likely want to use native word order
(another feature of CUPS Raster that we are not bringing along for PWG
Raster...)

=09=20

	[gwp] Do you mean big/little-endian?  I am nothing requesting
the word ordering flag (value) be used.  The current specification is
ok.

=20

My main point was that if you are concerned about having a standard
representation for intermediate data, CUPS Raster already provides that.
If you are trying to tweak PWG Raster for use as an internal
representation format then I'd rather not put that in the standard since
internal formats are OOS for any PWG standard.

=20

Would it be sufficient to document an uncompressed version of PWG Raster
(with the "RAS3" file header) and then mark the native word order
support as out-of-scope for the spec but something that might be used
internally?

=20

[gwp] I believe the RAS3 is for the entire PWG Raster file.  I am
requesting a flags (value) for individual pages.=20=20

=20

Since the format does not support this, I would be opposed to adding
something that would be used only for an internal representation of a
PWG Raster file.

=20

[gwp] Again, I do not understand your objection.=20

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC034C.9CDB02FF
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable























Paul,



 



I would like to change my request to=
 the
following



 



I would like to request that that 16
integer, 16 floating point and 16 string that are denoted in CUPS raster as
driver-defined be added to the PWG raster.



 



I realize it is a mute point for this
request since the data elements are already reserved in CUPS raster and, as
such, are by defacto, inherited by the PWG raster (even if in the shadow or=
 not
specifically declared) as long as the PWG raster maintains 100% compatible =
with
CUPS raster.



 



These fields do not jerry-rig additi=
ons
to either the CUPS or PWG raster since they are already defined by CUPS.



These fields do not cause any interp=
retability
testing issues since they are driver specific information.



 



Glen



 



 















From: Paul Tyk=
odi [mailto:ptykodi@tykodi.com]


Sent: Friday, April 22, 2011=
 4:28
PM

To: Petrie, Glen

Cc: ipp@pwg.org; 'Ira McDona=
ld';
msweet@apple.com

Subject: RE: [IPP] Requested
Additions to PWG Raster






 



Hi Glen,<=
/o:p>



 



Where we are
currently reaching out to some printer manufacturers who have previously not
participated in PWG activities (portable printer manufacturers, thermal
transfer-direct thermal printer manufacturers) to let them know about the I=
PP
Anywhere project and the PWG Raster Format, I am in favor of waiting for a
little while to see if we get some interest from the reach out activities
before making a final decision on your request.



 



If we do get s=
ome
participation from the printer manufacturers outlined above, they might also
find some value in the feature you are requesting so I believe it is a litt=
le
premature to reject the idea of adding the field at this time.



 



Best Regards,<=
o:p>



 






--=






Paul Tykodi

Principal Consultant

TCS - Tykodi Consulting Services LLC



Tel/Fax: 603-343-1820

Mobile:=
 
603-866-0712

E-mail:  ptykodi@tykodi.com<=
/span>

WWW:  http://www.tykodi.com=










From:
ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie, Glen

Sent: Friday, April 22, 2011=
 3:08
PM

To: Ira McDonald

Cc: ipp@pwg.org

Subject: RE: [IPP] Requested
Additions to PWG Raster









 



Uncle !!!!!!!!!



 



It is an optional field and complete=
ly
testable in an interoperability test.



 



Glen



 



 















From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Friday, April 22, 2011=
 11:52
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.o=
rg

Subject: Re: [IPP] Requested
Additions to PWG Raster






 



Hi Glen,



I agree with Mike here in objecting to registering these fields.



PWG standards are supposed to only contain fields/attributes

that *could* be tested in an interoperability event.  It's not

plausible that a typical streaming client would know the size 

when it's very large (when the feature's useful), so such a

feature's not interoperable or verifiable.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box=
 221 
Grand Marais, MI 49839

  906-494-2434



 =







On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:









As stated below, I do understand objection to adding the field.
 I would to hear from other PWG members on the addition of these field=
s.



 



Glen



 



 















From: Michael Sweet [mailto:msweet@apple.com] 
Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] Requested=
 Additions
to PWG Raster









 









On Apr 2=
2, 2011,
at 9:34 AM, Petrie, Glen wrote:





















... 


















[gwp] The important case is the size of the compressed raster d=
ata.
The decompressed size is recorded only if the raster is uncompressed.









[gwp] I agree that some (a few or a lot) of implementation may =
not
provide the information but as I said, I am requesting that the assignment =
be
made and those who can (want to) may record the size information.


















 






It reall=
y isn't a
matter of "may not provide", in most cases clients (and printers)
simply can't buffer hundreds of megabytes of raster data I can add the fiel=
d,
but since most producers of PWG Raster will not be able to supply the
compressed size of the raster no printer will be able to depend on it anywa=
ys,
so IMHO it is best to have the printer, if it is going to do any local
processing of full page images, use its own optimal internal storage format
than try to gerry-rig something into the format that just won't work.<=
/o:p>












 



[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging
anything.  I do not understand your comment “that just won’=
;t
work”.  It works fine.  In fact, I wrote a routine that will
find the size-only of compressed page by running the compression routine
without storing the compressed data.  I don’t understand your
objection to assigning the field.



























 



... 












I would =
actually
prefer to flag the file as version 3 which is an uncompressed CUPS Raster w=
ith
the version 2 page header. And in the case of local processing, you'll like=
ly
want to use native word order (another feature of CUPS Raster that we are n=
ot
bringing along for PWG Raster...)















 









[gwp] Do you mean big/little-endian?  I am nothing request=
ing
the word ordering flag (value) be used.  The current specification is =
ok.


















 






My main =
point was
that if you are concerned about having a standard representation for
intermediate data, CUPS Raster already provides that. If you are trying to
tweak PWG Raster for use as an internal representation format then I'd rath=
er
not put that in the standard since internal formats are OOS for any PWG
standard.









&nb=
sp;












Would it=
 be
sufficient to document an uncompressed version of PWG Raster (with the
"RAS3" file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?=










 









[gwp] I believe the RAS3 is for the entire PWG Raster file.&nbs=
p; I
am requesting a flags (value) for individual pages.  












 















Since th=
e format
does not support this, I would be opposed to adding something that would be
used only for an internal representation of a PWG Raster file.



 






[gwp] Again, I do not understand your objection. =













 












____________________________________________________=
____________________

Michael Sweet, Senior Printing System Engineer, PWG Chair









 














-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 











_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp






 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC034C.9CDB02FF--

--===============0148191426==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0148191426==--

From ipp-bounces@pwg.org  Mon Apr 25 06:51:50 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C29E5E073A for ; Mon, 25 Apr 2011 06:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.597
X-Spam-Level: 
X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDxtArloku2I for ; Mon, 25 Apr 2011 06:51:48 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 82E82E073F for ; Mon, 25 Apr 2011 06:51:48 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 118BE7952D; Mon, 25 Apr 2011 09:51:34 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id E1DA77952D for ; Mon, 25 Apr 2011 09:51:19 -0400 (EDT)
MIME-version: 1.0
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LK70002MNTI3RZ0@mail-out.apple.com> for ipp@pwg.org; Mon, 25 Apr 2011 06:51:19 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-07-4db57c56b9a8
Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay16.apple.com (Apple SCV relay) with SMTP id 59.35.12552.65C75BD4; Mon, 25 Apr 2011 06:51:18 -0700 (PDT)
Received: from [10.0.1.4] (pool-71-116-72-81.snfcca.dsl-w.verizon.net [71.116.72.81]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LK700C93NTBB770@cardamom.apple.com> for ipp@pwg.org; Mon, 25 Apr 2011 06:51:18 -0700 (PDT)
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>      <000001cc0144$e1149c50$a33dd4f0$@tykodi.com> 
In-reply-to: 
Message-id: 
X-Mailer: iPad Mail (8F190)
From: Mike Sweet 
Subject: Re: [IPP] Requested Additions to PWG Raster
Date: Mon, 25 Apr 2011 06:51:24 -0700
To: "Petrie, Glen" 
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0600063075=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 118BE7952D.AA6D1
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0600063075==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_WNGFihjeQNC+1k2xp2rXLw)"


--Boundary_(ID_WNGFihjeQNC+1k2xp2rXLw)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

I can add them, with the caveat that some of the cupsInteger fields will be=
 used for PWG Raster.


Sent from my iPad

On Apr 25, 2011, at 6:28 AM, "Petrie, Glen"  wr=
ote:

> Paul,
>=20=20
> I would like to change my request to the following
>=20=20
> I would like to request that that 16 integer, 16 floating point and 16 st=
ring that are denoted in CUPS raster as driver-defined be added to the PWG =
raster.
>=20=20
> I realize it is a mute point for this request since the data elements are=
 already reserved in CUPS raster and, as such, are by defacto, inherited by=
 the PWG raster (even if in the shadow or not specifically declared) as lon=
g as the PWG raster maintains 100% compatible with CUPS raster.
>=20=20
> These fields do not jerry-rig additions to either the CUPS or PWG raster =
since they are already defined by CUPS.
> These fields do not cause any interpretability testing issues since they =
are driver specific information.
>=20=20
> Glen
>=20=20
>=20=20
> From: Paul Tykodi [mailto:ptykodi@tykodi.com]=20
> Sent: Friday, April 22, 2011 4:28 PM
> To: Petrie, Glen
> Cc: ipp@pwg.org; 'Ira McDonald'; msweet@apple.com
> Subject: RE: [IPP] Requested Additions to PWG Raster
>=20=20
> Hi Glen,
>=20=20
> Where we are currently reaching out to some printer manufacturers who hav=
e previously not participated in PWG activities (portable printer manufactu=
rers, thermal transfer-direct thermal printer manufacturers) to let them kn=
ow about the IPP Anywhere project and the PWG Raster Format, I am in favor =
of waiting for a little while to see if we get some interest from the reach=
 out activities before making a final decision on your request.
>=20=20
> If we do get some participation from the printer manufacturers outlined a=
bove, they might also find some value in the feature you are requesting so =
I believe it is a little premature to reject the idea of adding the field a=
t this time.
>=20=20
> Best Regards,
>=20=20
> --
> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
>=20
> Tel/Fax: 603-343-1820
> Mobile:  603-866-0712
> E-mail:  ptykodi@tykodi.com
> WWW:  http://www.tykodi.com
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petri=
e, Glen
> Sent: Friday, April 22, 2011 3:08 PM
> To: Ira McDonald
> Cc: ipp@pwg.org
> Subject: RE: [IPP] Requested Additions to PWG Raster
>=20=20
> Uncle !!!!!!!!!
>=20=20
> It is an optional field and completely testable in an interoperability te=
st.
>=20=20
> Glen
>=20=20
>=20=20
> From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
> Sent: Friday, April 22, 2011 11:52 AM
> To: Petrie, Glen; Ira McDonald
> Cc: Michael Sweet; ipp@pwg.org
> Subject: Re: [IPP] Requested Additions to PWG Raster
>=20=20
> Hi Glen,
>=20
> I agree with Mike here in objecting to registering these fields.
>=20
> PWG standards are supposed to only contain fields/attributes
> that *could* be tested in an interoperability event.  It's not
> plausible that a typical streaming client would know the size=20
> when it's very large (when the feature's useful), so such a
> feature's not interoperable or verifiable.
>=20
> Cheers,
> - Ira
>=20
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> May to Christmas:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434
>=20=20
>=20
> On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen  wrote:
> As stated below, I do understand objection to adding the field.  I would =
to hear from other PWG members on the addition of these fields.
>=20=20
> Glen
>=20=20
>=20=20
> From: Michael Sweet [mailto:msweet@apple.com]=20
> Sent: Friday, April 22, 2011 10:20 AM
> To: Petrie, Glen
> Cc: ipp@pwg.org
> Subject: Re: [IPP] Requested Additions to PWG Raster
>=20=20
> On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:
> ...=20
> [gwp] The important case is the size of the compressed raster data. The d=
ecompressed size is recorded only if the raster is uncompressed.
> [gwp] I agree that some (a few or a lot) of implementation may not provid=
e the information but as I said, I am requesting that the assignment be mad=
e and those who can (want to) may record the size information.
>=20=20
> It really isn't a matter of "may not provide", in most cases clients (and=
 printers) simply can't buffer hundreds of megabytes of raster data I can a=
dd the field, but since most producers of PWG Raster will not be able to su=
pply the compressed size of the raster no printer will be able to depend on=
 it anyways, so IMHO it is best to have the printer, if it is going to do a=
ny local processing of full page images, use its own optimal internal stora=
ge format than try to gerry-rig something into the format that just won't w=
ork.
>=20=20
> [gwp] As I stated in my original request, I am not worried about the prin=
ter, it will accept the streaming input just fine.  I want the size informa=
tion for navigation of a many page raster without having to decompress page=
s in a serial manor.   I am not jerry-rigging anything.  I do not understan=
d your comment =E2=80=9Cthat just won=E2=80=99t work=E2=80=9D.  It works fi=
ne.  In fact, I wrote a routine that will find the size-only of compressed =
page by running the compression routine without storing the compressed data=
.  I don=E2=80=99t understand your objection to assigning the field.
>=20=20
> ...=20
> I would actually prefer to flag the file as version 3 which is an uncompr=
essed CUPS Raster with the version 2 page header. And in the case of local =
processing, you'll likely want to use native word order (another feature of=
 CUPS Raster that we are not bringing along for PWG Raster...)
>=20=20
> [gwp] Do you mean big/little-endian?  I am nothing requesting the word or=
dering flag (value) be used.  The current specification is ok.
>=20=20
> My main point was that if you are concerned about having a standard repre=
sentation for intermediate data, CUPS Raster already provides that. If you =
are trying to tweak PWG Raster for use as an internal representation format=
 then I'd rather not put that in the standard since internal formats are OO=
S for any PWG standard.
>=20=20
>=20
> Would it be sufficient to document an uncompressed version of PWG Raster =
(with the "RAS3" file header) and then mark the native word order support a=
s out-of-scope for the spec but something that might be used internally?
>=20=20
> [gwp] I believe the RAS3 is for the entire PWG Raster file.  I am request=
ing a flags (value) for individual pages.=20=20
>=20=20
> Since the format does not support this, I would be opposed to adding some=
thing that would be used only for an internal representation of a PWG Raste=
r file.
>=20=20
> [gwp] Again, I do not understand your objection.
>=20=20
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>=20=20
>=20
> --=20
> This message has been scanned for viruses and=20
> dangerous content by MailScanner, and is=20
> believed to be clean.
>=20
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>=20
>=20=20
>=20
> --=20
> This message has been scanned for viruses and=20
> dangerous content by MailScanner, and is=20
> believed to be clean.
>=20
> --=20
> This message has been scanned for viruses and=20
> dangerous content by MailScanner, and is=20
> believed to be clean.
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_WNGFihjeQNC+1k2xp2rXLw)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable


I can add them, with the caveat that s=
ome of the cupsInteger fields will be used for PWG Raster.

Sent from my iPad

On Apr 25, 2011, at 6:28 AM, "Petrie, Gle=
n" <glen.petrie@eitc.epson=
.com> wrote:

Hi Glen,
 
=

Where we are currently reaching out to some pri=
nter manufacturers who have previously not participated in PWG activities (=
portable printer manufacturers, thermal transfer-direct thermal printer man=
ufacturers) to let them know about the IPP Anywhere project and the PWG Ras=
ter Format, I am in favor of waiting for a little while to see if we get so=
me interest from the reach out activities before making a final decision on=
 your request.
 =

If we do get some participatio=
n from the printer manufacturers outlined above, they might also find some =
value in the feature you are requesting so I believe it is a little prematu=
re to reject the idea of adding the field at this time.
 
Best Regards,
<=
o:p> 
/Paul
--
Paul Tykodi
Princ=
ipal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603=
-343-1820
Mobile:  603-866-0712
E-mail:  ptykodi@tykodi.com
WWW:  <=
/span>http://www.tykodi.com
From: ipp-bounce=
s@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie, Glen
=
Sent: Friday, April 22, 2011 3:08 PM
To: Ira McDonald
<=
b>Cc: ipp@pwg.org
Subject: RE: [IPP] Requested Additions to P=
WG Raster
 =

Uncle !!!!!!!!!
 
It is an optional field and completely testable in an interoperabi=
lity test.
 
Glen=

 
 =

=

From: I=
ra McDonald [mailto:blueroofmusic@gmail.com] 
Sent: Friday, April=
 22, 2011 11:52 AM
To: Petrie, Glen; Ira McDonald
Cc: M=
ichael Sweet; ipp@pwg.org
Subject: Re: [IPP] Requested Additions =
to PWG Raster
 
Hi Glen,

I agree with Mike here in obje=
cting to registering these fields.

PWG standards are supposed to onl=
y contain fields/attributes
that *could* be tested in an interoperabilit=
y event.  It's not
plausible that a typical streaming client would =
know the size 
when it's very large (when the feature's useful), so such=
 a
feature's not interoperable or verifiable.

Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Li=
nux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Ch=
air - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
=
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic<=
/a>
http://sites.google.com/site/highnorthinc=

mailto:blueroofmusic@gmail.com
Christmas through April:
  5=
79 Park Place  Saline, MI  48176
  734-944-0094
May to=
 Christmas:
  PO Box 221  Grand Marais, MI 49839
  906=
-494-2434
 
On Fri, Apr 22, 2011 at 1:3=
3 PM, Petrie, Glen <glen.p=
etrie@eitc.epson.com> wrote:
As stated below, I do unde=
rstand objection to adding the field.  I would to hear from other PWG =
members on the addition of these fields.
 =

Glen
 
 
From: Michael Sweet [mailto:msweet@apple.com] 
Sent: F=
riday, April 22, 2011 10:20 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject=
: Re: [IPP] Requested Additions to PWG Raster
 
On Apr 22, 2011, at 9:3=
4 AM, Petrie, Glen wrote:
... 
=
[gwp] The importan=
t case is the size of the compressed raster data. The decompressed size is =
recorded only if the raster is uncompressed.
[gwp] I a=
gree that some (a few or a lot) of implementation may not provide the infor=
mation but as I said, I am requesting that the assignment be made and those=
 who can (want to) may record the size information.
 
=
It really isn't a matter of "may not provide", in most cases clie=
nts (and printers) simply can't buffer hundreds of megabytes of raster data=
 I can add the field, but since most producers of PWG Raster will not be ab=
le to supply the compressed size of the raster no printer will be able to d=
epend on it anyways, so IMHO it is best to have the printer, if it is going=
 to do any local processing of full page images, use its own optimal intern=
al storage format than try to gerry-rig something into the format that just=
 won't work.
 
[gwp] As I stated in my original request, I am not worr=
ied about the printer, it will accept the streaming input just fine.  =
I want the size information for navigation of a many page raster without ha=
ving to decompress pages in a serial manor.   I am not jerry-rigg=
ing anything.  I do not understand your comment “that just won&#=
8217;t work”.  It works fine.  In fact, I wrote a routine t=
hat will find the size-only of compressed page by running the compression r=
outine without storing the compressed data.  I don’t understand =
your objection to assigning the field.
=

 
... =
;
I would actually prefer to flag the=
 file as version 3 which is an uncompressed CUPS Raster with the version 2 =
page header. And in the case of local processing, you'll likely want to use=
 native word order (another feature of CUPS Raster that we are not bringing=
 along for PWG Raster...)
 
[gwp] Do you mean big/litt=
le-endian?  I am nothing requesting the word ordering flag (value) be =
used.  The current specification is ok.
 
My main=
 point was that if you are concerned about having a standard representation=
 for intermediate data, CUPS Raster already provides that. If you are tryin=
g to tweak PWG Raster for use as an internal representation format then I'd=
 rather not put that in the standard since internal formats are OOS for any=
 PWG standard.
 
Would it be sufficient to document an uncompressed version of PWG =
Raster (with the "RAS3" file header) and then mark the native wor=
d order support as out-of-scope for the spec but something that might be us=
ed internally?
 
=
[gwp] I believe th=
e RAS3 is for the entire PWG Raster file.  I am requesting a flags (va=
lue) for individual pages.  
 
Since the format do=
es not support this, I would be opposed to adding something that would be u=
sed only for an internal representation of a PWG Raster file.
 
[gwp] Again, I do not understand your objection. <=
/o:p>
 
___________________________________________________________________=
_____
Michael Sweet, Senior Printing System Engineer, PWG Chair
 

-- 
This message has been scanned for viruses and dangerous content by MailScanner, and is 
believed to be clean. =


___=
____________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo=
/ipp
=

















Paul,



 



I would like to change my request to=
 the
following



 



I would like to request that that 16
integer, 16 floating point and 16 string that are denoted in CUPS raster as
driver-defined be added to the PWG raster.



 



I realize it is a mute point for this
request since the data elements are already reserved in CUPS raster and, as
such, are by defacto, inherited by the PWG raster (even if in the shadow or=
 not
specifically declared) as long as the PWG raster maintains 100% compatible =
with
CUPS raster.



 



These fields do not jerry-rig additi=
ons
to either the CUPS or PWG raster since they are already defined by CUPS.



These fields do not cause any interp=
retability
testing issues since they are driver specific information.



 



Glen



 



 















From: Paul=
 Tykodi [mailto:ptykodi@tykodi.com]


Sent: Friday, April 22, 2011=
 4:28
PM

To: Petrie, Glen

Cc: ipp@pwg.org; 'Ira McDonald';
msw=
eet@apple.com

Subject: RE: [IPP] Requested
Additions to PWG Raster






 



=
Hi Glen,=




=
&nb=
sp;



=
Where we=
 are
currently reaching out to some printer manufacturers who have previously not
participated in PWG activities (portable printer manufacturers, thermal
transfer-direct thermal printer manufacturers) to let them know about the I=
PP
Anywhere project and the PWG Raster Format, I am in favor of waiting for a
little while to see if we get some interest from the reach out activities
before making a final decision on your request.



=
&nb=
sp;



=
If we do=
 get some
participation from the printer manufacturers outlined above, they might also
find some value in the feature you are requesting so I believe it is a litt=
le
premature to reject the idea of adding the field at this time.



=
&nb=
sp;



=
Best Reg=
ards,



=
&nb=
sp;






--






Paul Tykodi<=
br>
Principal Consultant

TCS - Tykodi Consulting Services LLC



Tel/Fax: 603-343-1820

Mobile:=
 
603-866-0712

E-mail:  ptykodi@tykodi.com

WWW:  htt=
p://www.tykodi.com









From:
ipp-bounces@pwg.org [mailto:ipp-=
bounces@pwg.org] On Behalf Of Petrie, Glen

Sent: Friday, April 22, 2011=
 3:08
PM

To: Ira McDonald

Cc: ipp@pwg.org

Subject: RE: [IPP] Requested
Additions to PWG Raster









 



Uncle !!!!!!!!!



 



It is an optional field and complete=
ly
testable in an interoperability test.



 



Glen



 



 















From: Ira =
McDonald
[mailto:blueroofmusic@gmail.com] 

Sent: Friday, April 22, 2011=
 11:52
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.org<=
br>
Subject: Re: [IPP] Requested
Additions to PWG Raster






 



Hi Glen,



I agree with Mike here in objecting to registering these fields.



PWG standards are supposed to only contain fields/attributes

that *could* be tested in an interoperability event.  It's not

plausible that a typical streaming client would know the size 

when it's very large (when the feature's useful), so such a

feature's not interoperable or verifiable.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.co=
m/site/blueroofmusic

http://sites.google.com/=
site/highnorthinc

mailto:blueroofmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box=
 221 
Grand Marais, MI 49839

  906-494-2434



 






On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <=
glen.petrie@eitc.epson.com>
wrote:









As stated below, I do understand objection to adding the field.
 I would to hear from other PWG members on the addition of these field=
s.



 



Glen



 



 















From: Michael Sweet [mailto:msweet@app=
le.com] 

Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org=


Subject: Re: [IPP] Requested=
 Additions
to PWG Raster









 









On Apr 22, 2011,
at 9:34 AM, Petrie, Glen wrote:





















... 


















[gwp] The important case is the size of the compressed raster d=
ata.
The decompressed size is recorded only if the raster is uncompressed.









[gwp] I agree that some (a few or a lot) of implementation may =
not
provide the information but as I said, I am requesting that the assignment =
be
made and those who can (want to) may record the size information.


















 






It really isn't a
matter of "may not provide", in most cases clients (and printers)
simply can't buffer hundreds of megabytes of raster data I can add the fiel=
d,
but since most producers of PWG Raster will not be able to supply the
compressed size of the raster no printer will be able to depend on it anywa=
ys,
so IMHO it is best to have the printer, if it is going to do any local
processing of full page images, use its own optimal internal storage format
than try to gerry-rig something into the format that just won't work.<=
/o:p>












 



[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging
anything.  I do not understand your comment =E2=80=9Cthat just won=E2=
=80=99t
work=E2=80=9D.  It works fine.  In fact, I wrote a routine that w=
ill
find the size-only of compressed page by running the compression routine
without storing the compressed data.  I don=E2=80=99t understand your
objection to assigning the field.



























 



... 












I would actually
prefer to flag the file as version 3 which is an uncompressed CUPS Raster w=
ith
the version 2 page header. And in the case of local processing, you'll like=
ly
want to use native word order (another feature of CUPS Raster that we are n=
ot
bringing along for PWG Raster...)















 









[gwp] Do you mean big/little-endian?  I am nothing request=
ing
the word ordering flag (value) be used.  The current specification is =
ok.


















 






My main point was
that if you are concerned about having a standard representation for
intermediate data, CUPS Raster already provides that. If you are trying to
tweak PWG Raster for use as an internal representation format then I'd rath=
er
not put that in the standard since internal formats are OOS for any PWG
standard.









 












Would it be
sufficient to document an uncompressed version of PWG Raster (with the
"RAS3" file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?=










 









[gwp] I believe the RAS3 is for the entire PWG Raster file.&nbs=
p; I
am requesting a flags (value) for individual pages.  












 















Since the format
does not support this, I would be opposed to adding something that would be
used only for an internal representation of a PWG Raster file.



 






[gwp] Again, I do not understand your objection. =













 












____________________________________________________=
____________________

Michael Sweet, Senior Printing System Engineer, PWG Chair









 














-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is=
 

believed to be clean. 











_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.org/mailma=
n/listinfo/ipp






 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




_______________________________________________
ipp=
 mailing list
ipp@pwg.org
http=
s://www.pwg.org/mailman/listinfo/ipp

--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_WNGFihjeQNC+1k2xp2rXLw)--

--===============0600063075==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0600063075==--

From ipp-bounces@pwg.org  Mon Apr 25 07:24:46 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A662E074A for ; Mon, 25 Apr 2011 07:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWUgL7OaduhC for ; Mon, 25 Apr 2011 07:24:37 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 84714E06B8 for ; Mon, 25 Apr 2011 07:24:37 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 8AA6F79537; Mon, 25 Apr 2011 10:24:03 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 85EB079535 for ; Mon, 25 Apr 2011 10:23:45 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 25 Apr 2011 07:23:44 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Mon, 25 Apr 2011 07:23:43 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] Requested Additions to PWG Raster
Thread-Index: AcwDT9xMj/NfvMNKTiCopauTw7pvjQAAU5Tw
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>      <000001cc0144$e1149c50$a33dd4f0$@tykodi.com>  
From: "Petrie, Glen" 
To: "Mike Sweet" 
X-OriginalArrivalTime: 25 Apr 2011 14:23:44.0614 (UTC) FILETIME=[622CC860:01CC0354]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0317227587=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 8AA6F79537.A9C71
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0317227587==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0354.61AAF92A"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0354.61AAF92A
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Doesn't "using them for PWG Raster" make the CUPS and PWG raster
incompatible?=20=20

=20

I believe the current fields for proposed to use the driver-specific
same are not needed.

=20

1. "total number of pages"=20

2. HorizontalTransform

3. VerticalTransform=20

=20

The Job Ticket will specify the output format (duplex, flip, rotate);
therefore, transforms data and information are part of the Job Ticket
and the raster must be transformed to the correct orientation required
so that the printer (or any consumer of the raster) does not know or
have to perform the transforms.  Raster data means the data is
rastered-out and should not require additional transforms (scaling might
be an exception); the transforms here may require the printer to have
rotation buffers which could be large and expensive to implement; not
desirable.

=20

Therefore, I am opposed to adding the specific PWR element for
Horizontal and Vertical Transform.  If a vendor which to use transforms,
then it is part of their driver specific information but not an official
PWG Raster element.

=20

The same logic applies to the total number of page.

=20

Thus, not officially specifying the elements above or any new elements
in the driver data space continues to make CUPS and PWG raster 100%
compatible but allow drivers (vendors) to add them and other data as
they deem necessary.

=20

=20

Glen

=20

=20

________________________________

From: Mike Sweet [mailto:msweet@apple.com]=20
Sent: Monday, April 25, 2011 6:51 AM
To: Petrie, Glen
Cc: ptykodi@tykodi.com; ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

I can add them, with the caveat that some of the cupsInteger fields will
be used for PWG Raster.



Sent from my iPad


On Apr 25, 2011, at 6:28 AM, "Petrie, Glen" 
wrote:

	Paul,

=09=20

	I would like to change my request to the following

=09=20

	I would like to request that that 16 integer, 16 floating point
and 16 string that are denoted in CUPS raster as driver-defined be added
to the PWG raster.

=09=20

	I realize it is a mute point for this request since the data
elements are already reserved in CUPS raster and, as such, are by
defacto, inherited by the PWG raster (even if in the shadow or not
specifically declared) as long as the PWG raster maintains 100%
compatible with CUPS raster.

=09=20

	These fields do not jerry-rig additions to either the CUPS or
PWG raster since they are already defined by CUPS.

	These fields do not cause any interpretability testing issues
since they are driver specific information.

=09=20

	Glen

=09=20

=09=20

=09
________________________________


	From: Paul Tykodi [mailto:ptykodi@tykodi.com]=20
	Sent: Friday, April 22, 2011 4:28 PM
	To: Petrie, Glen
	Cc: ipp@pwg.org; 'Ira McDonald'; 
msweet@apple.com
	Subject: RE: [IPP] Requested Additions to PWG Raster

=09=20

	Hi Glen,

=09=20

	Where we are currently reaching out to some printer
manufacturers who have previously not participated in PWG activities
(portable printer manufacturers, thermal transfer-direct thermal printer
manufacturers) to let them know about the IPP Anywhere project and the
PWG Raster Format, I am in favor of waiting for a little while to see if
we get some interest from the reach out activities before making a final
decision on your request.

=09=20

	If we do get some participation from the printer manufacturers
outlined above, they might also find some value in the feature you are
requesting so I believe it is a little premature to reject the idea of
adding the field at this time.

=09=20

	Best Regards,

=09=20

	--

	Paul Tykodi
	Principal Consultant
	TCS - Tykodi Consulting Services LLC
=09
	Tel/Fax: 603-343-1820
	Mobile:  603-866-0712
	E-mail:   ptykodi@tykodi.com
	WWW:  http://www.tykodi.com =20

	From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf
Of Petrie, Glen
	Sent: Friday, April 22, 2011 3:08 PM
	To: Ira McDonald
	Cc:  ipp@pwg.org
	Subject: RE: [IPP] Requested Additions to PWG Raster

=09=20

	Uncle !!!!!!!!!

=09=20

	It is an optional field and completely testable in an
interoperability test.

=09=20

	Glen

=09=20

=09=20

=09
________________________________


	From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
	Sent: Friday, April 22, 2011 11:52 AM
	To: Petrie, Glen; Ira McDonald
	Cc: Michael Sweet;  ipp@pwg.org
	Subject: Re: [IPP] Requested Additions to PWG Raster

=09=20

	Hi Glen,
=09
	I agree with Mike here in objecting to registering these fields.
=09
	PWG standards are supposed to only contain fields/attributes
	that *could* be tested in an interoperability event.  It's not
	plausible that a typical streaming client would know the size=20
	when it's very large (when the feature's useful), so such a
	feature's not interoperable or verifiable.
=09
	Cheers,
	- Ira
=09
	Ira McDonald (Musician / Software Architect)
	Chair - Linux Foundation Open Printing WG
	Co-Chair - IEEE-ISTO PWG IPP WG
	Co-Chair - TCG Hardcopy WG
	IETF Designated Expert - IPP & Printer MIB
	Blue Roof Music/High North Inc
	
http://sites.google.com/site/blueroofmusic
	http://sites.google.com/site/highnorthinc
=20
	mailto:  blueroofmusic@gmail.com
	Christmas through April:
	  579 Park Place  Saline, MI  48176
	  734-944-0094
	May to Christmas:
	  PO Box 221  Grand Marais, MI 49839
	  906-494-2434

=09=20

	On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <
 glen.petrie@eitc.epson.com> wrote:

	As stated below, I do understand objection to adding the field.
I would to hear from other PWG members on the addition of these fields.

=09=20

	Glen

=09=20

=09=20

=09
________________________________


	From: Michael Sweet [mailto: 
msweet@apple.com]=20
	Sent: Friday, April 22, 2011 10:20 AM
	To: Petrie, Glen
	Cc:  ipp@pwg.org
	Subject: Re: [IPP] Requested Additions to PWG Raster

=09=20

	On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:

		...=20

		[gwp] The important case is the size of the compressed
raster data. The decompressed size is recorded only if the raster is
uncompressed.

		[gwp] I agree that some (a few or a lot) of
implementation may not provide the information but as I said, I am
requesting that the assignment be made and those who can (want to) may
record the size information.

=09=20

	It really isn't a matter of "may not provide", in most cases
clients (and printers) simply can't buffer hundreds of megabytes of
raster data I can add the field, but since most producers of PWG Raster
will not be able to supply the compressed size of the raster no printer
will be able to depend on it anyways, so IMHO it is best to have the
printer, if it is going to do any local processing of full page images,
use its own optimal internal storage format than try to gerry-rig
something into the format that just won't work.

=09=20

	[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging anything.
I do not understand your comment "that just won't work".  It works fine.
In fact, I wrote a routine that will find the size-only of compressed
page by running the compression routine without storing the compressed
data.  I don't understand your objection to assigning the field.

=09=09=20

		...=20

		I would actually prefer to flag the file as version 3
which is an uncompressed CUPS Raster with the version 2 page header. And
in the case of local processing, you'll likely want to use native word
order (another feature of CUPS Raster that we are not bringing along for
PWG Raster...)

=09=09=20

		[gwp] Do you mean big/little-endian?  I am nothing
requesting the word ordering flag (value) be used.  The current
specification is ok.

=09=20

	My main point was that if you are concerned about having a
standard representation for intermediate data, CUPS Raster already
provides that. If you are trying to tweak PWG Raster for use as an
internal representation format then I'd rather not put that in the
standard since internal formats are OOS for any PWG standard.

=09=20

	Would it be sufficient to document an uncompressed version of
PWG Raster (with the "RAS3" file header) and then mark the native word
order support as out-of-scope for the spec but something that might be
used internally?

=09=20

	[gwp] I believe the RAS3 is for the entire PWG Raster file.  I
am requesting a flags (value) for individual pages.=20=20

=09=20

	Since the format does not support this, I would be opposed to
adding something that would be used only for an internal representation
of a PWG Raster file.

=09=20

	[gwp] Again, I do not understand your objection.=20

=09=20

=09
________________________________________________________________________
	Michael Sweet, Senior Printing System Engineer, PWG Chair

=09=20

=09
	--=20
	This message has been scanned for viruses and=20
	dangerous content by MailScanner 
, and is=20
	believed to be clean.=20

=09
	_______________________________________________
	ipp mailing list
	 ipp@pwg.org
	
https://www.pwg.org/mailman/listinfo/ipp

=09=20

=09
	--=20
	This message has been scanned for viruses and=20
	dangerous content by MailScanner 
, and is=20
	believed to be clean.=20

=09
	--=20
	This message has been scanned for viruses and=20
	dangerous content by MailScanner 
, and is=20
	believed to be clean.=20

	_______________________________________________
	ipp mailing list
	ipp@pwg.org
	https://www.pwg.org/mailman/listinfo/ipp


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0354.61AAF92A
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable























Doesn’t “using them for =
PWG
Raster” make the CUPS and PWG raster incompatible?  <=
/span>



 



I believe the current fields for
proposed to use the driver-specific same are not needed.<=
/font>



 



1. “total number of pages̶=
1; 



2. HorizontalTransform



3. VerticalTransform 



 



The Job Ticket will specify the outp=
ut format
(duplex, flip, rotate); therefore, transforms data and information are part=
 of
the Job Ticket and the raster must be transformed to the correct orientatio=
n required
so that the printer (or any consumer of the raster) does not know or have t=
o perform
the transforms.  Raster data means the data is rastered-out and should=
 not
require additional transforms (scaling might be an exception); the transfor=
ms
here may require the printer to have rotation buffers which could be large =
and
expensive to implement; not desirable.



 



Therefore, I am opposed to adding the
specific PWR element for Horizontal and Vertical Transform.  If a vend=
or
which to use transforms, then it is part of their driver specific informati=
on
but not an official PWG Raster element.



 



The same logic applies to the total
number of page.



 



Thus, not officially specifying the
elements above or any new elements in the driver data space continues to ma=
ke
CUPS and PWG raster 100% compatible but allow drivers (vendors) to add them=
 and
other data as they deem necessary.



 



 



Glen



 



 















From: Mike Swe=
et
[mailto:msweet@apple.com] 

Sent: Monday, April 25, 2011=
 6:51
AM

To: Petrie, Glen

Cc: ptykodi@tykodi.com;
ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster






 






I can add them, with the caveat that some of the cupsInteger fields
will be used for PWG Raster.













Sent from my iPad











On Apr 25, 2011, at 6:28 AM, "Petrie, Glen" <glen.petrie@eitc.epson.com&g=
t;
wrote:












Paul,



 



I would like to change my request to=
 the
following



 



I would like to request that that 16
integer, 16 floating point and 16 string that are denoted in CUPS raster as
driver-defined be added to the PWG raster.<=
/o:p>



 



I realize it is a mute point for this
request since the data elements are already reserved in CUPS raster and, as
such, are by defacto, inherited by the PWG raster (even if in the shadow or=
 not
specifically declared) as long as the PWG raster maintains 100% compatible =
with
CUPS raster.



 



These fields do not jerry-rig additi=
ons
to either the CUPS or PWG raster since they are already defined by CUPS.



These fields do not cause any
interpretability testing issues since they are driver specific information.=




 



Glen=




 



 















From: Paul Tyk=
odi
[mailto:ptykodi@tykodi.com] 

Sent: Friday, April 22, 2011=
 4:28
PM

To: Petrie, Glen

Cc: ipp@pwg.org;
'Ira McDonald'; msweet@apple.com

Subject: RE: [IPP] Requested
Additions to PWG Raster






 



Hi Glen,=




 



Where we are
currently reaching out to some printer manufacturers who have previously not
participated in PWG activities (portable printer manufacturers, thermal
transfer-direct thermal printer manufacturers) to let them know about the I=
PP
Anywhere project and the PWG Raster Format, I am in favor of waiting for a
little while to see if we get some interest from the reach out activities
before making a final decision on your request.<=
o:p>



 



If we do get s=
ome
participation from the printer manufacturers outlined above, they might also
find some value in the feature you are requesting so I believe it is a litt=
le
premature to reject the idea of adding the field at this time.=




 



Best Regards,<=
u1:p>



 






--=









Paul Tykodi

Principal Consultant

TCS - Tykodi Consulting Services LLC



Tel/Fax: 603-343-1820

Mobile: 
603-866-0712

E-mail:  ptykodi@tykodi.com

WWW:  http://www.tykodi.com=












From: ipp-bounces@pwg.org
[mailto:ipp-bounces@pwg.org] On Behalf =
Of Petrie,
Glen

Sent: Friday, April 22, 2011=
 3:08
PM

To: Ira McDonald

Cc: ipp@pwg.org

Subject: RE: [IPP] Requested
Additions to PWG Raster









 



Uncle !!!!!!!!!<=
/font>



 



It is an optional field and complete=
ly
testable in an interoperability test.=




 



Glen=




 



 















From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Friday, April 22, 2011=
 11:52
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.org<=
/a>

Subject: Re: [IPP] Requested
Additions to PWG Raster






 



Hi Glen,



I agree with Mike here in objecting to registering these fields.



PWG standards are supposed to only contain fields/attributes

that *could* be tested in an interoperability event.  It's not

plausible that a typical streaming client would know the size 

when it's very large (when the feature's useful), so such a

feature's not interoperable or verifiable.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.com=
/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroofmusic@gmail.com

Christmas through April:

  579 Park Place  Saline, MI  =
48176

  734-944-0094

May to Christmas:

  PO Box 221 
Grand Marais, MI 49839

  906-494-2434



 






On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:









As stated below, I do understand objection to adding the field.
 I would to hear from other PWG members on the addition of these field=
s.



 



Glen



 



 















From: Michael Sweet [mailto:msweet@apple.com] 

Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster









 









On Apr 2=
2, 2011,
at 9:34 AM, Petrie, Glen wrote:





















... 


















[gwp] The important case is the size of the compressed raster d=
ata.
The decompressed size is recorded only if the raster is uncompressed.









[gwp] I agree that some (a few or a lot) of implementation may =
not
provide the information but as I said, I am requesting that the assignment =
be
made and those who can (want to) may record the size information.


















 






It reall=
y isn't a
matter of "may not provide", in most cases clients (and printers)
simply can't buffer hundreds of megabytes of raster data I can add the fiel=
d,
but since most producers of PWG Raster will not be able to supply the
compressed size of the raster no printer will be able to depend on it anywa=
ys,
so IMHO it is best to have the printer, if it is going to do any local
processing of full page images, use its own optimal internal storage format
than try to gerry-rig something into the format that just won't work.=













 



[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging
anything.  I do not understand your comment “that just won’=
;t
work”.  It works fine.  In fact, I wrote a routine that will
find the size-only of compressed page by running the compression routine
without storing the compressed data.  I don’t understand your
objection to assigning the field.



























 



... 












I would =
actually
prefer to flag the file as version 3 which is an uncompressed CUPS Raster w=
ith
the version 2 page header. And in the case of local processing, you'll like=
ly want
to use native word order (another feature of CUPS Raster that we are not
bringing along for PWG Raster...)















 









[gwp] Do you mean big/little-endian?  I am nothing request=
ing
the word ordering flag (value) be used.  The current specification is =
ok.


















 






My main =
point was
that if you are concerned about having a standard representation for
intermediate data, CUPS Raster already provides that. If you are trying to
tweak PWG Raster for use as an internal representation format then I'd rath=
er
not put that in the standard since internal formats are OOS for any PWG
standard.









&n=
bsp;












Would it=
 be
sufficient to document an uncompressed version of PWG Raster (with the
"RAS3" file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?









 









[gwp] I believe the RAS3 is for the entire PWG Raster file.&nbs=
p; I
am requesting a flags (value) for individual pages.  












 















Since th=
e format
does not support this, I would be opposed to adding something that would be
used only for an internal representation of a PWG Raster file.=




 






[gwp] Again, I do not understand your objection. =













 












____________________________________________________=
____________________

Michael Sweet, Senior Printing System Engineer, PWG Chair









 














-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 











_______________________________________________

ipp mailing list

ipp@pwg.o=
rg

=
https://www.pwg.org/mailm=
an/listinfo/ipp






 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 















_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.org/ma=
ilman/listinfo/ipp












--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0354.61AAF92A--

--===============0317227587==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0317227587==--

From pwg-announce-bounces@pwg.org  Mon Apr 25 08:51:42 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6284AE06E8 for ; Mon, 25 Apr 2011 08:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy4Y8CfEWnio for ; Mon, 25 Apr 2011 08:51:41 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 7D7EBE0664 for ; Mon, 25 Apr 2011 08:51:41 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id ED40C79540; Mon, 25 Apr 2011 11:51:25 -0400 (EDT)
X-Original-To: pwg-announce@pwg.org
Delivered-To: pwg-announce@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 9608379533 for ; Mon, 25 Apr 2011 11:51:13 -0400 (EDT)
MIME-version: 1.0
Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK700KYXTC33M21@mail-out.apple.com> for pwg-announce@pwg.org; Mon, 25 Apr 2011 08:51:12 -0700 (PDT)
X-AuditID: 1180711d-b7c70ae00000719a-df-4db5986869b6
Received: from [17.153.44.36] (Unknown_Domain [17.153.44.36]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay13.apple.com (Apple SCV relay) with SMTP id CC.21.29082.E6895BD4; Mon, 25 Apr 2011 08:51:12 -0700 (PDT)
From: Michael Sweet 
Date: Mon, 25 Apr 2011 08:51:02 -0700
To: pwg-announce@pwg.org
Message-id: <041272B0-7E26-42E6-81D0-FEFD02B76C10@apple.com>
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [Pwg-Announce] **4 DAY** PWG May 2011 Face-to-Face Meeting in Webster, NY
X-BeenThere: pwg-announce@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Printer Working Group Announcement List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1565663197=="
Sender: pwg-announce-bounces@pwg.org
Errors-To: pwg-announce-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: ED40C79540.AC69B
X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org

--===============1565663197==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_NOkK/dJgS0ZGbpKiQ+uLdA)"


--Boundary_(ID_NOkK/dJgS0ZGbpKiQ+uLdA)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

All,

The May 2011 PWG face-to-face meeting page is now available. The agenda and venue information can be found at:

	http://www.pwg.org/chair/meeting-info/may_2011_webster.html

NOTE: This meeting is 4 days long to accommodate the amount of material we have to discuss.

This page will be updated with document links as the material becomes available.

Please visit the February 2011 survey page and indicate whether you plan to participate in person or call in:

	http://www.surveymonkey.com/s/T3H2YTC

For those not able to attend in person, the usual telephone bridge number will be provided. The details of the conference call are:

Call-in toll-free number (US/Canada): +1 866 469-3239
Call-in toll number (US/Canada): +1 650 429-3300
Call-in toll number (US/Canada): +1 408 856-9570

Attendee access code: Please request from the PWG Chair (msweet@apple.com) if you need it.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_NOkK/dJgS0ZGbpKiQ+uLdA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


All,

The May 2011 PWG face-to-face meeting page is now available. The a=
genda and venue information can be found at:


NOTE=
: This meeting is 4 days long to accommodate the amount of material we have=
 to discuss.

This page will be updated with docume=
nt links as the material becomes available.

Please=
 visit the February 2011 survey page and indicate whether you plan to parti=
cipate in person or call in:


=

For those not able to attend in person, the usual telephone=
 bridge number will be provided. The details of the conference ca=
ll are:

Call-in toll-free number (US/Canada): +1 866 469-=
3239
Call-in toll number (US/Canada): +1 650 429-3300
Call-in toll nu=
mber (US/Canada): +1 408 856-9570

Attendee access code: P=
lease request from the PWG Chair (mswee=
t@apple.com) if you need it.



______________________________________________________________________=
__
Michael Sweet, Senior Printing System Engineer, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_NOkK/dJgS0ZGbpKiQ+uLdA)--

--===============1565663197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

--===============1565663197==--

From ipp-bounces@pwg.org  Mon Apr 25 09:37:21 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4EAE3E06CC for ; Mon, 25 Apr 2011 09:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErMk1p8YNovR for ; Mon, 25 Apr 2011 09:37:18 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id 3F9E7E06A9 for ; Mon, 25 Apr 2011 09:37:18 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7D0C67954E; Mon, 25 Apr 2011 12:36:56 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id D6C3A79545 for ; Mon, 25 Apr 2011 12:36:39 -0400 (EDT)
MIME-version: 1.0
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK700JDIVE4YD10@mail-out.apple.com> for ipp@pwg.org; Mon, 25 Apr 2011 09:36:39 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-ba-4db5a3165146
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 57.0A.23242.613A5BD4; Mon, 25 Apr 2011 09:36:38 -0700 (PDT)
Subject: Re: [IPP] Requested Additions to PWG Raster
From: Michael Sweet 
In-reply-to: 
Date: Mon, 25 Apr 2011 09:36:38 -0700
Message-id: <6B4A7B70-0DE1-478B-9B27-BB534FF61227@apple.com>
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>      <000001cc0144$e1149c50$a33dd4f0$@tykodi.com>   
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1005082873=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 7D0C67954E.AA32C
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1005082873==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_oQQNiU7TuqPB0DLpSc5QUg)"


--Boundary_(ID_oQQNiU7TuqPB0DLpSc5QUg)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

On Apr 25, 2011, at 7:23 AM, Petrie, Glen wrote:
> Doesn=92t =93using them for PWG Raster=94 make the CUPS and PWG raster in=
compatible?

Not at all. All of the cupsInteger, cupsReal, and cupsString fields are dri=
ver-specific use. In this case the "driver" is the generic IPP Everywhere/P=
WG Raster path.

> I believe the current fields for proposed to use the driver-specific same=
 are not needed.
>=20=20
> 1. =93total number of pages=94

Given that many existing CUPS Raster drivers want this information, I think=
 this is at least useful information to expose (when available).

> 2. HorizontalTransform
> 3. VerticalTransform

These *are* necessary if the raster data could be consumed by a different i=
maging device than originally targeted (likely in the Cloud case).

> The Job Ticket will specify the output format (duplex, flip, rotate); the=
refore, transforms data and information are part of the Job Ticket and the =
raster must be transformed to the correct orientation required so that the =
printer (or any consumer of the raster) does not know or have to perform th=
e transforms.

The transform information for back sides are not exposed in job tickets, on=
ly as printer description attributes for clients who are generating the ras=
ter data. The assumption (and conformance requirement) is that the client w=
ill produce raster data in a supported color space, bit depth, resolution, =
dimensions, and coordinate space - this doesn't require the transform infor=
mation in the header.

However, there are two specific use cases where that information may be nec=
essary:

1. For fan-out devices, the IPP Printer may need to do transforms on the PW=
G Raster data to make it suitable for any of the devices.
2. For Cloud Printing the Cloud Imaging Provider may need to do transforms =
on the PWG Raster data to make it suitable for the Cloud Imaging Manager.

Since the transform information is not in the job ticket, does not express =
intent (i.e. all job template attributes tell you how to print a job - any =
descriptive elements are sent as operation attributes), and since that tran=
sform information is specific to PWG Raster documents, it makes sense to pu=
t the transform information in the PWG Raster document.


>  Raster data means the data is rastered-out and should not require additi=
onal transforms (scaling might be an exception); the transforms here may re=
quire the printer to have rotation buffers which could be large and expensi=
ve to implement; not desirable.
>=20=20
> Therefore, I am opposed to adding the specific PWR element for Horizontal=
 and Vertical Transform.  If a vendor which to use transforms, then it is p=
art of their driver specific information but not an official PWG Raster ele=
ment.
>=20=20
> The same logic applies to the total number of page.
>=20=20
> Thus, not officially specifying the elements above or any new elements in=
 the driver data space continues to make CUPS and PWG raster 100% compatibl=
e but allow drivers (vendors) to add them and other data as they deem neces=
sary.
>=20=20
>=20=20
> Glen
>=20=20
>=20=20
> From: Mike Sweet [mailto:msweet@apple.com]=20
> Sent: Monday, April 25, 2011 6:51 AM
> To: Petrie, Glen
> Cc: ptykodi@tykodi.com; ipp@pwg.org
> Subject: Re: [IPP] Requested Additions to PWG Raster
>=20=20
> I can add them, with the caveat that some of the cupsInteger fields will =
be used for PWG Raster.
>=20
>=20
> Sent from my iPad
>=20
> On Apr 25, 2011, at 6:28 AM, "Petrie, Glen"  =
wrote:
>=20
>> Paul,
>>=20=20
>> I would like to change my request to the following
>>=20=20
>> I would like to request that that 16 integer, 16 floating point and 16 s=
tring that are denoted in CUPS raster as driver-defined be added to the PWG=
 raster.
>>=20=20
>> I realize it is a mute point for this request since the data elements ar=
e already reserved in CUPS raster and, as such, are by defacto, inherited b=
y the PWG raster (even if in the shadow or not specifically declared) as lo=
ng as the PWG raster maintains 100% compatible with CUPS raster.
>>=20=20
>> These fields do not jerry-rig additions to either the CUPS or PWG raster=
 since they are already defined by CUPS.
>> These fields do not cause any interpretability testing issues since they=
 are driver specific information.
>>=20=20
>> Glen
>>=20=20
>>=20=20
>> From: Paul Tykodi [mailto:ptykodi@tykodi.com]=20
>> Sent: Friday, April 22, 2011 4:28 PM
>> To: Petrie, Glen
>> Cc: ipp@pwg.org; 'Ira McDonald'; msweet@apple.com
>> Subject: RE: [IPP] Requested Additions to PWG Raster
>>=20=20
>> Hi Glen,
>>=20=20
>> Where we are currently reaching out to some printer manufacturers who ha=
ve previously not participated in PWG activities (portable printer manufact=
urers, thermal transfer-direct thermal printer manufacturers) to let them k=
now about the IPP Anywhere project and the PWG Raster Format, I am in favor=
 of waiting for a little while to see if we get some interest from the reac=
h out activities before making a final decision on your request.
>>=20=20
>> If we do get some participation from the printer manufacturers outlined =
above, they might also find some value in the feature you are requesting so=
 I believe it is a little premature to reject the idea of adding the field =
at this time.
>>=20=20
>> Best Regards,
>>=20=20
>> --
>> Paul Tykodi
>> Principal Consultant
>> TCS - Tykodi Consulting Services LLC
>>=20
>> Tel/Fax: 603-343-1820
>> Mobile:  603-866-0712
>> E-mail:  ptykodi@tykodi.com
>> WWW:  http://www.tykodi.com
>> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petr=
ie, Glen
>> Sent: Friday, April 22, 2011 3:08 PM
>> To: Ira McDonald
>> Cc: ipp@pwg.org
>> Subject: RE: [IPP] Requested Additions to PWG Raster
>>=20=20
>> Uncle !!!!!!!!!
>>=20=20
>> It is an optional field and completely testable in an interoperability t=
est.
>>=20=20
>> Glen
>>=20=20
>>=20=20
>> From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
>> Sent: Friday, April 22, 2011 11:52 AM
>> To: Petrie, Glen; Ira McDonald
>> Cc: Michael Sweet; ipp@pwg.org
>> Subject: Re: [IPP] Requested Additions to PWG Raster
>>=20=20
>> Hi Glen,
>>=20
>> I agree with Mike here in objecting to registering these fields.
>>=20
>> PWG standards are supposed to only contain fields/attributes
>> that *could* be tested in an interoperability event.  It's not
>> plausible that a typical streaming client would know the size=20
>> when it's very large (when the feature's useful), so such a
>> feature's not interoperable or verifiable.
>>=20
>> Cheers,
>> - Ira
>>=20
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Co-Chair - IEEE-ISTO PWG IPP WG
>> Co-Chair - TCG Hardcopy WG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music/High North Inc
>> http://sites.google.com/site/blueroofmusic
>> http://sites.google.com/site/highnorthinc
>> mailto:blueroofmusic@gmail.com
>> Christmas through April:
>>   579 Park Place  Saline, MI  48176
>>   734-944-0094
>> May to Christmas:
>>   PO Box 221  Grand Marais, MI 49839
>>   906-494-2434
>>=20=20
>>=20
>> On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen  wrote:
>> As stated below, I do understand objection to adding the field.  I would=
 to hear from other PWG members on the addition of these fields.
>>=20=20
>> Glen
>>=20=20
>>=20=20
>> From: Michael Sweet [mailto:msweet@apple.com]=20
>> Sent: Friday, April 22, 2011 10:20 AM
>> To: Petrie, Glen
>> Cc: ipp@pwg.org
>> Subject: Re: [IPP] Requested Additions to PWG Raster
>>=20=20
>> On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:
>> ...=20
>> [gwp] The important case is the size of the compressed raster data. The =
decompressed size is recorded only if the raster is uncompressed.
>> [gwp] I agree that some (a few or a lot) of implementation may not provi=
de the information but as I said, I am requesting that the assignment be ma=
de and those who can (want to) may record the size information.
>>=20=20
>> It really isn't a matter of "may not provide", in most cases clients (an=
d printers) simply can't buffer hundreds of megabytes of raster data I can =
add the field, but since most producers of PWG Raster will not be able to s=
upply the compressed size of the raster no printer will be able to depend o=
n it anyways, so IMHO it is best to have the printer, if it is going to do =
any local processing of full page images, use its own optimal internal stor=
age format than try to gerry-rig something into the format that just won't =
work.
>>=20=20
>> [gwp] As I stated in my original request, I am not worried about the pri=
nter, it will accept the streaming input just fine.  I want the size inform=
ation for navigation of a many page raster without having to decompress pag=
es in a serial manor.   I am not jerry-rigging anything.  I do not understa=
nd your comment =93that just won=92t work=94.  It works fine.  In fact, I w=
rote a routine that will find the size-only of compressed page by running t=
he compression routine without storing the compressed data.  I don=92t unde=
rstand your objection to assigning the field.
>>=20=20
>> ...=20
>> I would actually prefer to flag the file as version 3 which is an uncomp=
ressed CUPS Raster with the version 2 page header. And in the case of local=
 processing, you'll likely want to use native word order (another feature o=
f CUPS Raster that we are not bringing along for PWG Raster...)
>>=20=20
>> [gwp] Do you mean big/little-endian?  I am nothing requesting the word o=
rdering flag (value) be used.  The current specification is ok.
>>=20=20
>> My main point was that if you are concerned about having a standard repr=
esentation for intermediate data, CUPS Raster already provides that. If you=
 are trying to tweak PWG Raster for use as an internal representation forma=
t then I'd rather not put that in the standard since internal formats are O=
OS for any PWG standard.
>>=20=20
>>=20
>> Would it be sufficient to document an uncompressed version of PWG Raster=
 (with the "RAS3" file header) and then mark the native word order support =
as out-of-scope for the spec but something that might be used internally?
>>=20=20
>> [gwp] I believe the RAS3 is for the entire PWG Raster file.  I am reques=
ting a flags (value) for individual pages.=20=20
>>=20=20
>> Since the format does not support this, I would be opposed to adding som=
ething that would be used only for an internal representation of a PWG Rast=
er file.
>>=20=20
>> [gwp] Again, I do not understand your objection.
>>=20=20
>> ________________________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>=20=20
>>=20
>> --=20
>> This message has been scanned for viruses and=20
>> dangerous content by MailScanner, and is=20
>> believed to be clean.
>>=20
>> _______________________________________________
>> ipp mailing list
>> ipp@pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp
>>=20
>>=20=20
>>=20
>> --=20
>> This message has been scanned for viruses and=20
>> dangerous content by MailScanner, and is=20
>> believed to be clean.
>>=20
>> --=20
>> This message has been scanned for viruses and=20
>> dangerous content by MailScanner, and is=20
>> believed to be clean.
>> _______________________________________________
>> ipp mailing list
>> ipp@pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_oQQNiU7TuqPB0DLpSc5QUg)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


On Apr 25, 2011,=
 at 7:23 AM, Petrie, Glen wrote:















Doesn=92t =93using them for PWG
Raster=94 make the CUPS and PWG raster incompatible?
=


Not at all. A=
ll of the cupsInteger, cupsReal, and cupsString fields are driver-specific =
use. In this case the "driver" is the generic IPP Everywhere/PWG Raster pat=
h.

<=
div class=3D"Section1">
I believe the c=
urrent fields for
proposed to use the driver-specific same are not needed.
 
<=
p class=3D"MsoNormal">1. =93total number of pages=94 

<=
/div>Given that many existing CUPS Raster drivers want this information, I =
think this is at least useful information to expose (when available).
=


2. HorizontalTransform
3. VerticalTransform <=
/p>

These=
 *are* necessary if the raster data could be consumed by a different imagin=
g device than originally targeted (likely in the Cloud case).
The Job Ticket will specify the output format
(duplex, flip, rotate); therefore, transforms data and information are part=
 of
the Job Ticket and the raster must be transformed to the correct orientatio=
n required
so that the printer (or any consumer of the raster) does not know or have t=
o perform
the transforms.

The transform information for back sides are not exposed =
in job tickets, only as printer description attributes for clients who are =
generating the raster data. The assumption (and conformance requirement) is=
 that the client will produce raster data in a supported color space, bit d=
epth, resolution, dimensions, and coordinate space - this doesn't require t=
he transform information in the header.

However, t=
here are two specific use cases where that information may be necessary:

1. For fan-out devices, the IPP Printer may need to =
do transforms on the PWG Raster data to make it suitable for any of the dev=
ices.
2. For Cloud Printing the Cloud Imaging Provider may n=
eed to do transforms on the PWG Raster data to make it suitable for the Clo=
ud Imaging Manager.

Since the transform informatio=
n is not in the job ticket, does not express intent (i.e. all job template =
attributes tell you how to print a job - any descriptive elements are sent =
as operation attributes), and since that transform information is specific =
to PWG Raster documents, it makes sense to put the transform information in=
 the PWG Raster document.


=

  Raster data means the data is rastered-out and should not
require additional transforms (scaling might be an exception); the transfor=
ms
here may require the printer to have rotation buffers which could be large =
and
expensive to implement; not desirable.
 
<=
p class=3D"MsoNormal">Therefore, I am opposed to adding the
specific PWR element for Horizontal and Vertical Transform.  If a vend=
or
which to use transforms, then it is part of their driver specific informati=
on
but not an official PWG Raster element.
 
<=
p class=3D"MsoNormal">The same logic applies to the total
number of page.
 
<=
p class=3D"MsoNormal">Thus, not officially specifying the
elements above or any new elements in the driver data space continues to ma=
ke
CUPS and PWG raster 100% compatible but allow drivers (vendors) to add them=
 and
other data as they deem necessary.
 
<=
p class=3D"MsoNormal"> 
<=
p class=3D"MsoNormal">Glen
 
<=
p class=3D"MsoNormal"> 












From: Mike=
 Sweet
[mailto:msweet@apple.com] 

Sent: Monday, April 25, 2011=
 6:51
AM

To: Petrie, Glen

Cc: ptykodi@tykodi.com;
ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster



 



I can add them, with the caveat that some of the cupsInteger fields
will be used for PWG Raster.










Sent from my iPad








On Apr 25, 2011, at 6:28 AM, "Petrie, Glen" <glen.petrie@eitc.epson.com>
wrote:









Paul,
 
I would like to change my request to=
 the
following
<=
font size=3D"3" color=3D"blue" face=3D"Cambria"> 
I would like to request that that 16
integer, 16 floating point and 16 string that are denoted in CUPS raster as
driver-defined be added to the PWG raster.<=
/o:p>
 
I realize it is a mute point for this
request since the data elements are already reserved in CUPS raster and, as
such, are by defacto, inherited by the PWG raster (even if in the shadow or=
 not
specifically declared) as long as the PWG raster maintains 100% compatible =
with
CUPS raster.
 
These fields do not jerry-rig additi=
ons
to either the CUPS or PWG raster since they are already defined by CUPS.
These fields do not cause any
interpretability testing issues since they are driver specific information.=

 
Glen=

 
 












From: Paul=
 Tykodi
[mailto:ptykodi@tykodi.com] 

Sent: Friday, April 22, 2011=
 4:28
PM

To: Petrie, Glen

Cc: ipp@pwg.org;
'Ira McDonald'; msweet@apple.com

Subject: RE: [IPP] Requested
Additions to PWG Raster



 
Hi Glen,
 
Where we are
currently reaching out to some printer manufacturers who have previously not
participated in PWG activities (portable printer manufacturers, thermal
transfer-direct thermal printer manufacturers) to let them know about the I=
PP
Anywhere project and the PWG Raster Format, I am in favor of waiting for a
little while to see if we get some interest from the reach out activities
before making a final decision on your request.<=
o:p>
 
If we do get some
participation from the printer manufacturers outlined above, they might also
find some value in the feature you are requesting so I believe it is a litt=
le
premature to reject the idea of adding the field at this time.=

 
Best Regards,=

 



--






Paul Tykodi

Principal Consultant

TCS - Tykodi Consulting Services LLC



Tel/Fax: 603-343-1820

Mobile: 
603-866-0712

E-mail:  ptykodi@tykodi.com

WWW:  htt=
p://www.tykodi.com








From: ipp-bounces@pwg.org
[mailto:ipp-bounces@pwg.org] On Behalf =
Of Petrie,
Glen

Sent: Friday, April 22, 2011=
 3:08
PM

To: Ira McDonald

Cc: ipp@pwg.org

Subject: RE: [IPP] Requested
Additions to PWG Raster






 
Uncle !!!!!!!!!<=
/font>
 
It is an optional field and complete=
ly
testable in an interoperability test.=

 
Glen=

 
 












From: Ira =
McDonald
[mailto:blueroofmusic@gmail.com] 

Sent: Friday, April 22, 2011=
 11:52
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.org<=
br>
Subject: Re: [IPP] Requested
Additions to PWG Raster



 
Hi Glen,



I agree with Mike here in objecting to registering these fields.



PWG standards are supposed to only contain fields/attributes

that *could* be tested in an interoperability event.  It's not

plausible that a typical streaming client would know the size 

when it's very large (when the feature's useful), so such a

feature's not interoperable or verifiable.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.googl=
e.com/site/blueroofmusic

http://sites.google.com/=
site/highnorthinc

mailto:blueroofmusic@gmail.com

Christmas through April:

  579 Park Place  Saline, MI  48176

  734-944-0094

May to Christmas:

  PO Box 221 
Grand Marais, MI 49839

  906-494-2434
 



On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <glen.petrie@eitc.epson.com>
wrote:






As stated below, I do understand objection to adding the field.
 I would to hear from other PWG members on the addition of these field=
s.
 
Glen
 
 












From: Michael Sweet [mailto:msweet=
@apple.com] 

Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org=


Subject: Re: [IPP] Requested
Additions to PWG Raster






 






On Apr 22, 2011,
at 9:34 AM, Petrie, Glen wrote:


















... 















[gwp] The important case is the size of the compressed raster d=
ata.
The decompressed size is recorded only if the raster is uncompressed.






[gwp] I agree that some (a few or a lot) of implementation may =
not
provide the information but as I said, I am requesting that the assignment =
be
made and those who can (want to) may record the size information.















 



It really isn't a
matter of "may not provide", in most cases clients (and printers)
simply can't buffer hundreds of megabytes of raster data I can add the fiel=
d,
but since most producers of PWG Raster will not be able to supply the
compressed size of the raster no printer will be able to depend on it anywa=
ys,
so IMHO it is best to have the printer, if it is going to do any local
processing of full page images, use its own optimal internal storage format
than try to gerry-rig something into the format that just won't work.=










 
[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging
anything.  I do not understand your comment =93that just won=92t
work=94.  It works fine.  In fact, I wrote a routine that will
find the size-only of compressed page by running the compression routine
without storing the compressed data.  I don=92t understand your
objection to assigning the field.
























 
... 









I would actually
prefer to flag the file as version 3 which is an uncompressed CUPS Raster w=
ith
the version 2 page header. And in the case of local processing, you'll like=
ly want
to use native word order (another feature of CUPS Raster that we are not
bringing along for PWG Raster...)












 






[gwp] Do you mean big/little-endian?  I am nothing request=
ing
the word ordering flag (value) be used.  The current specification is =
ok.















 



My main point was
that if you are concerned about having a standard representation for
intermediate data, CUPS Raster already provides that. If you are trying to
tweak PWG Raster for use as an internal representation format then I'd rath=
er
not put that in the standard since internal formats are OOS for any PWG
standard.






 









Would it be
sufficient to document an uncompressed version of PWG Raster (with the
"RAS3" file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?






 






[gwp] I believe the RAS3 is for the entire PWG Raster file.&nbs=
p; I
am requesting a flags (value) for individual pages.  









 












Since the format
does not support this, I would be opposed to adding something that would be
used only for an internal representation of a PWG Raster file.=

 



[gwp] Again, I do not understand your objection. =










 









____________________________________________________=
____________________

Michael Sweet, Senior Printing System Engineer, PWG Chair






 











-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is=
 

believed to be clean. 








_______________________________________________

ipp mailing list

ipp@pwg.o=
rg

=
https://www.pwg.org/ma=
ilman/listinfo/ipp



 


-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 


-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 












_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.org/ma=
ilman/listinfo/ipp



















_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_oQQNiU7TuqPB0DLpSc5QUg)--

--===============1005082873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1005082873==--

From ipp-bounces@pwg.org  Mon Apr 25 09:46:29 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfc.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B1BCE075B for ; Mon, 25 Apr 2011 09:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level: 
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYQFYvXgT04V for ; Mon, 25 Apr 2011 09:46:18 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfc.amsl.com (Postfix) with ESMTP id A35CBE0749 for ; Mon, 25 Apr 2011 09:46:18 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 68C1979552; Mon, 25 Apr 2011 12:45:37 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 7D3227954E for ; Mon, 25 Apr 2011 12:45:17 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 25 Apr 2011 09:45:17 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Mon, 25 Apr 2011 09:45:16 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] Requested Additions to PWG Raster
Thread-Index: AcwDZvcF6DS8OVtmS9We8/XYrmktFAAABU/w
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>      <000001cc0144$e1149c50$a33dd4f0$@tykodi.com>    <6B4A7B70-0DE1-478B-9B27-BB534FF61227@apple.com>
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 25 Apr 2011 16:45:17.0161 (UTC) FILETIME=[28209D90:01CC0368]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0818000870=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 68C1979552.AAAF0
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0818000870==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0368.27A497F9"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0368.27A497F9
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

	Doesn't "using them for PWG Raster" make the CUPS and PWG raster
incompatible?

=20

Not at all. All of the cupsInteger, cupsReal, and cupsString fields are
driver-specific use. In this case the "driver" is the generic IPP
Everywhere/PWG Raster path.

=20

[gwp] What, this is the very definition of incompatibility;  I a devices
receives a CUPS raster file with some vendor-data in the position of the
page number and it does not represent the page number then no telling
what will happen.

[gwp] If you change the PWG raster file identifier so it does not match
CUPS raster then is this not produce a conflict; because they would not
longer be the same thing.  Right now, no one reading a CUPS raster or
PWG raster change tell which is which.

=20

	I believe the current fields for proposed to use the
driver-specific same are not needed.

=09=20

	1. "total number of pages"=20

=20

Given that many existing CUPS Raster drivers want this information, I
think this is at least useful information to expose (when available).





2. HorizontalTransform

3. VerticalTransform=20

=20

These *are* necessary if the raster data could be consumed by a
different imaging device than originally targeted (likely in the Cloud
case).

=20

[gwp] I disagree.  You mean that your/the proposed Job Ticket does have
the duplex setting or the layout orientation data.  If not, how can
someone ever generate the correct print output!!!=20





The Job Ticket will specify the output format (duplex, flip, rotate);
therefore, transforms data and information are part of the Job Ticket
and the raster must be transformed to the correct orientation required
so that the printer (or any consumer of the raster) does not know or
have to perform the transforms.

=20

The transform information for back sides are not exposed in job tickets,
only as printer description attributes for clients who are generating
the raster data. The assumption (and conformance requirement) is that
the client will produce raster data in a supported color space, bit
depth, resolution, dimensions, and coordinate space - this doesn't
require the transform information in the header.

=20

However, there are two specific use cases where that information may be
necessary:

=20

1. For fan-out devices, the IPP Printer may need to do transforms on the
PWG Raster data to make it suitable for any of the devices.

2. For Cloud Printing the Cloud Imaging Provider may need to do
transforms on the PWG Raster data to make it suitable for the Cloud
Imaging Manager.

=20

Since the transform information is not in the job ticket, does not
express intent (i.e. all job template attributes tell you how to print a
job - any descriptive elements are sent as operation attributes), and
since that transform information is specific to PWG Raster documents, it
makes sense to put the transform information in the PWG Raster document.

=20





 Raster data means the data is rastered-out and should not require
additional transforms (scaling might be an exception); the transforms
here may require the printer to have rotation buffers which could be
large and expensive to implement; not desirable.

=20

Therefore, I am opposed to adding the specific PWR element for
Horizontal and Vertical Transform.  If a vendor which to use transforms,
then it is part of their driver specific information but not an official
PWG Raster element.

=20

The same logic applies to the total number of page.

=20

Thus, not officially specifying the elements above or any new elements
in the driver data space continues to make CUPS and PWG raster 100%
compatible but allow drivers (vendors) to add them and other data as
they deem necessary.

=20

=20

Glen

=20

=20

________________________________

From: Mike Sweet [mailto:msweet@apple.com]=20
Sent: Monday, April 25, 2011 6:51 AM
To: Petrie, Glen
Cc: ptykodi@tykodi.com; ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

I can add them, with the caveat that some of the cupsInteger fields will
be used for PWG Raster.



Sent from my iPad


On Apr 25, 2011, at 6:28 AM, "Petrie, Glen" 
wrote:

	Paul,

=09=20

	I would like to change my request to the following

=09=20

	I would like to request that that 16 integer, 16 floating point
and 16 string that are denoted in CUPS raster as driver-defined be added
to the PWG raster.

=09=20

	I realize it is a mute point for this request since the data
elements are already reserved in CUPS raster and, as such, are by
defacto, inherited by the PWG raster (even if in the shadow or not
specifically declared) as long as the PWG raster maintains 100%
compatible with CUPS raster.

=09=20

	These fields do not jerry-rig additions to either the CUPS or
PWG raster since they are already defined by CUPS.

	These fields do not cause any interpretability testing issues
since they are driver specific information.

=09=20

	Glen

=09=20

=09=20

=09
________________________________


	From: Paul Tykodi [mailto:ptykodi@tykodi.com]=20
	Sent: Friday, April 22, 2011 4:28 PM
	To: Petrie, Glen
	Cc: ipp@pwg.org; 'Ira McDonald'; 
msweet@apple.com
	Subject: RE: [IPP] Requested Additions to PWG Raster

=09=20

	Hi Glen,

=09=20

	Where we are currently reaching out to some printer
manufacturers who have previously not participated in PWG activities
(portable printer manufacturers, thermal transfer-direct thermal printer
manufacturers) to let them know about the IPP Anywhere project and the
PWG Raster Format, I am in favor of waiting for a little while to see if
we get some interest from the reach out activities before making a final
decision on your request.

=09=20

	If we do get some participation from the printer manufacturers
outlined above, they might also find some value in the feature you are
requesting so I believe it is a little premature to reject the idea of
adding the field at this time.

=09=20

	Best Regards,

=09=20

	--

	Paul Tykodi
	Principal Consultant
	TCS - Tykodi Consulting Services LLC
=09
	Tel/Fax: 603-343-1820
	Mobile:  603-866-0712
	E-mail:   ptykodi@tykodi.com
	WWW:  http://www.tykodi.com =20

	From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf
Of Petrie, Glen
	Sent: Friday, April 22, 2011 3:08 PM
	To: Ira McDonald
	Cc:  ipp@pwg.org
	Subject: RE: [IPP] Requested Additions to PWG Raster

=09=20

	Uncle !!!!!!!!!

=09=20

	It is an optional field and completely testable in an
interoperability test.

=09=20

	Glen

=09=20

=09=20

=09
________________________________


	From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
	Sent: Friday, April 22, 2011 11:52 AM
	To: Petrie, Glen; Ira McDonald
	Cc: Michael Sweet;  ipp@pwg.org
	Subject: Re: [IPP] Requested Additions to PWG Raster

=09=20

	Hi Glen,
=09
	I agree with Mike here in objecting to registering these fields.
=09
	PWG standards are supposed to only contain fields/attributes
	that *could* be tested in an interoperability event.  It's not
	plausible that a typical streaming client would know the size=20
	when it's very large (when the feature's useful), so such a
	feature's not interoperable or verifiable.
=09
	Cheers,
	- Ira
=09
	Ira McDonald (Musician / Software Architect)
	Chair - Linux Foundation Open Printing WG
	Co-Chair - IEEE-ISTO PWG IPP WG
	Co-Chair - TCG Hardcopy WG
	IETF Designated Expert - IPP & Printer MIB
	Blue Roof Music/High North Inc
	
http://sites.google.com/site/blueroofmusic
	http://sites.google.com/site/highnorthinc
=20
	mailto:  blueroofmusic@gmail.com
	Christmas through April:
	  579 Park Place  Saline, MI  48176
	  734-944-0094
	May to Christmas:
	  PO Box 221  Grand Marais, MI 49839
	  906-494-2434

=09=20

	On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <
 glen.petrie@eitc.epson.com> wrote:

	As stated below, I do understand objection to adding the field.
I would to hear from other PWG members on the addition of these fields.

=09=20

	Glen

=09=20

=09=20

=09
________________________________


	From: Michael Sweet [mailto: 
msweet@apple.com]=20
	Sent: Friday, April 22, 2011 10:20 AM
	To: Petrie, Glen
	Cc:  ipp@pwg.org
	Subject: Re: [IPP] Requested Additions to PWG Raster

=09=20

	On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:

		...=20

		[gwp] The important case is the size of the compressed
raster data. The decompressed size is recorded only if the raster is
uncompressed.

		[gwp] I agree that some (a few or a lot) of
implementation may not provide the information but as I said, I am
requesting that the assignment be made and those who can (want to) may
record the size information.

=09=20

	It really isn't a matter of "may not provide", in most cases
clients (and printers) simply can't buffer hundreds of megabytes of
raster data I can add the field, but since most producers of PWG Raster
will not be able to supply the compressed size of the raster no printer
will be able to depend on it anyways, so IMHO it is best to have the
printer, if it is going to do any local processing of full page images,
use its own optimal internal storage format than try to gerry-rig
something into the format that just won't work.

=09=20

	[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging anything.
I do not understand your comment "that just won't work".  It works fine.
In fact, I wrote a routine that will find the size-only of compressed
page by running the compression routine without storing the compressed
data.  I don't understand your objection to assigning the field.

=09=09=20

		...=20

		I would actually prefer to flag the file as version 3
which is an uncompressed CUPS Raster with the version 2 page header. And
in the case of local processing, you'll likely want to use native word
order (another feature of CUPS Raster that we are not bringing along for
PWG Raster...)

=09=09=20

		[gwp] Do you mean big/little-endian?  I am nothing
requesting the word ordering flag (value) be used.  The current
specification is ok.

=09=20

	My main point was that if you are concerned about having a
standard representation for intermediate data, CUPS Raster already
provides that. If you are trying to tweak PWG Raster for use as an
internal representation format then I'd rather not put that in the
standard since internal formats are OOS for any PWG standard.

=09=20

	Would it be sufficient to document an uncompressed version of
PWG Raster (with the "RAS3" file header) and then mark the native word
order support as out-of-scope for the spec but something that might be
used internally?

=09=20

	[gwp] I believe the RAS3 is for the entire PWG Raster file.  I
am requesting a flags (value) for individual pages.=20=20

=09=20

	Since the format does not support this, I would be opposed to
adding something that would be used only for an internal representation
of a PWG Raster file.

=09=20

	[gwp] Again, I do not understand your objection.=20

=09=20

=09
________________________________________________________________________
	Michael Sweet, Senior Printing System Engineer, PWG Chair

=09=20

=09
	--=20
	This message has been scanned for viruses and=20
	dangerous content by MailScanner 
, and is=20
	believed to be clean.=20

=09
	_______________________________________________
	ipp mailing list
	 ipp@pwg.org
	
https://www.pwg.org/mailman/listinfo/ipp

=09=20

=09
	--=20
	This message has been scanned for viruses and=20
	dangerous content by MailScanner 
, and is=20
	believed to be clean.=20

=09
	--=20
	This message has been scanned for viruses and=20
	dangerous content by MailScanner 
, and is=20
	believed to be clean.=20

	_______________________________________________
	ipp mailing list
	ipp@pwg.org
	https://www.pwg.org/mailman/listinfo/ipp

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0368.27A497F9
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable























 












Doesn’t “using them for =
PWG Raster” make
the CUPS and PWG raster incompatible?












 








Not at all. All of the cupsInteger, cupsReal, and cupsString fields=
 are
driver-specific use. In this case the "driver" is the generic IPP
Everywhere/PWG Raster path.









<=
span
style=3D'font-size:12.0pt;color:blue'> 



[gwp] What, this is the very definit=
ion
of incompatibility;  I a devices receives a CUPS raster file with some
vendor-data in the position of the page number and it does not represent the
page number then no telling what will happen.



[gwp] If you change the PWG raster f=
ile
identifier so it does not match CUPS raster then is this not produce a
conflict; because they would not longer be the same thing.  Right now,=
 no one
reading a CUPS raster or PWG raster change tell which is which.<=
/span>



 















I
believe the current fields for proposed to use the driver-specific same are=
 not
needed.



 



1. “total number of pages̶=
1; 












 








Given that many existing CUPS Raster drivers want this information,=
 I
think this is at least useful information to expose (when available).<=
/o:p>






















2. HorizontalTransform<=
/span>



3. VerticalTransform <=
o:p>









 








These *are* necessary if the raster data could be consumed by a dif=
ferent
imaging device than originally targeted (likely in the Cloud case).









<=
span
style=3D'font-size:12.0pt;color:blue'> 



[gwp] I disagree.  You mean tha=
t your/the
proposed Job Ticket does have the duplex setting or the layout orientation =
data.
 If not, how can someone ever generate the correct print output!!! 
















The
Job Ticket will specify the output format (duplex, flip, rotate); therefore,
transforms data and information are part of the Job Ticket and the raster m=
ust
be transformed to the correct orientation required so that the printer (or =
any
consumer of the raster) does not know or have to perform the transforms.









 








The transform information for back sides are not exposed in job
tickets, only as printer description attributes for clients who are generat=
ing
the raster data. The assumption (and conformance requirement) is that the
client will produce raster data in a supported color space, bit depth,
resolution, dimensions, and coordinate space - this doesn't require the
transform information in the header.









 









However, there are two specific use cases where that information ma=
y be
necessary:









 









1. For fan-out devices, the IPP Printer may need to do transforms on
the PWG Raster data to make it suitable for any of the devices.<=
/span>









2. For Cloud Printing the Cloud Imaging Provider may need to do
transforms on the PWG Raster data to make it suitable for the Cloud Imaging
Manager.









 









Since the transform information is not in the job ticket, does not
express intent (i.e. all job template attributes tell you how to print a jo=
b -
any descriptive elements are sent as operation attributes), and since that
transform information is specific to PWG Raster documents, it makes sense to
put the transform information in the PWG Raster document.=










 






















 Raster
data means the data is rastered-out and should not require additional
transforms (scaling might be an exception); the transforms here may require=
 the
printer to have rotation buffers which could be large and expensive to
implement; not desirable.



 



Therefore, I am opposed to adding the
specific PWR element for Horizontal and Vertical Transform.  If a vend=
or
which to use transforms, then it is part of their driver specific informati=
on
but not an official PWG Raster element.



 



The same logic applies to the total
number of page.



 



Thus, not officially specifying the
elements above or any new elements in the driver data space continues to ma=
ke
CUPS and PWG raster 100% compatible but allow drivers (vendors) to add them=
 and
other data as they deem necessary.



 



 



Glen=




 



 















From: Mike Swe=
et
[mailto:msweet@apple.com] 

Sent: Monday, April 25, 2011=
 6:51
AM

To: Petrie, Glen

Cc: ptykodi@tykodi.com; ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster






 






I can add them, with the caveat that some of the cupsInteger fields
will be used for PWG Raster.













Sent from my iPad











On Apr 25, 2011, at 6:28 AM, "Petrie, Glen" <glen.petrie@eitc.epson.com&g=
t;
wrote:












Paul,<=
/p>


 



I would like to change my request to=
 the
following



 



I would like to request that that 16
integer, 16 floating point and 16 string that are denoted in CUPS raster as
driver-defined be added to the PWG raster.=




 



I realize it is a mute point for this
request since the data elements are already reserved in CUPS raster and, as
such, are by defacto, inherited by the PWG raster (even if in the shadow or=
 not
specifically declared) as long as the PWG raster maintains 100% compatible =
with
CUPS raster.



 



These fields do not jerry-rig additi=
ons
to either the CUPS or PWG raster since they are already defined by CUPS.



These fields do not cause any
interpretability testing issues since they are driver specific information.=




 



Glen



 



 















From: Paul Tyk=
odi
[mailto:ptykodi@tykodi.com] 

Sent: Friday, April 22, 2011=
 4:28
PM

To: Petrie, Glen

Cc: ipp@pwg.org;
'Ira McDonald'; msweet@apple.com

Subject: RE: [IPP] Requested
Additions to PWG Raster<=
/p>





 



Hi Glen,=




 



Where we are
currently reaching out to some printer manufacturers who have previously not
participated in PWG activities (portable printer manufacturers, thermal
transfer-direct thermal printer manufacturers) to let them know about the I=
PP
Anywhere project and the PWG Raster Format, I am in favor of waiting for a
little while to see if we get some interest from the reach out activities
before making a final decision on your request.<=
u1:p>



 



If we do get s=
ome
participation from the printer manufacturers outlined above, they might also
find some value in the feature you are requesting so I believe it is a litt=
le
premature to reject the idea of adding the field at this time.=




 



Best Regards,<=
u4:p>



 






--=









Paul Tykodi

Principal Consultant

TCS - Tykodi Consulting Services LLC



Tel/Fax: 603-343-1820

Mobile: 
603-866-0712

E-mail:  ptykodi@tykodi.com

WWW:  http://www.tykodi.com=












From: ipp-bounces@pwg.org
[mailto:ipp-bounces@pwg.org] On Behalf =
Of Petrie,
Glen

Sent: Friday, April 22, 2011=
 3:08
PM

To: Ira McDonald

Cc: ipp@pwg.org

Subject: RE: [IPP] Requested
Additions to PWG Raster<=
/p>








 



Uncle !!!!!!!!!<=
/font>



 



It is an optional field and complete=
ly
testable in an interoperability test.



 



Glen



 



 















From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Friday, April 22, 2011=
 11:52
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.org<=
/a>

Subject: Re: [IPP] Requested
Additions to PWG Raster<=
/p>





 



Hi Glen,



I agree with Mike here in objecting to registering these fields.



PWG standards are supposed to only contain fields/attributes

that *could* be tested in an interoperability event.  It's not

plausible that a typical streaming client would know the size 

when it's very large (when the feature's useful), so such a

feature's not interoperable or verifiable.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.com=
/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroofmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline=
,
 MI<=
/st1:state> 
 48176

  734-944-0094

May to Christmas:

  PO Box
 221  Grand Marais<=
/st1:City>,
 MI=

 49839

  906-494-2434



 






On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:









As stated below, I do understand objection to adding the field.
 I would to hear from other PWG members on the addition of these field=
s.



 



Glen



 



 















From: Michael Sweet [mailto:msweet@apple.com] 

Sent: Friday, April 22, 2011=
 10:20
AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster<=
/p>








 









On Apr 2=
2, 2011,
at 9:34 AM, Petrie, Glen wrote:=






















... 


















[gwp] The important case is the size of the compressed raster d=
ata.
The decompressed size is recorded only if the raster is uncompressed.









[gwp] I agree that some (a few or a lot) of implementation may =
not
provide the information but as I said, I am requesting that the assignment =
be
made and those who can (want to) may record the size information.


















 






It reall=
y isn't a
matter of "may not provide", in most cases clients (and printers)
simply can't buffer hundreds of megabytes of raster data I can add the fiel=
d,
but since most producers of PWG Raster will not be able to supply the
compressed size of the raster no printer will be able to depend on it anywa=
ys,
so IMHO it is best to have the printer, if it is going to do any local
processing of full page images, use its own optimal internal storage format
than try to gerry-rig something into the format that just won't work.=













 



[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine.  I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging
anything.  I do not understand your comment “that just won’=
;t work”.
 It works fine.  In fact, I wrote a routine that will find the
size-only of compressed page by running the compression routine without sto=
ring
the compressed data.  I don’t understand your objection to assig=
ning the
field.



























 



... 












I would =
actually
prefer to flag the file as version 3 which is an uncompressed CUPS Raster w=
ith
the version 2 page header. And in the case of local processing, you'll like=
ly
want to use native word order (another feature of CUPS Raster that we are n=
ot
bringing along for PWG Raster...)















 









[gwp] Do you mean big/little-endian?  I am nothing request=
ing
the word ordering flag (value) be used.  The current specification is =
ok.


















 






My main =
point was
that if you are concerned about having a standard representation for
intermediate data, CUPS Raster already provides that. If you are trying to
tweak PWG Raster for use as an internal representation format then I'd rath=
er
not put that in the standard since internal formats are OOS for any PWG
standard.









&n=
bsp;












Would it=
 be
sufficient to document an uncompressed version of PWG Raster (with the
"RAS3" file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?









 









[gwp] I believe the RAS3 is for the entire PWG Raster file.&nbs=
p; I
am requesting a flags (value) for individual pages.  












 















Since th=
e format
does not support this, I would be opposed to adding something that would be
used only for an internal representation of a PWG Raster file.=




 






[gwp] Again, I do not understand your objection. =













 












____________________________________________________=
____________________

Michael Sweet, Senior Printing System Engineer, PWG Chair









 














-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 










_______________________________________________

ipp mailing list

ipp@pwg.o=
rg

=
https://www.pwg.org/mailm=
an/listinfo/ipp






 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 




-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 

















_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.org/ma=
ilman/listinfo/ipp















 











______________=
__________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0368.27A497F9--

--===============0818000870==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0818000870==--

From ipp-bounces@pwg.org  Mon Apr 25 15:18:41 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA5E0681 for ; Mon, 25 Apr 2011 15:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.597
X-Spam-Level: 
X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guGFuHBBIr4t for ; Mon, 25 Apr 2011 15:18:40 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1C190E066F for ; Mon, 25 Apr 2011 15:18:36 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id AC67E7958E; Mon, 25 Apr 2011 18:18:18 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 675CD79583 for ; Mon, 25 Apr 2011 18:18:06 -0400 (EDT)
MIME-version: 1.0
Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LK8003DXB7ZOL40@mail-out.apple.com> for ipp@pwg.org; Mon, 25 Apr 2011 15:18:05 -0700 (PDT)
X-AuditID: 11807136-b7c6bae000004a34-3b-4db5f31d287a
Received: from da0704a-dhcp142.apple.com (da0704a-dhcp142.apple.com [17.197.43.142]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay15.apple.com (Apple SCV relay) with SMTP id A2.91.18996.D13F5BD4; Mon, 25 Apr 2011 15:18:05 -0700 (PDT)
Subject: Re: [IPP] Requested Additions to PWG Raster
From: Michael Sweet 
In-reply-to: 
Date: Mon, 25 Apr 2011 15:18:05 -0700
Message-id: <954A4590-809A-4645-B1B1-EEC9F67906F8@apple.com>
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>      <000001cc0144$e1149c50$a33dd4f0$@tykodi.com>    <6B4A7B70-0DE1-478B-9B27-BB534FF61227@apple.com> 
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0138101859=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: AC67E7958E.AB37A
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0138101859==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_08rY+/GR4327pdOenCNYaA)"


--Boundary_(ID_08rY+/GR4327pdOenCNYaA)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Apr 25, 2011, at 9:45 AM, Petrie, Glen wrote:
> ... 
> 
> [gwp] What, this is the very definition of incompatibility;  I a devices receives a CUPS raster file with some vendor-data in the position of the page number and it does not represent the page number then no telling what will happen.
> 

By definition all of these fields are driver-specific and cannot be interpreted outside that particular driver.

(in this case a PWG Raster driver)
> [gwp] If you change the PWG raster file identifier so it does not match CUPS raster then is this not produce a conflict; because they would not longer be the same thing.  Right now, no one reading a CUPS raster or PWG raster change tell which is which.
> 

Actually, you can - if the PageSize field is all 0's, then it isn't a CUPS Raster file which will always have the media size in integer points... 
> [gwp] I disagree.  You mean that your/the proposed Job Ticket does have the duplex setting or the layout orientation data.  If not, how can someone ever generate the correct print output!!!
> 

The job ticket has "sides", which is an instruction to do duplex printing. However, it doesn't tell the printer how the raster data was generated.
> The Job Ticket will specify the output format (duplex, flip, rotate); therefore, transforms data and information are part of the Job Ticket and the raster must be transformed to the correct orientation required so that the printer (or any consumer of the raster) does not know or have to perform the transforms.
> 
The job ticket has "sides" and "orientation-requested". We don't require the printer support anything other than "portrait" orientation and the printer tells the client how to send the back side of duplex pages, so the client may have to pre-rotate/flip the bitmap data (or the intermediate format that is converted to a bitmap) before sending it to the printer.

However, there is no indication to the printer what rotation or flipping was actually done for a given page. That information is *not* present in the job ticket, and I would argue that it is not appropriate for inclusion in the job ticket because it is a) format-specific and b) informational rather than directive.
> ...
> 
> Raster data means the data is rastered-out and should not require additional transforms (scaling might be an exception); the transforms here may require the printer to have rotation buffers which could be large and expensive to implement; not desirable.
> 
Agreed.

> Therefore, I am opposed to adding the specific PWR element for Horizontal and Vertical Transform.  If a vendor which to use transforms, then it is part of their driver specific information but not an official PWG Raster element.
> 
That isn't the point of these fields - they are informational, not directive. A low-end printer will likely ignore them since the assumption is that the client did the right thing. Instead, this is for high-end printers and Cloud services that may need to "tweak" the raster document before sending it to the real output device.

> The same logic applies to the total number of page.
> 
How?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_08rY+/GR4327pdOenCNYaA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


On Apr 25, 2011,=
 at 9:45 AM, Petrie, Glen wrote:
... 
[gwp] What, this is the very definit=
ion
of incompatibility;  I a devices receives a CUPS raster file with some
vendor-data in the position of the page number and it does not represent the
page number then no telling what will happen.
=

<=
/o:smarttagtype>

By definition =
all of these fields are driver-specific and cannot be interpreted outside t=
hat particular driver.

(in this case a PWG Raster =
driver)
[gwp] If you change the PWG raster f=
ile
identifier so it does not match CUPS raster then is this not produce a
conflict; because they would not longer be the same thing.  Right now,=
 no one
reading a CUPS raster or PWG raster change tell which is which.
=


Actually, you can - if the PageSize field is all 0's, then it isn't a C=
UPS Raster file which will always have the media size in integer points...<=
span class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family=
: 'Times New Roman'; font-size: 16px; "> 
[gwp] I disagree.  You mean tha=
t your/the
proposed Job Ticket does have the duplex setting or the layout orientation =
data.
 If not, how can someone ever generate the correct print output!!! 

The job ticket has "sides", which is an instruction to do dupl=
ex printing. However, it doesn't tell the printer how the raster data was g=
enerated.
=

The
Job Ticket will specify the output format (duplex, flip, rotate); therefore,
transforms data and information are part of the Job Ticket and the raster m=
ust
be transformed to the correct orientation required so that the printer (or =
any
consumer of the raster) does not know or have to perform the transforms.
<=
/o:smarttagtype>The job ticket has "sides" and "orientation-requested". We don't requi=
re the printer support anything other than "portrait" orientation and the p=
rinter tells the client how to send the back side of duplex pages, so the c=
lient may have to pre-rotate/flip the bitmap data (or the intermediate form=
at that is converted to a bitmap) before sending it to the printer.

However, there is no indication to the printer what rotat=
ion or flipping was actually done for a given page. That information is *no=
t* present in the job ticket, and I would argue that it is not appropriate =
for inclusion in the job ticket because it is a) format-specific and b) inf=
ormational rather than directive.
...
Raster
data means the data is rastered-out and should not require additional
transforms (scaling might be an exception); the transforms here may require=
 the
printer to have rotation buffers which could be large and expensive to
implement; not desirable.
=

Agreed.

Therefore, I am opposed to adding the
specific PWR element for Horizontal and Vertical Transform.  If a vend=
or
which to use transforms, then it is part of their driver specific informati=
on
but not an official PWG Raster element.
<=
/u1:smarttagtype>
That isn't the point of these fields - they are informational, not direct=
ive. A low-end printer will likely ignore them since the assumption is that=
 the client did the right thing. Instead, this is for high-end printers and=
 Cloud services that may need to "tweak" the raster document before sending=
 it to the real output device.

The same logic applies to the total
number of page.
How?



_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_08rY+/GR4327pdOenCNYaA)--

--===============0138101859==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0138101859==--

From ipp-bounces@pwg.org  Mon Apr 25 15:42:19 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA7EE06B0 for ; Mon, 25 Apr 2011 15:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p3S-6U+7Cz2 for ; Mon, 25 Apr 2011 15:42:16 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id C1AE8E0663 for ; Mon, 25 Apr 2011 15:42:15 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 8296F7958E; Mon, 25 Apr 2011 18:41:57 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 26EC579193 for ; Mon, 25 Apr 2011 18:41:42 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 25 Apr 2011 15:41:42 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] Requested Additions to PWG Raster
Date: Mon, 25 Apr 2011 15:41:41 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] Requested Additions to PWG Raster
Thread-Index: AcwDlrIdCqQROwzvSYqjKBGD15AmzAAAFY7g
References:  <0B621406-8CE5-4E3E-8DE5-332E383911D4@apple.com>      <000001cc0144$e1149c50$a33dd4f0$@tykodi.com>    <6B4A7B70-0DE1-478B-9B27-BB534FF61227@apple.com>  <954A4590-809A-4645-B1B1-EEC9F67906F8@apple.com>
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 25 Apr 2011 22:41:42.0072 (UTC) FILETIME=[F2871380:01CC0399]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============2126015481=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 8296F7958E.A9CB7
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============2126015481==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0399.F1ECBEDD"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0399.F1ECBEDD
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Monday, April 25, 2011 3:18 PM
To: Petrie, Glen
Cc: ptykodi@tykodi.com; ipp@pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster

=20

On Apr 25, 2011, at 9:45 AM, Petrie, Glen wrote:

	...=20

	[gwp] What, this is the very definition of incompatibility;  I a
devices receives a CUPS raster file with some vendor-data in the
position of the page number and it does not represent the page number
then no telling what will happen.

=20

By definition all of these fields are driver-specific and cannot be
interpreted outside that particular driver.

=20

[gwp] I agree; that does not change my statement.

=20

(in this case a PWG Raster driver)

	[gwp] If you change the PWG raster file identifier so it does
not match CUPS raster then is this not produce a conflict; because they
would not longer be the same thing.  Right now, no one reading a CUPS
raster or PWG raster change tell which is which.

=20

Actually, you can - if the PageSize field is all 0's, then it isn't a
CUPS Raster file which will always have the media size in integer
points...=20

=20

[gwp] Great this says you "have a unique Id for PWG Raster" and that the
PageSize field of CUPS raster can never be used for PWG raster since the
value must be all 0' to uniquely identify a PWG Raster.  This new
identification MUST be stated in the PWG raster specification as the new
identifier.

=20

	[gwp] I disagree.  You mean that your/the proposed Job Ticket
does have the duplex setting or the layout orientation data.  If not,
how can someone ever generate the correct print output!!!=20

=20

The job ticket has "sides", which is an instruction to do duplex
printing. However, it doesn't tell the printer how the raster data was
generated.

=20

[gwp] I don't understand your reply.

	The Job Ticket will specify the output format (duplex, flip,
rotate); therefore, transforms data and information are part of the Job
Ticket and the raster must be transformed to the correct orientation
required so that the printer (or any consumer of the raster) does not
know or have to perform the transforms.

The job ticket has "sides" and "orientation-requested". We don't require
the printer support anything other than "portrait" orientation and the
printer tells the client how to send the back side of duplex pages, so
the client may have to pre-rotate/flip the bitmap data (or the
intermediate format that is converted to a bitmap) before sending it to
the printer.

=20

However, there is no indication to the printer what rotation or flipping
was actually done for a given page. That information is *not* present in
the job ticket, and I would argue that it is not appropriate for
inclusion in the job ticket because it is a) format-specific and b)
informational rather than directive.

=20

[gwp] If the printer does not support anything other than "portrait";
that is given in the printer capabilities and the printer will not
receive a job outside of it capabilities.  If the printer does receive a
job outside of its capabilities; it will best effort and must not be
required to "jump through hops" to do something it could not do.  We are
sending raster to the printer not an image.

[gwp] If the printer is capable of duplex; it is the client that sets
the flip/orientation; and, thus, only the client worries about how to
"flip" or not flip the content.  The printer only knows to do duplex; it
does not need to know the flip or orientation the raster. Remember this
is raster, not image.=20

	...

	Raster data means the data is rastered-out and should not
require additional transforms (scaling might be an exception); the
transforms here may require the printer to have rotation buffers which
could be large and expensive to implement; not desirable.

Agreed.





Therefore, I am opposed to adding the specific PWR element for
Horizontal and Vertical Transform.  If a vendor which to use transforms,
then it is part of their driver specific information but not an official
PWG Raster element.

That isn't the point of these fields - they are informational, not
directive. A low-end printer will likely ignore them since the
assumption is that the client did the right thing. Instead, this is for
high-end printers and Cloud services that may need to "tweak" the raster
document before sending it to the real output device.

=20

[gwp] Why would or should any printer "tweak" the raster.  The raster
must be in the correct format; otherwise it is not (printer) raster.
This is a raster format, not an image format.  If you want to change the
specification to PWG Image specification; then I would agree that the
printer can perform transforms on the image data.  But raster means it
be "poured" in the printer and printed as delivered; that is, the raster
was generated for the printer for this reason.=20

=20

	The same logic applies to the total number of page.

How?

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0399.F1ECBEDD
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

















 



 















From: Michael =
Sweet
[mailto:msweet@apple.com] 

Sent: Monday, April 25, 2011=
 3:18
PM

To: Petrie, Glen

Cc: ptykodi@tykodi.com;
ipp@pwg.org

Subject: Re: [IPP] Requested
Additions to PWG Raster






 









On Apr 25, 2011, at 9:45 AM, Petrie, Glen wrote:<=
/font>


















... 



[gwp] What, this is the very definition of incompatibility;&nbs=
p; I
a devices receives a CUPS raster file with some vendor-data in the position=
 of
the page number and it does not represent the page number then no telling w=
hat
will happen.


















 








By definition all of these fields are driver-specific and cannot be
interpreted outside that particular driver.



 



[gwp] I agree; that does not change =
my
statement.









 









(in this case a PWG Raster driver)





















[gwp] If you change the PWG raster file identifier so it does n=
ot
match CUPS raster then is this not produce a conflict; because they would n=
ot
longer be the same thing.  Right now, no one reading a CUPS raster or =
PWG
raster change tell which is which.


















 








Actually, you can - if the PageSize field is all 0's, then it isn't=
 a
CUPS Raster file which will always have the media size in integer points...=
&nbs=
p;



 



[gwp] Great this says you “hav=
e a
unique Id for PWG Raster” and that the PageSize field of CUPS raster =
can
never be used for PWG raster since the value must be all 0’ to unique=
ly identify
a PWG Raster.  This new identification MUST be stated in the PWG raster
specification as the new identifier.



 





















[gwp] I disagree.  You mean that your/the proposed Job Tic=
ket
does have the duplex setting or the layout orientation data.  If not, =
how
can someone ever generate the correct print output!!! 


















 








The job ticket has "sides", which is an instruction to do
duplex printing. However, it doesn't tell the printer how the raster data w=
as
generated.



 



[gwp] I don’t understand your
reply.





















The Job Ticket wi=
ll
specify the output format (duplex, flip, rotate); therefore, transforms data
and information are part of the Job Ticket and the raster must be transform=
ed
to the correct orientation required so that the printer (or any consumer of=
 the
raster) does not know or have to perform the transforms.















The
job ticket has "sides" and "orientation-requested". We
don't require the printer support anything other than "portrait"
orientation and the printer tells the client how to send the back side of
duplex pages, so the client may have to pre-rotate/flip the bitmap data (or=
 the
intermediate format that is converted to a bitmap) before sending it to the
printer.









 









However, there is no indication to the printer what rotation or
flipping was actually done for a given page. That information is *not* pres=
ent
in the job ticket, and I would argue that it is not appropriate for inclusi=
on
in the job ticket because it is a) format-specific and b) informational rat=
her
than directive.



 



[gwp] If the printer does not support
anything other than “portrait”; that is given in the printer
capabilities and the printer will not receive a job outside of it capabilit=
ies.
 If the printer does receive a job outside of its capabilities; it will
best effort and must not be required to “jump through hops” to =
do
something it could not do.  We are sending raster to the printer not an
image.



[gwp] If the printer is capable of
duplex; it is the client that sets the flip/orientation; and, thus, only the
client worries about how to “flip” or not flip the content. &nb=
sp;The
printer only knows to do duplex; it does not need to know the flip or
orientation the raster. Remember this is raster, not image. 
























...




















<=
/u1:smarttagtype><=
u1:smarttagtype namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=
 name=3D"City">














Raster data means the data is rastered-out and should =
not
require additional transforms (scaling might be an exception); the transfor=
ms
here may require the printer to have rotation buffers which could be large =
and
expensive to implement; not desirable.




















Agreed.















<=
u4:smarttagtype namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=
 name=3D"State"><=
/u1:p>














Therefore, I am o=
pposed
to adding the specific PWR element for Horizontal and Vertical Transform.
 If a vendor which to use transforms, then it is part of their driver
specific information but not an official PWG Raster element.<=
/span>




















That
isn't the point of these fields - they are informational, not directive. A
low-end printer will likely ignore them since the assumption is that the cl=
ient
did the right thing. Instead, this is for high-end printers and Cloud servi=
ces
that may need to "tweak" the raster document before sending it to=
 the
real output device.



 



[gwp] Why would or should any printe=
r “tweak”
the raster.  The raster must be in the correct format; otherwise it is=
 not
(printer) raster.  This is a raster format, not an image format. =
 If
you want to change the specification to PWG Image specification; then I wou=
ld
agree that the printer can perform transforms on the image data.  But
raster means it be “poured” in the printer and printed as deliv=
ered;
that is, the raster was generated for the printer for this reason. 









 





















The same logic ap=
plies
to the total number of page.























How?









 















______________=
__________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0399.F1ECBEDD--

--===============2126015481==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============2126015481==--

From pwg-announce-bounces@pwg.org  Tue Apr 26 04:27:24 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AACE0723 for ; Tue, 26 Apr 2011 04:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gWHE3y+wxq7 for ; Tue, 26 Apr 2011 04:27:19 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 53179E0703 for ; Tue, 26 Apr 2011 04:27:07 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 23E3E79597; Tue, 26 Apr 2011 07:26:40 -0400 (EDT)
X-Original-To: pwg-announce@pwg.org
Delivered-To: pwg-announce@pwg.org
Received: from USA7109MR001.ACS-INC.COM (usa7109mr001.acs-inc.com [63.101.151.9]) by pwg.org (Postfix) with ESMTP id 9939179595 for ; Tue, 26 Apr 2011 07:26:24 -0400 (EDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmEAAJ2qtk0Nh9IPmWdsb2JhbACCYZR5jWoUAQEBAQEICwsHFCXEMoMZgl0EggWDd4xXiiw
X-IronPort-AV: E=Sophos;i="4.64,267,1301893200"; d="scan'208,217";a="33669647"
Received: from usa0300gw002.na.xerox.net ([13.135.210.15]) by USA7109MR001.ACS-INC.COM with ESMTP; 26 Apr 2011 06:26:23 -0500
Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 07:26:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Pwg-Announce] PWG Last Call of PWG Copy Service Semantic Model and Service Interface specification (3/21/11 - 5/6/11)
Date: Tue, 26 Apr 2011 04:25:53 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pwg-Announce] PWG Last Call of PWG Copy Service Semantic Model and Service Interface specification (3/21/11 - 5/6/11)
Thread-Index: AcwEBLQBIcGoIlKTTVS504it1HglsQ==
From: "Zehler, Peter" 
To: 
X-OriginalArrivalTime: 26 Apr 2011 11:26:09.0493 (UTC) FILETIME=[BDA41850:01CC0404]
X-pwg-MailScanner: Found to be clean, Found to be clean
X-BeenThere: pwg-announce@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Printer Working Group Announcement List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0585317038=="
Sender: pwg-announce-bounces@pwg.org
Errors-To: pwg-announce-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 23E3E79597.AC9E2
X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0585317038==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0404.B5BD018D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0404.B5BD018D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Per PWG process we are extending the Last call for comments on the PWG
Copy Service Semantic Model and Service Interface specification.  I am
extending it to a week from Friday.  Please register you Last Call
comments or lack thereof so that quorum can be reached.

=20

Thanks,

Pete

=20

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20

From: pwg-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org]
On Behalf Of Zehler, Peter
Sent: Monday, March 21, 2011 12:49 PM
To: pwg-announce@pwg.org
Subject: [Pwg-Announce] PWG Last Call of PWG Copy Service Semantic Model
andService Interface specification (3/21/11 - 4/22/11)

=20

All,
=20
[This PWG Last Call will start today on Monday March 21, 2011.
This PWG Last Call will end Friday April 22, 2011 at 10pm US PDT.]
=20
This is the formal announcement of the PWG Copy Service Semantic Model
and Service Interface specification, which is located at:

=20
Many of the operations and attributes defined in this document have been
prototyped by Xerox.  The prototype is based on existing protocols such
as ISO 10175, IETF/PWG IPP and Microsoft WSD.  The MFD WG has completed
a working group last call and subsequent revisions of this document.
=20
The PWG Process/3.0 requires that a quorum (30%) of PWG voting members
must acknowledge a PWG Last Call (with or without comments), before any
document can progress to PWG Formal Vote.  This PWG Last Call is NOT a
Formal Vote but it DOES require your review acknowledgment.
=20
Please send your review acknowledgment *exactly* as follows:
=20
To:  mfd at pwg.org =20
Subject:   has reviewed the MFD Model and Common Semantics
and has [no] comments
=20
Please do NOT simply reply to this note on the PWG-Announce list.
=20
This specification in normatively dependent on the MFD Model and Common
Semantics specification.  As a result this specification is less than 30
pages and consists primarily of figures, tables, and simplified text
that references the MFD Model and Common Semantics specification that
contains the details.  I have also posted a "-rev" version of this
specification for those of you that would like to see what has changed
since the MFD group Last Call.
=20
Note:  The PWG Definition of the Standards Development Process Version
3.0 is located at:
  
=20

=20

=20

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0404.B5BD018D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


------_=_NextPart_001_01CC0404.B5BD018D--

--===============0585317038==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

--===============0585317038==--

From pwg-announce-bounces@pwg.org  Tue Apr 26 04:32:40 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FA3E06ED for ; Tue, 26 Apr 2011 04:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY+-b4IfOLVJ for ; Tue, 26 Apr 2011 04:32:37 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1B364E0703 for ; Tue, 26 Apr 2011 04:32:37 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7AB16795A7; Tue, 26 Apr 2011 07:31:58 -0400 (EDT)
X-Original-To: pwg-announce@pwg.org
Delivered-To: pwg-announce@pwg.org
Received: from USA7109MR001.ACS-INC.COM (usa7109mr001.acs-inc.com [63.101.151.9]) by pwg.org (Postfix) with ESMTP id CA9AD795A7 for ; Tue, 26 Apr 2011 07:31:41 -0400 (EDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmEAAK+rtk0Nl9IPmWdsb2JhbACCYZR5jWoUAQEBAQEGDQsHFCXEMYMZgl0EggWDd4xXiiw
X-IronPort-AV: E=Sophos;i="4.64,268,1301893200"; d="scan'208,217";a="33671977"
Received: from usa7061gw002.na.xerox.net ([13.151.210.15]) by USA7109MR001.ACS-INC.COM with ESMTP; 26 Apr 2011 06:31:40 -0500
Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA7061GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 04:31:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Pwg-Announce] PWG Last Call of PWG Copy Service Semantic Model and Service Interface specification (3/21/11 - 5/6/11)
Date: Tue, 26 Apr 2011 04:31:03 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pwg-Announce] PWG Last Call of PWG Copy Service Semantic Model and Service Interface specification (3/21/11 - 5/6/11)
Thread-Index: AcwEBWz8TKim8EFPSHio6mtU8bb2Mg==
From: "Zehler, Peter" 
To: 
X-OriginalArrivalTime: 26 Apr 2011 11:31:33.0703 (UTC) FILETIME=[7EE29D70:01CC0405]
X-pwg-MailScanner: Found to be clean, Found to be clean
X-BeenThere: pwg-announce@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Printer Working Group Announcement List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1422186686=="
Sender: pwg-announce-bounces@pwg.org
Errors-To: pwg-announce-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 7AB16795A7.AC900
X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1422186686==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0405.6E47A5C3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0405.6E47A5C3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Corrected subject line for Last Call response (cut and paste error)

=20

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20

From: pwg-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org]
On Behalf Of Zehler, Peter
Sent: Tuesday, April 26, 2011 7:26 AM
To: pwg-announce@pwg.org
Subject: RE: [Pwg-Announce] PWG Last Call of PWG Copy Service Semantic
Model and Service Interface specification (3/21/11 - 5/6/11)

=20

Per PWG process we are extending the Last call for comments on the PWG
Copy Service Semantic Model and Service Interface specification.  I am
extending it to a week from Friday.  Please register you Last Call
comments or lack thereof so that quorum can be reached.

=20

Thanks,

Pete

=20

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20

From: pwg-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org]
On Behalf Of Zehler, Peter
Sent: Monday, March 21, 2011 12:49 PM
To: pwg-announce@pwg.org
Subject: [Pwg-Announce] PWG Last Call of PWG Copy Service Semantic Model
andService Interface specification (3/21/11 - 4/22/11)

=20

All,
=20
[This PWG Last Call will start today on Monday March 21, 2011.
This PWG Last Call will end Friday April 22, 2011 at 10pm US PDT.]
=20
This is the formal announcement of the PWG Copy Service Semantic Model
and Service Interface specification, which is located at:

=20
Many of the operations and attributes defined in this document have been
prototyped by Xerox.  The prototype is based on existing protocols such
as ISO 10175, IETF/PWG IPP and Microsoft WSD.  The MFD WG has completed
a working group last call and subsequent revisions of this document.
=20
The PWG Process/3.0 requires that a quorum (30%) of PWG voting members
must acknowledge a PWG Last Call (with or without comments), before any
document can progress to PWG Formal Vote.  This PWG Last Call is NOT a
Formal Vote but it DOES require your review acknowledgment.
=20
Please send your review acknowledgment *exactly* as follows:
=20
To:  mfd at pwg.org =20
Subject:   has reviewed the Copy Service Semantic Model
and Service Interface specification and has [no] comments
=20
Please do NOT simply reply to this note on the PWG-Announce list.
=20
This specification in normatively dependent on the MFD Model and Common
Semantics specification.  As a result this specification is less than 30
pages and consists primarily of figures, tables, and simplified text
that references the MFD Model and Common Semantics specification that
contains the details.  I have also posted a "-rev" version of this
specification for those of you that would like to see what has changed
since the MFD group Last Call.
=20
Note:  The PWG Definition of the Standards Development Process Version
3.0 is located at:
  
=20

=20

=20

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0405.6E47A5C3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Corrected subject line for Last Call response (cut and paste =
error)
 
 
Peter Zehler

Xerox Research Center Webster
=
Email: Peter.Zehler@Xero=
x.com
Voice: (585) 265=
-8755
FAX: (585) 265-7441<=
/span>
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
=
Webster NY, 14580-9701 
 
Fr=
om: pwg-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org] <=
b>On Behalf Of Zehler, Peter
Sent: Tuesday, April 26, 2011 7:=
26 AM
To: pwg-announce@pwg.org
Subject: RE: [Pwg-Announ=
ce] PWG Last Call of PWG Copy Service Semantic Model and Service Interface =
specification (3/21/11 - 5/6/11)
 
Per PWG process we are extending the Last call for comments on th=
e PWG Copy Service Semantic Model and Service Interface specification. =
; I am extending it to a week from Friday.  Please register you Last C=
all comments or lack thereof so that quorum can be reached.
 <=
/span>
Thanks,
Pete=

&n=
bsp;
 
Peter Zehler

Xerox Research Center Webster
Emai=
l: Peter.Zehler@Xerox.com
Voice: (585) 265-8755<=
span style=3D'color:#1F497D'>
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
=
M/S 128-25E
Webst=
er NY, 14580-9701 <=
o:p>
 
From: pwg-a=
nnounce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org] On Behalf =
Of Zehler, Peter
Sent: Monday, March 21, 2011 12:49 PM
=
To: pwg-announce@pwg.org
Subject: [Pwg-Announce] PWG Last Cal=
l of PWG Copy Service Semantic Model andService Interface specification (3/=
21/11 - 4/22/11)
 
All,=

 
[This PWG Last Call will start today on Monday March 21, 2011.<=
o:p>
This PWG Last Call will end Friday April 22, 2011 at 10pm US PDT.]
 
This is the formal announcement of the PWG Copy Service Semantic Model=
 and Service Interface specification, which is located at:
<ftp://ftp=
.pwg.org/pub/pwg/mfd/wd/wd-mfdcopymodel10-20110321.pdf>
 =
;
M=
any of the operations and attributes defined in this document have been pro=
totyped by Xerox.  The prototype is based on existing protocols such a=
s ISO 10175, IETF/PWG IPP and Microsoft WSD.  The MFD WG has completed=
 a working group last call and subsequent revisions of this document.<=
/o:p>
 
The PWG Process/3.0 requires that a quorum (30%) of PWG voting member=
s must acknowledge a PWG Last Call (with or without comments), before any d=
ocument can progress to PWG Formal Vote.  This PWG Last Call is NOT a =
Formal Vote but it DOES require your review acknowledgment.
 
Plea=
se send your review acknowledgment *exactly* as follows:<=
/pre>
 
To:&nbs=
p; mfd at pwg.org
Subject:  <C=
ompany Name> has reviewed the Copy Service Semantic Model and Service Interface specificat=
ion and has [no] co=
mments
 
Please do NOT simply reply to this note on the PWG-Announ=
ce list.
 
This specification in normatively dependent on the MFD =
Model and Common Semantics specification.  As a result this specificat=
ion is less than 30 pages and consists primarily of figures, tables, and si=
mplified text that references the MFD Model and Common Semantics specificat=
ion that contains the details.  I have also posted a “-rev”=
; version of this specification for those of you that would like to see wha=
t has changed since the MFD group Last Call.
 
Note:  The PWG=
 Definition of the Standards Development Process Version 3.0 is located at:=

  <http://www.pwg.org/chair/membership_docs/pwg-process30.pdf>=
;
 
 
 
 
Peter Zehler

Xerox Research Center Webster=

Email: Peter.Zehler@=
Xerox.com
Voice: (585)=
 265-8755
FAX: (585) 265-7=
441
US Mail: Peter Zehler<=
/span>
Xerox Corp.
800 Phillips Rd.
M/S 128-25E<=
br>Webster NY, 14580-9701 
 <=
/p>

-- 
This message has been scanned for viruses an=
d 
dangerous content by Mail=
Scanner, and is 
believed to be clean. 

-- 
This message has been scanned for viruses and 
=
dangerous content by MailScanne=
r, and is 
believed to be clean. 
--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


------_=_NextPart_001_01CC0405.6E47A5C3--

--===============1422186686==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

--===============1422186686==--

From pwg-announce-bounces@pwg.org  Tue Apr 26 07:06:47 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA0CE077A for ; Tue, 26 Apr 2011 07:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZfi66yWUEa5 for ; Tue, 26 Apr 2011 07:06:47 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1C114E0773 for ; Tue, 26 Apr 2011 07:06:47 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 647C8795B9; Tue, 26 Apr 2011 10:06:27 -0400 (EDT)
X-Original-To: pwg-announce@pwg.org
Delivered-To: pwg-announce@pwg.org
Received: from mail-gw.okidata.com (mail-gw.okidata.com [207.77.135.74]) by pwg.org (Postfix) with ESMTP id 24CDD7958E; Tue, 26 Apr 2011 10:06:14 -0400 (EDT)
In-Reply-To: 
To: "Zehler, Peter" 
MIME-Version: 1.0
X-KeepSent: 0E79018A:36CBC151-8525787E:004D58D8; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6  CCH4 June 18, 2008
Message-ID: 
From: Nancy.Chen@okidata.com
Date: Tue, 26 Apr 2011 10:06:12 -0400
X-MIMETrack: Serialize by Router on ODA-SMTP-MTA/OKIDATA/OKI_DATA_CORP/OKI_ELECTRIC/US(Release 8.5.1FP5|September 29, 2010) at 04/26/2011 10:06:15 AM, Serialize complete at 04/26/2011 10:06:15 AM
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: pwg-announce@pwg.org, pwg-announce-bounces@pwg.org
Subject: [Pwg-Announce] Oki Data has reviewed the Copy Service Semantic Model and Service Interface specification and has no comments
X-BeenThere: pwg-announce@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Printer Working Group Announcement List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0503521966=="
Sender: pwg-announce-bounces@pwg.org
Errors-To: pwg-announce-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 647C8795B9.ACAE5
X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org

This is a multipart message in MIME format.
--===============0503521966==
Content-Type: multipart/alternative;
	boundary="=_alternative 004D79308525787E_="

This is a multipart message in MIME format.
--=_alternative 004D79308525787E_=
Content-Type: text/plain; charset="US-ASCII"

-Nancy
--------------------------------------------------------------------------------------------------
Nancy Chen, PWG Vice-Chair
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--=_alternative 004D79308525787E_=
Content-Type: text/html; charset="US-ASCII"



-Nancy

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

Nancy Chen, PWG Vice-Chair

Principal Engineer

Solutions and Technology

Oki Data

2000 Bishops Gate Blvd.

Mt. Laurel, NJ 08054

Phone: (856)222-7006
-- 

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.



--=_alternative 004D79308525787E_=--

--===============0503521966==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

--===============0503521966==--

From ipp-bounces@pwg.org  Tue Apr 26 08:30:18 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19930E07F0 for ; Tue, 26 Apr 2011 08:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7waMdLTQ7bd for ; Tue, 26 Apr 2011 08:30:17 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 244A9E07ED for ; Tue, 26 Apr 2011 08:30:17 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 1AFAE795B4; Tue, 26 Apr 2011 11:30:04 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id A947479525 for ; Tue, 26 Apr 2011 11:29:51 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Apr 2011 08:29:50 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [IPP] (Another) New PWG Raster Format draft posted
Date: Tue, 26 Apr 2011 08:29:49 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] (Another) New PWG Raster Format draft posted
Thread-Index: AcvsOLeboktmuTvOS8aJaFOPG8mvuwX7YjGg
References: <4FC3E57E-91F6-4E75-A677-7196660D3792@apple.com>
From: "Petrie, Glen" 
To: "Michael Sweet" , 
X-OriginalArrivalTime: 26 Apr 2011 15:29:50.0248 (UTC) FILETIME=[C84A4280:01CC0426]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 1AFAE795B4.A8552
X-pwg-MailScanner-From: ipp-bounces@pwg.org

Since the title of document is called the "PWG Rater Format" I believe
we should change the file name to wd-pwgraster10-xxxxx instead of
wd-ippraster10-xxxxx

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet
Sent: Saturday, March 26, 2011 9:37 PM
To: ipp@pwg.org
Subject: [IPP] (Another) New PWG Raster Format draft posted

All,

The previous updated draft of the PWG Raster Format has two whole
subsections accidentally deleted from it... Here is a newer and even
better version with the lost subsections added back in along with the
IANA IPP registration templates for good measure:

   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf
   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.docx

The -rev version shows the changes from the last "good" version (Feb
23rd)...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Tue Apr 26 09:35:55 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB397E07EC for ; Tue, 26 Apr 2011 09:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvUWyKO9n9ib for ; Tue, 26 Apr 2011 09:35:54 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9891BE06A6 for ; Tue, 26 Apr 2011 09:35:54 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 714FF795C2; Tue, 26 Apr 2011 12:35:37 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com [209.85.161.46]) by pwg.org (Postfix) with ESMTP id DA46179582 for ; Tue, 26 Apr 2011 12:35:23 -0400 (EDT)
Received: by fxm17 with SMTP id 17so785679fxm.5 for ; Tue, 26 Apr 2011 09:35:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=50pjWxvVDO2mfC7xVBksInQpY9N2+94NKtYTBjCB1jM=; b=FPialY9qsWNTlNuhhII//Hn4yjPGkYSeNfnzNOR+Welj5q1cDT4nPp1a7m0MMpWMj5 xjW6TaQbSMg3SiKLjVwyCwiN/D8hw5ZfiRTfAuAyVGH8Z8V8nCyeqPH52yun4lwsTm3D FRuG3dBkMAONvhidN1w/bshi1X1/ZKQ1nHNSY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uIVTT3gBaFrk1FNh2LCgmVNRniEruRAYlqS+ctq/3BPeeBJ5vy36BHkPlbQXKCZVy8 ZxSg2uBYtqhAVZNuDWrtyimGQ6dapBZMAjjtOOJcPR9aKWImOr+ssMuhGUZAlLrffqGs WkpK6yZj+9kI/UW4vGq/qAsKQ6U9MBtgxvcDU=
MIME-Version: 1.0
Received: by 10.223.7.26 with SMTP id b26mr1046781fab.119.1303835722770; Tue, 26 Apr 2011 09:35:22 -0700 (PDT)
Received: by 10.223.37.19 with HTTP; Tue, 26 Apr 2011 09:35:22 -0700 (PDT)
In-Reply-To: 
References: <4FC3E57E-91F6-4E75-A677-7196660D3792@apple.com> 
Date: Tue, 26 Apr 2011 12:35:22 -0400
Message-ID: 
Subject: Re: [IPP] (Another) New PWG Raster Format draft posted
From: Ira McDonald 
To: "Petrie, Glen" , Ira McDonald 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1797467814=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 714FF795C2.A9C0F
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1797467814==
Content-Type: multipart/alternative; boundary=00151747347c19e92e04a1d4e95e


--00151747347c19e92e04a1d4e95e
Content-Type: text/plain; charset=ISO-8859-1

Hi Glen,

No - our PWG Naming Policy requires that the first part
of the filename be the responsible working group.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen
wrote:

> Since the title of document is called the "PWG Rater Format" I believe
> we should change the file name to wd-pwgraster10-xxxxx instead of
> wd-ippraster10-xxxxx
>
> Glen
>
>
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
> Michael Sweet
> Sent: Saturday, March 26, 2011 9:37 PM
> To: ipp@pwg.org
> Subject: [IPP] (Another) New PWG Raster Format draft posted
>
> All,
>
> The previous updated draft of the PWG Raster Format has two whole
> subsections accidentally deleted from it... Here is a newer and even
> better version with the lost subsections added back in along with the
> IANA IPP registration templates for good measure:
>
>   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
>   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf
>   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.docx
>
> The -rev version shows the changes from the last "good" version (Feb
> 23rd)...
>
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--00151747347c19e92e04a1d4e95e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Glen,

No - our PWG Naming Policy requires that the first part
=
of the filename be the responsible working group.

Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair -=
 Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desig=
nated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
<=
a href=3D"http://sites.google.com/site/blueroofmusic" target=3D"_blank">htt=
p://sites.google.com/site/blueroofmusic

http://sites.google.com/site/highnorthinc=

mailto:blu=
eroofmusic@gmail.com

Christmas through April:
=A0 579 Park Place=A0 Saline, MI=A0 48176
=
=A0 734-944-0094
May to Christmas:
=A0 PO Box 221=A0 Grand Marais, MI=
 49839
=A0 906-494-2434






On Tue, Apr 26, 2011 at 11:29 AM, Petrie=
, Glen <=
glen.petrie@eitc.epson.com> wrote:

Since the title of document is called the "PWG Rater Format" I be=
lieve

we should change the file name to wd-pwgraster10-xxxxx instead of

wd-ippraster10-xxxxx



Glen





-----Original Message-----

From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf=
 Of

Michael Sweet

Sent: Saturday, March 26, 2011 9:37 PM

To: ipp@pwg.org

Subject: [IPP] (Another) New PWG Raster Format draft posted




All,



The previous updated draft of the PWG Raster Format has two whole

subsections accidentally deleted from it... Here is a newer and even

better version with the lost subsections added back in along with the

IANA IPP registration templates for good measure:



 =A0 ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20=
110327-rev.pdf

 =A0 ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-201103=
27.pdf

 =A0 ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110=
327.docx



The -rev version shows the changes from the last "good" version (=
Feb

23rd)...



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp



--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--00151747347c19e92e04a1d4e95e--

--===============1797467814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1797467814==--

From ipp-bounces@pwg.org  Tue Apr 26 09:41:03 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1790E0713 for ; Tue, 26 Apr 2011 09:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMJTWkbtjTTE for ; Tue, 26 Apr 2011 09:41:02 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8D145E0681 for ; Tue, 26 Apr 2011 09:41:02 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D649B795C2; Tue, 26 Apr 2011 12:40:46 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id B242D79540 for ; Tue, 26 Apr 2011 12:40:33 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Apr 2011 09:40:32 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] (Another) New PWG Raster Format draft posted
Date: Tue, 26 Apr 2011 09:40:31 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] (Another) New PWG Raster Format draft posted
Thread-Index: AcwEL/vF25R3/w2ASXeJ23Krik5c8gAAEC2A
References: <4FC3E57E-91F6-4E75-A677-7196660D3792@apple.com> 
From: "Petrie, Glen" 
To: "Ira McDonald" 
X-OriginalArrivalTime: 26 Apr 2011 16:40:32.0974 (UTC) FILETIME=[A926DEE0:01CC0430]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0504400879=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: D649B795C2.A9D71
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0504400879==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0430.A839DE8C"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0430.A839DE8C
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

So it should be wd-ipppwgraster

=20

________________________________

From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
Sent: Tuesday, April 26, 2011 9:35 AM
To: Petrie, Glen; Ira McDonald
Cc: Michael Sweet; ipp@pwg.org
Subject: Re: [IPP] (Another) New PWG Raster Format draft posted

=20

Hi Glen,

No - our PWG Naming Policy requires that the first part
of the filename be the responsible working group.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
=20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434





On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen
 wrote:

Since the title of document is called the "PWG Rater Format" I believe
we should change the file name to wd-pwgraster10-xxxxx instead of
wd-ippraster10-xxxxx

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet
Sent: Saturday, March 26, 2011 9:37 PM
To: ipp@pwg.org
Subject: [IPP] (Another) New PWG Raster Format draft posted


All,

The previous updated draft of the PWG Raster Format has two whole
subsections accidentally deleted from it... Here is a newer and even
better version with the lost subsections added back in along with the
IANA IPP registration templates for good measure:

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf
  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.docx

The -rev version shows the changes from the last "good" version (Feb
23rd)...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0430.A839DE8C
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable






















--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0430.A839DE8C--

--===============0504400879==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0504400879==--

From ipp-bounces@pwg.org  Tue Apr 26 09:43:27 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBFFE0787 for ; Tue, 26 Apr 2011 09:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2SpQy8YBDNP for ; Tue, 26 Apr 2011 09:43:25 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 333F9E0713 for ; Tue, 26 Apr 2011 09:43:25 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 989C0795CD; Tue, 26 Apr 2011 12:43:04 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id B7D29795C2 for ; Tue, 26 Apr 2011 12:42:47 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Apr 2011 09:42:47 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] (Another) New PWG Raster Format draft posted
Date: Tue, 26 Apr 2011 09:42:46 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] (Another) New PWG Raster Format draft posted
Thread-Index: AcwEL/vF25R3/w2ASXeJ23Krik5c8gAAEC2AAAAO1zA=
References: <4FC3E57E-91F6-4E75-A677-7196660D3792@apple.com> 
From: "Petrie, Glen" 
To: "Petrie, Glen" , "Ira McDonald" 
X-OriginalArrivalTime: 26 Apr 2011 16:42:47.0332 (UTC) FILETIME=[F93C4640:01CC0430]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0651289740=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 989C0795CD.AA458
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0651289740==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0430.F8ACDC92"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0430.F8ACDC92
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Ops, you don't include PWG normally; but here it is part of name; that
is Raster is not the name "PWG Raster"; correct

=20

________________________________

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Petrie, Glen
Sent: Tuesday, April 26, 2011 9:41 AM
To: Ira McDonald
Cc: ipp@pwg.org
Subject: RE: [IPP] (Another) New PWG Raster Format draft posted

=20

So it should be wd-ipppwgraster

=20

________________________________

From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
Sent: Tuesday, April 26, 2011 9:35 AM
To: Petrie, Glen; Ira McDonald
Cc: Michael Sweet; ipp@pwg.org
Subject: Re: [IPP] (Another) New PWG Raster Format draft posted

=20

Hi Glen,

No - our PWG Naming Policy requires that the first part
of the filename be the responsible working group.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
=20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

=20

On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen
 wrote:

Since the title of document is called the "PWG Rater Format" I believe
we should change the file name to wd-pwgraster10-xxxxx instead of
wd-ippraster10-xxxxx

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet
Sent: Saturday, March 26, 2011 9:37 PM
To: ipp@pwg.org
Subject: [IPP] (Another) New PWG Raster Format draft posted


All,

The previous updated draft of the PWG Raster Format has two whole
subsections accidentally deleted from it... Here is a newer and even
better version with the lost subsections added back in along with the
IANA IPP registration templates for good measure:

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf
  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.docx

The -rev version shows the changes from the last "good" version (Feb
23rd)...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

=20


--=20
This message has been scanned for viruses and=20
dangerous content by MailScanner  , and is

believed to be clean.=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0430.F8ACDC92
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable




















Per PWG process we are extending the Last call for comments o=
n the PWG Copy Service Semantic Model and Service Interface specification.&=
nbsp; I am extending it to a week from Friday.  Please register you La=
st Call comments or lack thereof so that quorum can be reached.<=
/span>
 
Thanks,
Pete<=
o:p>
 
 
Peter Zehler

Xerox Research Center Webster
=
Email: Peter.Zehler@Xerox.com=

Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.=

M/S 128-25E
W=
ebster NY, 14580-9701 
 
From:=
 pwg=
-announce-bounces@pwg.org [mailto:pwg-announce-bounces@pwg.org] On Behal=
f Of Zehler, Peter
Sent: Monday, March 21, 2011 12:49 PM
<=
b>To: pwg-announce@pwg.org
Subject: [Pwg-Announce] PWG Last C=
all of PWG Copy Service Semantic Model andService Interface specification (=
3/21/11 - 4/22/11)
 
Al=
l,
 
[This PWG Last Call will start today on Monday March 21, 2011=
.
This PWG Last Call will end Friday April 22, 2011 at 10pm US PDT.]=

 
This is the formal announcement of the PWG Copy Service Semantic Mod=
el and Service Interface specification, which is located at:
<ftp://=
ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdcopymodel10-20110321.pdf>
&n=
bsp;
Many of the operations and attributes defined in this document have been =
prototyped by Xerox.  The prototype is based on existing protocols suc=
h as ISO 10175, IETF/PWG IPP and Microsoft WSD.  The MFD WG has comple=
ted a working group last call and subsequent revisions of this document.
=
 
The PWG Process/3.0 requires that a quorum (30%) of PWG voting mem=
bers must acknowledge a PWG Last Call (with or without comments), before an=
y document can progress to PWG Formal Vote.  This PWG Last Call is NOT=
 a Formal Vote but it DOES require your review acknowledgment.
 =
;
P=
lease send your review acknowledgment *exactly* as follows:
 
To:&=
nbsp; mfd at pwg.org
Subject:  &l=
t;Company Name> has reviewed the MFD Model and Common Semantics and has =
[no] comments
 
Please do NOT simply reply to this note on the PWG=
-Announce list.
 
This specification in normatively dependent on t=
he MFD Model and Common Semantics specification.  As a result this spe=
cification is less than 30 pages and consists primarily of figures, tables,=
 and simplified text that references the MFD Model and Common Semantics spe=
cification that contains the details.  I have also posted a “-re=
v” version of this specification for those of you that would like to =
see what has changed since the MFD group Last Call.
=

 
Note:  =
The PWG Definition of the Standards Development Process Version 3.0 is loca=
ted at:
  <http://www.pwg.org/chair/membership_docs/pwg-process30.pdf=
>
 
 
 
 
=
Peter Zehler

Xerox Research Center =
Webster
Email: Peter.=
Zehler@Xerox.com
Voice=
: (585) 265-8755
FAX: (585=
) 265-7441
US Mail: Peter =
Zehler
Xerox Corp.<=
span style=3D'color:#1F497D'>
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 
 =


-- 
This message has been scanned for vir=
uses and 
dangerous content by =
MailScanner, and is 
believed to be clean. =




So it should be wd-ipppwgraster=




 















From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Tuesday, April 26, 201=
1 9:35
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.o=
rg

Subject: Re: [IPP] (Another)=
 New
PWG Raster Format draft posted






 



Hi Glen,



No - our PWG Naming Policy requires that the first part

of the filename be the responsible working group.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box=
 221 
Grand Marais, MI 49839

  906-494-2434














On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:



Since the title of document is called the "PWG Rater Format&qu=
ot;
I believe

we should change the file name to wd-pwgraster10-xxxxx instead of

wd-ippraster10-xxxxx



Glen





-----Original Message-----

From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet

Sent: Saturday, March 26, 2011 9:37 PM

To: ipp@pwg.org

Subject: [IPP] (Another) New PWG Raster Format draft posted











All,



The previous updated draft of the PWG Raster Format has two whole

subsections accidentally deleted from it... Here is a newer and even

better version with the lost subsections added back in along with the

IANA IPP registration templates for good measure:



  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-=
rev.pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.=
pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.=
docx



The -rev version shows the changes from the last "good" version (=
Feb

23rd)...



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp



--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp












 






Ops, you don’t include PWG
normally; but here it is part of name; that is Raster is not the name ̶=
0;PWG
Raster”; correct



 















From:
ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie, Glen

Sent: Tuesday, April 26, 201=
1 9:41
AM

To: Ira McDonald

Cc: ipp@pwg.org

Subject: RE: [IPP] (Another)=
 New
PWG Raster Format draft posted






 



So it should be wd-ipppwgraster=




 















From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Tuesday, April 26, 201=
1 9:35
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.o=
rg

Subject: Re: [IPP] (Another)=
 New
PWG Raster Format draft posted






 



Hi Glen,



No - our PWG Naming Policy requires that the first part

of the filename be the responsible working group.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box=
 221 
Grand Marais, MI 49839

  906-494-2434



 =







On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:



Since the title of document is called the "PWG Rater Format&qu=
ot;
I believe

we should change the file name to wd-pwgraster10-xxxxx instead of

wd-ippraster10-xxxxx



Glen





-----Original Message-----

From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet

Sent: Saturday, March 26, 2011 9:37 PM

To: ipp@pwg.org

Subject: [IPP] (Another) New PWG Raster Format draft posted











All,



The previous updated draft of the PWG Raster Format has two whole

subsections accidentally deleted from it... Here is a newer and even

better version with the lost subsections added back in along with the

IANA IPP registration templates for good measure:



  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-=
rev.pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.=
pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.=
docx



The -rev version shows the changes from the last "good" version (=
Feb

23rd)...



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp



--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp












 





-- 

This message has been scanned for viruses and 

dangerous content by MailScanner, and is 

believed to be clean. 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0430.F8ACDC92--

--===============0651289740==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0651289740==--

From ipp-bounces@pwg.org  Tue Apr 26 11:06:30 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F093E077C for ; Tue, 26 Apr 2011 11:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUxwpmJv+Eb0 for ; Tue, 26 Apr 2011 11:06:29 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBCE076A for ; Tue, 26 Apr 2011 11:06:29 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BDE6D795C7; Tue, 26 Apr 2011 14:06:13 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 804017957F for ; Tue, 26 Apr 2011 14:05:58 -0400 (EDT)
MIME-version: 1.0
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LK90032YU5IOLB1@mail-out.apple.com> for ipp@pwg.org; Tue, 26 Apr 2011 11:05:57 -0700 (PDT)
X-AuditID: 11807134-b7c8cae000005108-0f-4db7098443ef
Received: from [17.151.72.128] (Unknown_Domain [17.151.72.128]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id 9D.CC.20744.48907BD4; Tue, 26 Apr 2011 11:05:57 -0700 (PDT)
Subject: Re: [IPP] (Another) New PWG Raster Format draft posted
From: Michael Sweet 
In-reply-to: 
Date: Tue, 26 Apr 2011 11:05:56 -0700
Message-id: 
References: <4FC3E57E-91F6-4E75-A677-7196660D3792@apple.com>   
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1617120244=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: BDE6D795C7.A9D1C
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1617120244==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_5wn0D9OJ/dVJiGRQR8NIAg)"


--Boundary_(ID_5wn0D9OJ/dVJiGRQR8NIAg)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

Glen, the filename doesn't need to reflect the whole document title. Also, we'd need to change the charter to reflect the new name.

I really don't see the need to change the filename...

On Apr 26, 2011, at 9:40 AM, Petrie, Glen wrote:

> So it should be wd-ipppwgraster
>  
> From: Ira McDonald [mailto:blueroofmusic@gmail.com] 
> Sent: Tuesday, April 26, 2011 9:35 AM
> To: Petrie, Glen; Ira McDonald
> Cc: Michael Sweet; ipp@pwg.org
> Subject: Re: [IPP] (Another) New PWG Raster Format draft posted
>  
> Hi Glen,
> 
> No - our PWG Naming Policy requires that the first part
> of the filename be the responsible working group.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.com
> Christmas through April:
>   579 Park Place  Saline, MI  48176
>   734-944-0094
> May to Christmas:
>   PO Box 221  Grand Marais, MI 49839
>   906-494-2434
> 
> 
> 
> On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen  wrote:
> Since the title of document is called the "PWG Rater Format" I believe
> we should change the file name to wd-pwgraster10-xxxxx instead of
> wd-ippraster10-xxxxx
> 
> Glen
> 
> 
> -----Original Message-----
> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
> Michael Sweet
> Sent: Saturday, March 26, 2011 9:37 PM
> To: ipp@pwg.org
> Subject: [IPP] (Another) New PWG Raster Format draft posted
> 
> All,
> 
> The previous updated draft of the PWG Raster Format has two whole
> subsections accidentally deleted from it... Here is a newer and even
> better version with the lost subsections added back in along with the
> IANA IPP registration templates for good measure:
> 
>   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
>   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf
>   ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.docx
> 
> The -rev version shows the changes from the last "good" version (Feb
> 23rd)...
> 
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>  

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_5wn0D9OJ/dVJiGRQR8NIAg)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

Glen, the filename doesn't need to reflect the whole document title. Also, we'd need to change the charter to reflect the new name.

I really don't see the need to change the filename...

On Apr 26, 2011, at 9:40 AM, Petrie, Glen wrote:
















So it should be wd-ipppwgraster
 












From: Ira McDonald
[mailto:blueroofmusic@gmail.com] 

Sent: Tuesday, April 26, 2011 9:35
AM

To: Petrie, Glen; Ira McDonald

Cc: Michael Sweet; ipp@pwg.org

Subject: Re: [IPP] (Another) New
PWG Raster Format draft posted



 
Hi Glen,



No - our PWG Naming Policy requires that the first part

of the filename be the responsible working group.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

http://sites.google.com/site/blueroofmusic

http://sites.google.com/site/highnorthinc

mailto:blueroofmusic@gmail.com

Christmas through April:

  579 Park Place 
 Saline, MI 
 48176

  734-944-0094

May to Christmas:

  PO Box 221 
Grand Marais, MI 49839

  906-494-2434








On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen <glen.petrie@eitc.epson.com>
wrote:
Since the title of document is called the "PWG Rater Format"
I believe

we should change the file name to wd-pwgraster10-xxxxx instead of

wd-ippraster10-xxxxx



Glen





-----Original Message-----

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of

Michael Sweet

Sent: Saturday, March 26, 2011 9:37 PM

To: ipp@pwg.org

Subject: [IPP] (Another) New PWG Raster Format draft posted








All,



The previous updated draft of the PWG Raster Format has two whole

subsections accidentally deleted from it... Here is a newer and even

better version with the lost subsections added back in along with the

IANA IPP registration templates for good measure:



  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.docx



The -rev version shows the changes from the last "good" version (Feb

23rd)...



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.org/mailman/listinfo/ipp



--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

https://www.pwg.org/mailman/listinfo/ipp









 













________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair





-- 

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_5wn0D9OJ/dVJiGRQR8NIAg)--

--===============1617120244==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1617120244==--

From ipp-bounces@pwg.org  Tue Apr 26 11:21:59 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3EE07CE for ; Tue, 26 Apr 2011 11:21:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLrWUSq9HC-S for ; Tue, 26 Apr 2011 11:21:57 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 76499E0758 for ; Tue, 26 Apr 2011 11:21:57 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id B21A3795CF; Tue, 26 Apr 2011 14:21:40 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 819897953C for ; Tue, 26 Apr 2011 14:21:27 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Apr 2011 11:21:26 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] (Another) New PWG Raster Format draft posted
Date: Tue, 26 Apr 2011 11:21:25 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] (Another) New PWG Raster Format draft posted
Thread-Index: AcwEPJv1JRi3yH+1Sc2Eh8A3pv2qYQAAfYyQ
References: <4FC3E57E-91F6-4E75-A677-7196660D3792@apple.com>    
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 26 Apr 2011 18:21:26.0663 (UTC) FILETIME=[C16E8170:01CC043E]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1646392848=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: B21A3795CF.A8E1B
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1646392848==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC043E.C0DCEC0B"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC043E.C0DCEC0B
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Oh!  Ok!

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Tuesday, April 26, 2011 11:06 AM
To: Petrie, Glen
Cc: Ira McDonald; ipp@pwg.org
Subject: Re: [IPP] (Another) New PWG Raster Format draft posted

=20

Glen, the filename doesn't need to reflect the whole document title.
Also, we'd need to change the charter to reflect the new name.

=20

I really don't see the need to change the filename...

=20

On Apr 26, 2011, at 9:40 AM, Petrie, Glen wrote:





So it should be wd-ipppwgraster

=20

________________________________

From: Ira McDonald [mailto:blueroofmusic@gmail.com]=20
Sent: Tuesday, April 26, 2011 9:35 AM
To: Petrie, Glen; Ira McDonald
Cc: Michael Sweet; ipp@pwg.org
Subject: Re: [IPP] (Another) New PWG Raster Format draft posted

=20

Hi Glen,

No - our PWG Naming Policy requires that the first part
of the filename be the responsible working group.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
=20
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434






On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen
 wrote:

Since the title of document is called the "PWG Rater Format" I believe
we should change the file name to wd-pwgraster10-xxxxx instead of
wd-ippraster10-xxxxx

Glen


-----Original Message-----
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet
Sent: Saturday, March 26, 2011 9:37 PM
To: ipp@pwg.org
Subject: [IPP] (Another) New PWG Raster Format draft posted


All,

The previous updated draft of the PWG Raster Format has two whole
subsections accidentally deleted from it... Here is a newer and even
better version with the lost subsections added back in along with the
IANA IPP registration templates for good measure:

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf
  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.docx

The -rev version shows the changes from the last "good" version (Feb
23rd)...

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

=20

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC043E.C0DCEC0B
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable























Oh!  Ok!



 















From: Michael =
Sweet
[mailto:msweet@apple.com] 

Sent: Tuesday, April 26, 2011
11:06 AM

To: Petrie, Glen

Cc: Ira McDonald; ipp@pwg.or=
g

Subject: Re: [IPP] (Another)=
 New
PWG Raster Format draft posted






 



Glen, the filename doesn't need to reflect the whole document title.
Also, we'd need to change the charter to reflect the new name.






 









I really don't see the need to change the filename...









 









On Apr 26, 2011, at 9:40 AM, Petrie, Glen wrote:<=
/font>



















So it should be wd-ipppwgraster



 















From: Ira McDo=
nald
[mailto:blueroofmusic@gmail.com] 

Sent: Tuesday, April 26, 201=
1 9:35
AM

To: Petrie, Glen; Ira McDona=
ld

Cc: Michael Sweet; ipp@pwg.org

Subject: Re: [IPP] (Another)=
 New
PWG Raster Format draft posted






 



Hi Glen,



No - our PWG Naming Policy requires that the first part

of the filename be the responsible working group.



Cheers,

- Ira



Ira McDonald (Musician / Software Architect)

Chair - Linux Foundation Open Printing WG

Co-Chair - IEEE-ISTO PWG IPP WG

Co-Chair - TCG Hardcopy WG

IETF Designated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc

ht=
tp://sites.google.com/site/blueroofmusic

http://sites.google.com/sit=
e/highnorthinc

mailto:blueroo=
fmusic@gmail.com

Christmas through April:

  579 Park Place  Saline, MI  =
48176

  734-944-0094

May to Christmas:

  PO Box 221 
Grand Marais, MI 49839

  906-494-2434


















On Tue, Apr 26, 2011 at 11:29 AM, Petrie, Glen <glen.petrie@eitc.epson.com&g=
t;
wrote:



Since the title of document is called the "PWG Rater Format&qu=
ot;
I believe

we should change the file name to wd-pwgraster10-xxxxx instead of

wd-ippraster10-xxxxx



Glen





-----Original Message-----

From: ipp-bounces@pwg.org [mailt=
o:ipp-bounces@pwg.org] On Behalf Of
Michael Sweet

Sent: Saturday, March 26, 2011 9:37 PM

To: ipp@pwg.org

Subject: [IPP] (Another) New PWG Raster Format draft posted











All,



The previous updated draft of the PWG Raster Format has two whole

subsections accidentally deleted from it... Here is a newer and even

better version with the lost subsections added back in along with the

IANA IPP registration templates for good measure:



  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-=
rev.pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.=
pdf

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.=
docx



The -rev version shows the changes from the last "good" version (=
Feb

23rd)...



________________________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair





--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp



--

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.



_______________________________________________

ipp mailing list

ipp@pwg.org

http=
s://www.pwg.org/mailman/listinfo/ipp












 









 











______________=
__________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 









--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC043E.C0DCEC0B--

--===============1646392848==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1646392848==--

From ipp-bounces@pwg.org  Tue Apr 26 16:06:25 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24C0E06B5 for ; Tue, 26 Apr 2011 16:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArDphsBd4u+Z for ; Tue, 26 Apr 2011 16:06:24 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id C2C15E07A3 for ; Tue, 26 Apr 2011 16:06:24 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 849CB795E3; Tue, 26 Apr 2011 19:06:09 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 7987C795E0 for ; Tue, 26 Apr 2011 19:05:58 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 Apr 2011 16:05:57 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 26 Apr 2011 16:05:54 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PWG Raster comtinue
Thread-Index: AcwEZlkXThlR8IEvT8KnUey7cMXFEQ==
From: "Petrie, Glen" 
To: , "Michael Sweet" 
X-OriginalArrivalTime: 26 Apr 2011 23:05:57.0701 (UTC) FILETIME=[80902F50:01CC0466]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] PWG Raster comtinue
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1092428911=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 849CB795E3.A9AE4
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1092428911==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0466.7EE8F1C0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0466.7EE8F1C0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Mike,

=20

We still seem to differ on the adding page number and flip/orientation.
I hope we agree on adding the driver data fields to the PWG Raster.=20

=20

An unusual request:  I would like to understand better the need for
flip/orientation in a raster.    Since I do not know who or what company
may have requested the flip/orientation data, would it be possible for
you to send an email to the individuals who requested the
flip/orientation asking if they can state why they need the data and why
they are not expecting the raster to be in the correct flip/orientation
that the printer would need to print the specified print job.=20

=20

Glen

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0466.7EE8F1C0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
















Mike,



 



We still seem to differ on the adding page number and
flip/orientation.   I hope we agree on adding the driver data fie=
lds
to the PWG Raster. 



 



An unusual request:  I would like to understand
better the need for flip/orientation in a raster.    Since I=
 do
not know who or what company may have requested the flip/orientation data, =
would
it be possible for you to send an email to the individuals who requested the
flip/orientation asking if they can state why they need the data and why th=
ey
are not expecting the raster to be in the correct flip/orientation that the
printer would need to print the specified print job. 



 



Glen



 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC0466.7EE8F1C0--

--===============1092428911==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1092428911==--

From ipp-bounces@pwg.org  Wed Apr 27 07:44:44 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9824DE07A9 for ; Wed, 27 Apr 2011 07:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whdHzyR3A-cZ for ; Wed, 27 Apr 2011 07:44:40 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2D4E07AD for ; Wed, 27 Apr 2011 07:44:40 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 3189D795EA; Wed, 27 Apr 2011 10:44:12 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id E9E55795D4 for ; Wed, 27 Apr 2011 10:43:52 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 Apr 2011 07:43:51 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 27 Apr 2011 07:43:50 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PWG Raster comtinue
Thread-Index: AcwEZlkXThlR8IEvT8KnUey7cMXFEQAfT0IA
References: 
From: "Petrie, Glen" 
To: "Petrie, Glen" , , "Michael Sweet" 
X-OriginalArrivalTime: 27 Apr 2011 14:43:51.0594 (UTC) FILETIME=[866AD0A0:01CC04E9]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] RE: PWG Raster comtinue
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============2111980492=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 3189D795EA.AA080
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============2111980492==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC04E9.859535C5"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC04E9.859535C5
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

After thinking on it I decided I should explain in more detail my
objection to flip/orientation specification in the raster in more
detail.

=20

All printers should be able to consume (PWG) Raster but it more likely
that most mid and higher end printer will consume PDF.  It is also more
likely that it will be lower end printers, those with limited resources,
which will directly consume (PWG) Raster.  Since by definition they have
limited resources it would be burden to have these printers perform
flip/orientation transforms that require very large buffers that would
basically have to hold an entire page worth of raster data.  (example; a
typical Epson inkjet can print width is US Legal and has a specified
maximum page length of 44 inches.   Lets assume we are just talking 24
bit RGB data on legal size media at high quality print DPI of 1440v x
2880h or 8.5*2880*3x1440*13 or about 1.3 gb.  Big and expensive.  For
larger media size and if CMYK or CMYKLcLm data was sent to the printer
we are talking very large buffers.  I am not sure if a printer has to
support all of color-spaces defined in the (PWG) Raster; but the largest
on is 30 byte per pixel!!! That really big and expensive.=20

=20

=20

In the old days, when there were printer drivers; they handled producing
raster content for the target printer in the orientation the printer
needed.  In the new order of things, where there are no printer drivers;
it is up to the producer of the raster to put the content in a
"standard" format for printer and not to expect the printer to perform
additional transforms the raster content.=20=20

=20

*	Raster must continue to mean ready for the printer to consume.=20=20
*	Raster must be targeted to specific printer or at least printer
model.  If the print-job is re-targeted to a different printer then the
raster may have to be regenerated to the new target printer.
*	The Alternate to the above is the raster producer will orient
and flip the print content exactly the same for all printers and based
solely on the user print intent.  Then it is the print vendor issue to
consume this standardized format and ensure the correct output is
obtained.  In this case, there is no need to put this information in the
raster header since it has no meaning or value to printer.

=20

=20

In conclusion, I would have not objection to the data being present in
the header only if something like the follow clause were added.=20=20

"The orientation or flip information is provided only as informational
data.  The orientation or flip data SHALL NOT require the printer to
perform any transforms to the raster content to print the raster content
to meet the end-user's print intent."

=20

Glen

=20

=20

=20

=20

________________________________

From: Petrie, Glen=20
Sent: Tuesday, April 26, 2011 4:06 PM
To: ipp@pwg.org; 'Michael Sweet'
Cc: Petrie, Glen
Subject: PWG Raster comtinue

=20

Mike,

=20

We still seem to differ on the adding page number and flip/orientation.
I hope we agree on adding the driver data fields to the PWG Raster.=20

=20

An unusual request:  I would like to understand better the need for
flip/orientation in a raster.    Since I do not know who or what company
may have requested the flip/orientation data, would it be possible for
you to send an email to the individuals who requested the
flip/orientation asking if they can state why they need the data and why
they are not expecting the raster to be in the correct flip/orientation
that the printer would need to print the specified print job.=20

=20

Glen

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC04E9.859535C5
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

















After thinking on it I decided I sho=
uld
explain in more detail my objection to flip/orientation specification in the
raster in more detail.



 



All printers should be able to consu=
me (PWG)
Raster but it more likely that most mid and higher end printer will consume
PDF.  It is also more likely that it will be lower end printers, those
with limited resources, which will directly consume (PWG) Raster.  Sin=
ce
by definition they have limited resources it would be burden to have these
printers perform flip/orientation transforms that require very large buffers
that would basically have to hold an entire page worth of raster data. &nbs=
p;(example;
a typical Epson inkjet can print width is US Legal and has a specified maxi=
mum
page length of 44 inches.   Lets assume we are just talking 24 bit
RGB data on legal size media at high quality print DPI of 1440v x 2880h or =
8.5*2880*3x1440*13
or about 1.3 gb.  Big and expensive.  For larger media size and if
CMYK or CMYKLcLm data was sent to the printer we are talking very large
buffers.  I am not sure if a printer has to support all of color-spaces
defined in the (PWG) Raster; but the largest on is 30 byte per pixel!!! That
really big and expensive. 



 



 



In the old days, when there were pri=
nter
drivers; they handled producing raster content for the target printer in the
orientation the printer needed.  In the new order of things, where the=
re
are no printer drivers; it is up to the producer of the raster to put the
content in a “standard” format for printer and not to expect the
printer to perform additional transforms the raster content.  



 



    
 
  • Raster
     must continue to mean ready for the printer to consume.  
    • 
 
  • Raster
     must be targeted to specific printer or at least printer model.  =
If
     the print-job is re-targeted to a different printer then the raster may
     have to be regenerated to the new target printer.
    • 
 
  • The
     Alternate to the above is the raster producer will orient and flip the
     print content exactly the same for all printers and based solely on the
     user print intent.  Then it is the print vendor issue to consume =
this
     standardized format and ensure the correct output is obtained.  In
     this case, there is no need to put this information in the raster head=
er
     since it has no meaning or value to printer.<=
/li>




 



 



In conclusion, I would have not
objection to the data being present in the header only if something like the
follow clause were added.  



“The
orientation or flip information is provided only as informational data. &nb=
sp;The
orientation or flip data SHALL NOT require the printer to perform any
transforms to the raster content to print the raster content to meet the
end-user’s print intent.”



 



Glen



 



 



 



 















From: Petrie, =
Glen 

Sent: Tuesday, April 26, 201=
1 4:06
PM

To: ipp@pwg.org; 'Michael Sw=
eet'

Cc: Petrie, Glen

Subject: PWG Raster comtinue=







 



Mike,



 



We still seem to differ on the adding page number and
flip/orientation.   I hope we agree on adding the driver data fie=
lds
to the PWG Raster. 



 



An unusual request:  I would like to understand
better the need for flip/orientation in a raster.    Since I=
 do
not know who or what company may have requested the flip/orientation data,
would it be possible for you to send an email to the individuals who reques=
ted
the flip/orientation asking if they can state why they need the data and why
they are not expecting the raster to be in the correct flip/orientation that
the printer would need to print the specified print job. =




 



Glen



 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC04E9.859535C5--

--===============2111980492==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============2111980492==--

From ipp-bounces@pwg.org  Thu Apr 28 04:03:37 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1377E06B1 for ; Thu, 28 Apr 2011 04:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r841aiKJxqV for ; Thu, 28 Apr 2011 04:03:34 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id F0353E0659 for ; Thu, 28 Apr 2011 04:03:33 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 398E0795BE; Thu, 28 Apr 2011 07:03:10 -0400 (EDT)
X-Original-To: IPP@pwg.org
Delivered-To: ipp@pwg.org
Received: from USA7109MR002.ACS-INC.COM (usa7109mr002.acs-inc.com [63.101.151.11]) by pwg.org (Postfix) with ESMTP id E76EA795B8 for ; Thu, 28 Apr 2011 07:02:54 -0400 (EDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnAAAD9JuU0Nl9IPmWdsb2JhbACCYpUujW4UAQEBAQEICwsHFCXCcoMZgl0EhgmMb4oN
X-IronPort-AV: E=Sophos;i="4.64,280,1301893200"; d="scan'208,217";a="34270528"
Received: from usa7061gw002.na.xerox.net ([13.151.210.15]) by USA7109MR002.ACS-INC.COM with ESMTP; 28 Apr 2011 06:02:32 -0500
Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA7061GW002.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 04:02:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 28 Apr 2011 04:02:03 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WS-Discovery
Thread-Index: AcwBLlIsyY5dNihZSv6AUu6Ogpr/agDCdpuQAFZsjLA=
References: <15713B46EB868E4FB0CF6D8BFD33617E47E3DB24@TK5EX14MBXC114.redmond.corp.microsoft.com>
From: "Zehler, Peter" 
To: 
X-OriginalArrivalTime: 28 Apr 2011 11:02:03.0690 (UTC) FILETIME=[B4B390A0:01CC0593]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] FW: WS-Discovery
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1645284258=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 398E0795BE.AAEC8
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1645284258==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC0593.B4917FB5"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0593.B4917FB5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

Below is the only thing I could find in the specifications relating to
Web Service Discovery that supported the position that it is Web Service
(i.e. SOAP) specific.  I could not locate any record of my conversations
about using WS-Discovery for IPP nor recall any of the individuals with
whom I had the conversation.  It was early in the creation of Web
Services for Devices which was about 8 years ago.  It was the consensus
of the group that the advertised endpoint must be a Web Service.

Pete

=20

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20

From: Zehler, Peter=20
Sent: Tuesday, April 26, 2011 1:57 PM
To: 'Justin Hutchings'
Subject: RE: WS-Discovery

=20

Justin,

=46rom my readings of the specs I did not see any reason that the
WS-Discovery, WS-Transfer and WS-MetadataExchange specifications would
preclude the advertising of services that are not Web Services based.
However the Devices Profile for Web Services specification contains a
chain of definitions that does seem to limit the applicability.  I tried
to find the mail thread from long ago that I had when I was looking into
using WSD to also make the IPP endpoint visible.  I could not locate the
mail notes.  As I have stated I have no objection to making IPP
discoverable using WSD.  Since many vendors currently use WSD we just
need to insure that it is acceptable to apply the technology to non-SOAP
based services.

Pete

=20

PS If you have no objections, I'll post this response to the IPP mail
list.

=20

HOSTED SERVICE=20=20

A distinguished type of SERVICE that is hosted by another SERVICE. The
lifetime=20

of the HOSTED SERVICE is a subset of the lifetime of its host. The
HOSTED

SERVICE is visible (not encapsulated) and is addressed separately from
its host.=20

Each HOSTED SERVICE has exactly one host. (The relationship is not
transitive.)

=20

SERVICE=20=20

A network endpoint that receives and/or sends MESSAGEs to provide a
service.

=20

MESSAGE=20

Protocol elements that are exchanged, usually over a network, to affect
a Web=20

service. Always includes a SOAP ENVELOPE. Typically also includes
transport=20

framing information such as HTTP headers, TCP headers, and IP headers.

=20

SOAP ENVELOPE=20=20

An XML Infoset that consists of a document information item [XML
Infoset] with=20

exactly one member in its [children] property, which MUST be the SOAP

Envelope [SOAP 1.2] element information item.

=20

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701=20

=20

From: Justin Hutchings [mailto:justhu@microsoft.com]=20
Sent: Friday, April 22, 2011 4:48 PM
To: Zehler, Peter
Subject: WS-Discovery

=20

Peter,

Did you have a reference to the doc published on W3C that needs revision
for us to enable WS-Discovery on IPP? I'd like to review with some folks
on the Microsoft side.=20

=20

Thanks!

Justin

=20

Justin Hutchings | Program Manager |
Windows\DNT\DeviceConnectivity::Printing and Imaging

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC0593.B4917FB5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


All,
Below is the only thing I could find in the specifications =
relating to Web Service Discovery that supported the position that it is We=
b Service (i.e. SOAP) specific.  I could not locate any record of my c=
onversations about using WS-Discovery for IPP nor recall any of the individ=
uals with whom I had the conversation.  It was early in the creation o=
f Web Services for Devices which was about 8 years ago.  It was the co=
nsensus of the group that the advertised endpoint must be a Web Service.
Pete<=
o:p>
 
 
Peter Zehler

Xerox Research Center Webster
=
Email: Peter.Zehler@Xerox.com=

Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.=

M/S 128-25E
W=
ebster NY, 14580-9701 
 
From:=
 Zeh=
ler, Peter 
Sent: Tuesday, April 26, 2011 1:57 PM
To: '=
Justin Hutchings'
Subject: RE: WS-Discovery
=

 
=
Justin,
From my readings of the specs I did not =
see any reason that the WS-Discovery, WS-Transfer and WS-MetadataExchange s=
pecifications would preclude the advertising of services that are not Web S=
ervices based.  However the Devices Profile for Web Services specifica=
tion contains a chain of definitions that does seem to limit the applicabil=
ity.  I tried to find the mail thread from long ago that I had when I =
was looking into using WSD to also make the IPP endpoint visible.  I c=
ould not locate the mail notes.  As I have stated I have no objection =
to making IPP discoverable using WSD.  Since many vendors currently us=
e WSD we just need to insure that it is acceptable to apply the technology =
to non-SOAP based services.
Pete
 
PS If you have no objections, I’ll pos=
t this response to the IPP mail list.
 
HOSTED SERVICE  
A distinguished =
type of SERVICE that is hosted by another SERVICE. The lifetime 
of the HOSTED SERVICE is a=
 subset of the lifetime of its host. The HOSTED
SERVICE is visible (not encaps=
ulated) and is addressed separately from its host. 
Each HOSTED SERVICE has ex=
actly one host. (The relationship is not transitive.)
=

 =

SERVICE  =

A netwo=
rk endpoint that receives and/or sends MESSAGEs to provide a service.<=
/p>
 
MESSAGE 
Protocol e=
lements that are exchanged, usually over a network, to affect a Web 
service. =
Always includes a SO=
AP ENVELOPE. Typically also includes transport 
framing information suc=
h as HTTP headers, TCP headers, and IP headers.
 
SOAP ENVELOPE  =

An XML =
Infoset that consists of a document information item [XML Infoset] with 
exact=
ly one member in its [children] property, which MUST be the SOAP=

Envelope [SOA=
P 1.2] element information item.
 
Peter=
 Zehler

Xerox Researc=
h Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
=
FAX: (585) 265-7441
US Mai=
l: Peter Zehler
Xerox Cor=
p.
800 Phillips Rd.=

M/S 128-25E
Webster NY, 14580-9701 
 
From: Justin Hutchings [mailto:justhu@microsoft.com] <=
br>Sent: Friday, April 22, 2011 4:48 PM
To: Zehler, Peter<=
br>Subject: WS-Discovery
 
Peter,
Did you have a reference to the doc published on W3C =
that needs revision for us to enable WS-Discovery on IPP? I’d like to=
 review with some folks on the Microsoft side. 
 
Thanks!
Justin
 
Justin =
Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printi=
ng and Imaging
 <=
/p>

--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


------_=_NextPart_001_01CC0593.B4917FB5--

--===============1645284258==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1645284258==--

From ipp-bounces@pwg.org  Thu Apr 28 09:52:08 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586AEE0714 for ; Thu, 28 Apr 2011 09:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJvvrsF0Hg2x for ; Thu, 28 Apr 2011 09:52:07 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id B20EEE0670 for ; Thu, 28 Apr 2011 09:52:07 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 61BFF795CA; Thu, 28 Apr 2011 12:51:52 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 3DFA9795C7 for ; Thu, 28 Apr 2011 12:51:38 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Apr 2011 09:51:38 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 28 Apr 2011 09:51:36 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: (PWG) Raster Question on what is required
Thread-Index: AcwFxCP6q2s9x8VgTa2xDhNMhww2Lw==
From: "Petrie, Glen" 
To: 
X-OriginalArrivalTime: 28 Apr 2011 16:51:38.0431 (UTC) FILETIME=[8A9F0CF0:01CC05C4]
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [IPP] (PWG) Raster Question on what is required
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0525202582=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 61BFF795CA.A7F0A
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0525202582==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC05C4.89BFA2FE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC05C4.89BFA2FE
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

In the (PWG) Raster, the specification states support for 16-bits per
color.  TIFF seems to the only image file format supporting it and even
the TIFF libraries I could find only support up to 8-bits per color.

=20

While I believe the (PWG) Raster specification indicates the range of
possible values; will or is there is a specification or compliance
requirements on what must be supported?  (The same would apply to color
spaces.)

=20

Or is the situation that the printer provides it capabilities, which
must be one or more of the of the (PWG) Raster values.  Thus, there are
no mandatory values just a possible range of supported values.=20

=20

glen


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC05C4.89BFA2FE
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
















In the (PWG) Raster, the specification states support =
for
16-bits per color.  TIFF seems to the only image file format supportin=
g it
and even the TIFF libraries I could find only support up to 8-bits per colo=
r.



 



While I believe the (PWG) Raster specification indicat=
es
the range of possible values; will or is there is a specification or compli=
ance
requirements on what must be supported?  (The same would apply to color
spaces.)



 



Or is the situation that the printer provides it
capabilities, which must be one or more of the of the (PWG) Raster values.&=
nbsp;
Thus, there are no mandatory values just a possible range of supported valu=
es. 



 



glen






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC05C4.89BFA2FE--

--===============0525202582==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0525202582==--

From ipp-bounces@pwg.org  Thu Apr 28 10:10:02 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362BDE0698 for ; Thu, 28 Apr 2011 10:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTRNCM2Px8Xf for ; Thu, 28 Apr 2011 10:10:00 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A7E069A for ; Thu, 28 Apr 2011 10:10:00 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 1CF4A795D6; Thu, 28 Apr 2011 13:09:45 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 27BB0795C8 for ; Thu, 28 Apr 2011 13:09:31 -0400 (EDT)
MIME-version: 1.0
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LKD00EG5GLNZON1@mail-out.apple.com> for ipp@pwg.org; Thu, 28 Apr 2011 10:09:23 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-8e-4db99f41e953
Received: from [17.151.74.218] (Unknown_Domain [17.151.74.218]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 03.0E.23242.24F99BD4; Thu, 28 Apr 2011 10:09:23 -0700 (PDT)
Subject: Re: [IPP] (PWG) Raster Question on what is required
From: Michael Sweet 
In-reply-to: 
Date: Thu, 28 Apr 2011 10:09:21 -0700
Message-id: <89169579-F912-4E85-B1EA-835F8975E4EC@apple.com>
References: 
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============2130776443=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 1CF4A795D6.A8EBB
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============2130776443==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_1n0ejjlc/dOFp6oo1QOr4A)"


--Boundary_(ID_1n0ejjlc/dOFp6oo1QOr4A)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Apr 28, 2011, at 9:51 AM, Petrie, Glen wrote:
> In the (PWG) Raster, the specification states support for 16-bits per color.  TIFF seems to the only image file format supporting it and even the TIFF libraries I could find only support up to 8-bits per color.

libtiff (the most widely-used TIFF library) supports 16-bits per color.

> While I believe the (PWG) Raster specification indicates the range of possible values; will or is there is a specification or compliance requirements on what must be supported?  (The same would apply to color spaces.)

I thought I had included this, but couldn't find any requirements in the PWG Raster or IPP Everywhere specs.

My thought was to require sgray-1 and sgray-8 for all printers and srgb-8 for color printers. 

> Or is the situation that the printer provides it capabilities, which must be one or more of the of the (PWG) Raster values.  Thus, there are no mandatory values just a possible range of supported values.

I think for interoperability we want a minimum set for interoperability (and to address the use cases/design requirements). But most values of color space and bit depth should be optional.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_1n0ejjlc/dOFp6oo1QOr4A)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


In the (PWG) Raster, the specification=
 states support for 16-bits per color.  TIFF seems to the only image f=
ile format supporting it and even the TIFF libraries I could find only supp=
ort up to 8-bits per color.

libtiff (the most widely-used TIFF library) supports 16-=
bits per color.

While I believe the (PWG) Raster specification indicates t=
he range of possible values; will or is there is a specification or complia=
nce requirements on what must be supported?  (The same would apply to =
color spaces.)

<=
div>I thought I had included this, but couldn't find any requirements in th=
e PWG Raster or IPP Everywhere specs.

My thought w=
as to require sgray-1 and sgray-8 for all printers and srgb-8 for color pri=
nters. 

Or is the situation =
that the printer provides it capabilities, which must be one or more of the=
 of the (PWG) Raster values.  Thus, there are no mandatory values just=
 a possible range of supported values.

I think for interoperability we want a minimum set f=
or interoperability (and to address the use cases/design requirements). But=
 most values of color space and bit depth should be optional.


_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_1n0ejjlc/dOFp6oo1QOr4A)--

--===============2130776443==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============2130776443==--

From ipp-bounces@pwg.org  Thu Apr 28 10:22:17 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900BAE071F for ; Thu, 28 Apr 2011 10:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S50dkc89LFU for ; Thu, 28 Apr 2011 10:22:14 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8F88EE0701 for ; Thu, 28 Apr 2011 10:22:14 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D1E1A795DC; Thu, 28 Apr 2011 13:21:52 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 9B2C1795D6 for ; Thu, 28 Apr 2011 13:21:36 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Apr 2011 10:21:36 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] (PWG) Raster Question on what is required
Date: Thu, 28 Apr 2011 10:21:35 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] (PWG) Raster Question on what is required
Thread-Index: AcwFxxBUYhPCaxErT1u17ZagE+jgDAAAD5eQ
References:  <89169579-F912-4E85-B1EA-835F8975E4EC@apple.com>
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 28 Apr 2011 17:21:36.0158 (UTC) FILETIME=[BA266BE0:01CC05C8]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1321179790=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: D1E1A795DC.A8B90
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============1321179790==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC05C8.B994ED37"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC05C8.B994ED37
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Thursday, April 28, 2011 10:09 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] (PWG) Raster Question on what is required

=20

On Apr 28, 2011, at 9:51 AM, Petrie, Glen wrote:

=09

	In the (PWG) Raster, the specification states support for
16-bits per color.  TIFF seems to the only image file format supporting
it and even the TIFF libraries I could find only support up to 8-bits
per color.

=20

libtiff (the most widely-used TIFF library) supports 16-bits per color.

=20

I must be looking at the wrong version because TIFF 6.0 shows only
<8,8,8> http://www.libtiff.org/support.html=20





While I believe the (PWG) Raster specification indicates the range of
possible values; will or is there is a specification or compliance
requirements on what must be supported?  (The same would apply to color
spaces.)

=20

I thought I had included this, but couldn't find any requirements in the
PWG Raster or IPP Everywhere specs.

=20

Not in (PWG) Raster spec (I believe it would in section 4.3.4 or is
there another section)

The conformance section (6.x)  the "MUST" for attributes but not for
values=20

=20

My thought was to require sgray-1 and sgray-8 for all printers and
srgb-8 for color printers.=20

=20

Sound good to me.

=20

=09

	Or is the situation that the printer provides it capabilities,
which must be one or more of the of the (PWG) Raster values.  Thus,
there are no mandatory values just a possible range of supported values.

=20

I think for interoperability we want a minimum set for interoperability
(and to address the use cases/design requirements). But most values of
color space and bit depth should be optional.

=20

Ok, then from your color-spaces, the required bits-per-color would 1 and
8.  Also, the required bits-per-pixel would be 1, 8, 24

=20

One more time.  Does conformance to pwg-raster-back-side mean "the
printer will perform the indicated transforms" or this is an identifier
stating what the "state" of the back-side image is?

=20

=20

=20

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC05C8.B994ED37
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


















 



 















From: Michael =
Sweet
[mailto:msweet@apple.com] 

Sent: Thursday, April 28, 20=
11
10:09 AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] (PWG) Ras=
ter
Question on what is required






 









On Apr 28, 2011, at 9:51 AM, Petrie, Glen wrote:<=
/font>















In the (PWG) Raster, the specification states support =
for
16-bits per color.  TIFF seems to the only image file format supportin=
g it
and even the TIFF libraries I could find only support up to 8-bits per colo=
r.

















 






libtiff (the most widely-used TIFF library) supports 16-bits per co=
lor.









<=
span
style=3D'font-size:12.0pt;color:blue'> 



I must be looking at the wrong versi=
on because
TIFF 6.0 shows only <8,8,8> http://www.libtiff.org/support.html




















While I believe the (PWG) Ra=
ster
specification indicates the range of possible values; will or is there is a
specification or compliance requirements on what must be supported?  (=
The
same would apply to color spaces.)














 









I thought I had included this, but couldn't find any requirements in
the PWG Raster or IPP Everywhere specs.



 



Not in (PWG) Raster spec (I believe =
it would
in section 4.3.4 or is there another section)



The conformance section (6.x)  =
the “MUST”
for attributes but not for values 









 









My thought was to require sgray-1 and sgray-8 for all printers and
srgb-8 for color printers. 









<=
span
style=3D'font-size:12.0pt;color:blue'> 



Sound good to me.<=
/font>



 















Or is the situation that the
printer provides it capabilities, which must be one or more of the of the (=
PWG)
Raster values.  Thus, there are no mandatory values just a possible ra=
nge
of supported values.

















 






I think for interoperability we want a minimum set for interoperabi=
lity
(and to address the use cases/design requirements). But most values of color
space and bit depth should be optional.



 



Ok, then from your color-spaces, the=
 required
bits-per-color would 1 and 8.  Also, the required bits-per-pixel would=
 be 1,
8, 24



 



One more time.  Does conformanc=
e to
pwg-raster-back-side mean “the printer will perform the indicated
transforms” or this is an identifier stating what the “state=
221;
of the back-side image is?



 



 



 









 












______________=
__________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC05C8.B994ED37--

--===============1321179790==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1321179790==--

From ipp-bounces@pwg.org  Thu Apr 28 10:27:11 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5313CE06D0 for ; Thu, 28 Apr 2011 10:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24oCTANwSHWW for ; Thu, 28 Apr 2011 10:27:10 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 27DFDE0675 for ; Thu, 28 Apr 2011 10:27:10 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7A9B77952A; Thu, 28 Apr 2011 13:26:52 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 58B4C794A3 for ; Thu, 28 Apr 2011 13:26:40 -0400 (EDT)
MIME-version: 1.0
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LKD009D2HKYCQU0@mail-out.apple.com> for ipp@pwg.org; Thu, 28 Apr 2011 10:26:39 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-ee-4db9a34ecb3d
Received: from [17.151.74.218] (Unknown_Domain [17.151.74.218]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay16.apple.com (Apple SCV relay) with SMTP id 40.A9.12552.F43A9BD4; Thu, 28 Apr 2011 10:26:39 -0700 (PDT)
Subject: Re: [IPP] (PWG) Raster Question on what is required
From: Michael Sweet 
In-reply-to: 
Date: Thu, 28 Apr 2011 10:26:38 -0700
Message-id: 
References:  <89169579-F912-4E85-B1EA-835F8975E4EC@apple.com> 
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0625884149=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 7A9B77952A.A89F5
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============0625884149==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_d5JbCuNVk4ZuPGzJbrHvwQ)"


--Boundary_(ID_d5JbCuNVk4ZuPGzJbrHvwQ)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

On Apr 28, 2011, at 10:21 AM, Petrie, Glen wrote:
> ...
> libtiff (the most widely-used TIFF library) supports 16-bits per color.
>=20=20
> I must be looking at the wrong version because TIFF 6.0 shows only <8,8,8=
> http://www.libtiff.org/support.html

Hmm, they must have removed 16-bit support at one point - back when I was d=
oing print software for SGI workstations the "Sam Leffler" version of libti=
ff supported it...

> ...=20
> I think for interoperability we want a minimum set for interoperability (=
and to address the use cases/design requirements). But most values of color=
 space and bit depth should be optional.
>=20=20
> Ok, then from your color-spaces, the required bits-per-color would 1 and =
8.  Also, the required bits-per-pixel would be 1, 8, 24

Right.

> One more time.  Does conformance to pwg-raster-back-side mean =93the prin=
ter will perform the indicated transforms=94 or this is an identifier stati=
ng what the =93state=94 of the back-side image is?

Conformance for a printer means that it will advertise what it needs. For a=
 client it means the client will transform the back side images as indicate=
d by the printer.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_d5JbCuNVk4ZuPGzJbrHvwQ)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


...
libtiff (the=
 most widely-used TIFF library) supports 16-bits per color.
 
... 
I think for interoperability we want a=
 minimum set for interoperability (and to address the use cases/design requ=
irements). But most values of color space and bit depth should be optional.=

<=
span style=3D"font-size: 12pt; font-family: Cambria; color: blue; ">&n=
bsp;
Ok, then=
 from your color-spaces, the required bits-per-color would 1 and 8.  A=
lso, the required bits-per-pixel would be 1, 8, 24=

=

=


Right.

On=
e more time.  Does conformance to pwg-raster-back-side mean =93the pri=
nter will perform the indicated transforms=94 or this is an identifier stat=
ing what the =93state=94 of the back-side image is?

Conformance for a prin=
ter means that it will advertise what it needs. For a client it means the c=
lient will transform the back side images as indicated by the printer.



_______________________________________________=
_________________________
Michael Sweet, Senior Printing System Engineer=
, PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_d5JbCuNVk4ZuPGzJbrHvwQ)--

--===============0625884149==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0625884149==--

From ipp-bounces@pwg.org  Thu Apr 28 13:23:26 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8593E06D7 for ; Thu, 28 Apr 2011 13:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqyAwUDELz9z for ; Thu, 28 Apr 2011 13:23:24 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 73B24E072B for ; Thu, 28 Apr 2011 13:23:24 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E6584795FB; Thu, 28 Apr 2011 16:23:05 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id E0821795F5 for ; Thu, 28 Apr 2011 16:22:49 -0400 (EDT)
Received: from EEAEX03.us.epson.net ([148.130.32.21]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Apr 2011 13:22:48 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [IPP] (PWG) Raster Question on what is required
Date: Thu, 28 Apr 2011 13:22:46 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPP] (PWG) Raster Question on what is required
Thread-Index: AcwFyX5KkbXBchQLTc2W/aDzk6zoeQAFyiSw
References:  <89169579-F912-4E85-B1EA-835F8975E4EC@apple.com>  
From: "Petrie, Glen" 
To: "Michael Sweet" 
X-OriginalArrivalTime: 28 Apr 2011 20:22:48.0581 (UTC) FILETIME=[0A9E8350:01CC05E2]
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0916190509=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: E6584795FB.A977E
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0916190509==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC05E2.093981F8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC05E2.093981F8
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Mike,

=20

Question on your definition of bytes-per-line (BPL): You have it ending
at an octet (8-bit) but I have seen cases where the boundary is at the
word or 32-bit level.   In fact, I have seen were people clip a line by
changing the number of pixel per line but not the bytes-per-line.   What
has been your experience?   Suggestion: Leave the equation out of
specification and it is understood or is stated that new raster lines
begin at multiples of bpl.

=20

Glen

=20

=20

________________________________

From: Michael Sweet [mailto:msweet@apple.com]=20
Sent: Thursday, April 28, 2011 10:27 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject: Re: [IPP] (PWG) Raster Question on what is required

=20

On Apr 28, 2011, at 10:21 AM, Petrie, Glen wrote:

=09

	...

=09

	libtiff (the most widely-used TIFF library) supports 16-bits per
color.

=09=20

	I must be looking at the wrong version because TIFF 6.0 shows
only <8,8,8> http://www.libtiff.org/support.html

=20

Hmm, they must have removed 16-bit support at one point - back when I
was doing print software for SGI workstations the "Sam Leffler" version
of libtiff supported it...





...=20

I think for interoperability we want a minimum set for interoperability
(and to address the use cases/design requirements). But most values of
color space and bit depth should be optional.

=20

Ok, then from your color-spaces, the required bits-per-color would 1 and
8.  Also, the required bits-per-pixel would be 1, 8, 24

=20

Right.

=20

=09

	One more time.  Does conformance to pwg-raster-back-side mean
"the printer will perform the indicated transforms" or this is an
identifier stating what the "state" of the back-side image is?

=20

Conformance for a printer means that it will advertise what it needs.
For a client it means the client will transform the back side images as
indicated by the printer.

=20

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

=20


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01CC05E2.093981F8
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


















Mike,



 



Question on your definition of
bytes-per-line (BPL): You have it ending at an octet (8-bit) but I have seen
cases where the boundary is at the word or 32-bit level.   In fac=
t, I
have seen were people clip a line by changing the number of pixel per line =
but
not the bytes-per-line.   What has been your experience? &nb=
sp; Suggestion:
Leave the equation out of specification and it is understood or is stated t=
hat
new raster lines begin at multiples of bpl.



 



Glen



 



 















From: Michael =
Sweet
[mailto:msweet@apple.com] 

Sent: Thursday, April 28, 20=
11
10:27 AM

To: Petrie, Glen

Cc: ipp@pwg.org

Subject: Re: [IPP] (PWG) Ras=
ter
Question on what is required






 









On Apr 28, 2011, at 10:21 AM, Petrie, Glen wrote:=



















...





























libtiff (the most widely-used TIFF library) supports 16-bits per co=
lor.















<=
span
style=3D'font-size:12.0pt;color:blue'> 









I must be looking at the wrong versi=
on
because TIFF 6.0 shows only <8,8,8> http://www.libtiff.org/support=
.html




















 






Hmm, they must have removed 16-bit support at one point - back when=
 I
was doing print software for SGI workstations the "Sam Leffler"
version of libtiff supported it...




























... 









I think for interoperability we want a minimum set for interoperabi=
lity
(and to address the use cases/design requirements). But most values of color
space and bit depth should be optional.









 









Ok, then from your color-spaces, the
required bits-per-color would 1 and 8.  Also, the required bits-per-pi=
xel
would be 1, 8, 24















 






Right.









 





















One
more time.  Does conformance to pwg-raster-back-side mean “the
printer will perform the indicated transforms” or this is an identifi=
er
stating what the “state” of the back-side image is?




















 












Conformance for a printer means that it will advertise what it need=
s.
For a client it means the client will transform the back side images as
indicated by the printer.









 












______________=
__________________________________________________________

Michael Sweet, Senior Printing System Engineer, PWG Chair=










 






--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.




------_=_NextPart_001_01CC05E2.093981F8--

--===============0916190509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============0916190509==--

From ipp-bounces@pwg.org  Thu Apr 28 13:44:55 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9904E06C3 for ; Thu, 28 Apr 2011 13:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXjcpTzdRSCN for ; Thu, 28 Apr 2011 13:44:50 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 93EE3E0669 for ; Thu, 28 Apr 2011 13:44:50 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 223A579603; Thu, 28 Apr 2011 16:44:37 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 3C9C1795FE for ; Thu, 28 Apr 2011 16:44:23 -0400 (EDT)
MIME-version: 1.0
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LKD004IVQSI4K90@mail-out.apple.com> for ipp@pwg.org; Thu, 28 Apr 2011 13:44:23 -0700 (PDT)
X-AuditID: 11807134-b7c8cae000005108-48-4db9d1a584bd
Received: from [17.151.77.23] (Unknown_Domain [17.151.77.23]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id 77.12.20744.6A1D9BD4; Thu, 28 Apr 2011 13:44:22 -0700 (PDT)
Subject: Re: [IPP] (PWG) Raster Question on what is required
From: Michael Sweet 
In-reply-to: 
Date: Thu, 28 Apr 2011 13:44:22 -0700
Message-id: 
References:  <89169579-F912-4E85-B1EA-835F8975E4EC@apple.com>   
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1222)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1628826305=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 223A579603.A8EDE
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1628826305==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_AER3du8ffMKoPmqbre7VGQ)"


--Boundary_(ID_AER3du8ffMKoPmqbre7VGQ)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

We need the definition in the spec, if for any reason to avoid getting the =
wrong interpretation.

Yes, some platforms align on words (I have seen 16-, 32-, and 64-bit alignm=
ent), but for PWG (CUPS) Raster we want 8-bit (octet) alignment. In practic=
e this means that we only have extra/leftover bits for the 1-bit grayscale/=
black case since the other depths supported in PWG Raster are 8- and 16-bit=
s per color.

On Apr 28, 2011, at 1:22 PM, Petrie, Glen wrote:

> Mike,
>=20=20
> Question on your definition of bytes-per-line (BPL): You have it ending a=
t an octet (8-bit) but I have seen cases where the boundary is at the word =
or 32-bit level.   In fact, I have seen were people clip a line by changing=
 the number of pixel per line but not the bytes-per-line.   What has been y=
our experience?   Suggestion: Leave the equation out of specification and i=
t is understood or is stated that new raster lines begin at multiples of bp=
l.
>=20=20
> Glen
>=20=20
>=20=20
> From: Michael Sweet [mailto:msweet@apple.com]=20
> Sent: Thursday, April 28, 2011 10:27 AM
> To: Petrie, Glen
> Cc: ipp@pwg.org
> Subject: Re: [IPP] (PWG) Raster Question on what is required
>=20=20
> On Apr 28, 2011, at 10:21 AM, Petrie, Glen wrote:
>> ...
>> libtiff (the most widely-used TIFF library) supports 16-bits per color.
>>=20=20
>> I must be looking at the wrong version because TIFF 6.0 shows only <8,8,=
8> http://www.libtiff.org/support.html
>=20=20
> Hmm, they must have removed 16-bit support at one point - back when I was=
 doing print software for SGI workstations the "Sam Leffler" version of lib=
tiff supported it...
>=20
>=20
> ...=20
> I think for interoperability we want a minimum set for interoperability (=
and to address the use cases/design requirements). But most values of color=
 space and bit depth should be optional.
>=20=20
> Ok, then from your color-spaces, the required bits-per-color would 1 and =
8.  Also, the required bits-per-pixel would be 1, 8, 24
>=20=20
> Right.
>=20=20
>> One more time.  Does conformance to pwg-raster-back-side mean =93the pri=
nter will perform the indicated transforms=94 or this is an identifier stat=
ing what the =93state=94 of the back-side image is?
>=20=20
> Conformance for a printer means that it will advertise what it needs. For=
 a client it means the client will transform the back side images as indica=
ted by the printer.
>=20=20
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>=20=20

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_AER3du8ffMKoPmqbre7VGQ)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


 
=
Question on your definition of bytes-per-line (BPL): You have it ending at =
an octet (8-bit) but I have seen cases where the boundary is at the word or=
 32-bit level.   In fact, I have seen were people clip a line by =
changing the number of pixel per line but not the bytes-per-line.  &nb=
sp;What has been your experience?   Suggestion: Leave the equatio=
n out of specification and it is understood or is stated that new raster li=
nes begin at multiples of bpl.
 
Glen
 
 
From: Michael Sweet [mailto:msweet@apple.com] 
S=
ent: Thursday,=
 April 28, 2011 10:27 AM
To: Petrie, Glen
Cc: ipp@pwg.org
Subject:=
 Re: [IPP] (PWG) Raster Question on what is required
 
On Apr 28=
, 2011, at 10:21 AM, Petrie, Glen wrote:
...<=
o:p>
libtiff (the m=
ost widely-used TIFF library) supports 16-bits per color.=

 
I must be looking at the wrong version because TIFF 6.=
0 shows only <8,8,8> http://www.libtiff.org/support.html
 
Hmm, they must have removed 16-bit support at one po=
int - back when I was doing print software for SGI workstations the "Sam Le=
ffler" version of libtiff supported it...
... 
=
I think for interoperability we want a mi=
nimum set for interoperability (and to address the use cases/design require=
ments). But most values of color space and bit depth should be optional.
 
=

Ok, then from your color-spaces, the r=
equired bits-per-color would 1 and 8.  Also, the required bits-per-pix=
el would be 1, 8, 24
 
Right.
 
=

<=
span class=3D"apple-style-span">=
One more time.  Does conformance to pwg-raster-back-side mean =93the p=
rinter will perform the indicated transforms=94 or this is an identifier st=
ating what the =93state=94 of the back-side image is?<=
o:p>
 
Conformance for a printer means that it will a=
dvertise what it needs. For a client it means the client will transform the=
 back side images as indicated by the printer.
 
<=
div>
__________________________=
______________________________________________
Michael Sweet, Senior Pri=
nting System Engineer, PWG Chair
_______________________________________=
___________
Michael Sweet, Senior Printing System Engineer, =
PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_AER3du8ffMKoPmqbre7VGQ)--

--===============1628826305==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1628826305==--

From ipp-bounces@pwg.org  Thu Apr 28 13:47:28 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCD6E0729 for ; Thu, 28 Apr 2011 13:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.597
X-Spam-Level: 
X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlCq6uNhDoIe for ; Thu, 28 Apr 2011 13:47:27 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 799EDE0728 for ; Thu, 28 Apr 2011 13:47:27 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 855A57960C; Thu, 28 Apr 2011 16:47:08 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 3D73D79603 for ; Thu, 28 Apr 2011 16:46:53 -0400 (EDT)
MIME-version: 1.0
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LKD00EYXQT95731@mail-out.apple.com> for ipp@pwg.org; Thu, 28 Apr 2011 13:46:51 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-14-4db9d2391232
Received: from [17.151.77.23] (Unknown_Domain [17.151.77.23]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay16.apple.com (Apple SCV relay) with SMTP id 23.54.12552.A32D9BD4; Thu, 28 Apr 2011 13:46:50 -0700 (PDT)
Subject: Re: [IPP] (PWG) Raster Question on what is required
From: Michael Sweet 
In-reply-to: 
Date: Thu, 28 Apr 2011 13:46:50 -0700
Message-id: 
References:  <89169579-F912-4E85-B1EA-835F8975E4EC@apple.com>   
To: "Petrie, Glen" 
X-Mailer: Apple Mail (2.1222)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1154354061=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 855A57960C.A94FA
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1154354061==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_x0juntiFBqLCLkBy8O1GAw)"


--Boundary_(ID_x0juntiFBqLCLkBy8O1GAw)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

Oh, and since we are using the compressed version new raster lines begin wh=
ere the last line ends. Hopefully the other examples I'll be adding will ma=
ke that more clear...

On Apr 28, 2011, at 1:22 PM, Petrie, Glen wrote:

> Mike,
>=20=20
> Question on your definition of bytes-per-line (BPL): You have it ending a=
t an octet (8-bit) but I have seen cases where the boundary is at the word =
or 32-bit level.   In fact, I have seen were people clip a line by changing=
 the number of pixel per line but not the bytes-per-line.   What has been y=
our experience?   Suggestion: Leave the equation out of specification and i=
t is understood or is stated that new raster lines begin at multiples of bp=
l.
>=20=20
> Glen
>=20=20
>=20=20
> From: Michael Sweet [mailto:msweet@apple.com]=20
> Sent: Thursday, April 28, 2011 10:27 AM
> To: Petrie, Glen
> Cc: ipp@pwg.org
> Subject: Re: [IPP] (PWG) Raster Question on what is required
>=20=20
> On Apr 28, 2011, at 10:21 AM, Petrie, Glen wrote:
>> ...
>> libtiff (the most widely-used TIFF library) supports 16-bits per color.
>>=20=20
>> I must be looking at the wrong version because TIFF 6.0 shows only <8,8,=
8> http://www.libtiff.org/support.html
>=20=20
> Hmm, they must have removed 16-bit support at one point - back when I was=
 doing print software for SGI workstations the "Sam Leffler" version of lib=
tiff supported it...
>=20
>=20
> ...=20
> I think for interoperability we want a minimum set for interoperability (=
and to address the use cases/design requirements). But most values of color=
 space and bit depth should be optional.
>=20=20
> Ok, then from your color-spaces, the required bits-per-color would 1 and =
8.  Also, the required bits-per-pixel would be 1, 8, 24
>=20=20
> Right.
>=20=20
>> One more time.  Does conformance to pwg-raster-back-side mean =93the pri=
nter will perform the indicated transforms=94 or this is an identifier stat=
ing what the =93state=94 of the back-side image is?
>=20=20
> Conformance for a printer means that it will advertise what it needs. For=
 a client it means the client will transform the back side images as indica=
ted by the printer.
>=20=20
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>=20=20

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_x0juntiFBqLCLkBy8O1GAw)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable


<=
font size=3D"3" color=3D"blue" face=3D"Cambria">Mike,
 
Question on your definition of bytes=
-per-line (BPL): You have it ending at an octet (8-bit) but I have seen cas=
es where the boundary is at the word or 32-bit level.   In fact, =
I have seen were people clip a line by changing the number of pixel per lin=
e but not the bytes-per-line.   What has been your experience?&nb=
sp;  Suggestion: Leave the equation out of specification and it is und=
erstood or is stated that new raster lines begin at multiples of bpl.<=
/o:p>
 
Glen
 =

 =

From:=
 Michael Sweet [mailto:ms=
weet@apple.com] 
Sent: Thursday, April 28, 2011 10:27 AM
To: Petrie, Glen
Cc:=
 ipp@p=
wg.org
Subject: Re: [IPP] (PWG) Raster Ques=
tion on what is required
 
On Apr 28, 2011, at 10:21 AM, Petrie, Glen wrote:
...
libtiff (the most widely-used TIFF library) supports 16-b=
its per color.
=

<=
font size=3D"3" color=3D"blue" face=3D"Times New Roman"> 
I must be looking at the=
 wrong version because TIFF 6.0 shows only <8,8,8> http://www.libtiff=
.org/support.html
 
Hmm, they must have =
removed 16-bit support at one point - back when I was doing print software =
for SGI workstations the "Sam Leffler" version of libtiff supported it...


<=
span style=3D"orphans: 2; widows: 2; -webkit-border-horizontal-spacing: 0px=
; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect:=
 none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word=
-spacing: 0px; ">
... 
I think f=
or interoperability we want a minimum set for interoperability (and to addr=
ess the use cases/design requirements). But most values of color space and =
bit depth should be optional.
 
=
Ok, th=
en from your color-spaces, the required bits-per-color would 1 and 8.  =
;Also, the required bits-per-pixel would be 1, 8, 24
 
 
One more time.  Does conformance to p=
wg-raster-back-side mean =93the printer will perform the indicated transfor=
ms=94 or this is an identifier stating what the =93state=94 of the back-sid=
e image is?
<=
/blockquote>
 
Conformance fo=
r a printer means that it will advertise what it needs. For a client it mea=
ns the client will transform the back side images as indicated by the print=
er.
 
_____________________________________________________________________=
___
Michael Sweet, Senior Printing System Engineer, PWG Chair=

=
 



_______________________________________=
___________
Michael Sweet, Senior Printing System Engineer, =
PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_x0juntiFBqLCLkBy8O1GAw)--

--===============1154354061==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1154354061==--

From ipp-bounces@pwg.org  Thu Apr 28 14:39:34 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0304E06A6 for ; Thu, 28 Apr 2011 14:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ+J3r4CuaJz for ; Thu, 28 Apr 2011 14:39:33 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC0E06C3 for ; Thu, 28 Apr 2011 14:39:33 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 4539B79610; Thu, 28 Apr 2011 17:39:16 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by pwg.org (Postfix) with ESMTP id 004DB795F4 for ; Thu, 28 Apr 2011 17:39:02 -0400 (EDT)
Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p3SLd2pt010631 for ; Thu, 28 Apr 2011 17:39:02 -0400
Authentication-Results: cm-omr14 smtp.user=ptykodi@tykodi.com; auth=pass (LOGIN)
X-Authenticated-UID: ptykodi@tykodi.com
Received: from [65.96.244.16] ([65.96.244.16:33592] helo=TCS2010LAPTOP) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 8A/EB-07497-67ED9BD4; Thu, 28 Apr 2011 17:39:02 -0400
From: "Paul Tykodi" 
To: , 
Date: Thu, 28 Apr 2011 17:39:02 -0400
Organization: Tykodi Consulting Services LLC
Message-ID: <013b01cc05ec$b1271110$13753330$@tykodi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcwF69AZplIum1hYTS6r6fRFJc7isw==
Content-Language: en-us
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] Defining User Intent
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ptykodi@tykodi.com
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 4539B79610.A839F
X-pwg-MailScanner-From: ipp-bounces@pwg.org

Hi,

I saw the following article this afternoon:

http://www.technifoldusa.com/bindery-success-blog/bid/57441/Where-Are-All-th
e-Apps-for-the-Printing-Industry

Do people think any of these applications potentially impact our concept of
user intent such that we would need to have a mechanism to expose some of
this content within our schemas for Cloud and IPP Everywhere?

Best Regards,

/Paul
--
Paul Tykodi
Principal Consultant=A0
Tykodi Consulting Services LLC
3 Lowell Ave.
Dover, NH 03820-2705=20

Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP Working Group
ptykodi@tykodi.com=20
tel: 	(603) 343-1820
mobile: (603) 866-0712





--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Thu Apr 28 14:53:51 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC83E0765 for ; Thu, 28 Apr 2011 14:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VioPFNL3RK7N for ; Thu, 28 Apr 2011 14:53:50 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4E64DE070B for ; Thu, 28 Apr 2011 14:53:50 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 10F0979619; Thu, 28 Apr 2011 17:53:33 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 2A3EB7960D; Thu, 28 Apr 2011 17:53:17 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LKD00GZCU4TRN00@mail-out.apple.com>; Thu, 28 Apr 2011 14:53:17 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-48-4db9e1ccadd1
Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 91.1A.23242.CC1E9BD4; Thu, 28 Apr 2011 14:53:16 -0700 (PDT)
Received: from [10.0.1.4] (pool-71-116-72-81.snfcca.dsl-w.verizon.net [71.116.72.81]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LKD007WGU4ODQ20@koseret.apple.com>; Thu, 28 Apr 2011 14:53:16 -0700 (PDT)
References: <013b01cc05ec$b1271110$13753330$@tykodi.com>
In-reply-to: <013b01cc05ec$b1271110$13753330$@tykodi.com>
Message-id: <5F52118D-D1D2-4940-B683-FE60FAE688C9@apple.com>
X-Mailer: iPad Mail (8F190)
From: Mike Sweet 
Subject: Re: [IPP] Defining User Intent
Date: Thu, 28 Apr 2011 14:53:10 -0700
To: "ptykodi@tykodi.com" 
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: "cloud@pwg.org" , "ipp@pwg.org" 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 10F0979619.A8164
X-pwg-MailScanner-From: ipp-bounces@pwg.org

Paul,

It isn't clear to me what the relationship would be - calculator applications for traditional offset and book printing (which appears to be the focus of this article and the apps on the referenced web page) don't have much to do with our efforts in the digital print arena...

Sent from my iPad

On Apr 28, 2011, at 2:39 PM, Paul Tykodi  wrote:

> Hi,
> 
> I saw the following article this afternoon:
> 
> http://www.technifoldusa.com/bindery-success-blog/bid/57441/Where-Are-All-th
> e-Apps-for-the-Printing-Industry
> 
> Do people think any of these applications potentially impact our concept of
> user intent such that we would need to have a mechanism to expose some of
> this content within our schemas for Cloud and IPP Everywhere?
> 
> Best Regards,
> 
> /Paul
> --
> Paul Tykodi
> Principal Consultant 
> Tykodi Consulting Services LLC
> 3 Lowell Ave.
> Dover, NH 03820-2705 
> 
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP Working Group
> ptykodi@tykodi.com 
> tel:    (603) 343-1820
> mobile: (603) 866-0712
> 
> 
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> _______________________________________________
> ipp mailing list
> ipp@pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Thu Apr 28 21:48:27 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A2CE065B for ; Thu, 28 Apr 2011 21:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5--riv2nqwK0 for ; Thu, 28 Apr 2011 21:48:22 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id BB76DE0743 for ; Thu, 28 Apr 2011 21:48:21 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BA5BF7961C; Fri, 29 Apr 2011 00:47:43 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail.celstream.com (mail.celstream.com [164.164.95.11]) by pwg.org (Postfix) with ESMTP id C00F87961C for ; Fri, 29 Apr 2011 00:47:15 -0400 (EDT)
X-TM-IMSS-Message-ID: <6257c7d10007bce6@celstream.com>
Received: from cel-bang-dlp.celstream-in.com ([127.0.0.1]) by cel-bangt-m02.celstream-in.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 10:17:00 +0530
Received: from CEL-BANGT-M01.celstream-in.com ([10.255.10.109]) by cel-bang-dlp.celstream-in.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 29 Apr 2011 10:17:00 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC0628.79BE29A5"
Date: Fri, 29 Apr 2011 10:16:59 +0530
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question on PWG draft specification mismatch & parsing
thread-index: AcwGKC6k7pqY5RReTfaK9PqMCV6Dng==
From: "Roy Samuel" 
To: , "Michael Sweet" 
X-OriginalArrivalTime: 29 Apr 2011 04:47:00.0419 (UTC) FILETIME=[7A1EA930:01CC0628]
X-TM-AS-Product-Ver: IMSS-7.1.0.1433-6.5.0.1024-18104.004
X-TM-AS-Result: No--30.558-5.0-31-10
X-imss-scan-details: No--30.558-5.0-31-10
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
X-TM-AS-Result-Xfilter: Match text exemption rules:No
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] Question on PWG draft specification mismatch & parsing
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: BA5BF7961C.A9C03
X-pwg-MailScanner-From: ipp-bounces@pwg.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC0628.79BE29A5
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01CC0628.79BE29A5"


------_=_NextPart_002_01CC0628.79BE29A5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Michael,

=20

I had downloaded the sample PWGRaster files from:=20
http://ftp.easysw.com/pub/cups/examples/PWGRasterSamples.zip, with your
latest working draft of the PWG raster found at:=20
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf. I
compared the raster files in the folders:

PWGRasterSamples\srgb-16  &

PWGRasterSamples\srgb-8, with the specs given in the draft document.

=20

I found that neither of the directories contained files that adhered to
the draft document w.r.t parsing the header. Specifically for the value
of 'NumColors'.=20

=20

--1--

According to the draft document, bytes 420-423 need to contain
'NumColors' value, however, I found them to be zero. Are the sample
files outdated??

=20

--2--

Based on the decode algorithm given in the draft document, I had tried
to obtain plain RGB raster data from a pwg-raster file. I had converted
the PDF document obtained here:=20
http://orenyomtov.com/downloads/testpage.pdf to obtain pwg-raster file
using Google cloud print. I am able to get the pwg-raster file from GCP
successfully. However, on converting the pwg-raster file to RGB data,  I
have been successful in decoding around 1/6th or so, to raster data
successfully, i.e. the top part of the page is being rendered
successfully, while the rest is not rendered.

(I use GIMP to open the output raster file in RAW mode).

I have attached a screenshot of the output file that I'm able to view
through GIMP (scaled down version).

=20

Is my algorithm wrong? Or are the specs incorrect?

=20

Regards.

_________________________________________________

Roy Samuel | Celstream Technologies | www.celstream.com
=20

=20

=20


___________________________________________________________________________=
___
 DISCLAIMER: This electronic message and any attachments to this electronic
 message is intended for the exclusive use of the addressee(s) named herein
 and may contain legally privileged and confidential information. It is the=
=20
 property of Celstream Technologies Pvt Limited. If you are not the intended
 recipient, you are hereby strictly notified not to copy, forward, distribu=
te
 or use this message or any attachments thereto. If you have received this
 message in error, please delete it and all copies thereof, from your system
 and notify the sender at Celstream Technologies or=20
 administrator@celstream.com immediately.
___________________________________________________________________________=
___

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_002_01CC0628.79BE29A5
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi Michael,=

 
I =
had downloaded the sample PWGRaster files from: http://ftp.easysw.com/pub/cup=
s/examples/PWGRasterSamples.zip, with your latest working draft of the =
PWG raster found at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-2011=
0327-rev.pdf. I compared the raster files in the folders:
PWGRasterSamples\srgb-16  &
PWGRasterSamples\srgb-8, with the specs given in the dra=
ft document.
 
I found that neither of the directories contained files that=
 adhered to the draft document w.r.t parsing the header. Specifically for t=
he value of ‘NumColors’. 
 
--1--
According to the draft document, bytes 420-423 need to contain ‘=
;NumColors’ value, however, I found them to be zero. Are the sample f=
iles outdated??
 
--2--
Based on the dec=
ode algorithm given in the draft document, I had tried to obtain plain RGB =
raster data from a pwg-raster file. I had converted the PDF document obtain=
ed here: http://or=
enyomtov.com/downloads/testpage.pdf to obtain pwg-raster file using Goo=
gle cloud print. I am able to get the pwg-raster file from GCP successfully=
. However, on converting the pwg-raster file to RGB data,  I have been=
 successful in decoding around 1/6th or so, to raster data succe=
ssfully, i.e. the top part of the page is being rendered successfully, whil=
e the rest is not rendered.
(I use GIMP =
to open the output raster file in RAW mode).
I have attached a screenshot of the output file that I’m able to=
 view through GIMP (scaled down version).
 
Is my algorithm wrong? Or are t=
he specs incorrect?
 
Regards.
__=
_______________________________________________
Roy Samuel | Celstream Technologies | <=
/span>www.celstream.com
=

 
 <=
/o:p>

--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


_______________=
_______________________________________________________________
 DISCLAIMER: This electronic message and any attachments to this electronic
 message is intended for the exclusive use of the addressee(s) named herein
 and may contain legally privileged and confidential information. It is the=
=20
 property of Celstream Technologies Pvt Limited. If you are not the intended
 recipient, you are hereby strictly notified not to copy, forward, distribu=
te
 or use this message or any attachments thereto. If you have received this
 message in error, please delete it and all copies thereof, from your system
 and notify the sender at Celstream Technologies or=20
 administrator@celstream.com immediately.
___________________________________________________________________________=
___


------_=_NextPart_002_01CC0628.79BE29A5--

------_=_NextPart_001_01CC0628.79BE29A5
Content-Type: image/jpeg;
	name="pwgTORGB-output.jpg"
Content-Transfer-Encoding: base64
Content-Description: pwgTORGB-output.jpg
Content-Disposition: attachment;
	filename="pwgTORGB-output.jpg"

iVBORw0KGgoAAAANSUhEUgAAAogAAALOCAIAAAClKnWcAAAAAXNSR0IArs4c
6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAPcrSURB
VHhe7P13mFzHdSaM97/f79ldQcGyd2VLlFeW7fXaVpZt2TK/XX2iRImZAEiC
ASQlSgwSg8ScAIIACBIgAYLIeZAGM5icc449PT2dpnPOOYeJ+p2qun27p6dn
MMgzPaefFxc1t2+oevve+95z6tQpwZGTZy3BmTH71Jh9UmybyMaobYKDNTU6
D2KyJskg5pAQWxNjBEkJBRQIbEmJLV3mVrLNMhBb4nNgjo3mhSU2aokD6MZk
d3IiW0pqn5A5JgFy56TCNTXunh53z4x7ZpSeWaU3C/AnxfgSoPDM5kDunp0D
16w8DZlrNhtS1ywH56w0DYlzlmKGg2NGkobYMcNj1D4jss+M2KdHbFNC6+SQ
ZXLQPDlgmug3JPv0iV5dvEcX79bGurRRQKc62pFGuzpKoIq2qWiBAsoMrQD4
k64h5Rwoo63KaAtBrEXFoVkVa1YStCjjLSqCZoLYHNANmpRxQPN8qBJN89Cs
TnJQJZvTaFIlF4Q61bQAmtWpZvXEMgZUL1/lF2ksEEIaRdCiAUy0aicZ2gC6
qXY9w3SHYbrTMDMHxpnOJaDLOJMNbhfDTAdFO0A/05ZGq36GQEfQQsHKlwbb
8UrBV+BGFqDh2W3PPbWB0NKqnybQTbfoploZtFMt2kkCDUGzZqJFzaFZwy4A
/tpONCkTjRnEG8fjDeMxAkWsXhFtUETrFRFAgzxSLw/Xy8INcgKuLIM1IUAD
XdZLg4AGWbBeRpYNtNxIygFAoyzQJA8CmhXBFkWoZTzUqozAA6FTE++CZ4g+
2WeY6DfBs2VqyDo9bJ0ZthEIszBCnkIUNgA8jhimRqwZwANKaJkcsUwKrRNC
y4QvNn3PQ7/yRycsvoTVl4BlFuIWX9ziTS+hQGH2xjh4YmYA/MkKBFGAN5z8
4OO9kcQk+5P7yhuzMPjiVoA/YaOwB5IARyDlCGbgDE44QxkE41OfPbXRp1Sa
KkoZLBWltkrABWflBVflBU/lBV8VQbDqQpgieplgewFCVRf89FDeygtuenx7
5QVbRam1otRM4RaJ1v3fW0PJWYWbwB6eBUX+m//9XYE3Ni1xgCoTYaaY4JEl
0qlRWxrWFEgygS0JANFlyzFbCtQXILUTyBaG1JZYAuJSGweJLZ4Nuj5zBJk9
IXOkFM7UuGti3D2p9EypCKYJvDNqH2D2sqDyzRJ4F4BnVpUFJvM88uo9r+5y
90wOZO4ZBqlrDkC5xxzTYsf0qH1aBHeCDa7+iWFzasiUHDAkAH2GOIE+BujV
xXoAWgIQbB5dtAxLClDxWJcm1kn/hGUGsFIT68gg3qGl0GQj0aEBzF2pjneo
4+0MGkAiB22wRpsfHdpkNtq1ycWgS7UvgA5dqkM3sYwB1ctX+UXbS3Zh/EDr
9BOdhklAF8FUt3G6B2Ai6DUDZvrmwzLTt3TQ3eE4gB7TTDdFl4kT+A4j1WkQ
JIYslV2SXvI7XlGBnXpZgAo2B9KWaQKq0G36KXhbArTqJgmYQmsn4I2KItVC
3rGSzRryMtqkJu+pzexVlchzHABvtI3KWCOR5yigkcpzA5XnegUnzESeable
TlSZCDMpUD1mYizPlOHPRnmAgQizPAiq3KIMtSnDIMxwp3dpQZgTvcZUv2li
wDw5aJ0GbeYk2T4j5PV4TmEaTAURE2Y7PJEomELbJkdAnq0TI9YJf3z6ng2/
CsQmQCmJMNNllkJTVc4G0Wair6DHfCEj1V5OmLd9tCdLmMlKTpW9MaLK84TZ
HkwyYXYCQoBcYf70iQ1ehUJ/4SzAdOGs+cJZa+lZW+lZe+lZV+lZ98Uz3otn
/BShsjNhgtPRhQHfRrK+hT9hF9gxSI/gu3gGDgiAI8Px4SxWekY4L5zdPTS0
9v/9dxBmXjv8idm//8fvCDQ+MOCmqDYvJszitDBDgZdkYgrbk2P2lMSekjpS
MntK5kjKHUkFwJkcd1K9zIEjOZ4fiXEHgYJDXGEnkOeDwp7gwA7lTCldEyr3
hNo9qfFMEfimtb4ZgM7PMLtEaP2zOdD4Z+fAN6tZAGrvbA6y1V1JzPc5AIOe
Axj37hlFGky8M2rtJG9Oo3bivRixpISW5LA5QWCKDxrjg4b4AEU/D328nwdZ
GQMwCaegis7pOkh7vHcuevTEIidLim4K/k+uwKz2HJAtE7kwJLoNyTnQJ7v1
SXhh7zGkGLqXhIluQx70GCaWP/LVfEmthqb1Gif6ACbAJNg3/eapAcs0xcwg
wDozNB+2maElAMwjspmVHAQwYJ3pp3JOFDot0mBYgz09R56pJQ128JKEGTa7
Iklme90USV7wvKTJ02mTmgqzgZrO+inAPGHmtBksZhBmTpvTwgyq3KhiekwB
RjNZUruZajM1nSPZ2kwsZjm1ktmSA7GVmblMClIwlDl55oxmXps5ozncxhnN
sS5dAm49uLT6zRNgNDNtBruZyDPV5nnyTIQ5YzRnC3OWNoPFfO+GX/kiKaMn
ZnRTeKIE7gwMUHZFAAZ3xADLxRA2uMKuYPz9Dz8JRJNQnovIzr0n7lv31CL4
eN9J8orgT2bDF5349NG1bolEffqY9vQxPeDMMdOZY+Yzx6xnj9kp3BS+s8f8
Z48Gzx4NnT0apvjs1Tf500E57xpYCbvAjv6zx7z0OK70YeH4cBbjGXJGOC+c
3d7Xd9+P/zVbmA2B2cMnzgpk8NwHYc5oc8ZiBtM5x2imqpyi9jExjokeEzEm
kDsJmBIrXSkVgzulzoYrpV4YdJdkBs6k0pnIC5UzqXImCFxJckA4hWdC45nQ
eiZ13imdb0rnn9L7pw3+GWikkUdw1rgwDMFZDoFZ2ItBPx/+Wf0SZD5X3bO0
fI75nqXlTMU5xzv1tDOplrumZc4pgMQxKQF/BrwhQSeCJQkYMSdGzHEhg4lg
2MhhyBgHgHjDGlZmAC0fMnEFousLIjFg5BEfMAISg2lkfZW9GSn3G5PZGDAm
CUwpDsbUAMUgLPmVSyyY4e0+DwbJkwVAHP7LEvmqDZbKpVqdbhdp2hDAMgUY
tk4JbWDccCA+RvusKAeOWdESMEq3Yb5KeAoznc4odJYNzXzdzMvNm85LFear
0OabIsyZNua8GeQIM7GVM8IMDu0W3SQgbTHzwjzBvNnEaCadFJzRDMLMqTIT
Zt6hTbUZhJk5tOvBoa2gfmxemIk2cw5tKs/Em83kGYSZajOR53rqzeblmfi0
FeDTBm92uE0Vgc4vMJrh/RiMZnjnG2AObQunzZxDO0ebyZXGabOQqjIsSYEa
zcK0NvvAYn7oV+5QQuMIa9PQOEIEdopMOaixE6jpkivbgmpbUEOWAR4Of2zz
9l3+SDJ7JSuDRv5p0Q9skH4ngFcEDp5was8DdztFI8qj+1RH96kp9McITMf2
mY/tsx3bZz+2z3lsn/vYZ95jn/mOfeY/tpch+4xQ3vvH13LWpLckO8LurmOf
waEAVnpkIz2LLn1SOLutq/Oef/t+tjCD/zWYnBUQJyrT5rlG8/z2zszM5qwk
VjIvyS7iTE5brimNJ6UlmNB6J3SeCZ03xaAFcF/lLSS1Hgo3gSYvXEktgG5A
QI+mg7N4J/S+SQPAP230T5sC06bgDMAcnOUQmjUvAFNolkNw1nQpzFd3Xsjn
F0DFs5FtuOcxzal+c8pNNRu88UqAB7rMpxUu0oMuc0Bv+gS8D5Fue+hHIL37
pGt/1MJBZEmILHGGkawClEHFiZZb8oFoPAehOSE0J8E0F1oSGZjhPSBJ1i+A
YTOY8slhMOjngh4HDP05GCZ/kk6pywBxl+UBuNFWBHIrf6m2k0ZZwD1IW2eb
hB4NwKh9SmwnfRwMY46ZMRKywGIXsuCalSwNY85ZsXOWF2lOoXkDmlrPvHOb
mc7Mp315WIF2cx6rPcuhDarMwBnNtLMZep2JPNOAAN6bne5mJj3NoM00kIK4
sudp85yeZq6zmfQ0R6CnGVAnB3C2ch2RXlKuI6DaTOQ5QJCW57naDM5tIswt
42HoaYZAE3Bod+rAv5XsNRCHdj+81JI3v0xnc648k75n8joIRjMvyXO1mdyb
TJhtvqjU6JUaPQSG+XBLDW4JQJ8Nl0SXHyZX8K0tO1yBqETnzMFShFlp8XOw
+pUUUL2d99xmG+gXf7JD8skO6Sc7ZJ/sUOzZodzzgXrPB9o92/V7thv3bDfv
2W7ds92xZ7uTYKubYs/zL+UoMa+JsB6+hW1ce7bCLrAj7A6A48DR4JhwZDg+
nGWcnhHOC2c3Njfe+d1/yhZmMMmSU38SyLKEOVubczTYqVfaTJqclXLWuUv6
d1NKN3Umc5YrlUnvhMHHweib4GGA9YshZfBy0HuTufAk9RQGWHpTALoxOSA5
vn/S5J8yB6bMwWmAJTRjBYQBs5cLS3g2L8zhWQJe4HnVp4VsUV/MOs8yyjPW
+TxbnCr3DPQ1aLzTai/0mk9BDzq8/SgAzgkgHwB9+axTX8p8GLYEYE5gHfyZ
s4aG42WQjtFLR/ClQ/lo9ABbOTfEj4/1m/MtFwnIxyLwfR8kHIFzvWTCCWlc
oRhcMpeBSTHEJy4A2hHDQiWWJ+bX/BJtJ8GYlBzSNAd5b2aA12gpOFEo5C4W
tTA3JpH96bkEIPQBNpMBqIRnFDptQIP1zDu3M9rM2803Sptvit083wPPVSO/
3Uy82QRpuxm0uZkLB+MtZi4KrFGVhOAv6GAmfcxpu7lByfzYXAgYtZjTRrMi
Uke1uY5BTsSYSnKwTgqgZVIg2lwnDQCYNhMwqSaBYESYm+Qhos3KcKuKRIGR
zmZwaOtT0F0CvSQD4NAmRjMXBZaJBWOmc1qY094azlwGW5nIMzGaM8Js8YTF
WhdgVOsUa52wzEDjHNU45kOksYvU9lE1LG0U5E+RygYwOAJvbP7A6YuwPwEj
FFDgNXK+N5tJFayXGdwyg0du9MhNHCyeyEd3/F9LX8/Iji0A8Y4tkh1bZB9t
UXy0GaD+aLN252b9zs3GXZvNuzbbdm22UzjT2P27F+a/EMAaWM+2YdvDjrA7
QA/YSY4JR4bjyz/aLKNnhPOKdmzRN9T98tv/kEeYpU6wmOGlmw8B48KzszV4
dvZPVrPBoajLFeaM7xr6d9OqTIzXSabKVCzJ0rQwsjUbygZfag68ScMlQLTZ
6ANMmPwTZv+kOQCYtgSnrSEA1ebQjC0MmJ2PPIIdmrUuAEtoNgdEoedqM/0T
zHRirJsC+WEMzAAMOQDHu39GnwXSO057yrW+adBmjWdaDXFtEOAGYW5OQAr6
8qFHH0BD7RKyuVF1TKQBLFaO/5PF6C0K2JjbYI6Ez90r56usP6GzAwz6HIAT
Phfgmb88gDO/kLCU5tP2SilYjwYAejcI3AAuNIGMQcgGH76weIHszskzDCIA
mxvkmVjP9lnoa4RnNPRkgzazuDDS30zDtpmtTLqZlxKbzba50thstuPlWefX
aPv5dSbV0AGm6RLaRWKzCbRckDaxmLVTIMkEJDx7sklDhgxwYwpUKarKyQaC
RMN4onEclsSPXT8OIdmxOop6eaxOHiWQ0aU8UieL1ErDgDpYykK1UoIaabBW
kkamHKgdC9RKAnU8qFQD0jHboSZ5uFlB7OZ2FYR8xru0EPOR6jXQIAYawQCx
C9mBC0yhCUCzCcCqnhaSJelYGabdK2RJMMmisk2ukFDlYBhW2YeV9mGVbVg5
H9ZhJcW4dWicLBmGxi3Z0Np8r727ze4NDyksGdBtQA5D9AMFodIqVFLBVtuz
18ObgVjnGuPNcb0Lqvfh7f9p7u4c3vI2YGTL26Nb3h7b+rZ065uA8a1vqra9
qdn2pm77m8btb1q2v2mlsGfhk2d/z5+CnR3W8Buw7WFH2B2g3U6OBseEI8Px
JVvfHKNnhPPC2bU1Vb/4p7/jo7JZbDaxmOnQnVxVBmvGmPXR6vQGgyF7DSsr
HKxHmQVeTWjcxHet89qKHxTwn7W1NpMvZSaSyQHkkyBXqlOwGQdv0jQXRm+S
B9Pp1j1Zp6ixmLx0X3oKS2CSIDgFsAanbaDKDESbLwNjDRsFG7rG0tIO6g4m
+BwEZ2CkGQ+mx7lYQJtBs5k8cyJNVZlhjjZD/Jp3GqD1kqA2tWcSAtxUpMsg
pXTSIDsCEjEntxOANnOQtNwteOSUhFPrzHrb2GaOOe7bHDmv3iW4u9wslbTc
lSH4kRMSXuOT0u6D3De7JBD6x1C1K7P1XeUWEpyfBqfxZDMSJCixS6ECm7tp
wKAdfPI8ZJsFj56UZq/JVwY3fj4wDz8bMieTdtwtOFzDynMgf4+v5sdy+pX9
1PpMze+usJOVPYczq/jjkGOyT94jkxPVfJzeb31HV6Ym3Mr3emgfBEDazh+q
Ot18oJ197q6w8ZykG8U1TU5HAxK4pmBMIIEbMN1bvZHte2+1U+meUbqdZ7gb
8Gi9Z6Z+N3xDCtmxh31kl42nFdBF4ix6INPcTb1k2B6M1gNhhqcwPKP7Sdg2
CQLvMsLoLIh+ov5bMliICFLLIqDbXBNkJJDXwhtVyK0/bS9RYlIgMsxBM0WU
mOpxEwfQ44lGNYgxA5PkBJPkeiLGFApelaO18jRk0VoQY6LHkRppmCJUIyGo
lgRrxoI1sCQI1IwRVMOSlqvH/IAaBom/FjBGlxQZeSamc7hFGYExkzCkIqPN
RggwnOIDDMGAJqBxYQzDYFKDx5sqMRf0YJkEPYYhnRAGMWzmhFmotBQ3i843
i4pbRFBgON888vQLmxeP1Xr6hU3nGoc4NAydAzQO9Yg1T/7uNbneTv7MRuMQ
HM1FP1Aobhq+AGgeKWkZyV5f3jFW3impAHRJKimGFaa3/vqLsrNFpT//cfnP
f1xx+4+rb/9x3e0/brj9P5p/+R9tv/z3rl/+qO+OH/Xf+aPhO380euePxu78
kXQutt93H38KdnZYk72NhO44Qo8Ax+m540dwzPZf/nvLL/8DzlJz+4+rbifn
hbMP7975oy/9l1AyE/wLcUVUmME/xnn/JsGmAa8jG7IsWsInLcwkzguCsKgw
p3QeKwjzjgFqKKva1goeLVVNWPygzSkzKHQaGRlmegzKqoSND7VDgSBHmxNG
7xy07RGsrTETtVa2rhUIPhyA7UGYyRuAhWqzlSE4ZQOEAESh7bxIL17Qda1j
D6sNnWPE7M4CGOJZALs8L5gvHQx3AOntngdjYHoOaL849I7z0PumGUg4m3cK
hBlC2zQAeAeigXUgzBAZR+LYSYx6XG7jILOZTnG1B+mNy2zZIF/dXW6SWeNd
5Y8I1rV08ULOCl0HBTvHpNa4dAx0/UA1FGzxTrplJx29RvXjYDU1wcl6wSMn
JaTMyTmspy8EsDJH75lO8/KzuYtTbhLJz0H6nuDRU1L+zysuTMhgUHv3YcEu
GSlkoavi0fe62RoZKDQt206th5PO2Szfvvz2EzXAwLwj02Paarpt/MFBX2k1
ZDW0AnBqgeBQDWkpNBNOTVpHDyWFAvl2fVsXfCttu3thEuSOCTl0YTihI2OS
wDU57rKfBll9oKPPPaV0T1ENPlJPyoqtgsfOKPiVoNkO2CANxxkixo+dVkDP
iAOEeUsfBBhOS3uPgFofl9IRevThCzFB8KTuM071GKa69FMdusl2Ft9EzcFm
NQUrXzewwcE3EXmaRhtOqkQKdBi9aqKJQ6pJmWpKKzEnxswyVhAQJaZmMWcZ
Z2lwrQzM4rQSS8JEicdC1QRBikC1mKCKwF9NUSX2VY36q0f9sKRlX/UoLL3V
ADFBTbpcI/bVjvnqxvx1En+DhDi3wbPdQkxn0GYwnRMgz+DWhsHNfUSeCSAo
jACSKPBhlSRMLA0TEWMIURwyTQwSwGDOFAy+vfvBJ4fl5jONw2caKOqHT7Nl
PdHRS8ZqFdX2F9VkcKqmv3NE9fizr8i0tlM1fUVzAQe00s98vefXl7SKSgFt
oxTii23iAZnhza99Tlp0ovj//kvp//2Xiz/5l4qf/Ev1T/6l9ic/bPzpD1t+
+oOOn36v57bv9f7se4M/+97Iz743+rPvjWVh+z138+dlZ2EVgPX8ZmK64zA9
Ahyn87bvtf/0e3BkOD6cpfIn/1L+E3JeOPvgzg/+9fP/TzBBgnx5JCZnBTSv
CEktQvr/QI8tBCOW5BJ0WQQeVLDSQBtAJCBAGmK1tG5emKmH2WstfUjw0SCn
x1linDT55gKUmEjswfa0JGdbyZwqexLGNNp2C9ZWU2H2JniRpsckMk+0mclz
kIGXZybSTKcJ5ohuzp/DR4gwp2V4ngATi5zBnAVTYGoO/FPQ7W3MB4N/KgPf
lME3pZ+HtCpPUlUmnQXgnCCq7GKjzogqE1uZU+WYzJaGVbwZBHIsJrVmYaz5
bsH+am4Nv0GcKLE1LrHGq3YKNnfGJNaYZKz5LsH+Kihkl8nKA1Ww5dyR5fAn
7HhXmQmOILGCRf7IiTFI/DIXGV+6+cQ6weaubDc7E2kJsZglGVObt7nnFPg+
9QULZKSAlNjlh6rpqIG8IG8SFVap3XpyPZjpc7fpPgR6OWcvWLO+rZMdimjn
YkeGbdIHzzostxf1N6xv7WSVl7beTd5yLCcJIVzD6SuOJbftXG6AlNxOAgso
SJyBovcwqHIvUeg03JMwmn/cLX+f6C4p1+0W3PPAY1S8J5UMfbDXY/fCBnJQ
dzsI83s94CqHDmzH8fWCd7pIuBmYQfAIhqczdEDCqK0uPRks3qadaCXZM7is
KWAINlweJhpUi6FRNbESkGpQphuuTDVSEO/0OEE9sYYT9QqCuvE4gSJeq4jV
ymM18iiglihxtEYGAhyploYJJOEqSSiDsVDVWKhyLFgpDlaIA5WjBBWjfkD5
qK8CIPKVi7yACgquPOItH/GUiwgqoDACS3eFiGLEUwkQERDNBrUWE4Wul5D4
bdLxPB7h5Fmb6NIRzzYoNBtMxaMf+qHpn6zQD2OgM0hC7iMYfAHDMbzRqbse
fGJQbjpNlHj4dB3R49N1Q0WAWiLMgUU/sAEocRp9oMSAjhHVxudekWqsJ6v7
AGwlA2wPrtxFPsSSbh650AJmNJVnin6p4Y2vrZGePnnhJz8q/cmPyv6/f6v4
6b9V//Tfan/6r423/WvLbT/s+NkPe37+w77bfzh0+w9Hbv/h6O0/HLv9Bwzb
77kn+6Q5ZfiWbSamOwpv/+Hg7T/svf2HnT//YfttP4Qjw/Frb/vXqtvIGeG8
F3/yo6FdH/zrF/5/IMxSJ4SPcCDCnFZiEOMUCbs1JQDDxsRShBkexGBFwVBj
hSOudJDxS2pnQuuyFD8g+KA/qXcnDeNEa9uo1rZnnM+Pliip+atsAWOXfB5s
GeHLAqq4ngRIL/d5sEXoSRg8YzsEj1yoPgArd/THW3cL7q82GTxxgyeRLptL
Mi70Qx3URreo2znr8aHDOx8S7BxmOq3YmT72ujqHNTCVDUtgigMI80MdYv5P
0nWdBvRkqzu4ygseK1VD0Jm95CHeJXi4zT9p9E2O1D4m2NNxIb1+x+Ck3if/
QPBYsQoK0A0/2bJHcF+NHbrkKezgafigpuM+AVk5WPMYf7htfRMaRdu9gkMN
1FCuB5fpxxIqyWNbBAdqrDEZBdFgS5RBYhndLHj4hBgKWejYL1jX1GGJjhEY
iEB2wLcxhjGzeJNgf6U5OgYYbQJhJmVLtOPiI4KPxGOWWHu6AOUcVH4kuOui
kawkp2hupxtwh52zcXzMYoLzbuqAAgHVcgam6FAgG6Q/5D2go+wRsOO5zcbA
x36wClS/M+1RT78H0JeDFuKo3zUGHergXeflP6t/nb0Q8C8HpMB91rV0sLcH
cBukP+wIHeAboMekoPWUkB6BzLf8vpkNsjv16RFIExLptrC3FtZkvuGEhzmN
5ZghG0sBXLgAkXAaVZCq/Zi8XsyRamJPA2RbBI8WyUgZtrmnUkbM4l72FVmz
pZduAK4Ch+3kemgIhAXAe7nt6DrB2x3EBhqAhy+MMtenunSpTi1JeNKmSbbQ
uGKwAkF76hSJWkWiRr5U1MoTVwt6xpuAeTWvkccB0BxSkBHUUtTIYjVSgmpZ
lKFKGqmSRColYQ5j4YqxEKBSHKoA3R0Nlo8GCESBMpG/jCy58sUR30UhQRlZ
ekuHPaVCCigMu0uH3CVDLkApXXIYdJYMEZQyDDovDgFcZMmVnWXDzvJhV7nQ
BbJdNeohZrTET9OHUef2OKQFjIFzm2QTApHWJnl0g2BT9JBloicX8R5IWqKL
eSKTdz7wxIDUdKp2+FTtUA5AxmyLfmCDk9X9PE5VkXKbULnx2VckWtvJqr6T
sIYCvgLA9ppFP7DB+caR4kbRhSbRhWZRCaBF1CcxvP7XX5KeO1P6i1tL77i1
/I5bK+64tebOW+vvurXprltb7rq1465be+66te+uWwfuuVV4z3+K7v1P8X0/
Zsg+I5S3rV2bs2bsvh8DxPf958h9/zl8762D997ae/et3Xff2n73rS1339pw
9611d99ac9etFXfeWn7nraV33ircu/Nfv/RfA/Hp7BAcIsycEhMxZkNdY4OG
2KA+uhRhFpvJQ19qjcptMYUtprTHVY64xmk6n+m1OtDqjvNmLi3EieLuHjMy
oR0HZU1D0XK/gGxvcMeF1Y/ANlAAUN016t3iD+Bx+UDzsDumd8daPhHcX2XU
u2J6F6x/pFgRM5D1ZHuDxwQKvZZ0PEs+FKTt9aFDsPdHQ2BJ2y6CEU8KANlH
4GlXZ/q/s/vCzUOHBQ+1i1iPeE6/uKodXPQlqnSouXcCrHbBHhmLDxfWPCp4
sF3ICgJ4R5nQeyaGqokzs9mTGoTCbikd5SXdLjjU5CZdABTWc4Q3siZ78PdA
1aOCB9r6nZYzDzx6RgZW8tj7RDYO1IJx3Llf8NEokWFzZIyHKSwmGNkk2HBc
xMpptO8TrG1s4/7UHV8r2NQeEZsiowyixjvXNrbyZV6dPhxhG1R8KLizVM+X
2ffvtnNfpTd/+JiIrMkclj++KTpqiopNBnpeKFCYeYxuEjx8fDR7DdnyrlKD
2Jz5qq304btKjeJRYtBXmGNiALwKrG1uM8cqPoIqPHJ8NCa2ELRdfATeFVg5
B/AVvGrMXWk8vo68W8xZCUeGs9BDZW0Pry+PHBfT865rbhPTmrBTkO1pHeBb
7qTksOTDTmeOtZXSQ7GakzchqDAsMw2HBsJvmkUL25Ig/TIUl3AvNOQNBl4O
QLBlNnO6/wI886DZEtovAA6tZC3xDVi6wVu+SwJ/yqmZXmuXgDCfIv4JC31P
osPiR1vvEBwsgdHqhkQ/Tf7aTRPAwcMaErU2j8cgKVU9DUqqkUap3kQqxhZD
5VgkD+iOVwA4401BnqpmtauCaC2FOFxO5JZiNFQOoisG3Q2WjQYIRIGLIj/B
CEHpiK9UCPASDHtLhj0lQwDvBbL0XBhyXxgkKB50FQ+4zg84iwH9zvMDDsC5
fvt5QB/AcQ6WXNl2rs92vtd2HpYE1vO9VigUU8CfxYB+64V+a0m/rWTAXjpo
Lxt2lAudlaDQIqLQ4OKGwdCNrPuZ2tDpbL4g1Rw6wOnNgWQChnzAHFRQiADc
4ck71m8clJlP1QoZTqYLp2qET7946T7mE9UDJylIoYoU2oXqjc+8KlHbTlQN
AMjKNP7w1q7FO61ffueTc42i4qZRgmaCC81iEObX/uYvZKXny9f9omL9L6rW
/6Jm/S/q1/+iYf3tLetvb3/o5x0bbuvZcFv/htuGH7lN+MhtokduE6ex7cEH
+DNCGdbPXwMrR+mOgIENt/VtuK17w20dD93W9uDPm9ffDmepo2eE88LZhQf2
/ujLn/fHplhqCob4xIxgQB/loIsO6KL92nAfxVKEWWQMj5rCY6aw1ByRWSIK
a3TcFlXaDWfXC7b1xiAqfrtAsL0vpgP5BNXsY48t+vlEnNbU/S2uqJ5B3nS/
gP1pAJt7zufjUZ0TjvbweVlU6yRo5gNt4BS93MrByof5vYg93XeA2OLwNkD6
py2lD9KuaNKTPeezYyATWTbHfz5wUPBgq5CLCZfsSO8EzoBhIq4SNnCLQvKB
4NHi8aSOG10t2S549LwiSTVYonEnCFxj2wSPnJMn1PKWewUHG10Jdd9BwSdj
ahfNlEJgPvuAYGtvOqeKtOUevprrW3rs8Z7yR+4uN8pBjHc2n1oH1nCkCuzU
Up3YKHw3veU7rUGRISjSA4bfETx0dDgwos9Cy17B/XUt3BrNkfsF77QERwzB
ET3FcP0d99e38GXB3ov6gBB2Eewtg5WGYBlQsGOYbM9BS47QSvYt+0BwR7GW
HgfOSw9LdxkxhOZBR/fKXh8eMQBG3hFsOCIk5ZYLG/im33FBB2vg1LQA+5Jt
WksyG9At95Ubw+U7BHeW6OCaFBkjgNaSh+8s0bNyNmA9vJ20zlsvaiNvLXPX
64+uFbzTRg4l2CFKH0T0juDhoyPkmHBG+MAGc08BGwBR/PZcZQR0L3qoEVpJ
AGny0ZFMw7m27xihhBCwU2R/6LtR5hUHXlzGQLM52SZKf0IMrogxVgAJJxfJ
RZPEwtnlYJHTTgf6pxgSzhuPZe6HRw4OR/t10V5ttFsT6YRBNUp4RofB2wkW
FQzIgYCjKuJiJUYeVRd/iZCgFED/vCZg0rXMQVrKt5qQ4CMYJqBC6wWVZUJ7
YRCE1lM85CYgWus+PwhaS+SWoN95rh/01Xm2z0HQ6zjTZz/TC7AR9NhO91hP
dzNYTndZirrNRV3m0xRQKOqkyy4Tw6lOY1EXBRQYuoynAZ0Aw+kuw5ku45lu
09lu07ke8/k+C9HpARsR6SFnpZAptJfzckvJCCuGdM5tMtqKDLhKo5UUgq0k
rRhZAiD/5b0P/7ZPrD3TIC6qHS2qExXV8hgpqmUQppdEuYtq4E+KGuGpmmFA
UWY5dKpmqGNE+9izr0k19lPVQxSDFKRcVDMHp2uGT9cKzwDqhGfrR841iM43
UEluEl9oHivhIOmTmN76+7+SV5ZVPbG++on1tU+sr39iffOv1jf/en37r9d3
PrWu+6l1fU+tG3x63fDTa0efvm/0mfvGnrlPmhfP3iedB8mz941SDD+zFtD/
9Lre36zr/s269t+sa3tqffNT65t+vb7uyfW1gN9sGCk69uO/+LIvOik0xngQ
Ye7VhHn0aMI96lC3OtitCi5FmIfpQ1xkCImNIQmR57CcyLP+9DrB1u6oyh5R
S5vuE+xvdkZ1Mig8XExllcjnxzCwjaopWS8QrG8adES1ZON9TY6IxqE/B9Le
A4UwB3tYYx/ZJthwTgoFgqZdgnsrdGp7mIemex88oOnukaaPBfdVGrS9+8HC
HnLFwZLWe8zEUdyf0I+DXX6whfjGyWBohiyJzZR1IJwPtA65EzoGF4GWYrDq
EdBUVtYQUNGVJTTEmR9XO8mfZ2XxgcpHBB+PKYmfHzC2VfDIGSkUTKfXC97v
Zsv4OM08SmEqWi/Y0g0xXDG5TbxFINjSBYWYvItYZl3gpgZJXtdUdfHhzR2R
9tINd5WMHFu74aiQyWpAqOMwrPVTDL0teOjwICsTDAEG634p+LSElbVDbwke
OjTIyulv76trnLdl4/mHBNuHyDbNnwoyu8MumkP3Cd5qDgxpAyXbBb88r4FC
TpmtmQu2V3BIl4PhtwQbDg0Fh5rJq0AJ/bbkA8Evi7VkS1h5X30jXTbpgk3F
GwQfDA/rgtkopS8HZI0+BIBt7ijWsTIPsuP9DU1zV3Lftnw27yvd4fsFb7eE
hrO/Gm64Q/BZKT0CnBE+ZIOcA17yUKzmQ/V3CPaW6rSH7xO8nSYk02TKwJw2
6rmmCfUhoQFA32DmvEyMwkvDMRHI9ui7XCEKjoQ7Sw2jZlZoIutHo6NmssFR
UXTEaIA2vtUSGdRH+nUReCPvVoc7VaF2ZQies/BEboDBNiTil4QXQe9mGTH1
QG+8xYPe80Oec4OXh/Ow19VgCE56M5CnzqTh51nzBzznObjPDbjP9ROc7Xed
HXCRZb/zDKCP4HSf43Svo6jXTtADsBV12051Wzl0WU8COi2AE9zSfKKD4HiH
6Xg7wMhwrN1wrM14rA2WDHoOrfqjrbpjbQz6460A3fE2DifadCfa9Cfa9Sfb
9ac6DSDboNlEpHstYE+X9NvB6Q2ObuiThq5osKFrxvh4MXINQJ80A1wSDVKI
IPNDoVHqb5T4yVLqA0B66od/+3L3sKKsffxck/RcIwUpSLIwdq5xHhroGrIU
EzSIzzaQJaB71PDE796U61znGkbP1WcB/pyL842j5xvFxY1jxU1jF5olJc3S
0hZZaavsYpu8rA2qpCjrUJR3jA/KrG/90zdU9bWNLzzV9MJTzS8StL/0686X
ft390q97//irwVd+NfzKr0SvPDH62hOS15+QAt54QrEw5G88AeA3gDJsD3vB
7oARejQ4JhwZjg8nArCTtr3x0nBJyZ3f/Lo3Ojmgj/CIpaYFoMEESoIugkDn
uB+wFGFmD1yQBJE+MGoIjhF5DsnMuqJ1gi2d4XFrWGkLNxAF1atBNdc3DoBU
2/VgTwt2wWAzXlOJ4p6VhlXSxnsF+xrsYZUt3F8OJtG+Bhspq2whCuFWwYYz
kpDSRlC/U3BvmU5pDfHog112wUg22H5kKwwdAdkmBwSBj2odnIW9vS+udVFP
+ycwsG2O1jKVpYhrneCQj2t6DwgeaBkgQhtXO+ZAJQWrV7C1J6ZyUNhj9RBh
u765zw7+/FhvxSNQ7rXFemnccpGE+PnB3gV97QahtcaI1bvu4bvXNXVZozJr
tHqn4O6LBqnFQIKASKdvVCImXbxVtHsYum/h4dtOnMMi8E7fuXZfhSEsEoI8
CAT3g0oFmOgOanwEat8AQOUdUA28KXjwYD8UvP0qb/FWwS/OKvtVygP3soK3
7uyDgntrapXeProBxcAbgj3FrNxf8wvBnvMq8m2fauB1wYP7+6Gg3A/Nhr24
7VVwtDcafP0qHz2+qk/l61MNvi4QvN4AhfzoV9G9Gv396hwMvSl46OCAv/7s
Q4JtQwNq/4Aa1sBh1bSsPnjvQ7+4V/BmI5T9AwN1vxCky+Rbggvb0htrAgOa
APz5ZhMp8Kg/95Dgvrr6rDVZ3w6Tc53T5G4v2HuBbE++ZUeDwwq2DZPNmuAt
oa6e1IRtk0FmG34l2Qxalz5UY4BVmLWUNPneunquXYQE1qJcaPwDBIFBbZBh
SAdvM9BZIhzWsZeDkbfB6zAcFvIFQ/gidTaAiguFjeSa2TFCygZuyyGd7uB9
gjeaQ32aELyUd6mCHePBNkWgBbJSSP31Yz54QFdBkNGItww6OMHFOuQGaw/0
5kyf63Sfs6gX4Focp3tdlw1y8DyAk94s5NaHNMrJQEngyqd7HEUM3Y5T3XaC
HljaTjJ02U50WU90AizHAR2WYx1mgnbz8XbzsTaA6SigFZbGI4BWA4cW/WFA
M0B3uEUHy0PN2kNNusNNsOShOdSkOdRIcLiJgBTS5SNN6sNN6iNNmiPNmqPN
mmMt2uOtWtBsEOmiDsPpTmJDF/daLwzYSwYdZaQfmo8a83Jh3jTAG0xqQO0o
XBis4K0Ve2rBzqYFeGy+t/vE29s+GZDbq3s0pR2qkjZlSdt4egkFBf0TlhSt
2ZCXtAJgDStw6Jeaf/3Cu+NGb0mrjENLusCvSRdKW+UgwxfbFQDQ4PJOZUWn
qrJLVdWtqerRQJWqe7UilXPT9/9e3dLc9uYf2976Y8dbL3W9/VLP2y/1vfvS
4LsvDW16SbT5JfHmFyVbXpS9/6Ji6wsA1dbfqy8Him2/V2x7Qbb1BcnWF8fe
e1FE8NLQ5pcGN73U985LXYDNr/R+sGns7Klz+w9vfuhBT2SiTxMG9FMQYSZK
TMSYgUgyoEPhW4oww4NjSAPWGKfNYqLNQalJd2qtYEtHWGEJjYNwjjXcC7or
YVpLPveuAwUlyVtAPtlnayenryC3ZAOiuLozmQgg2CAIQ8/fF2w4LQ4qLAS1
HwnuuahlZcA4Bayknw33rqMHAZHuAjOafnY1cQ52Z0wjayZmOvfZ3+iMqXMg
awYBynw+FoP0AkB0M+jmPfMgvVGFzQCvI/wxa6Hf3RrtLntYsHN/euzs/up0
ZJaURGaBF1rP+oZJ5FSpfsyk5zt9oYNWDP3B9HPnWuZ6Jc5P4tjcIRwBg0k/
/LZAcMd5zaDGT8WYE2Cio8rxfXNqv/vcuPvc+4LbTyt6x929vdW3c7XcfVbp
6Rkn6E0DNnutjq4km+0+S78FVJ8GFa+uptufpV3c3Oee6hpYqfSc5X9LgeD2
M+OwpkfZ/xocQentzcK5rM0g5G9fX/a3IP8P7ev39ap86c0euv1ewe1nVbAG
UAPqJdhzjpbTf6arsXWQ7cVv3Kcael3w6XmVvy8DWDPnA5Lf108EnvtsHWIb
n89U8qH9/ekjNIC3gH7urauFzciO3Ldke1iZfSi2zZxDwcvK/EPV1nDNUfE/
GbzTsAbOB33XoQdRE8CbzYAalF4Dypr5bB8e1GrBJ0E/n5XoQtQE1w3pQqDB
1FcBBYAQ/BMHB0MDWu2B+wSvNwZ7VOSlvGM80Cb3t8jADPLVj5HHLrg3K4Tu
smF3CenvJK7Xs2D5gRT1OE/1OE52LwmniEploccB+14uOMHjle9mFHLrzKSX
avBJhi4AEWCiwUSAKTqIBcyU+Dgxf5kYUw0m4DT4MMhwixFwuMVwuNlwqFnP
cBBkuEl3sElL0Kg90Kg50KA52KgGHAA05EB1oJ6igYKWDwIaAEoK1eFGNUGT
+miz+liLBqxqKs/GM13mcz1gPUMntAPCx4g8D7uJQhORJoAOadYnDage8VSL
3Aw13NLVrfSLVZZfrn/8lU0f9gjlSktQZvTLjX5+mfOn3OiTGX2w5GDwyQw+
eRYgbAfw+1ff9wTjcoP3EjB65UavwugjMPnGTX6A0gwIqCxBAmtITbHj3//Z
qVSra6u0tVW62kp9HYGxrtJUV2luILA3lQOcTeUuCvflA/aC3dlxbI3l5LD0
+Oxc+qb6oarKU7v33PGPf6fQ2SBOqFcd5BFNTgt4Mc5SZX/70oQZnhRgn1Ft
9gl1frCbxYYA1eagzBySW0IKa1hhpfIM1nMWxkGzORBB5fU1t2AOKggCPOTm
wNLAHzM0biOGu9ImgucndbBTOGCZtneJycutV9qhjzwX0HHOoMiC3AYhb0R9
KSLgw4de9gzMEeh37yCBPCJQX4YxEwdm+3KRWdBPT0E6HcEUToPvZeQKRIwJ
mG9zSAdmEzyUiVEFBm4fET8mou4ehbsbIHflRZfcReHORrcctqdranfDmNac
b+dvmdkedlEsAHYo8q2n+7Iw7u3Ohyp4OXh/IO9X81f21O8RbB3oUXqXLbqV
+Zu5SAN7xr0cSLuYcvsZ+tSBfh7ETA8OaC+Nfk2wjz4OelQBqsp+qsq+JomX
qjJ58lJVdpUMkvijc6QfFFSZWIRMik50XRpUq+aCl7FFC5zFyYkfk8DlhbQS
c3p8ghjEoMdEko8TPSaSTMXYcrwdwBnHRJKJKlM9JmaxESSZiHHaLCZ63AQA
MdYdbNQdADFuAj2mkkxUWb0fUA9Q7W+gYOU6inrl/joe4+RPigN1ygP18Oc4
LA/Wjx9qUB1qBIVWEXmm2gwubqrNYDpbIIjsQr+9dIBEd5cNueACoDY0B7gk
OIUecVWOuKoI3HRJ0CZxjZt82w8UP/LMa7fd+zDBPRT3PvwzWmBLVmC47Z4N
P7tnAyx5wJ9pPASFX9y7BNy34RcUvyR4mOD+h++guHPtIxSP3rWOw+N/+5W7
v8Hhnr/5yj3f/Mv7vvlX9/3tV+//u6+u/fuvrf2Hr6/7h79e/7//ev0/fuOB
f/rGQ//0Nw/98zcp/nbDP/8tLDl8iys88M9/+2DWevgTsP6fv7nun7659h//
5v7//Y37/uGv7/2Hv77n779+99/dcufffu2Ob/4V4Fff+btPHntAbw+O6ALw
WpwNIsxzLWZiNHcoCJZiMfcpwWsK7lPiSmXCPEqFecwUpD5tqs0WbgmFbMBX
BLBNfgTlZg4ycyADU0C2AKTp9VzBTF8OSB3g5SA83kl6oOsgNo2Ep8Eyr+1L
zYx1xAs9TuLMOSWeq8FEicH/nA0aF50NGiNtgp7ghwUfiqBALGAGqsEkdgki
gBbQYKEeXJEEw/NAbZ0Q+DCZ4xRspj61r1fpA/npHvdwGil3dwJkrhx0yFxz
4e6Q8WBfkT+L3hP87JQi66vszfKV5e6OfKgoeuCVWv4rT6d8yVB4O/Ng4BXB
g5/25P1q3sqemp8L9pwZ93Utb+Rr5pIa2DXuhaZ1A5QAfw+AyHOgV80B5JYA
dDcfQI8Z0qrMOrAC7Qp/q9zfDJ2FEl8dyU3hqYIRsUI3DLlh5jLEKJ0hvaSc
uXyDLWZmrd50uzmPoc8ZzeA84O1mqtBUpE9yRjO1mzmR5hXaTBXaxOQ5V6Fb
qMXcpCfyzIEo9MFGMJc5hWYiTZdMntMKDTrN7Gaq07DkzGhSYHazErSZOLeZ
ZxuM5jb9qXbodTaf7aHh3P3Ep03HXIEqu8uExHTmrWcmzGl5BlVmwuyupgW4
ILXOmM2fyA9fZr3dHyfb+OLZsGf9CeXsP9ObxWy+mD0Dsk0G/jgcFuAgSDgD
FMGkiyDlCqXcDGHAxBXAE564hpDNtZWZ0UyEmetjJo6sbASWIszwzt6vIkbb
oIb0dEJnM0QhQWezGLSZ9jdLzZw8gzpygACxNGTmMGjnQpCaieU9HxKi+oFc
GMkLAfeVEb4lZalJezITcfpw0VgETFsaOk46fcftMYWdLOFPtoaBxFtBN3AW
MqOEyUDhDCTmGIDGxNKxvxTcKCA6FogMfflwFMYO8VG7I0YRuKDhFeGiISJM
Y9gQ4aCPDFMMMegigwRhHgPa8IA21K9NP3CJrUOey/CM7lJ4O+QehnaZm0Dq
YmjLD3eb1N0qdTEssE32erZ9LtqknjbZZaNd5mmHesq9S0F5ERmf/rMi5dyN
fe3yRaHwQY/Mcsai9Z/PTKaxXKPSHU/wMg3KCvcviRShISM9cGGoSZ/xIuil
38LGsCP0K7crAq3yQDM4saFrWeKrFUMOKW8lpK0Qei6SwTwknPgchDJxvbwQ
x8T1rbIe1uvS2bz8e5qhhpnOZuhrT1PRA+8u1FdPHfgg2KeyXNycVGd6mqlO
055mptNp5zZnSc93bh9q1lH/NnVup/3bB5uIYFP/NvV1E3c36DeR7YM8wAFO
y4eaCNJdzloizCQijAgzsZj7iMVcAhbzIKfKFUKSt4TkKhF5ARB2QDqeRQBP
NfGseGu4AvGywCsd/FkzCgXi5QbUErgANXRZK3JmMOKsHXHUihyZ5Yi9locQ
yrZaIQVXsNYJraxcx2PEVjdiq2cQ2RpE9sZRgKNpzNk85mqRuskzSu6FG6dT
4YeuW3KzsDuFIJTBArcM3CxLR586lAsNieGYC9KjvBCi0MfMBkflxmZrljRc
ijjQwG6j0SgkgjQdpD1K47THTAQSMwEEbOdAYg5DIDeI90IAszsbIPZZCIiN
FIYcBKGfG6x2sp5tz9UhDKeTWiJg2sIbChFaLkNWTsZK+idNg8Ulw4IBo3OQ
SazBjy4lBVNs1BQTEUQZRgDGqJCHISo0RIcphgwRhkGAfg5IVJ6OoF8Xno8+
XbgXfin2Y2U9VZmTA3ofQLfaZN5WmQcuRECzZD5czRKCpjzIu31mZZPEvRCa
JZ5LQ+pplnpz0CLzXiVaZb7FICcm4PLFgpVfkJZMY2m72sjvzgCO6GCHMtjJ
IQSR1V2qcB6ow11pwDYdNAC7bTzUOg7TApIw7EY6dSBMhEAyPqYjsSHTBQwB
IsHYEBSdDkU+O0ACki83MDu9/VWEZ9+UwGx20gXCszMkME4IIDCbw5l0rByJ
zSZhYiQ2m/YI2Iu6SWz2KYZu60kAic22nACQbmnSIU37pCEkm3RLE7QBjFS8
DYCjgFb9EYYW/dEW3ZEcNMMaLeAoXR5p1h4FkD91EMJNIrfb9Cc7aJB2NzGX
YTz0BehjBluZdDCDGIMS+ypJsk+SBLQmDZKFOw2S6ZPk+8wB6RAB1NFl/Zin
XuzhlqTgrhcTNJClC9DAlqOwdDaMOutHnQ1cwdEwSlBPlxT2rALTYAK6nhSa
xI5mTpLB6iCqDM/GDrBelOQVlr229hKlZGODYTBCBv3ayIIgT2YO7EF97UFj
s0nwF+QSAZChzHQcc1oY6NgJOnwCdB7aQF+9g70aMLQD4AEjfjDwhhGfKkSH
Ev8qjQuFaE8yPpWNbwa3LaS2gFHOACLDWWCanQPQ8vkYNYY4EMXlQXzm4Dmf
DzZsl6wnGwT53Un/LriXLRES80wyTVLphfzPdMnlmMxkoSI5mFhqKoA4jVFL
nIM5PkohMhM9HqEQArLGog0bYxTRIYpBQxZ4zvVk2ChF5ifnmGf86yK9Wg49
mggHdaRbHYHHKzxYO5UheBy3j4O542+R+1pA/CSeJorGMTcBueLpJT4HroYx
V2Me0F2y0DDmzkbjmKcRjnyF8DZK5qBJ6p0HX5P0MgAW3qUB7tlli3z1X4SB
7Ma2kF88AABLF4Y2gbi2KYnKUoQ7VIAIDxiUnAs1+bZdFW6DeQDpeGXILNGk
CDXQSX9r6ahlSNFcJQ7SlJAsIxU3fBmG8LIRzPNBRvdeu2HNy3w0M1+9zLBm
fkxzeljzBfpCQ99pYDSzp3iQwV08QOLbz/cTnCOjmZ1n+x0EfXQoM8XpXhug
qMda1E1wqtsCKOqyAk51WU6RIVXmNEwnOzic6DCeaKfoMBC0G463kyUB/RO6
kxlOtYMeG2CsM4R9ne22nKNObAjMhnFTZSQ7mKeSpPCEcVOgwXTSKjJRFT/9
M+QLIyBzShLQ/Nu00JQLP7mkIXZB6muW0nLWjQ8v603krd0DS3hq0Vd8d7OU
mAFQICbEmAusXgIwKrgy2MHEFKYGMYWEoGWMQuJslVAvIHgNiVvO0wmGMvT7
qIgkEz3WhkF6idIRu2jukzn7KU3LQ1eBtAQwIbgMxGAc8zDk/MqBkaTkHCKI
D5EsYDGWgYSIB7SHNom6WIm7FWw+MP7A+0rHYERGjAQiLtlTOosT9K2aOYya
IxzINkS/M0iHQbFgKB4wTjoHoP1CQ5BAvzjIcE/SlUuOBueF+hCVJXJLNBgy
HaZnP6QFfuLC7JmJsxOyiCCFeBqQTnzEkhCaswDZTCl1HHuGxJCBJFFiGCCI
M/QD9PG+NHr1cQIdQU82IMtdFiANE0MXTKSqiXZqouzBCk/h1vEwjPFvhvuB
DihsAEi8DfCKOuapEy8M+JZuQ95kOXAvufyrLrzt5oB+BSG7WYAIXgJwgS4I
MuqRDHzMBhsQebVIPxf4B8S8gjwE+YyWKTLPtUy1yfNuYVqy20tn2CWCCrJK
AQmbaM4mkrYpBvP60ZxNcR4dkG0xC+0qktUL0Krkcns1kfResQY5l+GLZnWO
VksBXNYtkgZr0Wxfi+QCu7aJwKAmyyURGOWkcizMGsgnAmO5wAhIIrBQGWQB
ExFcJO83AS4ZC32PYclJmIRzaUloZpKchCTnoJs/LeGQluRsn50kJCHZSCh6
yBKEHNKSUHCZSc6w5CRpnOHLPZYzPRYwkc9CjrBe0qkMhjJk9CSGMnFZ+2DC
DHg5o1M+hxvkEcj71jTOoXk8CmhRRiGLJ4EyQuaqImVWiLSR65A8l9IAlwzn
mIG0JOCeIYDeE0WgjWQmgSWAxB6SJSvIfYBWgIwVvOCLBo8gt4QCQXYnGvcn
6/DqgK49CFWhVjIvyUS/iEkKcgsyGSfPapqCmoB7kieFkJeaAhJUXwGyNWKx
sjkpWhgkwYjIOpEBmb4iC7R+nGzThJ0kW6chBq2CzJ0AYg7CCwV9FyDGIhiO
pEAcudSjGwODchTAeXo5Ny/n7zVGRbmIiAwcRkDjKWhHLEg+A82rwIKT0xjS
h+YAYqPSSK+nbwwGMGrjIlNCZE6ILIlRaxIgtqbENgCZU4vHqBWSBhNk0TIh
shCMMJgnhGkMmyeGTZBbmMysAvOrDBpTA9kwpCDhMKAvC70GmP2UANLEk2Tx
FJA4nqGLZieGVPILQpuATLbtaoI28mCNt5KMiVFi7pAMTUEyNTpJCkGmkYH5
ZCBLABtxmB8sk0Aa0LNYm+Wt4t1Wcwp0UjnyBp0NCXmhvhSCdeQ+zwGklJoH
Mg/8ZQAeHIsB5plftlig5os3n28sPC7ZE5M8NBXRZqKv8RZVgkerKtGqXhBt
6a/Y9s2qRJOSgM4TTKdhUMAcDFyOay4ttixRncbSE2UvtGXBZM+unZc9m+XQ
rpbFqiF1NkUV5DElqUyj6ZebTCJPTrbTyk31O1A2Qv0TkLkTsomR/J2QXIzm
FAP9HuayiXFpO9OZO2lCMRfR73RasfOQVoxkFuMAWTxhDQVL6gkZPR0Q1ncB
8mwPQuZtCPLyQBqZSuK1pqpMJRle15ogJ6uKXFrkilIl4MrhQZ5F6ScSeQXU
kDSu8P5HJq2iuTyzs3h2ED9NtFMFGT2JC4f6dSiI5y8bJO4BBu91wGABMl4g
XYY1JLSCBimn45S5Ib7jJKCElbsYOEmmXmuwksGY1FP9MsapEoPuErEjs0WQ
CRW5x/5SCmLrxGKYKyg5+gJ/srTY89fza+KQK1tsn8qATDPFYdQ2CfNNceJE
55viXiXSrxgjpgRAaI4DRhhMsExQgI+XAny/XJmINHP88r5f5gHmQBV9PjKB
UTRCakgfBgxmkJFhXo9pIRMwRfpxSedubNhEfg9q6Sbhl4CmkQm1SDMnR+0c
RLZJhhEe1kkhxTADP/8oTL/DwM+DRudHY3OlsXnTYO5xmEONoTeNHsMkQ3cG
ZPaeHHTqJzLQTXTqyPQ+DO0M6akF4MnboorDndOgAAUKwzOdTqXOzdjKpmhl
k8TxgGnjssAmkqOgc7ump5ljk80tAPBzZoFMUUcmb7802DTvWSAzwOcBm492
iWATyy8GmHx+2SJPzRdveLqlESiQOQTBxh0HxBtBVkFcVclmmG1CnWrRAMh8
UK0wK1Q+cN/SbaDMpo0CNAG4WYQz0yjBlEr1CyMz4dLlzTfFjl8As07NnWiL
zDdFUE8m/CCoo9N+sJk/QMWpkMN8UzGY94JMd0F8EtyMF9ykF3mmu0jPeEGS
b8OMF5B52wdzXZSOeAlY2m1ulgsPSb5N82/DpBclMAadTHoByWFcAH7SiwtD
TgBMg1E67AIr+aLQUwbhXTByHR4U8JINhjKzkuFtj7zewSwmMJdJqkPLPYXg
iQTogiU8qYgtQaGfY1HApBddOpgMAyatglmfqbePJmDv0sa6tbEukvmVOP9o
IdqliUAiWLKErjpSIEnoukgmSr4AZS4xZbeKLwS7YLCfKgBmMclZmQbpSIaO
V95xTVSAGpPUOCZ6TMUY9A7mV8zC1BhMguxYEsiMydcUMMMbA5nEQuKYngvu
ZKRyTLPZpJDMiGTvF9Sdm23mg1VOBI9TZbBK08IMBVBrMFWz1hD9ngchvMUQ
zHPEp2OmaNhUdIj0zs4NmMr0wEPPAQEJXaZdtlzPPPFdgJVPLH76q8AbRkoE
IEbwpMg6BbPPcksoMFjJfLQMQgYLmZ6Wgc0QPmQms9UyDKQBc4wz9MEsthS9
HCZ7jBl0Gyc5GCa75qLTMDkH+smObNAJcTnQRy08fOEpTB7Hyjg8mukcAzC/
OpnMlWlq1SiAmzyOdRZmg00qVzkK/YhpiEm3IkXoEqDz0zFUj5HZ65aASI1k
LsgEtGRShBzUSmF2vNhlQB6vKyBcquEwlxEhhzUZpvglc/2OE0sXpn4CTSVg
8wRrCMjMwTCJ8qLInnW4iZ9cmU483HT5WM3zNLOZqoF/DtxclvMniExSnwR1
S9DfEaaGJIApqug0IdB9QEA89mG4v6oI6IyQ0OtPJ4Vk80LS+an85SKCMpoz
tXwElpCpjQNMTnVxxEuWEGCfRtkwBNu7OT0WwjSRZAZJcF+T2Z2prVwvDVPf
NTGUiSqDJBMlnuzUT3bx4E0L/WSPnlgaMENoj56CugN70x7BHj1M9pzsZUs6
MxVdcnNSwbRUvdpYD4doj5Zka++B2BpNlEXV9HLhNWGSNDqdQ7qHBj+xMFgW
zJUNGgJNYrsgipb1JRP3NdEd8JiCJKfAHhNTSWbiKnVMS2FK8ssEzGJ+VXBN
y+aCTclMhFnqmpFkwRmd9cRmMojOeKIz7ug0QQQw5ZqP8JRrSZh0hbMQmnTl
YsIVmnDmRXDCSeHIQSDlmAd7eg1f4PYKTToJ+NpOu0iLADM8XJGZvHBGZgjC
HBzhmYVgD8/MQWjGtgCsoRlr8EpgCc4wmAPTAG76ZzLl8yTA4JvQ+1J6L0yM
zSOp88BU2fngIV9RZG+/tDKc4kowoffOBalwXtDJMa8aBh9wAiAzXi9LkOpd
QTPT7Zpks3rzc37D/N8mP1wVGZgDcKksBlNg5triEmeES7cgQe5H2jTC55yf
gP/TGJgimD9Bu2/KSK5Pdq1OGrwEuXeKN6Wfd5/SeeqSBHNucD7B8JwCJPbP
yj0MSf4hRTFDQusmgGl4yMQB3pTBmzL6YFa9SbN/ysymvg1OA6yA9Lz1/Kz2
tjDMbQ8POm6Se75gJ2um7DkITpGVQYZJgI0u52HCHkwjQAuwJEgBbHR5CQRT
dgKqGkRWmPoQCQMhI0/+6DSoG0FsxnutEJ/xXibcsVm5eyYbiak/gTDP8nBF
Z48XVz387BsIZAAZQAaQAWQAGbjeDJwsrgJtVrgzSIIwy9yzPLzx2Ueee2N2
9k8IZAAZQAaQAWQAGbjeDIDm+uILC7PUPcuEeWZ2dnoGgQwgA8gAMoAMIAPX
kQFQ28WEGVSZF+bJqZlEahqBDCADyAAygAwgA9ePAVDb/MLMJDlbmFOT05H4
JAIZQAaQAWQAGUAGrh8DoLZLFeZkajoYmUAgA8gAMoAMIAPIwPVjANR2AWHO
isr2xmYhAi0an3T5EghkABlABpABZAAZuH4MgNqC5kJ0l9ydARkuJXHO8IDh
XLBRJDZp98TzoeJhOmEx+3x3i9Q+9OF3Bf+yaQg2hq9Y4Wow5/gPn885VPoU
mZNe6bnOP5FuxBOnF2zp1TdnseqdfpQSyJ8dqvRoRRafV9q0Rfnf9D3a7u99
2HdVP9O1qts1uWausjJSjpNL0HLdqwrXQ85nzuVx6d/r6mt4ve/uJf1SwEPW
jT+3UZd9j1w9J0uqc9ZDb/4ZF6nDja/e5TYHt7/uDIDaUmGeN44Z0n6NpQFD
rTc887rbl5Br/flwYa3g+6+2Xu5Xebe/goPMP/si9Vn4pK1bvyV47ABrYOvW
V49eQU1ydrmiahx9TPDABZ7kAw8I1uavydLZW8qWV1TV/BfDUk63+DY3uzLk
SsiifcGLAVpxw6p6xSe64h3532gpd/fVn+VSl032fUF/oG+9OcJuk/o3v8+X
F3hAXYsb86qu9st6Rl1/Mq+qLZf6pfDg14IBUFvQXEhvkp1BjGT+GrVP8YBM
KA89/RoV5kA+lFBhvtyv8m5/BQeZf/ZF6rPwSeHO//a2+vwN5Pe6rCNf1sbp
U7Ruo+8H7E84Al9eOl1XsOUVVfUSXF1BNfhWL3Q5XfExl76j6NVvgyovcfsb
xtsVn+iKd1zKNc8f/OrPcinC4b5I356gxGvf3PatB0roPQK/1+VeLde/trm3
xmU9o2589S5F/vW60/G8CzIAagua64lCYuxM5m0izNyMSXTeJEhX9sBvXnX7
EwpdIB/IlfRaW/ZX/Jqsr9pActjnsYP5j5P34LBy/vEDivTRvvXWtvTZ2Waw
TH8eKFmgwgu1QvCtt0Rzdsmt8+LNEb32He7Ua49dcTXIQdYeozU8BtYza8KC
5z0IJjXbOGeby247+wXpiY5xvxQcueGt77Mm8czAGbkPf4o8v0XmB7omP/fc
k2ZRxFj6zrYGKOT7sdY+APV/7DIuA3KQBa7PzPEX4DxNTPYvwipwUJd9bSx0
nS+yft4tkKcy2QzMr+EVV+CSd/e8S33hH+IqeID6s0uUFcg7K32MZBeyruG3
Hsu5bvM9MfIwtugNdT04zH/dzr8Zcx9Nl/cIvYJLDne5mQyA2j7wm1cgRWhm
ekPbBJldasiU4OEMT65/6mWPPzmuD+ZDybqsfrB1x2AbWPP919vzFoLjxzZ+
++3RBQ51yeNvPETqQM5ITxRsfBsefAufK3+F854FVo6+TpWVHTmrFXyd57eL
/4rsO7dd/MYLnS7/emgRO86hB+fXJOuYjMZjGwUPlpDawp/f4Xbkj7BkkrPb
JQCda6QHBCq4FpEyY57HnF0W/i2u7OdmP+h8pE/KtzrD0jxm6EVymVdacLx9
27dZ83ORueTINnkuufSPNefbLALZz3SFyLmWFqpM3jpQMrMYu8w6XObdnbn3
s++aa8BD+nYoWUd/oEMP5rRr7jWcvinS1+1CT4x5jC1yQ10jDtMPy5ynVt6H
TPpmzFxUV3wJ4Y4riQFQW9BcMIlhUigyOxSdpJnMx9yvj/brOEC+77VP/sET
SCoNoXwoXSf4wesd2V/xa9KFju3fzg5iebB0gUMt7fhwtO9sb+IqM+9chvn1
yXvYBVbSqq47HlLmqfPCzSEbbzw8h58rrQbXOlB6ntVFz0upOPzgD14/zmjJ
3nGJDZ/PIeyYXf+s8nEi2PRDq5f3t7i2PzewmnNSUjfGduk6diUs8mPlv2gX
+fVzfke65dzf9zC8M8EVwlO0+Lfp6sFbwuVc9nlvqIUrc+kaEnW8/Aos4e7O
vlQW/yHot1dUDXoNwHODLQ2hprd/AMdhS9qoRa/hBa/SzG/N/abpLfPcUFde
+YU5XIyuOXulL7kl3tG42cpmANQWNBembiJzJ6YRS80I2ERaDDBlx71PvOQN
JNXGUD6Urhf84I3O7K/4NelCJ9GtI/l3z3vMvEdLr4SjfWd7M3e0eecyzq/P
JU8xZ4Pmd34AN786T50Xbs4iG192q0ff+M4P3jiRr415zkI37ixdTwiB8sYj
c8hZYsPncwg7ZtM4v+HsvCHC0vzf4pr/3NzFkz6pMQS/0bffGWVLck1eM/7h
FIL1J+bxNvf4Rx5k2+S/HnK/TV8A5LoS5Dv4pa+QuZd03sosXkN6iiuqwBLu
7uxLZQk/xBVVg7vSjrzzA+7XgRM9uJ27CEnrFr2Gl3CVpn+1S9xQV1T5hTlc
jK7svRa4LC995SzxCYCbLS8GQG1Bcx3BFDdJMZ2tOJaaFnQqgzys/uQ9G1/w
BVMaUzgfLoIwv9mV/RW/Jrsg+PY74gWOkPew/Mq8x4cHHNmghTzs2Nnnn3Tx
w8799sT2dBPEb4JTmlQVDphT50Waw++1SLWXWh/aqOxTL0YjbPzt74A+EW6h
vP6hjZfPc17qsmlPl09sFHxnewtcBl3wpsXTnve3uHY/d56T0gp8Z+P67/AX
3iI/1lJp5y5OOB2Rz/ReXdvfJGVyfG4lafvGo+RemPO7LPxtpgLkx7qSuyDn
FlioMovUkKvD5VdgiXf35f0Ql18NqD+5xdI3O/eLgKea/hAL3f55fqC5T4z5
jJGbaPEb6vIrvziHS3jIZC65y7yY8z+x8SDLnQFQW9BcmL8SJpbmEU1OCzrG
AzwsvuTdjz3vD03oLNF8KH9A8IO3urO/4tdkfdW9Ix0aJRBsKF/gUAsdP+MH
/84mCdn31ONs1Xc27UifPXOuYxvod1d8Fn7H3Dov3hz4Nh0XdYo05IqqQRkg
582mdNHzZm+cu2NePnNXvvVdWu3v7mizZP+UecuS9MaPP/DddA3z/BasCenP
Ff8Q5PeFnzvfSRm92Ude5MfKf90uTE72oQgt/I/C+fDTV3ve34X/4bK+TVMk
EDx+7HIrQ7afd4tlaph1neRZmd7xyiuwpLt7zqW+yA9x5dUgP0Hbph/Qq5T7
4eZeAPmeOdm8XeIqzaEx/Wf2DXXllV+Ew/l3ypyGPLCBvKPD5wH6SEGsEgZA
bUFzbf5ktyoI6KEgwtyu8POw+BJ3PfZ8IDxhsEYRyMCCDPSAGD9+/EZdJMc3
CB4swgsSGShUBsofFPzg7Z5CbR22azEGQG1Bc6kwB3jkt5hhU6MtNh8ZYzZd
yrvZFa+83sdnFbsxZ7kkCfOrAWsuuddVbsCf9CqPcwJM2O/u6Mx3kSz9yEv9
IXp3fOeqz7WUi5nVZ+n1v7Zb3pTr4fo14YqPnJeH7JVXfOQbsOMilV/07ESY
3+nN88i9AXXGU9xcBkBtsy1mZjcTYZ7fxxyMTJrscQQyMJcB6TvME04+T5y4
EVcIO+O/vNOHVyMyUMAMVDyEF/mNeJ4sx0sI1Bb6mCHsuienj7lbEyZQE7Co
7FBk0uyII5ABZAAZQAaQAWTg+jEAanvvEy9C8Fe/NkKgIyBR2TCIuS8NNo6Z
CnMCgQwgA8gAMoAMIAPXjwFQ2/zjmIeMCR6OEMn8Vd86gkAGkAFkABlABpCB
680An/kLkn8xkMxfQvMERQrAcmWHrujzJ/wgA8gAMoAMIAOrjwGIhbki2SQ7
sVzZo9YJHvEJmF3KNsnDHSGzS13ZCeC3uLIdcS9kABlABpABZGCFMnDy5Mmr
EWY2u9SYY4oHmV1qzD7Nw03nY+bZ0Wg0e/fufT7fB9bDt9k8ojCv0KsKq40M
IAPIADJwxQxcpTCz+ZilzmkeVJgdMzw80ZmHn32Drx+ob0VFRd7qwnr4tiCF
+Wrefa74p13OOyIhOb8OEoKELH7D4hWyqq6QqxTmh6kwy1wZJCb/JBhzzgIk
FJ7YbLYwg6m8yPWX823BWMx4U62qm+oKXonwCsErBIX5sm6cwr5l8grzLbdv
B03kl7Ozs1Cemp6C5cTERDZ7oLne+IzMPcsjMfUnAZNkXpgfybKYeemFQnt7
u8ViyT5cwQtz6UaaS+MH20cv6xosuI25m2p0O5fMN81IDj+rhy6OEK7BG0vT
v/jihBQwP/kJWcUXTFqHeAq4i2S1XyGhuYQUyhWSV5gzAXCgyTOz09MzoMqT
5DMB2jxPmGfl7gwuQ5hZR3O2PBe4MMM9RO8muHhWuTRnhDmjQaFQDj+ria7s
1//SjWlSFiekoPnJTwjcOav1guFvme30rY17huAVMrp9DiGFcoUsYjHP/mn2
yLHDjz/5GODwkUOTYCynUslkcknCnO3KXshizo4As9vtcNzCFubMNZNz9RSc
QXzJBuUV5hx+VhVdeXVocUIKm5+lCPOqumByPLes7XiF8I8ajoq5j9aVe4Us
ZDETVT56eO9ne1wup9Pp+HTv7kOHD6aSiSVZzKyPmWkz9DEvLsyrx2Iu3Zi2
k1GY2RA93u9EicnhZ1XRlVeHFieksPlZUJhpXxDr+lhVF8xcYeaajldIps+H
PVwL5ZGykMU8MzsDhjJoMriwJyYn7Hbb4088lkjG4/HYfIsZOph5bzZxZS9R
mFdbH/Po9o1c3zIK89yx8+nX/zn8rCq6FrCYFyOksPnJL8zpZ88qvGCyCEn7
r4kM4RUC10SGkBwDenF+LunYu4kb5BXmmZkZ6FYGYXY4HdSDnbTaLBufeAxk
Oa/FzCK/mDbPEWZQaHf0+kZlX3Fs3pXteFV7XWan4FWd6/KvqRt5upxzccRc
qo/5JtZw6XRefSUvo4+Zvt9cbsjC1ddw6WzAlld/ugwhWTFxpK95/gWz7Am5
MjayaJwrQpfsY15thBTKFbKQxTw1NQX9yuDBttltoMp/+OOLv3rqiaGhgVg0
kmsxw3CpnKhssWOGByQYWeI45uLi4isYx3zVF/plPWSu8imT9rMsLfTrypp2
ZXtdkwfo0qnkKslFlApYTFzGD8Xxk0vXlTXtRu51tTTyhEClCSc5DOT+ydy6
lxvkv4IJudQFc/0IefHFF7mDz/0P1i/9sr/iy4PfMRN0zP3sK/4KubKrcUFC
bt4VMv8yuLKmsb3yCjOoMg3BTh06fAA82GArgyoDXvrjC/929+/mCDNLMOLK
gIxjHrVP83BHrkHmr0VauHjjr2zHVbjX4o+MVUgIXlc5D5oruwYK5roKBoPr
1q3L0WZYA+sv64mM1xVeV0u5KRaymLkQ7FQikSD9yjU1VX/4w4tr19/3zqa3
sond8Ayk5JyROKYZIP8Xyfw1Yp3k4boWubJX+UPhWt35+FDAh8JSHgp5TUC8
Bz0ez49//ONsbYY1yBXPwJVdIVe21w2+jK+sklezV15hhl5l6EtO0hjsRDwG
y2g0DLYyqDJoc/alCLmy3dFpsX2KBxHmIXOKwETgvLrZpdjJrqyFV7zjlZ1u
Re+FXC1ds5GrVcsVJET63ve+B3c6W+ZV5Su+PK54x2tek+V/wILn6ipTcsLs
UjCvo8gyQWAlILNLDRgS/Wmw+ZgXuoIXXw+JTlj98IMMIAPIADKADKwSBq5S
mEFzneHJYVOCQWhOkPmYezQRHrZAau2Tf7gyYV4lvwE2ExlABpABZAAZyGHg
ynQT9gLNdQQnBvRRHrHUjKBLFeJh9afufeLyAhevuDa4IzKADCADyAAysMoZ
uPeJl+yBVJ8mwiOamha0KwI8LL7kPRtf4LNvL+WdyOVyLdLJsRIZ/9Of5rQb
/uSR/QWuZ2wgD8gD3hfsLkAeroCHlagR17bO9zz+gs2f6laGAD0qgmhyWtCm
8LfKOZi9ibsfe/6SEzhmX3//+I//WHjCnJkYBEvIADKADCAD14uBBYPyrq34
3ZijpVIpq9UKOTj9fj+MzeM/cPacoXrhcDgSibCRAndvfN7qT3YpAzyIMLfK
fYAWChDmu+YKc9656nhh/ta3vsXKN6bZN+Ys9KUPP8gAMoAMIAPXm4GC0o4r
FObHQJgTneN+igCACfPCFvMCaSmZGP+f//N/bDYbCvP1vnLx+MgAMoAMFCQD
BWbUXYUwJzvBYlZxoK7s8QCBAuC3+BKsj5nZpgvNVQdsrl27lpnhhSfMtN8U
P8gAMoAMIAPXlwEUZtBQ0FybP9mtCvIgwtypCjF0qEIWf/Lex1/khXmhueqe
e+453mOOwnx9r1w8OjKADCADBcoACjMIM4yEgqjsXm2YoU8bIVHZPdoIDxjH
fP+Tf8iymC899SEKc4HeMtgsZAAZQAauLwMozAuOY6Zpv+IMdpr5ixfm3Jna
8gVfoTBf3ysXj44MIAPIQMEysCqCv6LRKMxiAUteQrOjstf9mmb+MicYuMxf
XK5smjHbQXJlv5IR5tyZ7PIoc+EJM0ZlF+xDABuGDCADy4uBwhdmGBYFqgzj
irO1OVuYSa7syBTLkp3JlS20TvJgs0tlCfOCA5TmjKXH4VLL61rH2iADyAAy
sCIYKHBhZqr81a9+9fvf//6GDRt4bc4WZjK7VGTO7FJxmF1KZJ/mYJt20fmY
lyLMvGKjxbwiLn+sJDKADCADy4+BQhZmpspf//rXf/7zn7/++us7d+7ctm0b
0+ZsYd7wNJmPeQwmY3ZyINM+jjpmeLiiMw8/+wYK8/K7fLFGyAAygAwUGgOF
HfwFGgzjil999dVjx46Vl5c3NDR0dHTU19fD+mxhfviZ1z2xGYkrg8TknwRi
5+wowEHgjs6iMOM45kK7+7E9yAAysCwZKGxhZhbz/E+OxQyaS4V5VgpwEySm
/iQYc87ycMdmH3lutVvMKMzL8hbGSiEDyEChMVDYwrzEXNkgzN44J8mgyrJs
YQa7GYDCzHKZFdrlj+1BBpABZGD5MYDCDIrzCBVm0GMenMXMVBmFmUW0oTAv
v/sXa4QMIAMFyUAhB38t0WLOL8y8KqMwM2HGccwF+QDARiEDyMDyYwCFmbOY
mRObgVjMc4Q5in3MKMzL7+bFGiEDyEBhMoDCnBFmXpupMNN47KVHZeekFsFx
zIV5v2CrkAFkABm47gygMIdoVPYsF5VNY7PJcKlR+4woDRzHjK7s634n4gmQ
AWQAGaAMFF7wl1AovHjx4qG5n8OHD8MKWPKfkpKS0dFRNnXyw8+SccxjzhlJ
GlSYbVMAkZUAUnJi5i8M/sKHBjKADCADN4CBwhNmUGWbzZZIf9ggZr/f7/X6
PR6v2+1xOJwmk3lsTFpWVsaEGTTXE50ec0zxIJm/snNlO5ecK7uAU3KiMN+A
GxJPgQwgA8hA4QnzgQMHmCiDHkci0VA4HAyGrFa7yWTRG0wajV4ilff0Dshk
in379zFhZrmymYUspiC5sgdNSR7zZpdacBILFGa8qZABZAAZQAauhoGCFGZm
JdNJHsOBQNDn8+v1JrVaN65Uy2Tjg0MjXV19YDHzwkxmlwpPjVhSDCJLKj4x
K+jTxXnYg5MwNyQQfWlBTm9ReMFfaDFfzZ2G+yIDyAAysGQGCi34CyxmUOVY
LBYOR5gqu91etUanUKgkErlIJBkYEHZ29orFEl6YyXzMockhY4JHbGJG0KWJ
8LAGUvc/+YdVLsw4jnnJNxVuiAwgA8jA1TCAwhy6/8mX7IGJPl0U0E8RS80I
OpRBgvFg+3jQ4kve+/iLKMxXc6HhvsgAMoAMIANLYwCFOQSaawuketRhHtHU
tKBN7ge0Upi9iXs2voDCvLRLCrdCBpABZAAZuBoGUJhDoLlWX7JLGQB0K4OA
aHJa0CrztaRBhfn5pQhzTpqRpfdJL/8t0ZV9NfcZ7osMIAPIwBIZKNTgr8vq
Y7574/NWX6JznAgzAxXmtLmMFjNOYrHE2wk3QwaQAWTg6hlAYQbRAYsZOpFB
mAl4YW5XBhnasI8ZZ5e6+lsNj4AMIAPIwNIYQGEGzYE+Zqs/1aUKdatCrJuZ
WMzdmki3OtJFgVHZOO3j0m4o3AoZQAaQgatlAIUZFIdGZad6tZE+bZRAF41C
VDYbxNxLgeOYUZiv9lbD/ZEBZAAZWCoDGPwVgnHMjtDkoCE+aASQ0cxkHPOQ
KTVo5OAITUEWkqUEfxVw5i8M/lrqPYXbIQPIADJwVQygMIdAc53hKaE5BaDJ
vyZI5i+hZZKHMzwNeTtRmK/qSsOdkYGVwMDMzEwQ0viGYAJy/CADN4sBFGaS
KxumjxLZJgGjdgKSK1sEU0tRjODsUtQPgBbzzbpH8bw3hoHZ2dmJiQmHw1F0
qujTPZ9OTk7emPPiWZCBeQygMJPZpdzRabFjCsAmmCKzS82ZjzkyA5M2o8WM
9w8yUKgMgKHssNubm5pa29vNJsvpM6erqmtBqgu1vdiu5cwABn+R+Zhh2sdY
ZjJmmJWZzsfsmBHZObiilxbmnNQiOInFcr7usW7IAM8AqC/4rru7uz/bs7ep
qV5kdPQb4ia7++WXX9br9ajNeKnceAZQmIkwP/sGEWYXB6mLCrPYMQPaTOTZ
MQPC/Mhzq91ixtmlbvz9iWe8rgyA6IK/Wi6Xb/vggy1bt6q1OpkzebzPf7rf
b/AkFYrxfXv3ppLJ61oHPDgyMJ8BFOZsYQZJJnDPJKaoMPPa7EZhDoVQmPEJ
UhgMgB7DJxQKDg8NHjp0aO9n+3sHRxyhxLAlViIKnh/ynR7010iCqVTq+LGj
crmsMFqNrVhBDKAwc8IczZjLnDCPZQkzWsw4jnkF3dVY1bwMgBhDRzJ8kslk
V0/Hlk2b9uz5dFAocgfCQmO0uM/+3pGqo82q0tHgBaG3aMCrdcREo6MHPtsP
u6BDGy+qG8sABn9RV3ZamMGhTVzZxGJ2zYidM6NOdGVzY7MxKvvG3pl4tmvD
ALOPmSonk4lR8egbm99/64MdwuGRUCjsDKU6lKGLfcZXtuz57re+vfH510ok
7rP93lN93upRXywW3/LeexqNGiO0r82PgUdZKgMozJk+Zs6VzfUxM2Gm3cxo
MeNwqaXeULjdMmOASfLkREo0MlxeXnL8xInK+qZRmUptdukcIZE+2D0eqB3W
//6N9//pn/7p0d/+vk3l7dJEulTB0kGP2RPv7Og4sP8ARIeh0bzMftjCrg4K
M2cxj9HgL6bNJPhrzEn6mFk3MwozCnNhPwYKuHVg7GrVin179xw+eGREOOD1
uo12+7mm7rMtA8Nqu9wUEOp8PSrPmdreF15+/VxZncYdldkTCkds0BDp14Vj
kfj7m9+XSKWg7gXMEjZtmTGAwpx2ZTtpN7M7HfxFhBkt5qxpotGVvcxuXazO
ggyAdTs1Oen1uIVDA2dOFxUVnRCJBr1eZyIWSkQCDqf9XGPPntLm9pFxvdU/
bvaPWwMaR1Bjc2kdIbUrrrAn5I74uCMu7JfGA/7Wlra6mlrIPYKMIwM3hgEM
/uKDv0CIpQA+KpsJMzOa0WLG4K8bc0PiWa6eAZBkp93a0tx04dxpSBgyJh4L
+L3xaCAZDYIqx8L+WMQ3LFXsOV99rqnPaPW4/WF3MOoJxlyBuMUX17kTWndS
Zw3ZtDrz6T0h8aDT4Th/9hwsr75ueARkYCkMoDAzYYbxUBCFDalFAFzwFwgz
bzQvfbhUTpqRLINzxRdxuNRS7ijc5mYxwAYlu53Ogf6+yrLSsrLzI8LhcCQ0
MZFMxsOJiA+EOQ6IhOKxkMXmPFnXcaG51+L0JBLJUDThD8e9wbgjkDD7Y3ar
x6OUBsfa9ef2j/eLY7HY+fMXYLgzdjPfrB93tZ0XhTnbYs4IM9fHTKOyAUsX
5gKeXQqFebU9HVZKe2emp+G+MxgMfT09TfV1XR1tcrnU7/dOTqbisYjH60vE
wol4KAEWcywMwpyIhmKxiNpoHpapTXYPjJ6KxRPhaDwQjXu8Ab9eFRD3hsZ6
3eOStl7lxUEwpxOtzW3trR3ozV4pl8RKrycKM28xg9+amcuZ4C9mNKMws7cN
FOaVfrcXXv3BhHW73VKptLWpuam5ViQcdDodiUQcrORUMk4ENxa1Od3BcDCZ
iCUTkWQimozDMjYJUdqppM5sl2tN8VgCTO1EPBZ2WoPyoZCwI6QQB+y2MVOo
cixwbjAgNkYlMuWhfYfdXm/hcYgtWpYMYPAXdWVHiCsbVJgbxwwWM5R4Vzb2
MWNU9rK8e1dppaanpxPxuNvlEolEHa2tfd09MNQ4FPRNTKSikUgC5lNPJVOp
BADWBIIhi90FQp1KxWENmNFg+MIRIMra5QtKNSa3J5AKeKKG8ZCkNyQbDJuN
gUDQ6ov3qYLNUn+lyN8gCVoc/n37D1vMZvRmr9Jr7kY3G4WZCLOLzC7FdTNz
FjMTZgIHurJx2scbfV/i+fIyAGoaiUSsVmtLS0t7a+uocASmhIrH4xDwNT09
pVTI93zyUUtzM3iqwQgGAZ6iH63ZFksQkWZ/wlfwgUMlkkmlzqSTSIKgx5K+
qEEZD3gj4Zg3EFObAwMqX4c8UD8WrBgJ6l3R8+dKh4eEEzgXJF6aN4IBFGZm
MU+POQCc0UzGMZOxUywwG/qYYziJBc7HfCNuRzzHQgyAoPr9fq1GW1ZSVl9X
Z9Tow8Egk1jwXUejURDaI4cPfPc73/ntb3+lVMjIiCn6gYLJ6nK6/bABGMqw
BgQb9pqG/QIOy8iguKPJPy5JBd2g3PABk9vmDCmN/lGtv08ZaJUEK0UBhT3e
3zNQfrEmHk/gb4QMXH8GUJipxRyZHrXDfMzTLP6LCDMYzpBzhHmzUZjRlX39
b0U8wxwGQFBBR0EpvT7vuHK8t7e7rra2ubFJLR9PxuNMZalZnALftS8YTE5M
nD1z5qc/+T9vvPZHtUbDEn6BDMPSH4yM6yxsDUgzxIQl/LawbjSsGPQqRNBF
Df3QU9NTkLAzHo0EfEGbMwDjm+XGgFAb7JAH6yXBEWNMozNeuFAaDkXwd0IG
rjcDGPzFgr9ckalR2ySnzSzzF5sGkmkzRmVj8Nf1vhXx+DwD0P8LQ5hcLpdM
Jmtra7lwobi+rn5EOKJVq80mU9gfIGqcIl3FxPCdnoolYjaXy+b2mM2mpsa6
cYUSvsqyj8mmI0pdJJaYhs5nvyOilYQUA1GdLOl3JeNRjdkmVRvDoRCociQU
DAUCXg90Swc05oDYEIKe5iZZqEsZsblCpSUXLSYr/lLIwPVmAIWZE+YwEWax
fWrMThzanMWMwpw9+Bqjsq/33bjKj88ltYaxyB5PX1/fp/s/ff/dLWfPnlUq
FFazWa9RabUau9ma008M6qwYl1+sqrhQcrF/cFBnMIXCUSrYZEooZnNDQaK1
GIzGuFUdHGkNSfpjHgebMwqOZna6hiQqp8sTjxNhDgcDIX/Q6QrobWA0B4d1
4a7xcMt4xBObqq6uhtycq/xnwubfAAZQmHlhFlknRu1Umx3TWRYzc2XjfMw4
XOoG3I6r9RQgn36fX6FQ1NTUHDp8+ONP9hw+dBSSdknlYpVyHGZElivkKtW4
SqmCfmUmzLCL0+lqa28/9MmH+zf9/uzmZ05v/tWpd357atNTRza/fGLP1oqS
M2NjErfPDxuD49ohGWo8ezYs60+4LVOpJAuuZl3O0Vi8a1jSJZTEI+F4OAyn
CMEgaI/P7PCrLEGY5aJHFW6ShyzBVFdX1+DQ0Gr9lbDdN44BFGZemEesEyJm
NDNhhj5m1uFMXNlLCP7KyfnF/lzx6b6yGoAW8427L1fNmcA67ezsKjp16r3N
m99+5/19B49erKjv7BkeGhweGRocGRaKRkUSyRjRZrlUNq4CrzQZ5uT1nzxX
8t7bb53Z+nvh0be1Z7cYS7ab6nabmj4xtu1Wlm8THnq17YPfHH310V2vv3R0
y1uqQx9FlMLG1l670wPDpBi76S7qRDIV7xLJzzf0ujzeRDQSBm920B/0e53Q
02wPSvWBQX2kVRmSOGIjQlFfby9o+ar5fbChN4uBgtIO8FodOHAARk9AEr1w
OALDEX0+v9vtVWt0CoVKIpGLRJKBAWFnZ69YLNm3f5/H42HC7AxPjVhTzGge
c0wRYZbRPmbmzfYsQZhzNLjwhBknsbhZ92hBnhcSehw6dPiFP7z26+eef33L
J4eKyi/W9zS0DbZ2DML92dvdKxwYFA0Pi8VCmUSkHJdaTQZfICBTKj87uP+5
tXceeOIXol2/1RRvNl7cYWr6zNSy19T4ibFqp7F4m/r0e7ryD83Nn5maP1AW
vVG+7Tcfv3CfzWhQ2Rz9UnVqYpIl74QkJLSrOglllcF6prZTotLDowOGY0VC
oQjk1/b6zM6gyhIa0Ye6xkPD5phKa2ioa4QI74L8RbBRy4kBFGYmzJNCc5IT
ZjsI8yyxmInRTIHCjFHZy+mmLYS6gEn63O//+NaeCx8X1e8733LiYvOFiqbz
JTV79+w7VXSqv6d7eKhvZKhfOirSKhXDgwPFxef3fvbZ7l07Dv1hfelj/7d9
44/qHv2f1fd9o23j9/teuk3ywYPyI7/XnP/IUP2JqfpjU+0Oc/1Oz3ClW3bK
2XKXcPNfdzaUQoaRtiGpPxTlA7bZmGaIFPP4Q7U9oqZ+cSgSJsIMDu0QvNX7
IeBLYw1KdKF+VbhtPDiuMVeWlSuVqkL4AbANy5oBFGYqzKFJoSU5YkmREDDH
JBFmsJg5o9mJwowJRpb1TbwSKwce6aPHjr+64/CnZ5r3n646dr6mtLxl+4c7
7vrlz5587OHayvLR4SHZ2MiocPBM0en33tt86OD+puaG4eE+eX+HUTRkEnbr
u6rGiz/r2vrr8o3fLrv/GyV3/WP3H36iO/icqXars/t4UNPvG93rOfuf/r1f
NHz2pYuHXoUMIwMStcXuBmFmHzaeCoQ5EosPStWlLUMuX4DpMnVoB52ekM4W
lOlDQk24dsg0Oqatq6wUi8UrkXCs84piAIU5LcymJPFm2ybG7EyYYWbmtNGM
FjNazCvqrl4ZlVWMy/749oefnWncd7rmZHFNcUXDm2+9e+t//Mf9995z4fSZ
lrqao4cOfLLro1PHD/d2tanHJQa91mm3+f2+cCgcDgTdDqceYsPEI4axYfNA
k/TMrvbXHxja/Ji793Rg7Ky76nH//m8E9nwhtGeN/8ia2re/pzFZDTa3RK3n
s3exqGzizk4mzXZnSWO/ymBJJBKQrgQueIgC83pDJnsQYrNHtMGSFln3kLyq
snJ4cBATc66MK2zF1rLA4pOuuI/ZEZoYNiWoN5sYzZwwg8XMvNkozDiOecXe
48u34mCZfrx797a9F/adqTlxASzmxuPHTz//3O+feOLxrZs2Hdy/r6G2Riwa
NOjVLocl6PdEw8FYFFJi+0x6g0oqN8g1TpsFRjdBt3AMhiD7vT7dqL3l3NiW
jfq3vuvf+ReBXZ8HVQ7tWxM6vka28ytVpcfd/mCfWB6KxhgpTJjBmw3SHIpG
63tF/WIVjfiejkVjYRjS7A1Z7SGF0SdUes9V9dV3jNVW1/W0tELf9PKlFWu2
8hlAYWbBX0SYjfFhc0JkSY5aJ+LUYp6VAlwEntjsI8+9AT/30qOsCy/4C6Oy
V/79vrxaAJ7khoaG5/+w6bOTlSdLm06eOr9t+4evvfzyJ7t2Cfs6nRaTx+kI
+DygxYlEhCTlCgdMOs3o0LBaqgi4vYlklJi6CZiyMRBzGMOKgUB/o6OhaOB3
Px3Z+JfeHV8IfPT50KdrQgfWhI6s8Z/6wuFXf+xw+3pGVWY7N4iZDXQGVzb5
pCaG5Zq6XlEyNcG83KEAvAQEbI6AyuwfkNiKyjvLGoZrqhsaq6sgsnR5UYm1
KSwGUJgzwmwCYY6PEGFOEWGWu2dBm4k8ozDT9xEU5sK695dFazwu1/PPv/j2
jj1vbvrwjdffOnzo8FB/n8vhDAX8kaAfQqTBrwx5P/xel16nlIyJFHKpz+MA
ESU5siGNV8gXMSvDsu7QYH2opyrQXenrq1F/9nLXY//b8tqXQ7vXEGE+uCZ0
dE2oeE3TO98UDvaOqvVCpTo1SVJ18ilNmDRrrY7yjmGYkpl9BWuCvqDD7tdZ
gz1CzenKzuLa/srq5vLS8z6c/3FZXD4FWwkUZl6Yh4xxoSnOvNmcxcwbzV60
mFGYC/YhcNMaBg5hGJ/8u9/97qWXXjl66OjAwIDL5YSe3bDfBxm4ICE2WMke
j0OrGVdIxVqN0umwJ5OQJXsakl3Hva6gSuIf7QoJG4L9taG+2tBAg7+vITjU
5KwvEv3xDuHTXwkyYd6/JnRoTejMGtuhP6s+84HOZGkfkkF6Tj7+i82EAR+X
z1/RPqgymMG9DTm1YYNYJAYpwDQWf0uP5FxlZ1FFX3ldW2VxiduDI6Zu2mWz
Ok6MwV/UlR2cGDLFhk3xEerNnmMxgzwvXZhz0ows3fW9/LfEccyr44lw3VtJ
km1FoyMjIyUlJQf2768oLRWPiWDmKNJN7PG5nS7oRYbBVHarRaWUyyUjWpXK
5yVTP83A/BPxcNxjimhFIUm39Mxe8ZmPff21wYG64GB9cLgpMNgQJGjW7X+9
44FvuLd9KfTZGgIQ5pNrfCVravfcrzdo20TjNo+PCTNL/sUGTcFYKehm7hTJ
Qf6TCaLc8K3HF5FrrA2tg+eqO06Wt1fUt18oLrbb7dedJjzBqmYAhTktzEYi
zEJzYsSSoMLsmZUBqDd76cLM62vh9TGjMK/qB8W1aDzNo+ns7ek+f+7sieMn
GhsbVSpV0Of1+XwOu9NmszlsdpIWW60Zl0tVcjmUg8EAeKynEtGEzx6zKsPj
/SFxa3CoHlJeq8qOdOze5OypDg43B4aag8Im0ObgMAhzm6P2eM+j35f+/r8H
wWIGYQZv9vE1wXNrhHu/JR1uHVbqlSYrdVcT6WXaDB/ITNQtlpe1DUJ+EfCi
QygpeMth/NSAUFLT1Fdc2XXkYkdJbcfZs+csFvO14AOPgQwsxAAKc1qYDSDM
MSHpZk7EJ2aIMPPdzN44Bn/hfMz4ELlaBkCATxw7WnzyRE93l9ls9LrdNqNZ
JyezU+h1Bq1WJ5fKJWNitVrl9YCJnCRe60Qk6bNEdCMhWUtQ1BIcaQgKmwMg
wKMt3v6a5r3v6VrOB0XNoNNBIXzbAq7s4FBjoLtm9L0HBtb9D/+OLxBvNgRm
H14TPLVGeeTPu2r3qax2kcowSadqzjaaIZJMqjGcrOm2ubzQtw3x3kG/32Bx
NLb1VTX2nqtsPVbafLa6/cTps3qtFkdMXe3VgPsvxgAKc5YwG2PQzQzebCLM
CvcsALQZgMKM45jxMXL1DIC5/PFHO9pbmswmg8th08A0y1KpSqnQq7ValWZ8
XKXV6zwudyqRnIa0H/FgwmMJa8es3eWO7vIg9CWDKouaiDCDAI+0+EVtfYe2
j5ccC460B0WtASFocxs1mhsDQ436I1u67r/FtPnPgjBiKm002098sen4b7Qm
Y59cE44lWIv40cxgImss9mOVHdDNDNNBRvz+gM83JlPVtfSUN3SdrWw9XNJy
vKL98OEiuUwGAWJXTwgeARnIywAGf3HBX8HUkCE6zAlzHIU5T5c3RmXjQ+Qq
GYAU9sePHv1k147y8vLO1ha1Sul1u6wWs8NiBWMahg7D4KepVGIi4I6aFaHx
vpCkzT/U2Hd8h+jc7oCoESQ5NNoaFLUFxW3B0faguEN+8Wj/oZ1usJhFHcRo
JoINPu3mgLDF03q+58l/H//9XwQh+Au0mcZmB4vWtO36jkwp7pVpnIFgtjBD
HzNYzDaXp6i2s39sHAZGh/1+j8vZOyBsaO4tq+ssqmw9UtJ8tLR174ETkJAM
/N9XyQbujgws6MgurAmQriLBCAhzZIgJs4kJs2cWQBzaHrSYcbgUPkOuAQMQ
ZNXT0/PKa68WFRXt37njfPF5o1YDkVakk3dyIhkNRxymsHokOAb6SmSYdBuL
GhSl+1oPvu0BYRY1h8baQmMdaXRa2itadm+ytNcGJZ2wMgCaPdIWGAbZbvEP
Nsk/fKL70b/0f0KFmXqzIQRMvvMvOpvOj6i0JocbUomwCS1Y8i9Y+ILBC+29
DV3D0LcdDYf1Gm1bZ391S/fF6o6iyraDxU37zjXt+OTwAJljavIaMIKHQAby
MYAWMze7FERlG8FijgqpNmeEmWkzurJxHDM+QK6eAVBBs9n85ltvnTxy+PSp
U0cPHay8eLGnq9OgHo9YlMREBqsXHNHDVJJBm0dAmFscXRXte9+1d1aEZJ0Q
+RUSg63cHhoDJe70Dbe07N+qqioKKHpAmIOjHQH4VgTrm41N57q3Pdt07/90
vvFl4soGbaaZRlyffanh2EtjKs2o0hCKxlmubJKnJJGAJeT6bOgXnm/u9/oD
IZ9fOChsauuubug4X912/GLzvjNNH59q3vzh3q7ODpDzqycEj4AMoCt7sWkf
QZiJKzsqNAFiRJjHqcVMgH3MmGAEnx/XiAG4lPbv379nz+6SCxdOHj9eV1FW
U1Pd1VDrHgAlbgr210PoFlVl4pEmLmtxm1/Y0Ld/m67uREjdS4W5A5zYobEu
AnHnyLkDPcd2eYnF3B6SdAUVff6hJsnp3aU7Xmn4dHvdY/+pePyrZCgzjGlm
Pc2H1zR+8jOZWjsgU7v8IT5XNggzRGXDDBZdIsmpmm6n12/S6jvbu+uaOytq
209XtRwrbt51qv7jEw1vf3Cgra0dBlhdI0rwMMjAfAYw+ItOYhGcGKbCTLuZ
08IM2szgw6jsEEZl4+PjGjAAQtjU2LBp06ba8vJzRUU1FeUtDQ3tTY0mEdjB
jWSwk7AxBBFe0FssArOY9SW3iUv2dxz7IDQOZjExlAkkVJhlvebG0vpP33FC
5i/1kEvUOl56qHLHWxXHPlPL5Ymwr2fbbytuuyWw8/NB5tDeS3zaw9u/LRru
7ZZqrG4fxHCBHxtUGT7QBQ4ZRUYU48eqO9V643D/UFNHZ21D5/nq1hPlrQfO
NO46Xrf9aP0bW/Y0NTeDnX0N6MBDIAP5GUBhZrNLUWHmjGYmzN5ZAmo0L0WY
c1KL4DhmvOOQgfkMgDd7fHz8g21bG2qqy0pLq8vL21pA5prV/a3BsXZiNA9D
hBeghXYnEwTFncam4oZP3vIM1YXkvbSDGbS5i2izvCcg6+o98oGk5MBI+ZHW
Y3t76ioMGm0kGiVTOqZS48VHTn7vG653/pxo88fUbt67xrTjrwebTg3JNQaz
nVnMWcIclWr1Rypa2rv6+ru6G5q7y+taT1c0Hytp2VtU99GJunf31z7z8qam
5lZ0ZePlfT0ZQGFOCzPXx0y6mYkwK6kqo8XMx2djgpHreR+uomOHQsHDhw6W
FZfU1lXX1lW0NTe0tLSIO1tDEvBRtwbFLUEIvR5tpaoMRnNHcKzLJWzo2rdD
WPZZSN6XFuaekLw/pBp0D1SffuP5z95+dXSg3xcMsHguNjoZsnnZJV2n7/i7
0d/+D1DlwIefD+5aA6azbceftZ/eNKax6yxOmLKCdTATczkWi0fDOqPl4NmK
8qrq7s7umvq28zVNx8qaDpxt3Huu6b2DNQ8/+ftdH+8KeP04jnkVXbI3oako
zESYXaEJIYn8yupjVnpmASjMKMw34a4s6FOCrVlXW/vZp3u6OlobGupaW5tb
W1p7Opudoo6QpB3MZdq1TKKsecd1YKxdfOaTml3vBEGYJWS9R9hu6a6R1V4Y
aW1sb2srKS/1ef08bZwwT06GXcbmV+9tvuMr/g++4Nv6xcCHZMop1/Yvdn36
uMpkMzk88STk3eY+VJgjKq1m58GTJWWV7S0d5VWtZyqbD11o3lNU8/LW/S/8
8fXmppZoFKeWKugLdBk0DqOyWVR2RpiN0RFjlLOYwWhm8GMfM05isQxu18Ko
AvVmK955562uLhjM3Nja1NLS2tTZ0moRthFhJkYzifnihBmiuqQdQUmHoels
4/Y3nION3oFafUv1eEejerTPYTVDLLXb662sqlap1dn8EFc2RFxHw4qKg9X/
79c8m7/k3/4FIswffsG344t9H/x/UsWY0eGLxuIs7IvYy9FYyOvr7en54LOj
50oqGpraiqtaTlQ2f/DZmRde37z9gw9h+DL4vQvjV8BWLGcGUJgzwkzisaMj
FCjMmGBkOd+2K75ufr/31VdframpAKO5rbWtvb25uaVF3dfuJzIMTmywiakf
G/6UdQUl3dD9bGsvrd/5SveZQ5qBDqfNEouGWU5N4AKktbm5tb9/EJQ422gm
+a9TCff4cPFdtxhf+bJv2xdBmxmG3/hWT3en1h6EMGyY0ZloMvwLh9Xj8rqq
+g8/O3aupLq6uf3ouYpXNr3/4muv1dXWBwIQKUZOhx9k4HozgMLMC/MIicdm
wpzuY1Z5ZxnQYsZxzNf7VlxVx4fsHCeOH928afOpE8dLSorra2vBHT3S1+0j
bmrobKb9zaNtnsF6R3eVpaXc2FVvHO5tqrgIru9EDGZ+nJMOE/R3bExaXVUf
DMLYAe7DEm1C5pJUIlK18ceK3/4FCLN3y5d87xN5Hn/jL+svnFCZ3ZFILJWM
J0CYw2GdStXT0V5fU7tz/4lDx859tOuTrds/KKuo8Hg80A+Nncqr6hK9uY1F
YeaFWWSKgSqLCKgw86qMwszMZ0zJeXPv1UI6O4icSCR87ZVXyoqLd3/6yUcf
7Ty472BZRYkNknZJOhwdFaPlB/vOHx66eFbc1WTRKINeN0z0ZLFaii+WZZvF
jBM4GsxMdaGswmKx5HQzQwgYfNv97jOjG/4KJrTwvU+EGRTa+sZflO9+ZUyp
BUsZUo/BJNAalbIHTPe2ltMnTz/7h7c2vb25rr7RaDKg77qQLryV0xYM/qJ9
zOEJJskic2zUzITZN8vDn8DZpXAc88q5qVdCTcPh4KbN7zS3NIMYVlVVHz10
fMcHH/S2t8T8NuVwZ1NlmUI6CtNPgZeZt48hLdf588XgfJ7fvnA4XFVVIx2T
gxLzag0R2hBoBsIsLtrZcf/XiCS/T4xmgPvdL1dsvm9YOBhPTUAHs0ah6G5v
qbhYtvOjna+8+vap08U6jW7+G8BK4BXrWBgMoDBzwgx6zINZzDM8/PEZUG/4
wfN0vS6wCscxF8b9ga24TgzAlI779u+/UHy+p7u7q6OjtbW1urxqVCSCQcUx
mD8i4IWorpw+XTBeq6tq5HLl/CrBVx0dnb19A7yBC73BoOisH1rXfrH2l1/3
bPozIszvEaPZ886f1bz6bz2dTTDzslKpLL94cd9ne/fu3nP+/PkRodDn8/MC
f52aj4dFBhZlAIWZCLM7PAGqLE6DCrNnmgcR5mdeX4ow56QZWbqQL/8tcRwz
PkquLQOtrS37Pts/MNjf0dXR2d7R2dMpHhXBKOeFzgJC2z8wCOb1/O5elrek
qbkpGolme7PB6vUFAu3lRcV3fNP1+p+DK5tYzJu/BCI98OxfNxYfbmvv/mjH
jl0ffXT+zBnl+DhYzzif47X9lfFoV8QACjMnzGJLjAcVZveUMg1/fHrD068t
RZh5fUWL+YouR9xpFTFgNBp3fvThwMBAd1tHJxi87R39vf12u53pbt5gK4Ne
f/jw4Xg0Np8mh8NRX9/gtDvYvhMTKZfT2dfXV1xSUnGu6ML6H9h+/xVQZc+7
f8aEWfHqV/a++sjuzw5UVlZr1BqIyl5F1GNTlzcDGPzFgr/AYh6jwgxLQIKk
5HSmePhiUw/+5uVVLswY/LW87+WVV7tQMLT7k08aGhq7u7rAm93ZDgObu1Ua
1SLZLqORyMGDB0160/zWgrHb2tqmVqphd4ijHh4erqmpaWxslMkVPqux9rk7
ZY9+FfSYqDLVZsMrf1n50W+USgXM9ohW8sq7egq6xijMTJg9kYkxa4xBYqXC
LLfHeHgjE+t/9RIKc0HfC9i4G80ApMw8CzMzFxV1tbV1tHc0d7W3dbaPjohB
YhepSnFxMXRF59jTLA1nb09vZ2eXRCK5cOHCxx/vOXe2qKOjXTImDfp8TW8/
1HP/X4EwQ+8ykef3vmR7/St9B54N+Zw3utl4PmTgUgygMPPCDHrMgwiz1Bzi
4Q2n7n/8eRTmS11O+D0ycHkMdHd3b3r33Yb6+s52cGZ3dLR19PX1BnyLZaIW
Dgvr6+snJzLTIUOgVjKZMpus+/Z++uJzT7/98gvb3vnD8U+31BR9VnH8iUMf
/d+ioj3nX9tYc/v/IKr8LifM7re/PPDJOqfZcHk1xq2RgevPAAozE2ZvZFJq
i/NITM4IRvU+Hu5g/J5HnkFhvv4XJJ5hdTEA3cAvvvhiacmFrk7oYm6FoVNd
bZ0mkw4SgwAR4GGe39Mc8AXAaIZBUywhdjyeMBpNMNd6bU3dbzY+8psHf95c
vNMsvOCUVzp1R13j/6kTf2Xg4te2/O7br/30b8Ze/Irt7S8Tuxnk+d0/G97+
U71ibHUxjq1dGQxg8BcnzHJ7XAawERBhHtG4RBoXLEc0TlcgdudDT61yYcao
7JVxR6+0Wn7w/vtHDx9qa2vpaukGZzbMAqmQSFPJJC/M873WF0vLDEZzMBSC
5ah4bFQshkwg0Vhi/569f/zV2qELH5s7Tjr69zlafhDqWRMaWhOSf84l+fPT
h/9m17P/q+Lpr6le+XMneLO3fGn43R8qRT0rjTCs72pgAIWZCnN0Um5PUMQB
RJiFKodQZR9W2gBOf+QX659EYV4NNwS28QYzUN9Qu2fPbhjI3An9zFSYhweH
IMiLn70RzOJs0xmyYxadPlPX0CSTj4MwBwIBlkUEqt3Y3LbnnRdEpbvUjQct
ra/7Kr8YqloTalgT6l8Tkq7xyr8o7vqr8x9/ffuj/6vlN1/1bP2S5P1vKwaa
bnB78XTIwBIYQGEmwuyLTirsCQIHLONJEGYiyeNWBqcvcvvax1GYl3A94SbI
wOUxEE/Ed+7cefrUKZjJYrC/rxdmd+rsdjocvDCzAoxIdthswsFBmVxeUVoF
Xu9olCQFy7anTRbLnm1vth94e6zsFVPlP4Zq1gTKPx+4+PlQ9ZpQ15rg6Jqw
9L+FZf9FWvtXm575X5/e9z/bX/iuurfi8qqLWyMDN4IBFOa0MDsS46DKBFSY
hUpOlYfGLU5fOFuYc7KILPLn8k8bsvQaoiv7RtyPq/IcJ44d2bn9gwMHPjt0
4MDpEyeryio0KhWIbjKRgCTY47Kxvu6uns4OkXAI/oRZGvVGI8xGFZ6bmxMU
OhSJnj5x+sim51sOPtb04TckR7/iuvjFIMhzxeeDFWtAp4lne2RNTPZfXEOf
bzj833e8+P1Dn+6y2jxTU3NmxViVPwI2ehkxgMFfLPgLLGZQ5TSoMI+o7SNK
m3DcCnCBK3vdE6vcYsZxzMvoxi2sqgwM9B0+fLAFpo6qqqq8UH70yNHa6mrI
IuJ2Obva20eHh+02K0wABXNSMfvY4XQWl5baHA7eXoa1MFsFJMfuGxS++/vH
L2z5j4tbvl723tfadn517NhXApWfB3kGbQ5WrgnVrwl1rwmP/rew5L85Bz7f
dvZv9+54vKa2IRRdbIxWYfGNrVnuDKAwM2H2RyeVRJjjDESYxVqXWOMc1TgA
7kDsjgd/nRHm0e0/4MzkH2wfzW9zFl7mLxTm5X43r9j6GQz6zz7d01hb3Q49
za3t3S0wBeRghM7hyPuxoSOZTRUFljSEZJ89exaSZpPeZ4jNppicmUlNTVmt
1jffffdXD/7wxBv/s+q9W8rfu6X4rVvqtt1iOfvlAPQ3g08btBnQQoPCwLkt
/m/h4f9avvvv3n711739Qki1jdM7rtjrqHAqjsLMCXNsUulMKB1xBiLMUoMX
INF7AN5Q/K6Hn54jzBtLF3cCozAXzl2CLbnODASDwSMHDpZdLG1taWptbW5r
himnWu02G2gk6DFMawF6yT6gzdDZDJ+y8vK+/oGJiQmQ5imQZNhsYiKZmvD6
fGVllWeLyz776P3Nz3335Gu3VL1/S8WWWy6+f8vgZ1+zFn8JrGdOm0GkO9aE
BkGePxcWfU7X8OXjH/7w5NEP5ePqZDIzSPo6Nx0PjwzkYQCFmRdmlTPBgwjz
uCUIUFD4wsl7H3sOhRnvIWTgejAAcltWVnr00JHWxiYAzAXZ2tisko9PTk6A
EMfjMGUyaHMSAEoMHzCaYTaqxqamaDwO80fBGvginkoBICKsrrGhrraho6tr
2+bNb7z04LtP/t2FV2+p/QC0+WsN274mPPgVz8U/C1YTzzaJ2QbPdsfnQsLP
BUWfsw1+savs7498fP/pojNanf16tBSPiQwsjQEM/iKu7EBsUu1MAFQusiTC
rHbE1I6oyk4QiE6sffKFPK7sBT3ZocKzmDH4a2l3FG51JQyMCkUffrS1vra6
ubG5ubmxqbFheKA/FouC6zoRjycTAJgHEj6g0AkQbOGIEPJuwvyMYEaDYifg
38QEbAIdzyeOnfjoox2NDY0q+KgNFy5UvPn8uo9/+/dgOlduvaVy8y2NO76q
OvUX3qovBCAcDLQZlo0kLiw88jm/eI2q/783Hvr7j97fWF5R63LB/I8YF3Yl
Pyjuc3UMoDBzwqxxJQBqCiLMOndS505oKYLxyQd+/YeMMKe92NDXvJBLG4X5
6q5L3PuGMsD6bm/oKeeeLBwMfPDB9pILF0CSmxsamxoa21pb3W431ArCvmDq
p3gslgDTmSg0GMZJo9FQdKbIYrESczmZCvgDep1+aGi4u7fvzJmzZ8+ccbtc
4WAw4PN5nB6RSHbg050vr/1fe35/S9mmW2qIc/trnXv+SnHyLzzlXwzVUXkG
zzZ0PPetCYk/5xF/XtZ+S/mR/33ksz+2tvYEAlGU55t4bazKU6MwM2Ge0riT
GheAyHMKhNngnTB4UwyheP7ZpUo3ClCYV+VtU2iNZuktWaTVTWkbnPfUyZPH
DhxqaKitq6ttrG9oamjQabXQnQx6HI2EY+CkjkRgfotENJqIxYKBQPG5Cxqt
FsR7VDTW09Uz3C/Uag2QDkwkElVUlsP8jx6702a1WPSQhsSsU40fWft3O35+
y7aN3zz18i11W0mvc9V7X+va81Xr2T8L1abjwqDQ/rnQwOcCY58PSf6ruvnL
RZ/+264PtvQNiKempm8KM3jSVckACjMV5viU1p1Mgwqz0TdB4AWkQompB3/7
SsZiBkFmn4VDwNBiXpW30wpuNEvWkTc99Y1pVX9f357dn1RXVsJYqcY6+NSM
jY7CqOVUIhEJh6LhcAwA8hwln4Dff6qoqKmpaUwyJpHI1Dqdy+OCkc3g7JZK
pRdLS616k91sMev1ep1mXKVWymTlD/x11X3f+PCZX3707sbDb/2g/L2vQ1BY
5ZZbWj7+K9nJ/+G4+MVA9ec50xk8250w4vlzYcnnTF2fbzz0z2f3PV5TUWa2
2iayJs+4MbTgWVYhAxj8RYK/nnk9yAkz57pOTc0ITL4JAKgyEeYFLOb5gdk5
yUaWnr5j+W+Jw6UK+wEBkgxGM8t/eVNa6nG7P/lk14XTZ2traqqr4FMNCTp9
Xu/U5AQIcyQUBjGGjGBgRkslknHF+LHjJ+obGuxOhz8QAEM5FAr6/f5AMMim
fVQrVCadQaNWq5TjsHFXc9OODf9+fssL4v42jUpTefH0vs0bDv7xu6Xvfr3y
/Vtqtn2t8+O/kp/4766LX4C4sIw890LA9n8LjK7Rtfz3+hPfPbX/RYhMs9qc
wNISKbpZHoglVg83W54MoDDD/bzhmdegE5n2KZNuZQATZpDkpMGTAIAwP/DU
H+f3MS+ipoVnMaMwL897+FrViqW9JOORqDgzt/aN9GtDGNfJYyc+/OhDkNXS
kpKKsvLaikqjTgfua7lMBvY0jHKGz1D/AEhtMBDsgDFVLW0wPsrj9bo9IOvQ
rex0utxjYyDMJWNiiVqlVijko6OiC8UlH+/+uLKyxu2BYC6iqROTUyqV/nzx
yQ9fu+/EW38LpnP55lvKP/haz56vas79eQBitiEhSSVZch3PI2tCY2tUDX9x
7tN/PfbxizALVjAQ5r0L86livofsd52b6Iq4VlcIHueGMYDCDNr60NOvUmEm
kpwRZqM3YXDH9e6YzhWDr9c++WK2MHPO7NUUlY3CfMNuy5tyItASGA0MnwkA
k2gmJjdKoOGEdTU1r/3x5d27Pv70408OfHag6Pjx/p4eh91eVlLSVFcnGho2
anVuu8PrdodDod7e3pqqGpvVZnc4bHa7xWaFvmSYlVk0Kj53rmR4WDg8MlJW
Vvbxxx+fOnECArQhQ0kOsdBbPTo6dnTP+7te/z9F736zfNMt5Vtvqfngq8P7
v2I6T4dUgTZDvjCQ5zYy4jk8+jlP/5ru8/984NNNZ06fHVcqWUKSvMIMzQEy
GZE583DclN8XT7qCGEBhBmF+4KmXA7EJnTOmdcW0sHTGSB8zkWRnVOsIAwKx
1H0bfzenj5n2LkNU9kLSjBbzCroNsKrAAKgLjAamaTroeGFIgAmiQrU5z6zI
14EyqMCIcGTTe5sO7dt/5OjRT3fv3r512/Ejx3wej06tNhh0ZqPBYjFZLVaL
2exyuob6B0tKLmi1epPRpIevDeDk1ur0RtGI+GRR0cWLZfsOHDp0+NDIyEg4
TKzbvFWGtw9wf9fV1+7e/Nwnr323ZNPX696/pWz7LfU7vio//pfu8i8QbQaF
piOew72fs3d8eaDuCZVMWH7q+O43Xh0eGpjv1mbmMkgyCvN1uExWySEx+Cu0
7skXA9GUxhHhkZqcFuicEZBkjS2otgUCkeTdjzzDC3NmlNTC46UKT5hxHHNh
PxKIME9OwlAkMlI4rc1g7hFA9/MN6Xh2uVyffrpn63tbIeNm6dlzRUVF8M9s
Ih+VQqFWqnRqjV6j1Wm0JqNhYHDwTNEZuVShVKuh21ilBsf1+LBw5MKFix98
8OGn+w9193TE4kvKgA0B6ZB398z5kg83PXzs9X+o2Pr18m23lG66pW3HLdrT
f+Gt/Dyk84SZMHxVXxBd+OlAR4lKrpTu397z/F17330zEo1mXxgsvp3PUMab
yzer576wL9rCbR0KcwiMYX8kqSYSHGJIEmF2hDT2oNrqV1t9gUjizoee4oW5
dGPaTkZhLtw7Y7W1DBQFrORoMhVnAHlmdjO4ZKk2M7v5uvY6g2e4rbnljy/8
4ZOdH588fhJShRQdLxIODxt1esnoGMR8KWSycYUClspx5WDfwKlTRWKxGPRY
KBxpaWqBOO0jh4+UlJYJhUKIA7vcXzCRmpDJNSeOfPbJu/cff+ufarbdUgUJ
Sbbd0rf7L1Wn/txbvUZ/4WuN598bHhL2nTs5/ubDyj/cd/DlZyAkLftEfL8y
k2TmxMYO5sv9LVb99ijMIUiD7Q/HlWaf0uJXAaz+5AQVZq0tAKqsthBh/uUD
v8qymDdyc1egMK/6G6iQCJicmo4kU7G0MBPPNu1yhskhSGfp9ZcXkH7I81Vd
U/X873//3nvvnTh67OSx49DxrFIooctYNDAsGhoZGxkbHRmVj8kH+/uLjhXV
NdSdOnp6145dH3+8u6GhAaK/oKZXHLVGOtonJsdk6t27Pv3whX+/8PZfV+4k
qbbLt35NuOdrdQd+UltVXFd7sfedpw2v3jfw4n2Hd74PsWk5wpwT88X31BfS
pYJtuc4MoDCHQHN9ofi40T1u8oybvEqzNzkxRYXZHtBYfYBAJP6L9U+u8j5m
dGVf51vx5h8eLONwMhlNpKLJJBjNRKGpT5tMEcHyVjP774p1b2lNBEO9va39
xedfevWVVw5+duhiSalYNDrQPyAcHB4RCkUjouGhYcgocv7M2bfefGvLlveP
Hj3W2dnt9rqXdvglbeXzx6rqWt57+eGDb/yvakhFsvWWc5u+eXTXH0vOniz9
ZJv0lQf0r9139ncPtTU3wXtAzhGZicx/lnQ+3AgZyGIAg78ghOvnax/3BmMK
g0thdFF5dhNh1jtDOntQa/NTYU7MnY85Pe8jRmXj7VRADBBhTqQATJtBmGO0
v5lza7No7RvimYVXAKfdVXzu/PO/f3HL5vcG+kCVR1pbWk8dL9q2fft7m7fs
33+wuLi4q6Pb4XBAsuzr8aoADbVanRfPn3/r6Z8feOVvSj5+5OjBnad2bep9
/Snj6/e2PX3HmT0f+fz++afmB0qxQgFdINiUG8QACjMI88/ue8wbjMr1DoXB
CQBtJsJsdEWINjuCYDcTYc62mPONX85JLVJ4wV84XOoG3ZQ37zRgEIfikE4n
EY4nI4kksZsTST4cDLqcifWcHgDERWtfz8FUoGomg2XLli1PPfXUs88++9KL
L+3fd2B4aMTv9IFz/cbwBO1zON0H9u1/+/nfHv30g4EPXzW9/oDklbuKXnly
RDQy333AB3/hKKkb8wMV5FlQmEFjb7vvUV8wSiUZ4Bo3uYgwm70xkydqdEeM
rnAolvrlg7/OuLKXkKYLhbkgb5jCbhRYw6F4EhCOg92cjFB5hjkXmWebn3mR
DHfmB1PxBvR1G/EcjyUsRrPb6UnEknDe62EcX/JnhdmewYu+f/euoheeKP/d
vadefaa7uWmCePczg73ZQXgPNo5dviSruMFCDKAwE1f2/Rv94ZjK5FaZAR61
2UOE2epLWLwxsydqckfgOXXXht9kCzMmGMGbqvAYAJEBizkYTQRjSRBmUOgI
5KkG0xnkGUB92myUM+lyhomQmTxnfa5/B/RNYx1eCGAaSoNGIx+T2G02eDnh
U4tkJxhhZexjvmm/U4GcGIO/QreveyIQjqstXg3ASpACYbb5k1Z/wuqLgzyH
4xP3PPpsRpjTs0qtqgQjGPxVILf8ws0A73QwlvJHk8EY0WYiz1ShwXQm2kzs
Zs50ZmOdIRsJxGyDNsOSDHemIp2Rq+s8turG/xzUTU0yhyzRascO5hv/GxXK
GVGYQ3c89BR0IkOYl47BHiAJRhzBCXswZQ8kbQGwGybvf/z3vDBjgpFCufqx
HXMYAL0BYfZFEoFoMkDt5iBxa1PTGaZbZKYzjQjLWM/MgKZgIp2dgpJl9GTn
uK4DoG/MD5ltGd+YM+JZVisDKMyhex59BjqRDc5QGuEJEGZneMoZmnSGJhyh
iWhyat2vXuKFGROMrNa7pcDbDdpJhDmcgIQ7QaLNZAnyHCJIgPXM3No0Zpu4
tZlnm8sUBgY0FWliQFNAjzUDS0tyA/KTFPjPg81bRQygMIfuf/x58FVDbzKP
CZhdyhWZdkWmCMJTsdQ0JNTOspgxwcgqukVWVVPhFdUXSfrCSW8kCT5tfxSs
ZzCdYYI1ABFmBggHo+OpuCUzoHmFJqm205NhsKxh0HsN/l9wc3PyfD1juVfV
74WNLUgGMPgLgr/W/+ol8FVDbzLEe7ElEWZ3dJpHPDUDU1Ct8j5mHC5VkI+A
nEYFoylPKAHwhpOg0H7i1k4EYvFgNA5GM5VnMpiKdDxTeYagMKbQgATrhKa5
PEGbGUjWMKrNPDh5pi7u653jczX8ZNjGwmMAhRmE+cHfvAy+auhN5jE5PSPw
xGYIogTxiRmYtDkjzGRaKToeChOMFN49sYpbBHZsKJpyB4kwe8BoDieIWztM
tTkapxFhCTCp00OqQJtT1LlNu59ZQpJ0Os/slGFMmydnZmB0EQAKzHrmPquY
cGw6MpCXARRmEOYNT78WS0GH8gQD9ClPTs8KvLEZHiDMDz/7epYwLziQOSfN
yBIGPK+YTdBiLviHCCglTKTmDsbdoTg1mgFxEGZ/JE592mA3ky5niAij2pxK
m87puDAaGhalbm0uZdjEBLGeIaPn9DQAOp5BpJk2AzKe7YJnFhuIDFwOAyjM
RJifeR06kV3hSQYnif0CYY7nCPMbSxFmXmYxwcjlXIe47bJgAIb3+EJJFwgz
0WYwmgl84bg3EiemczRO+ptZUFick2fwaXPyzMK2mVs7xckzCRADbZ6cTIIk
T0/Dkog0/Ekzb/OmM2StLICY7WXxE2IlCoQBDP4KgTEcT02708IM2kyE2Ref
4ZGYnHnkudUuzDiOuUBu+YWbAQ5nMJSdgbgLwLQZ7OYQ0WaY5gWmYPOBQkcT
/hgZTBWAZdp6JtpMwYeGgekcYaOqJibik5OgzQRTU2BAkzXMjAYXNzWdwbPN
JfgseIqxgcjAkhhAYQZhfoMIc2TKHZlkmEJhnu9hR2Fe0g21PDYiw5MuvyYT
U9PuABVmP9FmEGbi0waHdihOwAszaDMd6EzlOUU92yRmO2M9Q2hYMgnCDG5t
MuiZajMDPwaaWdLMsw3CnInZXmLyjstv3UJ7oLF+7bjEI10rBlCYs4UZtJkA
hTlPzzcK87W6527AcUDwwJwFY/SyVAdS0dr9USdBzBkAkM5mVyjiDsW8oagb
fNoUxG6OgDYz0zkZSLu1adh2MgTObQAIMwG1mycmAFG6ZGY0N7wq7eXmep2z
5Pl6zyzJ/wQYFn4DrkY8xeUzgMLMCbMnOuWJcCDC7E+7sqGArmwQahTmy7+7
btoeMDbJ5AlZ/WGYw3E6O//WojVKpCbt3rDDG3H4og5Om2PuQMwdjLiCUQ8A
FDoMyJLnSIJmCmPDnWkWT2pAE20mM0hy8gymMwNVawJIUUICxNI+ba7LOWu4
M9T6xtB3g05zYxqDZykIBjD4CxSHuLInpokwM22OUosZ9JgHCjPQhFHZK+uW
j6YmlHavxuF3BKIhMjT/Er5tcCFDSi+rJ2z1hGzeCMDhj4IB7QhEnP6IMxBx
AYJRsJ494RhVaGpAM+uZyDMJDQOAJQ3TYLAhVSwnCSg0MZ0p+EmriDDD2Kp0
DzSY+CRse+54qiW/UaysXwZriwxcggEUZl6YvUyYKaZmUJjnObPhWsmeRwjL
y5wByImpdfkVNp/c6lE5vPZgJAXDDRb+wPZ2l09vdujMDljqLU69zWWwOo1W
h9HmNDHYnSaHy2x3W5wui8NjcUCBwOp025weWFpdbrvLY3N72NLh9jo8XqfH
54SlF0AKsMbh8bi8XpfP5/b5YOmh8Pr9DL5AgCAY9AeDgSD5rJgxhVhRZOBa
MIDCnC3MoM0MRJgDiVkeyclZjMqGa0WEH2QAGUAGkIHrzAAKMxPmxMSMLzbN
40qEOSe1SEGOY77OVyMeHhlABpABZEAEAT3XwvBeLseA6W0OHDgQj8djsVg4
HAkEgj6f3+32qjU6hUIlkchFIsnAgLCzs1csluzbv8/j8cwXZm8MMvviOOZ5
vylcK3jHIAPIADKADFxvBlCY5wd/ccOlXNFZHrEJdGWTqOzrfTni8ZEBZAAZ
QAZQmJkwR1PTjtCUPQ2S+UvsmBE7Zxk8MRRmFGZ8XCADyAAycCMYQGFmwgxz
Lg9bUsNmClMyNjEjaNVPtxlmAO2GGUsIU3KiMN+IGxLPgQwgA8gABn8xYTb6
JxuUiXplvGE8Xq+IhZIzghbdDKBVT2AOojCTccx4wyADyAAygAxcbwZQmDlh
9k3WjyfqxuN1initIh5KcMI8TbRZh8JMIsFQmK/33YjHRwaQAWQAGEBhni/M
oM3UYtZOE/DC/Oxqn10KhRkfGcgAMoAM3AAGUJjTwjxVD67stNFMhLlZO9Ws
mWom8jxlDsyAvxuyqC19XBiOY74Bly+eAhlABpCBwmMAg794YW5QJkGYmTYT
YW5STzZpJhvVE42qCVNgasMzry1FmHPSjCxdyJf/ljhcqvDuf2wRMoAMLEMG
UJjTwV9TvDCDNhNhJn+ntdrom3zo6VeXIsy8vhaexYzCvAxvYKwSMoAMFB4D
KMxzhJkEZhOjmQhzjTxaK4vWSCM10rDem3rwqZdRmAvvBsAWIQPIADKw3BhA
Yc4WZmokp4W5UhyoHPVVAERerSu+7lcvoTAvt8sX64MMIAPIQOExgMFfGWFW
JecIc+mwq3TIWTpoLxmwqe2R+x///SoXZozKLrz7H1uEDCADy5ABFOYsYU41
qGi3spK6ss/1mc/1ms51G8506ZSWwD2PPoPCvAyvYKwSMoAMIAMFxgAKMy/M
jSoQZk6biTAXdWqL2tUnW5UnmhVyk/euDb9BYS6wqx+bgwwgA8jAMmQAhTlb
mKk2E4c2EeYTrcrjTYpjjZKjdWKpwXXHA79CYV6GVzBWCRlABpCBAmMAg78y
wqxOzRHmY03yIw3SI/XiwzUiid71yweeXOXCjMOlCuzmx+YgA8jA8mQAhZkJ
s8k/1cgJMzGaw2AxH22SHamXHKkfPVy7JGHOSS2C45iX5xWPtUIGkAFkYJkz
gMLMCXOAE2YwmgFEmI81K442yo40gDaDK9t9x4O/Rot5mV/NWD1kABlABgqA
ARTmLGGeYEYzJ8wn2tQnWkjk1/EmOQZ/AU3oyi6AGx6bgAwgA8ufAQz+4oW5
ST0BYNpMLObTXcbTnbrTHdrTHZpxS+DeR59d5RYzjmNe/vcz1hAZQAYKgAEU
5owwa5gwE20OJ2cFxQO2833W832W831mFUkw8jwKcwFc8dgEZAAZQAaWOQMo
zGlhnm4CYU5rMxHmUqHnotB9cdgNS0jJuX7Vp+REi3mZ38xYPWQAGSgMBlCY
s4SZTPMI2gxGMxHmCnGwUhysgIzZ4qDOk3zwN6t9EgsU5sK457EVyAAysMwZ
wOAvXpibNZOAjDBXSSPVMphaKloti+q9Extw2sc/CZb51YzVQwaQAWSgABhA
Yc4Is5YTZuhpJhZzjSxeK4/XKuJ1ioTRN7XhmddXeR8zRmUXwA2PTUAGkIHl
zwAKcx5h1jBhVsRrxxN140mA0T8FWUhQmJf/BY01RAaQAWRgpTOAwpwjzMyb
TYS5VpGoUxBVrh9PgTA/sjRhzsn/BUcvmA9azCv9bsf6IwPIwIpgAIO/mDCb
A9PN4MpOe7M5Ya6l5nKdkljMjzy32i1mDP5aEbc0VhIZQAZWOgMozLwwt2in
mgHEYp4Mp6jFjMKcbe6jMK/0ux3rjwwgAyuCARTmjDDrqDBTo5kIM+ljJtpM
upnRYgaaUJhXxC2NlUQGkIGVzgAKcx5h1qaFuSYtzAZ0ZaMwr/R7HeuPDCAD
K4QBDP7KFmbwZlOH9nxh9mEfM05isULuaawmMoAMrHAGUJjTwjzTopsi4IW5
Wh7nvdkG3yQGf2FU9gq/2bH6yAAysDIYQGFeRJhjNWltRmHGaR9Xxg2NtUQG
kIGVzwAKcz5hniLBX9VyFOY5Y7DRYl759zu2ABlABlYAAxj8xQlzcKZVN817
s6kwy2LMmw0hYEuxmHNSi7A/Cya7CEZlr4C7GauIDCADBcFAgWlHKpU6cOBA
PB6PxWLhcCQQCPp8frfbq9boFAqVRCIXiSQDA8LOzl6xWLJv/z6PxzNXmDlt
JsJcBcKc1mY99jFjVHZB3PDYCGQAGVj+DKAwX1KYid2MwowW8/K/mbGGyAAy
UBgMoDBnhFk/Tb3ZxGhOu7I5ozmm92JUNiYYKYxbHluBDCADy50BDP6aI8yc
NlNhrpLGGMChTYR5aZNY8J3KhdfHjMFfy/1uxvohA8hAQTCAwrygMFdKopWS
CKBKGtV5J3DaRxTmgrjlsRHIADKw3BlAYU4LM3Figyu7VUsKxGKuEIfLxeEK
cahiLKz1pB5+5nWcj3m5X85YP2QAGUAGVj4DKMxEmJ953RSYJvk4afIvkGci
zBdFfgofLLWuxIanX0NhXvkXPLYAGUAGkIHlzgAGf4Ewb3jmNVNgqkkzAfNK
MXmOgDAXD7p4qJ3xB3/z8ioXZpxdarnfzVg/ZAAZKAgGUJhBmB96+lWY17FR
lWpSc9pMLObT3WZAUbcJluO28Ppfv7QUYc5JM4IJRgriNsFGIAPIADJw4xhA
YQbpfPC3rxh9Ew3jiQZlspFqMxHmYy3qoy2qo83Ko80quTlw/+PPL0WYCzgq
Gy3mG3df4pmQAWRgFTOAwgxK+sBTf9R7U7WyaL0i3gB2s2aCCPP+2rH9NeL9
1aP7qkclevc9jz6DwryK7xRsOjKADCADN4gBDP4CYV7/6z/oPMlqSbhOHmsY
T4JDmwjzp+VDe8oGd1/sB4xqHHdueGqVCzMOl7pBNyWeBhlABlY3AyjMIMxr
n3xJ605USYK1skj9eAK82USYdxV37zzf9dG5jg/Pto8oLb9c/yQK8+q+WbD1
yAAygAzcCAZQmKkwv6B1xSvHAjXSMPNmE2H+8GzHjtOt24uat51sGlYYf772
MRTmG3FJ4jmQAWQAGVjdDKAwgzDf/wQVZjER5jpFjAhzclaw40z7B0Ut2042
bj1ePyQ3/Oy+R1GYV/fNgq1HBpABZOBGMIDBX1SYn9e44hUgzKybWZkkwvzh
uc4dp9u2n2raeqJ+SGb42b2PrHJhxqjsG3FH4jmQAWRg1TOAwkyE+fFsYY7C
uCkizLsu9H50vnPHGaLNQ3IjWswozKv+cYEEIAPIwI1gAIWZE2ZnrFLsr5KE
SPyXIh5Ozgj2lA9+Utr/8YUeiP8SjptvX7uRt5hzsogs8icmGLkRVzGeAxlA
BpCBAmIAhZkX5gqRr4rGf9XJoyEQ5gO1Y/uqR/ZWwKCp/lG17ZcPrPaobLSY
C+jGx6YgA8jA8mUAg79IVDa4sp2xilFvFYv/klFhPtqiPNKkONQgPVgrluhd
d234TaaPuXQjtZI3li5sEeN8zMv3qseaIQPIADKwjBlAYQZpXQfBXyDMIl/1
WDBjMRd1GU916k+2a4+3quUm/72PPZcT/FW6EYV5GV/aWDVkABlABlYmAyjM
JPPXky9qnbEqsb8GcoxII3UKajGf77ef67ed67Oe7bXAJBYw2BmFeWVe5Fhr
ZAAZQAZWEgMozCRX9q9e0rni1ekOZi74q0ToLRn2XBh2XxhyqRwxSKiNwryS
Lm2sKzKADCADK5MBDP4is0tBrmxXnJjLskiDIt7IxjGXi4Nlo4BAmSigcSUe
+u0rq1yYMfhrZd7jWGtkABlYYQygMJP5mJ96We9O1EI+TpJdJAETMxNhrpRE
ABWAsbDWk9rwzGsozCvs6sbqIgPIADKwAhlAYQZh3vDbV/SeJJn2cTwOab+4
2aWqZLEqKQedd+LhZ1+fF5W9WGh24UVlo8W8Am9wrDIygAysPAZQmEGYH376
Nb2Hzsc8Dn7sFCfM1bI4D7138uFn31hKSs6cZCOYYGTl3RNYY2QAGUAGbioD
GPxFhPkZKszyucJcI49XpwHC/MhzSxJmXokLz2LG+Zhv6q2KJ0cGkIHVwgAK
MxXm10GYa2TROkUCXNmNajrtY40isYgwcylGfrB9dAGjGIV5tdxD2E5kABlA
Bq4pAyjMRJiffUPnSVVLQZjj9coEN+1jrjBnu7JBlmlykdHtP1hImlGYr+mF
igdDBpABZGC1MIDCnCXMkVp5rI7Gf5GobBDmGgXnzSau7CxhBj3mkn5lSrmG
MwrzarmHsJ3IADKADFxTBjD4iwmz1p2skoTBm12riNWTaR9nmDAnWE9zjjCX
bkzbyatJmDEq+5reengwZAAZQAbyM4DCzAtz5VioWhqpkROHdpYwU7t5nsW8
ketbRmHGOwsZQAaQAWTgmjKAwswLc8VYsEoargajWR4jubI5i5nazTnCHFqV
fcxoMV/TWw8PhgwgA8gAWswqiUQuEkkGBoSdnb1isWTf/n0ej4cTZleyQhys
lHBGcz5hnjNcCixl2om8mqKyUZjxKYIMIAPIwA1gAIO/0sKcKBcHiNEsIUbz
PGH2XXocc05qEQz+ugGXL54CGUAGkIHCYwCFOSPMowHeaA4lclzZSxDmnLBs
FObCu1uwRcgAMoAM3AAGUJiZMMP0UWWjft5oDiWm5/YxzxNmTDByA65OPAUy
gAwgA6uQARTmjDCL/OXMaB4LBfMIMyYY+ZNgFd4h2GRkABlABm4wAxiVzQvz
RZGPN5ovIcyrM8EIBn/d4JsTT4cMIAOrkwEU5jnCLPKXjQbAoX0JYcYEI6vz
bsFWIwPIADJwAxhAYc4WZmI0U20Oxuf3Mc9JyYkJRm7AxYmnQAaQAWRgNTKA
wpwR5hHfRQDVZibMcT7HiB6Cv1Z9HzO6slfjEwLbjAwgAzecAQz+SgtzvDRX
mOVzhXnVJxjB+Zhv+O2JJ0QGkIHVyAAKc5Ywe7Ms5ikBzF0BM1gwo5lYzHOE
eYFJmEOhnDQjC263Ar9AYV6NTwhsMzKADNxwBlCYs4W5dITT5mB8SsDmlWIO
7aULMy+4mGDkhl/MeEJkABlABgqBARTmHGFm2kyFWZFYRJgxwUghXP7YBmQA
GUAGlh8DGPy1mDBTc5kAg7+AJgz+Wn73L9YIGUAGCpABFGY+Khts5TR8AWYx
U5Ce5hxhxgQjBXgrYJOQAWQAGVgeDKAwZw+X4rX5EsKMCUaWx9WLtUAGkAFk
oAAZQGG+pDAn8lnMmGCkAG8GbBIygAwgA8uBAQz+WoIwQ1S2d+5wKQj92lgK
e4JP+wfbR/MOfcKo7OVwfWMdkAFkABlYcQygMOdk/oI0I+DQznZl03HMOcJM
FJkq70KynB7QvAKHKy9YZRzHvOJub6wwMoAMrEQGUJivTJjzqFdOahG0mFfi
/YB1RgaQAWTgpjOAwpybKzu/xbzkzF+YYOSmX9NYAWQAGUAGVjQDGPw1X5gh
wcg8VzYKM45jXtE3OlYeGUAGVg4DKMwozEvtB8cEIyvnvsaaIgPIwApmAIUZ
hRmFeQXfwFh1ZAAZKDwGUJgzwiyi8zFToCs7f3Rb4d0A2CJkABlABpYbAxj8
xYRZ60qUifwX09pMhLmWS8l5edM+YvDXcrvEsT7IADKADKwsBlCYFxTmGjnk
/IIJpghgHDOo95/+9Kelun1xHPPKug+wtsgAMoAMLBsGUJgXFOZqaQxQRaHz
Tjz8zOsozMvmusWKIAPIADJQsAygMGcLM+/NJq7syrEwD60nteHp15YizDlp
RpZuYS//LTHzV8E+BrBhyAAysJwYwOCvecLs54K/+EgwKGhc8Qd/8/JShLmA
+5hxuNRyunOxLsgAMlCwDKAwLyjM5wcc5/sZ7Cp7dP2vX0JhLtj7ABuGDCAD
yMCyYQCFOS3MybJRP7iymTebuLJPdehPAtoBOoUleP/jz6MwL5vrFiuCDCAD
yEDBMoDCzAtz+WiACTOACPORetnhetmhOunBWonU4Ln7kadRmAv2PsCGIQPI
ADKwbBjA4K+8whwEYf6sUri3fHhP2dDui4OjGscvH/z1KhdmDP5aNrctVgQZ
QAYKmQEU5jnCnPZmE2H+pKRvV3H3R+c6PzzTIVRafr72cRTmQr4VsG3IADKA
DCwPBlCYOWF2J8GVTbzZVJuJMO881/Xhmfbtp1q2nWwakht/dt+jKMzL46LF
WiADyAAyUMgMoDAvKMy7znftON22/WTz1uONIMy33YvCLCjkWwHbhgwgA8jA
8mAAg78WFObd4Mo+3/0haPOplmGF6Wf3Pba4xZyTWoT9ufzThiy9hjiOeXnc
s1gLZAAZKHAGCkw7UqnUgQMH4vF4LBYLhyOBQNDn87vdXrVGp1CoJBK5SCQZ
GBB2dvaKxZJ9+/d5PJ6MMIuJK5t5s7ngr0/LBj++0LvzfPeIynr7uidWuSsb
hbnAHwbYPGQAGVgeDKAwZwlzkAkzgAgzjJU6WDu2r0q0t0Io1jrveOgpFObl
cdFiLZABZAAZKGQGUJgXFGbIK3K8VXOsWXmkUSE1eu959BkU5kK+FbBtyAAy
gAwsDwYw+GuOMKe92cRihkycZ3utZ3rMp7tNCmto7ROrPfMXjmNeHvcs1gIZ
QAYKnAEUZl6YK8RBQDnV5mB8WnBxxFsq9JQMuy8MulSO2Ppf/2GVW8wozAX+
MMDmIQPIwPJgAIU5I8xjTJiJNhNhrhSHiFaPkp5nrSv54G9fQWFeHhct1gIZ
QAaQgUJmAIU5LcypCirMDESYq2WxammUQeeZWOJ8zAU87SNazIX8JMC2IQPI
wLJhAIO/FhTmWnmCIl4jj+u9kw8/+/oqt5hxuNSyuW2xIsgAMlDIDKAwM2HW
ucFiDvFGM7GY6xRJhlpFUu+bgo2WIsw5aUaWnr5j+W+JwlzITwJsGzKADCwb
BlCY5wozp81UmMeTPAy+qUeeW5IwF7ArG4V52dy2WBFkABkoZAZQmFGYl2qr
ozAX8pMA24YMIAPLhgEM/uKE2ZOqHAsBmDcbLeY8ao3BX8vmtsWKIAPIQCEz
gMKcEWZJWpjHUJjzWdEozIX8JMC2IQPIwLJhAIU5R5ip0RxCixkt5mVzj2JF
kAFkYJUxgMI8R5g5oxmFGS3mVfYgwOYiA8jA8mEAg794Ya6ShCsJqMWcwKjs
edqMwV/L577FmiADyEABM4DCnBFmaZhqM+lpRmHOYzKjMBfwgwCbhgwgA8uH
ARRmJsx6T6qKF2YJCnM+VzYK8/K5b7EmyAAyUMAMoDDnCDMzmq/EYs7J+cX+
XOoY4ZWwHQpzAT8IsGnIADKwfBjA4K85wpw2mqkwKzHz15z3BRwutXzuW6wJ
MoAMFDADKMy8MFdLI8SbTbWZCHM9CvNcOx6FuYAfBNg0ZAAZWD4MoDBzwuxN
VctAmDltZsKcIkYzlWfMlQ00oTAvn/sWa4IMIAMFzAAKc1qYJ0CYwWhmdjMV
5vEUp81MmJc2u1QBT2KBwlzADwJsGjKADCwfBgosPimVSh04cCAej8disXA4
EggEfT6/2+1Va3QKhUoikYtEkoEBYWdnr1gs2bd/n8fjmSPMVJs5Ya4DYR5P
kQmmFCDMMB8zzi4lWD4XLtYEGUAGkIFCZQCFmRfmGlmUGc2cMNcqEoA6sozr
vZMPP/P6UuZjLmCLGaOyC/UpgO1CBpCBZcUACjPfxwzCzPUxs+CvalmsBiCP
w1LnTW14+jUU5mV17WJlkAFkABkoSAZQmIkwP/M6KC+XYIRM/khnlyI5wCQQ
pR2pGgtr3ckHf/MyCnNB3gPYKGQAGUAGlhUDGPwFwgzGsM6drBAHCEYDZSJ/
MD4lKBvxlYl85aN+WGqc8fW//sNShDknzchKSByy1Dpi8NeyunWxMsgAMlCo
DKAwgyw99NtXtK542Yi3TOgpHfaUDrkCsUlB8YCzZMhVOuS+MOhQ2SNrn3h+
KcJcwH3MKMyF+hTAdiEDyMCyYgCFGZT0gaf+qHZELww4ivtt53stZ3vM/uiE
4EyP+Wyv+Rz83W0atwTvfew5FOZlde1iZZABZAAZKEgGUJhBmNc++YLSFjrd
ZSzq0J1s055oVfvCScGJNs3Jdu2pDu3JNrXM6L1rw29RmAvyHsBGIQPIADKw
rBjA4C8QZjCG5SbfsUb5kQbZ4XrJodoxTyguONo4frRJcaxpHNZK9O47Hvz1
KhdmHC61rG5drAwygAwUKgMozCDMdz38W4netb9qZF/l8GflQ3vLBtyBqOBQ
vexwnfRInfRQrXhM6/zF+idRmAv1NsB2IQPIADKwfBhAYQZh/uUDvxZr7LtL
+3aX9Hxc3L3rfKfLHxEcrCO286Ea8YGqEfj69rWPozAvnwsXa4IMIAPIQKEy
gMIMwvyLdU+IVFbQ451n2wEfnWkjwnyI2MpEmPdXCFGYgSZ0ZRfqUwDbhQwg
A8uKAQz+AsX5+drHR5QW0OOPqCp/eKadCPORBvnheunhOsnBKpEYXdk4u9Sy
unGxMsgAMlC4DKAwgzCDl5oI89n2Xec6wW7+uLjL5Y8KjreojjWPk5CwOgl0
QWcHf+VkEVnkz6Um71gJ2+E45sJ9DmDLkAFkYBkxgMJMXNnrnxSpbJ9c6IFu
5j0X+z+F4K9gTFDUoS9qJ2OljjcrcbgUzse8jO5arAoygAwUNAP///bO7DmO
407Q+C/2YSNmdx4c4Y1YR1i7YT54/LjjGfmSJeuyKEqQZFGjw/aMZ2RZ8pMn
ZEGWqHNE0pRIiSIJXuB94eIB8QJJnI37BggeuO+rSQDG/uro6urqqkZ1o9Go
rvo6MkigUd2V+XVmfv3LysxCzGKcnz61UaZdbz5WIROzt56s/uupmsHx2Zx9
l2/JBiP5l3r2fNPV2Dsas8FIQa4aJecWOEe6WhidDZGw2zwSMfu6K6BwEICA
Vwj4zB2p3Y/55xtekZB4e1GDMnRd0qxsMDI5l1NwY0C25Dx4rW9/+R11S85/
tczKLsgNlpiZ/OWVVks+IAABXxNAzBIv/uK538iem7vKuiQ23nOxZ+9ldUtO
uZ3FkaoRuZXFoRtDtjexQMy+bhoUDgIQgMDaEEDMIubHX/hdy52pA1fvHLx2
9+D1Pv0mFsflno+1E0erx49UjbX3zz250XrbR8S8NnWWs0IAAhDwNQHErN3E
Qr+7lHKbR+VOj8ptH4+Hpo7VTh2pnjhSNd7eH35y4+8ZyvZ1W6BwEIAABDxB
gMlfIuZfvvR6+8DsMeV+zGPHJNWOjc0u5BytmT5SNXm4YrKgYrytT8T8RsDF
zOQvTzRZMgEBCPidAGJWI2YR89xRTcy1o8dFzDMLOYcqJg9cG99/dWzflbGW
O3OPvWCKmPVZ2YmmZjMr2+9th/JBAAIQWBUCiFnE/MSL/64MZcs4tjKUPSKG
Voay914e2/PN6K4LIzvPDzX2zvziOes1ZttlRpbNRtwuRcqG44iYV6UJ8qYQ
gAAEYgkgZvV+zP/WeneqQKZ93eg/VCFpYHT6fs7Os0M7Sga3FfZvO91f1z39
8w2/C/hNLBAzvQcEIACBDBBg8peyXCr3N823xvMv9e67oqT9V3uV5VJ/Pd2/
+cTdT4/c/uTwrZqOyZ8+9W9RMVfnrdND43V51fbRrv+GslnHnIEGySkgAAEI
IGbRqmww0nhzdOf59q/Pt++6oKThyXDOp4dufXSg9/19Pe/v665qnfjxk7+N
EXOizUUUVSNmWhcEIAABCKRAADGLQ3+2/qW6rsEvCuu+KKzfLqmofmhiNmdT
fs97u7vzvu56d1dXZfP4g48j5pwUahgvgQAEIACBpAggZhHzT578VW1Hv2yU
vUXZLrti6/HKQbmJhfg4b2fnn3d2vPN1Z0W8mLWI2HEkm4g5qXrIwRCAAAQg
oBNg8pdy28cnnq9pu/Op3FdKTZ8UXBkYncr581cdkt6Wf3fGiTlyWVmuNTsN
aftvKJvJX3QbEIAABDJAADErYn78+erW2x8fvPTR/m8kfbivrH9kMiLmnR15
X3dWtkz86AnTUHZEzLKeGTFnoJpyCghAAALBIYCYo2I+cFGs/MHeC5vyzyti
fkcdxH5nV+df9miTv0x3lzI2GHGeAkbEHJxWREkhAAEIpJEAYhYx//jJF2Qo
+5OCyx8fuPThPsXNipglUH53d9dfdnfLxOzqtsmfmJdL2a2QsmwtgpjTWE15
KwhAAALBIcDkL3HsT5/aGOro/+zItf86XP5pwRUZ01auMb+/p/v9vT2b9vV8
eLC3pn3yp+tN65hdbNTlPzGzjjk4/QIlhQAE1pAAYlbXMb9c3z30+enabaeq
t56o2nzshjIr+8P9vR8e6P3oYO8nh2/Xdk79bH3Mzl/6YDazstew8nJqCEAA
An4kgJhFzI/k/rqpd/Trc607S5t3FDduL2pQ1jF/cujWp4dv/9eR258dv1vX
Nf2QeUvOyKQvmZXtpGYiZj+2F8oEAQhAYNUJIGZ1r+x/bbkzuf/yzb2XevIv
du/5pnNEdv7acvzu1pN3/3qqb9uZ/vrumYef+Xdj56/oKinn9VKIedUrLyeA
AAQg4EcCPp78NT09I2lqampiYrKvb+D27bu9vbe7u3vr65vKyi7X1IQ2b9k8
ODho3F3q0I3+ght9BdfvHrx2V7mJxfai/h3FA3Ifiy9LBy13lyrIjcTJQRIz
65j92ANQJghAwHMEfCzm2dm5f/j+9194/vk/vPGGlj75+ONjR4+2t3dZxCz3
Y+4YmD0qN3ysHj5aNXKkakS57ePX5we/vjC068Lw7m+Gm2/PPvZ89LaP1Xm5
+r0rELPnqjQZggAEIJDdBPwt5o0vvvj1zp3HI49z587duHEjXsy/fEnEPHe8
dkxLJ0LjY7MLOfkXB/MvDu29NLzvykjL3bnHf2W6H3MgrzETMWd3Wyf3EIBA
lhDwsZjdD2U/ufE/JGI+VjNyrGb0eGjsRN3EuIh53+X+fVcH918dOnhtpLVv
9okXTWIej9z3MUizshFzljRqsgkBCGQ3AR9P/nI/lP3Er37X3jd9qGLgSNXg
seqRY7WjasR86fa+K3f3X+07UD7Qenfm8V9FJ38lWMZs2WbExYLnrDmEdczZ
3dbJPQQgkCUE/C1ml0PZjz7325Y7E/uv3DxYfkfmfx2Sm0up15g7d5d177nY
u/dSr0zafux5Nhjhto9Z0qzJJgQgkM0EfCxm90PZjzzzSmPvyNfnWnaXdeZf
6tl/9ZYyK3tHUeOXJc07z7Z+fa69sXdMFjsby6UkyGWDkWyu9uQdAhCAgHcJ
+FjM7oeyf7Z+Y13XwOena3YUN3xV2rzrfPvI1L0cuS3ztpPVX5yu/aKwTjYG
e+jpl6NiDuTkL4ayvduOyRkEIOAjAj6e/CVi/s8//UnWR52PPMrLy0OhUPys
7J/I/Zjb73x25OqWYze2narZXlg3PDGXIze1+PTwVdlBe/PR67UdfT/55YsB
32CEyV8+avgUBQIQ8C4BH4vZ/VD2g489W93S++H+C58cvPTpoavKXtnjMzly
k6mP9pd9fOCi3HOqpvW23LTZEDMbjHi3RpMzCEAAAllOwMdilg2/RkfHhodH
BgaGWts6GhtbQqGGqqpQeXmFZYORf35kQ2VTz/u7Szbln/twX5lydym5icX7
+Wc/yD//4b4LH+4vq2q59eBjuaaImQ1Gsrzik30IQAACXiWAmGUi1z898nRl
U/d7XxeKm9/fc3ZT/nnlto8f7D2nBM12YlamfuUWyCsDdRMLhrK92orJFwQg
4CsCPp785T5iVsXc896u4vcl7S59b1dp/8hkzkcHvvnk4MVPCy7Jxeaatjs/
euw506zsIG4wwuQvXzV9CgMBCHiVAGKWuPfBR5+Ra8xKhJx/ViJmcbMiZpnz
teXY9S3HKySFZPLXky+Yl0vFbwti2VqEu0t5tc6TLwhAAAKeJoCYxbA/fvw5
CYmV2PjgxY/2f/Ph3gvKUPb2wtCOovodxfXyr7Jcav1LicVsUTVi9nTFJ3MQ
gAAEvEoAMYtPf/bUi3Vd/dtOVkqE/NmR8k8PXRkYnc7ZdaF9d1mH3JxZ/m3q
HX3kmVcRs1erMfmCAAQg4B8CTP4SMT8sO3/dHPmqpHFHUZ1sKLLtZNWQLJc6
eO2O3Jy54Jrcn/lOq7Il528DLmYmf/mn3VMSCEDAwwQQs4j50ed+I3tl77vU
vaesY9f51q9KmpQNRtS7TSk3nJJ/2/tnnnjxd4jZwzWZrEEAAhDwCQHELGJW
7i7VP3PoRt/B8tv7r8hNK7qVLTlPN06fbpg63TB9qmGqcygsN21GzD6p9RQD
AhCAgIcJIGYRszi3czB8onbsWPXwkcoBMbRyE4ui1rni1nBRS7iwebZ7+P76
l99AzB6uyWQNAhCAgE8IMPlLxPzUy2+Iec80Tp+qnzxZN35C7sc8s5BT3Ha/
tO1+Sdv94rZ7PSPz61/5Q8DFzDpmnzR6igEBCHibAGIWMYtze0bni1vmippm
CxtnzjRMj88u5JS2L5xtX5B/S9rne0YXnn71TcTs7cpM7iAAAQj4gQBiFjE/
/cqbYt6S9vslrfeKW5TR64m5xZyzHQtaKu1YuDm6sOHVt9yI2bLNSPw+JNn7
DBGzH1o8ZYAABDxPADErYn71rZtji6Ud80pqm5eh64nw3xQxi5K1dHPMrZgN
77LBiOcrPxmEAAQg4EUCTP7SxNw7tqhHyMrQ9X1DzOLqiJhfcxUx+1jMrGP2
YgsmTxCAgO8IIOaomDsXzkpSRDyvi9kImiWg3oCYl3J8V/8pEAQgAAHPEUDM
hpjPdS5qYpakilkVtRoxzyNmwUTE7LnmS4YgAAE/EkDMVjGrOp5EzPGT1BCz
H3sAygQBCHiOAJO/lhGzPiuboezxcWZle675kiEIQMCPBBCzWcz6aLY5YtaG
thnKFkyI2Y89AGWCAAQ8RwAxm8S8IGLW3BwdytYuOyNmxOy5tkuGIAABnxJA
zOZZ2Q5i7nQlZsvWIqxj9mmToVgQgAAEVpcAk79cRMzuxGyZLeU/MTP5a3Xb
Iu8OAQhAQCWAmC3XmLWgOXYoGzGrXzoQM50GBCAAgQwQQMyxYtYvM0+Gl3LM
65qVa8zu9spm568M1FpOAQEIQMDHBBCzs5g7Ittnt8/LTSy4uxQRs487AooG
AQh4hwCTv6Ji7lIGsSND2Us56j0f5+V+zCVyP+ZR7sfMcinvNFtyAgEI+JkA
Yo4Rs+pmdbnUUo74uLg1LLeBLGye6x65/9TLb7i57aOPh7JZx+znnoCyQQAC
niGAmK1iVt2siLmwebawaeZM49Tp+smuofCTG19HzJ6pt2QEAhCAgG8JIGYb
MXepYj5VN3EyNH68dux4zXDHwOwTv/odYvZtO6BgEIAABDxDgMlfjmI+WjV0
pHLgcEXfoet32+5OPfrcb92I2bLNSPytILL3GSZ/eabZkhEIQMDPBBCzo5gP
XO09cKV3/+Wb+y71NN8ef+TZ19yI2cfXmBGzn3sCygYBCHiGAGJ2FPPusvbd
F9p3XWjbdb6tsXf05xteRsyeqbdkBAIQgIBvCSBmRzHvKKrfUSypQVJDz9DP
1r+EmH3bDigYBCAAAc8QYPKXo5g/P13z+enaL86EvigM1XcP/vSpjQEXM8ul
PNNsyQgEIOBnAojZUcx/PVH511PV20TPZxCzcukcMfu5J6BsEICAZwggZkcx
b1XFrATNSsTMUDZi9kyrJSMQgICvCSBmRzFvi1h5e5FcYx5+6OmgT/4iYvZ1
V0DhIAABrxBg8pejmL8orFPmf5U0fnW2WWZlP/zMqwG/xsxyKa+0WvIBAQj4
mgBiNsR8vmtR0jk1KTt/fVXStPNsy9fn23aXdSrrmHN/nVjMlq1FtF+zdzuR
+JwjZl93BRQOAhDwCgHE7Cjm3WUd+Re79l7q3nf5ZuudyUefd7XzFxuMeKVq
kw8IQAAC2UkAMTuK+cDVWwfLbxdcu1two7+9f+bxwO+VTcScnW2cXEMAAllG
wGejreFweOvWrTMzM9PT0xMTk6OjY8PDIwMDQ61tHY2NLaFQQ1VVqLy8oqzs
ck1NaPOWzYODgxYxa6PZylD2kcqho1XDx6qHj9eMdA7OPbnxPwJ+jZnJX1nW
uMkuBCCQnQQQc7yYxc2KmE/WjZ+qnzhVP3m6fqp76N4v/+X3iDk7Kzm5hgAE
IJBNBBCzo5gLm2aLJDXPSeoemV//8h8QczZVbfIKAQhAIDsJIGZHMZe03itp
01PP6MLTr7yJmLOzkpNrCEAAAtlEgMlfjmIu7ZjX0tmO+Ztji0+/+lbAxczk
r2xq2eQVAhDIWgKI2VHMZzsXjdQ7trgBMS/lZG09J+MQgAAEsoYAYnYUs7bV
iJZ6xxc3vEbEjJizpmGTUQhAIHsJIOY0i9my/xc7f2Vv2yDnEIAABNaEAJO/
0ixmH+/8xTrmNWminBQCEAgaAcSMmN1G9Yg5aL0D5YUABNaEAGJGzIh5TZoe
J4UABCBgTwAxI2bETO8AAQhAwEMEmPyFmN2KmXXMHmq4ZAUCEPAvAcTsKGbz
/ZlZLiWYELN/+wFKBgEIeIgAYkbMRMweapBkBQIQgABiRsyImX4AAhCAgIcI
MPlrGTFr92e2DGVbdhFJ8Ktb6WXDcSyX8lDDJSsQgIB/CSDmVMTsRqOard0c
mS3HIGb/9gOUDAIQ8BABn7kjHA5v3bp1ZmZmenp6YmJydHRseHhkYGCota2j
sbElFGqoqgqVl1eUlV2uqQlt3rJ5cHAwNTFX563TzJtb4OBVxOyhak5WIAAB
CGQPAcS8vJhlNNs6K7s6L08Vsvh5XV61rZoRc/a0AnIKAQhAwEMEmPyVkpgj
KhYxO4XM/hMzy6U81HDJCgQg4F8CiHklYi7IdYqXx8cRs39bDSWDAAQgsIoE
EHPKYi7Idb7ALG+KmFex2vLWEIAABPxLADGnJuZlrIyY/dtkKBkEIACB1SXA
5K9UxGzMyRZ8TP5a3RrKu0MAAhAIGAHEnIqYE6w8tmw2ki1rlN3kk3XMAesc
KC4EILA2BBBzmsVsGM5/15gR89q0Uc4KAQgEjABiTlHMcpFZeQRpVjZiDljn
QHEhAIG1IcDkL9difvWtpaUlPSCOzP0K1AYjrGNemzbKWSEAgYARQMypiDm6
r4jzDiP+G8pGzAHrHCguBCCwNgQQcypijm4sgpjXpt5yVghAAAK+JYCYUxFz
dV6uvkM2YvZt06BgEIAABNaGAJO/UhHzeCCvMTP5a23aKGeFAAQCRgAxuxbz
a6bJX8ptpZiVHbC2QnEhAAEIZIQAYk5NzDYbcli2FvHf5C8i5ow0SU4CAQgE
nQBiTpuYLa5GzEFvW5QfAhCAQEoEmPyVopgDuMEIy6VSamK8CAIQgEByBBCz
azGzwchSTnKVi6MhAAEIQCB5Aog5FTGzwUjyNY1XQAACEICAKwKIORUxs8GI
q8rFQRCAAAQgkDwBJn+lIuZgbjDCrOzk2xevgAAEIJA0AcScipjZYCTpisYL
IAABCEDAHQHE7FrMbDCSw+Qvd62KoyAAAQisgABiTk3MNhuMaE9ZthlxPC4L
/8BQ9goaGi+FAAQg4JYAk7/SLGZDuP7bYIR1zG5bFcdBAAIQWAEBxJyimNlg
ZAW1jpdCAAIQgIAjAcTsWsxsMMIGI/QkEIAABFafAGJORcxsMLL6NZMzQAAC
EAgoASZ/pSLmYG4wwuSvgHYSFBsCEMgsAcScipjZYCSztZSzQQACEAgQAcTs
Wszmdcwy9Su3QF4pY9rr8qptlz75b1Y2EXOAOgaKCgEIrB0BxJySmBUjq+Z1
0nJkQXMWLldOtER77SoqZ4YABCAQFAJM/kpNzDb2smwt4r+ImXXMQekVKCcE
ILCmBBBz2sRscTViXtOKzckhAAEIZCsBxIyY3Q63EzFnaysn3xCAQFYRQMyI
GTFnVZMlsxCAgN8JMPkLMbsVM7Oy/d4bUD4IQMATBBAzYkbMnmiKZAICEICA
RgAxI2bETG8AAQhAwEMEEDNiRsweapBkBQIQgACTvxCzWzEzK5v+AgIQgEAG
CCDmNIvZss2IW+llw3GIOQMNklNAAAIQQMxpFrNhWDYYoXVBAAIQgEAKBBAz
YnYbrRMxp9DAeAkEIACBZAkw+QsxuxUz65iTbV0cDwEIQCAFAogZMSPmFBoO
L4EABCCwWgQQs6OYz3Utno+k3vHFDeb7Mbtwmf+uMRMxr1Yr5H0hAAEImAgg
ZsTs4luGeghipuuAAAQgkAECTP5CzG7FzOSvDDRITgEBCEAAMScSszGazVC2
YELM9BcQgAAEMkAAMS8jZs3NbsRs2VrEf9eYEXMGGiSngAAEIICYDTGLgo0I
eTK8lKP97l7MlhFhxEzrggAEIACBFAgw+Qsxu73GzOSvFBoYL4EABCCQLAHE
vLyYJWh2M5Tt+4gZMSfbujgeAhCAQAoEELNFzNrQdcxQNmLWvnMg5hQaGC+B
AAQgkCwBxIyYGcpOttVwPAQgAIFVJMDkL8TsVszMyl7FhshbQwACEIgQQMzx
Ypaha4aybWyNmOk3IAABCGSAAGJGzETMGWhonAICEICAWwKIOc1itmwz4lZ6
2XAcEbPbVsVxEIAABFZAgMlfaRazYVj/bTDCrOwVNDReCgEIQMAtAcSMmN1G
64jZbaviOAhAAAIrIICYETNiXkED4qUQgAAE0k0AMSNmxJzuVsX7QQACEFgB
ASZ/IWa3Ymby1woaGi+FAAQg4JYAYkbMiNlta+E4CEAAAhkggJgRM2LOQEPj
FBCAAATcEkDMjmI+2zFvpJtjC0+/+ubS0pJbiam3fPDZBXyGst22Ko6DAAQg
sAICPnNHOBzeunXrzMzM9PT0xMTk6OjY8PDIwMBQa1tHY2NLKNRQVRUqL68o
K7tcUxPavGXz4OCgo5iLWsLFkdQzMr/+5T8kFrNlaxH/iZnlUitoaLwUAhCA
gFsCiNlRzKfrJ43UNRT+5UuvBzxiRsxuWxXHQQACEFgBAcTsKOajVUNGau+f
efxXv0PMK6hpvBQCEIAABFwRQMyOYt53ucdILXcmHsn9NWJ2Vac4CAIQgAAE
VkCAyV+OYv6yuEHSV5JKGhp7hh5a/1LAxczkrxU0NF4KAQhAwC0BxOwo5i1H
rxsp1N7348efR8xuqxXHQQACEIBAqgQQs6OYP9p/UU3fSKpuuf3Pv3gWMada
zXgdBCAAAQi4JYCYHcX8Qf6FTXvOa6myufeHDz+DmN1WK46DAAQgAIFUCTD5
K4GYv9m0p2zT7gvv775Q2XQLMbNcKtVWxusgAAEIJEEAMTuK+cO9lz/Iv7Rp
z6VNuy9WNt/+4cOuhrIt24y43ynM+0ci5iQaFodCAAIQSJUAYna+xry3/IP8
q5t2X9m0+3Jl850fPvxcwIeyEXOqrYzXQQACEEiCAGJ2jpjzr2/ac+39XeWS
Kpvu/vDhoM/KRsxJNCwOhQAEIJAqASZ/OYr5/V3X39t57d2vyiVVNN79x58H
XcysY061lfE6CEAAAkkQQMyOYn73y/J3dlz98/Yr72y/eqPh7v97CDHnJFGz
OBQCEIAABFIigJgdxSxK/vMXV97+4sqfEbM6M42IOaUmxosgAAEIJEcAMTuK
+e3PFSu//YUEzeU3Gvr+8aEXAj75CzEn17Y4GgIQgEBKBJj8lVjMipXf2XG9
orH/hw//KuBiZvJXSk2MF0EAAhBIjgBidhRz3o5r7355/d2dFe/tqqxsHvin
RzYi5uQqF0dDAAIQgEDyBBCzo5g37an+IL/mw721Hx0I1bQOPfjYvyDm5CsY
r4AABCAAgeQIIGZHMX92qPGzw02bjzZvOdZS1zn6k1++aojZsr1Xgl+9v5+X
+xwylJ1c2+JoCEAAAikRYPKXo5i3F3ZJ2lHU9WVxT+PNiZ9v+E3AI2Ymf6XU
xHgRBCAAgeQIIGZHMed/c1fS3ot9ey/1tdyZ/kXuv5nEXJ23TouTcwscQk7t
z+7jUe8fiZiTa1scDQEIQCAlAog5KubOxXNdepoML+UcujFipPb+ucde+Peo
mKvz8lQhi5/X5VXbOhUxp1QheREEIACBoBNAzI5iPlE7Kem4mjoGw0+8+Hr8
ULaI2SlkRsxBb1uUHwIQgEBKBHw22hoOh7du3TozMzM9PT0xMTk6OjY8PDIw
MNTa1tHY2BIKNVRVhcrLK8rKLtfUhDZv2Tw4OBgjZgma1bhZiZhP18+crps5
VTd9KjTdOXjvyY3xYi7IdYqXx8f9J2Ymf6XUxHgRBCAAgeQIIGZHMZ+pnxU3
R8VsjZgLcp0vMMubIubkaiJHQwACEICASgAxO4r5ZGhKGcqumThWPd7eH378
hf8wDWUvY2XETPuCAAQgAIHUCCBmGzF3qkPZRypGD8v8r+vDBeVDrXdmHn0u
OivbmJMt+IIz+Yuh7NTaGK+CAAQgkBQBJn85innfpf59slZKFk2V3WnunXzY
3Tpmy2Yj3l8E5T6HLJdKqmlxMAQgAIHUCCBmRzF/VdLzZVHXDtlm5ExnfdfY
T007f7mRmf+uMSPm1NoYr4IABCCQFAHE7Cjmvx5v2Xq0efPhJtmbs7Zt+Efm
vbKjY9mO07IRc1IVkYMhAAEIQEAjgJgdxfzJ/rqP99UqN7HIr6luGfynR140
bzDiuH45Ek0jZtoYBCAAAQikQIDJX45i3rS76r2vK9+T2z5+VVEp92P+uel+
zAk2FvGvmJn8lUID4yUQgAAEkiWAmB3F/JedN/4i92PeoaSKxr5/fOiFmIhZ
i4jZYCTZGsfxEIAABCCQkABiTiDmir98dUNLSsT8sClijoTFgdqSk4iZzgQC
EIBABggg5gRD2dWb9ijpg/yaqpbBf/7Fxvi9shPsM+K/a8yIOQMNklNAAAIQ
YPKX8+SvA3WfHqz/r4KGzw43htpHfvzEy1Exi5C1h+NdH324JSfLpegvIAAB
CGSAAGJ2FPPWE23bTrZ/cbpje2FnQ/f4Q+t/HR8xmxc0W7YW8V/EjJgz0CA5
BQQgAAHE7CjmnaU3d52/tafsTv43fS23p3+RG92Skw1GaDkQgAAEILBKBBCz
85aclwcOXB0suD58+MZoe/9c7E0sxvXB7CDNyiZiXqVGyNtCAAIQMBNg8pfz
TSyqxo5VT5yonTop92Meuv/kS7+PucasXl2WWdncxIIWBQEIQAACaSSAmB3F
fLJu5nTD3JmmcGFzuHtkfv3LfzDEHF0l5bxeyn/XmJmVncaGx1tBAAIQcCKA
mB3FLD4uarlX3Ha/pG2+Z3Rh/StvGmIuyI3EyYiZtgUBCEAAAmklgJgdxSw+
Lm2fL+1YONuxcHNs8elX3zJFzLl51eoMMMSc1urIm0EAAhCAAJO/HMV8tl2U
vHhOUudi79jiBpOYlalfwbvGzOQv+gsIQAACGSCAmB3FrChZtbKNmJVIOXB7
ZSPmDDRITgEBCEAAMWtilrFqTcFamgwv5Zh/VyLm16JD2QnWMVu2GXGz4jlb
jkHM9BcQgAAEMkAAMRtiPpsWMRuW9d+sbMScgQbJKSAAAQgw+cssZsPNy0fM
AdxghOVS9BcQgAAEMkAAMbsWc+AnfyHmDDRITgEBCEAAMaciZjYYoeVAAAIQ
gMAqEUDMFjFro9l2Q9mmiJkNRlapOvK2EIAABCDA5K9UxFydF8QNRpj8RX8B
AQhAIAMEELNrMZuXS7HBSAbqJqeAAAQgEEgCiDlezDKaveysbDYYCWRzodAQ
gAAEVp8AYk5NzDabgli2FmEd8+rXXs4AAQhAwIcEmPyVNjFbXO0/MbNcyocd
AEWCAAS8RwAxI2a3W4IiZu+1X3IEAQj4kABiRsyI2YcNmyJBAALZSwAxI2bE
nL3tl5xDAAI+JMDkL8TsVsysY/ZhB0CRIAAB7xFAzIgZMXuvXZIjCEAgwAQQ
M2JGzAHuACg6BCDgPQKI2VHM5vsz944tbjDv/OXCZf5bLsVQtvfaLzmCAAR8
SIDJX2kWs2WbERcGz5pDWC7lww6AIkEAAt4jgJjTLGZDs/6LmBGz99ovOYIA
BHxIADEnErMxms1QtmBCzD7sACgSBCDgPQKIeRkxa25GzIjZe42XHEEAAv4k
wOSv5cUsbkbMgonJX/7sAygVBCDgMQKI2ZWYbzIrGzF7rOmSHQhAwK8EEDNi
djstnIjZr70A5YIABDxFADEjZsTsqSZJZiAAgaATYPIXYnYrZmZlB723oPwQ
gEBGCCDmtInZsrUI65gzUoE5CQQgAAG/EUDMaROzJfBEzH5rK5QHAhCAQEYI
IGbEzFB2RpoaJ4EABCDgjgCTvxCzWzEzK9tdm+IoCEAAAisigJgRM2JeURPi
xRCAAATSSwAxI2bEnN42xbtBAAIQWBEBxIyYEfOKmhAvhgAEIJBeAkz+Qsxu
xcw65vS2Pd4NAhCAgC0BxIyYETOdAwQgAAEPEUDMaRazZZsRt9LLhuOImD3U
cMkKBCDgXwKIOc1iNgzLBiP+bTWUDAIQgMAqEmDyF2J2G62zjnkVGyJvDQEI
QCBCADEjZsRMfwABCEDAQwQQM2JGzB5qkGQFAhCAAGJGzIiZfgACEICAhwgw
+csQc2nnoqSzapoML+VoP2np5tjihtfeWlpaciux8XEmf3mompMVCEAAAtlD
ADEjZrdfNlgulT3tmpxCAAJZTAAxI2bEnMUNmKxDAAL+I4CYLWLWRrOVoezS
juSGsi1bizCU7b/WQokgAAEIZIAAk78SiHnBuObMNWbBxDrmDDRITgEBCEAA
MTuKuaR9obRDdzNiRsx0FhCAAAQyQwAxI2a315iJmDPTJjkLBCAQcAKIOV7M
MoA9IdeY9YhZvdJMxEzEHPCeguJDAAIZI8DkrwRinjfcjJgFE8ulMtYsOREE
IBBkAojZUczFbfdL2udL5DJzxwJiRsxB7iYoOwQgkEkCiDmRmIvbJGieR8za
VWgi5ky2TM4FAQgElgBidhRzUes9LWhGzIg5sB0EBYcABDJPgMlfjmIubAmr
blaCZvdD2ZZtRtzOeM6G45iVnfn2yRkhAIEAEkDMjmI+o4tZCZp7Rhe4iQVi
DmAHQZEhAIHME0DMzmJunosEzfcRM8ulMt84OSMEIBBMAojZUcynm+aMoBkx
I+ZgdhCUGgIQyDwBJn8lEPPsGT1oJmJmVnbm2yZnhAAEAkoAMTuK+VTj7OnI
aDYRM8ulAtpDUGwIQCDjBBBzAjHPnGrSg+ZuJn+xjjnjjZMTQgACwSSAmB3F
fLJx5lTjzOmmWZkC1j06z6xsNhgJZh9BqSEAgQwTYPKXo5hPNEyfbJgWMcuV
5u4RxMz9mDPcNjkdBCAQUAKI2VnM9VMiZjVotorZsotIgl+zYeMQt3lkHXNA
OwmKDQEIZJYAYk4kZjVolgHtWSJmlktltmFyNghAILgEELOjmI/XT52oV0az
JWjuGr4fc425Om+dFibnFjjFm9rf3Uaj2XAcEXNw+wlKDgEIZJCAz9wRDoe3
bt06MzMzPT09MTE5Ojo2PDwyMDDU2tbR2NgSCjVUVYXKyyvKyi7X1IQ2b9k8
ODioi3l0sbRjsbRTTxPhpZzjdVOGm61ijni0IHddXrW9VP0nZiZ/ZbBhcioI
QCC4BBBzjJgjblbEfKxuUtx8Qr3S7CBmCZwdQ2bEHNxWRckhAAEIrIAAYnYW
c0jEPKmJudMylD0+XpAr6BzDZW07Dp/BJWJeQUPjpRCAAATcEvCZO1Y6lB0T
Mati1kazO4dirzHro9fKpWankBkxu62DHAcBCEAAAiYCTP6yRsyqm9Wh7NCE
OpqtBM2dQ/dsNxhJMJbtPzEz+YuuAwIQgEAGCCBmRzEfrZ2IuDlOzOpANrOy
M1BBOQUEIACBoBFAzCmJ2cXqJiLmoLUlygsBCEAgLQQQs42YO9ShbD1iVq80
dzgMZccL2rILmAuDZ80hDGWnpcnxJhCAAAQSE2DylybmHm0dcyTpYjbc3DEU
tlxj1geznedl+y9iZlY2vQkEIACBDBBAzAnEPH60dvyoTAELScQc3vDqW0tL
S3p4K1pWZ2PL5C8nNSPmDFRfTgEBCEDAfwQQcypijk7Gdp6WjZj911ooEQQg
AIEMEEDMhphLOhYsQ9lqxFw7IUFzx2BMxBzdiRMxZ6CScgoIQAACQSLA5K9l
xay42SLm6rxcfYvsIImZyV9B6hkoKwQgsGYEELNZzCWxk7+0iNlGzMqGnMG7
xoyY16yZcmIIQCBIBBBzRMwLxe0LMpqtudmYla2LuV2Gsl8zTf5SZn2pF5GD
NCsbMQepZ6CsEIDAmhFAzCYxz5cobjbEHJpQLjCrQXOcmJdffOy/yV+Iec2a
KSeGAASCRIDJX2kTs2VrEf+JmXXMQeoZKCsEILBmBBCzWczKaLYaNKtD2Qkj
ZjYYWbM6y4khAAEI+JoAYtbE3D26UNw2X9wuSbnSHBFzxM3KUDYbjOTk+Lot
UDgIQAACniCAmB3E/Df1to8OYmaDEU9UXjIBAQhAwI8EmPxlI+Z2iZgTijmY
G4ww+cuPPQBlggAEPEcAMetiHlkokqFsfTR73iRmNWi2DGWzwYjnKjIZggAE
IOAXAog5Iub5otb7hpujYlZGs0NWMbPBiF/qP+WAAAQg4DkCiNkQc6GIWXNz
uylijoqZDUaWmPzluQZMhiAAAf8RYPJXVMwt99yLOYgbjLCO2X/tnxJBAAIe
JICYDTGfabmnBM3qlWZtKHtSm5gtyf3OX5ZtRpYXePYcgZg92IDJEgQg4D8C
iFkTc9fwvCpmPWhWxVwXFbNyd6mYoWzlKnPQ9spGzP5r/5QIAhDwIAHEbBaz
HjS33rcTMxuMsMGIB1swWYIABHxHgMlfFjFrbjbELEGzEjfH3Y95nXrXx3Hl
LlP6T9Yhaf/tlc06Zt81fwoEAQh4kQBiNsR8ujl8pkWSWczKaLaNmNlgxIt1
mTxBAAIQ8AUBxBwjZsXNypXmiTntGrODmNlgxBeVn0JAAAIQ8CIBv4p5ampq
fHxieHhkcHCov3+gubmtvr6ppqauoqL6ytXr5y9crKkJbd6yeXBwMCrmpjk1
aL4nySLmSevkL5n6pY5gy0j2urxq24nVDGV7sb6TJwhAAAKeJ+DLyV/T09Oa
lQcGBvv6Bu7c6auvbxQTV1RWl5ffuHjp6rnz38SJ+f4pXcyKm8ejEbMaN8fN
yhYjMyvb87WbDEIAAhDIQgL+E/P+/ftv3749MTExOjo2PDw8NDQsQXNnZ1db
W0drW3tLS2tTU0tDQ9P16xX5+fnmiFkTsxY0Lyvm5Vcf+y9iZrlUFjZwsgwB
CGQfAf+Juby8XNwsw9SJk1i5tLTUIuZI0JySmC1biyDm7GsN5BgCEICABwj4
T8y3bt3q6+sbGRkZMz0kwJXfzGGuhNSTk5OamDe8+lbn8P2TjbPOYh6ybjCy
bMiMmD1QvckCBCAAgewj4L/JXymL+ZQqZs3NcUPZiHl8nHXM2de+yTEEIJCF
BBCzETFrVkbMjmMBiDkLGzhZhgAEso8AYjaLWRnNVuNmImYbPSPm7Gvf5BgC
EMhCAojZfI3ZJObFyAYj2nIphrIZys7C5k2WIQCBbCTA5C9tgxFj8pc2mj0+
h5jjYmaWS2VjCyfPEIBA1hFAzLqYh/RZ2WJliZsRs81QNmLOuuZNhiEAgWwk
4G8xy4KoGbuHbNhpXi6lRMyqmI2EmBFzNjZn8gwBCPiBgL/FLFL+7ne/+y31
8e1vf/sHP/jBxo0bN23aJM8nEPOKhrIt24wsu9w5iw4gYvZDi6cMEICA5wn4
e/KXFjE/9thjzz777Jtvvim7fV24cEGeIWJO5fsAs7I935zJIAQg4AcC/haz
7Palufn1118/cOBAZWWlZmXR0vJD2cfrpvQ7PzIrW/U4YvZDi6cMEICA5wn4
Usz9/f2jo6NGUCgmFh8fOnTIsDJiJmL2fNMkgxCAQFAJ+FLMQ0NDEitLTGw8
5EaQs7Oz8q/xjETSImzjJhbacqmYyV9EzBZ7EzEHtZeg3BCAQEYJ+HLyl4TL
2kh1godY2RCzcROLWDHXT4mbj7PBSMTPTP7KaNPkZBCAQFAJ+FLMYhKLksXB
WohseVjuLhUnZtXN7PylqRkxB7WXoNwQgEBGCfhSzPEOlkFsUbL8a3kkLead
yTx8BhcxZ7RpcjIIQCCoBHzmjnA4LLd9jBew0zPJidmyRtnNr6lMsvLqa8zl
levNRuJ5DQUc4EC70FoBHFbOwaseSCVfmphFt+4flptYaKPZys5fx2UcW0t1
U9pNLFLJEa+BAAQgAAEIQCBJAsZNLOyuMatu7hi6txIxy/cFHhCAAAQgAIFg
EkhSysrh9ntlRyPmFYu5y/WjM/K4efPmpUuXZK+yz9THZtMj/hnzX/kZAhCA
AAQgsHICmmuMh/hIrCRusjx6XTy8KGYX2bYecufOHaFw+/Ztbd4aDwhAAAIQ
gMAaEhBLiZXETZbH3diH7PAl15JHRka09VGiMG0yl+3jf/4oT5Ltn1Y9Yu5z
/TAKKCXZsmWLuleZImZZ62UkWaKtrtKOeZJfIQABCEAAAmkkoLlGkmxiLduD
jI6Obdu2Tdwke3jFP4YjD1GytvWmtj4qgZg1Kzu5+elX37S57WPioeylpaV3
3/uzluRn7WE8Y/H/QOxDCqY9oe2EIv9aDpBfpWxbt26dntZvuJHCOAAvgUBg
CUiHIG1Hku0PgcVCwSGQGgFR8uCgiHfkiy++EDdZHqIwLTKWfxV7j43JWbRN
vhKI2WxlWzc//YqIeT5uS05jVrbdNWbRsFMJ4/9kK2bNynLrK/nXSczybUP9
qjImREgQgIBLAtIh/MP3v7/xxRctP/znn/4kz7h8Ew6DAAQ0AmLlvv4BCSmd
xCxWllssa252KWZNoAmGsteLmIdFzHNJzMpeoZg1K//93//9G2+8kVDMU6Nj
4yqXIRIEIOCSgHxZf+H557/eudPyw7GjR+UZl2/CYRCAgEZApHznbl9iMX/r
W9+SOFNzc+KI2XxR2SJm8590MTeJmHU3K+uYTySMmGXUOuWIWbPy3/3d3z34
4IM7duxIIGb5di/D9QqX/gESBCDgkoC0zT+88cbx48ctP5w/f16ecfkmHAYB
CGgE7t7tu337jozsJoiYRczPPvus3GJZu42j01B2vImdPB0Vs+LmyAYjJ+qn
jcvM8euYE4g5/k+WkWr5QvGd73zne9/73ptvvnnkyJEEYh4YGOzpudnW1tHU
1EKCAARcEpBORBOz5QcRszzj8k04DAIQ0Ag0NDTV1Na1trUlEPO3v/1tMdqB
Awe0Wyzbijn+urLTM/IFOtNi1iLm9evXb9q0qbCwMIGY5atKZ2d3c3NrXV0j
CQIQcEng5s1bmpgtP4iY5RmXb8JhEICARqC2tr6yslpMlEDMP/jBD2QxVWVl
ZYKIeQViVoJmbSg7UcSc4BrzshGzjNRrbn7nnXcuXLiQQMx9ff0SLtfXN1VX
h0gQgIBLAl1dPZ98/PG5c+csP5SXl8szLt+EwyAAAY1ARWXNtWsVTU3NCcS8
ceNG0dmy15hTHMqW0eymOVXMDdPiZu1Kc/xQ9gonfxlrpc6cOZNAzDKy39zc
VlNTd+NGFQkCEHBJoKOjS+Z53bhxw/JDKBSSZ1y+CYdBAAIaAbHy5cvlMqCd
QMwyAOxyVnbSk79UK+tiPtkwY7h5NcTsZh1z763b8m3lypXrAoUEAQi4JCDf
ZVta2iXZ/uDyTTgMAhDQCFy8ePXChUt19Q1pXMfsdrlUxMpRMRtutp385bS7
iMt1zPFrl83PaBuMyLf7srLL589/c/ZcGQkCEIAABCCQaQJny0pLL5SUnA+F
6pzErO4Lpj9crmN2tcGIrGO2FfNJdUC7c2V3lzL2Klv2B2OfMylbQUHBjRsV
ctW9qqpWLryTIAABCEAAAmtF4OrVa7t27RI3JX6YFzGvdEvOVRWz+duEtmOZ
5Zn4X6VsNTU1spjqSx4QgAAEIACBtSawZ8+e4uJizbuJH9pmnJqVV3QTC2cx
z0jQvMKIWaZh84AABCAAAQgEk0AKe3TL3aW6hudPNc1Jipn8JdeYtbRCMaeQ
J14CAQhAAAIQCCwBt2LeyQMCEIAABCAAAdcEEiwtTvydw42Y72947S3JSWC/
vFBwCEAAAhCAQLIEUhbzBn0oO2yMZisbjBjj2OpQdiDEXHD45Nom+cjXNgMu
z55s1eR4CEAAAsEkkA4xK26OWcccucYcFDH/69o9RIqamOWDXKuHm9Jr+eQB
AQhAAALLEki3mBv1mV+BipjFTAtr8ZDzekTMiUtv5HPZ6sgBEIAABCCQLjFL
0KwOZQdYzLIKLZMPcaGnxOxUdnM+aW8QgAAEILAsgTSJWRnNVsR8Su7MHF0u
FaChbNFPJq0s50LMy1ZuDoAABCCQjQTSJ+Zw0MW83L4uaf6718TsVDwi5mzs
F8gzBCCwhgRWQcwymq0OaAdnVrZ2jTnDn6LXxOxU/DgxF+TmRB+5Be6xyQvX
5VW7Pz69R9qfvTpvXU5urrlEOUYmjYLG59rxT+of4qAoZ9Hf1obe2nJJL2Xe
DQIQEALpF7Mymh1IMS+3S3ma/+41MTsVz07MEVOpWnOt5rUVkN3ZJf8W6RpH
KUVz+BqR4E/jyuvlEfv9Q5Ox9qQpG1F68fmgc4MABLKYQFrF/DflGnNgxSw3
nczkIxUxn9moxqobz+grq9o//r4WvBrPyB/sntSf+/7H7cor5TfzC7QBA6ey
JxKzWTPLNyLPiTmBlxPkNWExlD/m5saaWZ5TgvI4MZvpKce4/oazPGqOgAAE
1pLAqom5MXBD2cventJ8gGk0N/pjUu+QiphVH5/ZGLHqmY2aaWNE2/7xx6q3
5Undw8pL1B/bP94o/1m0vLSkiVkyb1uoRGI26SQ6RBsVjDqCqz7U5wyjmcZ7
I4esy8szq0vcpr8o+h6GucxmNL+n+h7qIxqx2ry/0VyX83Lk3WKNqZ7R/k9G
Gc2a1c4Sm09tPD/+qLXsSTg3BCCQNgKrImYtbu4cDtasbP220Nff/t4zb7/9
PbWD/97b14eG9j+j/W/+SfnNojHjrtIuf0iDmHXhxplW9bf5WbOYo16PbGii
iVnLdnyhEl5jjo/yEowFa38yD38rhtbewnIVNmLW6AHqEQmCTpPsoy+yfX+j
7cVFqVHjqyPSeWrOTFmI6NTpT9EvH9G31u0f+6XE/HVFzw4hc9r6RN4IAmtO
IN1iblKUHEwxt2uPs398IOeBP57Vf1R/kqfk/+1P5jy5XT9I/8/QWOzTrn5L
h5jFzHEj2bpuI9G09qs+lL3xjKJl7UVGOK1HzEamLYVa7hqz2aGmeNXm8rNq
O/OV25iQ1S6mjH2TiLucI2Z9ZlnkAPv3dxSz6X3Np7CUJMGfTKMCkVPH5dn0
8phr1VxmXvO+lAxAIG0EEPNKUcreW1rI2KY9Sv/4wBPb9Z+3P/HAH0v1J3Ny
jKf1v6r/iYvMv7r/eeVijsbEsRZWhq5jrjobe30qWtbGs80BdUzx4wqV8Bpz
RFrx85jsxaya2QizvSVmW99rwbx5MpdFzAkmj0nIbbzU7muHOggQgUHEvNKG
zOsh4B0CLsUsh9XU1JizbbqJhewuoqTxOZn8ZYqYuwI2lN2iPYrfeuCBt4rV
Hz9/IueJzyNPfR59Xj9yZf+lRcx62BsjZicr6xenncTsVBpXEbPNAHb83GX9
oNjA1HYo27CdZSg7Ouyt+0z5+zLj23FD5UYriDGuJbt2w+HR/OuZto5ymyJm
fQzcvPTKdla2aX77Gi4l805/Rk4g4AsCLsXc19d39OhRN2KeM4aygybmJu1R
9OYD8tAGZR/fJk9sezzngTeLtL9oz6TlkYqY9ZFrY/ja+F2ZDqbN9jLmZMeM
Vpsj5NgZ2lKBtIjZqVAJrzEbMjEmWZmnJKvXfdVH7OQvywVlbbpWzOSv6HKj
6OQvk7iMN3Yz21nNgOn9o63AZOb4rxHGic3fErSf4/9kHh43MzEGB2yvMceW
iFnZvuiRKQQEhIBLMcezcoqY59TbQCqXmYMm5gbtceaN7z62Vf95Nf9LRczG
mHRaf9DE7FTWDO38ZTP0vfoN3CsXdr2Sj9UnzhkgEAgCicVsjGC7H8oOrpjr
tMep33/30S36z6v5n9fE7FTWzIg5Oiad2Wa7Jt8HLEW0GRHPLATOBgEIpJdA
YjEbI9jJDGUHNWIOZfbhNTE7lX41xRwdp7bZxzK9DYV3gwAEIJApAqkPZb/2
VtfwvDbtyzz5S4uYldHsoA1ly+y4TD68Jmansq+mmDPVSjgPBCAAgQwSsBVz
/Ai2zVC2rZhP61ZW3Bw0MYuBMvzw1P2YE5TdyGcGKzanggAEIJCtBGzFbAxc
9/b2Hjx4UMpmM5RtL+ZmI2IOlpjFPWvykFXU8vHIv2mdzpXcm7kpuJZPHhCA
AAQgsCyBNA9ln26eM4Lm4ETMYp01TJqYvZ+WrYscAAEIQAACQmBVxTy/4bW3
du7cCWgIQAACEIAABFwSSLuYw0bQLHPDNDEnNzDK0RCAAAQgAIFgE3CpcMth
4lybWdmnm0XMYW00u2Vw/tOdR+Q4EgQgAAEIQAACq01AnCvmtS6XMou5vOee
HCH2lovNRpJ7QSppyJLudQ4pqcM+hTuGnNNguCOS2gfD8Un5q/Jy/RR6Tkbm
uyWNzveMLihpbPFmkql3bDGVNL7Y66e0LDQNr13qHl2IJOWD0JP2uTikrhGt
OiVI0ZqmfdB6fYv/QWqg01+tldOoq9H6qVXXSFLeKlLDlbzp+VcLqJZ90X0F
c6xUK6k2al0113DJTzSNLnanLymFTZDM543/OfaFaq7USiKfu5aG562fWsyH
5dSByPORDsTUXUjPYNNjDITbY9Jc+4Bz6p9ts0vt/bPmV2ldkNQWqSTdI5L0
nufm6IL2oSgf+ko+X/NrU+uXXLzKpoeMtGul8aptVmlxek+ud8s6YSvVCGTb
jyD2MzK6d+sPMVJI8NEn+pOa23gfqc8k6D1s/iQ10z4t12Ut26cld4A4t7zn
vlnME+GlnItd91Q3R6eAGTt0Gnton2ycOdlgTScapk/UTx+vn7JJdVPH6yaP
JUihyWOhCS0dlVQraTyStOcn5R2O103JKeTUpxpnTjfNnmmeK2wJF7XeL26f
L2mfL+1YKO1cPOs6netcTCV1LZ5LazrftZj2lEQOFVwLMUkwqums/sN8qYq3
pP2+ktqUVGxKwr+o9Z6R5BORdMZIzeEzpqTUK7Vq2ab4mqZVuZM2Sa1+9n+a
lT+dsE9aFY1J8owcrL2bshOtmjclzy33CpVyKYVVit+xIEmrY26qmU3VWq7a
xFeDmM/RVLGVPHQslqipWFK7korSmrT3dEzaeeOT8pIFIxW1LRS1zUs603r/
dIt0LErfIoQtH1z0wzJ/NEqnEU0xvYepu9A7DVOPcaRmPDaNHamJpsPVozGp
auSQXTpcNaIddkRSzejR2jE50Yn6yVMN09LzFDbPFbWEi9vuSYso7ZiXliIt
SP/El/uUXbXN1LomF6+K7R6V+ix1W2q41n6l5UrppHc9Id24dNcqZ603PiLJ
ClZ9JtpRR3tspQ+P9OdGxx73g9UI5o/b8WfFLzbt17a9O/YP9v3G3EmpmQ5J
7ZqiO35k8ueLnfc+35mf0zM6rwfNzm62FbPaGyZyc8pilpoRdXO95uZpxc26
mO/pXWe71LPVF7PU/rS0vcibpN3K8oZJ5FBtzBYxKx1NJKmSNolZdXOsmBV7
mcSsNG/NzfoPiuTUpBs6sZjV1XqRO4Kbvgva6VmxqYOend1sadjyPdLiZuVL
Q7Pi5sIWpbdSCqt/NVH0rH1rWbamrYaY1U9KSWYxG272hJj1bwlWNxe23pcv
OqqbUxSz9NTRDiQ5MYs/khazZmvDzUdrxo7Vjh+vmzhZPyU9zxlxs4i59Z60
BfnaGuPmpFqf08EuFJtKUKE39mgnqYlZvl5oblaardLty1db6ck1N6vBkuZm
WzGrT5riKO1n5SXOStb783gjLO9mPfCLullpvOp36/iUpJilh/GimGUY4399
5//kbN+ZH7qrudkxaFZ7w6SD5uXEHKkENkHzuPr9ywiap+QbgHwPiATNWliT
StAsfVwq9TstbW81xZysm9Xu3iZuNoJmtfVGguZYN6tW1pIeN4vPNCXrobNV
zHrVig+aI1vO6fdQMevZvo1FIl3bkNohaJ6JE7PWsJUapQTNjbN6xtRsK0Gz
8kVkXnVzJGjuUALWxHGzfb1yUXMsX9QsQbOtm1cpaBbTJx0xRyN43c1F7UrQ
XNgqSXWzKmZL0BzzSan9rPoZqWNvMUFzxM2KmKNjbKZhNn2kzU4hupsPV4+5
DJoNMStxc82Y+EYJmutig2ZxswTN7aag2cVHvPz35tT6JdevMuJm7VumFjRr
bpbvo+ag2RQ3JyVm1c3JB83HYodJ7D0dFzRLbVltN0e6pkwHzeJiMfK3/vf/
zflv//1/yE8SN1/uvmfeBcx8n2Z1dDGtYtZGuU0fpDqgbfoiZhGzETSrX121
sEYfzVaGlVY5bk5L2/O2mLVAORIdKqPZlgFtPWiOs7L6vVtLqphjh7K1X51G
s01itrp59cQc+cYdFbM2mq0EzUoR1PEA1c0xo9mKmxNdOnH8wrdc5bEdQYl2
5bED2tHR7AwPaDsNZRvPR8a0NTErblYHtA03Wz9Qc8QTHauMEbMaNJvdHBOT
mS+BOY67RkJni5ttR7NVMUeCZhnN1oPmyZMNU6claG5WB7Rbw1rQHB3NXu7z
Xd7K2ju4tmwKR5p7SGNIzBw0y6iAETRrcXOSEbNLMSvhVtJxs52Y0+lmbwxo
yzVliZXFxWLkhx9+OOeVV14RP0vs/PlX+eNzi8un2cVxuzQ2u2iXFsZmV55M
Z1RzODH3t4mwOS1NhkkpEPjbZNgmxbK1oI78Kh+BXRpXn5R/Y5OLeuWm7mnH
SPVzOtihcspLLJUzWodj3krJtl6umApmQEgBctpeIlNCvJ2sVcVUB+I+sthP
yqH30D41dx3IzMKY6zQ6M2+bxmbm1RR5K/XU40rS82+uG5G2k7bPN2OdWEwD
V5pq5NOxpW1L1eWH4vYwW3cs86SthvQn3Xcmyx8Z35utyjPiX7GwuFisLDsz
/n/i8+W6lz0nxQAAAABJRU5ErkJggg==

------_=_NextPart_001_01CC0628.79BE29A5
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

------_=_NextPart_001_01CC0628.79BE29A5--

From pwg-announce-bounces@pwg.org  Fri Apr 29 10:34:54 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33AEE06A1 for ; Fri, 29 Apr 2011 10:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNnU-qKVWEJ2 for ; Fri, 29 Apr 2011 10:34:46 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB2FE069F for ; Fri, 29 Apr 2011 10:34:46 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 5A6CF79622; Fri, 29 Apr 2011 13:34:27 -0400 (EDT)
X-Original-To: pwg-announce@pwg.org
Delivered-To: pwg-announce@pwg.org
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by pwg.org (Postfix) with ESMTP id 35E2279621 for ; Fri, 29 Apr 2011 13:34:11 -0400 (EDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id dVVh1g00517dt5G5DVaC5L; Fri, 29 Apr 2011 17:34:12 +0000
Received: from VistaBusiness ([24.61.240.234]) by omta13.westchester.pa.mail.comcast.net with comcast id dVaB1g00X548CT43ZVaCt7; Fri, 29 Apr 2011 17:34:12 +0000
From: "William Wagner" 
To: 
Date: Fri, 29 Apr 2011 13:34:04 -0400
Message-ID: <002a01cc0693$a2c88070$e8598150$@net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwGk6JojcF15P1FS/iikEmAqyK8jg==
Content-Language: en-us
X-pwg-MailScanner: Found to be clean, Found to be clean
Subject: [Pwg-Announce] Request for info on MFD Alerts Implementations
X-BeenThere: pwg-announce@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Printer Working Group Announcement List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============0100989231=="
Sender: pwg-announce-bounces@pwg.org
Errors-To: pwg-announce-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 5A6CF79622.AC9A7
X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org

This is a multi-part message in MIME format.

--===============0100989231==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002B_01CC0672.1BB6E070"
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01CC0672.1BB6E070
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

There is an uncompleted PWG effort to document the use of the Printer MIB
alerts mechanism for handling alert and other events associated with the
non-printer aspects of an MFD, a practice used by some manufacturers at the
time. The WIMS group is investigating the updating and completion of this
effort, including the expansion of the effort to include security alerts and
specific MFD conditions. There will be a project charter presented for
consideration of the PWG membership shortly. 

 

To better scope out this renewed effort, and to ensure that the
specification supports and does not conflict with current practices, the
WIMS group is requesting information from members on whether and in what
ways they may be extending the Printer MIB Alerts capability to support MFD
events and conditions. Please provide this information to me or to the WIMS
mail list (wims@pwg.org), and/or by  participation in the WIMS conference
calls and face-to-face sessions.

Thank you.

Bill Wagner, Chair, WIMS


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------=_NextPart_000_002B_01CC0672.1BB6E070
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


There is an uncompleted PWG effort to document the use of =
the Printer MIB alerts mechanism for handling alert and other events associ=
ated with the non-printer aspects of an MFD, a practice used by some manufa=
cturers at the time. The WIMS group is investigating the updating and compl=
etion of this effort, including the expansion of the effort to include secu=
rity alerts and specific MFD conditions. There will be a project charter pr=
esented for consideration of the PWG membership shortly. =

 =

To better =
scope out this renewed effort, and to ensure that the specification support=
s and does not conflict with current practices, the WIMS group is requestin=
g information from members on whether and in what ways they may be extendin=
g the Printer MIB Alerts capability to support MFD events and conditions. P=
lease provide this information to me or to the WIMS mail list (wims@pwg.org), and/or by  participation in the=
 WIMS conference calls and face-to-face sessions.
Thank you.
Bill Wagner, C=
hair, WIMS

--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


------=_NextPart_000_002B_01CC0672.1BB6E070--


--===============0100989231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce

--===============0100989231==--


From ipp-bounces@pwg.org  Fri Apr 29 15:40:22 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A426EE06DA for ; Fri, 29 Apr 2011 15:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level: 
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whZ-iUqpZdYH for ; Fri, 29 Apr 2011 15:40:19 -0700 (PDT)
Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 639F2E06AF for ; Fri, 29 Apr 2011 15:40:19 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BFA5A79630; Fri, 29 Apr 2011 18:39:53 -0400 (EDT)
X-Original-To: IPP@pwg.org
Delivered-To: ipp@pwg.org
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by pwg.org (Postfix) with ESMTP id 178437962D for ; Fri, 29 Apr 2011 18:39:37 -0400 (EDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Apr 2011 15:39:37 -0700
Received: from TK5EX14MBXC110.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0289.008; Fri, 29 Apr 2011 15:39:36 -0700
From: Justin Hutchings 
To: "Zehler, Peter" , "IPP@pwg.org" 
Thread-Topic: WS-Discovery
Thread-Index: AcwBLlIsyY5dNihZSv6AUu6Ogpr/agDCdpuQAFZsjLAASvBk0A==
Date: Fri, 29 Apr 2011 22:39:36 +0000
Message-ID: <15713B46EB868E4FB0CF6D8BFD33617E47E74A94@TK5EX14MBXC110.redmond.corp.microsoft.com>
References: <15713B46EB868E4FB0CF6D8BFD33617E47E3DB24@TK5EX14MBXC114.redmond.corp.microsoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
MIME-Version: 1.0
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] RE: WS-Discovery
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1616766352=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: BFA5A79630.AA5A2
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1616766352==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_15713B46EB868E4FB0CF6D8BFD33617E47E74A94TK5EX14MBXC110r_"


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E74A94TK5EX14MBXC110r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Peter,
I spoke with folks here at Microsoft, and we believe the IPP everywhere spe=
c should simply reference the OASIS WS-Discovery 1.1 specification (http://=
docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html)=
 and describe how an implementer should describe the IPP endpoint. While th=
e DPWS specifications are more specific as to how to describe a set of web =
service endpoints, that's pertinent only to an implementation of the full D=
PWS and shouldn't affect the IPP spec.

So I'm expecting we're unblocked here and can proceed with this aspect of t=
he specification.

Thanks!
Justin

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Zehler,=
 Peter
Sent: Thursday, April 28, 2011 4:02 AM
To: IPP@pwg.org
Subject: [IPP] FW: WS-Discovery

All,
Below is the only thing I could find in the specifications relating to Web =
Service Discovery that supported the position that it is Web Service (i.e. =
SOAP) specific.  I could not locate any record of my conversations about us=
ing WS-Discovery for IPP nor recall any of the individuals with whom I had =
the conversation.  It was early in the creation of Web Services for Devices=
 which was about 8 years ago.  It was the consensus of the group that the a=
dvertised endpoint must be a Web Service.
Pete


Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

From: Zehler, Peter
Sent: Tuesday, April 26, 2011 1:57 PM
To: 'Justin Hutchings'
Subject: RE: WS-Discovery

Justin,
>From my readings of the specs I did not see any reason that the WS-Discover=
y, WS-Transfer and WS-MetadataExchange specifications would preclude the ad=
vertising of services that are not Web Services based.  However the Devices=
 Profile for Web Services specification contains a chain of definitions tha=
t does seem to limit the applicability.  I tried to find the mail thread fr=
om long ago that I had when I was looking into using WSD to also make the I=
PP endpoint visible.  I could not locate the mail notes.  As I have stated =
I have no objection to making IPP discoverable using WSD.  Since many vendo=
rs currently use WSD we just need to insure that it is acceptable to apply =
the technology to non-SOAP based services.
Pete

PS If you have no objections, I'll post this response to the IPP mail list.

HOSTED SERVICE
A distinguished type of SERVICE that is hosted by another SERVICE. The life=
time
of the HOSTED SERVICE is a subset of the lifetime of its host. The HOSTED
SERVICE is visible (not encapsulated) and is addressed separately from its =
host.
Each HOSTED SERVICE has exactly one host. (The relationship is not transiti=
ve.)

SERVICE
A network endpoint that receives and/or sends MESSAGEs to provide a service.

MESSAGE
Protocol elements that are exchanged, usually over a network, to affect a W=
eb
service. Always includes a SOAP ENVELOPE. Typically also includes transport
framing information such as HTTP headers, TCP headers, and IP headers.

SOAP ENVELOPE
An XML Infoset that consists of a document information item [XML Infoset] w=
ith
exactly one member in its [children] property, which MUST be the SOAP
Envelope [SOAP 1.2] element information item.

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler@Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

From: Justin Hutchings [mailto:justhu@microsoft.com]
Sent: Friday, April 22, 2011 4:48 PM
To: Zehler, Peter
Subject: WS-Discovery

Peter,
Did you have a reference to the doc published on W3C that needs revision fo=
r us to enable WS-Discovery on IPP? I'd like to review with some folks on t=
he Microsoft side.

Thanks!
Justin

Justin Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printi=
ng and Imaging


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--_000_15713B46EB868E4FB0CF6D8BFD33617E47E74A94TK5EX14MBXC110r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thanks Peter,


I spoke with folks her=
e at Microsoft, and we believe the IPP everywhere spec should simply refere=
nce the OASIS WS-Discovery 1.1 specification (http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.=
1-spec-os.html)
 and describe how an implementer should describe the IPP endpoint. While th=
e DPWS specifications are more specific as to how to describe a set of web =
service endpoints, that’s pertinent only to an implementation of the =
full DPWS and shouldn’t affect the IPP
 spec.   


 


So I’m expecting=
 we’re unblocked here and can proceed with this aspect of the specifi=
cation.  


 


Thanks!


Justin


 






From: ipp-boun=
ces@pwg.org [mailto:ipp-bounces@pwg.org]
On Behalf Of Zehler, Peter

Sent: Thursday, April 28, 2011 4:02 AM

To: IPP@pwg.org

Subject: [IPP] FW: WS-Discovery






 


All,=



Below is the only thin=
g I could find in the specifications relating to Web Service Discovery that=
 supported the position that it is Web Service (i.e. SOAP) specific.  =
I could not locate any record of my conversations
 about using WS-Discovery for IPP nor recall any of the individuals with wh=
om I had the conversation.  It was early in the creation of Web Servic=
es for Devices which was about 8 years ago.  It was the consensus of t=
he group that the advertised endpoint must
 be a Web Service.


Pete=



 




 


Peter Zehler



Xerox Research Center Webster

Email:
Peter.Zehler@Xerox.com=


Voice: (585) 265-8755

FAX: (585) 265-7441

US Mail: Peter Zehler

Xerox Corp.

800 Phillips Rd.

M/S 128-25E

Webster NY, 14580-9701





 






From: Zehler, =
Peter


Sent: Tuesday, April 26, 2011 1:57 PM

To: 'Justin Hutchings'

Subject: RE: WS-Discovery






 


Justin,


From my readings of th=
e specs I did not see any reason that the WS-Discovery, WS-Transfer and WS-=
MetadataExchange specifications would preclude the advertising of services =
that are not Web Services based.  However
 the Devices Profile for Web Services specification contains a chain of def=
initions that does seem to limit the applicability.  I tried to find t=
he mail thread from long ago that I had when I was looking into using WSD t=
o also make the IPP endpoint visible. 
 I could not locate the mail notes.  As I have stated I have no object=
ion to making IPP discoverable using WSD.  Since many vendors currentl=
y use WSD we just need to insure that it is acceptable to apply the technol=
ogy to non-SOAP based services.


Pete=



 


PS If you have no obje=
ctions, I’ll post this response to the IPP mail list.


 


HOSTED SERVICE 



A distinguished type o=
f SERVICE that is hosted by another
SERVICE. The =
lifetime



of the HOSTED SERVICE =
is a subset of the lifetime of its host. The HOSTED


SERVICE is visible (no=
t encapsulated) and is addressed separately from its host.



Each HOSTED SERVICE ha=
s exactly one host. (The relationship is not transitive.)=



 


SERVICE 



A network endpoint tha=
t receives and/or sends
MESSAGEs to p=
rovide a service.


 


MESSAGE



Protocol elements that=
 are exchanged, usually over a network, to affect a Web



service. 
Always includes a SOAP ENVELOPE. Typically also includes transport <=
o:p>


framing information su=
ch as HTTP headers, TCP headers, and IP headers.


 


SOAP ENVELOPE 



An XML Infoset that co=
nsists of a document information item [XML Infoset] with



exactly one member in =
its [children] property, which MUST be the SOAP


Envelope [SOAP 1.2] el=
ement information item.




 


Peter Zehler



Xerox Research Center Webster

Email:
Peter.Zehler@Xerox.com=


Voice: (585) 265-8755

FAX: (585) 265-7441

US Mail: Peter Zehler

Xerox Corp.

800 Phillips Rd.

M/S 128-25E

Webster NY, 14580-9701





 






From: Justin H=
utchings [mailto:justhu@microsoft.com]


Sent: Friday, April 22, 2011 4:48 PM

To: Zehler, Peter

Subject: WS-Discovery






 


Peter,


Did you have a reference to the doc published on W3C=
 that needs revision for us to enable WS-Discovery on IPP? I’d like t=
o review with some folks on the Microsoft side.



 


Thanks!


Justin


 


Justin
Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printi=
ng and Imaging


 




-- 

This message has been scanned for viruses and 

dangerous content by MailScanne=
r, and is


believed to be clean. 




--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.



--_000_15713B46EB868E4FB0CF6D8BFD33617E47E74A94TK5EX14MBXC110r_--

--===============1616766352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1616766352==--

From ipp-bounces@pwg.org  Sat Apr 30 10:12:23 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395D6E0693 for ; Sat, 30 Apr 2011 10:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OgMAz8z14-T for ; Sat, 30 Apr 2011 10:12:22 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6EBE0685 for ; Sat, 30 Apr 2011 10:12:19 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id AB01F79548; Sat, 30 Apr 2011 13:12:03 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com [209.85.161.46]) by pwg.org (Postfix) with ESMTP id ECE8F79537 for ; Sat, 30 Apr 2011 13:11:49 -0400 (EDT)
Received: by fxm17 with SMTP id 17so4210044fxm.5 for ; Sat, 30 Apr 2011 10:11:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=LN4QiG+nJs6lTvXPOpVeetuMGNwev0Xbx6T0QPs+om4=; b=Ey2+LLPrAnghKeids0f2YJcebkYS6RBa6TFEwT1DYJibsQE/PDO7KB897CoN5NebXL /YgJv9wPd0WcGv1uOOqx895qzQPBbcMEWi+QI3bOZAXLif/TKdox58AJfoWklQnpxHil mlqKL7lvoQwFnWWiejxz6kxvrR6Pth/lFW9pk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kuG9DIekx60cF5Nv4f5qeJ1UZ91se2jAO63OCkJckqC84nhj5W4jpZVuaOGfW5K1TC yzrFBlWGlrqg7saNpSuCjfWhKEJlAyygpcXC0QHzUs7HruCtNgNwlwXJ5kizUPJDM6p+ ywso7/DK/DCzcSXDcU+ZnXFqbYjAdhI8W4iYI=
MIME-Version: 1.0
Received: by 10.223.17.68 with SMTP id r4mr1446053faa.62.1304183508847; Sat, 30 Apr 2011 10:11:48 -0700 (PDT)
Received: by 10.223.37.19 with HTTP; Sat, 30 Apr 2011 10:11:48 -0700 (PDT)
Date: Sat, 30 Apr 2011 13:11:48 -0400
Message-ID: 
From: Ira McDonald 
To: ipp@pwg.org, Michael R Sweet , Paul Tykodi , Ira McDonald 
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
Subject: [IPP] IPP Agenda - 1pm EDT Monday 2 May 2011
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1419081317=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: AB01F79548.A8D37
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1419081317==
Content-Type: multipart/alternative; boundary=0015173fe69ac44e9304a225e231


--0015173fe69ac44e9304a225e231
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Our next IPP WG call will be on Monday.

  Monday 2 May 10-11am US PST / 1-2pm US EST

  Call-in toll-free number (US/Canada): 1-866-469-3239
  Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
  Call-in toll number (US/Canada): 1-408-856-9570 (Backup)

  Attendee Access Code: *******#
  Attendee ID Code: # (empty)

If you need the Attendee Access code, please email me a request.

Live Meeting Info (courtesy of Pete Zehler):

  Link:
https://www.livemeeting.com/cc/xerox/join?id=PWG_MFD&role=attend&pw=LetMeIn
  URL: https://www.livemeeting.com/cc/xerox/join
  Meeting ID: PWG_MFD
  Entry Code: LetMeIn

*** Main Objective - Review IPP JPS3 and PWG Raster specs ***

Agenda:

(1) PWG IP Policy and Minute Taker
     - Mike?

(2) Approve IPP minutes from previous meeting
     -
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20110418.pdf

(3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (Mike)
     -
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pdf
     - continue review at section 5.2.2
     - see minutes from 18 April for issues

(4) Review PWG Raster (Mike)
     - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
     - see minutes from 18 April for issues

(5) Discussion of IPP Everywhere (Mike/Ira)
     - http://pwg-wiki.wikispaces.com/IPP+Everywhere

(6) Next Steps
     - IPP WG teleconference on Monday 16 May
     - Use Case BOF at PWG F2F on Tuesday 24 May
     - IPP WG sessions at PWG F2F on Wednesday/Thursday 25-26 May
     - Review IPP Scan and IPP over USB drafts
     - All - post more use cases to IPP/Cloud Imaging mailing lists

Cheers,
- Ira (IPP WG Co-Chair)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--0015173fe69ac44e9304a225e231
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,


Our next IPP WG call will be on Monday.



=A0 Monday 2 May 10-11am US PST / 1-2pm US EST



=A0 Call-in toll-free number (US/Canada): 1-866-469-3239

=A0 Call-in toll number (US/Canada): 1-650-429-3300 (Primary)

=A0 Call-in toll number (US/Canada): 1-408-856-9570 (Backup)



=A0 Attendee Access Code: *******#

=A0 Attendee ID Code: # (empty)



If you need the Attendee Access code, please email me a request.


Live Meeting Info (courtesy of Pete Zehler):

=A0 Link: https://www.livemeeti=
ng.com/cc/xerox/join?id=3DPWG_MFD&role=3Dattend&pw=3DLetMeIn

=A0 URL: https://www.=
livemeeting.com/cc/xerox/join
=A0 Meeting ID: PWG_MFD
=A0 Entry C=
ode: LetMeIn


*** Main Objective - Review IPP JPS3 and PWG Raster specs ***


Agenda:



(1) PWG IP Policy and Minute Taker

 =A0 =A0=A0 - Mike?



(2) Approve IPP minutes from previous meeting
=A0=A0 =A0 - =
ftp://ftp.pwg.=
org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20110418.pdf

















(3) Review IPP Job and Printer Extensions - Set 3 (JPS3) (Mike)














 =A0 =A0=A0 - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330-rev.pdf<=
/a>

=A0=A0=A0=A0 - continue review at section 5.2.2
=A0=A0=A0=A0 - see minut=
es from 18 April for issues

(4) Review PWG Raster (Mike)

=A0 =A0=A0 - ftp://ftp=
.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf
=A0=A0=A0=A0=
 - see minutes from 18 April for issues


(5) Discussion of IPP Everywhere (Mike/Ira)

=A0=A0=A0=A0 - http://pwg-wiki.wikispaces.com/IPP+Everywhere


(6) Next Steps
=A0=A0=A0=A0 - IPP WG teleconference on Mond=
ay 16 May
=A0=A0=A0=A0 - Use Case BOF at PWG F2F on Tuesday 24 May
=
=A0=A0=A0=A0 - IPP WG sessions at PWG F2F on Wednesday/Thursday 25-26 May=A0=A0=A0=A0 - Review IPP Scan and IPP over USB drafts

=A0=A0=A0=A0 - All - post more use cases to IPP/Cloud Imaging mailing lists=


Cheers,

- Ira (IPP WG Co-Chair)

Ira McDonald (Mus=
ician / Software Architect)
Chair - Linux Foundation Open Printing WGCo-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Desi=
gnated Expert - IPP & Printer MIB

Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic<=
/a>
http://sites.google.com/site/highnorth=
inc

mailto:blueroo=
fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S=
aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2=
21=A0 Grand Marais, MI 49839

=A0 906-494-2434





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--0015173fe69ac44e9304a225e231--

--===============1419081317==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1419081317==--

From ipp-bounces@pwg.org  Sat Apr 30 13:43:35 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FACE06D5 for ; Sat, 30 Apr 2011 13:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.777
X-Spam-Level: 
X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYjVAt9lN6rS for ; Sat, 30 Apr 2011 13:43:30 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2D295E0694 for ; Sat, 30 Apr 2011 13:43:30 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 660FE79573; Sat, 30 Apr 2011 16:43:16 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by pwg.org (Postfix) with ESMTP id D123979571 for ; Sat, 30 Apr 2011 16:42:58 -0400 (EDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 9AF074011B; Sat, 30 Apr 2011 20:42:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1304196177; bh=BOcuaPyI7etgTYdKXX1FtevGS48+TNmth8qeRcP/pts=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=EHsCfHRIuqclGxCukgxp1uYrvJ4k3qVtIpbQRk/d9gqzFsZP01cFuNg2brqJHx/sg eFgP2BB/OXifnNm49VQs8z4iCvrfIVXM7qv45rGCtBxw2raSUW9c73UfVVKWcI/yRi zms/97mq4a4YdYB0TajK7l5F+3Iuxa7XPNnd+kEQ=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8A0CA260042; Sat, 30 Apr 2011 20:39:18 +0000 (UTC)
From: James Cloos 
To: ipp@pwg.org
Subject: Re: [IPP] (PWG) Raster Question on what is required
In-Reply-To:  (Glen Petrie's message of "Thu, 28 Apr 2011 10:21:35 -0700")
References:  <89169579-F912-4E85-B1EA-835F8975E4EC@apple.com> 
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sat, 30 Apr 2011 16:39:18 -0400
Message-ID: 
Lines: 22
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110430:ipp@pwg.org::2xkmRj1fvhY1mAMS:00000sl8B3
X-Hashcash: 1:30:110430:glen.petrie@eitc.epson.com::O7ODgTnqU7yPN2nz:0000000000000000000000000000000000NMJgA
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: 
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 660FE79573.A8DB8
X-pwg-MailScanner-From: ipp-bounces@pwg.org

>>>>> "PG" == Petrie, Glen  writes:

PG> I must be looking at the wrong version because TIFF 6.0 shows
PG> only <8,8,8> http://www.libtiff.org/support.html 

Libtiff has support for 8, 16, and 32 bit int per sample and 32 bit
ieee-float per sample images.  Support for signed ints might be limited
to 16 and 32 bit.  I'm not sure to what exetent libtiff supports tiff's
options for 64 bit ieee float, complex signed int and complex ieee float
sizes and formats, beyond recognizing and reporting them.

IIRC, libtiff.org was hijacked some time back.
The real homepage for libtiff is:

http://www.remotesensing.org/libtiff/

Also, PNG (and libpng) supports 16 bit per sample images, and OpenEXR
supports arbitrary sizes, much like tiff.

-JimC
-- 
James Cloos          OpenPGP: 1024D/ED7DAEA6

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

From ipp-bounces@pwg.org  Sat Apr 30 17:33:00 2011
Return-Path: 
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD1E0695 for ; Sat, 30 Apr 2011 17:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdoBGiNqiluQ for ; Sat, 30 Apr 2011 17:32:59 -0700 (PDT)
Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 531FEE0593 for ; Sat, 30 Apr 2011 17:32:59 -0700 (PDT)
Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 9152C79574; Sat, 30 Apr 2011 20:32:41 -0400 (EDT)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id BAFC979566 for ; Sat, 30 Apr 2011 20:32:27 -0400 (EDT)
MIME-version: 1.0
Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LKH00B0NQTYF291@mail-out.apple.com> for ipp@pwg.org; Sat, 30 Apr 2011 17:32:26 -0700 (PDT)
X-AuditID: 1180711d-b7c70ae00000719a-b2-4dbcaa195c7d
Received: from [17.151.74.166] (Unknown_Domain [17.151.74.166]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay13.apple.com (Apple SCV relay) with SMTP id 62.E8.29082.A1AACBD4; Sat, 30 Apr 2011 17:32:26 -0700 (PDT)
From: Michael Sweet 
In-reply-to: 
Date: Sat, 30 Apr 2011 17:32:27 -0700
Message-id: <218EADC7-860F-40EC-95C7-FE29BA49896F@apple.com>
References: 
To: Roy Samuel 
X-Mailer: Apple Mail (2.1222)
X-Brightmail-Tracker: AAAAAA==
X-pwg-MailScanner: Found to be clean, Found to be clean
Cc: ipp@pwg.org
Subject: [IPP] Re: Question on PWG draft specification mismatch & parsing
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Internet Printing Protocol \(current\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Content-Type: multipart/mixed; boundary="===============1858299609=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
X-pwg-MailScanner-Information: Please contact the ISP for more information
X-pwg-MailScanner-ID: 9152C79574.A9A47
X-pwg-MailScanner-From: ipp-bounces@pwg.org

--===============1858299609==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_b0DSI2clHYxTpc5CS18bbw)"


--Boundary_(ID_b0DSI2clHYxTpc5CS18bbw)
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable

On Apr 28, 2011, at 9:46 PM, Roy Samuel wrote:
> ...
> I found that neither of the directories contained files that adhered to t=
he draft document w.r.t parsing the header. Specifically for the value of =
=91NumColors=92.
>=20=20
> --1--
> According to the draft document, bytes 420-423 need to contain =91NumColo=
rs=92 value, however, I found them to be zero. Are the sample files outdate=
d??

Not exactly outdated, just the code that generated them (and the page heade=
rs) contains an error. I will post updates next week.
=20
> --2--
> ...
> (I use GIMP to open the output raster file in RAW mode).
> I have attached a screenshot of the output file that I=92m able to view t=
hrough GIMP (scaled down version).
>=20=20
> Is my algorithm wrong? Or are the specs incorrect?

I would suspect the former since the compression code that generated the fi=
les has been in use for many years now.

Another tool you can use is RasterView, available here (with source):

    http://www.easysw.com/~mike/rasterview/

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--Boundary_(ID_b0DSI2clHYxTpc5CS18bbw)
Content-type: text/html; charset=windows-1252
Content-transfer-encoding: quoted-printable

=

On Apr 28, 2011, at 9:46 PM, Roy Samuel wrote:
...
I found that neither of the directories containe=
d files that adhered to the draft document w.r.t parsing the header. Specif=
ically for the value of =91NumColors=92.
 
--1--
Accordin=
g to the draft document, bytes 420-423 need to contain =91NumColors=92 valu=
e, however, I found them to be zero. Are the sample files outdated??
<=
/div>

Not exactly outdated, just th=
e code that generated them (and the page headers) contains an error. I will=
 post updates next week.
 
...
(I use GIMP to ope=
n the output raster file in RAW mode).
I have attached a screenshot of the output file=
 that I=92m able to view through GIMP (scaled down version).
 
Is my algorithm wrong? Or are the specs incorrect?

I would suspect t=
he former since the compression code that generated the files has been in u=
se for many years now.

Another tool you can use is=
 RasterView, available here (with source):




_______________________________________=
___________
Michael Sweet, Senior Printing System Engineer, =
PWG Chair





--=20

This message has been scanned for viruses and

dangerous content by
MailScanner, and is

believed to be clean.


--Boundary_(ID_b0DSI2clHYxTpc5CS18bbw)--

--===============1858299609==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp

--===============1858299609==--