Message-ID: <187275088.4099628.1378122608384.JavaMail.app@ela4-app2491.prod> Subject: Tiffany Takashima's invitation is awaiting your response MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4099624_723436260.1378122608382" X-LinkedIn-Template: inv_exp_snackified_01 X-LinkedIn-fbl: s-vZjH5-_VTEA0B-CbCrS4llNhNRU01NZHnaSQXi_2ZgUT1PnHGOQQGX ------=_Part_4099624_723436260.1378122608382 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Tiffany Takashima would like to connect on LinkedIn. How would you like to respond? Tiffany Takashima Within 23 wards, Tokyo, Japan This is a reminder that on 8/28/13 12:44 AM, Tiffany Takashima sent you an invitation to become part of their professional network at LinkedIn. Reminder emails for pending invitations. © 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ------=_Part_4099624_723436260.1378122608382 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Tiffany Takashima would like to connect on LinkedIn. How would you like to respond?

Confirm you know Tiffany

You are receiving Reminder emails for pending invitations. Unsubscribe.

------=_Part_4099624_723436260.1378122608382-- From pwg-announce-bounces@pwg.org Tue Sep 3 04:57:31 2013 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 57D3D21F9DAA for ; Tue, 3 Sep 2013 04:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-2.077, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnsjY5JhxzRq for ; Tue, 3 Sep 2013 04:57:13 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id E7C2C21F9CDA for ; Tue, 3 Sep 2013 04:57:11 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id CFB4285BD; Tue, 3 Sep 2013 12:03:47 +0000 (UTC) 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.49]) by www.pwg.org (Postfix) with ESMTPS id 389CD85BB for ; Tue, 3 Sep 2013 12:03:46 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSJ00C0OT6YOAR0@mail-out.apple.com> for pwg-announce@pwg.org; Tue, 03 Sep 2013 04:57:06 -0700 (PDT) X-AuditID: 11807158-b7fea6d000001e19-8b-5225ce8f2767 Received: from [17.153.41.25] (Unknown_Domain [17.153.41.25]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 4C.79.07705.09EC5225; Tue, 03 Sep 2013 04:57:05 -0700 (PDT) From: Michael Sweet Date: Tue, 03 Sep 2013 07:57:03 -0400 To: "PWG Announcements Inc." Message-id: X-Mailer: Apple Mail (2.1800) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiOFNTUnfiOdUggz+rTSyOfIu1WNe6mtmB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgyrj1dhJTwXznis1Xl7M2MC616mLk5JAQMJF4 0DqVGcIWk7hwbz1bFyMXh5BAN5PExp7PrCAJNgE1id+T+sBsZoEEiaYj25m6GDk4WARUJF4v ygUJCwukSvy9O58JxBYRMJS49KOBHcTmFbCROHJvIQuErSfR83waI0irhICsxOo5HhMYuWch GToLSRVEXFti2cLXzLOAOpgFdCQmL0QThrA/nj/CtICRbRWjQFFqTmKlqV5iQUFOql5yfu4m RlBQNRRG7GD8v8zqEKMAB6MSDy/HXpUgIdbEsuLK3EOMEhzMSiK8/KdUg4R4UxIrq1KL8uOL SnNSiw8xSnOwKInzsscrBgkJpCeWpGanphakFsFkmTg4pRoYfV1XaIjvuzl9tUXaYZtXq81/ 9M+der5FQNkmXeHZuhANs3mFrtvSGDtXmNySufjpkav+up1KP57yfnjw+nDYe9W3d5Xlu5bX pe/tuvJql/cVLSte/+1KEd4KJ6fwJpqsmvqByfnWBOVI3psmMgnnUkrT+qU/pf9xyWzxzFWT UDPZ+/7K+/0flViKMxINtZiLihMB6jgawCYCAAA= Subject: [PWG-Announce] [EXTENDED] PWG Last Call of IPP Transaction-Based Printing Extensions (07/30/13 to 09/13/13) X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Printer Working Group announcement list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0943534377==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org --===============0943534377== Content-type: multipart/alternative; boundary="Boundary_(ID_++ODzfhYNnJWArZ9a60ZaA)" --Boundary_(ID_++ODzfhYNnJWArZ9a60ZaA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT [THIS LAST CALL HAS BEEN EXTENDED UNTIL FRIDAY, SEPTEMBER 13, 2013. IF YOU HAVE NOT ALREADY DONE SO, PLEASE REVIEW THE DOCUMENT LINKED BELOW AND PROVIDE YOUR ACKNOWLEDGEMENT. THANK YOU!] All, [This PWG Last Call starts today, Tuesday July 30, 2013, and ends Friday, September 13, 2013 at 10pm US PST.] This is the formal announcement of the PWG Last Call for the IPP Transaction-Based Printing Extensions specification, located at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf All required attributes and values defined in this document have been prototyped by Apple and/or other vendors. The IPP WG has completed extensive review of the various revisions of this document and an IPP WG last call. The PWG Process/3.0 requires that a quorum (30%) of PWG 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. HOW TO RESPOND Send an email with *exactly* the following subject line format: Subject: has reviewed the IPP Transaction-Based Printing Extensions specification and has [no] comments WHERE TO SEND YOUR RESPONSE Please send your response to *all* of the following email addresses (replacing "dot" with '.' and "at" with '@'): ipp "at" pwg "dot" org (IPP WG mailing list - you must be subscribed!) blueroofmusic "at" gmail "dot" com (Ira McDonald, IPP WG Co-Chair) ptykodi "at" tykodi "dot" com (Paul Tykodi, IPP WG Co-Chair) msweet "at" apple "dot" com (Michael Sweet, IPP WG Secretary and IPP Transaction-Based Printing Extensions Editor) Note that you must be subscribed to the IPP WG mailing list to send email there - otherwise your email will be silently discarded. Please do NOT simply reply to this note on the PWG-Announce list. 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 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --Boundary_(ID_++ODzfhYNnJWArZ9a60ZaA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

[THIS LAST CALL HAS BEEN EXTENDED UNTIL FRIDAY, = SEPTEMBER 13, 2013. IF YOU HAVE NOT ALREADY DONE SO, PLEASE REVIEW = THE DOCUMENT LINKED BELOW AND PROVIDE YOUR ACKNOWLEDGEMENT. THANK = YOU!]

All,

[This = PWG Last Call starts today, Tuesday July 30, 2013, and ends Friday, = September 13, 2013 at 10pm US PST.]

This is the = formal announcement of the PWG Last Call for the IPP Transaction-Based = Printing Extensions specification, located = at:

ftp:/= /ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf

<= /div>

All required = attributes and values defined in this document have been prototyped by = Apple and/or other vendors. The IPP WG has completed extensive review of = the various revisions of this document and an IPP WG last = call.

The PWG Process/3.0 requires that a quorum (30%) of PWG = 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.

HOW TO RESPOND

Send an email with *exactly* = the following subject line format:
Subject: = <Company Name> has reviewed the IPP Transaction-Based Printing = Extensions specification and has [no] comments

WHERE TO SEND YOUR RESPONSE

Please send your response to *all* of = the following email addresses (replacing "dot" with '.' and "at" with = '@'):

ipp "at" pwg "dot" org (IPP WG mailing list - you must be = subscribed!)
blueroofmusic "at" gmail "dot" com = (Ira McDonald, IPP WG Co-Chair)
ptykodi "at" = tykodi "dot" com (Paul Tykodi, IPP WG Co-Chair)
msweet "at" apple "dot" com (Michael Sweet, IPP WG = Secretary and IPP Transaction-Based Printing Extensions = Editor)

Note that you must be subscribed to the IPP WG mailing list = to send email there - otherwise your email will be silently = discarded.

Please do NOT simply reply to this note on the PWG-Announce = list.

Note: The PWG Definition of the Standards Development = Process Version 3.0 is located at:

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

_______________________________________________
pwg-announce = mailing list
pwg-announce@pwg.org
https://w= ww.pwg.org/mailman/listinfo/pwg-announce
= --Boundary_(ID_++ODzfhYNnJWArZ9a60ZaA)-- --===============0943534377== 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 --===============0943534377==-- From ipp-bounces@pwg.org Tue Sep 3 05:10:14 2013 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 6883B21E810A for ; Tue, 3 Sep 2013 05:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-1.962, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKxfKejLDSI0 for ; Tue, 3 Sep 2013 05:10:09 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 08DBF21E809E for ; Tue, 3 Sep 2013 05:10:09 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 53B0785BF; Tue, 3 Sep 2013 12:16:45 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 49E0585BE for ; Tue, 3 Sep 2013 12:16:44 +0000 (UTC) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSJ00CC6TSSOAR0@mail-out.apple.com> for ipp@pwg.org; Tue, 03 Sep 2013 05:10:04 -0700 (PDT) X-AuditID: 11807166-b7fd66d000006a64-d3-5225d199e805 Received: from [17.153.41.25] (Unknown_Domain [17.153.41.25]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 39.E0.27236.B91D5225; Tue, 03 Sep 2013 05:10:04 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Tue, 03 Sep 2013 08:10:00 -0400 Message-id: <165688C8-527B-42F0-B3F8-EB211C63E13E@apple.com> References: To: Daniel Manchala X-Mailer: Apple Mail (2.1800) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUiOFNTUnfORdUgg4tPlC1ev1rKbvF4x2RW i2P7XrJYHPkWa9H5zdqB1WPryR9sHjtn3WX3mLd4OpPH5ivPWTyWn1rPFsAaxWWTkpqTWZZa pG+XwJVx9dMO1oI+v4pdT04yNTBOceli5OSQEDCRWDe1hwnCFpO4cG89WxcjF4eQQDeTxK0j /WwgCWGBHIlfx1+ygti8AnoSPc+nMYLYzAIJEj0794PZbAJqEr8n9YHVcAoEShyesoeli5GD g0VARaLxvBlEebZEy693zBBjbCRmfeoGGy8kECDxeFcjK0i5iIC+xPnrqiCmhICsxOo5HhMY +WYh2TsLyV4IW1ti2cLXzBC2gcTTzlesmOL6Em/ezWFawMi2ilGgKDUnsdJCL7GgICdVLzk/ dxMjKKwbCtN2MDYttzrEKMDBqMTDy7FXJUiINbGsuDL3EKMEB7OSCC//KdUgId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rwc8YpBQgLpiSWp2ampBalFMFkmDk6pBsabawMO/LfjyTyyYh5zpPOb 1si717ddU7izidtL2Cru1toznwTz7FTK0xtrrGSbprtHlq3Z+/eIpl/uzFrpU1NtNv4JCT26 45bTz0d72ximFek21JdL+FioW8mJ1R/tcS9ZtHeS8QnZNi3bCtV6bkPfz6bX5vw2yVh8zT3m f+ingsTedwzzK5VYijMSDbWYi4oTAQt3AFVnAgAA Cc: "ipp@pwg.org" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0840015353==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0840015353== Content-type: multipart/alternative; boundary="Boundary_(ID_DXbNAHxOfz5+8tFbnW85PA)" --Boundary_(ID_DXbNAHxOfz5+8tFbnW85PA) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel, Thank you for your comments. My initial responses are inline below... On Aug 30, 2013, at 1:27 AM, Manchala, Daniel = wrote: > Xerox has reviewed the IPP Transaction-Based Printing Extensions = specification and has the following comments. >=20 > Xerox would like to add a new "job-state-reason" to section 8.1 = =93job-state-reasons (1setOf type2 keyword)=94: =93incompatible = account-information=94. This account (=93job-account-id=94) is not = associated with the user (=93job-accounting-user-id=94).=20 No objection, although we need a proper keyword value. = 'account-info-conflicting'? > Likewise, add a new associated status-code to section 8.2 = "client-error-account-information-incompatible" (or something of that = nature). In this case I'd prefer to keep using = client-error-conflicting-attributes and have the printer return the = job-account-id and job-accounting-user-id attributes in the unsupported = attributes group. > Add an attribute: =93job-account-type (type2 keyword | name(MAX))=94 along with =93job-account-type-supported(1setOf type2 = keyword | 1setOf name(MAX))=94 and = =93job-account-type-default(type2 keyword | name(MAX))=94. The = keywords initially can start with =91none=92, =91general=92, =91group=92 = or =91visa-card=92, =91master-card=92, =91paypal=92,=92bit-coin=92, = =91micro-mint=92, =91cash=92, =91credit-account=92, etc., . The = preference is to use keywords as it aids in the internationalization.=20 We've very specifically avoided currency or payment identifiers since a) = many members, including Xerox, have indicated that payment processing is = done separately from the printer and b) we have no facility in IPP to = express currency values or other complex, fractional types. What would be the purpose of adding this when the printer-charge-info = and printer-charge-info-uri values provide localized resources that can = be displayed by the Client? Since the Client never has to have knowledge = of how transactions are processed (just whether the printer needs = transactional information), and since job-account-id will not (or at = least SHOULD NOT) be a credit card number or other direct payment = identifier, I don't see the point in telling the Client anything other = than "I need a job-account-id from the user." > Add the conformance requirement in IPP: Transaction Based Printing, as = an addendum to PWG 5100.3-2001 IPP:Production Printing Attributes =96 = Set 1, Section 7 as follows: > =20 > If the Printer supports =93job-accounting-user-id=94 then the Printer = MUST support =93job-account-id=94. No objection to adding this. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_DXbNAHxOfz5+8tFbnW85PA) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel,

Thank you for your = comments. My initial responses are inline = below...

On Aug 30, 2013, at 1:27 AM, = Manchala, Daniel <Daniel.Manchala@xerox.com>= ; wrote:

Xerox has reviewed the IPP = Transaction-Based Printing Extensions specification and has the = following comments.

Xerox would like to add a new "job-state-reason" to section 8.1 =93job-state-reasons (1setOf type2 keyword)=94: = =93incompatible account-information=94. This account = (=93job-account-id=94) is not associated with the user = (=93job-accounting-user-id=94).

No objection, = although we need a proper keyword value. = 'account-info-conflicting'?

Likewise, add a new associated status-code to section = 8.2 "client-error-account-information-incompatible" (or something of = that = nature).

In = this case I'd prefer to keep using client-error-conflicting-attributes = and have the printer return the job-account-id and = job-accounting-user-id attributes in the unsupported attributes = group.

Add an attribute: = =93job-account-type (type2 keyword | name(MAX))<Job Template>=94 = along with =93job-account-type-supported(1setOf type2 keyword | 1setOf = name(MAX))<Printer>=94 and =93job-account-type-default(type2 keyword | name(MAX))<Printer>=94. The keywords initially can = start with =91none=92, =91general=92, =91group=92 or =91visa-card=92, = =91master-card=92, =91paypal=92,=92bit-coin=92, =91micro-mint=92, = =91cash=92, =91credit-account=92, etc., . The preference is to use = keywords as it aids in the internationalization.

We've very = specifically avoided currency or payment identifiers since a) many = members, including Xerox, have indicated that payment processing is done = separately from the printer and b) we have no facility in IPP to express = currency values or other complex, fractional = types.

What would be the purpose of adding this = when the printer-charge-info and printer-charge-info-uri values provide = localized resources that can be displayed by the Client? Since the = Client never has to have knowledge of how transactions are processed = (just whether the printer needs transactional information), and since = job-account-id will not (or at least SHOULD NOT) be a credit card number = or other direct payment identifier, I don't see the point in telling the = Client anything other than "I need a job-account-id from the = user."

Add the conformance requirement in IPP: Transaction Based Printing, as an addendum to PWG 5100.3-2001 IPP:Production Printing = Attributes =96 Set 1, Section 7 as follows:

If the Printer supports =93job-accounting-user-id=94 = then the Printer MUST support = =93job-account-id=94.

<= /div>No objection to adding this.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_DXbNAHxOfz5+8tFbnW85PA)-- --===============0840015353== 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 --===============0840015353==-- From ipp-bounces@pwg.org Tue Sep 3 05:59:32 2013 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 E8FF721E813E for ; Tue, 3 Sep 2013 05:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=-2.857, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_HTML_MOSTLY=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inmbBZHk9Npe for ; Tue, 3 Sep 2013 05:59:18 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 17DDF21E8133 for ; Tue, 3 Sep 2013 05:59:17 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 1A48385BE; Tue, 3 Sep 2013 13:05:54 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 5A8B980A5; Tue, 3 Sep 2013 13:05:53 +0000 (UTC) MIME-version: 1.0 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSJ00GZBW0ISB11@mail-out.apple.com>; Tue, 03 Sep 2013 05:57:55 -0700 (PDT) X-AuditID: 11807153-b7fa56d000007d7a-d0-5225dccf6a11 Received: from [17.153.41.25] (Unknown_Domain [17.153.41.25]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id E4.4C.32122.0DCD5225; Tue, 03 Sep 2013 05:57:54 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Tue, 03 Sep 2013 08:57:50 -0400 Message-id: <469D5BFC-3F06-4587-8F9C-0208CDD9DB1F@apple.com> References: To: Daniel Manchala X-Mailer: Apple Mail (2.1800) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUiOFNTUvfSHdUgg59/9Sxev1rKbvF4x2RW i2P7XrJYHPkWa9H5zdpi+YWrTA5sHltP/mDz2DnrLrvHvMXTmTw2X3nO4rH81Hq2ANYoLpuU 1JzMstQifbsErow5a44wFvycwFhx6uU99gbGJ7VdjJwcEgImEhu+HGaCsMUkLtxbz9bFyMUh JNDNJPG0bQEjSEJYoEji5ImD7CA2r4CeRM/zaWBxZoEEidcPtoPZbAJqEr8n9bGC2JwCgRIX Tr1mBrFZBFQk5r/oZQUZyizQwSixetZuqEE2EpumrGSC2DaVUeLC879Aqzk4RAT0Jc5fVwUx JQRkJVbP8ZjAyDcLyepZSFZD2NoSyxa+ZoawDSSedr5ixRTXl3jzbg7TAka2VYwCRak5iZXG eokFBTmpesn5uZsYQYHeUBi8g/HPMqtDjAIcjEo8vAn7VYKEWBPLiitzDzFKcDArifDyn1IN EuJNSaysSi3Kjy8qzUktPsQozcGiJM7LFq8YJCSQnliSmp2aWpBaBJNl4uCUamDcfkzc48i9 tBV/WDUbVK37X2u3pv22sHOwjPpygPO+zvu1Ttwr2pesZWrQ3M39WOFWdhez4KTjysqN0XwS fyWKzuy+rrJ4SfHZ1IMs4jW311v6xNSo7X9Ys1ht9sLvekU8Jefqlz/suWl/tqpx63v2uh32 7wyX6QewvzAP8BHfxPrHsm3aCUslluKMREMt5qLiRAA5wzlmcAIAAA== Cc: "ipp@pwg.org" , "sm3@pwg.org" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0605968804==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0605968804== Content-type: multipart/alternative; boundary="Boundary_(ID_vV+yP8XrFd24rvNEqEUb/A)" --Boundary_(ID_vV+yP8XrFd24rvNEqEUb/A) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel, Thank you for the additional comments. My initial responses are inline = below, but as a general comment I think we don't need to mirror every = IPP attribute in the SM - some things are a side-effect of the protocol = or of targeting specific markets/use cases. On Aug 30, 2013, at 12:57 PM, Manchala, Daniel = wrote: >=20 > Some additional comments from Xerox: >=20 > IPP Attributes should be document format independent. Existing = semantics should be used when they exist or corrected when additional = semantics are required. > 1) =93jpeg-k-octets-supported=94 should be dropped in favor of = the existing =93k-octets-supported=94.=20 > a. Note that IPP attribute coloring can be used to obtain = document format specific values when required. In actual implementation, the existing attribute (with multiple queries) = was too inefficient. This attribute has been widely implemented in IPP = printers since 2010. My preference is to reject this request. > 2) =93pdf-k-octets-supported=94 should be dropped in favor of the = existing =93k-octets-supported=94. In actual implementation, the existing attribute (with multiple queries) = was too inefficient. This attribute has been widely implemented in IPP = printers since 2010. My preference is to reject this request. (For reference, a Client might need to determine supported file formats = and sizes in order to determine which format to send to the Printer. = And certain file formats such as PWG Raster generally are streamed on = both the Client and Printer so the job-k-octets-supported value is MAX = vs. some smaller value for PDF or JPEG) > 3) =93pdf-versions-supported=94 should be dropped in favor of the = existing =93document-format-details-supported=94 (=93document-format=94 = and =93document-format-version=94 members). "document-format-version" is localized text, = "document-format-details-supported" is a list of member attributes = supported by the "document-format-details" attribute, and = "document-format-version-supported" is a list of all of the localized = version strings that are supported for all formats that is optionally = filtered by document-format when you do a Get-Printer-Attributes = request. Since there is no way to register localized text values, filtering those = values with multiple Get-Printer-Attributes requests is inefficient, and = this attribute is supported by most IPP+PDF printers since 2010, my = preference is to reject this request. > 4) =93jpeg-x-dimension-supported=94 and = =93jpeg-y-dimension-supported=94 should apply to any image format. The = names should be changed to =93max-image-x-dimension-supported=94 and = =93max-image -x-dimension-supported=94. These attributes have been widely implemented since 2010. And as I've = noted before doing multiple Get-Printer-Attributes requests is really = inefficient. My preference is to reject this request. > 5) =93printer-dns-sd-name=94 should be applicable to any service. = The name should be changed to =93dns-sd-name=94. With a few exceptions, we prefix all Printer Description attributes that = are not associated with Job/Document Template attributes with = "printer-". And since DNS-SD is a *service* discovery protocol, not a = device discovery protocol, I don't think dropping the "printer-" prefix = or using an alternate prefix like "device-" makes sense. And FWIW CUPS = has implemented "printer-dns-sd-name" for a very long time (since CUPS = 1.2/2005 IIRC). > Scaling should not be print specific. IPP =3D Internet Printing Protocol, so we are necessarily focused on = printing. And as has been done in the past, SM can (and probably should) = map print-scaling to ScalingMode (or whatever), just as print-quality is = mapped to Quality, printer-resolution =3D> Resolution, etc. > The PWG Semantic Model already defined a collection for scaling (i.e., = =93scaling=94). Apparently we didn=92t quite get it right. The current = definition allows for explicit scaling (i.e., =93scaling-height=94 and = =93scaling-width=94) or a boolean for =93auto-scaling=94. The explicit = scaling member should be kept. The Boolean =93auto-scaling=94 should be = deprecating and an attribute with a unique name (e.g., = =93auto-scale-mode=94) should replace it with the semantics defined for = =93print-scaling=94 FWIW, CUPS previously supported two other attributes for scaling in the = past - "scaling" (scale to a percentage of the media size) and = "natural-scaling" (scale to a percentage of the document size). This = allowed for "poster" printing over multiple media sheets, among other = things, but had a lot of limitations and implementation issues. (BTW, = we only ever supported symmetric scaling: scaling-width =3D=3D = scaling-height) I *can* see the use case for copy - copy this hardcopy document and = enlarge to 200% - but for print the 99% use case is "enlarge this = document/image to fit/fill these (media) dimensions". In many cases = there are no (reliable) physical dimensions to work with, so saying = "enlarge to 200%" has no meaning. However, you can always say "fit/fill = the document data on the requested media". Also, the current Scaling group in SM is not part of the Print service, = just under the Copy, FaxIn, FaxOut, and Scan services (under = DocumentProcessing). My preference is to reject this request. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_vV+yP8XrFd24rvNEqEUb/A) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel,

Thank you for the = additional comments. My initial responses are inline below, but as = a general comment I think we don't need to mirror every IPP attribute in = the SM - some things are a side-effect of the protocol or of targeting = specific markets/use cases.

On = Aug 30, 2013, at 12:57 PM, Manchala, Daniel <Daniel.Manchala@xerox.com>= ; wrote:

Some additional comments from = Xerox:

IPP Attributes should be document format = independent. Existing semantics should be used when they exist or = corrected when additional semantics are required.
1) =93jpeg-k-octets-supported=94 should be dropped in favor = of the existing =93k-octets-supported=94.
a. Note that IPP attribute coloring can be used to obtain = document format specific values when required.

In actual = implementation, the existing attribute (with multiple queries) was too = inefficient. This attribute has been widely implemented in IPP = printers since 2010.

My preference is to reject = this request.

2) =93pdf-k-octets-supported=94 should be dropped in favor = of the existing = =93k-octets-supported=94.

In actual implementation, the existing attribute (with multiple = queries) was too inefficient. This attribute has been widely = implemented in IPP printers since 2010.

My = preference is to reject this = request.

(For reference, a Client = might need to determine supported file formats and sizes in order to = determine which format to send to the Printer. And certain file = formats such as PWG Raster generally are streamed on both the Client and = Printer so the job-k-octets-supported value is MAX vs. some smaller = value for PDF or JPEG)

3) =93pdf-versions-supported=94 should be dropped in favor = of the existing =93document-format-details-supported=94 = (=93document-format=94 and =93document-format-version=94 = members).

"document= -format-version" is localized text, "document-format-details-supported" = is a list of member attributes supported by the = "document-format-details" attribute, and = "document-format-version-supported" is a list of all of the localized = version strings that are supported for all formats that is optionally = filtered by document-format when you do a Get-Printer-Attributes = request.

Since there is no way to register = localized text values, filtering those values with multiple = Get-Printer-Attributes requests is inefficient, and this attribute is = supported by most IPP+PDF printers since 2010, my preference is to = reject this request.

4) =93jpeg-x-dimension-supported=94 and = =93jpeg-y-dimension-supported=94 should apply to any image format. = The names should be changed to =93max-image-x-dimension-supported=94 and =93max-image = -x-dimension-supported=94.

These attributes have been widely implemented since 2010. And = as I've noted before doing multiple Get-Printer-Attributes requests is = really inefficient.

My preference is to = reject this request.

5) =93printer-dns-sd-name=94 should be applicable to any = service. The name should be changed to = =93dns-sd-name=94.

= With a few exceptions, we prefix all Printer Description attributes that = are not associated with Job/Document Template attributes with = "printer-". And since DNS-SD is a *service* discovery protocol, = not a device discovery protocol, I don't think dropping the "printer-" = prefix or using an alternate prefix like "device-" makes sense. = And FWIW CUPS has implemented "printer-dns-sd-name" for a very = long time (since CUPS 1.2/2005 IIRC).

Scaling should not be print = specific.

IPP =3D = Internet Printing Protocol, so we are necessarily focused on printing. = And as has been done in the past, SM can (and probably should) map = print-scaling to ScalingMode (or whatever), just as print-quality is = mapped to Quality, printer-resolution =3D> Resolution, = etc.

The PWG Semantic Model already defined a collection for = scaling (i.e., =93scaling=94). Apparently we didn=92t quite get it right. The current definition = allows for explicit scaling (i.e., =93scaling-height=94 and = =93scaling-width=94) or a boolean for =93auto-scaling=94. The = explicit scaling member should be kept. The Boolean =93auto-scaling=94= should be deprecating and an attribute with a unique name (e.g., =93auto-scale-mode=94) = should replace it with the semantics defined for =93print-scaling=94

FWIW, CUPS previously = supported two other attributes for scaling in the past - "scaling" = (scale to a percentage of the media size) and "natural-scaling" (scale = to a percentage of the document size). This allowed for "poster" = printing over multiple media sheets, among other things, but had a lot = of limitations and implementation issues. (BTW, we only ever = supported symmetric scaling: scaling-width =3D=3D = scaling-height)

I *can* see the use case for = copy - copy this hardcopy document and enlarge to 200% - but for print = the 99% use case is "enlarge this document/image to fit/fill these = (media) dimensions". In many cases there are no (reliable) = physical dimensions to work with, so saying "enlarge to 200%" has no = meaning. However, you can always say "fit/fill the document data = on the requested media".

Also, the current = Scaling group in SM is not part of the Print service, just under the = Copy, FaxIn, FaxOut, and Scan services (under = <service>DocumentProcessing).

My = preference is to reject this = request.

_________________________________________________________

Michael Sweet, Senior Printing = System Engineer, PWG Chair

= --Boundary_(ID_vV+yP8XrFd24rvNEqEUb/A)-- --===============0605968804== 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 --===============0605968804==-- From ipp-bounces@pwg.org Thu Sep 5 15:06:38 2013 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 AE0DC21E8167 for ; Thu, 5 Sep 2013 15:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjpgBH-cxpAz for ; Thu, 5 Sep 2013 15:06:31 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id B6ECB21E8165 for ; Thu, 5 Sep 2013 15:06:24 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 289488661; Thu, 5 Sep 2013 22:13:12 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by www.pwg.org (Postfix) with ESMTPS id 3DAE48660 for ; Thu, 5 Sep 2013 22:13:10 +0000 (UTC) Received: from BY2PR03MB144.namprd03.prod.outlook.com (10.242.35.150) by BY2PR03MB141.namprd03.prod.outlook.com (10.242.35.143) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 5 Sep 2013 22:06:07 +0000 Received: from BY2PR03MB144.namprd03.prod.outlook.com ([169.254.5.104]) by BY2PR03MB144.namprd03.prod.outlook.com ([169.254.5.144]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 22:06:06 +0000 From: Justin Hutchings To: "'ipp@pwg.org'" , Ira McDonald , "ptykodi@tykodi.com" , Michael R Sweet Thread-Topic: Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments Thread-Index: Ac6qgbD6vgakgWL6Q4qUkQLdrNTLQw== Date: Thu, 5 Sep 2013 22:06:06 +0000 Message-ID: <82f142d2fc6a4ed280bb5bc97492e6e1@BY2PR03MB144.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(41574002)(189002)(199002)(19580395003)(74366001)(74662001)(80022001)(83322001)(69226001)(76796001)(76576001)(65816001)(51856001)(76786001)(81342001)(47736001)(47976001)(81542001)(81686001)(76176001)(46102001)(50986001)(81816001)(4396001)(49866001)(31966008)(47446002)(551934002)(74502001)(74706001)(15975445006)(74316001)(80976001)(74876001)(63696002)(16236675002)(77096001)(76482001)(56816003)(15202345003)(54316002)(83072001)(19300405004)(59766001)(54356001)(77982001)(53806001)(56776001)(79102001)(33646001)(24736002)(3826001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB141; H:BY2PR03MB144.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; RD:InfoNoRecords; MX:1; A:1; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2100740547==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============2100740547== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_82f142d2fc6a4ed280bb5bc97492e6e1BY2PR03MB144namprd03pro_" --_000_82f142d2fc6a4ed280bb5bc97492e6e1BY2PR03MB144namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable - OpenXPS has a MIME type of application/oxps, not application/Ope= nXPS (http://www.iana.org/assignments/media-types/application/oxps) - This spec appears to have a bunch of content which is completely= unrelated to the transaction based printing. Why are we throwing these int= o what would otherwise be a very straightforward, to-the-point spec? o Print-scaling-supported o Print-scaling-default o Printer-dns-sd-name o Printer-kind o Jpeg-* o Pdf-* Thanks! Justin --_000_82f142d2fc6a4ed280bb5bc97492e6e1BY2PR03MB144namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

- &= nbsp; OpenXPS has a MIME type of application/oxps, not ap= plication/OpenXPS (http://www.iana.org/assignments/media-types/application/ox= ps)

- &= nbsp; This spec appears to have a bunch of content which = is completely unrelated to the transaction based printing. Why are we throw= ing these into what would otherwise be a very straightforward, to-the-point= spec?

o Print-scaling-supported

o Print-scaling-default

o Printer-dns-sd-name

o Printer-kind

o Jpeg-*

o Pdf-*

Thanks!

Justin

--_000_82f142d2fc6a4ed280bb5bc97492e6e1BY2PR03MB144namprd03pro_-- --===============2100740547== 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 --===============2100740547==-- From ipp-bounces@pwg.org Fri Sep 6 07:00:04 2013 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 0141C11E82AA for ; Fri, 6 Sep 2013 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=-1.847, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxmRjmjvxvAf for ; Fri, 6 Sep 2013 06:59:58 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 10DDE11E825E for ; Fri, 6 Sep 2013 06:59:57 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 3B891879B; Fri, 6 Sep 2013 14:06:46 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id A1AD6879A for ; Fri, 6 Sep 2013 14:06:44 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSP00D2XIVI77Z0@mail-out.apple.com> for ipp@pwg.org; Fri, 06 Sep 2013 06:59:52 -0700 (PDT) X-AuditID: 11807158-b7fea6d000001e19-15-5229dfd5ce62 Received: from [17.153.54.109] (Unknown_Domain [17.153.54.109]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 49.8F.07705.6DFD9225; Fri, 06 Sep 2013 06:59:52 -0700 (PDT) From: Michael Sweet In-reply-to: <82f142d2fc6a4ed280bb5bc97492e6e1@BY2PR03MB144.namprd03.prod.outlook.com> Date: Fri, 06 Sep 2013 09:59:51 -0400 Message-id: References: <82f142d2fc6a4ed280bb5bc97492e6e1@BY2PR03MB144.namprd03.prod.outlook.com> To: Justin Hutchings X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiONMsV/fGfc0ggxl9nBavXy1ltzi27yWL xbXH6hZHvsVadH6zdmD12HryB5vHzll32T1ad/xl95i3eDqTx+Yrz1kCWKO4bFJSczLLUov0 7RK4Mt5dm8hWsDOj4vuf5YwNjFNiuhg5OSQETCSOPT7CDGGLSVy4t54NxBYS6GWSODTHE8QW FiiT6Fu2igXE5hXQk/h4bTkjiM0skCCxY20nE4jNJqAm8XtSHyuIzSkQJvFu4xSwehYBFYnF x78D1XMA1edKTD1XATHGRmLK63YWiFWhEj+2XQezRQS0JSY+3c4OcY6sxNnJE1knMPLNQrJ5 FpLNELa2xLKFr5lngW3QkZi8kBFVGML+eP4I0wJGtlWMAkWpOYmVpnqJBQU5qXrJ+bmbGEFB 3VAYsYPx/zKrQ4wCHIxKPLw3bmgGCbEmlhVX5h5ilOBgVhLhNdsPFOJNSaysSi3Kjy8qzUkt PsQozcGiJM47mx8oJZCeWJKanZpakFoEk2Xi4JRqYFRZYnToCYvEIcHDL6QstA+lNzx4kl/E sjPP8lhJYLDI7A5meaXt6n95LV8dnRRzzWnW/BdtFw5vE3fq3GKa2PmCtaxw6ooZUc0nVALf qTbqfE7KVa6ePZlFauEE9S+bpzFnNB97vUei42tQuLpvu2b4sRQfh/OiMuyPnwkaVpucP/7V wXv2ESWW4oxEQy3mouJEANoYTK9mAgAA Cc: "ipp@pwg.org" Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1365229137==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1365229137== Content-type: multipart/alternative; boundary="Boundary_(ID_OlyqAmzCsw1yuAxPPzyujg)" --Boundary_(ID_OlyqAmzCsw1yuAxPPzyujg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Justin, Thank you for your feedback! Quick comments inline... On Sep 5, 2013, at 6:06 PM, Justin Hutchings wrote: > - OpenXPS has a MIME type of application/oxps, not application/OpenXPS (http://www.iana.org/assignments/media-types/application/oxps) Oops, will fix. > - This spec appears to have a bunch of content which is completely unrelated to the transaction based printing. Why are we throwing these into what would otherwise be a very straightforward, to-the-point spec? These have particular application to commercial print services and service discovery. > o Print-scaling-supported > o Print-scaling-default These provide control over the final imposition/scaling of the document data on the output media - important particularly for commercial print services. > o Printer-dns-sd-name This is used for service discovery; we need to have a way to configure the service name. > o Printer-kind This is used for service selection/filtering - again, if you are looking for a print service that supports the kind of document you are printing, you need this information. (this is also part of the DNS-SD TXT record, but DNS-SD is not the only way to do discovery) > o Jpeg-* > o Pdf-* These are used to inform the Client of limits for direct photo and PDF printing - having dealt with a lot of commercial print shops over the years, it is VERY important for the Client to be able to know whether they support a particular flavor of PDF or have limits in the maximum size/dimensions of print files. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_OlyqAmzCsw1yuAxPPzyujg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Justin,

Thank you for your = feedback! Quick comments inline...

On Sep = 5, 2013, at 6:06 PM, Justin Hutchings <justhu@microsoft.com> = wrote:

- OpenXPS has a MIME type of application/oxps, = not application/OpenXPS (http= ://www.iana.org/assignments/media-types/application/oxps)

Oops, will fix.

- This spec appears to have a bunch of content = which is completely unrelated to the transaction based printing. Why are = we throwing these into what would otherwise be a very straightforward, = to-the-point spec?

These have = particular application to commercial print services and service = discovery.

o = Print-scaling-supported
<= p class=3D"MsoListParagraph" = style=3D"margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2 lfo1"> o = Print-scaling-default

These provide control over the final = imposition/scaling of the document data on the output media - important = particularly for commercial print services.

o = Printer-dns-sd-name

This is used for service discovery; we need to = have a way to configure the service name.

o = Printer-kind

This is used for service selection/filtering - again, = if you are looking for a print service that supports the kind of = document you are printing, you need this = information.

(this is also part of the DNS-SD = TXT record, but DNS-SD is not the only way to do = discovery)

o Jpeg-*
o = Pdf-*

These are used to inform the Client of limits for = direct photo and PDF printing - having dealt with a lot of commercial = print shops over the years, it is VERY important for the Client to be = able to know whether they support a particular flavor of PDF or have = limits in the maximum size/dimensions of print files.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_OlyqAmzCsw1yuAxPPzyujg)-- --===============1365229137== 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 --===============1365229137==-- From ipp-bounces@pwg.org Fri Sep 6 09:53:20 2013 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 D4CBE11E82C3 for ; Fri, 6 Sep 2013 09:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBVC53EJi5RX for ; Fri, 6 Sep 2013 09:53:12 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 7130511E81A7 for ; Fri, 6 Sep 2013 09:53:12 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 3F4818661; Fri, 6 Sep 2013 17:00:04 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by www.pwg.org (Postfix) with ESMTPS id B88C7861F for ; Fri, 6 Sep 2013 17:00:02 +0000 (UTC) Received: from BY2PR03MB144.namprd03.prod.outlook.com (10.242.35.150) by BY2PR03MB141.namprd03.prod.outlook.com (10.242.35.143) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 6 Sep 2013 16:53:08 +0000 Received: from BY2PR03MB144.namprd03.prod.outlook.com ([169.254.5.104]) by BY2PR03MB144.namprd03.prod.outlook.com ([169.254.5.105]) with mapi id 15.00.0745.000; Fri, 6 Sep 2013 16:53:07 +0000 From: Justin Hutchings To: Michael Sweet Thread-Topic: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments Thread-Index: Ac6qgbD6vgakgWL6Q4qUkQLdrNTLQwAh6oGAAAX/jwA= Date: Fri, 6 Sep 2013 16:53:07 +0000 Message-ID: <71991fd9bae448f8817ab71e649b4641@BY2PR03MB144.namprd03.prod.outlook.com> References: <82f142d2fc6a4ed280bb5bc97492e6e1@BY2PR03MB144.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::4] x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(41574002)(189002)(199002)(377454003)(80022001)(15202345003)(551934002)(33646001)(65816001)(53806001)(81816001)(15975445006)(69226001)(74706001)(83072001)(31966008)(77096001)(80976001)(56816003)(47446002)(74876001)(74502001)(74662001)(19580395003)(19580405001)(74366001)(83322001)(81542001)(74316001)(47736001)(49866001)(4396001)(19300405004)(16236675002)(46102001)(50986001)(47976001)(51856001)(56776001)(54316002)(63696002)(81686001)(54356001)(76482001)(77982001)(59766001)(81342001)(76796001)(76576001)(79102001)(76786001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB141; H:BY2PR03MB144.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::4; RD:InfoNoRecords; MX:1; A:1; LANG:en; MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "ipp@pwg.org" Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1632474983==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1632474983== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_71991fd9bae448f8817ab71e649b4641BY2PR03MB144namprd03pro_" --_000_71991fd9bae448f8817ab71e649b4641BY2PR03MB144namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your quick response, Mike. It might be worthwhile to articulate = the rationale as to why these are required in the spec. I didn't pick up on= all that during my read through. Thanks! Justin From: Michael Sweet [mailto:msweet@apple.com] Sent: Friday, September 6, 2013 7:00 AM To: Justin Hutchings Cc: ipp@pwg.org; Ira McDonald; Paul Tykodi Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printin= g Extensions specification and has comments Justin, Thank you for your feedback! Quick comments inline... On Sep 5, 2013, at 6:06 PM, Justin Hutchings > wrote: - OpenXPS has a MIME type of application/oxps, not application/Ope= nXPS (http://www.iana.org/assignments/media-types/application/oxps) Oops, will fix. - This spec appears to have a bunch of content which is completely= unrelated to the transaction based printing. Why are we throwing these int= o what would otherwise be a very straightforward, to-the-point spec? These have particular application to commercial print services and service = discovery. o Print-scaling-supported o Print-scaling-default These provide control over the final imposition/scaling of the document dat= a on the output media - important particularly for commercial print service= s. o Printer-dns-sd-name This is used for service discovery; we need to have a way to configure the = service name. o Printer-kind This is used for service selection/filtering - again, if you are looking fo= r a print service that supports the kind of document you are printing, you = need this information. (this is also part of the DNS-SD TXT record, but DNS-SD is not the only way= to do discovery) o Jpeg-* o Pdf-* These are used to inform the Client of limits for direct photo and PDF prin= ting - having dealt with a lot of commercial print shops over the years, it= is VERY important for the Client to be able to know whether they support a= particular flavor of PDF or have limits in the maximum size/dimensions of = print files. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_71991fd9bae448f8817ab71e649b4641BY2PR03MB144namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your quick = response, Mike. It might be worthwhile to articulate the rationale as to wh= y these are required in the spec. I didn’t pick up on all that during= my read through.

Thanks!

Justin

From: Michael Sweet [mailto:msweet@apple.com]=
Sent: Friday, September 6, 2013 7:00 AM
To: Justin Hutchings
Cc: ipp@pwg.org; Ira McDonald; Paul Tykodi
Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based = Printing Extensions specification and has comments

Justin,<= /span>

Thank you for your feedback! Quick comments in= line...

On Sep 5, 2013, at 6:06 PM, Justin Hutchings <justhu@microsoft.com> wrote:

- &= nbsp; OpenXPS has a MIME type of application/oxps, not ap= plication/OpenXPS (http://www.iana.org/assignments/media-types/application/ox= ps)

Oops, will fix.

- &= nbsp; This spec appears to have a bunch of content which = is completely unrelated to the transaction based printing. Why are we throw= ing these into what would otherwise be a very straightforward, to-the-point= spec?

These have particular application to= commercial print services and service discovery.

o Print-scaling-supported

o Print-scaling-default

These provide control over the final= imposition/scaling of the document data on the output media - important pa= rticularly for commercial print services.

o Printer-dns-sd-name

This is used for service discovery; = we need to have a way to configure the service name.

o Printer-kind

This is used for service selection/f= iltering - again, if you are looking for a print service that supports the = kind of document you are printing, you need this information.

(this is also part of the DNS-SD TXT= record, but DNS-SD is not the only way to do discovery)<= /p>

o Jpeg-*

o Pdf-*

These are used to inform the Client = of limits for direct photo and PDF printing - having dealt with a lot of co= mmercial print shops over the years, it is VERY important for the Client to be able to know whether they support a particular flavor= of PDF or have limits in the maximum size/dimensions of print files.<= /o:p>

____________________________= _____________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--_000_71991fd9bae448f8817ab71e649b4641BY2PR03MB144namprd03pro_-- --===============1632474983== 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 --===============1632474983==-- From ipp-bounces@pwg.org Fri Sep 6 10:05:01 2013 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 1BFF021E80DD for ; Fri, 6 Sep 2013 10:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=-1.763, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Yv0-DtXfwH3 for ; Fri, 6 Sep 2013 10:04:56 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 2056B21E80DB for ; Fri, 6 Sep 2013 10:04:56 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 74C8B86D1; Fri, 6 Sep 2013 17:11:47 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 93D1386AA for ; Fri, 6 Sep 2013 17:11:46 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSP000AERFA6DF1@mail-out.apple.com> for ipp@pwg.org; Fri, 06 Sep 2013 10:04:28 -0700 (PDT) X-AuditID: 11807158-b7fea6d000001e19-0b-522a0b191800 Received: from [17.153.54.109] (Unknown_Domain [17.153.54.109]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 6B.F1.07705.A1B0A225; Fri, 06 Sep 2013 10:04:28 -0700 (PDT) From: Michael Sweet In-reply-to: <71991fd9bae448f8817ab71e649b4641@BY2PR03MB144.namprd03.prod.outlook.com> Date: Fri, 06 Sep 2013 13:04:32 -0400 Message-id: <64EBFA11-D91A-4631-AD91-7E62840C5509@apple.com> References: <82f142d2fc6a4ed280bb5bc97492e6e1@BY2PR03MB144.namprd03.prod.outlook.com> <71991fd9bae448f8817ab71e649b4641@BY2PR03MB144.namprd03.prod.outlook.com> To: Justin Hutchings X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUiONMsV1eGWyvI4FYjs8WxfS9ZLK49Vrc4 8i3Wgdlj68kfbB6tO/6ye8xbPJ0pgDmKyyYlNSezLLVI3y6BK6Pzx032gu3TGSsmf3zA2sD4 rJWxi5GTQ0LAROJp0ywmCFtM4sK99WxdjFwcQgK9TBL/Hs8BSwgLlEn0LVvFAmLzCuhJfLy2 HKyZWSBB4uSUSWA1bAJqEr8n9bGC2JwCYRJzlk8Gi7MIqEj869rADFEvL9Fw5wrUHBuJWadv sEMsu8AosfLFDnaQhIiAtsTEp9vZIS6SlTg7eSLrBEa+WUh2z0KyG8LWlli28DUzhG0g8bTz FSumuL7Em3dzmBYwsq1iFChKzUmsNNVLLCjISdVLzs/dxAgK3YbCiB2M/5dZHWIU4GBU4uG9 cUMzSIg1say4MvcQowQHs5II7xkGrSAh3pTEyqrUovz4otKc1OJDjNIcLErivLP5gaoF0hNL UrNTUwtSi2CyTBycUg2MR5+1H9G2sHDsmpTy99SiY1aNCzts5U7/k7p5pJr3rN4Xs7iQDatE tBykI9//f86145zOi5kXC7jiOxS/LSnu1H/ntSmsYcfCq1Pft36c+Vnu84G/Ihv3nxSb5jVh 4+6yvPPnvone+8b0Utfi3bkIr3sM6zfaC/UqvTLXSuF76u+oLSl1K/PofCWW4oxEQy3mouJE ANkUA0NZAgAA Cc: "ipp@pwg.org" Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1098536020==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1098536020== Content-type: multipart/alternative; boundary="Boundary_(ID_D3M0zsBRxYcrfPorVH8mQw)" --Boundary_(ID_D3M0zsBRxYcrfPorVH8mQw) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Justin, Fair enough, we do have use cases but will highlight for each of the = attributes. On Sep 6, 2013, at 12:53 PM, Justin Hutchings = wrote: > Thanks for your quick response, Mike. It might be worthwhile to = articulate the rationale as to why these are required in the spec. I = didn=92t pick up on all that during my read through. > =20 > Thanks! > Justin > =20 > From: Michael Sweet [mailto:msweet@apple.com]=20 > Sent: Friday, September 6, 2013 7:00 AM > To: Justin Hutchings > Cc: ipp@pwg.org; Ira McDonald; Paul Tykodi > Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based = Printing Extensions specification and has comments > =20 > Justin, > =20 > Thank you for your feedback! Quick comments inline... > =20 > On Sep 5, 2013, at 6:06 PM, Justin Hutchings = wrote: > - OpenXPS has a MIME type of application/oxps, not = application/OpenXPS = (http://www.iana.org/assignments/media-types/application/oxps) > =20 > Oops, will fix. >=20 >=20 > - This spec appears to have a bunch of content which is = completely unrelated to the transaction based printing. Why are we = throwing these into what would otherwise be a very straightforward, = to-the-point spec? > =20 > These have particular application to commercial print services and = service discovery. > =20 > o Print-scaling-supported > o Print-scaling-default > =20 > These provide control over the final imposition/scaling of the = document data on the output media - important particularly for = commercial print services. >=20 >=20 > o Printer-dns-sd-name > =20 > This is used for service discovery; we need to have a way to configure = the service name. >=20 >=20 > o Printer-kind > =20 > This is used for service selection/filtering - again, if you are = looking for a print service that supports the kind of document you are = printing, you need this information. > =20 > (this is also part of the DNS-SD TXT record, but DNS-SD is not the = only way to do discovery) >=20 >=20 > o Jpeg-* > o Pdf-* > =20 > These are used to inform the Client of limits for direct photo and PDF = printing - having dealt with a lot of commercial print shops over the = years, it is VERY important for the Client to be able to know whether = they support a particular flavor of PDF or have limits in the maximum = size/dimensions of print files. > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_D3M0zsBRxYcrfPorVH8mQw) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Justin,

Fair enough, we do = have use cases but will highlight for each of the = attributes.

On Sep 6, 2013, at = 12:53 PM, Justin Hutchings <justhu@microsoft.com> = wrote:

Thanks for your quick response, Mike. It might = be worthwhile to articulate the rationale as to why these are required = in the spec. I didn=92t pick up on all that during my read through.

Thanks!
Justin

From: Michael Sweet [mailto:msweet@apple.com]
Sent: Friday, September 6, 2013 7:00 AM
To: Justin Hutchings
Cc: ipp@pwg.org; Ira McDonald; = Paul Tykodi
Subject: Re: [IPP] Microsoft has reviewed the IPP = Transaction-Based Printing Extensions specification and has = comments

Justin,

Thank you for your feedback! Quick = comments inline...

On Sep 5, 2013, at 6:06 PM, Justin Hutchings = <justhu@microsoft.com> = wrote:

-          OpenXPS has a MIME type of application/oxps, = not application/OpenXPS (http= ://www.iana.org/assignments/media-types/application/oxps)

Oops, will fix.

-          This spec appears to have a bunch of content = which is completely unrelated to the transaction based printing. Why are = we throwing these into what would otherwise be a very straightforward, = to-the-point spec?

These have particular application to = commercial print services and service discovery.

o   = Print-scaling-supported
<= p class=3D"MsoListParagraph" = style=3D"margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2 lfo2"> o   Print-scaling-default

These provide control over the final = imposition/scaling of the document data on the output media - important = particularly for commercial print services.

o   Printer-dns-sd-name

This is used for service discovery; we = need to have a way to configure the service name.

o   Printer-kind

This is used for service = selection/filtering - again, if you are looking for a print service that = supports the kind of document you are printing, you need this = information.

(this is also part of the DNS-SD TXT = record, but DNS-SD is not the only way to do = discovery)

o   Jpeg-*
o   Pdf-*

These are used to inform the Client of = limits for direct photo and PDF printing - having dealt with a lot of = commercial print shops over the years, it is VERY important for the Client to be able to know whether they support a particular = flavor of PDF or have limits in the maximum size/dimensions of print = files.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG = Chair

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

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_D3M0zsBRxYcrfPorVH8mQw)-- --===============1098536020== 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 --===============1098536020==-- From ipp-bounces@pwg.org Sun Sep 8 17:01:28 2013 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 32C9221E805D for ; Sun, 8 Sep 2013 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9h9xN70Dw0b for ; Sun, 8 Sep 2013 17:01:24 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id EE77B21E8055 for ; Sun, 8 Sep 2013 17:01:23 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 1779F8533; Mon, 9 Sep 2013 00:08:25 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by www.pwg.org (Postfix) with ESMTPS id 1070F84FB for ; Mon, 9 Sep 2013 00:08:24 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k10so2914262iea.19 for ; Sun, 08 Sep 2013 17:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lm/Bm0YqAjGpBCOEHBzomMcOaWKfrqks8mTIDraI0OY=; b=VPttNbezn4APu0kGFwRTMws2QbOWCMa2N7pLZxyffBGUJCnYlD5vlqfllxn8BCmjBR VGVnLyTmrer2bweZMK8cjbJTkFwjd6G2IZ0CEF/KbwtGi3sMvxCVs8gdt9h27yIMIh5Z 8VwpE7g1OzVaIPwU+wwl2JU3bcNqu7zyd00/7PkkpDxZb5a90X1sISSdmX+SisDBKZAo 443M4Jhc/3sVi4jstdKgMIWAGchORvkPKhlQGuqh7q4OJXc4Y46nHcIzBVTdfnSMSFtW 2QkeG+lFK+OhDj7oV4sxW8OEXzmTCC6n8ginJKMHRoyPEszwv9MYybMBq5l2LspoC7zF keFQ== MIME-Version: 1.0 X-Received: by 10.50.20.99 with SMTP id m3mr6061665ige.54.1378684880580; Sun, 08 Sep 2013 17:01:20 -0700 (PDT) Received: by 10.50.96.135 with HTTP; Sun, 8 Sep 2013 17:01:20 -0700 (PDT) Date: Sun, 8 Sep 2013 20:01:20 -0400 Message-ID: From: Ira McDonald To: "ipp@pwg.org" , Ira McDonald Subject: [IPP] IPP Agenda - 3-5pm Eastern 9 September 2013 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075976429==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0075976429== Content-Type: multipart/alternative; boundary=047d7bd6b2b49077d804e5e81646 --047d7bd6b2b49077d804e5e81646 Content-Type: text/plain; charset=ISO-8859-1 Hi, Our next IPP WG call is this week Monday 9 September 12-2pm US Pacific / 3-5pm US Eastern 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) ------------------------------------------------------- Meeting information ------------------------------------------------------- Date: Every Monday, from Monday, July 9, 2012 to no end date Time: 12:00 pm, Pacific Daylight Time (San Francisco) Meeting Number: 624 587 312 Meeting Password: pwg123 ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://appleinc.webex.com/appleinc/j.php?ED=204995427&UID=504472682&PW=NNzM5MmRlMzBl&RT=MiM0 ------------------------------------------------------- Agenda: (1) PWG IP Policy and Minute Taker - Mike (2) Approve IPP minutes from previous meetings - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130819.pdf (3) Status of IPP Transaction-based Printing Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf - PWG Last Call ends on 13 September 2013 - discuss comments in responses so far (Apple, Xerox, Microsoft) (4) Status of IPP Fax Out (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130730-rev.pdf - PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments - reviewed at PWG F2F on 8 August 2013 - second WG/PWG last calls after changes are reviewed in the WG - job termination state (Pete & Ira favor "good news" rollup of job-state) - continue discussion of job termination state on mailing list (5) Status of IPP Self-Certification (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert10-20130731-rev.pdf - Updated ipptool and new ippfind - waiting for new draft from Mike (6) Status of IPP Implementor's Guide v2.0 (Smith) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20130722-rev.pdf - reviewed at PWG F2F on 6 August 2013 - waiting for new draft from Smith (7) Status of IPP Finishings v2.0 (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfinishings20-20130814.pdf - waiting for new draft from Mike (8) Review of IPP Shared Infrastructure Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130730-rev.pdf - align operations w/ Cloud WG session at PWG F2F (9) Next steps - IPP WG telecon on Monday 23 September - IPP WG telecon on Monday 7 October Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 --047d7bd6b2b49077d804e5e81646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Our next IPP WG call is this week Monday 9 September 12-2pm US Pacif= ic / 3-5pm US Eastern

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 A= ccess Code: *******#
Attendee ID Code: # (empty)

----------------= ---------------------------------------
Meeting information
----------------------------------------------------= ---
Date: Every Monday, from Monday, July 9, 2012 to no end date
Time: 12:00= pm, Pacific Daylight Time (San Francisco)
Meeting Number: 624 587 312Meeting Password: pwg123
---------------------------------------------= ----------
To start or join the online meeting
------------------------------------= -------------------
Go to https://appleinc.webex.com/appleinc/j.php?ED=3D20499= 5427&UID=3D504472682&PW=3DNNzM5MmRlMzBl&RT=3DMiM0
-------------------------------------------------------

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

(2) Approve IPP minut= es from previous meetings

- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-c= oncall-minutes-20130819.pdf

(3) Status of IPP= Transaction-based Printing Extensions (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pd= f

- PWG Last Call ends on 13 September 2013

- discuss comments = in responses so far (Apple, Xerox, Microsoft)

(4) Status of IPP Fax= Out (Mike)

- ftp://ftp.pwg.org/pub/pwg/i= pp/wd/wd-ippfaxout10-20130730-rev.pdf

- PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments=

- reviewed at PWG F2F on 8 August 2013

- secon= d WG/PWG last calls after changes are reviewed in the WG

- job termination state (Pete & Ira favor "good news" rollup = of job-state)

- continue discussion of job termination state = on mailing list

(5) Status of IPP Self-Certification= (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-i= ppeveselfcert10-20130731-rev.pdf

- Updated ipptool and new ippfind
- waiting for new draft fro= m Mike

(6) Status of IPP Implementor's Guide v2.0 (Smith)

- f= tp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20130722-rev.pdf

- reviewed at PWG F2F on 6 August 2013

- waiting for ne= w draft from Smith

(7) Status of IPP Finishings v2.0 (Mike)

- ftp:/= /ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfinishings20-20130814.pdf

- waiting for new draft from Mike

(8) Review of IPP Shared Infrastructure Extensions (Mike)

- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix1= 0-20130730-rev.pdf

- align operations w/ Cloud WG session at PWG F2F

=
(9) Next steps

- IPP WG telecon on Monday 23 September

- IPP WG telecon o= n Monday 7 October

Cheers,

- Ira

Ira McDonald (M= usician / Software Architect)
Chair - Linux Foundation Open Printing WG<= br>Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG = IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded System= s Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roo= f Music/High North Inc
http://sites.google.= com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

--047d7bd6b2b49077d804e5e81646-- --===============0075976429== 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 --===============0075976429==-- From ipp-bounces@pwg.org Mon Sep 9 13:54:13 2013 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 11CD021E816F for ; Mon, 9 Sep 2013 13:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngLqCjmrwEYM for ; Mon, 9 Sep 2013 13:54:05 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id D22CA11E8140 for ; Mon, 9 Sep 2013 13:54:02 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 6893984FB; Mon, 9 Sep 2013 21:01:08 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 301158476 for ; Mon, 9 Sep 2013 21:01:07 +0000 (UTC) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSV001IPM1K56V0@mail-out.apple.com> for ipp@pwg.org; Mon, 09 Sep 2013 13:53:56 -0700 (PDT) X-AuditID: 11807143-b7fce6d000001c8e-fe-522e356114a9 Received: from [17.153.18.31] (Unknown_Domain [17.153.18.31]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 51.A9.07310.3653E225; Mon, 09 Sep 2013 13:53:56 -0700 (PDT) From: Michael Sweet Date: Mon, 09 Sep 2013 16:54:47 -0400 To: ipp@pwg.org Message-id: X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiOFNIXjfFVC/I4KeAxbF9L1ksjnyLdWDy 2HryB5vHvMXTmQKYorhsUlJzMstSi/TtErgyfm1ey1jwULTi3Be+Bsa9wl2MnBwSAiYSd37P YIKwxSQu3FvP1sXIxSEk0M0k8evGP7AEm4CaxO9JfawgNrNAgsTcndcZQWwWARWJCQv6wGxh AWOJB9tawGwRAX6JiRch6nkFbCTm/H/JCGHrSXy8tpwRYpmsxNnJE1knMHLPQjJ2FpIyiLi8 xPa3c5hnMXIA2ToSkxdChbUlli18zQxjfzx/hGkBI9sqRoGi1JzESiO9xIKCnFS95PzcTYyg oGoodN7BeGyZ1SFGAQ5GJR7egGO6QUKsiWXFlbmHGCU4mJVEeDcw6wUJ8aYkVlalFuXHF5Xm pBYfYpTmYFES5z0npxUkJJCeWJKanZpakFoEk2Xi4JRqYIx//ojH9/fV144/pkyf9i83krXT 7c/WfKfa/V3evZuO7FvIJnttGatqWeSyWVXnVs98Zb3wgdnfQ7+21PQ/TK/z8/nZ0cEYGVfm eKA4SCGnWmEzZ+CFTUs7Sh6fj+NdEfL8magzV52SkJ77lBlcijPeLfr46mGcL1+I1LzI47me F5P4Xbl/tSuxFGckGmoxFxUnAgCQvt7IJgIAAA== Subject: [IPP] Minutes posted from today's IPP WG concall X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0260168660==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0260168660== Content-type: multipart/alternative; boundary="Boundary_(ID_m7paZ5VbMXbA8io4R8KN0g)" --Boundary_(ID_m7paZ5VbMXbA8io4R8KN0g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted the minutes from today's IPP WG conference call to: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130909.pdf Our next conference call is September 23, 2013 at 3pm ET. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_m7paZ5VbMXbA8io4R8KN0g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable All,

I have posted the minutes = from today's IPP WG conference call to:

ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-201309= 09.pdf

Our next conference call is = September 23, 2013 at 3pm ET.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_m7paZ5VbMXbA8io4R8KN0g)-- --===============0260168660== 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 --===============0260168660==-- From ipp-bounces@pwg.org Mon Sep 9 20:44:30 2013 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 D657C21E8083 for ; Mon, 9 Sep 2013 20:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAyrWoJu5kqX for ; Mon, 9 Sep 2013 20:44:25 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id F11B611E8147 for ; Mon, 9 Sep 2013 20:44:24 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id A5EF28430; Tue, 10 Sep 2013 03:51:31 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from USA7109MR004.ACS-INC.COM (usa7109mr004.acs-inc.com [63.101.151.13]) by www.pwg.org (Postfix) with ESMTPS id 79494831C for ; Tue, 10 Sep 2013 03:51:29 +0000 (UTC) Received: from usa7109ht002.na.xerox.net ([13.41.230.32]) by USA7109MR004.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 09 Sep 2013 22:44:20 -0500 Received: from USA7109MB013.na.xerox.net ([169.254.5.164]) by USA7109HT002.na.xerox.net ([13.41.230.32]) with mapi id 14.03.0123.003; Mon, 9 Sep 2013 22:44:20 -0500 From: "Manchala, Daniel" To: 'Michael Sweet' Thread-Topic: Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments Thread-Index: Ac6lQNZOZ1r4a0R7ShiXwdYJfcF+hwDh5W8AAUOiLOA= Date: Tue, 10 Sep 2013 03:44:19 +0000 Message-ID: References: <165688C8-527B-42F0-B3F8-EB211C63E13E@apple.com> In-Reply-To: <165688C8-527B-42F0-B3F8-EB211C63E13E@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "'ipp@pwg.org'" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1637567628==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1637567628== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E4503CD23822BF45A1EAEDA0BC5F107404CAAE42usa7109mb013nax_" --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAAE42usa7109mb013nax_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, Some more comments on IPP Transaction Based Printing Extensions: Section 8.1 job-state-reasons, it would be good to specify that 'account-au= thorization-failed' also means invalid job-accounting-user-id and/or 'job-a= ccount-id' were not valid. Right now it says: 'account-authorization-failed': The "job-authorization-uri" attribute was n= ot supplied the value supplied is not valid, or the value supplied has expired. The same is true for section 8.2 Status Codes. client-error-account-author= ization-failed (0x41F) should also refer to invalid job-accounting-user-id = and job-account-id were supplied. Right now it says: client-error-account-authorization-failed (0x41F); The print job creation r= equest is missing the "job-authorization-uri" operation attribute, the supplied value= is not valid, or the value supplied has expired. Xerox is ok with adding the keyword to "job-state-reason" =3D 'account-inf= o-conflicting' in Section 8.1 and 'client-error-conflicting-attributes' to = Section 8.2. Thanks, Daniel. From: Michael Sweet [mailto:msweet@apple.com] Sent: Tuesday, September 03, 2013 5:10 AM To: Manchala, Daniel Cc: ipp@pwg.org; Ira Mcdonald; Paul Tykodi Subject: Re: Xerox has reviewed the IPP Transaction-Based Printing Extensio= ns specification and has comments Daniel, Thank you for your comments. My initial responses are inline below... On Aug 30, 2013, at 1:27 AM, Manchala, Daniel > wrote: Xerox has reviewed the IPP Transaction-Based Printing Extensions specificat= ion and has the following comments. Xerox would like to add a new "job-state-reason" to section 8.1 "job-state-= reasons (1setOf type2 keyword)": "incompatible account-information". This = account ("job-account-id") is not associated with the user ("job-accounting= -user-id"). No objection, although we need a proper keyword value. 'account-info-confl= icting'? Likewise, add a new associated status-code to section 8.2 "client-error-acc= ount-information-incompatible" (or something of that nature). In this case I'd prefer to keep using client-error-conflicting-attributes a= nd have the printer return the job-account-id and job-accounting-user-id at= tributes in the unsupported attributes group. Add an attribute: "job-account-type (type2 keyword | name(MAX))" along with "job-account-type-supported(1setOf type2 keyword | 1setOf na= me(MAX))" and "job-account-type-default(type2 keyword | name(MAX))= ". The keywords initially can start with 'none', 'general', 'group= ' or 'visa-card', 'master-card', 'paypal','bit-coin', 'micro-mint', 'cash',= 'credit-account', etc., . The preference is to use keywords as it aids in = the internationalization. We've very specifically avoided currency or payment identifiers since a) ma= ny members, including Xerox, have indicated that payment processing is done= separately from the printer and b) we have no facility in IPP to express c= urrency values or other complex, fractional types. What would be the purpose of adding this when the printer-charge-info and p= rinter-charge-info-uri values provide localized resources that can be displ= ayed by the Client? Since the Client never has to have knowledge of how tra= nsactions are processed (just whether the printer needs transactional infor= mation), and since job-account-id will not (or at least SHOULD NOT) be a cr= edit card number or other direct payment identifier, I don't see the point = in telling the Client anything other than "I need a job-account-id from the= user." Add the conformance requirement in IPP: Transaction Based Printing, as an a= ddendum to PWG 5100.3-2001 IPP:Production Printing Attributes - Set 1, Sect= ion 7 as follows: If the Printer supports "job-accounting-user-id" then the Printer MUST supp= ort "job-account-id". No objection to adding this. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAAE42usa7109mb013nax_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

<= /p>

Some more comments on IPP= Transaction Based Printing Extensions:

<= /p>

Section 8.1 job-state-rea= sons, it would be good to specify that 'account-authorization-failed' also = means invalid job-accounting-user-id and/or 'job-account-id' were not valid. Right now it says:

R= 16;account-authorization-failed’: The “job-authorization-uri= 221; attribute was not supplied<= /span>

the = value supplied is not valid, or the value supplied has expired.

The same is true for sect= ion 8.2 Status Codes. client-error-account-authorization-failed (0x41= F) should also refer to invalid job-accounting-user-id and job-account-id were supplied. Right now it says:

clie= nt-error-account-authorization-failed (0x41F); The print job creation reque= st is

miss= ing the “job-authorization-uri” operation attribute, the suppli= ed value is not valid,

or t= he value supplied has expired.

<= /p>

Xerox is ok with adding t= he keyword to “job-state-reason” =3D ‘account-info-= conflicting’ in Section 8.1 and ‘client-error-conflicting-attri= butes’ to Section 8.2.

<= /p>

Thanks,=

Daniel.=

<= /p>

From: Michael = Sweet [mailto:msweet@apple.com]
Sent: Tuesday, September 03, 2013 5:10 AM
To: Manchala, Daniel
Cc: ipp@pwg.org; Ira Mcdonald; Paul Tykodi
Subject: Re: Xerox has reviewed the IPP Transaction-Based Printing E= xtensions specification and has comments

Daniel,

Thank you for your comments. My initial respon= ses are inline below...

On Aug 30, 2013, at 1:27 AM, Manchala, Daniel <Daniel.Manchala@xerox.com>= ; wrote:

Xerox has reviewed the IPP Transactio= n-Based Printing Extensions specification and has the following comments.
Xerox would like to add a new "job-state-reason" to section 8.1 “job-state-reasons (1setOf type2 k= eyword)”: “incompatible account-information”. This = account (“job-account-id”) is not associated with the user (“job-accounting-user-id”).

No objection, although we need a proper keyword valu= e. 'account-info-conflicting'?

Likewise, add a new ass= ociated status-code to section 8.2 "client-error-account-information-i= ncompatible" (or something of that nature).

In this case I'd prefer to keep using client-error-c= onflicting-attributes and have the printer return the job-account-id and jo= b-accounting-user-id attributes in the unsupported attributes group.

Add an attribute: ̶= 0;job-account-type (type2 keyword | name(MAX))<Job Template>” a= long with “job-account-type-supported(1setOf type2 keyword | 1setOf n= ame(MAX))<Printer>” and “job-account-type-default(type2 keyword | name(MAX))<Printer&= gt;”. The keywords initially can start with ‘none’, ̵= 6;general’, ‘group’ or ‘visa-card’, ‘ma= ster-card’, ‘paypal’,’bit-coin’, ‘micro= -mint’, ‘cash’, ‘credit-account’, etc., . The= preference is to use keywords as it aids in the internationalization. <= /o:p>

We've very specifically avoided currency or payment = identifiers since a) many members, including Xerox, have indicated that pay= ment processing is done separately from the printer and b) we have no facil= ity in IPP to express currency values or other complex, fractional types.

What would be the purpose of adding this when the pr= inter-charge-info and printer-charge-info-uri values provide localized reso= urces that can be displayed by the Client? Since the Client never has to ha= ve knowledge of how transactions are processed (just whether the printer needs transactional information), and = since job-account-id will not (or at least SHOULD NOT) be a credit card num= ber or other direct payment identifier, I don't see the point in telling th= e Client anything other than "I need a job-account-id from the user."

Add the conformance req= uirement in IPP: Transaction Based Printing, as an addendum to PWG 5100.3-2= 001 IPP:Production Printing Attributes – Set 1, Section 7 as follows:

If the Printer supports “job-ac= counting-user-id” then the Printer MUST support “job-account-id= ”.

No objection to adding this.

_____________________________________________= ____________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--_000_E4503CD23822BF45A1EAEDA0BC5F107404CAAE42usa7109mb013nax_-- --===============1637567628== 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 --===============1637567628==-- From SinaHachcky@gmx.com Tue Sep 10 05:05:36 2013 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 9C8BE21F8640 for ; Tue, 10 Sep 2013 05:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.656 X-Spam-Level: **** X-Spam-Status: No, score=4.656 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXhiGRtW1kB1 for ; Tue, 10 Sep 2013 05:05:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 68BDB21F8546 for ; Tue, 10 Sep 2013 05:05:26 -0700 (PDT) Received: from wjmb ([59.93.211.85]) by mail.gmx.com (mrgmx002) with ESMTPA (Nemesis) id 0MEFIm-1VCoAS3JbE-00FX5m for ; Tue, 10 Sep 2013 14:05:23 +0200 Message-ID: From: "Wilf" To: , , , , Subject: luxury watches Date: Tue, 10 Sep 2013 16:04:11 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FB3_01CEAE3F.63788AE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Provags-ID: V03:K0:+JnzDZ1cdxNhcGKmxzlws2VEG6iUw7x/IAt8md6NmZBd+g1A16e 5g8DAT8cLPRxrkn5Ts3M9x1Avc+7uItTA7erOAetkdoEc3OsL89gceLdFAyfkeDEy6TQIXs 9s+Q6CH6lA3gGsCK6rUiWrI4V7evNOR6sXE+tLajzMwIcqPjHoed6MT+NyYFPnQvITPlhSp wDYzdReQK+guc5WOo3dqQ== This is a multi-part message in MIME format. ------=_NextPart_000_0FB3_01CEAE3F.63788AE0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable luxury watches, ,bags on our website. discounts.- http://qps.ru/o6MmG ------=_NextPart_000_0FB3_01CEAE3F.63788AE0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

=20 luxury watches, ,bags on our website.=20 discounts.- http://qps.ru/Ulh4i

------=_NextPart_000_0FB3_01CEAE3F.63788AE0-- From s-uVkO7wvffnocI6oldI8XTvOdwXmwX7qlr7moUUql0CmwPVolu-9qrV@bounce.linkedin.com Tue Sep 10 05:38:48 2013 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 4B49B11E8117 for ; Tue, 10 Sep 2013 05:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.214 X-Spam-Level: X-Spam-Status: No, score=-13.214 tagged_above=-999 required=5 tests=[AWL=2.900, BAYES_00=-2.599, GB_I_INVITATION=-2, HABEAS_ACCREDITED_SOI=-4.3, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9pZujka-9RL for ; Tue, 10 Sep 2013 05:38:44 -0700 (PDT) Received: from maile-fd.linkedin.com (maile-fd.linkedin.com [199.101.162.92]) by ietfa.amsl.com (Postfix) with ESMTP id 627B711E8100 for ; Tue, 10 Sep 2013 05:38:44 -0700 (PDT) DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=prod; d=linkedin.com; h=DKIM-Signature:Sender:Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:X-LinkedIn-Template:X-LinkedIn-fbl; b=rQgMzkigqazRWKbLAU2f/3f2RTSplNJW8sVPcgrBBcuuYfzbZJX4jM3f/tjEOWL/ 2yLUCwv28zP5e8BptBs5m0b1VfyitPiT/D1eGqL2YrOeRx+IJ5wvaHsmirreiBI5 DKIM-Signature: v=1; a=rsa-sha1; d=linkedin.com; s=proddkim1024; c=relaxed/relaxed; q=dns/txt; i=@linkedin.com; t=1378816715; h=From:Subject:Date:To:MIME-Version:Content-Type:X-LinkedIn-fbl:X-LinkedIn-Template; bh=sJBvl9BcNGzYQJ2ciE/C8mEL8AI=; b=vTAUxKXlzVUEZb6RrcFyqG44ad+gbe/bkSnq4G9d0zMej2GoH7Pd/Dqo8HAgxnLW IaPEsCPZD3EJE1wiWPNhzUlwQ9gTJuj2ApM/onTnLb6volwMARejvZgoZ5UtZND/ BgxwfllLh7JC+y//aDQilwqCjRuOZgKpNvGns5vXUmY=; Sender: messages-noreply@bounce.linkedin.com Date: Tue, 10 Sep 2013 12:38:35 +0000 (UTC) From: "Tiffany Takashima (LinkedIn Invitations)" To: Message-ID: <1860831420.18275507.1378816715424.JavaMail.app@ela4-app3388.prod> Subject: Tiffany Takashima's invitation is awaiting your response MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18275505_1717918296.1378816715423" X-LinkedIn-Template: inv_exp_snackified_01 X-LinkedIn-fbl: s-uVkO7wvffnocI6oldI8XTvOdwXmwX7qlr7moUUql0CmwPVolu-9qrV ------=_Part_18275505_1717918296.1378816715423 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Tiffany Takashima would like to connect on LinkedIn. How would you like to respond? Tiffany Takashima Within 23 wards, Tokyo, Japan This is a reminder that on 8/28/13 12:44 AM, Tiffany Takashima sent you an invitation to become part of their professional network at LinkedIn. Reminder emails for pending invitations. © 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ------=_Part_18275505_1717918296.1378816715423 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Tiffany Takashima would like to connect on LinkedIn. How would you like to respond?

Tiffany Takashima

Confirm you know Tiffany

You are receiving Reminder emails for pending invitations. Unsubscribe.

------=_Part_18275505_1717918296.1378816715423-- From AngelikaPrinzlerfub@gmx.com Tue Sep 10 08:00:25 2013 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 5B77F21F93F8 for ; Tue, 10 Sep 2013 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD9c18Zsq1kt for ; Tue, 10 Sep 2013 08:00:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2221E812E for ; Tue, 10 Sep 2013 07:59:41 -0700 (PDT) Received: from tyaebjm ([92.47.229.107]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0M1RHp-1W7wYy3ZHt-00tVRe for ; Tue, 10 Sep 2013 16:59:28 +0200 Message-ID: <70BAB38EFDB14F70AE447C637FE44CED@cccsfcv> From: "Kurt" To: , , , , Subject: watches Date: Tue, 10 Sep 2013 18:59:00 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08DA_01CEAE57.CF263AE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Provags-ID: V03:K0:5uHjZteF0b1icC4hIJvylTWHK6xlyW7h5VAq3dWCEESbiyIAyp0 rcFSHtZI7g2V9nzeEz/GIhNkeWe5Tf/pn5LzjWIeKlhcdsoNSMgrxlEGWBagGeAT3RVE94r /nmkVIwj41OZxnu+xFMyUON19q25d2EIbClkTwxqK+SiYLxpGi800omxW36W/AWNelWdyea nzW+UrVKpFtUFx0F1q1ng== This is a multi-part message in MIME format. ------=_NextPart_000_08DA_01CEAE57.CF263AE0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable All, all- super- inexpensive. - http://qps.ru/nGJtg ------=_NextPart_000_08DA_01CEAE57.CF263AE0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

All, all-=20 super- inexpensive.=20 - http://qps.ru/BpSUu

------=_NextPart_000_08DA_01CEAE57.CF263AE0-- From pwg-announce-bounces@pwg.org Wed Sep 11 08:59:05 2013 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 498FE11E81A8 for ; Wed, 11 Sep 2013 08:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECN+BiuicmGt for ; Wed, 11 Sep 2013 08:59:00 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 0267D21F9FBC for ; Wed, 11 Sep 2013 08:58:56 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 32A7A8682; Wed, 11 Sep 2013 16:06:01 +0000 (UTC) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id 423CD8668 for ; Wed, 11 Sep 2013 16:06:00 +0000 (UTC) MIME-version: 1.0 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSY00AF9XMY8DC2@mail-out.apple.com> for pwg-announce@pwg.org; Wed, 11 Sep 2013 08:58:44 -0700 (PDT) X-AuditID: 11807153-b7fa56d000007d7a-4e-5230933323ee Received: from [17.153.18.148] (Unknown_Domain [17.153.18.148]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 27.AB.32122.43390325; Wed, 11 Sep 2013 08:58:45 -0700 (PDT) From: Michael Sweet Date: Wed, 11 Sep 2013 11:58:49 -0400 To: "PWG Announcements Inc." Message-id: X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLJMWRmVeSWpSXmKPExsUiOFNoiq7pZIMgg0U5Fke+xVqsa13N7MDk sfXkDzaPeYunMwUwRXHZpKTmZJalFunbJXBlzPwwibXgBnvF5kOzmRsYV7N1MXJySAiYSHSu O8QCYYtJXLi3HijOxSEk0MsksWDOXbAiNgE1id+T+lhBbGYBLYkb/14yQdjaEssWvmYGsVkE VCUaZ38CqxcWsJc4urKDHcQWETCW2NG+FyzOK2AjcXHmAUYIW0/i47XljBCLZSXOTp7IOoGR ZxaSFbOQrJiFpGUBI/MqRoGi1JzESmO9xIKCnFS95PzcTYygQGkoDN7B+GeZ1SFGAQ5GJR5e A0X9ICHWxLLiytxDjBIczEoivO0TDIKEeFMSK6tSi/Lji0pzUosPMUpzsCiJ81YYA1ULpCeW pGanphakFsFkmTg4pRoYY32zjq1/U3PYq2x5Dl/4+sn3+DepXv/utUBHWS9w9RrJ6Wt55cW5 tn0vUZ2UFiMes+bZoj+PRbQOLrVNUCqZECRSEJuScOIYm9zhG0vnqrPLyNT+nsD7fld363Gl sBe5L/Xlz+54czGjYDLfxX1Pzk+dvHuK3fRgX9Mu3/+vdk34Y7xQYdfkNUosxRmJhlrMRcWJ ANFat5YQAgAA Subject: [PWG-Announce] PWG October 2013 Face-to-Face Meeting in Cupertino, CA X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Printer Working Group announcement list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org All, The October 2013 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/october_2013_cupertino.html This page will be updated with document links as the material becomes available. Please visit the October 2013 survey page PRIOR TO October 18, 2013 and indicate whether you plan to participate in person or call in: http://www.surveymonkey.com/s/V8R9QND 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 _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce From s-vjEokZy1foQjMjdWJcMOVCEiGIchByqeF3EfqXMJfw-C4yIGwJ-rQJ@bounce.linkedin.com Thu Sep 12 02:03:23 2013 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 8142521E819C for ; Thu, 12 Sep 2013 02:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.707 X-Spam-Level: X-Spam-Status: No, score=-9.707 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, HABEAS_ACCREDITED_SOI=-4.3, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_UNI=0.591] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z009EEedllBK for ; Thu, 12 Sep 2013 02:03:19 -0700 (PDT) Received: from maile-ee.linkedin.com (maile-ee.linkedin.com [199.101.162.61]) by ietfa.amsl.com (Postfix) with ESMTP id A127421E8194 for ; Thu, 12 Sep 2013 02:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1378976589; bh=OGMQwH0ivQ23rlX4FD0Xfg1ymsCQyzXpu6PxqMSDjAg=; h=Date:From:To:Subject:MIME-Version:Content-Type: X-LinkedIn-Template:X-LinkedIn-Class:X-LinkedIn-fbl; b=AmhKx0DWGmIYReo+TI8oxrA59ntxhlg/uAQQUsfbGNLF8evc0yGlLCqdBUuLdTsXN g969X5Ji48hgfbE/ZAJK8vJkQZpfFNVuNIHmPmto3qw6GhblK2QE8MVPFIsbSfYPkt ryOLM5Buny9qXlYs5HjXy2/nDnilHyfKxIErwNNM= Sender: messages-noreply@bounce.linkedin.com Date: Thu, 12 Sep 2013 09:03:09 +0000 (UTC) From: Tiffany Takashima To: Message-ID: <236382493.55922642.1378976589466.JavaMail.app@ela4-app1201.prod> Subject: Invitation to connect on LinkedIn MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_55922640_869021082.1378976589464" X-LinkedIn-Template: invite_guest_59 X-LinkedIn-Class: INVITE-GUEST X-LinkedIn-fbl: s-vjEokZy1foQjMjdWJcMOVCEiGIchByqeF3EfqXMJfw-C4yIGwJ-rQJ ------=_Part_55922640_869021082.1378976589464 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Tiffany Tiffany Takashima Executive Recruitment Consultant at UCB K.K. Within 23 wards, Tokyo, Japan Confirm that you know Tiffany Takashima: https://www.linkedin.com/e/-w03wf5-hlhr226g-5o/isd/16105963957/rJ5nTqeO/?hs=false&tok=3ELtKATK8vIlU1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-w03wf5-hlhr226g-5o/lQNfPeTJnMvtCFKiQkZtKATD6Kiz2stWNF7BynQW/goo/ipp-archive%40lists%2Eietf%2Eorg/20061/I5486756541_1/?hs=false&tok=0KsUWeuOIvIlU1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ------=_Part_55922640_869021082.1378976589464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

From Tiffany Takashima

Executive Recruitment Consultant at UCB K.K.

Within 23 wards, Tokyo, Japan

I'd like to add you to my professional network on LinkedIn.

- Tiffany

Confirm that you know Tiffany

You are receiving Invitation to Connect emails. Unsubscribe

------=_Part_55922640_869021082.1378976589464-- From ipp-bounces@pwg.org Thu Sep 12 18:34:08 2013 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 D00AA11E822E for ; Thu, 12 Sep 2013 18:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by11qSLOyzps for ; Thu, 12 Sep 2013 18:34:03 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEF911E8131 for ; Thu, 12 Sep 2013 18:34:01 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 0F3C08405; Fri, 13 Sep 2013 01:41:21 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 76F72832A for ; Fri, 13 Sep 2013 01:41:19 +0000 (UTC) Received: from usa7109ht001.na.xerox.net ([13.41.230.31]) by USA7109MR003.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 12 Sep 2013 20:33:56 -0500 Received: from USA7109MB013.na.xerox.net ([169.254.5.164]) by USA7109HT001.na.xerox.net ([13.41.230.31]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 20:33:55 -0500 From: "Manchala, Daniel" To: 'Michael Sweet' Thread-Topic: Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments Thread-Index: Ac6lQNZOZ1r4a0R7ShiXwdYJfcF+hwDh5W8AAdUYOBA= Date: Fri, 13 Sep 2013 01:33:55 +0000 Message-ID: References: <165688C8-527B-42F0-B3F8-EB211C63E13E@apple.com> In-Reply-To: <165688C8-527B-42F0-B3F8-EB211C63E13E@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "'ipp@pwg.org'" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1171563314==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1171563314== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB86Busa7109mb013nax_" --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB86Busa7109mb013nax_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think I must have missed my point by including payment schemes (keywords = like 'visa' or 'paypal') into "job-account-type". It was my attempt to gene= ralize the scenario. Here is what I meant: Xerox has been using some accounting systems for seve= ral years that used "job-account-id" and a "job-account-group-id" or "job-a= ccount-general-id" to charge it to a specific group or a general account. T= he purpose of the request to add "job-account-type" by which a user can sel= ect or specify either 'general' or 'group' or 'none', for proper accounting= purposes. >>>>> Add an attribute: "job-account-type (type2 keyword | name(MAX))" along with "job-account-type-supported(1setOf type2 keyword | 1setOf na= me(MAX))" and "job-account-type-default(type2 keyword | name(MAX))= ". The keywords initially can start with 'none', 'general', 'group= ' or 'visa-card', 'master-card', 'paypal','bit-coin', 'micro-mint', 'cash',= 'credit-account', etc., . The preference is to use keywords as it aids in = the internationalization. We've very specifically avoided currency or payment identifiers since a) ma= ny members, including Xerox, have indicated that payment processing is done= separately from the printer and b) we have no facility in IPP to express c= urrency values or other complex, fractional types. What would be the purpose of adding this when the printer-charge-info and p= rinter-charge-info-uri values provide localized resources that can be displ= ayed by the Client? Since the Client never has to have knowledge of how tra= nsactions are processed (just whether the printer needs transactional infor= mation), and since job-account-id will not (or at least SHOULD NOT) be a cr= edit card number or other direct payment identifier, I don't see the point = in telling the Client anything other than "I need a job-account-id from the= user." --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB86Busa7109mb013nax_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think I must have mi= ssed my point by including payment schemes (keywords like ‘visa’= ; or ‘paypal’) into “job-account-type”. It was my a= ttempt to generalize the scenario.

Here is what I meant: = Xerox has been using some accounting systems for several years that used &#= 8220;job-account-id” and a “job-account-group-id” or R= 20;job-account-general-id” to charge it to a specific group or a gene= ral account. The purpose of the request to add “job-account-type” = by which a user can select or specify either ‘general’ or ̵= 6;group’ or ‘none’, for proper accounting purposes.

>>>>>

--_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB86Busa7109mb013nax_-- --===============1171563314== 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 --===============1171563314==-- From ipp-bounces@pwg.org Fri Sep 13 06:14:08 2013 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 ACF5921F9CE9 for ; Fri, 13 Sep 2013 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxcIkjhoEdBp for ; Fri, 13 Sep 2013 06:14:03 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 9809C11E81F0 for ; Fri, 13 Sep 2013 06:14:03 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 265858457; Fri, 13 Sep 2013 13:21:20 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by www.pwg.org (Postfix) with ESMTPS id DCA058430 for ; Fri, 13 Sep 2013 13:21:17 +0000 (UTC) Received: from mail-vc0-f179.google.com ([209.85.220.179]) (using TLSv1) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKUjMPkbujuuceBty9r8Ttv7smT8d+S1Hz@postini.com; Fri, 13 Sep 2013 06:13:54 PDT Received: by mail-vc0-f179.google.com with SMTP id ht10so884127vcb.24 for ; Fri, 13 Sep 2013 06:13:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=K1zoB8MyQRCDRP1jzzD2ikFvFPnypA1gwEW36+jb028=; b=W9L3+PzlBmtYJPm7532YUojjvmSMrBfiwrldNmWeLMwZ19jskV9a5rFsKdRH8VXFGU QXkaOK5AWp94OEqmX/x7qU86T/XZJLqd9OWTQFz6iwOE1NrpWIA2e6CwOzet4nLNHkHz 5eWiEo1QyCJwlKcfw9aeSmoUaYb+64/uxlabpH0ETyEW1NRdxBCnddBovt6o9xIXmfJd bgnkjaIp5UVJGNIskTobD0zDI/38HU6m86sSgWeuAwKTbdmCLjqROC79YEWnwFjk8IzW 9z1XHg+7M1hzlZVB+hb0+VPz2ZHLpT6lcJs+BKawzbka8DV1XBw6cZDPWJ21pKGDcVRI BTBg== X-Gm-Message-State: ALoCoQnXgIOlDxN8QM/tyQRTQRMnpAx/ZRMfO0ntW23OLWizVG083g8qsbvDzmFdyeuc0iWx+iHZe/fxO5oi+yPjEaREZ9qIznXLwZBQYPWotboQCxhfjTlrfe8FtrdvRMjOqF6A7Fm1 X-Received: by 10.58.152.3 with SMTP id uu3mr11917708veb.16.1379078033237; Fri, 13 Sep 2013 06:13:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.152.3 with SMTP id uu3mr11917698veb.16.1379078033165; Fri, 13 Sep 2013 06:13:53 -0700 (PDT) Received: by 10.52.162.194 with HTTP; Fri, 13 Sep 2013 06:13:53 -0700 (PDT) Date: Fri, 13 Sep 2013 09:13:53 -0400 Message-ID: From: Barry Cavill To: ipp@pwg.org, Ira McDonald , Michael Sweet , ptykodi@tykodi.com Cc: Jeremy Leber Subject: [IPP] Lexmark has reviewed the IPP Transaction-Based Printing Extensions specification and has one comment X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0515453638==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0515453638== Content-Type: multipart/alternative; boundary=047d7b86f53248e4a704e643a02b --047d7b86f53248e4a704e643a02b Content-Type: text/plain; charset=ISO-8859-1 "The actual methods of measurement and limit enforcement" are considered out-of-scope for the specification, which is fine. However, perhaps there should be a job-state-reason to indicate that the user's job is rejected for a measurement other than limit enforcement... for example, the user isn't authorized for color printing, or for printing on photo paper, or some similar scenario. -- Barry Cavill Lexmark International Phone (859) 232-5613 Bldg 082-2 bcavill@lexmark.com --047d7b86f53248e4a704e643a02b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

"The actual methods of measurement and limit enforcem= ent" are considered out-of-scope for the specification, which is fine. =A0 However, perhaps=20 there should be a job-state-reason to indicate that the user's job is= =20 rejected for a measurement other than limit enforcement... for example,=20 the user isn't authorized for color printing, or for printing on photo= =20 paper, or some similar scenario. =A0

--
Barry Cav= ill
Lexmark International
Phone (859) 232-5613=A0=A0=A0 Bldg 082-2=A0= =A0 bcavill@lexmar= k.com

--047d7b86f53248e4a704e643a02b-- --===============0515453638== 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 --===============0515453638==-- From pwg-announce-bounces@pwg.org Fri Sep 13 10:57:00 2013 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 1644921E80D1 for ; Fri, 13 Sep 2013 10:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TebOoYHik54D for ; Fri, 13 Sep 2013 10:56:55 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id CC62921E811A for ; Fri, 13 Sep 2013 10:56:54 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 5B6EB848E; Fri, 13 Sep 2013 18:04:16 +0000 (UTC) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by www.pwg.org (Postfix) with ESMTPS id 391DA8481 for ; Fri, 13 Sep 2013 18:04:14 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id u16so3176317iet.39 for ; Fri, 13 Sep 2013 10:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=3O7zxblfjwvcYnoQTNXUlpYGaRxfN7HyshutpodIg5U=; b=ZApyPrWzOcqj1XsnbgZ+QOJmTMZOrFdse2Byv7r3e/U8EgndnPo6/9NIRW/PZSLtyN th4QrzibFkzoxuVI4QBvOaJy4v+cJkrDMP0L1jFjnvCLcAeTy24BVxgmzDkbetk9iloB MVMA2qcDeFZ4zx99phhN39KIvi7VzTVlrtv4+Qi92NFdhb2Eby5m6xdtR0bwJ1VWouB3 RO44yYMbgDQlFVRgpngqMgCcwewwEtVALUN7BC9EN8PNRDkw8vrHMDLGJiTCvKNe8lOS UOM0kbeBr3OrbirG6QZMlv/P7TID60ABHoJBmMC3+LkBU7BdVMi6kzkWX+3A+8Bm/oep hAEg== X-Received: by 10.50.55.65 with SMTP id q1mr1786094igp.4.1379095009289; Fri, 13 Sep 2013 10:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.96.135 with HTTP; Fri, 13 Sep 2013 10:56:29 -0700 (PDT) From: Ira McDonald Date: Fri, 13 Sep 2013 13:56:29 -0400 Message-ID: To: Michael Sweet , Ira McDonald Cc: "PWG Announcements Inc." Subject: [PWG-Announce] ONE more ack needed today! - PWG Last Call of IPP Transaction-Based Printing Extensions (07/30/13 to 09/13/13) X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Printer Working Group announcement list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1627856610==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org --===============1627856610== Content-Type: multipart/alternative; boundary=047d7b10c80723eb3b04e64794e0 --047d7b10c80723eb3b04e64794e0 Content-Type: text/plain; charset=ISO-8859-1 Hi, We have had 8 acknowledgments of of the PWG Last Call for IPP Transaction-based Printing Extensions - ends today! We need ONE more acknowledgment (with or without comments) to achieve quorum and move forward to PWG Formal Vote. PLEASE send your acknowledgment today! Cheers, - Ira (co-chair of IPP WG) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Sep 3, 2013 at 7:57 AM, Michael Sweet wrote: > [THIS LAST CALL HAS BEEN EXTENDED UNTIL FRIDAY, SEPTEMBER 13, 2013. IF > YOU HAVE NOT ALREADY DONE SO, PLEASE REVIEW THE DOCUMENT LINKED BELOW AND > PROVIDE YOUR ACKNOWLEDGEMENT. THANK YOU!] > > > All, > > [This PWG Last Call starts today, Tuesday July 30, 2013, and ends Friday, > September 13, 2013 at 10pm US PST.] > > This is the formal announcement of the PWG Last Call for the IPP > Transaction-Based Printing Extensions specification, located at: > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf > > All required attributes and values defined in this document have been > prototyped by Apple and/or other vendors. The IPP WG has completed > extensive review of the various revisions of this document and an IPP WG > last call. > > The PWG Process/3.0 requires that a quorum (30%) of PWG 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. > > > HOW TO RESPOND > > Send an email with *exactly* the following subject line format: > Subject: has reviewed the IPP Transaction-Based Printing > Extensions specification and has [no] comments > > > WHERE TO SEND YOUR RESPONSE > > Please send your response to *all* of the following email addresses > (replacing "dot" with '.' and "at" with '@'): > > ipp "at" pwg "dot" org (IPP WG mailing list - you must be subscribed!) > blueroofmusic "at" gmail "dot" com (Ira McDonald, IPP WG Co-Chair) > ptykodi "at" tykodi "dot" com (Paul Tykodi, IPP WG Co-Chair) > msweet "at" apple "dot" com (Michael Sweet, IPP WG Secretary and IPP > Transaction-Based Printing Extensions Editor) > > Note that you must be subscribed to the IPP WG mailing list to send email > there - otherwise your email will be silently discarded. > > Please do NOT simply reply to this note on the PWG-Announce list. > > 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 > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > _______________________________________________ > pwg-announce mailing list > pwg-announce@pwg.org > https://www.pwg.org/mailman/listinfo/pwg-announce > > _______________________________________________ > pwg-announce mailing list > pwg-announce@pwg.org > https://www.pwg.org/mailman/listinfo/pwg-announce > > --047d7b10c80723eb3b04e64794e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

We have had= 8 acknowledgments of of the PWG Last Call for

IPP Transaction-bas= ed Printing Extensions - ends today!

We need ONE more acknowle= dgment (with or without comments)
to achieve quorum and move forward to PWG Formal Vote.

PLEASE = send your acknowledgment today!

Cheers,

- Ira (co-cha= ir of IPP WG)

Ira McDonald (Musician / Software Architect)
Chai= r - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Work= ing Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobi= lity Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP &a= mp; Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

On Tue, Sep 3, 2013 at 7:57 AM, Michael = Sweet <msweet@apple.com> wrote:

[THIS LAST CALL HAS BEEN EXTENDED = UNTIL FRIDAY, SEPTEMBER 13, 2013. =A0IF YOU HAVE NOT ALREADY DONE SO, PLEAS= E REVIEW THE DOCUMENT LINKED BELOW AND PROVIDE YOUR ACKNOWLEDGEMENT. =A0THA= NK YOU!]

All,

[This PWG Last Call s= tarts today, Tuesday July 30, 2013, and ends Friday, September 13, 2013 at = 10pm US PST.]

This is the formal announcement of t= he PWG Last Call for the IPP Transaction-Based Printing Extensions specific= ation, located at:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf
<= div>
All required attribute= s and values defined in this document have been prototyped by Apple and/or = other vendors. The IPP WG has completed extensive review of the various rev= isions of this document and an IPP WG last call.

T= he PWG Process/3.0 requires that a quorum (30%) of PWG members must acknowl= edge a PWG Last Call (with or without comments), before any document can pr= ogress to PWG Formal Vote. =A0This PWG Last Call is NOT a Formal Vote but i= t DOES require your review acknowledgment.

HOW TO RESPOND

Send an email with *exactly* the following subject line for= mat:
Subject: <Company Name> has rev= iewed the IPP Transaction-Based Printing Extensions specification and has [= no] comments

W= HERE TO SEND YOUR RESPONSE

Please = send your response to *all* of the following email addresses (replacing &qu= ot;dot" with '.' and "at" with '@'):<= br style=3D"font-family:monospace">
i= pp "at" pwg "dot" org (IPP WG mailing list - you must b= e subscribed!)
blueroofmusic "at" gmail "dot" com = (Ira McDonald, IPP WG Co-Chair)
ptykodi "at" tykodi "d= ot" com (Paul Tykodi, IPP WG Co-Chair)
msweet "at" appl= e "dot" com (Michael Sweet, IPP WG Secretary and IPP Transaction-= Based Printing Extensions Editor)

N= ote that you must be subscribed to the IPP WG mailing list to send email th= ere - otherwise your email will be silently discarded.

P= lease do NOT simply reply to this note on the PWG-Announce list.

Note: The PWG Definition of the Standards De= velopment Process Version 3.0 is located at:

h= ttp://www.pwg.org/chair/membership_docs/pwg-process30.pdf

_________________________________________________________
Michael Sweet,= Senior Printing System=A0Engineer, PWG Chair

_______________________________________________
pwg-announce m= ailing list
pw= g-announce@pwg.org
https://www.pwg.org/mailman/listinfo/pwg-ann= ounce

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

--047d7b10c80723eb3b04e64794e0-- --===============1627856610== 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 --===============1627856610==-- From ipp-bounces@pwg.org Fri Sep 13 11:23:31 2013 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 3EBA021F9D21 for ; Fri, 13 Sep 2013 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.925 X-Spam-Level: X-Spam-Status: No, score=0.925 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0d-yTwm7brN for ; Fri, 13 Sep 2013 11:23:26 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F821F84B6 for ; Fri, 13 Sep 2013 11:23:25 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id C020D848E; Fri, 13 Sep 2013 18:30:16 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from edge.dda.kyocera.com (edge.dda.kyocera.com [69.42.25.201]) by www.pwg.org (Postfix) with ESMTPS id EC1E28457 for ; Fri, 13 Sep 2013 18:30:15 +0000 (UTC) Received: from LISA.ktd.com (10.10.10.75) by edge.dda.kyocera.com (69.42.25.201) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 13 Sep 2013 11:24:54 -0700 Received: from LISA.ktd.com ([10.10.10.75]) by lisa ([10.10.10.75]) with mapi id 14.01.0438.000; Fri, 13 Sep 2013 11:22:38 -0700 From: Lida Wang To: "ipp@pwg.org" Thread-Topic: Kyocera Document Solution has reviewed the IPP Transaction-Based Printing Extensions specification and has no comments Thread-Index: Ac6wq9N0Pahgfb4FSG+jhbpbWHmQZwAAljdQ Date: Fri, 13 Sep 2013 18:22:37 +0000 Message-ID: <9E0A2C000B94894B8DCBA9E1354112DB27089C3D@lisa> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.18.226] MIME-Version: 1.0 Subject: [IPP] Kyocera Document Solution has reviewed the IPP Transaction-Based Printing Extensions specification and has no comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0996391696==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0996391696== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9E0A2C000B94894B8DCBA9E1354112DB27089C3Dlisa_" --_000_9E0A2C000B94894B8DCBA9E1354112DB27089C3Dlisa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Lida Wang Sent: Friday, September 13, 2013 11:06 AM To: 'Ira McDonald'; Michael Sweet Cc: PWG Announcements Inc. Subject: Kyocera Document Solution has reviewed the IPP Transaction-Based P= rinting Extensions specification and has no comments Ira, Kyocera Document Solution has reviewed the IPP Transaction-Based Printing = Extensions specification and has no comments. Regards, Lida From: pwg-announce-bounces@pwg.org [ma= ilto:pwg-announce-bounces@pwg.org] On Behalf Of Ira McDonald Sent: Friday, September 13, 2013 10:56 AM To: Michael Sweet; Ira McDonald Cc: PWG Announcements Inc. Subject: [PWG-Announce] ONE more ack needed today! - PWG Last Call of IPP T= ransaction-Based Printing Extensions (07/30/13 to 09/13/13) Hi, We have had 8 acknowledgments of of the PWG Last Call for IPP Transaction-based Printing Extensions - ends today! We need ONE more acknowledgment (with or without comments) to achieve quorum and move forward to PWG Formal Vote. PLEASE send your acknowledgment today! Cheers, - Ira (co-chair of IPP WG) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Sep 3, 2013 at 7:57 AM, Michael Sweet > wrote: [THIS LAST CALL HAS BEEN EXTENDED UNTIL FRIDAY, SEPTEMBER 13, 2013. IF YOU= HAVE NOT ALREADY DONE SO, PLEASE REVIEW THE DOCUMENT LINKED BELOW AND PROV= IDE YOUR ACKNOWLEDGEMENT. THANK YOU!] All, [This PWG Last Call starts today, Tuesday July 30, 2013, and ends Friday, S= eptember 13, 2013 at 10pm US PST.] This is the formal announcement of the PWG Last Call for the IPP Transactio= n-Based Printing Extensions specification, located at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf All required attributes and values defined in this document have been proto= typed by Apple and/or other vendors. The IPP WG has completed extensive rev= iew of the various revisions of this document and an IPP WG last call. The PWG Process/3.0 requires that a quorum (30%) of PWG members must acknow= ledge a PWG Last Call (with or without comments), before any document can p= rogress to PWG Formal Vote. This PWG Last Call is NOT a Formal Vote but it= DOES require your review acknowledgment. HOW TO RESPOND Send an email with *exactly* the following subject line format: Subject: has reviewed the IPP Transaction-Based Printing Ext= ensions specification and has [no] comments WHERE TO SEND YOUR RESPONSE Please send your response to *all* of the following email addresses (replac= ing "dot" with '.' and "at" with '@'): ipp "at" pwg "dot" org (IPP WG mailing list - you must be subscribed!) blueroofmusic "at" gmail "dot" com (Ira McDonald, IPP WG Co-Chair) ptykodi "at" tykodi "dot" com (Paul Tykodi, IPP WG Co-Chair) msweet "at" apple "dot" com (Michael Sweet, IPP WG Secretary and IPP Transa= ction-Based Printing Extensions Editor) Note that you must be subscribed to the IPP WG mailing list to send email t= here - otherwise your email will be silently discarded. Please do NOT simply reply to this note on the PWG-Announce list. Note: The PWG Definition of the Standards Development Process Version 3.0 i= s located at: http://www.pwg.org/chair/membership_docs/pwg-process30.pdf _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce _______________________________________________ pwg-announce mailing list pwg-announce@pwg.org https://www.pwg.org/mailman/listinfo/pwg-announce --_000_9E0A2C000B94894B8DCBA9E1354112DB27089C3Dlisa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= /p>

From: Lida Wan= g
Sent: Friday, September 13, 2013 11:06 AM
To: 'Ira McDonald'; Michael Sweet
Cc: PWG Announcements Inc.
Subject: Kyocera Document Solution has reviewed the IPP Transaction-= Based Printing Extensions specification and has no comments

Ira,

<= /p>

Kyocera Document Solution= has reviewed the IPP Transaction-Based Printing Extensions specifica= tion and has no comments.

<= /p>

Regards,

Lida

<= /p>

From: pwg-announce-bounces@pwg.or= g [mailto:pwg-announce-= bounces@pwg.org] On Behalf Of Ira McDonald
Sent: Friday, September 13, 2013 10:56 AM
To: Michael Sweet; Ira McDonald
Cc: PWG Announcements Inc.
Subject: [PWG-Announce] ONE more ack needed today! - PWG Last Call o= f IPP Transaction-Based Printing Extensions (07/30/13 to 09/13/13)

Hi,

We have had 8 acknowledgments of of the PWG Last Cal= l for

IPP Transaction-based= Printing Extensions - ends today!

We need ONE more ackn= owledgment (with or without comments)
to achieve quorum and move forward to PWG Formal Vote.

PLEASE send your ackn= owledgment today!

Cheers,

- Ira (co-chair of IP= P WG)

Ira McDonald (Musicia= n / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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:blueroo= fmusic@gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094=
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Tue, Sep 3, 2013 at 7:57 AM, Michael Sweet <msweet@apple.com>= ; wrote:

[THIS LAST CALL HAS BEEN EXTENDED UNTIL FRIDAY, SEPT= EMBER 13, 2013. IF YOU HAVE NOT ALREADY DONE SO, PLEASE REVIEW THE DO= CUMENT LINKED BELOW AND PROVIDE YOUR ACKNOWLEDGEMENT. THANK YOU!]

All,

[This PWG Last Call starts today, Tuesday July 30, 2= 013, and ends Friday, September 13, 2013 at 10pm US PST.]

This is the formal announcement of the PWG Last Call= for the IPP Transaction-Based Printing Extensions specification, located a= t:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-i= pptrans10-20130708.pdf

= All required attributes and values defined in this document have been proto= typed by Apple and/or other vendors. The IPP WG has completed extensive rev= iew of the various revisions of this document and an IPP WG last call.

The PWG Process/3.0 requires that a quorum (30%) of PWG members must acknow= ledge a PWG Last Call (with or without comments), before any document can p= rogress to PWG Formal Vote. This PWG Last Call is NOT a Formal Vote b= ut it DOES require your review acknowledgment.

HOW TO RESPOND

Send an email with *exactly* the following subject line format:
Subject: <Company Name> has reviewed the IPP Transaction-Based Printi= ng Extensions specification and has [no] comments

WHERE TO SEND YOUR RESPONSE

Please send your response to *all* of the following email addresses (replac= ing "dot" with '.' and "at" with '@'):

ipp "at" pwg "dot" org (IPP WG mailing list - you must = be subscribed!)
blueroofmusic "at" gmail "dot" com (Ira McDonald, IPP W= G Co-Chair)
ptykodi "at" tykodi "dot" com (Paul Tykodi, IPP WG Co-C= hair)
msweet "at" apple "dot" com (Michael Sweet, IPP WG Secr= etary and IPP Transaction-Based Printing Extensions Editor)

Note that you must be subscribed to the IPP WG mailing list to send email t= here - otherwise your email will be silently discarded.

Please do NOT simply reply to this note on the PWG-Announce list.

Note: The PWG Definition of the Standards Development Process Version 3.0 i= s located at:

ht= tp://www.pwg.org/chair/membership_docs/pwg-process30.pdf

_________________________________________________________=
Michael Sweet, Senior Printing System Engineer, PWG Chair

_______________________________________________
pwg-announce mailing list
pwg-announce@pwg.= org
https://www.pwg.org/mailman/listinfo/pwg-announce

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

--_000_9E0A2C000B94894B8DCBA9E1354112DB27089C3Dlisa_-- --===============0996391696== 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 --===============0996391696==-- From ipp-bounces@pwg.org Fri Sep 13 13:46:11 2013 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 9A4E811E80D3 for ; Fri, 13 Sep 2013 13:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiUygKSjTRYA for ; Fri, 13 Sep 2013 13:46:06 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE2521E80E6 for ; Fri, 13 Sep 2013 13:46:06 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 1F08E848E; Fri, 13 Sep 2013 20:53:29 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 2CB5D8481; Fri, 13 Sep 2013 20:53:27 +0000 (UTC) Received: from usa7109ht001.na.xerox.net ([13.41.230.31]) by USA7109MR001.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 13 Sep 2013 15:46:00 -0500 Received: from USA7109MB013.na.xerox.net ([169.254.5.164]) by USA7109HT001.na.xerox.net ([13.41.230.31]) with mapi id 14.03.0123.003; Fri, 13 Sep 2013 15:46:00 -0500 From: "Manchala, Daniel" To: 'Michael Sweet' Thread-Topic: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments Thread-Index: Ac6lQNZOZ1r4a0R7ShiXwdYJfcF+hwAYPDjVAMtU4QAB/Jx4cA== Date: Fri, 13 Sep 2013 20:45:59 +0000 Message-ID: References: <469D5BFC-3F06-4587-8F9C-0208CDD9DB1F@apple.com> In-Reply-To: <469D5BFC-3F06-4587-8F9C-0208CDD9DB1F@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "'ipp@pwg.org'" , "'sm3@pwg.org'" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682682617==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1682682617== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB94Eusa7109mb013nax_" --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB94Eusa7109mb013nax_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, The Semantic Model defines Scaling thus: Scaling (complex) { ScalingHeight (range of int) ScalingWeight (range of int) AutoScaleMode (keyword) //values of 'auto, 'fit', 'auto-fit= ', 'fill' and 'none'; SM to change replace boolean with keyword. } Why don't we translate this into IPP as follows?: print-scaling(collection) { scaling-height(integer(1:100)) //expressed as a percentage. scaling-width(integer(1:100)) auto-scale-mode(type2 keyword) //values of 'auto', 'auto-fi= t', 'fit', 'fill' and 'none' } Thanks, Daniel. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Scaling should not be print specific. IPP =3D Internet Printing Protocol, so we are necessarily focused on printi= ng. And as has been done in the past, SM can (and probably should) map prin= t-scaling to ScalingMode (or whatever), just as print-quality is mapped to = Quality, printer-resolution =3D> Resolution, etc. The PWG Semantic Model already defined a collection for scaling (i.e., "sca= ling"). Apparently we didn't quite get it right. The current definition al= lows for explicit scaling (i.e., "scaling-height" and "scaling-width") or a= boolean for "auto-scaling". The explicit scaling member should be kept. = The Boolean "auto-scaling" should be deprecating and an attribute with a un= ique name (e.g., "auto-scale-mode") should replace it with the semantics de= fined for "print-scaling" FWIW, CUPS previously supported two other attributes for scaling in the pas= t - "scaling" (scale to a percentage of the media size) and "natural-scalin= g" (scale to a percentage of the document size). This allowed for "poster"= printing over multiple media sheets, among other things, but had a lot of = limitations and implementation issues. (BTW, we only ever supported symmet= ric scaling: scaling-width =3D=3D scaling-height) I *can* see the use case for copy - copy this hardcopy document and enlarge= to 200% - but for print the 99% use case is "enlarge this document/image t= o fit/fill these (media) dimensions". In many cases there are no (reliabl= e) physical dimensions to work with, so saying "enlarge to 200%" has no mea= ning. However, you can always say "fit/fill the document data on the reque= sted media". Also, the current Scaling group in SM is not part of the Print service, jus= t under the Copy, FaxIn, FaxOut, and Scan services (under Document= Processing). My preference is to reject this request. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB94Eusa7109mb013nax_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

The Semantic Model def= ines Scaling thus:

Scaling (complex) {<= /o:p>

&= nbsp; ScalingHe= ight (range of int)

&= nbsp; ScalingWe= ight (range of int)

&= nbsp; AutoScale= Mode (keyword) //v= alues of ‘auto, ‘fit’, ‘auto-fit’, ‘fil= l’ and ‘none’; SM to change replace= boolean with keyword.

&= nbsp; }

<= /p>

Why don’t we transl= ate this into IPP as follows?:

<= /p>

print-scaling(collection)= {

&= nbsp; scaling-h= eight(integer(1:100)) //expressed as a percentage.

&= nbsp; scaling-w= idth(integer(1:100))

&= nbsp; auto-scal= e-mode(type2 keyword) //values of ‘auto’, ‘auto-fit’= ;, ‘fit’, ‘fill’ and ‘none’<= /span>

&= nbsp; }

Thanks,

Daniel.

>>>>>&g= t;>>>>>>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>>= ;>>>>>>>>>>>>

Scaling should not be print specific.

IPP =3D Internet Printing Protocol, so we are necess= arily focused on printing. And as has been done in the past, SM can (and pr= obably should) map print-scaling to ScalingMode (or whatever), just as prin= t-quality is mapped to Quality, printer-resolution =3D> Resolution, etc.

The PWG Semantic Model already defined a collection for scaling= (i.e., “scaling”). Apparently we didn’t quite get it rig= ht. The current definition allows for explicit scaling (i.e., “scaling-h= eight” and “scaling-width”) or a boolean for “auto-= scaling”. The explicit scaling member should be kept. The= Boolean “auto-scaling” should be deprecating and an attribute = with a unique name (e.g., “auto-scale-mode”) should replace it with the semantics= defined for “print-scaling”

FWIW, CUPS previously supported two other attributes= for scaling in the past - "scaling" (scale to a percentage of th= e media size) and "natural-scaling" (scale to a percentage of the= document size). This allowed for "poster" printing over multiple media sheets, among other things, but had a lot of limitations an= d implementation issues. (BTW, we only ever supported symmetric scali= ng: scaling-width =3D=3D scaling-height)

I *can* see the use case for copy - copy this hardco= py document and enlarge to 200% - but for print the 99% use case is "e= nlarge this document/image to fit/fill these (media) dimensions". &nbs= p; In many cases there are no (reliable) physical dimensions to work with, so saying "enlarge to 200%" has no mean= ing. However, you can always say "fit/fill the document data on = the requested media".

Also, the current Scaling group in SM is not part of= the Print service, just under the Copy, FaxIn, FaxOut, and Scan services (= under <service>DocumentProcessing).

My preference is to reject this request.<= /p>

_________________________________________________________=

Michael Sweet, Senior Printing System En= gineer, PWG Chair

--_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB94Eusa7109mb013nax_-- --===============1682682617== 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 --===============1682682617==-- From ipp-bounces@pwg.org Fri Sep 13 16:34:28 2013 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 58A6211E8149 for ; Fri, 13 Sep 2013 16:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGrRWDlqbnkV for ; Fri, 13 Sep 2013 16:34:23 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 4703011E8126 for ; Fri, 13 Sep 2013 16:34:23 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id B2719864D; Fri, 13 Sep 2013 23:41:47 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 3C4218533; Fri, 13 Sep 2013 23:41:45 +0000 (UTC) Received: from usa7109ht001.na.xerox.net ([13.41.230.31]) by USA7109MR003.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 13 Sep 2013 18:34:18 -0500 Received: from USA7109MB013.na.xerox.net ([169.254.5.164]) by USA7109HT001.na.xerox.net ([13.41.230.31]) with mapi id 14.03.0123.003; Fri, 13 Sep 2013 18:33:47 -0500 From: "Manchala, Daniel" To: 'Michael Sweet' Thread-Topic: IPP Transaction-Based Printing Extensions specification ...comments. Thread-Index: AQHOsNkOSkTD4jHtzUmUsb26b0j54Q== Date: Fri, 13 Sep 2013 23:33:47 +0000 Message-ID: References: <82f142d2fc6a4ed280bb5bc97492e6e1@BY2PR03MB144.namprd03.prod.outlook.com> <71991fd9bae448f8817ab71e649b4641@BY2PR03MB144.namprd03.prod.outlook.com> <64EBFA11-D91A-4631-AD91-7E62840C5509@apple.com> In-Reply-To: <64EBFA11-D91A-4631-AD91-7E62840C5509@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "'ipp@pwg.org'" , "'sm3@pwg.org'" Subject: [IPP] IPP Transaction-Based Printing Extensions specification ...comments. X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1510194483==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1510194483== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB9BEusa7109mb013nax_" --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB9BEusa7109mb013nax_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, Thanks for the response to earlier comments from Xerox. Just a few addition= al comments on the same topic. Given your explanation to Justin, and other "industry efforts", Xerox will = accept your rejection of 1 through 5 (copied below for reference), although= we believe IPP should have avoided PDL specific attributes. We have two w= ays to obtain the same information. The network overhead of attribute colo= ring is minimal and can be mitigated through parallel requests or technolog= ies such as "Volley. It is best the PWG mirror every IPP attribute in the PWG Semantic Model eve= n if they are a side-effect of the protocol or of targeting specific market= s/use cases. Thanks, /Daniel. Here are the five comments (copied from an earlier email note): IPP Attributes should be document format independent. Existing semantics s= hould be used when they exist or corrected when additional semantics are re= quired. 1) "jpeg-k-octets-supported" should be dropped in favor of the existin= g "k-octets-supported". a. Note that IPP attribute coloring can be used to obtain document fo= rmat specific values when required. In actual implementation, the existing attribute (with multiple queries) wa= s too inefficient. This attribute has been widely implemented in IPP print= ers since 2010. My preference is to reject this request. 2) "pdf-k-octets-supported" should be dropped in favor of the existing= "k-octets-supported". In actual implementation, the existing attribute (with multiple queries) wa= s too inefficient. This attribute has been widely implemented in IPP print= ers since 2010. My preference is to reject this request. (For reference, a Client might need to determine supported file formats and= sizes in order to determine which format to send to the Printer. And cert= ain file formats such as PWG Raster generally are streamed on both the Clie= nt and Printer so the job-k-octets-supported value is MAX vs. some smaller = value for PDF or JPEG) 3) "pdf-versions-supported" should be dropped in favor of the existing= "document-format-details-supported" ("document-format" and "document-forma= t-version" members). "document-format-version" is localized text, "document-format-details-suppo= rted" is a list of member attributes supported by the "document-format-deta= ils" attribute, and "document-format-version-supported" is a list of all of= the localized version strings that are supported for all formats that is o= ptionally filtered by document-format when you do a Get-Printer-Attributes = request. Since there is no way to register localized text values, filtering those va= lues with multiple Get-Printer-Attributes requests is inefficient, and this= attribute is supported by most IPP+PDF printers since 2010, my preference = is to reject this request. 4) "jpeg-x-dimension-supported" and "jpeg-y-dimension-supported" shoul= d apply to any image format. The names should be changed to "max-image-x-d= imension-supported" and "max-image -x-dimension-supported". These attributes have been widely implemented since 2010. And as I've note= d before doing multiple Get-Printer-Attributes requests is really inefficie= nt. My preference is to reject this request. 5) "printer-dns-sd-name" should be applicable to any service. The nam= e should be changed to "dns-sd-name". With a few exceptions, we prefix all Printer Description attributes that ar= e not associated with Job/Document Template attributes with "printer-". An= d since DNS-SD is a *service* discovery protocol, not a device discovery pr= otocol, I don't think dropping the "printer-" prefix or using an alternate = prefix like "device-" makes sense. And FWIW CUPS has implemented "printer-= dns-sd-name" for a very long time (since CUPS 1.2/2005 IIRC). Scaling should not be print specific. IPP =3D Internet Printing Protocol, so we are necessarily focused on printi= ng. And as has been done in the past, SM can (and probably should) map prin= t-scaling to ScalingMode (or whatever), just as print-quality is mapped to = Quality, printer-resolution =3D> Resolution, etc. The PWG Semantic Model already defined a collection for scaling (i.e., "sca= ling"). Apparently we didn't quite get it right. The current definition al= lows for explicit scaling (i.e., "scaling-height" and "scaling-width") or a= boolean for "auto-scaling". The explicit scaling member should be kept. = The Boolean "auto-scaling" should be deprecating and an attribute with a un= ique name (e.g., "auto-scale-mode") should replace it with the semantics de= fined for "print-scaling" FWIW, CUPS previously supported two other attributes for scaling in the pas= t - "scaling" (scale to a percentage of the media size) and "natural-scalin= g" (scale to a percentage of the document size). This allowed for "poster"= printing over multiple media sheets, among other things, but had a lot of = limitations and implementation issues. (BTW, we only ever supported symmet= ric scaling: scaling-width =3D=3D scaling-height) I *can* see the use case for copy - copy this hardcopy document and enlarge= to 200% - but for print the 99% use case is "enlarge this document/image t= o fit/fill these (media) dimensions". In many cases there are no (reliabl= e) physical dimensions to work with, so saying "enlarge to 200%" has no mea= ning. However, you can always say "fit/fill the document data on the reque= sted media". Also, the current Scaling group in SM is not part of the Print service, jus= t under the Copy, FaxIn, FaxOut, and Scan services (under Document= Processing). My preference is to reject this request. From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael= Sweet Sent: Friday, September 06, 2013 10:05 AM To: Justin Hutchings Cc: ipp@pwg.org Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printin= g Extensions specification and has comments Justin, Fair enough, we do have use cases but will highlight for each of the attrib= utes. On Sep 6, 2013, at 12:53 PM, Justin Hutchings > wrote: Thanks for your quick response, Mike. It might be worthwhile to articulate = the rationale as to why these are required in the spec. I didn't pick up on= all that during my read through. Thanks! Justin From: Michael Sweet [mailto:msweet@apple.com] Sent: Friday, September 6, 2013 7:00 AM To: Justin Hutchings Cc: ipp@pwg.org; Ira McDonald; Paul Tykodi Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printin= g Extensions specification and has comments Justin, Thank you for your feedback! Quick comments inline... On Sep 5, 2013, at 6:06 PM, Justin Hutchings > wrote: - OpenXPS has a MIME type of application/oxps, not application/Ope= nXPS (http://www.iana.org/assignments/media-types/application/oxps) Oops, will fix. - This spec appears to have a bunch of content which is completely= unrelated to the transaction based printing. Why are we throwing these int= o what would otherwise be a very straightforward, to-the-point spec? These have particular application to commercial print services and service = discovery. o Print-scaling-supported o Print-scaling-default These provide control over the final imposition/scaling of the document dat= a on the output media - important particularly for commercial print service= s. o Printer-dns-sd-name This is used for service discovery; we need to have a way to configure the = service name. o Printer-kind This is used for service selection/filtering - again, if you are looking fo= r a print service that supports the kind of document you are printing, you = need this information. (this is also part of the DNS-SD TXT record, but DNS-SD is not the only way= to do discovery) o Jpeg-* o Pdf-* These are used to inform the Client of limits for direct photo and PDF prin= ting - having dealt with a lot of commercial print shops over the years, it= is VERY important for the Client to be able to know whether they support a= particular flavor of PDF or have limits in the maximum size/dimensions of = print files. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB9BEusa7109mb013nax_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

Thanks for the respons= e to earlier comments from Xerox. Just a few additional comments on the sam= e topic.

Given your explanation= to Justin, and other “industry efforts”, Xerox will accept you= r rejection of 1 through 5 (copied below for reference), although we believ= e IPP should have avoided PDL specific attributes. We have two ways to obtain the same information. The network overhea= d of attribute coloring is minimal and can be mitigated through parallel re= quests or technologies such as “Volley.

It is best the PWG mir= ror every IPP attribute in the PWG Semantic Model even if they are a side-e= ffect of the protocol or of targeting specific markets/use cases.

Thanks,

/Daniel.

Here are the five comm= ents (copied from an earlier email note):

IPP Attributes should be document fo= rmat independent. Existing semantics should be used when they exist o= r corrected when additional semantics are required.<= o:p>

1) “jpeg-k-octets-supported” = should be dropped in favor of the existing “k-octets-supported”= .

a. Note that IPP attribute coloring can b= e used to obtain document format specific values when required.

In actual implementation, the existing attribute (wi= th multiple queries) was too inefficient. This attribute has been wid= ely implemented in IPP printers since 2010.

My preference is to reject this request.<= /p>

2) “pdf-k-octets-supported” s= hould be dropped in favor of the existing “k-octets-supported”.=

In actual implementation, the existing attribute (wi= th multiple queries) was too inefficient. This attribute has been wid= ely implemented in IPP printers since 2010.

My preference is to reject this request.<= /p>

(For reference, a Client might need to determine sup= ported file formats and sizes in order to determine which format to send to= the Printer. And certain file formats such as PWG Raster generally a= re streamed on both the Client and Printer so the job-k-octets-supported value is MAX vs. some smaller value for PDF = or JPEG)

3) “pdf-versions-supported” s= hould be dropped in favor of the existing “document-format-details-su= pported” (“document-format” and “document-format-ve= rsion” members).

"document-format-version" is localized tex= t, "document-format-details-supported" is a list of member attrib= utes supported by the "document-format-details" attribute, and &q= uot;document-format-version-supported" is a list of all of the localiz= ed version strings that are supported for all formats that is optionally filt= ered by document-format when you do a Get-Printer-Attributes request.<= /o:p>

Since there is no way to register localized text val= ues, filtering those values with multiple Get-Printer-Attributes requests i= s inefficient, and this attribute is supported by most IPP+PDF printers= since 2010, my preference is to reject this request.

4) “jpeg-x-dimension-supported̶= 1; and “jpeg-y-dimension-supported” should apply to any image f= ormat. The names should be changed to “max-image-x-dimension-su= pported” and “max-image -x-dimension-supported”.

These attributes have been widely implemented since = 2010. And as I've noted before doing multiple Get-Printer-Attributes = requests is really inefficient.

My preference is to reject this request.<= /p>

5) “printer-dns-sd-name” shou= ld be applicable to any service. The name should be changed to “= ;dns-sd-name”.

With a few exceptions, we prefix all Printer Descrip= tion attributes that are not associated with Job/Document Template attribut= es with "printer-". And since DNS-SD is a *service* discove= ry protocol, not a device discovery protocol, I don't think dropping the "printer-" prefix or using an alternate prefi= x like "device-" makes sense. And FWIW CUPS has implemented= "printer-dns-sd-name" for a very long time (since CUPS 1.2/2005 = IIRC).

Scaling should not be print specific.

The PWG Semantic Model already defined a collection for scal= ing (i.e., “scaling”). Apparently we didn’t quite get it = right. The current definition allows for explicit scaling (i.e., “scaling-height” and “scaling-width”) or a = boolean for “auto-scaling”. The explicit scaling member s= hould be kept. The Boolean “auto-scaling” should be depre= cating and an attribute with a unique name (e.g., “auto-scale-mode= 221;) should replace it with the semantics defined for “print-scaling”

Also, the current Scaling group in SM is not part of= the Print service, just under the Copy, FaxIn, FaxOut, and Scan services (= under <service>DocumentProcessing).

My preference is to reject this request.<= /p>

From: ipp-boun= ces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Friday, September 06, 2013 10:05 AM
To: Justin Hutchings
Cc: ipp@pwg.org
Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based = Printing Extensions specification and has comments

Justin,

Fair enough, we do have use cases but will highlight= for each of the attributes.

On Sep 6, 2013, at 12:53 PM, Justin Hutchings <justhu@microsoft.com> wrote:

Thanks for your quick = response, Mike. It might be worthwhile to articulate the rationale as to wh= y these are required in the spec. I didn’t pick up on all that during= my read through.

Thanks!

Justin

From: Michael Sweet [mailto:msweet@apple.com]
Sent: Friday, September 6, 2013 7:00 AM
To: Justin Hutchings
Cc: ipp@pwg.org; Ira McDonald; Pa= ul Tykodi
Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based = Printing Extensions specification and has comments

Justin,

Thank you for your feedback! Quick comments in= line...

On Sep 5, 2013, at 6:06 PM, Justin Hutchings <justhu@microsoft.com> wrote:

-= OpenXPS has a MIME type of application/oxps, not application/OpenXPS= (= http://www.iana.org/assignments/media-types/application/oxps)

Oops, will fix.

-= This spec appears to have a bunch of content which is completely unr= elated to the transaction based printing. Why are we throwing these into wh= at would otherwise be a very straightforward, to-the-point spec?=

These have particular application to= commercial print services and service discovery.

o Print-scaling-supported

o Print-scaling-default

These provide control over the final= imposition/scaling of the document data on the output media - important pa= rticularly for commercial print services.

o Printer-dns-sd-name

This is used for service discovery; = we need to have a way to configure the service name.

o Printer-kind

This is used for service selection/f= iltering - again, if you are looking for a print service that supports the = kind of document you are printing, you need this information.

(this is also part of the DNS-SD TXT= record, but DNS-SD is not the only way to do discovery)<= /p>

o Jpeg-*

o Pdf-*

________________________________________= _________________
Michael Sweet, Senior Printing System Engineer, PWG Chair<= /o:p>

____________________________________= ___________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/ma= ilman/listinfo/ipp

_________________________________________________________
Mich= ael Sweet, Senior Printing System Engineer, PWG Chair

--_000_E4503CD23822BF45A1EAEDA0BC5F107404CAB9BEusa7109mb013nax_-- --===============1510194483== 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 --===============1510194483==-- From ipp-bounces@pwg.org Fri Sep 13 18:01:26 2013 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 008EC11E8158 for ; Fri, 13 Sep 2013 18:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wcit1jCF8YTE for ; Fri, 13 Sep 2013 18:01:20 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4211E814B for ; Fri, 13 Sep 2013 18:01:20 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id C214A8668; Sat, 14 Sep 2013 01:08:44 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id E59948661; Sat, 14 Sep 2013 01:08:43 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MT300EUXC62Q1U0@mail-out.apple.com>; Fri, 13 Sep 2013 18:01:17 -0700 (PDT) X-AuditID: 11807158-b7fea6d000001e19-77-5233b55a7c22 Received: from [17.153.38.51] (Unknown_Domain [17.153.38.51]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 64.6C.07705.B55B3325; Fri, 13 Sep 2013 18:01:17 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Fri, 13 Sep 2013 21:01:13 -0400 Message-id: References: <469D5BFC-3F06-4587-8F9C-0208CDD9DB1F@apple.com> To: "Manchala, Daniel" X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUiOFPNWDd2q3GQQf8lOYvHOyazWhzb95LF 4si3WIvlF64yObB4bD35g81j3uLpTB7LT61nC2CO4rJJSc3JLEst0rdL4Mq4P3sxS8GOTsaK jnXv2RoY91V0MXJySAiYSEy7vJ4JwhaTuHBvPVsXIxeHkEA3k8S2PdfYQBLCAkUSJ08cZAex eQX0JD5eW84IYjMLJEj0d55jAbHZBNQkfk/qY+1i5ODgFAiUWDIvDiTMIqAq0fpmIQtImFnA TuLTL12IKTYSuz6cZIFbtWX3O1aQhIiAkcSDVYtZIO6RlTg7eSLrBEa+WUg2z0KyGcLWlli2 8DUzhG0g8bTzFSumuL7Em3dzmBYwsq1iFChKzUmsNNVLLCjISdVLzs/dxAgK4IbCiB2M/5dZ HWIU4GBU4uH94GscJMSaWFZcmXuIUYKDWUmE98RcoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe M95GQUIC6YklqdmpqQWpRTBZJg5OqQbGnpbjqqWF154azzzJJ+K16yPnHN2ftSeXqi6xuL36 vm/3g7wjsbf5WC/J61apBYYd6bYK6srf2vhsbcvu+8Zz5I78FORSqm/+7Ri78uOlLKM7nl1f pGNCVM5s7+q+UqjBGnjsiNubS4vda9ZrdUkLRbHmN3Ye55qyxMFwZ0uChdbUUGl/7TIlluKM REMt5qLiRAD9DRIFXAIAAA== Cc: "ipp@pwg.org" , "sm3@pwg.org" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074784628==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============2074784628== Content-type: multipart/alternative; boundary="Boundary_(ID_8+VGMsy2pH9ikfMoxe4UVQ)" --Boundary_(ID_8+VGMsy2pH9ikfMoxe4UVQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel, The "print-scaling" attribute, as defined in the IPP Transaction-Based = Printing Extensions, is already implemented in shipping IPP printers and = CUPS since v1.6. *If* we wanted percent scaling (which I do not support), we'd need to = define a print-scaling-col attribute or something (a different name). = However, since SM Scaling is not part of Print (it is specifically used = for hardcopy documents) I don't think we need to tie IPP to it. And I = think we will have a hard time agreeing on what the percentages are = based on - remember CUPS tried both percent-of-output-media and = percent-of-input-document and neither worked well. On Sep 13, 2013, at 4:45 PM, Manchala, Daniel = wrote: > Michael, > =20 > The Semantic Model defines Scaling thus: > =20 > Scaling (complex) { > ScalingHeight (range of int) > ScalingWeight (range of int) > AutoScaleMode (keyword) //values of =91auto, =91fit=92, = =91auto-fit=92, =91fill=92 and =91none=92; SM to change replace boolean = with keyword. > } > =20 > Why don=92t we translate this into IPP as follows?: > =20 > print-scaling(collection) { > scaling-height(integer(1:100)) //expressed as a = percentage. > scaling-width(integer(1:100)) > auto-scale-mode(type2 keyword) //values of =91auto=92, = =91auto-fit=92, =91fit=92, =91fill=92 and =91none=92 > } > =20 > =20 > Thanks, > Daniel. > =20 > =20 > = >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>= =20 > Scaling should not be print specific. > =20 > IPP =3D Internet Printing Protocol, so we are necessarily focused on = printing. And as has been done in the past, SM can (and probably should) = map print-scaling to ScalingMode (or whatever), just as print-quality is = mapped to Quality, printer-resolution =3D> Resolution, etc. > =20 > The PWG Semantic Model already defined a collection for scaling (i.e., = =93scaling=94). Apparently we didn=92t quite get it right. The current = definition allows for explicit scaling (i.e., =93scaling-height=94 and = =93scaling-width=94) or a boolean for =93auto-scaling=94. The explicit = scaling member should be kept. The Boolean =93auto-scaling=94 should be = deprecating and an attribute with a unique name (e.g., = =93auto-scale-mode=94) should replace it with the semantics defined for = =93print-scaling=94 > =20 > FWIW, CUPS previously supported two other attributes for scaling in = the past - "scaling" (scale to a percentage of the media size) and = "natural-scaling" (scale to a percentage of the document size). This = allowed for "poster" printing over multiple media sheets, among other = things, but had a lot of limitations and implementation issues. (BTW, = we only ever supported symmetric scaling: scaling-width =3D=3D = scaling-height) > =20 > I *can* see the use case for copy - copy this hardcopy document and = enlarge to 200% - but for print the 99% use case is "enlarge this = document/image to fit/fill these (media) dimensions". In many cases = there are no (reliable) physical dimensions to work with, so saying = "enlarge to 200%" has no meaning. However, you can always say "fit/fill = the document data on the requested media". > =20 > Also, the current Scaling group in SM is not part of the Print = service, just under the Copy, FaxIn, FaxOut, and Scan services (under = DocumentProcessing). > =20 > My preference is to reject this request. > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_8+VGMsy2pH9ikfMoxe4UVQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel,

The "print-scaling" = attribute, as defined in the IPP Transaction-Based Printing Extensions, = is already implemented in shipping IPP printers and CUPS since = v1.6.

*If* we wanted percent scaling (which I = do not support), we'd need to define a print-scaling-col attribute or = something (a different name). However, since SM Scaling is not = part of Print (it is specifically used for hardcopy documents) I don't = think we need to tie IPP to it. And I think we will have a hard time = agreeing on what the percentages are based on - remember CUPS tried both = percent-of-output-media and percent-of-input-document and neither worked = well.

On Sep 13, 2013, at = 4:45 PM, Manchala, Daniel <Daniel.Manchala@xerox.com>= ; wrote:

Michael,

The Semantic Model = defines Scaling thus:

Scaling (complex) {
        &nbs= p;       ScalingHeight (range of = int)
        &nbs= p;       ScalingWeight (range of int)
        &nbs= p;       AutoScaleMode (keyword) = //values of =91auto, =91fit=92, =91auto-fit=92, =91fill=92 and =91none=92;= SM to change = replace boolean with keyword.
        &nbs= p;       }

Why don=92t we translate this into IPP as = follows?:

print-scaling(collection) = {
        &nbs= p;       scaling-height(integer(1:100)) = //expressed as a percentage.
        &nbs= p;       = scaling-width(integer(1:100))
        &nbs= p;       auto-scale-mode(type2 keyword) = //values of =91auto=92, =91auto-fit=92, =91fit=92, =91fill=92 and = =91none=92
        &nbs= p;       }

Thanks,
Daniel.

>>>>>>>>>>>>&g= t;>>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>&g= t;>>>>>>>>>>>>>>>>>>= >>>>>>

Scaling should not be print specific.

IPP =3D Internet Printing Protocol, so we = are necessarily focused on printing. And as has been done in the past, = SM can (and probably should) map print-scaling to ScalingMode (or = whatever), just as print-quality is mapped to Quality, = printer-resolution =3D> Resolution, etc.

The PWG Semantic Model already defined a = collection for scaling (i.e., =93scaling=94). Apparently we didn=92t = quite get it right. The current definition allows for explicit scaling (i.e., = =93scaling-height=94 and =93scaling-width=94) or a boolean for = =93auto-scaling=94. The explicit scaling member should be = kept. The Boolean =93auto-scaling=94 should be deprecating and an = attribute with a unique name (e.g., =93auto-scale-mode=94) should replace it with the semantics = defined for =93print-scaling=94

FWIW, CUPS previously supported two other = attributes for scaling in the past - "scaling" (scale to a percentage of = the media size) and "natural-scaling" (scale to a percentage of the = document size). This allowed for "poster" printing over multiple media sheets, among other things, but had a lot of limitations = and implementation issues. (BTW, we only ever supported symmetric = scaling: scaling-width =3D=3D scaling-height)

I *can* see the use case for copy - copy = this hardcopy document and enlarge to 200% - but for print the 99% use = case is "enlarge this document/image to fit/fill these (media) = dimensions". In many cases there are no (reliable) physical dimensions to work with, so saying "enlarge to 200%" has no meaning. = However, you can always say "fit/fill the document data on the = requested media".

Also, the current Scaling group in SM is not = part of the Print service, just under the Copy, FaxIn, FaxOut, and Scan = services (under <service>DocumentProcessing).

My preference is to reject this = request.

____________________________________________= _____________

Michael Sweet, Senior Printing System Engineer, PWG = Chair

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

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_8+VGMsy2pH9ikfMoxe4UVQ)-- --===============2074784628== 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 --===============2074784628==-- From ipp-bounces@pwg.org Mon Sep 16 10:24:08 2013 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 2F12511E82B2 for ; Mon, 16 Sep 2013 10:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Paus9CEsLrH9 for ; Mon, 16 Sep 2013 10:24:02 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB5511E82A7 for ; Mon, 16 Sep 2013 10:24:02 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 86726848E; Mon, 16 Sep 2013 17:31:38 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 9EEED8424 for ; Mon, 16 Sep 2013 17:31:37 +0000 (UTC) MIME-version: 1.0 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MT800MMDAZUXKT0@mail-out.apple.com> for ipp@pwg.org; Mon, 16 Sep 2013 10:23:58 -0700 (PDT) X-AuditID: 11807157-b7f466d0000039e3-cb-52373eab23a9 Received: from [17.153.59.253] (Unknown_Domain [17.153.59.253]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id A3.DD.14819.CAE37325; Mon, 16 Sep 2013 10:23:57 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Mon, 16 Sep 2013 13:23:54 -0400 Message-id: References: <165688C8-527B-42F0-B3F8-EB211C63E13E@apple.com> To: "Manchala, Daniel" X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUiONP6r+5aO/Mgg7Zt5havXy1lt3i8YzKr xbF9L1ksjnyLtej8Zu3A6rH15A82j52z7rJ7zFs8nclj85XnLB7LT61nC2CN4rJJSc3JLEst 0rdL4MpY9ambsWBmWsWKVVNZGxg3h3cxcnJICJhI/N37nhXCFpO4cG89WxcjF4eQQC+TxMf+ e2AJYYEciV/HX4LZvAJ6Eh+vLWcEsZkFEiTOT9/GDmKzCahJ/J7UB1bDKRAocXHRLzCbRUBV YnHfZqB6DqD6XImp5ypATF4BG4mVP5hBKoQEjjFKtPQmgNgiAkYSD1YtZoE4R1bi7OSJrBMY +WYhWTwLyWIIW1ti2cLXzBC2gcTTzlesmOL6Em/ezWFawMi2ilGgKDUnsdJEL7GgICdVLzk/ dxMjKLAbCsN3MP5bZnWIUYCDUYmHd4aUeZAQa2JZcWXuIUYJDmYlEd4wXaAQb0piZVVqUX58 UWlOavEhRmkOFiVx3jPeRkFCAumJJanZqakFqUUwWSYOTqkGxqsXfxaczZ4Rcj1wxrzDx18k qUQlr4u/cextbYKpRZ6O9cPu7uuXD0Wv1E6Y9+T7vn2s/1OSD5q1+4otMVWZqHLj6aHEmo0m 8buqZ1x9z1/l38vfN2vZnEOSS2Zvjw7L3nzkvjg3e05L+gzzrQH32RzXykux5OQLWVW8vvmz p03I4I9RSfCnUiWW4oxEQy3mouJEAIHd329oAgAA Cc: "ipp@pwg.org" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0496699105==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0496699105== Content-type: multipart/alternative; boundary="Boundary_(ID_rwW6xlPrkNm8PaY2u8YInw)" --Boundary_(ID_rwW6xlPrkNm8PaY2u8YInw) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel, On Sep 12, 2013, at 9:33 PM, Manchala, Daniel = wrote: > I think I must have missed my point by including payment schemes = (keywords like =91visa=92 or =91paypal=92) into =93job-account-type=94. = It was my attempt to generalize the scenario. If the purpose is to provide the user interface with something other = than a generic "Account ID" label, then the printer-strings-uri = attribute is already able to do that. If you actually want to support different types of account numbers and = expose that choice to the client (which can supply 1 of N different = account ID types), then *maybe* we could add OPTIONAL job-account-type = (type3 keyword | name(MAX)), job-account-type-default (type3 keyword | = name(MAX)), and job-account-type-supported (1setOf (type3 keyword | = name(MAX))) attributes. But I can't see us including trademarked names = as keywords, nor would I like to have a generic "credit-card" keyword = since "job-account-id" by itself is insufficient to authorize credit = card transactions. Having implemented a couple credit card processing systems over the = years for my prior business, I know we would need a lot more attributes = and a lot of security language to conform to the current PCI security = standards council requirements. And those standards change over time and = vary subtly between countries. Here in Canada, for example, "chip" cards are common and require entry = of a PIN or passcode during credit card processing, and there are = special rules for ongoing service charges. In the US, few cards use = security chips and instead merchants collect 3 or 4 digit security codes = (CVC/CVV) to use in conjunction with the card number, expiration date, = and card holder name, and there are specific rules for their use that = are slightly different than in Canada. > Here is what I meant: Xerox has been using some accounting systems for = several years that used =93job-account-id=94 and a = =93job-account-group-id=94 or =93job-account-general-id=94 to charge it = to a specific group or a general account. The purpose of the request to = add =93job-account-type=94 by which a user can select or specify either = =91general=92 or =91group=92 or =91none=92, for proper accounting = purposes. I would have no objection to adding job-account-type-xxx as I have = outlined above with the keyword values 'none', 'general', and 'group'. = Vendors can provide their own keywords or (localized) name values for = credit cards if they choose, but we won't standardize those keywords = because of the reasons I have outlined above. > =20 > >>>>> >=20 > Add an attribute: =93job-account-type (type2 keyword | name(MAX))=94 along with =93job-account-type-supported(1setOf type2 = keyword | 1setOf name(MAX))=94 and = =93job-account-type-default(type2 keyword | name(MAX))=94. The = keywords initially can start with =91none=92, =91general=92, =91group=92 = or =91visa-card=92, =91master-card=92, =91paypal=92,=92bit-coin=92, = =91micro-mint=92, =91cash=92, =91credit-account=92, etc., . The = preference is to use keywords as it aids in the internationalization. > =20 > We've very specifically avoided currency or payment identifiers since = a) many members, including Xerox, have indicated that payment processing = is done separately from the printer and b) we have no facility in IPP to = express currency values or other complex, fractional types. > =20 > What would be the purpose of adding this when the printer-charge-info = and printer-charge-info-uri values provide localized resources that can = be displayed by the Client? Since the Client never has to have knowledge = of how transactions are processed (just whether the printer needs = transactional information), and since job-account-id will not (or at = least SHOULD NOT) be a credit card number or other direct payment = identifier, I don't see the point in telling the Client anything other = than "I need a job-account-id from the user." >=20 >=20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_rwW6xlPrkNm8PaY2u8YInw) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel,

On Sep 12, 2013, at 9:33 = PM, Manchala, Daniel <Daniel.Manchala@xerox.com>= ; wrote:

I think I must = have missed my point by including payment schemes (keywords like =91visa=92= or =91paypal=92) into =93job-account-type=94. It was my attempt to = generalize the scenario.

If = the purpose is to provide the user interface with something other than a = generic "Account ID" label, then the printer-strings-uri attribute is = already able to do that.

If you actually want = to support different types of account numbers and expose that choice to = the client (which can supply 1 of N different account ID types), then = *maybe* we could add OPTIONAL job-account-type (type3 keyword | = name(MAX)), job-account-type-default (type3 keyword | name(MAX)), and = job-account-type-supported (1setOf (type3 keyword | name(MAX))) = attributes. But I can't see us including trademarked names as keywords, = nor would I like to have a generic "credit-card" keyword since = "job-account-id" by itself is insufficient to authorize credit card = transactions.

Having implemented a couple = credit card processing systems over the years for my prior business, I = know we would need a lot more attributes and a lot of security language = to conform to the current PCI security standards council requirements. = And those standards change over time and vary subtly between = countries.

Here in Canada, for example, "chip" = cards are common and require entry of a PIN or passcode during credit = card processing, and there are special rules for ongoing service = charges. In the US, few cards use security chips and instead merchants = collect 3 or 4 digit security codes (CVC/CVV) to use in conjunction with = the card number, expiration date, and card holder name, and there are = specific rules for their use that are slightly different than in = Canada.

Here is what I meant: Xerox has been using some = accounting systems for several years that used =93job-account-id=94 and = a =93job-account-group-id=94 or =93job-account-general-id=94 to charge = it to a specific group or a general account. The purpose of the request to add =93job-account-type=94 by = which a user can select or specify either =91general=92 or =91group=92 = or =91none=92, for proper accounting purposes.

I = would have no objection to adding job-account-type-xxx as I have = outlined above with the keyword values 'none', 'general', and 'group'. = Vendors can provide their own keywords or (localized) name values = for credit cards if they choose, but we won't standardize those keywords = because of the reasons I have outlined = above.

>>>>>

Add an attribute: =93job-account-type (type2 = keyword | name(MAX))<Job Template>=94 along with = =93job-account-type-supported(1setOf type2 keyword | 1setOf = name(MAX))<Printer>=94 and =93job-account-type-default(type2 keyword | = name(MAX))<Printer>=94. The keywords initially can start with = =91none=92, =91general=92, =91group=92 or =91visa-card=92, = =91master-card=92, =91paypal=92,=92bit-coin=92, =91micro-mint=92, = =91cash=92, =91credit-account=92, etc., . The preference is to use keywords as it aids in the internationalization.

We've very specifically avoided currency or = payment identifiers since a) many members, including Xerox, have = indicated that payment processing is done separately from the printer = and b) we have no facility in IPP to express currency values or other complex, fractional types.

What would be the purpose of adding this = when the printer-charge-info and printer-charge-info-uri values provide = localized resources that can be displayed by the Client? Since the = Client never has to have knowledge of how transactions are processed (just whether the printer needs transactional information), = and since job-account-id will not (or at least SHOULD NOT) be a credit = card number or other direct payment identifier, I don't see the point in = telling the Client anything other than "I need a job-account-id from the user."

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_rwW6xlPrkNm8PaY2u8YInw)-- --===============0496699105== 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 --===============0496699105==-- From ipp-bounces@pwg.org Mon Sep 16 10:56:22 2013 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 D8F5A11E82DF for ; Mon, 16 Sep 2013 10:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.407 X-Spam-Level: X-Spam-Status: No, score=0.407 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_HTML_MOSTLY=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCNAylMUTfUw for ; Mon, 16 Sep 2013 10:56:11 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 791B711E82B2 for ; Mon, 16 Sep 2013 10:56:11 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 7C56184D1; Mon, 16 Sep 2013 18:03:47 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 65A5F84C0; Mon, 16 Sep 2013 18:03:46 +0000 (UTC) MIME-version: 1.0 Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MT800MM0CFJXKW0@mail-out.apple.com>; Mon, 16 Sep 2013 10:56:07 -0700 (PDT) X-AuditID: 1180715a-b7f8e6d000006c98-ed-5237463446cd Received: from [17.153.59.253] (Unknown_Domain [17.153.59.253]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id B0.CE.27800.53647325; Mon, 16 Sep 2013 10:56:06 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Mon, 16 Sep 2013 13:56:03 -0400 Message-id: <3B35DE0C-A463-4A7D-AFF2-5361F14DD7D6@apple.com> References: <82f142d2fc6a4ed280bb5bc97492e6e1@BY2PR03MB144.namprd03.prod.outlook.com> <71991fd9bae448f8817ab71e649b4641@BY2PR03MB144.namprd03.prod.outlook.com> <64EBFA11-D91A-4631-AD91-7E62840C5509@apple.com> To: "Manchala, Daniel" X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUiONP6r66Zm3mQwZ/L2haPd0xmtTi27yWL xZFvsRbLL1xlcmDx2HryB5vHvMXTmTyWn1rPFsAcxWWTkpqTWZZapG+XwJVxdOMi5oK5l5gq frd9Ym5gnLKcqYuRg0NCwETi83+hLkZOIFNM4sK99WxdjFwcQgK9TBKHr8xlBEkIC4RLTLx5 D8zmFdCT+HhtOZjNLJAgsfrwJXYQm01ATeL3pD5WEJtTIFBi5ellYHEWAVWJow8Xs4PsYhaw k/j0SxdijI3EsY27WSB2HWOS+P/5DthMEQEjiQerFrNAHCQrcXbyRNYJjHyzkKyehWQ1hK0t sWzha2YI20DiaecrVkxxfYk37+YwLWBkW8UoUJSak1hpppdYUJCTqpecn7uJERTCDYVROxgb llsdYhTgYFTi4Z0hZR4kxJpYVlyZe4hRgoNZSYQ3TBcoxJuSWFmVWpQfX1Sak1p8iFGag0VJ nPest1GQkEB6YklqdmpqQWoRTJaJg1OqgVH/89+1jWVF6/PEI4U2Plyacjwj2ySkZVPpc4kz SQVpkQVGpa6zG3r6bzJkFJ+dcjI0rZZjY7tyfHzkwSZVecty4XM9038+M/TYVuz+YEP5sbAc vntf735ltpv+vu3hxDT15mX/N1zMMGTeylQ9I7HyF0PNDOfE71uXFNYufeOhsmWvxq/aV0os xRmJhlrMRcWJAAo0iCJdAgAA Cc: "ipp@pwg.org" , "sm3@pwg.org" Subject: Re: [IPP] IPP Transaction-Based Printing Extensions specification ...comments. X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0612426670==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0612426670== Content-type: multipart/alternative; boundary="Boundary_(ID_TS4rtUJ8SA/gKz7K6FtRvA)" --Boundary_(ID_TS4rtUJ8SA/gKz7K6FtRvA) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel, Thank you for the response. My own personal experience with various IPP implementations from = consumer inkjet's through high-end light production office equipment = shows that performance with multiple requests (in serial or parallel) = introduces delays on the order of seconds with some printers. A delay = of even 1 second can seem like an eternity in an interactive UI. In some cases the overhead is with the implementation (low-end hardware = with non-optimized IPP stack) and in other cases with the configuration = (TLS, authentication, etc.) which introduces a lot of round trips and = retransmissions. And many low-end printers limit the number of = simultaneous client requests making a parallel request strategy cause = more delays than simply issuing multiple requests over a single = connection. Add IPP USB to the mix and you are *really* constrained in = the number of parallel requests you can make. Perhaps things like HTTP/2.0 and future TLS specifications will address = many of the performance issues inherent in a parallel request strategy, = but those are not yet available or implemented in production printers. (FWIW, I don't regret defining these PDL-specific attributes: it has = made printing an enjoyable experience for hundreds of millions of = users.) WRT the Semantic Model, there are already differences in what is defined = in IPP and the SM, from operations (Get-Jobs + which-jobs vs. = GetXxxJobs) to attributes (MediaType top-level element in SM that is not = in IPP, various IPP operation attributes like "compression" that are not = in the SM, etc.) IMHO the important thing is for the core semantics to = remain the same, not to provide a directly-accessible SM element for = every IPP attribute. So I might not add xxx-k-octets-supported to the SM, but something like = pdf-versions-supported would be a candidate since you can't get it from = DocumentFormatDetails. On Sep 13, 2013, at 7:33 PM, Manchala, Daniel = wrote: > Michael, > =20 > Thanks for the response to earlier comments from Xerox. Just a few = additional comments on the same topic. > =20 > Given your explanation to Justin, and other =93industry efforts=94, = Xerox will accept your rejection of 1 through 5 (copied below for = reference), although we believe IPP should have avoided PDL specific = attributes. We have two ways to obtain the same information. The = network overhead of attribute coloring is minimal and can be mitigated = through parallel requests or technologies such as =93Volley. > =20 > It is best the PWG mirror every IPP attribute in the PWG Semantic = Model even if they are a side-effect of the protocol or of targeting = specific markets/use cases.=20 > =20 > Thanks, > /Daniel. > =20 > Here are the five comments (copied from an earlier email note): > =20 > IPP Attributes should be document format independent. Existing = semantics should be used when they exist or corrected when additional = semantics are required. > 1) =93jpeg-k-octets-supported=94 should be dropped in favor of = the existing =93k-octets-supported=94.=20 > a. Note that IPP attribute coloring can be used to obtain = document format specific values when required. > =20 > In actual implementation, the existing attribute (with multiple = queries) was too inefficient. This attribute has been widely = implemented in IPP printers since 2010. > =20 > My preference is to reject this request. > =20 > 2) =93pdf-k-octets-supported=94 should be dropped in favor of the = existing =93k-octets-supported=94. > =20 > In actual implementation, the existing attribute (with multiple = queries) was too inefficient. This attribute has been widely = implemented in IPP printers since 2010. > =20 > My preference is to reject this request. > =20 > (For reference, a Client might need to determine supported file = formats and sizes in order to determine which format to send to the = Printer. And certain file formats such as PWG Raster generally are = streamed on both the Client and Printer so the job-k-octets-supported = value is MAX vs. some smaller value for PDF or JPEG) > =20 > 3) =93pdf-versions-supported=94 should be dropped in favor of the = existing =93document-format-details-supported=94 (=93document-format=94 = and =93document-format-version=94 members). > =20 > "document-format-version" is localized text, = "document-format-details-supported" is a list of member attributes = supported by the "document-format-details" attribute, and = "document-format-version-supported" is a list of all of the localized = version strings that are supported for all formats that is optionally = filtered by document-format when you do a Get-Printer-Attributes = request. > =20 > Since there is no way to register localized text values, filtering = those values with multiple Get-Printer-Attributes requests is = inefficient, and this attribute is supported by most IPP+PDF printers = since 2010, my preference is to reject this request. > =20 > 4) =93jpeg-x-dimension-supported=94 and = =93jpeg-y-dimension-supported=94 should apply to any image format. The = names should be changed to =93max-image-x-dimension-supported=94 and = =93max-image -x-dimension-supported=94. > =20 > These attributes have been widely implemented since 2010. And as I've = noted before doing multiple Get-Printer-Attributes requests is really = inefficient. > =20 > My preference is to reject this request. > =20 > 5) =93printer-dns-sd-name=94 should be applicable to any service. = The name should be changed to =93dns-sd-name=94. > =20 > With a few exceptions, we prefix all Printer Description attributes = that are not associated with Job/Document Template attributes with = "printer-". And since DNS-SD is a *service* discovery protocol, not a = device discovery protocol, I don't think dropping the "printer-" prefix = or using an alternate prefix like "device-" makes sense. And FWIW CUPS = has implemented "printer-dns-sd-name" for a very long time (since CUPS = 1.2/2005 IIRC). > =20 > Scaling should not be print specific. > =20 > IPP =3D Internet Printing Protocol, so we are necessarily focused on = printing. And as has been done in the past, SM can (and probably should) = map print-scaling to ScalingMode (or whatever), just as print-quality is = mapped to Quality, printer-resolution =3D> Resolution, etc. > =20 > The PWG Semantic Model already defined a collection for scaling (i.e., = =93scaling=94). Apparently we didn=92t quite get it right. The current = definition allows for explicit scaling (i.e., =93scaling-height=94 and = =93scaling-width=94) or a boolean for =93auto-scaling=94. The explicit = scaling member should be kept. The Boolean =93auto-scaling=94 should be = deprecating and an attribute with a unique name (e.g., = =93auto-scale-mode=94) should replace it with the semantics defined for = =93print-scaling=94 > =20 > FWIW, CUPS previously supported two other attributes for scaling in = the past - "scaling" (scale to a percentage of the media size) and = "natural-scaling" (scale to a percentage of the document size). This = allowed for "poster" printing over multiple media sheets, among other = things, but had a lot of limitations and implementation issues. (BTW, = we only ever supported symmetric scaling: scaling-width =3D=3D = scaling-height) > =20 > I *can* see the use case for copy - copy this hardcopy document and = enlarge to 200% - but for print the 99% use case is "enlarge this = document/image to fit/fill these (media) dimensions". In many cases = there are no (reliable) physical dimensions to work with, so saying = "enlarge to 200%" has no meaning. However, you can always say "fit/fill = the document data on the requested media". > =20 > Also, the current Scaling group in SM is not part of the Print = service, just under the Copy, FaxIn, FaxOut, and Scan services (under = DocumentProcessing). > =20 > My preference is to reject this request. > =20 > =20 > =20 > From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of = Michael Sweet > Sent: Friday, September 06, 2013 10:05 AM > To: Justin Hutchings > Cc: ipp@pwg.org > Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based = Printing Extensions specification and has comments > =20 > Justin, > =20 > Fair enough, we do have use cases but will highlight for each of the = attributes. > =20 > =20 > On Sep 6, 2013, at 12:53 PM, Justin Hutchings = wrote: >=20 >=20 > Thanks for your quick response, Mike. It might be worthwhile to = articulate the rationale as to why these are required in the spec. I = didn=92t pick up on all that during my read through. > =20 > Thanks! > Justin > =20 > From: Michael Sweet [mailto:msweet@apple.com]=20 > Sent: Friday, September 6, 2013 7:00 AM > To: Justin Hutchings > Cc: ipp@pwg.org; Ira McDonald; Paul Tykodi > Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based = Printing Extensions specification and has comments > =20 > Justin, > =20 > Thank you for your feedback! Quick comments inline... > =20 > On Sep 5, 2013, at 6:06 PM, Justin Hutchings = wrote: > - OpenXPS has a MIME type of application/oxps, not = application/OpenXPS = (http://www.iana.org/assignments/media-types/application/oxps) > =20 > Oops, will fix. >=20 >=20 >=20 > - This spec appears to have a bunch of content which is = completely unrelated to the transaction based printing. Why are we = throwing these into what would otherwise be a very straightforward, = to-the-point spec? > =20 > These have particular application to commercial print services and = service discovery. > =20 > o Print-scaling-supported > o Print-scaling-default > =20 > These provide control over the final imposition/scaling of the = document data on the output media - important particularly for = commercial print services. >=20 >=20 >=20 > o Printer-dns-sd-name > =20 > This is used for service discovery; we need to have a way to configure = the service name. >=20 >=20 >=20 > o Printer-kind > =20 > This is used for service selection/filtering - again, if you are = looking for a print service that supports the kind of document you are = printing, you need this information. > =20 > (this is also part of the DNS-SD TXT record, but DNS-SD is not the = only way to do discovery) >=20 >=20 >=20 > o Jpeg-* > o Pdf-* > =20 > These are used to inform the Client of limits for direct photo and PDF = printing - having dealt with a lot of commercial print shops over the = years, it is VERY important for the Client to be able to know whether = they support a particular flavor of PDF or have limits in the maximum = size/dimensions of print files. > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_TS4rtUJ8SA/gKz7K6FtRvA) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Daniel,

Thank you for the = response.

My own personal experience with = various IPP implementations from consumer inkjet's through high-end = light production office equipment shows that performance with multiple = requests (in serial or parallel) introduces delays on the order of = seconds with some printers. A delay of even 1 second can seem like = an eternity in an interactive UI.

In some cases = the overhead is with the implementation (low-end hardware with = non-optimized IPP stack) and in other cases with the configuration (TLS, = authentication, etc.) which introduces a lot of round trips and = retransmissions. And many low-end printers limit the number of = simultaneous client requests making a parallel request strategy cause = more delays than simply issuing multiple requests over a single = connection. Add IPP USB to the mix and you are *really* = constrained in the number of parallel requests you can = make.

Perhaps things like HTTP/2.0 and future = TLS specifications will address many of the performance issues inherent = in a parallel request strategy, but those are not yet available or = implemented in production printers.

(FWIW, I = don't regret defining these PDL-specific attributes: it has made = printing an enjoyable experience for hundreds of millions of = users.)

WRT the Semantic Model, there are = already differences in what is defined in IPP and the SM, from = operations (Get-Jobs + which-jobs vs. GetXxxJobs) to attributes = (MediaType top-level element in SM that is not in IPP, various IPP = operation attributes like "compression" that are not in the SM, etc.) = IMHO the important thing is for the core semantics to remain the = same, not to provide a directly-accessible SM element for every IPP = attribute.

So I might not add = xxx-k-octets-supported to the SM, but something like = pdf-versions-supported would be a candidate since you can't get it from = DocumentFormatDetails.

On Sep 13, = 2013, at 7:33 PM, Manchala, Daniel <Daniel.Manchala@xerox.com>= ; wrote:

Michael,

Thanks for the = response to earlier comments from Xerox. Just a few additional comments = on the same topic.

Given your explanation to Justin, and other = =93industry efforts=94, Xerox will accept your rejection of 1 through 5 = (copied below for reference), although we believe IPP should have = avoided PDL specific attributes. We have two ways to obtain the same information. The network = overhead of attribute coloring is minimal and can be mitigated through = parallel requests or technologies such as = =93Volley.

It is best the PWG mirror every IPP attribute in = the PWG Semantic Model even if they are a side-effect of the protocol or = of targeting specific markets/use cases.

Thanks,
/Daniel.

Here are the five = comments (copied from an earlier email note):

IPP Attributes should be document format = independent. Existing semantics should be used when they exist or = corrected when additional semantics are required.
1)      =93jpeg-k-octets-supported=94 = should be dropped in favor of the existing =93k-octets-supported=94. =
a.     &nbs= p; Note that IPP attribute coloring = can be used to obtain document format specific values when required.

In = actual implementation, the existing attribute (with multiple queries) = was too inefficient. This attribute has been widely implemented in = IPP printers since 2010.

My = preference is to reject this request.

2)      =93pdf-k-octets-supported=94 should = be dropped in favor of the existing =93k-octets-supported=94.

In = actual implementation, the existing attribute (with multiple queries) = was too inefficient. This attribute has been widely implemented in = IPP printers since 2010.

My = preference is to reject this request.

(For = reference, a Client might need to determine supported file formats and = sizes in order to determine which format to send to the Printer. = And certain file formats such as PWG Raster generally are streamed = on both the Client and Printer so the job-k-octets-supported value is MAX vs. some smaller value for = PDF or JPEG)

3)      =93pdf-versions-supported=94 should = be dropped in favor of the existing =93document-format-details-supported=94= (=93document-format=94 and =93document-format-version=94 = members).

"document-format-version" is localized text, = "document-format-details-supported" is a list of member attributes = supported by the "document-format-details" attribute, and = "document-format-version-supported" is a list of all of the localized version strings that are supported for all formats that is optionally = filtered by document-format when you do a Get-Printer-Attributes = request.

Since there is no way to register localized text = values, filtering those values with multiple Get-Printer-Attributes = requests is inefficient, and this attribute is supported by most IPP+PDF = printers since 2010, my preference is to reject this request.

4)      =93jpeg-x-dimension-supported=94 = and =93jpeg-y-dimension-supported=94 should apply to any image = format. The names should be changed to = =93max-image-x-dimension-supported=94 and =93max-image = -x-dimension-supported=94.

These attributes have been widely implemented since = 2010. And as I've noted before doing multiple = Get-Printer-Attributes requests is really inefficient.

My = preference is to reject this request.

5)      =93printer-dns-sd-name=94 should be = applicable to any service. The name should be changed to = =93dns-sd-name=94.

With a few exceptions, we prefix all Printer = Description attributes that are not associated with Job/Document = Template attributes with "printer-". And since DNS-SD is a = *service* discovery protocol, not a device discovery protocol, I don't think dropping the "printer-" prefix or using an alternate prefix like = "device-" makes sense. And FWIW CUPS has implemented = "printer-dns-sd-name" for a very long time (since CUPS 1.2/2005 = IIRC).

Scaling should not be print = specific.

IPP= =3D Internet Printing Protocol, so we are necessarily focused on = printing. And as has been done in the past, SM can (and probably should) = map print-scaling to ScalingMode (or whatever), just as print-quality is = mapped to Quality, printer-resolution =3D> Resolution, etc.

The PWG = Semantic Model already defined a collection for scaling (i.e., = =93scaling=94). Apparently we didn=92t quite get it right. The = current definition allows for explicit scaling (i.e., =93scaling-height=94 and =93scaling-width=94) or a boolean for = =93auto-scaling=94. The explicit scaling member should be = kept. The Boolean =93auto-scaling=94 should be deprecating and an = attribute with a unique name (e.g., =93auto-scale-mode=94) should = replace it with the semantics defined for =93print-scaling=94

FWIW, CUPS previously supported two other attributes = for scaling in the past - "scaling" (scale to a percentage of the media = size) and "natural-scaling" (scale to a percentage of the document = size). This allowed for "poster" printing over multiple media sheets, among other things, but had a lot of limitations = and implementation issues. (BTW, we only ever supported symmetric = scaling: scaling-width =3D=3D scaling-height)

I *can* = see the use case for copy - copy this hardcopy document and enlarge to = 200% - but for print the 99% use case is "enlarge this document/image to = fit/fill these (media) dimensions". In many cases there are no = (reliable) physical dimensions to work with, so saying "enlarge to 200%" has no meaning. = However, you can always say "fit/fill the document data on the = requested media".

Also, = the current Scaling group in SM is not part of the Print service, just = under the Copy, FaxIn, FaxOut, and Scan services (under = <service>DocumentProcessing).

My = preference is to reject this request.

From: ipp-bounces@pwg.org = [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Friday, September 06, 2013 10:05 AM
To: Justin Hutchings
Cc: ipp@pwg.org
Subject: Re: [IPP] Microsoft has reviewed the IPP = Transaction-Based Printing Extensions specification and has = comments

Justin,

Fair enough, we do have use cases but will = highlight for each of the attributes.

On Sep 6, 2013, at 12:53 PM, Justin = Hutchings <justhu@microsoft.com> = wrote:

Thanks for = your quick response, Mike. It might be worthwhile to articulate the = rationale as to why these are required in the spec. I didn=92t pick up = on all that during my read through.

Thanks!
Justin

From: Michael Sweet [mailto:msweet@apple.com]
Sent: Friday, September 6, 2013 7:00 AM
To: Justin Hutchings
Cc: ipp@pwg.org; Ira McDonald; = Paul Tykodi
Subject: Re: [IPP] Microsoft has reviewed the IPP = Transaction-Based Printing Extensions specification and has = comments

Justin,

Thank you for your feedback! Quick = comments inline...

On Sep 5, 2013, at 6:06 PM, Justin Hutchings = <justhu@microsoft.com> = wrote:

-       &= nbsp; OpenXPS has a MIME type of application/oxps, not = application/OpenXPS (http= ://www.iana.org/assignments/media-types/application/oxps)

Oops, will fix.

-       &= nbsp; This spec appears to have a bunch of content which is completely = unrelated to the transaction based printing. Why are we throwing these = into what would otherwise be a very straightforward, to-the-point = spec?

These have particular application to = commercial print services and service discovery.

o   Print-scaling-supported
o   Print-scaling-default

These provide control over the final = imposition/scaling of the document data on the output media - important = particularly for commercial print services.

o   Printer-dns-sd-name

This is used for service discovery; we = need to have a way to configure the service name.

o   Printer-kind

This is used for service = selection/filtering - again, if you are looking for a print service that = supports the kind of document you are printing, you need this = information.

(this is also part of the DNS-SD TXT = record, but DNS-SD is not the only way to do = discovery)

o   Jpeg-*
o   Pdf-*

These are used to inform the Client of = limits for direct photo and PDF printing - having dealt with a lot of = commercial print shops over the years, it is VERY important for the Client to be able to know whether they support a particular = flavor of PDF or have limits in the maximum size/dimensions of print = files.

____________________________________________= _____________
Michael Sweet, Senior Printing System Engineer, PWG = Chair

___________________________________________= ____
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mail= man/listinfo/ipp

_________________________________________________________
Michael Sweet, Senior Printing = System Engineer, PWG Chair

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

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_TS4rtUJ8SA/gKz7K6FtRvA)-- --===============0612426670== 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 --===============0612426670==-- From ipp-bounces@pwg.org Mon Sep 16 11:20:30 2013 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 7D37211E82EA for ; Mon, 16 Sep 2013 11:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLL8Tn33VEJx for ; Mon, 16 Sep 2013 11:20:18 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id C4CA811E82E8 for ; Mon, 16 Sep 2013 11:20:18 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id CECDF8339; Mon, 16 Sep 2013 18:27:55 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 6586D831C for ; Mon, 16 Sep 2013 18:27:55 +0000 (UTC) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MT8005XPDLQF5W0@mail-out.apple.com> for ipp@pwg.org; Mon, 16 Sep 2013 11:20:16 -0700 (PDT) X-AuditID: 11807165-b7f426d000003169-40-52374bddf11c Received: from [17.153.59.253] (Unknown_Domain [17.153.59.253]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 0B.92.12649.EDB47325; Mon, 16 Sep 2013 11:20:16 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Mon, 16 Sep 2013 14:20:13 -0400 Message-id: References: To: Barry Cavill X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUiONP6r+4Db/Mgg+VfOS12Ny5gtXj9aim7 xbF9L1ks3t6ewGpx5FusRec3awc2j60nf7B57Jx1l93jZdsORo95i6czeWy+8pwlgDWKyyYl NSezLLVI3y6BK2PzmymsBdvVK3p6pjM1MDYqdTFyckgImEjcPLqbHcIWk7hwbz1bFyMXh5BA L5PE0p1fmEESwgLlEo//nWcBsXkF9CQ+XlvOCGIzCyRI/J9+GsxmE1CT+D2pjxXE5hQIlFh5 ayobiM0ioCpxcv4FFpChzALNjBLrdjWzQgyykVhz8TtYkZBAgMTNphamLkYODhGgQb2tuhAH yUqcnTyRdQIj3ywkq2chWQ1ha0ssW/iaGcLWk3jZ9I4dU1xX4uK6SYwLGNlWMQoUpeYkVprr JRYU5KTqJefnbmIEhXlDYeoOxsblVocYBTgYlXh4Z0iZBwmxJpYVV+YeYpTgYFYS4Q3TBQrx piRWVqUW5ccXleakFh9ilOZgURLnPettFCQkkJ5YkpqdmlqQWgSTZeLglGpg3BM4pebLkZ0c y88UmrPsOttfXKU32UWAyXrC7u+rX62tdpBeZ7JtY+5HGffb/i+53tgtue9e0BORZ+njd6nN +sezRcmnO/53Vs7d9jW3sSqo7NXfVzWfFxdVspWsyWWf0+DZOqvBpFLyjPH8uPvP7+itjI7m SXiY4cP2znHWoYZEtyf6At+uKrEUZyQaajEXFScCAFlRGLZvAgAA Cc: ipp@pwg.org, Jeremy Leber Subject: Re: [IPP] Lexmark has reviewed the IPP Transaction-Based Printing Extensions specification and has one comment X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827639937==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0827639937== Content-type: multipart/alternative; boundary="Boundary_(ID_nrtl0NLviergHzMz4yRKIQ)" --Boundary_(ID_nrtl0NLviergHzMz4yRKIQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Barry, Thanks for your feedback. Response below. On Sep 13, 2013, at 9:13 AM, Barry Cavill wrote: > "The actual methods of measurement and limit enforcement" are considered out-of-scope for the specification, which is fine. However, perhaps there should be a job-state-reason to indicate that the user's job is rejected for a measurement other than limit enforcement... for example, the user isn't authorized for color printing, or for printing on photo paper, or some similar scenario. In general, such things would be detected when the job is submitted, however since we *do* define "job-state-reasons" keywords for many of the client-error-xxx status codes, how about the following additions? Status Code "job-state-reasons" Keyword ----------------------------------------------- ---------------------------------- client-error-attributes-or-values-not-supported 'unsupported-attributes-or-values' client-error-conflicting-attributes 'conflicting-attributes' Unfortunately, we don't have a place to store the actual unsupported attributes and values after the response, but at least the client would know there was a problem and the "job-state-message" attribute could provide a localized reason with specifics... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_nrtl0NLviergHzMz4yRKIQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Barry,

Thanks for your feedback. = Response below.

On Sep 13, 2013, at 9:13 = AM, Barry Cavill <bcavill@lexmark.com> = wrote:

"The actual = methods of measurement and limit enforcement" are considered out-of-scope for the specification, which is fine. However, = perhaps=20 there should be a job-state-reason to indicate that the user's job is=20 rejected for a measurement other than limit enforcement... for example,=20= the user isn't authorized for color printing, or for printing on photo=20= paper, or some similar scenario.

In general, such = things would be detected when the job is submitted, however since we = *do* define "job-state-reasons" keywords for many of the = client-error-xxx status codes, how about the following = additions?

Status Code = = = "job-state-reasons" Keyword

= ----------------------------------------------- = ----------------------------------

= client-error-attributes-or-values-not-supported = 'unsupported-attributes-or-values'

= client-error-conflicting-attributes = = 'conflicting-attributes'

Unfortunately, = we don't have a place to store the actual unsupported attributes and = values after the response, but at least the client would know there was = a problem and the "job-state-message" attribute could provide a = localized reason with specifics...

_________________________________________________________

Michael Sweet, Senior Printing = System Engineer, PWG Chair

= --Boundary_(ID_nrtl0NLviergHzMz4yRKIQ)-- --===============0827639937== 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 --===============0827639937==-- From s-uggbqwpY7lR-EwGZOcgHhX7Tebsvyz25aeRmnZLWwxcDEm6Yobn1jF@bounce.linkedin.com Tue Sep 17 05:55:50 2013 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 B4E2D11E83F0 for ; Tue, 17 Sep 2013 05:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.997 X-Spam-Level: X-Spam-Status: No, score=-11.997 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, GB_I_INVITATION=-2, HABEAS_ACCREDITED_SOI=-4.3, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzAkycta+lb3 for ; Tue, 17 Sep 2013 05:55:45 -0700 (PDT) Received: from maile-ea.linkedin.com (maile-ea.linkedin.com [199.101.162.57]) by ietfa.amsl.com (Postfix) with ESMTP id A347811E8417 for ; Tue, 17 Sep 2013 05:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1379422521; bh=RcmxOLhBCXCgz3y16ihjufKJzCkiuEyPR0wMwrjWLI4=; h=Date:From:To:Subject:MIME-Version:Content-Type: X-LinkedIn-Template:X-LinkedIn-fbl; b=lmbrvFzkZpDTiZ0rvbBU0EP2MqqRYA7nyJr1DIpHYyWmBR8gnnoJ/56fZx18YvBhM uZPUEkiBnhqQTw79EO9TAIRuGTQcJvImnEZc4tlIVJmDhnKUPImpmjlTdo/MhNNOb4 ICJg4sXHITRErKdzrRCztx6WuJync/t0av4kxvm8= Sender: messages-noreply@bounce.linkedin.com Date: Tue, 17 Sep 2013 12:55:21 +0000 (UTC) From: "Tiffany Takashima (LinkedIn Invitations)" To: Message-ID: <1625903521.8876289.1379422521959.JavaMail.app@ela4-app2347.prod> Subject: Tiffany Takashima's invitation is awaiting your response MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8876286_1891764405.1379422521957" X-LinkedIn-Template: inv_exp_snackified_01 X-LinkedIn-fbl: s-uggbqwpY7lR-EwGZOcgHhX7Tebsvyz25aeRmnZLWwxcDEm6Yobn1jF ------=_Part_8876286_1891764405.1379422521957 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Tiffany Takashima would like to connect on LinkedIn. How would you like to respond? Tiffany Takashima Within 23 wards, Tokyo, Japan This is a reminder that on 9/12/13 9:03 AM, Tiffany Takashima sent you an invitation to become part of their professional network at LinkedIn. Reminder emails for pending invitations. © 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ------=_Part_8876286_1891764405.1379422521957 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Tiffany Takashima would like to connect on LinkedIn. How would you like to respond?

Tiffany Takashima

Confirm you know Tiffany

You are receiving Reminder emails for pending invitations. Unsubscribe.

------=_Part_8876286_1891764405.1379422521957-- From ipp-bounces@pwg.org Tue Sep 17 11:06:55 2013 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 0489B21F8618 for ; Tue, 17 Sep 2013 11:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 tagged_above=-999 required=5 tests=[AWL=-1.410, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZWwWKfuuGyE for ; Tue, 17 Sep 2013 11:06:49 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id D3C5111E8290 for ; Tue, 17 Sep 2013 11:06:08 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id F36B88423; Tue, 17 Sep 2013 18:13:47 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 352A5807A; Tue, 17 Sep 2013 18:13:47 +0000 (UTC) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MTA00B4T7KTUVH0@mail-out.apple.com>; Tue, 17 Sep 2013 11:06:04 -0700 (PDT) X-AuditID: 11807165-b7f426d000003169-f6-52389a09757c Received: from [17.153.40.22] (Unknown_Domain [17.153.40.22]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id C5.91.12649.A0A98325; Tue, 17 Sep 2013 11:06:03 -0700 (PDT) From: Michael Sweet Message-id: <7F39B198-A2A1-44EF-B129-48E1A12FF8B3@apple.com> Date: Tue, 17 Sep 2013 14:06:01 -0400 To: ipp@pwg.org X-Mailer: Apple Mail (2.1805) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUiOFNDTJd7lkWQwdUVYhZNc78wWRzb95LF 4si3WAdmj60nf7B5zFs8nSmAKYrLJiU1J7MstUjfLoEr417TPLaC+R4V17vXMTYw7rXrYuTk kBAwkfg2+wQzhC0mceHeerYuRi4OIYFuJok/C3rAEmwCahK/J/WxgtjMAgkSrat+MIHYvAI2 Et92/WWBsPUkPl5bzghiswioSvxu3whWIyxgKvF15zFGiF4FiXdTOsFsEQF+iYkXIWZKCMhK nJ08kXUCI88sJCtmIRkLEdeWWLbwNfMsRg4gW0di8kI0YQj74/kjTAsY2VYxChSl5iRWmusl FhTkpOol5+duYgSFXkNh6g7GxuVWhxgFOBiVeHgvlFsECbEmlhVX5h5ilOBgVhLhbckGCvGm JFZWpRblxxeV5qQWH2KU5mBREuc9620UJCSQnliSmp2aWpBaBJNl4uCUamDsDUu0cdhlFPA4 dKPLMs7DF9pZ1FNYT6zOXNIwhdVCnlnmV82lfTZxonye8ZEbn6rfirpp+mra/c4krjjXzql8 VxVLo+NkvzmGHallePbZMH3p3dv3673WaegK5qd26lge/9vBYnDw2J8ApStXBUQ312b+WFHl daiQje3ariWZFoeMc6rnH1JiKc5INNRiLipOBADC5JJqOQIAAA== Cc: IDS Work Group Subject: [IPP] RFC: IPP firmware attributes from PWG 5110.1 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0765021809==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0765021809== Content-type: multipart/alternative; boundary="Boundary_(ID_xFlgNO6BL5BkjE30OFJUUA)" --Boundary_(ID_xFlgNO6BL5BkjE30OFJUUA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, We have a need to track the firmware information in a printer. Long term we plan on doing a full binding of the IDS Attributes specification (PWG 5110.1) as part of the IPP System Control Service specification, but in the short term I would like to propose the following attribute definitions that map the FirmwareXxx attributes to IPP Printer attributes. Comments are appreciated... (and assuming these are acceptable, we can use the same kind of mapping for the other IDS attributes...) .... printer-firmware-name (1setOf name(MAX)) The REQUIRED "printer-firmware-name" Printer attribute provides the name(s) of the firmware components used by the Printer. For example, the Printer might report the names and versions of its IPP, PDF, JPEG, and PWG Raster components. This attribute corresponds to the FirmwareName attribute defines in the PWG Hardcopy Device Health Assessment Attributes specification [PWG5110.1]. This attribute MUST have the same cardinality (contain the same number of values) as the "printer-firmware-string-version" and "printer-firmware-version" attributes. The ith value in the "printer-firmware-name" attribute corresponds to the ith value in the "printer-firmware-string-version" and "printer-firmware-version" attributes. printer-firmware-patches (text(MAX)) The RECOMMENDED "printer-firmware-patches" Printer attribute provides an ordered list of patches (first to last) that have been applied to the firmware in the Printer. Each patch is delimited by a carriage return and line feed pair (0x0D 0x0A). This attribute corresponds to the FirmwarePatches attribute defines in the PWG Hardcopy Device Health Assessment Attributes specification [PWG5110.1]. Note: Unlike "printer-firmware-name", "printer-firmware-string-version", and "printer-firmware-version", this attribute is provided as a single text value. printer-firmware-string-version (1setOf text(MAX)) The REQUIRED "printer-firmware-string-version" Printer attribute provides the human-readable version(s) of the firmware components used by the Printer. For example, the Printer might report the names and versions of its IPP, PDF, JPEG, and PWG Raster components. This attribute corresponds to the FirmwareStringVersion attribute defines in the PWG Hardcopy Device Health Assessment Attributes specification [PWG5110.1]. This attribute MUST have the same cardinality (contain the same number of values) as the "printer-firmware-name" and "printer-firmware-version" attributes. The ith value in the "printer-firmware-string-version" attribute corresponds to the ith value in the "printer-firmware-name" and "printer-firmware-version" attributes. printer-firmware-version (1setOf octetString(MAX)) This REQUIRED Printer attribute provides the machine-readable version(s) of the firmware components used by the Printer. For example, the Printer might report the names and versions of its IPP, PDF, JPEG, and PWG Raster components. This attribute corresponds to the FirmwareVersion attribute defines in the PWG Hardcopy Device Health Assessment Attributes specification [PWG5110.1]. This attribute MUST have the same cardinality (contain the same number of values) as the "printer-firmware-name" and "printer-firmware-string-version" attributes. The ith value in the "printer-firmware-version" attribute corresponds to the ith value in the "printer-firmware-name" and "printer-firmware-string-version" attributes. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_xFlgNO6BL5BkjE30OFJUUA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable All,

We have a need to track the = firmware information in a printer. Long term we plan on doing a = full binding of the IDS Attributes specification (PWG 5110.1) as part of = the IPP System Control Service specification, but in the short term I = would like to propose the following attribute definitions that map the = FirmwareXxx attributes to IPP Printer attributes. Comments are = appreciated...

(and assuming these are = acceptable, we can use the same kind of mapping for the other IDS = attributes...)

....

prin= ter-firmware-name (1setOf name(MAX))

The = REQUIRED "printer-firmware-name" Printer attribute provides the name(s) = of the firmware components used by the Printer. For example, the = Printer might report the names and versions of its IPP, PDF, JPEG, and = PWG Raster components. This attribute corresponds to the = FirmwareName attribute defines in the PWG Hardcopy Device Health = Assessment Attributes specification [PWG5110.1].

This = attribute MUST have the same cardinality (contain the same number of = values) as the "printer-firmware-string-version" and = "printer-firmware-version" attributes. The ith value in the = "printer-firmware-name" attribute corresponds to the ith value = in the "printer-firmware-string-version" and "printer-firmware-version" = attributes.

printer-firmware-patches = (text(MAX))

The RECOMMENDED = "printer-firmware-patches" Printer attribute provides an ordered list of = patches (first to last) that have been applied to the firmware in = the Printer. Each patch is delimited by a carriage return and line feed = pair (0x0D 0x0A). This attribute corresponds to the FirmwarePatches = attribute defines in the PWG Hardcopy Device Health Assessment = Attributes specification [PWG5110.1].

Note: Unlike = "printer-firmware-name", "printer-firmware-string-version", and = "printer-firmware-version", this attribute is provided as a single = text value.

printer-firmware-string-version (1setOf = text(MAX))

The REQUIRED = "printer-firmware-string-version" Printer attribute provides the = human-readable version(s) of the firmware components used by = the Printer. For example, the Printer might report the names and = versions of its IPP, PDF, JPEG, and PWG Raster components. = This attribute corresponds to the FirmwareStringVersion attribute = defines in the PWG Hardcopy Device Health Assessment Attributes = specification [PWG5110.1].

This attribute MUST have the same = cardinality (contain the same number of values) as the = "printer-firmware-name" and "printer-firmware-version" attributes. = The ith value in the "printer-firmware-string-version" attribute = corresponds to the ith value in the "printer-firmware-name" = and "printer-firmware-version" = attributes.

printer-firmware-version (1setOf = octetString(MAX))

This REQUIRED Printer = attribute provides the machine-readable version(s) of the firmware = components used by the Printer. For example, the Printer might = report the names and versions of its IPP, PDF, JPEG, and PWG = Raster components. This attribute corresponds to the = FirmwareVersion attribute defines in the PWG Hardcopy Device Health = Assessment Attributes specification [PWG5110.1].

This attribute = MUST have the same cardinality (contain the same number of values) as = the "printer-firmware-name" and "printer-firmware-string-version" = attributes. The ith value in the "printer-firmware-version" = attribute corresponds to the ith value in the = "printer-firmware-name" and "printer-firmware-string-version" = attributes.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_xFlgNO6BL5BkjE30OFJUUA)-- --===============0765021809== 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 --===============0765021809==-- From ipp-bounces@pwg.org Tue Sep 17 17:05:45 2013 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 4474211E8158 for ; Tue, 17 Sep 2013 17:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt1nqItFNAwR for ; Tue, 17 Sep 2013 17:05:39 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 4234411E8151 for ; Tue, 17 Sep 2013 17:05:31 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 835958423; Wed, 18 Sep 2013 00:13:13 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from USA7109MR004.ACS-INC.COM (usa7109mr004.acs-inc.com [63.101.151.13]) by www.pwg.org (Postfix) with ESMTPS id 537018406 for ; Wed, 18 Sep 2013 00:13:11 +0000 (UTC) Received: from usa7109ht004.na.xerox.net ([13.41.230.30]) by USA7109MR004.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 17 Sep 2013 19:05:24 -0500 Received: from USA7109MB013.na.xerox.net ([169.254.5.71]) by USA7109HT004.na.xerox.net ([13.41.230.30]) with mapi id 14.03.0123.003; Tue, 17 Sep 2013 19:05:19 -0500 From: "Manchala, Daniel" To: 'Michael Sweet' Thread-Topic: Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments Thread-Index: AQHOtAJlsLsrCP5m1keRxTadEjf2YQ== Date: Wed, 18 Sep 2013 00:05:18 +0000 Message-ID: References: <165688C8-527B-42F0-B3F8-EB211C63E13E@apple.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.94] MIME-Version: 1.0 Cc: "'ipp@pwg.org'" Subject: Re: [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0866719382==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0866719382== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E4503CD23822BF45A1EAEDA0BC5F107404CB807Fusa7109mb013nax_" --_000_E4503CD23822BF45A1EAEDA0BC5F107404CB807Fusa7109mb013nax_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, Thank you for your quick feedback. Your suggestion to add the following OP= TIONAL attributes is appreciated by Xerox: job-account-type(type3 keyword | name(MAX)) job-account-type-default(type3 keyword | name(MAX)) job-account-type-supported(1setOf (type3 keyword | name(MAX)) with some of the keywords like: 'none', 'general' and 'group'. Vendors may wish to supply their own keywords for credit cards if they choo= se to, but PWG will not standardize them. Daniel. From: Michael Sweet [mailto:msweet@apple.com] Sent: Monday, September 16, 2013 10:24 AM To: Manchala, Daniel Cc: ipp@pwg.org; Ira McDonald; Paul Tykodi Subject: Re: Xerox has reviewed the IPP Transaction-Based Printing Extensio= ns specification and has comments Daniel, On Sep 12, 2013, at 9:33 PM, Manchala, Daniel > wrote: I think I must have missed my point by including payment schemes (keywords = like 'visa' or 'paypal') into "job-account-type". It was my attempt to gene= ralize the scenario. If the purpose is to provide the user interface with something other than a= generic "Account ID" label, then the printer-strings-uri attribute is alre= ady able to do that. If you actually want to support different types of account numbers and expo= se that choice to the client (which can supply 1 of N different account ID = types), then *maybe* we could add OPTIONAL job-account-type (type3 keyword = | name(MAX)), job-account-type-default (type3 keyword | name(MAX)), and job= -account-type-supported (1setOf (type3 keyword | name(MAX))) attributes. Bu= t I can't see us including trademarked names as keywords, nor would I like = to have a generic "credit-card" keyword since "job-account-id" by itself is= insufficient to authorize credit card transactions. Having implemented a couple credit card processing systems over the years f= or my prior business, I know we would need a lot more attributes and a lot = of security language to conform to the current PCI security standards counc= il requirements. And those standards change over time and vary subtly betwe= en countries. Here in Canada, for example, "chip" cards are common and require entry of a= PIN or passcode during credit card processing, and there are special rules= for ongoing service charges. In the US, few cards use security chips and i= nstead merchants collect 3 or 4 digit security codes (CVC/CVV) to use in co= njunction with the card number, expiration date, and card holder name, and = there are specific rules for their use that are slightly different than in = Canada. Here is what I meant: Xerox has been using some accounting systems for seve= ral years that used "job-account-id" and a "job-account-group-id" or "job-a= ccount-general-id" to charge it to a specific group or a general account. T= he purpose of the request to add "job-account-type" by which a user can sel= ect or specify either 'general' or 'group' or 'none', for proper accounting= purposes. I would have no objection to adding job-account-type-xxx as I have outlined= above with the keyword values 'none', 'general', and 'group'. Vendors can= provide their own keywords or (localized) name values for credit cards if = they choose, but we won't standardize those keywords because of the reasons= I have outlined above. >>>>> Add an attribute: "job-account-type (type2 keyword | name(MAX))" along with "job-account-type-supported(1setOf type2 keyword | 1setOf na= me(MAX))" and "job-account-type-default(type2 keyword | name(MAX))= ". The keywords initially can start with 'none', 'general', 'group= ' or 'visa-card', 'master-card', 'paypal','bit-coin', 'micro-mint', 'cash',= 'credit-account', etc., . The preference is to use keywords as it aids in = the internationalization. We've very specifically avoided currency or payment identifiers since a) ma= ny members, including Xerox, have indicated that payment processing is done= separately from the printer and b) we have no facility in IPP to express c= urrency values or other complex, fractional types. What would be the purpose of adding this when the printer-charge-info and p= rinter-charge-info-uri values provide localized resources that can be displ= ayed by the Client? Since the Client never has to have knowledge of how tra= nsactions are processed (just whether the printer needs transactional infor= mation), and since job-account-id will not (or at least SHOULD NOT) be a cr= edit card number or other direct payment identifier, I don't see the point = in telling the Client anything other than "I need a job-account-id from the= user." _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_E4503CD23822BF45A1EAEDA0BC5F107404CB807Fusa7109mb013nax_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

<= /p>

Thank you for your quick = feedback. Your suggestion to add the following OPTIONAL attributes is= appreciated by Xerox:

<= /p>

job-account-type(type3 ke= yword | name(MAX))

job-account-type-default(= type3 keyword | name(MAX))

job-account-type-supporte= d(1setOf (type3 keyword | name(MAX))

<= /p>

with some of the keywords= like: ‘none’, ‘general’ and ‘group’.

<= /p>

Vendors may wish to suppl= y their own keywords for credit cards if they choose to, but PWG will not s= tandardize them.

<= /p>

Daniel.=

<= /p>

From: Michael = Sweet [mailto:msweet@apple.com]
Sent: Monday, September 16, 2013 10:24 AM
To: Manchala, Daniel
Cc: ipp@pwg.org; Ira McDonald; Paul Tykodi
Subject: Re: Xerox has reviewed the IPP Transaction-Based Printing E= xtensions specification and has comments

Daniel,

On Sep 12, 2013, at 9:33 PM, Manchala, Daniel <Daniel.Manchala@xerox.com>= ; wrote:

I think I must have mi= ssed my point by including payment schemes (keywords like ‘visa’= ; or ‘paypal’) into “job-account-type”. It was my a= ttempt to generalize the scenario.

If the purpose is to provide the user interface with= something other than a generic "Account ID" label, then the prin= ter-strings-uri attribute is already able to do that.

If you actually want to support different types of a= ccount numbers and expose that choice to the client (which can supply 1 of = N different account ID types), then *maybe* we could add OPTIONAL job-accou= nt-type (type3 keyword | name(MAX)), job-account-type-default (type3 keyword | name(MAX)), and job-account-type= -supported (1setOf (type3 keyword | name(MAX))) attributes. But I can't see= us including trademarked names as keywords, nor would I like to have a gen= eric "credit-card" keyword since "job-account-id" by itself is insufficient to authorize credit c= ard transactions.

Having implemented a couple credit card processing s= ystems over the years for my prior business, I know we would need a lot mor= e attributes and a lot of security language to conform to the current PCI s= ecurity standards council requirements. And those standards change over time and vary subtly between countries.

Here in Canada, for example, "chip" cards = are common and require entry of a PIN or passcode during credit card proces= sing, and there are special rules for ongoing service charges. In the US, f= ew cards use security chips and instead merchants collect 3 or 4 digit security codes (CVC/CVV) to use in conjunction with t= he card number, expiration date, and card holder name, and there are specif= ic rules for their use that are slightly different than in Canada.

Here is what I meant: = Xerox has been using some accounting systems for several years that used &#= 8220;job-account-id” and a “job-account-group-id” or R= 20;job-account-general-id” to charge it to a specific group or a gene= ral account. The purpose of the request to add “job-account-type” = by which a user can select or specify either ‘general’ or ̵= 6;group’ or ‘none’, for proper accounting purposes.

I would have no objection to adding job-account-type= -xxx as I have outlined above with the keyword values 'none', 'general', an= d 'group'. Vendors can provide their own keywords or (localized) name= values for credit cards if they choose, but we won't standardize those keywords because of the reasons I have outl= ined above.

>>>>>

Add an attribute: ̶= 0;job-account-type (type2 keyword | name(MAX))<Job Template>” a= long with “job-account-type-supported(1setOf type2 keyword | 1setOf n= ame(MAX))<Printer>” and “job-account-type-default(type2 keyword | name(MAX))<Printer&= gt;”. The keywords initially can start with ‘none’, ̵= 6;general’, ‘group’ or ‘visa-card’, ‘ma= ster-card’, ‘paypal’,’bit-coin’, ‘micro= -mint’, ‘cash’, ‘credit-account’, etc., . The= preference is to use keywords as it aids in the internationalization.

We've very specifically avoided currency or payment = identifiers since a) many members, including Xerox, have indicated that pay= ment processing is done separately from the printer and b) we have no facil= ity in IPP to express currency values or other complex, fractional types.

What would be the purpose of adding this when the pr= inter-charge-info and printer-charge-info-uri values provide localized reso= urces that can be displayed by the Client? Since the Client never has to ha= ve knowledge of how transactions are processed (just whether the printer needs transactional information), and = since job-account-id will not (or at least SHOULD NOT) be a credit card num= ber or other direct payment identifier, I don't see the point in telling th= e Client anything other than "I need a job-account-id from the user."

____________= _____________________________________________
Michael Sweet, Senior= Printing System Engineer, PWG Chair

--_000_E4503CD23822BF45A1EAEDA0BC5F107404CB807Fusa7109mb013nax_-- --===============0866719382== 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 --===============0866719382==-- From ipp-bounces@pwg.org Thu Sep 19 06:11:14 2013 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 803DA21F969F for ; Thu, 19 Sep 2013 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHOINT4nnewp for ; Thu, 19 Sep 2013 06:11:09 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 64FC921F9654 for ; Thu, 19 Sep 2013 06:11:09 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id E09768423; Thu, 19 Sep 2013 13:18:58 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by www.pwg.org (Postfix) with ESMTPS id 340B38406 for ; Thu, 19 Sep 2013 13:18:57 +0000 (UTC) Received: from mail-vc0-f172.google.com ([209.85.220.172]) (using TLSv1) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKUjr36d1XST7lygtpkZEi2163yE6NDiRF@postini.com; Thu, 19 Sep 2013 06:11:06 PDT Received: by mail-vc0-f172.google.com with SMTP id hu8so3954118vcb.31 for ; Thu, 19 Sep 2013 06:11:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QJDgn+oIMYpiyO5/e2aA4xIeCUAj+RanqFMXypW4Z+k=; b=myB+UDv6HcMebHYTtqyCPn3Ak9d/zAEd9gdfCrXmnOP2UZs5fCNfH02H0EsAHkf4Pi dhPaNPGtXfOUVp/wmO43EnKexJZu2MibXAV284S6vZzSIldDtxb3FAYdEejZWLArhpzG X75H76dz35EHG14OxPyp3quHykyfHD0BhvgJqyxKSZhYILymBpO1aBEmC6EcZhnqWUFy k45Pio8H7OkCBP7XN0a0xNiOrINKCei5yv0aYLYj0SKQHmdDb0n7yaaOG8NIUS8c9VAR wQkKnIexekSZjLB5h41oBiWyslSWkSPy5KMMWJ2hh/TS4pEIL39279Xy77FcIffkyqjy A3Tg== X-Gm-Message-State: ALoCoQkCRTlAGnYb8aW/19gNwXEgSchvKyzTxGDbvKxOCQB+GjQzdF6XxVutqjtOepQiKVmWrSwZ3V+Hm9cRJHJtQTiU3RS+R8tqcjioUV9UbzoZGKMqIcvjmvtVQNZyM/EcBkPus52J X-Received: by 10.220.46.72 with SMTP id i8mr1194969vcf.10.1379596265392; Thu, 19 Sep 2013 06:11:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.46.72 with SMTP id i8mr1194962vcf.10.1379596265294; Thu, 19 Sep 2013 06:11:05 -0700 (PDT) Received: by 10.52.162.194 with HTTP; Thu, 19 Sep 2013 06:11:05 -0700 (PDT) In-Reply-To: References:

Date: Thu, 19 Sep 2013 09:11:05 -0400 Message-ID: From: Barry Cavill To: Michael Sweet Cc: ipp@pwg.org, Jeremy Leber Subject: Re: [IPP] Lexmark has reviewed the IPP Transaction-Based Printing Extensions specification and has one comment X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0401055971==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0401055971== Content-Type: multipart/alternative; boundary=001a11c2c67453a09c04e6bc4993 --001a11c2c67453a09c04e6bc4993 Content-Type: text/plain; charset=ISO-8859-1 That sounds reasonable to us. On Mon, Sep 16, 2013 at 2:20 PM, Michael Sweet wrote: > Barry, > > Thanks for your feedback. Response below. > > On Sep 13, 2013, at 9:13 AM, Barry Cavill wrote: > > "The actual methods of measurement and limit enforcement" are considered > out-of-scope for the specification, which is fine. However, perhaps there > should be a job-state-reason to indicate that the user's job is rejected > for a measurement other than limit enforcement... for example, the user > isn't authorized for color printing, or for printing on photo paper, or > some similar scenario. > > > In general, such things would be detected when the job is submitted, > however since we *do* define "job-state-reasons" keywords for many of the > client-error-xxx status codes, how about the following additions? > > Status Code "job-state-reasons" > Keyword > ----------------------------------------------- > ---------------------------------- > client-error-attributes-or-values-not-supported > 'unsupported-attributes-or-values' > client-error-conflicting-attributes > 'conflicting-attributes' > > Unfortunately, we don't have a place to store the actual unsupported > attributes and values after the response, but at least the client would > know there was a problem and the "job-state-message" attribute could > provide a localized reason with specifics... > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > -- Barry Cavill Lexmark International Phone (859) 232-5613 Bldg 082-2 bcavill@lexmark.com --001a11c2c67453a09c04e6bc4993 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

That sounds reasonable to us.=A0=A0

On Mon, Sep 16, 2013 at= 2:20 PM, Michael Sweet <msweet@apple.com> wrote:

Barry,
Thanks for your feedback. =A0Response below.

On Sep 13, 2013, at 9:13 AM, Barry Cavill <bcavill@lexmark.com&= gt; wrote:
"The actual= methods of measurement and limit enforcement" are considered out-of-scope for the specification, which is fine. =A0 However, perhaps=20 there should be a job-state-reason to indicate that the user's job is= =20 rejected for a measurement other than limit enforcement... for example,=20 the user isn't authorized for color printing, or for printing on photo= =20 paper, or some similar scenario. =A0
<= div>
In general, such things would be detected when the= job is submitted, however since we *do* define "job-state-reasons&quo= t; keywords for many of the client-error-xxx status codes, how about the fo= llowing additions?

=A0 =A0 Status Code =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"job-state-reasons"= ; Keyword
=A0 =A0 -----------------------------------------------= =A0----------------------------------
=A0 =A0 client-error-attributes-or-values-not-supported =A0'unsupported= -attributes-or-values'
=A0 =A0 client-error-conflicting-attri= butes =A0 =A0 =A0 =A0 =A0 =A0 =A0'conflicting-attributes'

Unfortunately, we don't have a place to store the actua= l unsupported attributes and values after the response, but at least the cl= ient would know there was a problem and the "job-state-message" a= ttribute could provide a localized reason with specifics...

_______________= __________________________________________

Michael Sweet, Senior Printing System=A0Engineer, PWG Chair

--
Barry C= avill
Lexmark International
Phone (859) 232-5613=A0=A0=A0 Bldg 082-2= =A0=A0 bcavill@lex= mark.com
--001a11c2c67453a09c04e6bc4993-- --===============0401055971== 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 --===============0401055971==-- From ipp-bounces@pwg.org Thu Sep 19 07:45:31 2013 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 1D11321F92C2 for ; Thu, 19 Sep 2013 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJ+jhMUn6dBX for ; Thu, 19 Sep 2013 07:45:17 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 62E1521F90CC for ; Thu, 19 Sep 2013 07:45:17 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 6EEAA8423; Thu, 19 Sep 2013 14:53:05 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by www.pwg.org (Postfix) with ESMTPS id 6A1278406 for ; Thu, 19 Sep 2013 14:53:04 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id v2so5490509qcr.20 for ; Thu, 19 Sep 2013 07:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=n1MmSfosADQOICZHjUFwy/lom2NuEWVyhB/TILSw1ww=; b=G64RSIuqvplUIoP+TXlO4NhbD5DNJN3+liE0J92D/ENJEHvFrhjnlrbEFabh5oa5UN InSsYLycOU+D5lMV4gGGbSjZQFolU7IlZWZ+NZTQMCU2EgXrb9r/hi8C8DTaRbuSWl9L HS1a+/SK+K0viAZ/c5EJaQVApl8fekHnAJuVQ/T1h32gynCIYX6prUlfNIg9tWEaAJZv wgB71Xi/bJu8y02Mm/pZliOeBD0Co9zt9hHr7wQwfNZane357D9JqZ18o1A5+xAgd8zP 9gGDy/MzXQmpm3Zw1LZdKSPKx4QVg3aAnKkQOWWjnUeben2sQ5n1iLiIdYlnTsXqPD8A zBcw== X-Received: by 10.49.98.100 with SMTP id eh4mr4312621qeb.42.1379601912560; Thu, 19 Sep 2013 07:45:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 19 Sep 2013 07:44:52 -0700 (PDT) From: Ira McDonald Date: Thu, 19 Sep 2013 10:44:52 -0400 Message-ID: To: "ipp@pwg.org" , Ira McDonald Subject: [IPP] Posted new draft of IPP WG Charter (19 September 2013) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0336701773==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0336701773== Content-Type: multipart/alternative; boundary=047d7bdc9574ee05b904e6bd99e6 --047d7bdc9574ee05b904e6bd99e6 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thanks to Paul Tykodi for prompt review of the previous draft! I kept the redlines from the previous draft which show the major changes from the previous approved charter. *** This new draft is ready for PWG Steering Committee approval next week. *** Based on feedback from Mike Sweet, I have posted a new draft of the IPP WG Charter: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-charter-20130919.pdf / doc - clean version w/ line numbers ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-charter-20130919-rev.pdf / doc - redline version w/ line numbers Change Log (19 September 2013) (1) Changed status from "Initial" to "Stable". (2) Changed interop milestone for IPPSIX from "Q2 2014" to "Q4 2014". Change Log (21 August 2013) (0) Corrected broken clause in OOS-4 about IPP Multifunction. (1) Revised title to be a charter of the IPP WG (rather than a project). (2) Added Smith Kennedy (HP) as IPP editor. (3) Revised text of Problem Statement and list of current IPP projects. (4) Revised Out-of-scope to list suspended and abandoned IPP projects. (5) Revised Objectives to generalize and remove redundant project list. (6) Revised Milestones dates and list of current IPP projects. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 --047d7bdc9574ee05b904e6bd99e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Thanks to Paul Tykodi = for prompt review of the previous draft!

I kept the redlines from = the previous draft which show the major
changes from the previous approved charter.

*** This new draft = is ready for PWG Steering Committee approval

next week. ***

Based on feedback from Mike Sweet, I have posted a= new draft
of the IPP WG Chart= er:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-charter-2= 0130919.pdf / doc

- clean version w/ line numbers

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-charter-20130919-rev= .pdf / doc
- redline version w/ line numbers

Change Log (19 September 2013)
= (1) Changed status from "Initial" to "Stable".
(2) C= hanged interop milestone for IPPSIX from "Q2 2014" to "Q4 20= 14".

Change Log (21 August 2013)

(0) Corrected broke= n clause in OOS-4 about IPP Multifunction.

(1) Revised title to be a charter of the IPP WG (rather than a project).

(2) Added Smith Kennedy (HP) as IPP edit= or.

(3) Revised text of Problem Statement and list of current IPP projects.

(4) Revised Out-of-scope to list suspended and abandoned IPP projects.

(5) Revised Objectives to generalize an= d remove redundant project list.

(6) Revised Milestones dates and = list of current IPP projects.

Cheers,

- Ira

Ira McDonald (Musician / Software Architect)
Chair - Lin= ux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Gro= up
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

--047d7bdc9574ee05b904e6bd99e6-- --===============0336701773== 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 --===============0336701773==-- From ipp-bounces@pwg.org Thu Sep 19 08:05:45 2013 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 8D2F121F94FA for ; Thu, 19 Sep 2013 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNxAMhLQ78dl for ; Thu, 19 Sep 2013 08:05:40 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id D7DE621F944C for ; Thu, 19 Sep 2013 08:05:40 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 55CE88430; Thu, 19 Sep 2013 15:13:30 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by www.pwg.org (Postfix) with ESMTPS id 725288423 for ; Thu, 19 Sep 2013 15:13:29 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id q4so5465008qcx.40 for ; Thu, 19 Sep 2013 08:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ZbpQ1eYiGWbVeFQxxtcMzx1ZZ7Q+dTcxGHA51dSedvk=; b=faD7i+bqHWCnxZ8YOFceXHW2+vSdwyqMcJicjJNBX5adNiEBmuHARwCJ6jHCK7jrvQ dOu/byr79k5GoBfZ/TJswag0XsJjKMl0R06/A3bTIxCDRnQflfMLO/GdR91BnRpNPHTK QoocKVB04hHuAVZsoBKK/tl/xM93rXb591L8oORydI/M0SLFJ2y2u80oP3h5hmQUTScO BbIUJDX/ztdbiuTvGtMVH7m0l/vwBa+aOxVnGR7ALXTBOBkUP7th8XOBoU8kIlqI2j7c Y+xb2YtDmc7Yp6GMufcbRkkwQH64pip+03ydwnoLkjfNy+OJGYf9N/1sw0+tAlA+A1dj aCPg== X-Received: by 10.49.25.102 with SMTP id b6mr4218599qeg.91.1379603137483; Thu, 19 Sep 2013 08:05:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 19 Sep 2013 08:05:17 -0700 (PDT) From: Ira McDonald Date: Thu, 19 Sep 2013 11:05:17 -0400 Message-ID: To: "Kennedy, Smith (Wireless Architect)" , Michael R Sweet , Ira McDonald , "ipp@pwg.org" Subject: [IPP] Reminder and topics for IPP WG next Monday X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0993751379==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0993751379== Content-Type: multipart/alternative; boundary=047d7b621ac8f0dd4504e6bde293 --047d7b621ac8f0dd4504e6bde293 Content-Type: text/plain; charset=ISO-8859-1 Hi, Smith - will you have an updated IPP Imp Guide v2 for review? Mike - should we do IPP Finishings review? Also, should we discuss/summarize the state of PWG Last Call (quorum was achieved) comments on IPP Transaction-based Printing Ext? Other topics for next Monday, anyone? Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 --047d7b621ac8f0dd4504e6bde293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Smith = - will you have an updated IPP Imp Guide v2 for review?

Mike -= should we do IPP Finishings review?=A0 Also, should we

discuss/su= mmarize the state of PWG Last Call (quorum was

achieved) comments on IPP Transaction-based Printing Ext?

Other topics for next Monday, anyone?

Cheers,

- Ira=

Ira = McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer = Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted = Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF D= esignated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434

--047d7b621ac8f0dd4504e6bde293-- --===============0993751379== 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 --===============0993751379==-- From ipp-bounces@pwg.org Thu Sep 19 08:15:28 2013 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 132B021F9611 for ; Thu, 19 Sep 2013 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMfvY+5RKkE4 for ; Thu, 19 Sep 2013 08:15:22 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8D21F970E for ; Thu, 19 Sep 2013 08:15:22 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 5A1D28406; Thu, 19 Sep 2013 15:23:11 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by www.pwg.org (Postfix) with ESMTPS id 10F668341 for ; Thu, 19 Sep 2013 15:23:10 +0000 (UTC) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 78D1C2484E; Thu, 19 Sep 2013 15:15:18 +0000 (UTC) Received: from G4W6303.americas.hpqcorp.net (16.210.26.228) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Sep 2013 15:14:32 +0000 Received: from G4W3295.americas.hpqcorp.net ([169.254.3.99]) by G4W6303.americas.hpqcorp.net ([16.210.26.228]) with mapi id 14.03.0123.003; Thu, 19 Sep 2013 15:14:32 +0000 From: "Kennedy, Smith (Wireless Architect)" To: Ira McDonald Thread-Topic: Reminder and topics for IPP WG next Monday Thread-Index: AQHOtUmz20RwV2HR9Eu7dCr1nWoax5nNK1EA Date: Thu, 19 Sep 2013 15:14:31 +0000 Message-ID: <657A9A26-A653-443E-B800-2DB15909478F@hp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.19] MIME-Version: 1.0 Cc: "ipp@pwg.org" Subject: Re: [IPP] Reminder and topics for IPP WG next Monday X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1184233050==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1184233050== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_1E0B2F1B-62D4-4DFC-9DAA-EA6E7712A0D7"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_1E0B2F1B-62D4-4DFC-9DAA-EA6E7712A0D7 Content-Type: multipart/alternative; boundary="Apple-Mail=_6A1E9B85-7161-4A09-9A11-A42C4C5358CF" --Apple-Mail=_6A1E9B85-7161-4A09-9A11-A42C4C5358CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Ira, I had hoped to have a new draft out early this week, but still haven't = wrapped up resolving earlier issues. Hoping to post a new draft by EOD = tomorrow at the latest. Smith /** Smith Kennedy Hewlett-Packard Co. smith.kennedy@hp.com */ On 2013-09-19, at 9:05 AM, Ira McDonald wrote: > Hi, >=20 > Smith - will you have an updated IPP Imp Guide v2 for review? >=20 > Mike - should we do IPP Finishings review? Also, should we > discuss/summarize the state of PWG Last Call (quorum was > achieved) comments on IPP Transaction-based Printing Ext? >=20 > Other topics for next Monday, anyone? >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - TCG Embedded Systems Hardcopy SG > 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 > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 --Apple-Mail=_6A1E9B85-7161-4A09-9A11-A42C4C5358CF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi Ira,

I had hoped to have a new draft out early this week, but still haven't wrapped up resolving earlier issues. Hoping to post a new draft by EOD tomorrow at the latest.

Smith

/**
Smith Kennedy
Hewlett-Packard Co.
smith.kennedy@hp.com
*/

On 2013-09-19, at 9:05 AM, Ira McDonald <blueroofmusic@gmail.com>

wrote:

Hi,

Smith - will you have an updated IPP Imp Guide v2 for review?

Mike - should we do IPP Finishings review? Also, should we
discuss/summarize the state of PWG Last Call (quorum was

achieved) comments on IPP Transaction-based Printing Ext?

Other topics for next Monday, anyone?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

--Apple-Mail=_6A1E9B85-7161-4A09-9A11-A42C4C5358CF-- --Apple-Mail=_1E0B2F1B-62D4-4DFC-9DAA-EA6E7712A0D7 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH2zCCB9cw gga/oAMCAQICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEFBQAwgfcxCzAJBgNVBAYTAlVT MSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9y aXR5IEcyMB4XDTEyMTEyNjAwMDAwMFoXDTE0MTEyNjIzNTk1OVowgZgxIDAeBgNVBAoUF0hld2xl dHQtUGFja2FyZCBDb21wYW55MSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVtcGxveWVl czEPMA0GA1UECxMGUy9NSU1FMRYwFAYDVQQDEw1TbWl0aCBLZW5uZWR5MSMwIQYJKoZIhvcNAQkB FhRzbWl0aC5rZW5uZWR5QGhwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmo HmmwCMk0tCSI1w6tYppeJX3YINwFC5wUIhCt8HcRW/Ass9n7BxP1MpBUScmYpaQOjFI+n6JueqNN lmHysW9wFG8FiSxowAf2C6cN+kmrV1MOzprrpjZZTB979lqRD/UG5RCo4BNy3aTTtqMFk7JkrL1Q H8yLa5IOgUd36N7bK3+nSz6W3X3jo5G8Eax5xJvwCioOQzzmclRKpoDRKFT35bHptUCD0VR7IY74 9Ik7+A4RBp52w7zKYrs6N59Hy0PxxEzOsQImUC7++mhRJtg5AdX75wAKb665v3b4RZjJBMQhjYdU 8Al3e/iq362nUqJmrFbNhpM9LSapjpbCm7ECAwEAAaOCA7owggO2MB8GA1UdEQQYMBaBFHNtaXRo Lmtlbm5lZHlAaHAuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAw TqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFu eVNNSU1FRzIvTGF0ZXN0Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAd BgNVHQ4EFgQU2ugcyk1Ph3Uvd67i/95+2TE174IwggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsG AQUFBzABhhtodHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQL EydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MIIB PQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBD b21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3JyZXNwb25kIHdp dGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0ZS4gSXNzdWVkIHRvIGZhY2ls aXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJl ZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwME MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG 9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEFBQADggEBAImyDkwpuUnbTsboOwpQAPQ4 M1jbZkfWS/mLo6oj6XOWApq9IQ1jkwowCWwwCA3F3wCbKQGphJ8HdLaVGY9AznOEQoixLHx9rnIT aq9lFeagCZiqtFq6/i33etWRb6dXp3FZYn9ikhYv74Ewil/ue61VqW9vOAZq51Wt9JznLmVSkJN1 1A4oJxNL8/jiK82tSXMkUHe07VbZUUF+t609D979rvVK68sw6P+cDe+46gy6oM9LHtINt8Fclro/ 45hQe0FdW1A1dmyx4dyKW/SbRK4uw5c0nXvaZn0Wrlnq2Rxm/wCNKnGxAtp0ir7/7ubR6GjB3xuf BjNLp57JgbuFIg4xggTeMIIE2gIBATCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXds ZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx NTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi 82zI/6Xyi7FlMAkGBSsOAwIaBQCgggKlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMDkxOTE1MTQzNFowIwYJKoZIhvcNAQkEMRYEFNbeqvl5wrkwjP92loyx+gad YBVmMIIBHwYJKwYBBAGCNxAEMYIBEDCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXds ZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkx NTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEw LwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi 82zI/6Xyi7FlMIIBIQYLKoZIhvcNAQkQAgsxggEQoIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIC EDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEBBQAEggEAc2eHd5hdVgdLhjjKFOAEWPWzPvbT SH5ZveVpP5M4lbkRqbnCGIkGAHiUlWrjlt2HPGrHMEleSumtSWDxiP8G2WxEIcgzEDZIpmE9y/gR QIAHSv/qMVCX5XBImspy8YMJX3O8jm75Esmd+cegP9GqoujXNX+pplxDvlII48+AWizYc4wZcC4z Rm7NpcOGUXf+L+0oLqKStw1J5W0gnjJH+BbiaadrRgnL5F2w1cb4v4/KPxzK/qq/HztCvHOak3aJ u9RJrcR9qkQEAqMD+4aUvMWQTNCkPW4f9v9dg7G7dxL/Mc5ua2JFMtkkNlKTlCixuYW7QumCREUA IKwx4VFHCAAAAAAAAA== --Apple-Mail=_1E0B2F1B-62D4-4DFC-9DAA-EA6E7712A0D7-- --===============1184233050== 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 --===============1184233050==-- From ipp-bounces@pwg.org Thu Sep 19 09:23:14 2013 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 0495321F958A for ; Thu, 19 Sep 2013 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHNFKlcANmUM for ; Thu, 19 Sep 2013 09:23:07 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E021F9473 for ; Thu, 19 Sep 2013 09:23:07 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id C79A68341; Thu, 19 Sep 2013 16:30:56 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by www.pwg.org (Postfix) with ESMTPS id 0AF1C807A for ; Thu, 19 Sep 2013 16:30:55 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id v2so5574952qcr.20 for ; Thu, 19 Sep 2013 09:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=b65Nsa4GgbQq7IHqLestSHosLWlPeuvgxlRj3tVnot4=; b=VUnYvYOaaghhdaeNqYPSoHn1Lw0k9z34KQKiRsu6Q4wwIx8H3rp9mpFnYtKp8z/NZa oW5D0A8xtMhCjRPTLqRwq3ytdIugotCjSPpO4QHqZzwVC42GR1xgziWj/RSsOna7Gm0R XOzhUPzT2WXGMPXixtK4vs/gX1SCBYGMdtrLeOV76abPnVyePt1/S0aOMsecQKSDdQf8 H0J+fEkOB1W7FQMTy4DI6LHyZnk130xGwcBBv8nDJ8i/ED9bvgXOuYerSH7OzA0z4GzU c2ClMZtYUwVM7POBm5w/s2E/v8vLLx1UawLW5nHy6d3j+UZ5VqmiK/ntCWkmKr+S2NsV CvkQ== X-Received: by 10.49.30.227 with SMTP id v3mr5176218qeh.92.1379607783447; Thu, 19 Sep 2013 09:23:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 19 Sep 2013 09:22:43 -0700 (PDT) From: Ira McDonald Date: Thu, 19 Sep 2013 12:22:43 -0400 Message-ID: To: "ipp@pwg.org" , Ira McDonald Subject: [IPP] IPP over HTTP Transport Binding and 'ipps' URI Scheme (19 September 2013) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1946619614==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1946619614== Content-Type: multipart/alternative; boundary=047d7bd767aedca40204e6bef7f7 --047d7bd767aedca40204e6bef7f7 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've just posted another Internet-Draft of IPP over HTTP Transport Binding and 'ipps' URI Scheme to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-08-20130919.txt - plaintext Internet-Draft format (warning - contains explicit formfeed characters) ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-08-20130919.pdf - PDF of plaintext w/ line numbers (review *this* one) This document has already been accepted and posted to the IETF I-D repository. This document was created by a complete rewrite of IPP URI Scheme [RFC3510]. This version has minor editorial changes since the previous version - see below. Comments? Cheers, - Ira ------------------------------------ Change History 19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt Global - Updated references, per IPP WG review. --047d7bd767aedca40204e6bef7f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I've just posted an= other Internet-Draft of IPP over HTTP Transport Binding and
'ip= ps' <= span>URI Scheme to:

=A0ftp://ftp.pwg.org/pub/pwg/ipp/wd/dra= ft-mcdonald-ipps-uri-scheme-08-20130919.txt
=A0- plaintext Internet-Draft format (warning - contains expl= icit formfeed characters)

=A0ftp://ftp.pwg.org/pub/pwg/ipp/wd/dra= ft-mcdonald-ipps-uri-scheme-08-20130919.pdf
=A0- PDF of plaintext w/ line numbers (review *this* one)

This document has already been accepted and posted to the IETF I-D repository.

This document was created by a complete rewrite of I= PP URI= Scheme=A0 [RFC3510].

This version has minor editorial changes since the previo= us version - see below.

Comments?

Cheers,
- Ira

----------------------------------= --

Change History

=A0=A0 19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt
=A0= =A0 Global - Updated references, per IPP WG review.=A0

--047d7bd767aedca40204e6bef7f7-- --===============1946619614== 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 --===============1946619614==-- From ipp-bounces@pwg.org Thu Sep 19 09:28:59 2013 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 E2EAD21F9983 for ; Thu, 19 Sep 2013 09:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdD63gi2908j for ; Thu, 19 Sep 2013 09:28:54 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85B21F9473 for ; Thu, 19 Sep 2013 09:28:54 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 743E48341; Thu, 19 Sep 2013 16:36:44 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by www.pwg.org (Postfix) with ESMTPS id 69C16807A for ; Thu, 19 Sep 2013 16:36:43 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id j7so3760714qaq.12 for ; Thu, 19 Sep 2013 09:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=BJXx49sA/lHemaDktYKBPf5JMGNyC+l/JSbz4eREvAQ=; b=cdJGrWm31nF5Ap2ucBPWcIexSwhRBGX4YjCRK0IZoBroGVwAnwykDz8Jmrzf+GPOZD VfgGyYlZlZoPsWdEYylbJizKNxQX+p83/HcqICcXZghG8l0qyv07iB4JFan2L4XXP8Js qlCcQVZmqOPYbnaWq+++maDeP6J4XtBqSGAXnUdkgu6eTU1zYSWyiZ4PRvHyiScZ9Afj XmxkLcXD7fDU2QnipG3AJ6qprdYDKvXZiVQZTZQORhBXOrNV4spfbV/OdqMNeVg7fiwh 3lQeoIdTS5oBPoWoDu9W7mUgxIRjC6K6swLIAj7PN4tuu2kNu3ktINpiiW9nSDhIclZ3 gWyg== X-Received: by 10.49.25.102 with SMTP id b6mr5022920qeg.91.1379608130227; Thu, 19 Sep 2013 09:28:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 19 Sep 2013 09:28:30 -0700 (PDT) From: Ira McDonald Date: Thu, 19 Sep 2013 12:28:30 -0400 Message-ID: To: "ipp@pwg.org" , Ira McDonald , Pat Fleming Subject: [IPP] LDAP Printer Schema (19 September 2013) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1597227408==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1597227408== Content-Type: multipart/alternative; boundary=047d7b621ac888200a04e6bf0c37 --047d7b621ac888200a04e6bf0c37 Content-Type: text/plain; charset=ISO-8859-1 Hi, I *have* assigned OIDs to the few new attributes, because we have a stable set chosen in section 4.1 of the IPP Everywhere spec. I've just posted a new Internet-Draft of LDAP Schema for Printer Services to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ldap-printer-schema-05-20130919.txt - plaintext Internet-Draft format (warning - contains explicit formfeed characters) ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ldap-printer-schema-05-20130919.pdf - line numbered PDF of plaintext - use this version for review, please This document has already been accepted and posted to the IETF I-D repository. This document was created by revising the original LDAP Schema for Printer Services [RFC3712]. Cheers, - Ira --------------------------------------- Change History 19 September 2013 - draft-mcdonald-ldap-printer-schema-05.txt - Sixth draft - for IEEE-ISTO PWG IPP WG - Global - updated publication and expiration dates in copyright, header, footer, and boilerplate. - Global - updated references, per IEEE-ISTO PWG IPP WG review. --047d7b621ac888200a04e6bf0c37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I *have* assigned OIDs to the= few new attributes, because we have a
stable set chosen in section 4.1= of the IPP Everywhere spec.

=A0I've just posted a new Internet-Draft of LDAP Schema for Printer S= ervices to:

=A0ftp://ftp.pwg.org/pub/pwg/ipp/wd= /draft-mcdonald-ldap-printer-schema-05-20130919.txt
=A0- plaintext Internet-Draft format (warning - contains explicit formfeed= characters)

=A0ftp://ftp.pwg.org/pub/pwg/ipp/wd= /draft-mcdonald-ldap-printer-schema-05-20130919.pdf
=A0- line numbered PDF of plaintext - use this version for review, please<= br>
This document has already been accepted and posted to the IETF I-D r= epository.

This document was created by revising the original = LDAP Schema for
Printer Services [RFC3712].

Cheers,
- Ira

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

Change Histo= ry
=A0=A0
=A0=A0 19 September 2013 - draft-mcdonald-ldap-printer-sch= ema-05.txt
=A0=A0 - Sixth draft - for IEEE-ISTO PWG IPP WG
=A0=A0 -= Global - updated publication and expiration dates in copyright,
=A0=A0 header, footer, and boilerplate.=A0
=A0=A0 - Global - updated re= ferences, per IEEE-ISTO PWG IPP WG review.=A0

--047d7b621ac888200a04e6bf0c37-- --===============1597227408== 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 --===============1597227408==-- From ipp-bounces@pwg.org Thu Sep 19 09:50:41 2013 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 614F121F93B1 for ; Thu, 19 Sep 2013 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hsou5Zueq1Er for ; Thu, 19 Sep 2013 09:50:35 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEC21F9346 for ; Thu, 19 Sep 2013 09:50:35 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 5172E8341; Thu, 19 Sep 2013 16:58:26 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id AAEA5807A for ; Thu, 19 Sep 2013 16:58:24 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MTD00ABZTE12M60@mail-out.apple.com> for ipp@pwg.org; Thu, 19 Sep 2013 09:49:53 -0700 (PDT) X-AuditID: 11807158-b7fea6d000001e19-7d-523b2b2fe8c0 Received: from [17.153.35.50] (Unknown_Domain [17.153.35.50]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id A6.D0.07705.03B2B325; Thu, 19 Sep 2013 09:49:53 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Thu, 19 Sep 2013 12:49:51 -0400 Message-id: <0C893243-2258-4944-8788-AAE24AB6E903@apple.com> References: To: Ira McDonald X-Mailer: Apple Mail (2.1811) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUiOFPZSNdQ2zrIYPEJNYvXr5ayWxzb95LF 4si3WItXXbuYHVg8tp78weaxc9Zddo9d23YyecxbPJ0pgCWKyyYlNSezLLVI3y6BK+Nv9zWm gqW6Fe2LihoYz6p3MXJySAiYSHxYsIsJwhaTuHBvPVsXIxeHkEA3k8S/fZfYQBLCArYSPTdb mUFsXgE9iUUNL1m6GDk4mAUSJCbfkwAJswmoSfye1McKYnMKBEpca3jGAmKzCKhKrHv/hhHE ZhaIl7i1ZiELxBgbiUUbX4ONFBIIkGh4fQxspIiAlsSS54oQ58hKfD66i20CI98sJItnISye BTZUW2LZwtfMELaexMumd+yY4roSF9dNYlzAyLaKUaAoNSex0lQvsaAgJ1UvOT93EyMohBsK I3Yw/l9mdYhRgINRiYe3QNA6SIg1say4MvcQowQHs5II745/VkFCvCmJlVWpRfnxRaU5qcWH GKU5WJTEeXfIAqUE0hNLUrNTUwtSi2CyTBycUg2M8S6vymc4KTUoaPF6/ZlRYn4zS5DTzJ71 WZrQLMVMJgubxMzuBFHXgI27k4WFgoMyJob/VmZJ3Xv+qt97/pvebZ/CFzxbLaZ+9+/KD7eT 716/uyRr5mqvmT5nZDtq27M9RPkT5d901q++tHtei7zpDbPTSxUSnfpuLrI1jfyblPjmZHDB 191KLMUZiYZazEXFiQDU1DjSXQIAAA== Cc: "ipp@pwg.org" Subject: Re: [IPP] Reminder and topics for IPP WG next Monday X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1791903446==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1791903446== Content-type: multipart/alternative; boundary="Boundary_(ID_pPgSiIzWMdsoyUH9cJne4w)" --Boundary_(ID_pPgSiIzWMdsoyUH9cJne4w) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Ira, I would like to cover both the last call comments for transactions and do a first reading of IPP Finishings 2.0. And I am working on updates of transactions and faxout right now... On Sep 19, 2013, at 11:05 AM, Ira McDonald wrote: > Hi, > > Smith - will you have an updated IPP Imp Guide v2 for review? > > Mike - should we do IPP Finishings review? Also, should we > discuss/summarize the state of PWG Last Call (quorum was > achieved) comments on IPP Transaction-based Printing Ext? > > Other topics for next Monday, anyone? > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - TCG Embedded Systems Hardcopy SG > 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 > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_pPgSiIzWMdsoyUH9cJne4w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Ira,

I would like to cover both = the last call comments for transactions and do a first reading of IPP = Finishings 2.0. And I am working on updates of transactions and = faxout right now...

On Sep 19, = 2013, at 11:05 AM, Ira McDonald <blueroofmusic@gmail.com> = wrote:

Hi,

Smith - = will you have an updated IPP Imp Guide v2 for review?

Mike = - should we do IPP Finishings review? Also, should = we
discuss/summarize the state of PWG Last Call (quorum was

achieved) comments on IPP Transaction-based Printing = Ext?

Other topics for next Monday, = anyone?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO = Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - = TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems = Hardcopy SG
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
Winter 579 Park = Place Saline, MI 48176 734-944-0094
Summer PO = Box 221 Grand Marais, MI 49839 906-494-2434

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

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_pPgSiIzWMdsoyUH9cJne4w)-- --===============1791903446== 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 --===============1791903446==-- From ipp-bounces@pwg.org Thu Sep 19 10:58:50 2013 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 7954D21F93F8 for ; Thu, 19 Sep 2013 10:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRhmxt5BzDm5 for ; Thu, 19 Sep 2013 10:58:45 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id BBFBB21F9473 for ; Thu, 19 Sep 2013 10:58:45 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id E24178423; Thu, 19 Sep 2013 18:06:30 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by www.pwg.org (Postfix) with ESMTPS id 1F26C8406 for ; Thu, 19 Sep 2013 18:06:29 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id k4so3791528qaq.4 for ; Thu, 19 Sep 2013 10:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sdwJFeHjJfK2yyYXfNSXHW8LNpiKgRM6tbAdIsgCDog=; b=AzJPxRgvViNlwWu3Up1ETpffmbP88jVD/UeDYhIAm8/t9FxILmtH96e9+BJU3cJhOY dl8iiQPjw3FalTlrTPKycuAVBDETYRI3kzmb1MPgXbvhbDmzBjFHVxNDJSB2AM0asnMy hgLo/V01h7pAMIdYHVFXShC3b0rZpGN0pXtPcotTwHKDtLf38ErTHwi5dr8NODsrTxPi hBFTWglqlOQIuB7rfES8FMGTJ1iI7mKQ7ZGEsCqTEUQnP56ljVuI20HhjfgYbQimhPot wXPqaAdKBZpRF1kCjGhIMYGFE8t7sKV7YTONEQ3WXqJ/3Bkw4KzGAYGlsheG6jPrHrJv dKjg== X-Received: by 10.49.98.100 with SMTP id eh4mr6139390qeb.42.1379613516753; Thu, 19 Sep 2013 10:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 19 Sep 2013 10:58:16 -0700 (PDT) In-Reply-To: <0C893243-2258-4944-8788-AAE24AB6E903@apple.com> References: <0C893243-2258-4944-8788-AAE24AB6E903@apple.com> From: Ira McDonald Date: Thu, 19 Sep 2013 13:58:16 -0400 Message-ID: To: Michael Sweet , Ira McDonald Cc: "ipp@pwg.org" Subject: Re: [IPP] Reminder and topics for IPP WG next Monday X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0415407980==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0415407980== Content-Type: multipart/alternative; boundary=047d7bdc957497f21704e6c04d54 --047d7bdc957497f21704e6c04d54 Content-Type: text/plain; charset=ISO-8859-1 Hi, Smith - if there are loose ends so what? Post some work-in-progress if you can. Mike - thanks for all your hard work - try to sleep once in a while. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Sep 19, 2013 at 12:49 PM, Michael Sweet wrote: > Ira, > > I would like to cover both the last call comments for transactions and do > a first reading of IPP Finishings 2.0. And I am working on updates of > transactions and faxout right now... > > > On Sep 19, 2013, at 11:05 AM, Ira McDonald > wrote: > > Hi, > > Smith - will you have an updated IPP Imp Guide v2 for review? > > Mike - should we do IPP Finishings review? Also, should we > discuss/summarize the state of PWG Last Call (quorum was > achieved) comments on IPP Transaction-based Printing Ext? > > Other topics for next Monday, anyone? > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - TCG Embedded Systems Hardcopy SG > 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 > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > --047d7bdc957497f21704e6c04d54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Smith - if there are = loose ends so what?=A0 Post some work-in-progress if you can.

= Mike - thanks for all your hard work - try to sleep once in a while.

Cheers,

- Ira

Ira McDonald (Musician / Software Architect)
Chair = - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Workin= g Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

On Thu, Sep 19, 2013 at 12:49 PM, Michae= l Sweet <msweet@apple.com> wrote:

Ira,

I would like to= cover both the last call comments for transactions and do a first reading = of IPP Finishings 2.0. =A0And I am working on updates of transactions and f= axout right now...

On Sep 19, 2013, a= t 11:05 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:

=

= Hi,

Smith - will you have an updated IPP Imp Guide v2 for revi= ew?

Mike - should we do IPP Finishings review?=A0 Also, should= we

discuss/summarize the state of PWG Last Call (quorum was

achieved) comments on IPP Transaction-based Printing Ext?

Other topics for next Monday, anyone?

Cheers,
- Ira=

Ira McDonald (Musician / Software = Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer = Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted = Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF D= esignated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-9= 44-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

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

_________________________________________________________
Michael Sweet,= Senior Printing System=A0Engineer, PWG Chair

--047d7bdc957497f21704e6c04d54-- --===============0415407980== 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 --===============0415407980==-- From ipp-bounces@pwg.org Fri Sep 20 06:17:12 2013 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 B353221F99FB for ; Fri, 20 Sep 2013 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.762 X-Spam-Level: X-Spam-Status: No, score=-101.762 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_50=0.001, GB_I_INVITATION=-2, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8+959KjKKPb for ; Fri, 20 Sep 2013 06:17:08 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9721F9A19 for ; Fri, 20 Sep 2013 06:17:05 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 798FA864D; Fri, 20 Sep 2013 13:24:59 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from sjmda04.webex.com (sjmda04.webex.com [64.68.122.184]) by www.pwg.org (Postfix) with ESMTPS id 519CD85BB for ; Fri, 20 Sep 2013 13:24:58 +0000 (UTC) Received: from jta2tc302.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-2.webex.com [64.68.121.246]) by sjmda04.webex.com (8.14.3/8.13.1) with ESMTP id r8KDH2Kl015007 for ; Fri, 20 Sep 2013 13:17:02 GMT Received: from jta2tc302.webex.com (localhost [127.0.0.1]) by jta2tc302.webex.com (Postfix) with ESMTP id 6315FA00EB for ; Fri, 20 Sep 2013 13:17:02 +0000 (GMT) Date: Fri, 20 Sep 2013 13:17:02 +0000 (GMT) From: PWG WebEx To: ipp@pwg.org Message-ID: <1767066439.81981.1379683022404.JavaMail.nobody@jta2tc302.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_81979_1708692673.1379683022403" X-Priority: 3 Importance: normal Subject: [IPP] Meeting invitation: IPP/Cloud WG X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: msweet@apple.com List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org ------=_Part_81979_1708692673.1379683022403 Content-Type: multipart/Alternative; boundary="----=_Part_81980_1846427427.1379683022403" ------=_Part_81980_1846427427.1379683022403 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvICwKClBXRyBXZWJFeCBpbnZpdGVzIHlvdSB0byBhdHRlbmQgdGhpcyBvbmxpbmUgbWVl dGluZy4KClRvcGljOiBJUFAvQ2xvdWQgV0cKRGF0ZTogRXZlcnkgTW9uZGF5LCBmcm9tIE1vbmRh eSwgU2VwdGVtYmVyIDIzLCAyMDEzIHRvIG5vIGVuZCBkYXRlClRpbWU6IDM6MDAgcG0sIEVhc3Rl cm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkKTWVldGluZyBOdW1iZXI6IDY4 MiA3NjMgMzkzCk1lZXRpbmcgUGFzc3dvcmQ6IFByaW50aW5nMTIzCgoKLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUbyBqb2luIHRoZSBvbmxp bmUgbWVldGluZyAoTm93IGZyb20gbW9iaWxlIGRldmljZXMhKQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCjEuIEdvIHRvIGh0dHBzOi8vaWVl ZS1pc3RvLndlYmV4LmNvbS9pZWVlLWlzdG8vai5waHA/RUQ9MTUyNjk5NDIyJlVJRD0xMTgzNzYy NTM3JlBXPU5ZVE01TlROaE5qVXkmUlQ9TWlNeE1RJTNEJTNECjIuIElmIHJlcXVlc3RlZCwgZW50 ZXIgeW91ciBuYW1lIGFuZCBlbWFpbCBhZGRyZXNzLgozLiBJZiBhIHBhc3N3b3JkIGlzIHJlcXVp cmVkLCBlbnRlciB0aGUgbWVldGluZyBwYXNzd29yZDogUHJpbnRpbmcxMjMKNC4gQ2xpY2sgIkpv aW4iLgoKVG8gdmlldyBpbiBvdGhlciB0aW1lIHpvbmVzIG9yIGxhbmd1YWdlcywgcGxlYXNlIGNs aWNrIHRoZSBsaW5rOgpodHRwczovL2llZWUtaXN0by53ZWJleC5jb20vaWVlZS1pc3RvL2oucGhw P0VEPTE1MjY5OTQyMiZVSUQ9MTE4Mzc2MjUzNyZQVz1OWVRNNU5UTmhOalV5Jk9SVD1NaU14TVEl M0QlM0QKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCkZvciBhc3Npc3RhbmNlCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KMS4gR28gdG8gaHR0cHM6Ly9pZWVlLWlzdG8ud2ViZXguY29t L2llZWUtaXN0by9tYwoyLiBPbiB0aGUgbGVmdCBuYXZpZ2F0aW9uIGJhciwgY2xpY2sgIlN1cHBv cnQiLgoKWW91IGNhbiBjb250YWN0IG1lIGF0Ogptc3dlZXRAYXBwbGUuY29tCgoKVG8gYWRkIHRo aXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyIHByb2dyYW0gKGZvciBleGFtcGxlIE1pY3Jvc29m dCBPdXRsb29rKSwgY2xpY2sgdGhpcyBsaW5rOgpodHRwczovL2llZWUtaXN0by53ZWJleC5jb20v aWVlZS1pc3RvL2oucGhwP0VEPTE1MjY5OTQyMiZVSUQ9MTE4Mzc2MjUzNyZJQ1M9TUkmTEQ9MSZS RD0yJlNUPTEmU0hBMj1BQUFBQXZzR3psTERYT1FPLzN0VnJNV0RyYU82aURLaVVoWjZZdnVKMGxP YmdGM2UmUlQ9TWlNeE1RJTNEJTNECgoKClNpZ24gdXAgZm9yIGEgZnJlZSB0cmlhbCBvZiBXZWJF eApodHRwOi8vd3d3LndlYmV4LmNvbS9nby9tY2VtZnJlZXRyaWFsCgpodHRwOi8vd3d3LndlYmV4 LmNvbQoKCgpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBm ZWF0dXJlIHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRl cmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3Jk ZWQuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIHRoZSByZWNvcmRpbmcs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJpb3IgdG8gdGhl IHN0YXJ0IG9mIHRoZSByZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uIFBsZWFz ZSBub3RlIHRoYXQgYW55IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3ViamVjdCB0byBkaXNjb3Zl cnkgaW4gdGhlIGV2ZW50IG9mIGxpdGlnYXRpb24uCg== ------=_Part_81980_1846427427.1379683022403 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+PGZvbnQgRkFDRT0nVGFob21hLCBBcmlhbCwgc2Fucy1zZXJpZiwgSGVsdmV0aWNhLCBH ZW5ldmEnIHNpemU9JzInPjxicj4gSGVsbG8gLCA8YnI+IDxicj4gUFdHIFdlYkV4IGludml0ZXMg eW91IHRvIGF0dGVuZCB0aGlzIG9ubGluZSBtZWV0aW5nLiA8YnI+IDxicj4gVG9waWM6IElQUC9D bG91ZCBXRyA8YnI+IERhdGU6IEV2ZXJ5IE1vbmRheSwgZnJvbSBNb25kYXksIFNlcHRlbWJlciAy MywgMjAxMyB0byBubyBlbmQgZGF0ZSA8YnI+IFRpbWU6IDM6MDAgcG0sIEVhc3Rlcm4gRGF5bGln aHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkgPGJyPiBNZWV0aW5nIE51bWJlcjogNjgyIDc2 MyAzOTMgPGJyPiBNZWV0aW5nIFBhc3N3b3JkOiBQcmludGluZzEyMyA8YnI+IDxicj4gPGJyPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxi cj4gVG8gam9pbiB0aGUgb25saW5lIG1lZXRpbmcgKE5vdyBmcm9tIG1vYmlsZSBkZXZpY2VzISkg PGJyPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIDxicj4gMS4gR28gdG8gPEEgaHJlZj0naHR0cHM6Ly9pZWVlLWlzdG8ud2ViZXguY29tL2ll ZWUtaXN0by9qLnBocD9FRD0xNTI2OTk0MjImVUlEPTExODM3NjI1MzcmUFc9TllUTTVOVE5oTmpV eSZSVD1NaU14TVElM0QlM0QnIHRhcmdldD0gJ19ibGFuayc+aHR0cHM6Ly9pZWVlLWlzdG8ud2Vi ZXguY29tL2llZWUtaXN0by9qLnBocD9FRD0xNTI2OTk0MjImVUlEPTExODM3NjI1MzcmUFc9TllU TTVOVE5oTmpVeSZSVD1NaU14TVElM0QlM0Q8L0E+IDxicj4gMi4gSWYgcmVxdWVzdGVkLCBlbnRl ciB5b3VyIG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuIDxicj4gMy4gSWYgYSBwYXNzd29yZCBpcyBy ZXF1aXJlZCwgZW50ZXIgdGhlIG1lZXRpbmcgcGFzc3dvcmQ6IFByaW50aW5nMTIzIDxicj4gNC4g Q2xpY2sgIkpvaW4iLiA8YnI+IDxicj4gVG8gdmlldyBpbiBvdGhlciB0aW1lIHpvbmVzIG9yIGxh bmd1YWdlcywgcGxlYXNlIGNsaWNrIHRoZSBsaW5rOiA8YnI+IDxBIGhyZWY9J2h0dHBzOi8vaWVl ZS1pc3RvLndlYmV4LmNvbS9pZWVlLWlzdG8vai5waHA/RUQ9MTUyNjk5NDIyJlVJRD0xMTgzNzYy NTM3JlBXPU5ZVE01TlROaE5qVXkmT1JUPU1pTXhNUSUzRCUzRCcgdGFyZ2V0PSAnX2JsYW5rJz5o dHRwczovL2llZWUtaXN0by53ZWJleC5jb20vaWVlZS1pc3RvL2oucGhwP0VEPTE1MjY5OTQyMiZV SUQ9MTE4Mzc2MjUzNyZQVz1OWVRNNU5UTmhOalV5Jk9SVD1NaU14TVElM0QlM0Q8L0E+IDxicj4g PGJyPiA8YnI+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gPGJyPiBGb3IgYXNzaXN0YW5jZSA8YnI+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPiAxLiBHbyB0byA8QSBocmVmPSdo dHRwczovL2llZWUtaXN0by53ZWJleC5jb20vaWVlZS1pc3RvL21jJyB0YXJnZXQ9ICdfYmxhbmsn Pmh0dHBzOi8vaWVlZS1pc3RvLndlYmV4LmNvbS9pZWVlLWlzdG8vbWM8L0E+IDxicj4gMi4gT24g dGhlIGxlZnQgbmF2aWdhdGlvbiBiYXIsIGNsaWNrICJTdXBwb3J0Ii4gPGJyPiA8YnI+IFlvdSBj YW4gY29udGFjdCBtZSBhdDogPGJyPiAgPEEgaHJlZj0nbWFpbHRvOm1zd2VldEBhcHBsZS5jb20n Pm1zd2VldEBhcHBsZS5jb208L0E+IDxicj4gPGJyPiA8YnI+IFRvIGFkZCB0aGlzIG1lZXRpbmcg dG8geW91ciBjYWxlbmRhciBwcm9ncmFtIChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgT3V0bG9vayks IGNsaWNrIHRoaXMgbGluazogPGJyPiA8QSBocmVmPSdodHRwczovL2llZWUtaXN0by53ZWJleC5j b20vaWVlZS1pc3RvL2oucGhwP0VEPTE1MjY5OTQyMiZVSUQ9MTE4Mzc2MjUzNyZJQ1M9TUkmTEQ9 MSZSRD0yJlNUPTEmU0hBMj1BQUFBQXZzR3psTERYT1FPLzN0VnJNV0RyYU82aURLaVVoWjZZdnVK MGxPYmdGM2UmUlQ9TWlNeE1RJTNEJTNEJyB0YXJnZXQ9ICdfYmxhbmsnPmh0dHBzOi8vaWVlZS1p c3RvLndlYmV4LmNvbS9pZWVlLWlzdG8vai5waHA/RUQ9MTUyNjk5NDIyJlVJRD0xMTgzNzYyNTM3 JklDUz1NSSZMRD0xJlJEPTImU1Q9MSZTSEEyPUFBQUFBdnNHemxMRFhPUU8vM3RWck1XRHJhTzZp REtpVWhaNll2dUowbE9iZ0YzZSZSVD1NaU14TVElM0QlM0Q8L0E+IDxicj4gPGJyPiA8YnI+IDxi cj4gU2lnbiB1cCBmb3IgYSBmcmVlIHRyaWFsIG9mIFdlYkV4IDxicj4gPEEgaHJlZj0naHR0cDov L3d3dy53ZWJleC5jb20vZ28vbWNlbWZyZWV0cmlhbCcgdGFyZ2V0PSAnX2JsYW5rJz5odHRwOi8v d3d3LndlYmV4LmNvbS9nby9tY2VtZnJlZXRyaWFsPC9BPiA8YnI+IDxicj4gPEEgaHJlZj0naHR0 cDovL3d3dy53ZWJleC5jb20nIHRhcmdldD0gJ19ibGFuayc+aHR0cDovL3d3dy53ZWJleC5jb208 L0E+IDxicj4gPGJyPiA8YnI+IDxicj4gSU1QT1JUQU5UIE5PVElDRTogVGhpcyBXZWJFeCBzZXJ2 aWNlIGluY2x1ZGVzIGEgZmVhdHVyZSB0aGF0IGFsbG93cyBhdWRpbyBhbmQgYW55IGRvY3VtZW50 cyBhbmQgb3RoZXIgbWF0ZXJpYWxzIGV4Y2hhbmdlZCBvciB2aWV3ZWQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRp Y2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0 byB0aGUgcmVjb3JkaW5nLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgbWVldGluZyBo b3N0IHByaW9yIHRvIHRoZSBzdGFydCBvZiB0aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5IGJlIHN1 YmplY3QgdG8gZGlzY292ZXJ5IGluIHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLiA8YnI+IDwvZm9u dD48L2h0bWw+ ------=_Part_81980_1846427427.1379683022403-- ------=_Part_81979_1708692673.1379683022403 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 ------=_Part_81979_1708692673.1379683022403-- From ipp-bounces@pwg.org Fri Sep 20 09:12:46 2013 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 10B9F21F9C13 for ; Fri, 20 Sep 2013 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfd8waBkxRhy for ; Fri, 20 Sep 2013 09:12:40 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC9121F9BF0 for ; Fri, 20 Sep 2013 09:12:40 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id B61EF8660; Fri, 20 Sep 2013 16:20:34 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id 8A916864D for ; Fri, 20 Sep 2013 16:20:33 +0000 (UTC) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MTF00ITRMCK5UV0@mail-out.apple.com> for ipp@pwg.org; Fri, 20 Sep 2013 09:12:20 -0700 (PDT) X-AuditID: 11807166-b7fd66d000006a64-4b-523c73dbb7c8 Received: from [17.153.29.60] (Unknown_Domain [17.153.29.60]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 58.D5.27236.CD37C325; Fri, 20 Sep 2013 09:12:13 -0700 (PDT) From: Michael Sweet Date: Fri, 20 Sep 2013 12:12:10 -0400 To: ipp@pwg.org Message-id: <2BB42B0C-98C1-47A4-B4A9-B6AE47916615@apple.com> X-Mailer: Apple Mail (2.1811) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUiOFPWRvdusU2Qweu9AhbH9r1ksTjyLdaB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgynj0ZCJ7wRbRiqXXD7A3MJ4X7mLk5JAQMJHY cf89M4QtJnHh3nq2LkYuDiGBbiaJzrOPGUESbAJqEr8n9bGC2MwCCRIP9+8Da2ARUJVYOLuB DcQWFrCS+HzsLli9iAC/xMSLEPW8AjYSB2cfYoOw9SQWNbxkgVgmK/H56C62CYzcs5CMnYWk DCKuLbFs4WugOAeQrSMxeSEjRFheYvvbOcwwJR/PH2FawMi2ilGgKDUnsdJCL7GgICdVLzk/ dxMjKLAaCtN2MDYttzrEKMDBqMTD+yDEJkiINbGsuDL3EKMEB7OSCG9tAVCINyWxsiq1KD++ qDQntfgQozQHi5I4b/Y96yAhgfTEktTs1NSC1CKYLBMHp1QDo+QUns1iU8LPhU2cGqezL3LN HtP5iqV8Ky7M3bWiL8u9rOPMkm4Py1Mimd9ib63Vmmp9WL5Zn7N7S61j2AMuqZ92fFNuidjO 290n2cf5bOaXr/makQ8/ik3V6GXkCX1z/MounfjYAu55sxf0yfcfWu72cKKS3LcpuvXWSd9K xdjDmBe5CGzQVmIpzkg01GIuKk4EAC8HoJEoAgAA Subject: [IPP] Updated stable draft of IPP FaxOut Service posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1040325849==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1040325849== Content-type: multipart/alternative; boundary="Boundary_(ID_c5RZEKGdWjb0UPSHYKL+PA)" --Boundary_(ID_c5RZEKGdWjb0UPSHYKL+PA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have completed the edits to the IPP FaxOut Service specification and posted a new stable draft to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130920.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130920.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130920-rev.pdf I will be announcing a new WG last call for this document later today... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_c5RZEKGdWjb0UPSHYKL+PA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

I have completed the edits to the IPP FaxOut Service specification and posted a new stable draft to:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130920.docx

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130920.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130920-rev.pdf

I will be announcing a new WG last call for this document later today...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--Boundary_(ID_c5RZEKGdWjb0UPSHYKL+PA)-- --===============1040325849== 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 --===============1040325849==-- From ipp-bounces@pwg.org Sun Sep 22 21:00:47 2013 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 2590711E80D2 for ; Sun, 22 Sep 2013 21:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhddv6UCOfR7 for ; Sun, 22 Sep 2013 21:00:41 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id B1C0821F9CEA for ; Sun, 22 Sep 2013 21:00:41 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id E4AFF8479; Mon, 23 Sep 2013 04:08:47 +0000 (UTC) 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 www.pwg.org (Postfix) with ESMTPS id AF90D807A for ; Mon, 23 Sep 2013 04:08:46 +0000 (UTC) MIME-version: 1.0 Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MTK00MK28H0RW81@mail-out.apple.com> for ipp@pwg.org; Sun, 22 Sep 2013 21:00:39 -0700 (PDT) X-AuditID: 1180715a-b7f8e6d000006c98-51-523fbce58a22 Received: from [17.153.30.126] (Unknown_Domain [17.153.30.126]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 1D.C4.27800.6ECBF325; Sun, 22 Sep 2013 21:00:39 -0700 (PDT) From: Michael Sweet Date: Mon, 23 Sep 2013 00:00:36 -0400 To: ipp@pwg.org Message-id: X-Mailer: Apple Mail (2.1811) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUiOFOuTvf5Hvsggyk3uSyO7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlbHz3WLGgrmiFWeebGFvYDwi3MXIwSEhYCJx erJYFyMnkCkmceHeerYuRi4OIYFeJokjkx+xgCTYBNQkfk/qYwWxmQUSJO62TGUEsVkEVCX2 re9nBrGFBaIl5py5CVYvIsAvMfEiRD2vgI3E1s7J7BC2nsSihpcsEMtkJT4f3cU2gZF7FpKx s5CUQcS1JZYtfM08C+hUZgEdickLGSHC8hLb385hhin5eP4I0wJGtlWMAkWpOYmVZnqJBQU5 qXrJ+bmbGEFh1VAYtYOxYbnVIUYBDkYlHt6IRPsgIdbEsuLK3EOMEhzMSiK8TZ1AId6UxMqq 1KL8+KLSnNTiQ4zSHCxK4rzfG2yChATSE0tSs1NTC1KLYLJMHJxSDYxmj29H/n1694aEzluz nP1n792+ulktUrth5spPUo/2HVWLPPIoMfXr2ZuXGAwrquQtfD/lL/Odf+6Bk8h3ngOqrnmP as/0G5RdFGtaxrVhx42X/0ysfHUtZl4X5rA8cDFil9khnnWbFaUmF3TxCx46dPXRYXsGjmkt pmL9U7zPWVkV/+KKVPmqxFKckWioxVxUnAgA8YUBNicCAAA= Subject: [IPP] Updated Last Call review draft of IPP Transaction-Based Printing Extensions posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1692186139==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1692186139== Content-type: multipart/alternative; boundary="Boundary_(ID_tFJniW6M/cC3CGdFqw2+Qw)" --Boundary_(ID_tFJniW6M/cC3CGdFqw2+Qw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted a new draft of the IPP Transaction-Based Printing Extensions specifications with Last Call resolutions to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922-rev.pdf For review at the next IPP conference call... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_tFJniW6M/cC3CGdFqw2+Qw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

I have posted a new draft of the IPP Transaction-Based Printing Extensions specifications with Last Call resolutions to:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922.docx

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922-rev.pdf

For review at the next IPP conference call...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--Boundary_(ID_tFJniW6M/cC3CGdFqw2+Qw)-- --===============1692186139== 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 --===============1692186139==-- From ipp-bounces@pwg.org Mon Sep 23 10:17:47 2013 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 74D3D21F9F31 for ; Mon, 23 Sep 2013 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKczV9SI9E9q for ; Mon, 23 Sep 2013 10:17:41 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id C8D5521F9EE0 for ; Mon, 23 Sep 2013 10:17:41 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id BFE238533; Mon, 23 Sep 2013 17:25:49 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by www.pwg.org (Postfix) with ESMTPS id 65F4384D6 for ; Mon, 23 Sep 2013 17:25:48 +0000 (UTC) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 5ACBD24488 for ; Mon, 23 Sep 2013 17:17:38 +0000 (UTC) Received: from G9W3612.americas.hpqcorp.net (16.216.186.47) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Sep 2013 17:16:50 +0000 Received: from G9W0739.americas.hpqcorp.net ([169.254.10.155]) by G9W3612.americas.hpqcorp.net ([16.216.186.47]) with mapi id 14.03.0123.003; Mon, 23 Sep 2013 17:16:49 +0000 From: "Kennedy, Smith (Wireless Architect)" To: "" Thread-Topic: IPP/2.0 Implementer's Guide updated and available for review Thread-Index: AQHOuICwMP+1ibKKsUWcAAZFqZJNmQ== Date: Mon, 23 Sep 2013 17:16:49 +0000 Message-ID: <60B01DA2-CB72-49D6-98A0-9AACAF85C4B9@hp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.30] Content-ID: <5BD0C36FE6DE5746ACD7978D08464789@Compaq.com> MIME-Version: 1.0 Subject: [IPP] IPP/2.0 Implementer's Guide updated and available for review X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org Greetings, I have just posted an update to the IPP/2.0 Implementer's Guide. It is available here: ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-20130923.pdf ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-20130923.docx ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-20130923-rev.pdf This should be considered a "new baseline". There are a number of sections that need to be filled out more completely and comments visible in the -rev.pdf document. But at Ira's recommendation, I decided to get a new revision posted rather than wait any longer. Cheers, Smith /** Smith Kennedy Hewlett-Packard Co. */ _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Sep 23 10:30:48 2013 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 8072621F9A2E for ; Mon, 23 Sep 2013 10:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhxE9j5ZLclG for ; Mon, 23 Sep 2013 10:30:44 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id DA7A721F9CA1 for ; Mon, 23 Sep 2013 10:30:43 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 1BC8084C0; Mon, 23 Sep 2013 17:38:52 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by www.pwg.org (Postfix) with ESMTPS id A4E15849D for ; Mon, 23 Sep 2013 17:38:50 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id k4so1685507qaq.18 for ; Mon, 23 Sep 2013 10:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ppzSwWMFA8q16P7cv8ZInGn5d5vPj5dcMPx4M68CTNo=; b=eZ9PRilue3SypShIV2QD7yMLtTCDzuY8fMOoKONbSfmxh6bVoZqc7XRqacnXosoA7R uw2A3tuZnNG+wADDST87vHmfSc3Hm/5gPPpNF46wSYJE8jo0yp/iI4PJyjdwgmMPgnVE lqGuqDn0H21KCqXQTrLyeoXtSjX3fXO8dBHA0xKjzDsjZHSd+i/YWAvMjtY0H/VLzODG Z/xeesxm6WTZQjw0NhocXte51wnecW/zWmeeWO1vzJcdNnQQqnhxvEygqMWZcDtUHolR v6KhfEUcMYtwBnvLxeENyHKX1Ij4Ci84fkJzTXkJAqu725ftxjYprJS9xvQaSrQqhyiC f9xw== X-Received: by 10.224.88.136 with SMTP id a8mr3422435qam.106.1379957439784; Mon, 23 Sep 2013 10:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Mon, 23 Sep 2013 10:30:19 -0700 (PDT) From: Ira McDonald Date: Mon, 23 Sep 2013 13:30:19 -0400 Message-ID: To: "ipp@pwg.org" , Ira McDonald Subject: [IPP] IPP Agenda - 3-5pm Eastern 9 September 2013 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807005295==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1807005295== Content-Type: multipart/alternative; boundary=001a11c2bb4c00f97c04e71061e3 --001a11c2bb4c00f97c04e71061e3 Content-Type: text/plain; charset=ISO-8859-1 Hi, Our next IPP WG call is this week Monday 23 September 12-2pm US Pacific / 3-5pm US Eastern 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) ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: IPP/Cloud WG Date: Every Monday, from Monday, September 23, 2013 to no end date Time: 3:00 pm, Eastern Daylight Time (New York, GMT-04:00) Meeting Number: 682 763 393 Meeting Password: Printing123 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422&UID=1183762537&PW=NYTM5NTNhNjUy&RT=MiMxMQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: Printing123 4. Click "Join". To view in other time zones or languages, please click the link: https://ieee-isto.webex.com/ieee-isto/j.php?ED=152699422&UID=1183762537&PW=NYTM5NTNhNjUy&ORT=MiMxMQ%3D%3D ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ieee-isto.webex.com/ieee-isto/mc 2. On the left navigation bar, click "Support". ------------------------------------------------------- Agenda: (1) PWG IP Policy and Minute Taker - Mike (2) Approve IPP minutes from previous meetings - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130909.pdf (3) Status of various IPP documents (Ira/Mike/Smith) * IPP over HTTPS Transport Binding and 'ipps' URI Scheme (Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-08-20130919.pdf -- sent to IETF Application Area Directors 19 September * LDAP Printer Schema - ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ldap-printer-schema-05-20130919.pdf -- sent to IETF Application Area Directors 19 September * IPP WG Charter (Ira) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-charter-20130919-rev.pdf -- waiting for PWG SC review and approval * IPP Implementors Guide v2 (Smith) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20130722-rev.pdf -- reviewed at PWG F2F on 6 August 2013 -- waiting for new draft from Smith * IPP Fax Out (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130920.pdf -- updated based on first PWG Last Call -- Mike to announce second PWG Last Call * IPP Self-Certification (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert10-20130731-rev.pdf -- waiting for new draft from Mike * IPP Shared Infrastructure Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130730-rev.pdf -- completed review at IPP WG on 9 September 2013 -- waiting for new draft from Mike (3) Review of IPP Transaction-based Printing Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922-rev.pdf -- PWG Last Call ended on 13 September 2013 -- comments? -- waiting for PC SC approval and PWG Formal Vote (4) Proposal to add IPP firmware attributes from PWG 5110.1 (Mike) - http://www.pwg.org/archives/ipp/2013/017668.html -- email on 17 September 2013 -- comments? (5) Review of IPP Finishings v2.0 (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfinishings20-20130814.pdf -- comments? (6) Next steps - IPP WG telecon on Monday 7 October - IPP sessions at PWG F2F telecon on 22/23 October - IPP WG telecon on Monday 4 November Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 --001a11c2bb4c00f97c04e71061e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Our next IPP WG call is this week Monday 23 = September 12-2pm US Pacific / 3-5pm US Eastern

Call-in toll-free num= ber (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 A= ccess Code: *******#
Attendee ID Code: # (empty)

----------------= ---------------------------------------
Meeting information
----------------------------------------------------= ---
Topic: IPP/Cloud WG
Date: Every Monday, from Monday, September 23, 2013 = to no end date
Time: 3:00 pm, Eastern Daylight Time (New York, GMT-04:00= )
Meeting Number: 682 763 393
Meeting Password: Printing123
------= -------------------------------------------------
To join the online meeting (Now from mobile devices!)
------------------= -------------------------------------
1. Go to https://ieee-isto.webex.com/ieee-isto/= j.php?ED=3D152699422&UID=3D1183762537&PW=3DNYTM5NTNhNjUy&RT=3DM= iMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is = required, enter the meeting password: Printing123
4. Click "Join&qu= ot;.
To view in other time zones or languages, please click the link: https://ieee= -isto.webex.com/ieee-isto/j.php?ED=3D152699422&UID=3D1183762537&PW= =3DNYTM5NTNhNjUy&ORT=3DMiMxMQ%3D%3D
-------------------------------------------------------
For assistance-------------------------------------------------------
1. Go to https://ieee-isto.webex.com= /ieee-isto/mc
2. On the left navigation bar, click "Support".
-------------------------------------------------------

= Agenda:
(1) PWG IP Po= licy and Minute Taker
- Mike

(2) Approve IPP minutes from previous meetings

- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-c= oncall-minutes-20130909.pdf

(3) Status of various IP= P documents (Ira/Mike/Smith)

* IPP over HTTPS Transport Binding and 'ipps' URI Scheme= (Ira)
- ftp://ftp.pwg.org/pub/pwg/ip= p/wd/draft-mcdonald-ipps-uri-scheme-08-20130919.pdf

-- sent to IETF Application Area Directors 19 September

<= /div>

* LDAP Printer Schema
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ldap-printer-schema-05-201= 30919.pdf
-- sent to IETF Application Area Directors 19 September

* IPP WG Cha= rter (Ira)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-charter= -20130919-rev.pdf

-- waiting for PWG SC review and approval

* IPP Implementors Guide v2 (Smith)

- ftp://= ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20130722-rev.pdf

-- reviewed at PWG F2F on 6 August 2013
-- waiting for new draft f= rom Smith

* IPP Fax Out (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/w= d-ippfaxout10-20130920.pdf

-- updated based on first PWG Last Call

-- Mike to= announce second PWG Last Call

* IPP Self-Certification (Mike)
- ftp://ftp.pwg= .org/pub/pwg/ipp/wd/wd-ippeveselfcert10-20130731-re= v.pdf
-- waiting for new draft from Mike

* IPP Shared Infrastructure Exten= sions (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130730-rev.pdf

-- completed review at IPP WG on 9 September 2013

= -- waiting for new draft from Mike
=A0

(3) Review of IPP Transaction-b= ased Printing Extensions (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130922-rev.pdf

-- PWG Last Call ended on 13 September 2013

-- comments?
<= /div>

-- waiting for PC SC approval and PWG Formal Vote

(4) Proposal to add IPP firmware attributes from P= WG 5110.1 (Mike)
- http://www.p= wg.org/archives/ipp/2013/017668.html

-- email on 17 Septe= mber 2013

-- comments?

(5) Review of = IPP Finishings v2.0 (Mike)

- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfinishings20-20130814.pdf

-- comments?

(6) Next steps=

- IPP WG telecon on Monday 7 October

- IPP sessions a= t PWG F2F telecon on 22/23 October

- IPP WG telecon on Monday 4 November

Cheers,

- Ira

--001a11c2bb4c00f97c04e71061e3-- --===============1807005295== 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 --===============1807005295==-- From ipp-bounces@pwg.org Mon Sep 23 10:33:18 2013 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 7C1B321F9DF7 for ; Mon, 23 Sep 2013 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.367 X-Spam-Level: X-Spam-Status: No, score=0.367 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ljwRlTF0hlO for ; Mon, 23 Sep 2013 10:33:13 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id C001B21F9E01 for ; Mon, 23 Sep 2013 10:33:13 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 8CA8F84D3; Mon, 23 Sep 2013 17:41:22 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by www.pwg.org (Postfix) with ESMTPS id E6E7784C0 for ; Mon, 23 Sep 2013 17:41:20 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id p19so2284256qcv.11 for ; Mon, 23 Sep 2013 10:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4V+EFN7YHX9n93/W7KVojrRoj6QTnVgMwGcbi5KQQdU=; b=QLo+iURKnyWNYsOjpIDBkyk3x4qhuGDKbGMPcPrx1ep8EZ+47LppBu1/JldhxXMKX2 6/ipAWEw0Neaw/Nd2Trnus35SR9gDos4MKm/wkfNH4TzqT3euqWXgesDve48aocqwk4X AiylbfM6biUj7LuzE+iTdWjktLJWEG7nl5hb3lljE1Khm1/O9NjhWp4vpmgdnWOy8gpP +F6cbN5PvW+gu8VYH3gJJZNmEPfIj5ImpRz2fn4UvHZMFequeRTNWo1PNFkij/95MzGa ZBULgOyV2EyzASXPT5CA6KzpYzFBKmsCtzW9SyPCHwHWHCth+fyXFajmW3UXzwmRHhJ4 k/xg== X-Received: by 10.49.98.100 with SMTP id eh4mr24209824qeb.42.1379957590505; Mon, 23 Sep 2013 10:33:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Mon, 23 Sep 2013 10:32:49 -0700 (PDT) In-Reply-To: <60B01DA2-CB72-49D6-98A0-9AACAF85C4B9@hp.com> References: <60B01DA2-CB72-49D6-98A0-9AACAF85C4B9@hp.com> From: Ira McDonald Date: Mon, 23 Sep 2013 13:32:49 -0400 Message-ID: To: "Kennedy, Smith (Wireless Architect)" , Ira McDonald Cc: "" Subject: Re: [IPP] IPP/2.0 Implementer's Guide updated and available for review X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Internet Printing Protocol Workgroup discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1445516675==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1445516675== Content-Type: multipart/alternative; boundary=047d7bdc9574fcc78904e71069be --047d7bdc9574fcc78904e71069be Content-Type: text/plain; charset=ISO-8859-1 Hi, My simultaneous agenda was incomplete. We'll review this today if we get time. Order in agenda is TBD. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Sep 23, 2013 at 1:16 PM, Kennedy, Smith (Wireless Architect) < smith.kennedy@hp.com> wrote: > Greetings, > > I have just posted an update to the IPP/2.0 Implementer's Guide. It is > available here: > > ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-20130923.pdf > ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-20130923.docx > ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-20130923-rev.pdf > > This should be considered a "new baseline". There are a number of > sections that need to be filled out more completely and comments visible in > the -rev.pdf document. But at Ira's recommendation, I decided to get a new > revision posted rather than wait any longer. > > Cheers, > > Smith > > /** > Smith Kennedy > Hewlett-Packard Co. > */ > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > --047d7bdc9574fcc78904e71069be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

My simultaneous agenda was = incomplete.=A0 We'll review this today if we get time.

Or= der in agenda is TBD.

Cheers,

- Ira

=

Ira McDonald (Music= ian / Software Architect)
Chair - Linux Foundation Open Printing WG
S= ecretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP = WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded System= s Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roo= f Music/High North Inc
http://sites.google.= com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

On Mon, Sep 23, 2013 at 1:16 PM, Kennedy= , Smith (Wireless Architect) <smith.kennedy@hp.com> wrote= :

Greetings,

I have just posted an update to the IPP/2.0 Implementer's Guide. =A0It = is available here:

ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-2= 0130923.pdf
ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig20-= 20130923.docx
ftp://ftp.pwg.org/home/pwg/pub/pwg/ipp/wd/wd-ippig= 20-20130923-rev.pdf

This should be considered a "new baseline". =A0There are a number= of sections that need to be filled out more completely and comments visibl= e in the -rev.pdf document. =A0But at Ira's recommendation, I decided t= o get a new revision posted rather than wait any longer.

Cheers,

Smith

/**
=A0 =A0 Smith Kennedy
=A0 =A0 Hewlett-Packard Co.
*/

_______________________________________________
ipp mailing list
ipp@pwg.org
http= s://www.pwg.org/mailman/listinfo/ipp

--047d7bdc9574fcc78904e71069be-- --===============1445516675== 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 --===============1445516675==-- From ipp-bounces@pwg.org Mon Sep 23 10:39:29 2013 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 AF66421F9FEE for ; Mon, 23 Sep 2013 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKhdfFo83IJE for ; Mon, 23 Sep 2013 10:39:25 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1021F9FDE for ; Mon, 23 Sep 2013 10:39:25 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 429C884D3; Mon, 23 Sep 2013 17:47:33 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by www.pwg.org (Postfix) with ESMTPS id 6D07584C0 for ; Mon, 23 Sep 2013 17:47:32 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id a11so2314237qen.37 for ; Mon, 23 Sep 2013 10:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ybxNTyYQ698M4gglpUVp3z6uit5YicL3m4m7j7QKQTs=; b=hObr8FnTO/SrVwXXkWA6sbOQMr0knrn5gTTE5MUYImmhyzAnPFZC/aToMnFbTgjhWI Po9ndkdf3avs1zWBWhWTA3P+OcBBKTXCEHfVIBz2T0viEf8jIByfQZJaHyUvP6ae+A56 6we7xDoAvL+Z0Fk+02K9N/oeyAW6LLAmLdFp/sebk42T9hUWLStDm0Lqlrsc9hyg+HC0 UuYcdBK3Nh1EbECVPdV85JLpLPnStL0VTUsEw6zDBnaPOGsBSylPfr7Km0YLg7bW3g3F LBpbS9AFJDa5Tmal5zFaDL4FjNQtoRjLPQuNzbjH9M/0ya/R4MZxB4QqLLWJxsRd/h9m +5hg== X-Received: by 10.49.71.106 with SMTP id t10mr24534051qeu.26.1379957803195; Mon, 23 Sep 2013 10:36:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Mon, 23 Sep 2013 10:36:22 -0700 (PDT) In-Reply-To: <60B01DA2-CB72-49D6-98A0-9AACAF85C4B9@hp.com> References: <60B01DA2-CB72-49D6-98A0-9AACAF85C4B9@hp.com> From: Ira McDonald Date: Mon, 23 Sep 2013 13:36:22 -0400 Message-ID: To: "Kennedy, Smith (Wireless Architect)" Cc: ""