From pwg-announce-bounces@pwg.org Mon Aug 6 08:56:02 2012 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 465B221F85E7 for ; Mon, 6 Aug 2012 08:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_20=-0.74, 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 FTQBy7cMaR1A for ; Mon, 6 Aug 2012 08:56:01 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id E135E21F85ED for ; Mon, 6 Aug 2012 08:56:00 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A87C87924F; Mon, 6 Aug 2012 11:55:42 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by pwg.org (Postfix) with ESMTP id 954957924D for ; Mon, 6 Aug 2012 11:55:28 -0400 (EDT) Received: by lbbgm6 with SMTP id gm6so3194837lbb.5 for ; Mon, 06 Aug 2012 08:55:27 -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=hC4TNl4jK3iMtqvmA+56tlotTwviNZ6VhIrvXGkdkoc=; b=g8Zehip2plKzKkl98Ugn6qFqu3KKcrzV4TYkS7CPMTG5RoJIDeL9Q1TbBHBiYdUf+Y IODcrxFT2bVhrmpWEZwc4ze2Kwq6ebtJ2Abx20oL68bm9AV7BH3o7WatWtCGiWPWZu6U 8/QyOroFw7nS+BUorJqZz+z8AIZhjwWJoh369QT9WLhjKmiQ6p4ChidHIXrNSuCthnma 5FbkWBK0SK77aooBpQQdyrZ64hOHsFiomd+2B4g2N4EsWdvTYM7PrSFxPR/6fN/OkPFw hPw5cCp4FOPG4zSEV1KdngZSM3u22+kfUO7F/+UIutW2IGKjYtNO+aTaWbLQ/2Ru8aOr O6vQ== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr11395779lab.9.1344268527309; Mon, 06 Aug 2012 08:55:27 -0700 (PDT) Received: by 10.112.81.200 with HTTP; Mon, 6 Aug 2012 08:55:27 -0700 (PDT) Date: Mon, 6 Aug 2012 11:55:27 -0400 Message-ID: From: Ira McDonald To: pwg-announce@pwg.org, Ira McDonald X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [Pwg-Announce] Fwd: Live Meeting for August F2F X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1253637708==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: A87C87924F.AC62D X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============1253637708== Content-Type: multipart/alternative; boundary=e89a8f22c4110d945b04c69ae8fa --e89a8f22c4110d945b04c69ae8fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Murdock, Joe Date: Thu, Jul 26, 2012 at 4:55 PM Subject: [SC] Alternative Live meeting arrangements To: "sc@pwg.org" I=92ve set up a three day Live Meeting for the August F2F, in case there a= re problems with Mike=92s setup:**** ** ** Subject: PWG August F2F meeting**** Start Time: Monday, Aug 6, 2012 8:00 AM PDT**** End Time: Wednesday, Aug 8, 2012 5:00 PM PDT**** Occurrence: One time meeting**** Attendee URL: https://www.livemeeting.com/cc/sla/join?id=3DPWG-August-F2F&role=3Dattend&p= w=3DLetMeAttend **** Meeting ID: PWG-August-F2F**** Presenter Entry Code: LetMePresent**** Attendee Entry Code: LetMeAttend**** Location: Redmond, WA**** ** ** ---------------------------------------**** Joe Murdock**** Principal Engineer and Researcher**** Chair IEEE/ISTO Printer Working Group Imaging Device Security**** Sharp Labs of America**** 5750 NW Pacific Rim Blvd**** Camas, WA 98607**** (360) 817-7542**** jmurdock@sharplabs.com**** ** ** --=20 This message has been scanned for viruses and dangerous content by *MailScanner* , and is believed to be clean. _______________________________________________ SC mailing list SC@pwg.org https://www.pwg.org/mailman/listinfo/sc --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --e89a8f22c4110d945b04c69ae8fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: Murdock, Joe &= lt;jmurdock@sharplabs.com>=
Date: Thu, Jul 26, 2012 at 4:55 PM
Subject: [SC] Alternative Live meetin= g arrangements
To: "sc@pwg.org&qu= ot; <sc@pwg.org>


I=92ve set up a three day Live Meeting for the Augus= t F2F, in case there are problems with Mike=92s setup:

=A0

Subject:=A0 PWG August F2F meeting

Start Time:=A0 Monday, Aug 6, 2012 8:00 AM PDT

End Time:=A0 Wednesday, Aug 8, 2012 5:00 PM PDT

Occurrence:=A0 One time meeting


Attendee URL:=A0 https://www.livemeeting.com/cc/sla/join?id=3DPWG-August-= F2F&role=3Dattend&pw=3DLetMeAttend

Meeting ID:=A0 PWG-August-F2F

Presenter Entry Code:=A0 LetMePresent<= /p>

Attendee Entry Code:=A0 LetMeAttend

Location:=A0 Redmond, WA

=A0

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

Joe Murdock

Principal Engineer a= nd Researcher

Chair IEEE/ISTO Prin= ter Working Group Imaging Device Security

Sharp Labs of Americ= a

5750 NW Pacific Rim = Blvd

Camas, WA 98607

(360) 817-7542

jmurdock= @sharplabs.com=

=A0


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

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



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --e89a8f22c4110d945b04c69ae8fa-- --===============1253637708== 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 --===============1253637708==-- From pwg-announce-bounces@pwg.org Tue Aug 7 11:22:09 2012 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 94F3521F855A for ; Tue, 7 Aug 2012 11:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_50=0.001, 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 v3Y7DsELpjcw for ; Tue, 7 Aug 2012 11:22:08 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id B1EEE21F8550 for ; Tue, 7 Aug 2012 11:22:08 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D062E791A2; Tue, 7 Aug 2012 14:21:50 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by pwg.org (Postfix) with ESMTP id 655DD79199 for ; Tue, 7 Aug 2012 14:21:33 -0400 (EDT) Received: by lboi8 with SMTP id i8so23486lbo.5 for ; Tue, 07 Aug 2012 11:21:33 -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=y5thwzLddHjnCJ8wWv8PSyBUh+8OLz57INDyuSAuplk=; b=t8HnsSyOmLQU8tG33DH8sIzVRZzYjGTbdgo8GK7Za+6R48ctwyFsJaQGNjxqMXxUKF IgdvFTm4QjSAgHf6MGQToRF9L+1zlNru2NOAHdqvkowM7zcq7OEtdOzMXuppqJSH37sN VJBo8Dsadh7/fTsbkrGgJxYc/3BJcrGjwDSETYgC9gLzW3+QBo8e5d1xPX0r0qAR4HNh YWblen9W3DSM/bPFRMleYRPJXf1JE8K7w6OLr6JTUFjX/Z97fn5disoRuDKJmWqYaZcD g+/Vvry9ASiwP/mTCL47Z7IJm+5xpqXIPuaArpw6HH+XL1YmFmrGmHAIAzwYHgU52w47 YfDw== MIME-Version: 1.0 Received: by 10.112.103.135 with SMTP id fw7mr6669304lbb.25.1344363692924; Tue, 07 Aug 2012 11:21:32 -0700 (PDT) Received: by 10.112.81.200 with HTTP; Tue, 7 Aug 2012 11:21:32 -0700 (PDT) Date: Tue, 7 Aug 2012 14:21:32 -0400 Message-ID: From: Ira McDonald To: pwg-announce@pwg.org, Ira McDonald X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [Pwg-Announce] Posted PWG Plenary minutes (6 August 2012) X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2058711235==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: D062E791A2.ABEE5 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============2058711235== Content-Type: multipart/alternative; boundary=14dae9d7181a5d9e8f04c6b11078 --14dae9d7181a5d9e8f04c6b11078 Content-Type: text/plain; charset=ISO-8859-1 Hi, Minutes for yesterday's PWG Plenary are posted at: ftp://ftp.pwg.org/pub/pwg/general/minutes/pwg-plenary-minutes-20120806.htm Cheers, - Ira (PWG Secretary) 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 Temporary Cabin *** 2012 only *** 906-494-2523 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --14dae9d7181a5d9e8f04c6b11078 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Minutes for yesterday's PWG Plenary are posted at:

= =A0 ftp://ftp.pwg.org/pub/pwg/general/minutes= /pwg-plenary-minutes-20120806.htm

Cheers,
- Ira (PWG Secretary)

Ira McDonald (Mus= ician / Software Architect)
Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IP= P 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
Temporary Cabin= *** 2012 only *** 906-494-2523
=


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --14dae9d7181a5d9e8f04c6b11078-- --===============2058711235== 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 --===============2058711235==-- From ipp-bounces@pwg.org Wed Aug 8 08:27:58 2012 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 B198821F86BB for ; Wed, 8 Aug 2012 08:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, 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 JV8kKVYaQOmN for ; Wed, 8 Aug 2012 08:27:55 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id A805E21F86B7 for ; Wed, 8 Aug 2012 08:27:55 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id B8461791CF; Wed, 8 Aug 2012 11:27:40 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by pwg.org (Postfix) with ESMTP id 02776791CA for ; Wed, 8 Aug 2012 11:27:28 -0400 (EDT) Received: by lboi8 with SMTP id i8so592301lbo.5 for ; Wed, 08 Aug 2012 08:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CdWckZikMR5Yav1wxWZwq1g6hU3683mBn92UjBXmRUY=; b=ibyKOrH+U27eibGBr+dvpxYwjIqueaPJ/xSkgrd20n+fQWAkqby+4iMEvzNkRtdk4U 5IkfBoblUizFUsy0KMi+9bgdUbLSK1B5VLD7cudIVAYRLQhYWuSpfIO4CXtoN1KumyrK KTnLcRPW2zDSg07AimehRW6hkUpOdwbEGKWnOgthz1D9FMPHnG+E4NRY80wnlMIStwF2 +FSg1d3BK/lquTnBqBn2o7snQImPjMvX4IQ6HA4t1OvrUgtrLscRYIgnUIWs1yq8WSvY E+ogpqqsDAxQRLyeWPWYUOwUIFPcX6lBFfTfsE9q7JurWeuXsDQYWxTj2CGt09KnpqOa BlJA== MIME-Version: 1.0 Received: by 10.112.36.42 with SMTP id n10mr8067593lbj.7.1344439647747; Wed, 08 Aug 2012 08:27:27 -0700 (PDT) Received: by 10.112.81.200 with HTTP; Wed, 8 Aug 2012 08:27:27 -0700 (PDT) In-Reply-To: References: <201207301603.q6UG3s6b023932@smtp1.lax.icann.org> Date: Wed, 8 Aug 2012 11:27:27 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Ira McDonald X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Fwd: [IANA #596009] General Request for Assignment (ipp-registrations) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2046478736==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: B8461791CF.A908A X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============2046478736== Content-Type: multipart/alternative; boundary=e0cb4efe309ea0402504c6c2bf17 --e0cb4efe309ea0402504c6c2bf17 Content-Type: text/plain; charset=ISO-8859-1 Hi, IANA has completed the IPP JPS3 registrations. Cheers, - Ira ---------- Forwarded message ---------- From: Amanda Baber via RT Date: Tue, Aug 7, 2012 at 8:46 PM Subject: [IANA #596009] General Request for Assignment (ipp-registrations) To: blueroofmusic@gmail.com Hi, This update is up. Please see http://www.iana.org/assignments/ipp-registrations thanks, Amanda Baber IANA On Mon Jul 30 16:03:57 2012, blueroofmusic@gmail.com wrote: > > Contact Name: > Ira McDonald > > Contact Email: > blueroofmusic@gmail.com > > Type of Assignment: > Permanent registration updates in IPP Registry > > Copy of revised IANA XML registry is at: > ftp://ftp.pwg.org/pub/pwg/ipp/IANA-IPP-registrations/ > in the file ipp-registrations-20120727-jps3.xml > > Changes: > - Added IANA IPP Registry additions from section 14 of > PWG Candidate Standard 5100.13-2012 > IPP Job and Printer Extensions - Set 3 (JPS3) > ftp://ftp.pwg.org/pub/pwg/candidates/ > cs-ippjobprinterext3v10-20120727-5100.13.pdf > > > Registry: > IANA IPP Registry > http://www.iana.org/assignments/ipp-registrations/ipp- > registrations.xml > > Description: > Proposed: Mike Sweet (Apple) > Reviewed: By IETF Designated Experts for IPP Registry > Approved: 30 July 2012 > By: Ira McDonald (IETF Designated Expert for IPP Registry) > > Additional Info: > New operations, attributes, values, and status codes defined in IPP > JPS3 (PWG 5100.13-2012), edited by Mike Sweet (Apple, joint IETF > Designated Expert for IPP Registry) > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --e0cb4efe309ea0402504c6c2bf17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

IANA has completed the IPP JPS3 registrations.

Cheers,- Ira


---------- Forwarded message ----------<= br>From: Amanda Baber via RT <iana-prot-param@iana.= org>
Date: Tue, Aug 7, 2012 at 8:46 PM
Subject: [IANA #596009] General Reques= t for Assignment (ipp-registrations)
To: blueroofmusic@gmail.com


Hi,

This update is up. Please see

http://www.iana.org/assignments/ipp-registrations

thanks,

Amanda Baber
IANA

On Mon Jul 30 16:03:57 2012, blu= eroofmusic@gmail.com wrote:
>
> Contact Name:
> Ira McDonald
>
> Contact Email:
> blueroofmusic@gmail.com=
>
> Type of Assignment:
> Permanent registration updates in IPP Registry
>
> Copy of revised IANA XML registry is at:
> ftp://ftp.pwg.org/pub/pwg/ipp/IANA-IPP-registrations/
> in the file ipp-registrations-20120727-jps3.xml
>
> Changes:
> - Added IANA IPP Registry additions from section 14 of
> =A0 PWG Candidate Standard 5100.13-2012
> =A0 IPP Job and Printer Extensions - Set 3 (JPS3)
> =A0 ftp://ftp.pwg.org/pub/pwg/candidates/
> =A0 =A0 cs-ippjobprinterext3v10-20120727-5100.13.pdf
>
>
> Registry:
> IANA IPP Registry
> http://www.iana.org/assignments/ipp-registrations/ipp- > registrations.xml
>
> Description:
> Proposed: Mike Sweet (Apple)
> Reviewed: By IETF Designated Experts for IPP Registry
> Approved: 30 July 2012
> By: Ira McDonald (IETF Designated Expert for IPP Registry)
>
> Additional Info:
> New operations, attributes, values, and status codes defined in IPP
> JPS3 (PWG 5100.13-2012), edited by Mike Sweet (Apple, joint IETF
> Designated Expert for IPP Registry)
>





--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --e0cb4efe309ea0402504c6c2bf17-- --===============2046478736== 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 --===============2046478736==-- From ipp-bounces@pwg.org Wed Aug 8 16:00:57 2012 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 CB38611E8098 for ; Wed, 8 Aug 2012 16:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, 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 RsylY3XkwJVe for ; Wed, 8 Aug 2012 16:00:57 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id CC7B811E80A6 for ; Wed, 8 Aug 2012 16:00:56 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id EF3D7791D6; Wed, 8 Aug 2012 19:00:41 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 86278791D4 for ; Wed, 8 Aug 2012 19:00:28 -0400 (EDT) MIME-version: 1.0 Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M8G00F7GJMW4WD3@mail-out.apple.com> for ipp@pwg.org; Wed, 08 Aug 2012 16:00:27 -0700 (PDT) X-AuditID: 11807134-b7f866d000002583-7e-5022ef89b4bd Received: from [17.151.79.70] (Unknown_Domain [17.151.79.70]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 22.9A.09603.B8FE2205; Wed, 08 Aug 2012 16:00:27 -0700 (PDT) From: Michael Sweet Date: Wed, 08 Aug 2012 19:00:26 -0400 To: "ipp@pwg.org" Message-id: <79A93BA2-4B8E-4142-8558-480C728129F5@apple.com> X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUiON3fTbf7vVKAQf8SDYtj+16yWBz5FuvA 5LH15A82j3mLpzMFMEVx2aSk5mSWpRbp2yVwZbw8NoW94JZARd+q80wNjFP5uxg5OSQETCT2 33jFCGGLSVy4t56ti5GLQ0hgMpPEwzutzCAJNgE1id+T+lhBbGaBBImX1x6CNbAIqEgs/n6N BcQWFjCWWNu/ig3EFhGQl1jbNpUJxOYVsJE42b+KHcLWk5jdPocFYpmsxPfD59kmMHLPQjJ2 FpIyiLi8xPa3c5hnMXIA2ToSkxcyogqD2NoSH88fYVrAyLaKUbAoNSex0tBEL7GgICdVLzk/ dxMjKLQaCk12MB78yX+IUYCDUYmH9/JapQAh1sSy4srcQ4wSHMxKIrzV24BCvCmJlVWpRfnx RaU5qcWHGKU5WJTEeXt3AKUE0hNLUrNTUwtSi2CyTBycUg2MTG7H8pkvmp7q5T7InCW03m19 VZd+Y+d+hnuGi9Ju7Gmb6rnydOn+A7c89JWfSQuffcRXlxbYwzO/dXbSgYuf1BO/RpZ0rbPi E3Uw+dwtIeYe9v43y+c3J3tSRfX0fPq5JJ/9X72uevubjW9l47uedjon7W85dbzPWqD3+MMZ 3qe3nwyIDi9RYinOSDTUYi4qTgQAMZ0NdykCAAA= X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Minutes posted for yesterday's F2F session X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573220587==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: EF3D7791D6.A8AAB X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1573220587== Content-type: multipart/alternative; boundary="Boundary_(ID_tHCCkHI8801ZySnlI9gaQQ)" --Boundary_(ID_tHCCkHI8801ZySnlI9gaQQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted the minutes from yesterday's F2F session to: ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20120807.pdf Action items: - Mike to post stable draft of MSN2 for WG Last Call - Mike to post F2F review comments as last call feedback for IPP Everywhere _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_tHCCkHI8801ZySnlI9gaQQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

I have posted the minutes from yesterday's F2F session to:


Action items:

- Mike to post stable draft of MSN2 for WG Last Call
- Mike to post F2F review comments as last call feedback for IPP Everywhere

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_tHCCkHI8801ZySnlI9gaQQ)-- --===============1573220587== 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 --===============1573220587==-- From ipp-bounces@pwg.org Wed Aug 8 16:05:05 2012 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 65EBC11E8121 for ; Wed, 8 Aug 2012 16:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, 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 K-z1M13jjPVJ for ; Wed, 8 Aug 2012 16:05:04 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 263FD11E8098 for ; Wed, 8 Aug 2012 16:05:04 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D1F50791A8; Wed, 8 Aug 2012 19:04:48 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id CBD1A791D6 for ; Wed, 8 Aug 2012 19:04:36 -0400 (EDT) MIME-version: 1.0 Received: from relay15.apple.com ([17.128.113.54]) 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 <0M8G00JWAKE834BC@mail-out.apple.com> for ipp@pwg.org; Wed, 08 Aug 2012 16:04:36 -0700 (PDT) X-AuditID: 11807136-b7fed6d000005bf5-3f-5022f0829d5b Received: from [17.151.79.70] (Unknown_Domain [17.151.79.70]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 12.84.23541.380F2205; Wed, 08 Aug 2012 16:04:36 -0700 (PDT) From: Michael Sweet Date: Wed, 08 Aug 2012 19:04:34 -0400 To: "ipp@pwg.org" Message-id: <3459420A-539C-4E61-B6B5-2CB35B434EA9@apple.com> X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUiON3fTbflg1KAwb3lrBbH9r1ksTjyLdaB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgyjg6bRFTwQKliuUn/zI3MB6W7WLk4JAQMJH4 Mj2zi5ETyBSTuHBvPRuILSQwmUmiYa0fiM0moCbxe1IfK4jNLJAg0d2zjR3EZhFQkTj5/TuY LSzgK3F/61QmEFtEQF5ibRuEzStgI7HoWy8bhK0nMbt9DgvELlmJ74fPs01g5J6FZOwsJGUQ cW2JZQtfM0PYBhJPO1+xYorrS7x5N4dpASPbKkbBotScxEpDU73EgoKcVL3k/NxNjKDAaig0 28G446/cIUYBDkYlHt6La5UChFgTy4orcw8xSnAwK4nwVm8DCvGmJFZWpRblxxeV5qQWH2KU 5mBREuft2wGUEkhPLEnNTk0tSC2CyTJxcEo1MObk/z5vkDNrgknXAt09Vcf275ne/nWvJdep yD21hdr5n3defD8tefFhSeN0wYvOrV85p/T0qZ4ODuRzKbokwfGdZ+P5nIubTx+9LSorGeLH 67tH2ITnsUsKr3dQT6dufMdasS8/N3O94JOW5ZR02fjoivBS1YJ938MWdHcaeM+Zfa0sbFX3 TiWW4oxEQy3mouJEAENHwEwoAgAA X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Apple has reviewed the IPP Everywhere specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0934205016==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: D1F50791A8.A9420 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0934205016== Content-type: multipart/alternative; boundary="Boundary_(ID_KBIplm4anZw8/hmB4n54xw)" --Boundary_(ID_KBIplm4anZw8/hmB4n54xw) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Feedback from the IPP F2F session: =95 Lines 988-999: media-supported =95 Global: "might report" -> "could report" or "would report" =95 Change ranges of dimensions (N-M) to "N to M". =95 "in width" -> wide =95 "in length" -> long =95 Section 4.2.3: =95 After "here are the limits of a TXT record" we list a LOT of keys. How= to determine what is important? =95 DUUID + UUID =3D 20% of 400 octets? =95 What about UUIDs for other services? =95 That will be a job for system control service =95 Add text for multiple print service devices: primary/default is listed= in TXT record, others accessible indirectly, no multiple queue reporting d= ue to interoperability/stability issues. =95 Update text to identify 400 octet limit is unicast DNS limit and 1300 = octets is multicast DNS limit (up to 64k for DNS over TCP) =95 Section 4.2.3.8: =95 Make DUUID optional =95 Section 6.1: "Supporting Long-Edge Feed Media with PWG Raster Format Do= cuments" =95 Sections 9.1 and 9.2: Add bullets for sections 6.1, 10, 11, 13 =95 Section 10: Add network unicode references a la JPS3 =95 Global: Update JPS3 references to PWG 5100.13 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_KBIplm4anZw8/hmB4n54xw) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Feedback from the IPP= F2F session:

=95 Lines 988-999: media-supported
=95 Global: "might report" -> "could report" or "would report"
=95 Change ranges of dimensions (N-M) to "N to M".
=95 "in width" -> wide
=95 "in length" -> long
=95 Section 4.2.3:
=95 After "here are the limits of a TXT rec= ord" we list a LOT of keys. How to determine what is important?
= =95 DUUID + UUID =3D 20% of 400 octets?
=95 What about UUIDs for other = services?
=95 That will be a job for system control service
<= div> =95 Ad= d text for multiple print service devices: primary/default is listed in TXT= record, others accessible indirectly, no multiple queue reporting due= to interoperability/stability issues.
=95 Update text to identify 400 = octet limit is unicast DNS limit and 1300 octets is multicast DNS limi= t (up to 64k for DNS over TCP)
=95 Section 4.2.3.8:
=
=95 M= ake DUUID optional
=95 Section 6.1: "Supporting Long-Edge Fee= d Media with PWG Raster Format Documents"
=95 Sections 9.1 an= d 9.2: Add bullets for sections 6.1, 10, 11, 13
=95 Section 1= 0: Add network unicode references a la JPS3
=95 Global: Updat= e JPS3 references to PWG 5100.13


____________________= _____________________________________
Michael Sweet, Senior Printing Sys= tem Engineer, PWG Chair


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_KBIplm4anZw8/hmB4n54xw)-- --===============0934205016== 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 --===============0934205016==-- From ipp-bounces@pwg.org Tue Aug 14 15:26:03 2012 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 56D0C21F860F for ; Tue, 14 Aug 2012 15:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG8iXxPRSGVF for ; Tue, 14 Aug 2012 15:26:02 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0D21F85F7 for ; Tue, 14 Aug 2012 15:26:02 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 59BCD79198; Tue, 14 Aug 2012 18:25:43 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 71D0E79197 for ; Tue, 14 Aug 2012 18:25:29 -0400 (EDT) MIME-version: 1.0 Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M8R008VLMOGK88C@mail-out.apple.com> for ipp@pwg.org; Tue, 14 Aug 2012 15:25:26 -0700 (PDT) X-AuditID: 11807130-b7fb86d000004da6-d6-502ad0554f12 Received: from [17.151.66.198] (Unknown_Domain [17.151.66.198]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 0D.B3.19878.650DA205; Tue, 14 Aug 2012 15:25:26 -0700 (PDT) From: Michael Sweet Message-id: Date: Tue, 14 Aug 2012 18:25:27 -0400 References: To: "ipp@pwg.org" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUiON3pmG7YBa0Ag8nP1CyO7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlbF3hWvBK62Kfyu2sDYw9qh1MXJySAiYSGzp 72CEsMUkLtxbzwZiCwlMZZJYdTwIxGYTUJP4PamPFcRmFkiQWLz+A3MXIwcHr4CNxLR7JSBh XgE9idntc1hAbBYBVYn595aDlQsLFEm8PncdrFxIwFGicVMpSFhEQF5ibdtUJoitshLfD59n m8DIMwvJgllIpkLEtSWWLXwNFOcAsnUkJi9kRBWGsD+eP8K0gJFtFaNgUWpOYqWhoV5iQUFO ql5yfu4mRlCoNRQa7GBc+5P/EKMAB6MSD++PnVoBQqyJZcWVuYcYJTiYlUR4v28CCvGmJFZW pRblxxeV5qQWH2KU5mBREuft2aEUICSQnliSmp2aWpBaBJNl4uCUamCUeFdn/Ov84zy5k78e zGCddnRTptb/niuXfA5p7t6m8XZf25e/pkIK83xnxwSGJXwtPv9y9rG2r2K3bu+cvCm+IOfT XfeQN737fvfZzymu0bDbcG6mwJ4b3SkKs9x1685LPxW9MdfCtjex5j13wMHfu7p0LHbvXXS8 r+DFGyVt46bWfKlT0yyvKLEUZyQaajEXFScCAHAWXIQxAgAA X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Fwd: [IANA #565794] Request for MIME media type Image/Standards Tree -pwg-raster [www.ietf.org/rt #49511] X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0840850498==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 59BCD79198.A8BE2 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0840850498== Content-type: multipart/alternative; boundary="Boundary_(ID_trvyxBB335XA/9apXRWUGg)" --Boundary_(ID_trvyxBB335XA/9apXRWUGg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, The PWG Raster Format is now registered with IANA... Begin forwarded message: > From: Amanda Baber via RT > Subject: [IANA #565794] Request for MIME media type Image/Standards Tree -pwg-raster [www.ietf.org/rt #49511] > Date: August 14, 2012 6:10:54 PM EDT > To: msweet@apple.com > Reply-To: iana-mime@iana.org > > Dear Michael, > > IANA has registered the following media type with you as the > point of contact: > > Image/Standards Tree pwg-raster > > Please see > > http://www.iana.org/assignments/media-types/image/ > > If you need to update the contact information, please send a > message to iana@iana.org. > > Best regards, > > Amanda Baber > IANA Analyst > ICANN > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_trvyxBB335XA/9apXRWUGg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
All,

<= /div>The PWG Raster Format is now registered with IANA...


=
Begin forwarded message:

=
From: Amanda Baber via RT &= lt;iana-mime@iana.org>
Subject: [IANA #565794] Request for MIME = media type Image/Standards Tree -pwg-raster [www.ietf.org/rt #49511]
<= span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0= , 1.0);">Date: August 14, 2012 6:10:54 PM EDT
<= span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0= , 1.0);">To: msweet@apple.com

Dear Michael,

IA= NA has registered the following media type with you as the
point of con= tact:

Image/Standards Tree pwg-raster

Please see

http://www.iana.= org/assignments/media-types/image/

If you need to update the con= tact information, please send a
message to iana@iana.org.

Best r= egards,

Amanda Baber
IANA Analyst
ICANN


_________________________________________________= ________
Michael Sweet, Senior Printing System Engineer, PWG Chair<= /div>


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_trvyxBB335XA/9apXRWUGg)-- --===============0840850498== 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 --===============0840850498==-- From pwg-announce-bounces@pwg.org Fri Aug 17 11:00:20 2012 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 E142311E80E2 for ; Fri, 17 Aug 2012 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZhUexhgDYls for ; Fri, 17 Aug 2012 11:00:19 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8C13A11E80D1 for ; Fri, 17 Aug 2012 11:00:19 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 2EE0F791D6; Fri, 17 Aug 2012 14:00:03 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by pwg.org (Postfix) with ESMTP id 665C6791D1 for ; Fri, 17 Aug 2012 13:59:51 -0400 (EDT) Received: by lbbgj3 with SMTP id gj3so2480236lbb.5 for ; Fri, 17 Aug 2012 10:59:50 -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:cc:content-type; bh=1ffC9FIrfvEjit/ofmU5qqbqBQlXqQIUJ7YXehJrnwA=; b=G4h/aM1aRwlVVIM7yM0/25gtlKWfLsX7+0r2NMOP9BjlBQO3u1/v1kThXoo58JHIip Bk1qrFAxv8mIIYmy9IST9RNr1A4C37BozwU3Hc3PeN3KVbfFUN8LXDLynj8vOLzLUKKg YT/v1FLF0PS0wf/66Wd16/O7s1a0mF7rQorpe4vVn9iSyGj/iE/pmayLM2yIcY7zPEGS H+Bg3a+mkwSFXAkL8dG6hALIIlOCkgcsaIrkm/hWsPImu+NyjzGIod7c8vNE0nfnWFVY dk0XBJ5LUbSVPJ5CBTv4ouxpeZjBNHcfFA++q2QX8GYX8UJWHMo9yRiFw++JiWD4+6EL FQ3A== MIME-Version: 1.0 Received: by 10.152.46.49 with SMTP id s17mr5659052lam.17.1345226390274; Fri, 17 Aug 2012 10:59:50 -0700 (PDT) Received: by 10.112.128.233 with HTTP; Fri, 17 Aug 2012 10:59:50 -0700 (PDT) Date: Fri, 17 Aug 2012 13:59:50 -0400 Message-ID: From: Ira McDonald To: Michael Sweet , Ira McDonald X-pwg-MailScanner: Found to be clean, Found to be clean Cc: pwg-announce@pwg.org Subject: [Pwg-Announce] REMINDER - PWG Last Call of IPP Everywhere (ends 8/24/12) X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1961371976==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 2EE0F791D6.AC8EA X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============1961371976== Content-Type: multipart/alternative; boundary=bcaec55404242283e104c779ed36 --bcaec55404242283e104c779ed36 Content-Type: text/plain; charset=ISO-8859-1 Hi, Reminder to all to acknowledge their review of IPP Everywhere spec by next Friday (24 August 2012). All those in the room or on the phone at last week's IPP Everywhere review, please take a moment to send your acknowledgement. Cheers, - Ira (PWG Secretary) 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 Temporary Cabin *** 2012 only *** 906-494-2523 On Wed, Jul 25, 2012 at 2:53 PM, Michael Sweet wrote: > [THIS TIME WITH THE CORRECT URL...] > > All, > > [This PWG Last Call starts today Tuesday July 24, 2012 and ends Friday > August 24, 2012 at 10pm US PST.] > > This is the formal announcement of the PWG Last Call for the IPP > Everywhere specification, located at: > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20120724.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 voting members > must acknowledge a PWG Last Call (with or without comments), before any > document can progress to PWG Formal Vote. This PWG Last Call is NOT a > Formal Vote but it DOES require your review acknowledgment. > > > HOW TO RESPOND > > Send an email with *exactly* the following subject line format: > Subject: has reviewed the IPP Everywhere 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 > Everywhere 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 > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean. > > _______________________________________________ > pwg-announce mailing list > pwg-announce@pwg.org > https://www.pwg.org/mailman/listinfo/pwg-announce > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --bcaec55404242283e104c779ed36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Reminder to all to acknowledge their review of IPP Everywhere sp= ec
by next Friday (24 August 2012).

All those in the room or on t= he phone at last week's IPP Everywhere
review, please take a moment = to send your acknowledgement.

Cheers,
- Ira (PWG Secretary)

Ira McDonald (Mu= sician / Software Architect)
Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG I= PP 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
Temporary Cabin= *** 2012 only *** 906-494-2523
=



On Wed, Jul 25, 2012 at 2:53 PM, Michael= Sweet <msweet@apple.com> wrote:
<= div>[THIS TIME WITH THE CORRECT URL..= .]

= All,

[= This PWG Last Call starts today Tuesday July 24, 2012 and ends Friday Augus= t 24, 2012 at 10pm US PST.]

This is the formal announcement of th= e PWG Last Call for the IPP Everywhere specification, located at:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10= -20120724.pdf

A= ll required attributes and values defined in this document have been protot= yped by Apple and/or other vendors. The IPP WG has completed extensive revi= ew of the various revisions of this document and an IPP WG last call.

T= he PWG Process/3.0 requires that a quorum (30%) of PWG voting members must = acknowledge a PWG Last Call (with or without comments), before any document= can progress to PWG Formal Vote. =A0This PWG Last Call is NOT a Formal Vot= e but it 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 Everywhere specification and has [no] comments


WHERE TO SEND YOUR RESPONSE
Please send your response to *all* of the f= ollowing email addresses (replacing "dot" with '.' and &q= uot;at" with '@'):

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 Everywhere E= ditor)

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


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

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



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --bcaec55404242283e104c779ed36-- --===============1961371976== 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 --===============1961371976==-- From ipp-bounces@pwg.org Mon Aug 20 09:17:09 2012 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 36C1821F8540 for ; Mon, 20 Aug 2012 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww-kARDjOfEt for ; Mon, 20 Aug 2012 09:17:08 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB5821F84EC for ; Mon, 20 Aug 2012 09:17:07 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id B8D5E791CE; Mon, 20 Aug 2012 12:16:49 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-lpp01m010-f46.google.com (mail-lpp01m010-f46.google.com [209.85.215.46]) by pwg.org (Postfix) with ESMTP id BF0BF791AE for ; Mon, 20 Aug 2012 12:16:35 -0400 (EDT) Received: by lagy9 with SMTP id y9so3753737lag.5 for ; Mon, 20 Aug 2012 09:16:34 -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=kWv2gz0XOfG6phDEfSFooUFMEjYno1wTRccCfdZ+aH0=; b=kOyuqZhO6mJ25pkwV+wsDXxDexbuy4iHh9HU/3MHUfB31dWKc+hcz1rxbo+wxpuzoh sEJ4O3bPCM/PX6GKjvEh/GoDA+YCjqY5RYw3opRTVhiUQP4sTXGRlAJ3KkZMEzJ3PM8a MPMgU4c+TrGZBJHRVRL9XM9o+cj83Ua+Btl10pfb0YdOhrWWWFwVZqSyiJD1wcfZ7C2K E3Iy9EVmzkHjA+a5dtRPHPS+JUfhEt4OlieotiOXShMWMwCZEG0XdKp0zOR5ectGgklj IEkEc/VcvK4bReL2F0vpw5J6g+N8eZ7r7f3EEPg6BzEAFJuHUHw4N2qcS9FjlcLLV9Fl 2sig== MIME-Version: 1.0 Received: by 10.152.131.9 with SMTP id oi9mr14344187lab.39.1345479394527; Mon, 20 Aug 2012 09:16:34 -0700 (PDT) Received: by 10.112.128.233 with HTTP; Mon, 20 Aug 2012 09:16:34 -0700 (PDT) Date: Mon, 20 Aug 2012 12:16:34 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Ira McDonald X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] IPP Agenda - 3-5pm EDT Monday 20 August 2012 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0954867524==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: B8D5E791CE.A97BD X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0954867524== Content-Type: multipart/alternative; boundary=f46d042c64775d0b5c04c7b4d52c --f46d042c64775d0b5c04c7b4d52c Content-Type: text/plain; charset=ISO-8859-1 Hi, Our next IPP WG call will be today! Monday 20 August 12-2pm US PDT / 3-5pm US EDT Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 (Primary) Call-in toll number (US/Canada): 1-408-856-9570 (Backup) Attendee Access Code: *******# Attendee ID Code: # (empty) If you need the Attendee Access code, please email me a request. ------------------------------------------------------ Meeting information ------------------------------------------------------- Topic: IPP/Cloud Imaging WG Telecon 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: *** Main Objective - Plans for IPP Multifunction *** (1) PWG IP Policy and Minute Taker - Mike? (2) Approve IPP minutes from August F2F - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20120807.pdf (3) Status of PWG Last Call on IPP Everywhere - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20120724.pdf - ends 24 August 2012 (4) Discussion of priorities for IPP Multifunction specs - IPP System Control Service - IPP Resource Service (e.g., for firmware and fonts) - IPP Shared Infrastructure Extensions (for Cloud) - others (5) Next steps - IPP WG teleconference on Monday 10 September (skip Monday 3 September - US Labor Day holiday) 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 Temporary Cabin *** 2012 only *** 906-494-2523 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --f46d042c64775d0b5c04c7b4d52c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Our next IPP WG call will be today!

Monday 20 August 12-2= pm US PDT / 3-5pm US EDT

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

If you need the A= ttendee Access code, please email me a request.
----------= --------------------------------------------
Meeting information
----------------------------------------------------= ---
Topic: IPP/Cloud Imaging WG Telecon
Date: Every Monday, from Mond= ay, July 9, 2012 to no end date
Time: 12:00 pm, Pacific Daylight Time (S= an Francisco)
Meeting Number: 624 587 312
Meeting Password: pwg123
----------------= ---------------------------------------
To start or join the online meet= ing
-------------------------------------------------------
Go to https://appleinc.webex.com/appleinc/j.php?ED=3D2049954= 27&UID=3D504472682&PW=3D
NNzM5MmRlMzBl&RT=3DMiM0
--------------------------------------------= -----------

Agenda:

*** Main Objective - Plans for IPP Multif= unction ***

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

(2)= Approve IPP minutes from August F2F
- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20120807.pd= f

(3) Status of PWG Last Call on IPP Everywhere
- ftp://ftp.pwg.or= g/pub/pwg/ipp/wd/wd-ippeve10-20120724.pdf
- ends 24 August 2012

(4) Discussion of priorities for IPP Multifunc= tion specs
- IPP System Control Service
- IPP Resource Service (e.g.,= for firmware and fonts)
- IPP Shared Infrastructure Extensions (for Clo= ud)
- others

(5) Next steps
- IPP WG teleconference on Monday 10 Sept= ember
=A0 (skip Monday 3 September - US Labor Day holiday)

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://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
Temporary Cabin *** 2012 only *** 906-494-2523


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --f46d042c64775d0b5c04c7b4d52c-- --===============0954867524== 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 --===============0954867524==-- From ipp-bounces@pwg.org Mon Aug 20 11:01:06 2012 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 7443B21F8674 for ; Mon, 20 Aug 2012 11:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGNT2FwxK19w for ; Mon, 20 Aug 2012 11:01:04 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 986CC21F8602 for ; Mon, 20 Aug 2012 11:01:04 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 065DD791E3; Mon, 20 Aug 2012 14:00:45 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by pwg.org (Postfix) with ESMTP id 7483E791A7 for ; Mon, 20 Aug 2012 14:00:31 -0400 (EDT) Received: from mail200-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 18:00:30 +0000 Received: from mail200-ch1 (localhost [127.0.0.1]) by mail200-ch1-R.bigfish.com (Postfix) with ESMTP id 7A1233202CE for ; Mon, 20 Aug 2012 18:00:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VS2(zzc85fh14ffIzz1202hz31iz8275bh8275dhz2fh2a8h683h839hd24hf0ah107ah9a9j) Received-SPF: pass (mail200-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=justhu@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail200-ch1 (localhost.localdomain [127.0.0.1]) by mail200-ch1 (MessageSwitch) id 1345485628102420_8808; Mon, 20 Aug 2012 18:00:28 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail200-ch1.bigfish.com (Postfix) with ESMTP id 0AF26A004F for ; Mon, 20 Aug 2012 18:00:28 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 18:00:27 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 20 Aug 2012 18:00:21 +0000 Received: from mail187-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 18:00:06 +0000 Received: from mail187-ch1 (localhost [127.0.0.1]) by mail187-ch1-R.bigfish.com (Postfix) with ESMTP id BC9D03C0213 for ; Mon, 20 Aug 2012 18:00:06 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:FOP;SFS:;DIR:OUT; Received: from mail187-ch1 (localhost.localdomain [127.0.0.1]) by mail187-ch1 (MessageSwitch) id 1345485604396569_29855; Mon, 20 Aug 2012 18:00:04 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail187-ch1.bigfish.com (Postfix) with ESMTP id 5CAABE012F; Mon, 20 Aug 2012 18:00:04 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 18:00:03 +0000 Received: from CH1PR03MB598.namprd03.prod.outlook.com (10.255.156.163) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.190.9; Mon, 20 Aug 2012 18:00:03 +0000 Received: from CH1PR03MB598.namprd03.prod.outlook.com (10.255.156.163) by CH1PR03MB598.namprd03.prod.outlook.com (10.255.156.163) with Microsoft SMTP Server (TLS) id 15.0.485.6; Mon, 20 Aug 2012 18:00:02 +0000 Received: from CH1PR03MB598.namprd03.prod.outlook.com ([169.254.10.240]) by CH1PR03MB598.namprd03.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0485.006; Mon, 20 Aug 2012 18:00:02 +0000 From: Justin Hutchings To: "'ipp@pwg.org'" , "Ira McDonald (blueroofmusic@gmail.com)" , "ptykodi@tykodi.com" , "Michael Sweet (msweet@apple.com)" Thread-Topic: Microsoft has reviewed the IPP Everywhere specification and has comments Thread-Index: Ac1+/PovbBoN9lY0QXudeWEeMo9RLw== Date: Mon, 20 Aug 2012 18:00:01 +0000 Message-ID: <0b084c5b02fe4c95b6aa941b4752380c@CH1PR03MB598.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.156.150] MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PR03MB598.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TYKODI.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%APPLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%PWG.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Microsoft has reviewed the IPP Everywhere specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0243585107==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 065DD791E3.AA0A1 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0243585107== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_0b084c5b02fe4c95b6aa941b4752380cCH1PR03MB598namprd03pro_" --_000_0b084c5b02fe4c95b6aa941b4752380cCH1PR03MB598namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please see comments below. Thanks Justin [BONJOUR] does not exist in either the normative or informative references.= Is this intentional? We need to reference it properly or remove it entirel= y. Line 290: We should reference the underlying standards for OPC and XML in t= he references. Line 304: Are we being overly descriptive about what a printer is consideri= ng it is already defined as being either a logical or physical device? Line 353: I think we need to tighten this up. If we're talking about proxim= ity, then that indicates that a proximity based technology is used to facil= itate the discovery directly. If we're merely coloring the results of a dir= ectory service, cloud service or discovery protocol based discovery, then w= e should say so. Line 380: The parenthetical is unnecessary. Line 415: Based on discussion at the last face to face, I think we need to = be more plain that in this scenario, the accounting program paginates the c= ontent appropriately for the check media. Line 444: We shouldn't use a company name to indicate a generic concept. Ca= n we remove "follow me" and describe the concept more functionally? In the = IPP Everywhere context, are we considering "late binding" part of this scen= ario (like Cloud does)? Eg, I print to a service, and then go to one of sev= eral printers where I authenticate and the job is printed only after I've r= eleased it at a particular printer. Line 583: CUPS and CUPSIPP are not referenced properly as normative or info= rmative references. Line 613: Is it acceptable to specify new versions of TLS as they come alon= g, even if IPP Everywhere isn't advanced? What restrictions do we want to i= mpose here. Line 628: Do we have requirements (that the IPPtool validates) which blocks= use of any GUID value appearing in this spec? Line 994: We should make it clear that truncation should happen only after = a key/value pair has been completed. In other words, don't leave malformed = values, or keys without values. Line 1127: Clients should not be made to support DNS/SD. They may support a= ny discovery protocol described, and clients are generally not purchased ba= sed on what protocols they support. Devices, on the other hand, are. We sho= uld let the market drive this area. Line 1134: Clients should not be made to support any particular document fo= rmats. If they do not support a format that the printer supports, then they= can always opt-out of using IPP Everywhere and use Port 9100 or something = else. We should let the market drive this area. Justin Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printi= ng and Imaging --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_0b084c5b02fe4c95b6aa941b4752380cCH1PR03MB598namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Please see comments below.

 

Thanks

Justin

 

[BONJOUR] does not exist in either the normative or = informative references. Is this intentional? We need to reference it proper= ly or remove it entirely.

Line 290: We should reference the underlying standar= ds for OPC and XML in the references.

Line 304: Are we being overly descriptive about what= a printer is considering it is already defined as being either a logical o= r physical device?

Line 353: I think we need to tighten this up. If we&= #8217;re talking about proximity, then that indicates that a proximity base= d technology is used to facilitate the discovery directly. If we’re m= erely coloring the results of a directory service, cloud service or discovery protocol based discovery, then we should say so= .

Line 380: The parenthetical is unnecessary.

Line 415: Based on discussion at the last face to fa= ce, I think we need to be more plain that in this scenario, the accounting = program paginates the content appropriately for the check media.

Line 444: We shouldn’t use a company name to i= ndicate a generic concept. Can we remove “follow me” and descri= be the concept more functionally? In the IPP Everywhere context, are we con= sidering “late binding” part of this scenario (like Cloud does)? Eg, I print to a service, and then go to one of several print= ers where I authenticate and the job is printed only after I’ve relea= sed it at a particular printer.

Line 583: CUPS and CUPSIPP are not referenced proper= ly as normative or informative references.

Line 613: Is it acceptable to specify new versions o= f TLS as they come along, even if IPP Everywhere isn’t advanced? What= restrictions do we want to impose here.

Line 628: Do we have requirements (that the IPPtool = validates) which blocks use of any GUID value appearing in this spec?

Line 994: We should make it clear that truncation sh= ould happen only after a key/value pair has been completed. In other words,= don’t leave malformed values, or keys without values.

Line 1127: Clients should not be made to support DNS= /SD. They may support any discovery protocol described, and clients are gen= erally not purchased based on what protocols they support. Devices, on the = other hand, are. We should let the market drive this area.

Line 1134: Clients should not be made to support any= particular document formats. If they do not support a format that the prin= ter supports, then they can always opt-out of using IPP Everywhere and use = Port 9100 or something else. We should let the market drive this area.

 

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

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_0b084c5b02fe4c95b6aa941b4752380cCH1PR03MB598namprd03pro_-- --===============0243585107== 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 --===============0243585107==-- From ipp-bounces@pwg.org Mon Aug 20 11:35:48 2012 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 C1B8221F86A1 for ; Mon, 20 Aug 2012 11:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMzkObftAscO for ; Mon, 20 Aug 2012 11:35:48 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id F1AA321F854B for ; Mon, 20 Aug 2012 11:35:47 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id E6435791EC; Mon, 20 Aug 2012 14:35:26 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by pwg.org (Postfix) with ESMTP id 5645A791E8 for ; Mon, 20 Aug 2012 14:35:10 -0400 (EDT) Received: from mail-lb0-f172.google.com ([209.85.217.172]) (using TLSv1) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKUDKDXUDcQiOdbdS3xgnOOhi1jGRRhtHa@postini.com; Mon, 20 Aug 2012 11:35:10 PDT Received: by lbbgg6 with SMTP id gg6so3662383lbb.31 for ; Mon, 20 Aug 2012 11:35:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:x-mailer:thread-index:date:message-id:subject:to :content-type:x-gm-message-state; bh=2z/Km3LhHYBkJkewFm5UMoPFobHePLtKlZbhWNd5oDc=; b=WHXy0/c2jZFnXBXo0O2EGAZuLpbBXZYS1h4zqoo5m3yjSrOyIIKgKBkm2riKJa/btR /oEKL7LWa2hwaX0DIju1cPyOWK2jtVHSpt9ta5Bm2MrtQbEWbHdlFnu47JX9+I/YdZHP 6zhFIUZic0juXSuHR5OTZQUAJq6Y7yie39xK80KdirMBpzk9oC36jlqSgtTa5CR8QXWp YYEUfvz5s4KfNgOHeocaND67Dp06cKU90GPAvs3j8IVcyT+vNEugb33Sm/dtBDx+JaBW 8gN6HL0oh628dQdtHcmpriw0uXplZQdvx9NX1BFvOCi6LYf4BEopLfx+DPDeSked2HPs XS6g== Received: by 10.112.23.200 with SMTP id o8mr6718284lbf.9.1345487707895; Mon, 20 Aug 2012 11:35:07 -0700 (PDT) From: Jerry Thrasher MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1/AN9gx7m5osSwSTaGJBJCxRO/bQ== Date: Mon, 20 Aug 2012 14:35:05 -0400 Message-ID: To: ipp@pwg.org, Ira McDonald , ptykodi@tykodi.com, msweet@apple.com X-Gm-Message-State: ALoCoQmXN2KjSKXntoSR+6s30SlQ81bB50WLBNtfQ6ZEg4Ql1HtXU4wimiTaDmqPQX8bmqoTxDtt X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Lexmark has reviewed the IPP Everywhere specification and has the following additional comments. X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0261619949==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: E6435791EC.AA022 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0261619949== Content-Type: multipart/related; boundary=485b390f7bfee0f93004c7b6c421 --485b390f7bfee0f93004c7b6c421 Content-Type: multipart/alternative; boundary=485b390f7bfee0f92b04c7b6c420 --485b390f7bfee0f92b04c7b6c420 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Line 316, 316: need to add the comma after the =93e.g.=94 (inconsistent wi= th uses in other places in document) Line 480: We never define the proper term Visible Printer yet we define Visible Device. Need to make consistent. Line 252: A User is not restricted to using a Device (User also access Client) Need a better defn. Line 253,254: Should merge the definition of Visible Device and the concept of Visibility into one definition for Visible Device (or Visible Printer) Line 990: I don=92t believe that MANU is a valid abbreviation for Manufacturer from the IEEE 1284 specification, it=92s only MFG. [image: Description: lexmark_logo] *Jerry Thrasher* Senior Engineer, WW Corporate Standards Lexmark International Inc. 501C14/035-3, 740 New Circle Rd, Lexington Ky 40550 Office: +1 859 825 4056 Fax: +1 859 232 7628 thrasher(at)lexmark(dot)com --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --485b390f7bfee0f92b04c7b6c420 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Line 316, 316: =A0need to add= the comma after the =93e.g.=94 (inconsistent with uses in other places in = document)

Line 480: We never define the proper term Visible Pr= inter yet we define Visible Device.=A0 Need to make consistent.

Line 252: A User is not restricted to using a Device (User a= lso access Client)=A0 Need a better defn.

Line 253,254: Should merge the definition of Visible= Device and the concept of Visibility into one definition for Visible Devic= e

(or Visible Printer)

= Line 990: I don=92t believe that MANU is a valid abbreviation for Manufactu= rer from the IEEE 1284 specification, it=92s only MFG.

=A0

3D"Description:

=A0

Jerry Thrasher

Senior Engineer, WW Corporate Standards<= br>Lexmark International Inc.
501C14/035-3, 740 New Circle Rd, Lexington= Ky 40550
Office: +1 859 825 4056=A0=A0=A0=A0 Fax: +1 859 232 7628
thrasher(at)lex= mark(dot)com


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --485b390f7bfee0f92b04c7b6c420-- --485b390f7bfee0f93004c7b6c421 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ebcb0581f6974ac3_0.1 R0lGODlhqgAsANUmAO47M1pXWPHx8TEtLnZzdExJSuPj4z87PNbV1ayrq7q5 uYSBgmhlZp6dnZiWl/BUTf7z8l5bW/m1sv3m5fSFgPJsZvvOzO9HQPadmfrC v8TDxGxqara0taelpvza2fDw8PippXt5efWRjcjHx5GPjyMfIP///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACYALAAAAACqACwAAAb/ wJFwSBwJTMikcslsOp/QqHRKrVqvy5J2yy2NsOCweEwuRwWLrpZwNLvf8Li5 0D3I7/i8PknqLvaAgYJXfVwkg4hhBgqJYoVbh08GJEWVliMIBpdDBkgCm5ud T5+XbU8Edk8IoEOmSwkksbKzX56XDUqPWpFOI2q/vwG6v5G+wMcEUA3HtU4G Ws1MAcddAwSMStPHvMa/uV28TgJ0XcKzCwdcASYCBL+iSgYDWwQISCPzaq5L 6WpsUe5KMICigJwhEqjq2EuCT00BeOxGJFAXzcSwcM7UYESyTMs6JNq4VDSh QMuAih3BOUHwa4AUAflKQGTSbYsSBTG1YEMyscs+/yQBS2y0qFKKwV1Oen40 Ia+OKwT5EtD8lYpJUHVSdP15UlPLkpJcBph6htXqFqlNLk4JidRJmqUmUkJK IqDf1iXGcpbYSTcfW7hNYIb9yVANk35bcCUpZ7bEgIVpi0ZhK3TUAMCUSyzU VqDXGsavtBzQBZiJADVom3QtwYQBaCSvgZqEHNnQWsm2kiy4i6Qpl85pHBM2 YQxhl5nkGpCWcrVE1aldmAyDGztgAdq150qhjDFNFLlaXGvBrqR4V94stQhY HoUsF77lDS8Rv4U3aAHiCwz/Zns7bsH+/aKYZ5Ud5VISAQ3EXhT0eUQgF0sI xgVEjI2jhX5TqBWgdkyRI/+Fb1wkA0VxJvR0VhL5MLLgiGrMdI98CHaRGmzq WKgTFRpOVg4JCxyVoRoDEniIhBfyJBoSKy4BQTZdiIgXjAY0OAB8JnRRgIHk ZdeWjtR4NcVRjrkYX2UmBLeFPdpEkmQSEzxwUzU/rcZAAAYNwEAChNWhxgH7 8YHbE5QxgFBOOKpR2piRuLeGe6KsiQQFAEigBGJaBPliF+Bp9kQ5Jm7RWRQ5 QsFdEilNAZWAXG1JWYJ+bnHoBAAA4GYSnToHHYQNloBhE4yZSQ+ofzoxKq1e QlGXSdVkSdyWYKmxk6MYxApABkroBd9q7OjFmxKgZTZUqxwykcBWwyYxjRTi DWD/AKW6Cjnpnvw5qOQF0lYQr7yFRUeSs7yWZSMXMy4R6hIFDGRCuRyxBkUh jy0brMPhZBrOmtFKC4AFfXVBG7ZI5CoWE6+dqrETAxcWCcKmHXDgpSWk1pym T5LpSYv3AgYBvRbbG2OIY0LoiV6lxdbsFg1L9/CxtaC8hDsGM5UPb0ReuA+J SlzVNJJlJSGBxdJOkISi6uXrMxJDV5pF1glb+VPJNoqitCfiDUjO1WSrsS3V SaR3Y81LPMB1rBRULRnHSXgMmd5FLu1Qa3+OgFgS7G60Xky1BPSxNGpE0xHd JpCzchJHPbf137F6zfKRp4ed8W/E+hQhmCU4WaKhCghB/8JRH2VKwBA8ws7O I7K/WU0tx44XWgnb1iqz36QDEPjMTR7x8j9JlB27AMWHuA/YaxwBe5cLiNyl ocofABc6x5gPb7Uy5c3uFgcgkEHzsV4AQQLfO/b+ibqNLyMSCMjMb2ZBwALK YgSTMKACaTECBSoBFgtc4FeClEAFGkAE9IuVBBoYwQVGYz0dJGAtKijBRpgw ChbIIACWdMIWunAMFaDf815IwxpOIYXNM50Nd8jDvpFuhjR0wBYcEIESfIAD JXBAD104Oq55oIcKi0AENEBEJS6xhcyr1xKj6AAHbKCLV2whCLiGMSgiYYob +KIVw9iIm2lxi2fUQAg6AEY2miGwYtOyox5pCIFYzWqPgDwhpCQVyEImok2G TCQiWGjIIAAAOw== --485b390f7bfee0f93004c7b6c421-- --===============0261619949== 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 --===============0261619949==-- From ipp-bounces@pwg.org Mon Aug 20 18:22:30 2012 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 4A4AB21F855F for ; Mon, 20 Aug 2012 18:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjAhS1ZzQBP3 for ; Mon, 20 Aug 2012 18:22:29 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8C14F21F8517 for ; Mon, 20 Aug 2012 18:22:29 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 091C1791F7; Mon, 20 Aug 2012 21:22:15 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id B9CA7791F6 for ; Mon, 20 Aug 2012 21:22:01 -0400 (EDT) MIME-version: 1.0 Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M9200JIIYS73XZ1@mail-out.apple.com> for ipp@pwg.org; Mon, 20 Aug 2012 18:21:56 -0700 (PDT) X-AuditID: 1180711d-b7f896d000004730-55-5032e2afb694 Received: from [17.151.80.167] (Unknown_Domain [17.151.80.167]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id BD.3E.18224.2B2E2305; Mon, 20 Aug 2012 18:21:56 -0700 (PDT) From: Michael Sweet Date: Mon, 20 Aug 2012 21:22:04 -0400 To: "ipp@pwg.org" Message-id: X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUiOD1gue6WR0YBBhP6jSyO7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlXHt5FGmgq+iFbfPt7A1MF4S7mLk5JAQMJE4 cv8QC4QtJnHh3nq2LkYuDiGBqUwSrfsuMIIk2ATUJH5P6mMFsZkFEiSun/3H1MXIwcEioCox pz0YJCwsoCvx8glEuYiAvMTatqlMIDavgI3EpkOvWSBsPYnZ7XOgdslKfD98nm0CI/csJFNn ISmDiMtLbH87h3kW0DZmAR2JyQsZIcLaEssWvmaGsT+eP8K0gJFtFaNgUWpOYqWhsV5iQUFO ql5yfu4mRlBgNRTK7mDc/5P/EKMAB6MSD++DXqMAIdbEsuLK3EOMEhzMSiK8gsVAId6UxMqq 1KL8+KLSnNTiQ4zSHCxK4ryTyoBSAumJJanZqakFqUUwWSYOTqkGxg6hmYLWN5Junt5yxrA2 drEQw4OS1nl6ijE+LoGrGI+1ms3b8HBuPGduV+A9/rKzq74H1BVtfOMrfLp0SviNWWK6BzZ9 mM6fVxl9XiHm+6GTqtKbYv4UtOnOWLpzkXR04PdV3eFn1pssKZv27sRr+V+MjyQMMqUPrNay Uyybwmy6d1/EpIoHj5RYijMSDbWYi4oTAUgsy+EoAgAA X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Minutes from today's conference call X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0692090004==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 091C1791F7.A80BB X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0692090004== Content-type: multipart/alternative; boundary="Boundary_(ID_b8cNeAHex0CfTBFqdjwgOw)" --Boundary_(ID_b8cNeAHex0CfTBFqdjwgOw) 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-20120820.pdf Our next conference call is September 10, 2012. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_b8cNeAHex0CfTBFqdjwgOw) 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:
=

Our next conference call is Septe= mber 10, 2012.

_________________________________________________= ________
Michael Sweet, Senior Printing System Engineer, PWG Chair<= /div>


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_b8cNeAHex0CfTBFqdjwgOw)-- --===============0692090004== 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 --===============0692090004==-- From ipp-bounces@pwg.org Mon Aug 20 18:42:22 2012 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 CC6C821F8597 for ; Mon, 20 Aug 2012 18:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tjsn3hml5KR for ; Mon, 20 Aug 2012 18:42:20 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC221F8596 for ; Mon, 20 Aug 2012 18:42:20 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 15727791F0; Mon, 20 Aug 2012 21:42:03 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 660DE791EF for ; Mon, 20 Aug 2012 21:41:52 -0400 (EDT) MIME-version: 1.0 Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M92007YVZMVUBO0@mail-out.apple.com> for ipp@pwg.org; Mon, 20 Aug 2012 18:41:51 -0700 (PDT) X-AuditID: 11807130-b7fb86d000004da6-e0-5032e75d55d6 Received: from [17.151.80.167] (Unknown_Domain [17.151.80.167]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 16.DF.19878.E57E2305; Mon, 20 Aug 2012 18:41:51 -0700 (PDT) From: Michael Sweet Date: Mon, 20 Aug 2012 21:42:02 -0400 To: "ipp@pwg.org" Message-id: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUiOD1guW78c6MAgyuT5S2O7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlXG/+wxTwU6Zimnr9jA1MB6Q6GLk5JAQMJF4 vnsBM4QtJnHh3nq2LkYuDiGBqUwSzT8ugCXYBNQkfk/qYwWxmQUSJKbeXMMCYrMIqEp8uNAP ZgsLGEkcOnoQzBYRkJdY2zaVCcTmFbCR2LKqgxnC1pOY3T6HBWKZrMT3w+fZJjByz0IydhaS Moi4tsSyha+ZZzFyANk6EpMXMqIKQ9gfzx9hWsDItopRsCg1J7HS0FAvsaAgJ1UvOT93EyMo tBoKDXYwrv3Jf4hRgINRiYf3xRSjACHWxLLiytxDjBIczEoivILFQCHelMTKqtSi/Pii0pzU 4kOM0hwsSuK8k8qAUgLpiSWp2ampBalFMFkmDk6pBka9ltm3Qr6vL0y89KpXIHxdUfBzng9O aw10Pk35x8cw75pMlk5LA1Pu03yX/A9xgT/DIr/HSTR1JgV7vFwi+MdzvqjatGaZE6pXz6z4 f8Hs1OGsHSuarXSfxjS5Sgqlx/5fwtQdfOJ9qZKicGzhm89c3xZO8dyislvAOjE16MT7v9IP f5ckTlNiKc5INNRiLipOBABJQoPDKQIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] IPP Everywhere and "The Great Compromise" X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0836172557==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 15727791F0.A856F X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0836172557== Content-type: multipart/alternative; boundary="Boundary_(ID_jDzbDQ0trMxvGf04Lnx98w)" --Boundary_(ID_jDzbDQ0trMxvGf04Lnx98w) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, We discussed the PWG Last Call comments received thus far at today's IPP WG conference call. Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats. After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols) 2. Document Formats: a. Printers MUST support both JPEG and PWG Raster (no change) b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both) Please comment on the proposed changes. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_jDzbDQ0trMxvGf04Lnx98w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable All,

W= e discussed the PWG Last Call comments received thus far at today's IPP WG = conference call.  Two of the comments concerned the client requirement= s to support DNS-SD for discovery and both PWG Raster and JPEG for document= formats.  After over an hour of spirited debate, the following "great= compromise" was proposed to resolve the last call comments:

=
1. Discovery:

   a. Printers = MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)
&nb= sp;  b. Clients MUST support at least one of DNS-SD and WS-Discovery (= Clients can choose amongst the two required protocols)

=
2. Document Formats:

   a. Printers= MUST support both JPEG and PWG Raster (no change)
   b= . Clients MUST support at least one of JPEG and PWG Raster (relaxes conform= ance - previously a Client had to support both)

Pl= ease comment on the proposed changes.

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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_jDzbDQ0trMxvGf04Lnx98w)-- --===============0836172557== 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 --===============0836172557==-- From ipp-bounces@pwg.org Mon Aug 20 21:22:08 2012 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 B0A7A11E80E3 for ; Mon, 20 Aug 2012 21:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgFGpis2-Us7 for ; Mon, 20 Aug 2012 21:22:07 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9011E80D5 for ; Mon, 20 Aug 2012 21:22:07 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 480C179201; Tue, 21 Aug 2012 00:21:51 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by pwg.org (Postfix) with ESMTP id CD856791FE for ; Tue, 21 Aug 2012 00:21:27 -0400 (EDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta15.westchester.pa.mail.comcast.net with comcast id pGLb1j0051ei1Bg5FGMjNb; Tue, 21 Aug 2012 04:21:43 +0000 Received: from WagnerVistaPC ([98.216.178.129]) by omta24.westchester.pa.mail.comcast.net with comcast id pGGV1j00o2ntzM63kGGZ1W; Tue, 21 Aug 2012 04:16:33 +0000 From: "William A Wagner" To: References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> In-Reply-To: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> Subject: RE: [IPP] IPP Everywhere and "The Great Compromise" Date: Tue, 21 Aug 2012 00:16:22 -0400 Message-ID: <000001cd7f53$b8e80940$2ab81bc0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1/PuknSviT59rnS3Oxm8w7SSnMmwAFGFtQ Content-Language: en-us X-pwg-MailScanner: Found to be clean, Found to be clean X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1762849036==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 480C179201.A97DB X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============1762849036== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CD7F32.31D66940" Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CD7F32.31D66940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think this is a practical and reasonable compromise. From at least my perspective, this does not put an unreasonable additional burden on printers while making potentially easier for clients to achieve and claim compliance. Bill Wagner From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet Sent: Monday, August 20, 2012 9:42 PM To: ipp@pwg.org Subject: [IPP] IPP Everywhere and "The Great Compromise" All, We discussed the PWG Last Call comments received thus far at today's IPP WG conference call. Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats. After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols) 2. Document Formats: a. Printers MUST support both JPEG and PWG Raster (no change) b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both) Please comment on the proposed changes. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_0001_01CD7F32.31D66940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think t= his is a practical and reasonable compromise. From at least my perspective,= this does not put an unreasonable additional burden on printers while = ; making potentially easier for clients to achieve and claim compliance.

Bill Wagner

 

=

From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] <= b>On Behalf Of Michael Sweet
Sent: Monday, August 20, 2012 9:= 42 PM
To: ipp@pwg.org
Subject: [IPP] IPP Everywhere and= "The Great Compromise"

 

All,

<= div>

 

We discussed the PWG Last Call comments received thus far at today's IPP= WG conference call.  Two of the comments concerned the client require= ments to support DNS-SD for discovery and both PWG Raster and JPEG for docu= ment formats.  After over an hour of spirited debate, the following &q= uot;great compromise" was proposed to resolve the last call comments:<= o:p>

 

1. Discovery:

 

   = a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)

   b. Clients MUST s= upport at least one of DNS-SD and WS-Discovery (Clients can choose amongst = the two required protocols)

<= o:p> 

2. Document Formats:

 

   a. Printers MUST support both JPEG and P= WG Raster (no change)

  =  b. Clients MUST support at least one of JPEG and PWG Raster (relaxes = conformance - previously a Client had to support both)

=

 

Please comment on the proposed changes.

 

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

 


--
This message has been scanned for viruses and
danger= ous content by MailScanner<= /a>, and is
believed to be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_0001_01CD7F32.31D66940-- --===============1762849036== 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 --===============1762849036==-- From ipp-bounces@pwg.org Mon Aug 20 21:40:01 2012 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 CADCB11E80D1 for ; Mon, 20 Aug 2012 21:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvD+lN5xkxQg for ; Mon, 20 Aug 2012 21:40:00 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id DC3EE21F852D for ; Mon, 20 Aug 2012 21:39:59 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 4E14D791FF; Tue, 21 Aug 2012 00:39:33 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by pwg.org (Postfix) with ESMTP id 56F69791FE for ; Tue, 21 Aug 2012 00:39:16 -0400 (EDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.14.4/8.14.4) with ESMTP id q7L4dBFb001274 for ; Tue, 21 Aug 2012 00:39:11 -0400 X-Authenticated-IP: 98.151.18.90 Received: from [98.151.18.90] ([98.151.18.90:62277] helo=[192.168.1.106]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 18/10-31423-FE013305; Tue, 21 Aug 2012 00:39:11 -0400 From: Randy Turner Mime-Version: 1.0 (Apple Message framework v1278) Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" Date: Mon, 20 Aug 2012 21:39:10 -0700 In-Reply-To: <000001cd7f53$b8e80940$2ab81bc0$@net> To: ipp@pwg.org References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> <000001cd7f53$b8e80940$2ab81bc0$@net> Message-Id: X-Mailer: Apple Mail (2.1278) X-pwg-MailScanner: Found to be clean, Found to be clean X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0132261279==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 4E14D791FF.AA225 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0132261279== Content-Type: multipart/alternative; boundary="Apple-Mail=_C8B9B628-7DC4-4D4D-8DBB-ECE8CC56CACE" --Apple-Mail=_C8B9B628-7DC4-4D4D-8DBB-ECE8CC56CACE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 i think I understand the compromise, although I would have worded 1b and 2= b a little different Clients MUST support either DNS-SD or WS-Discovery=85. It's just a different use of a contraction "=85one of DNS-SD AND WS-Discovery" seemed to use an AND contraction which= implied both - someone might inadvertently parse this in a way we didn't e= xpect=85.although I got the gist of the compromise. R. On Aug 20, 2012, at 9:16 PM, William A Wagner wrote: > I think this is a practical and reasonable compromise. From at least my p= erspective, this does not put an unreasonable additional burden on printers= while making potentially easier for clients to achieve and claim complian= ce. > Bill Wagner >=20=20 > From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Micha= el Sweet > Sent: Monday, August 20, 2012 9:42 PM > To: ipp@pwg.org > Subject: [IPP] IPP Everywhere and "The Great Compromise" >=20=20 > All, >=20=20 > We discussed the PWG Last Call comments received thus far at today's IPP = WG conference call. Two of the comments concerned the client requirements = to support DNS-SD for discovery and both PWG Raster and JPEG for document f= ormats. After over an hour of spirited debate, the following "great compro= mise" was proposed to resolve the last call comments: >=20=20 > 1. Discovery: >=20=20 > a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discove= ry) > b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clien= ts can choose amongst the two required protocols) >=20=20 > 2. Document Formats: >=20=20 > a. Printers MUST support both JPEG and PWG Raster (no change) > b. Clients MUST support at least one of JPEG and PWG Raster (relaxes c= onformance - previously a Client had to support both) >=20=20 > Please comment on the proposed changes. >=20=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20=20 >=20 > --=20 > This message has been scanned for viruses and=20 > dangerous content by MailScanner, and is=20 > believed to be clean. >=20 > --=20 > This message has been scanned for viruses and=20 > dangerous content by MailScanner, and is=20 > believed to be clean. _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Apple-Mail=_C8B9B628-7DC4-4D4D-8DBB-ECE8CC56CACE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

R.
=

On Aug 20, 2012, at 9:16 PM, William A Wagner wrote:
I think this is a = practical and reasonable compromise. From at least my perspective, this doe= s not put an unreasonable additional burden on printers while  making = potentially easier for clients to achieve and claim compliance.<= /span>
Bill Wagner
 
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org]<= span class=3D"Apple-converted-space"> On Behalf Of Michael Sweet
Sent:<= span class=3D"Apple-converted-space"> Monday, August 20, 2012 9= :42 PM
To: ipp@pwg.org
Subject: [IPP] IPP Everywhere and "The Great Compromise"
 
All,
<= o:p> 
We discussed the PWG Last Call comments r= eceived thus far at today's IPP WG conference call.  Two of the commen= ts concerned the client requirements to support DNS-SD for discovery and bo= th PWG Raster and JPEG for document formats.  After over an hour of sp= irited debate, the following "great compromise" was proposed to resolve the= last call comments:
 
1. Discovery:
 
<= /div>
   a. Printers MUST support both DNS-SD and WS-Discove= ry (adds WS-Discovery)
   b. Clients = MUST support at least one of DNS-SD and WS-Discovery (Clients can choose am= ongst the two required protocols)
 
2. Document Formats:
 
   a. Printers MUST support both J= PEG and PWG Raster (no change)
   b. = Clients MUST support at least one of JPEG and PWG Raster (relaxes conforman= ce - previously a Client had to support both)
<= o:p> 
Please comment on the proposed changes.
 
_________________________________________________________
Michael= Sweet, Senior Printing System Engineer, PWG Chair
 

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

-- 
This message has been scanned for viru= ses and 
dangerous con= tent by MailScanner, and is =
believed to be clean. = ;_______________________________________________
ipp mailing list=
ipp@pwg.org
https://www.pw= g.org/mailman/listinfo/ipp

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Apple-Mail=_C8B9B628-7DC4-4D4D-8DBB-ECE8CC56CACE-- --===============0132261279== 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 --===============0132261279==-- From ipp-bounces@pwg.org Mon Aug 20 21:56:32 2012 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 AF17821F8594 for ; Mon, 20 Aug 2012 21:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IntH2t2DpgNn for ; Mon, 20 Aug 2012 21:56:31 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id A46CD21F8468 for ; Mon, 20 Aug 2012 21:56:25 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 74B4D7920E; Tue, 21 Aug 2012 00:56:07 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by pwg.org (Postfix) with ESMTP id 7B26379210 for ; Tue, 21 Aug 2012 00:55:31 -0400 (EDT) Received: by obbuo13 with SMTP id uo13so12946423obb.5 for ; Mon, 20 Aug 2012 21:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jGWu49WnPlxsbegYQRlYgSuv0gtQH6+D2IDOsAlADkQ=; b=v/Lv94yKA1gB+Sh9YxcEQPJ3UYTjWK9L3TuMm2YWLup2zddp5F8OcpiFuTXsmFCnA0 GzisgmAYvpoOWME+MJymN/u3ij9X8LQnVnLq07TppIgGC5SkmgxZSmU0G7S+V9rlVPZ7 Z2gM4IaciSFnbZFpztCShYEiROMhnyFyCseL5lK2L/cfgrdcSQMi2VWVc79lCaaMBSUw xmv+MtT43d78QSNQJnajT5yrJKdjDJY8fJhk6jCxTgKoaK0PNQmtO5yCEmEleSgE6qmy rlJgqptihl81yp9VBt3iw6nU0bOs1OUpX1ZZvzeUocntwoT8mSVWe+TWNUE/0xc2EAf9 fq/w== MIME-Version: 1.0 Received: by 10.182.131.73 with SMTP id ok9mr12183478obb.19.1345524930922; Mon, 20 Aug 2012 21:55:30 -0700 (PDT) Received: by 10.60.130.202 with HTTP; Mon, 20 Aug 2012 21:55:30 -0700 (PDT) In-Reply-To: References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> <000001cd7f53$b8e80940$2ab81bc0$@net> Date: Mon, 20 Aug 2012 22:55:30 -0600 Message-ID: Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" From: Daniel Dressler To: Randy Turner X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2019571992==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 74B4D7920E.AAF7B X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============2019571992== Content-Type: multipart/alternative; boundary=e89a8f64790b8b494e04c7bf6f41 --e89a8f64790b8b494e04c7bf6f41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a random bystander I can confirm that "one of X and Y" sounds a bit odd. Although the context does make it clear. How about "Clients MUST support either DNS-SD or WS-Discovery or both" to eliminate any final confusion with English's exclusive or. While I'm being usless let me also suggest another wording "The intersection between the set of client's supported protocols and the set {DNS-SD, WS-Discovery} must not be the empty set." Daniel 2012/8/20 Randy Turner > > i think I understand the compromise, although I would have worded 1b and > 2b a little different > > Clients MUST support either DNS-SD or WS-Discovery=E2=80=A6. > > It's just a different use of a contraction > > "=E2=80=A6one of DNS-SD AND WS-Discovery" seemed to use an AND contracti= on which > implied both - someone might inadvertently parse this in a way we didn't > expect=E2=80=A6.although I got the gist of the compromise. > > R. > > On Aug 20, 2012, at 9:16 PM, William A Wagner wrote: > > I think this is a practical and reasonable compromise. From at least my > perspective, this does not put an unreasonable additional burden on > printers while making potentially easier for clients to achieve and claim > compliance.**** > Bill Wagner**** > ** ** > *From:* ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] *On Behalf Of *M= ichael > Sweet > *Sent:* Monday, August 20, 2012 9:42 PM > *To:* ipp@pwg.org > *Subject:* [IPP] IPP Everywhere and "The Great Compromise"**** > ** ** > All,**** > ** ** > We discussed the PWG Last Call comments received thus far at today's IPP > WG conference call. Two of the comments concerned the client requirements > to support DNS-SD for discovery and both PWG Raster and JPEG for document > formats. After over an hour of spirited debate, the following "great > compromise" was proposed to resolve the last call comments:**** > ** ** > 1. Discovery:**** > ** ** > a. Printers MUST support both DNS-SD and WS-Discovery (adds > WS-Discovery)**** > b. Clients MUST support at least one of DNS-SD and WS-Discovery > (Clients can choose amongst the two required protocols)**** > ** ** > 2. Document Formats:**** > ** ** > a. Printers MUST support both JPEG and PWG Raster (no change)**** > b. Clients MUST support at least one of JPEG and PWG Raster (relaxes > conformance - previously a Client had to support both)**** > ** ** > Please comment on the proposed changes.**** > ** ** > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair**** > ** ** > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean.**** > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean. _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean. > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --e89a8f64790b8b494e04c7bf6f41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a random bystander I can confirm that "one of X and Y" sounds = a bit odd. Although the context does make it clear.

How about "= Clients MUST support either DNS-SD or WS-Discovery or both" to elimina= te any final confusion with English's exclusive or.

While I'm being usless let me also suggest another wording "Th= e intersection between the set of client's supported protocols and the = set {DNS-SD, WS-Discovery} must not be the empty set."

Daniel

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

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



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --e89a8f64790b8b494e04c7bf6f41-- --===============2019571992== 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 --===============2019571992==-- From ipp-bounces@pwg.org Tue Aug 21 04:14:45 2012 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 9FD7C21F86C5 for ; Tue, 21 Aug 2012 04:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-dRXPkQVWJQ for ; Tue, 21 Aug 2012 04:14:39 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id B2F6721F8600 for ; Tue, 21 Aug 2012 04:14:38 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id DD24C79216; Tue, 21 Aug 2012 07:14:23 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 501AE79215 for ; Tue, 21 Aug 2012 07:14:09 -0400 (EDT) MIME-version: 1.0 Received: from relay17.apple.com ([17.128.113.18]) 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 <0M9300J7FQZB3XB7@mail-out.apple.com> for ipp@pwg.org; Tue, 21 Aug 2012 04:14:06 -0700 (PDT) X-AuditID: 11807112-b7f796d000000feb-82-50336d7e11d9 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id DB.39.04075.E7D63305; Tue, 21 Aug 2012 04:14:06 -0700 (PDT) Received: from [10.0.1.11] (unknown [173.243.42.2]) by jimbu.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M9300KKJR7G6E70@jimbu.apple.com> for ipp@pwg.org; Tue, 21 Aug 2012 04:14:06 -0700 (PDT) References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> <000001cd7f53$b8e80940$2ab81bc0$@net> In-reply-to: Message-id: <6F631752-E09D-41F9-9FDB-2D169DE84C39@apple.com> X-Mailer: iPad Mail (9B206) From: Michael Sweet Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" Date: Tue, 21 Aug 2012 07:14:07 -0400 To: Daniel Dressler X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiON1OVbcu1zjA4PFzEYtj+16yODB6zFs8 nSmAMYrLJiU1J7MstUjfLoErY/LqHewFG2or2l/XNTB+ze9i5OSQEDCR2HljOROELSZx4d56 ti5GLg4hgVYmifZjk5kgnElMEss2vmYGqRISeMYoMWFrKIjNKRAssfXpVkYQm1dAXOL10SlA NgcHs0C8xKE5mhBhG4nLDcvZQWxmAXmJzWveMkOUeEqcPuoMsVda4t2dE6wgNpuAmsTvSX1g tjBQ6/cLq8FaWQRUJV4vXgpmiwgYSMyf85R9AqPALCSLZyEsnoVkGYStLbFs4WsoW1Nif/dy FkxxDYnObxNZFzCyr2IULErNSaw0NNdLLCjISdVLzs/dxAgK6oZCoR2M93fpHWIU4GBU4uF9 0GsUIMSaWFZcmXuIUYKDWUmEd0uccYAQb0piZVVqUX58UWlOavEhRmkOFiVx3ullQNUC6Ykl qdmpqQWpRTBZJg5OqQZGq6u9Bx1T7KJ+Mfgn34qeHFexw3mP9VRt9vA3RUXz78pPWai3UvXQ +9pbzmsmmPKXP1q3/lYAx/dd2+rLEjnEpNcbOtzwsVnQ8Mx7k7LX/LnckSd+1T84cHP30V3x F7rWHFZ0NLkZO8ng1V3lgK51G6+Ext7mKHgqvecXr2qE9kXt1jjulX/fKLEUZyQaajEXFScC AIfgohNmAgAA X-pwg-MailScanner: Found to be clean, Found to be clean Cc: "ipp@pwg.org" X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892239004==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: DD24C79216.A984D X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0892239004== Content-type: multipart/alternative; boundary="Boundary_(ID_91Zyvf21dx+H3Mh9gq+T/Q)" --Boundary_(ID_91Zyvf21dx+H3Mh9gq+T/Q) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Randy and Daniel, I agree my wording for the client requirements still needs some polish - to= ss it up to writing it up late at night... How about: Clients MUST support DNS-SD and/or WS-Discovery. (the math geek in me likes the intersection version below... :) Sent from my iPad On 2012-08-21, at 12:55 AM, Daniel Dressler wr= ote: > As a random bystander I can confirm that "one of X and Y" sounds a bit od= d. Although the context does make it clear. >=20 > How about "Clients MUST support either DNS-SD or WS-Discovery or both" to= eliminate any final confusion with English's exclusive or. >=20 > While I'm being usless let me also suggest another wording "The intersect= ion between the set of client's supported protocols and the set {DNS-SD, WS= -Discovery} must not be the empty set." >=20 > Daniel >=20 > 2012/8/20 Randy Turner >=20 > i think I understand the compromise, although I would have worded 1b and= 2b a little different >=20 > Clients MUST support either DNS-SD or WS-Discovery=E2=80=A6. >=20 > It's just a different use of a contraction >=20 > "=E2=80=A6one of DNS-SD AND WS-Discovery" seemed to use an AND contracti= on which implied both - someone might inadvertently parse this in a way we = didn't expect=E2=80=A6.although I got the gist of the compromise. >=20 > R. >=20 > On Aug 20, 2012, at 9:16 PM, William A Wagner wrote: >=20 >> I think this is a practical and reasonable compromise. From at least my = perspective, this does not put an unreasonable additional burden on printer= s while making potentially easier for clients to achieve and claim complia= nce. >> Bill Wagner >>=20=20 >> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Mich= ael Sweet >> Sent: Monday, August 20, 2012 9:42 PM >> To: ipp@pwg.org >> Subject: [IPP] IPP Everywhere and "The Great Compromise" >>=20=20 >> All, >>=20=20 >> We discussed the PWG Last Call comments received thus far at today's IPP= WG conference call. Two of the comments concerned the client requirements= to support DNS-SD for discovery and both PWG Raster and JPEG for document = formats. After over an hour of spirited debate, the following "great compr= omise" was proposed to resolve the last call comments: >>=20=20 >> 1. Discovery: >>=20=20 >> a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discov= ery) >> b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clie= nts can choose amongst the two required protocols) >>=20=20 >> 2. Document Formats: >>=20=20 >> a. Printers MUST support both JPEG and PWG Raster (no change) >> b. Clients MUST support at least one of JPEG and PWG Raster (relaxes = conformance - previously a Client had to support both) >>=20=20 >> Please comment on the proposed changes. >>=20=20 >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >>=20=20 >>=20 >> --=20 >> This message has been scanned for viruses and=20 >> dangerous content by MailScanner, and is=20 >> believed to be clean. >>=20 >> --=20 >> This message has been scanned for viruses and=20 >> dangerous content by MailScanner, and is=20 >> believed to be clean. _______________________________________________ >> ipp mailing list >> ipp@pwg.org >> https://www.pwg.org/mailman/listinfo/ipp >=20 >=20 > --=20 > This message has been scanned for viruses and=20 > dangerous content by MailScanner, and is=20 > believed to be clean. >=20 > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp >=20 >=20 >=20 > --=20 > This message has been scanned for viruses and=20 > dangerous content by MailScanner, and is=20 > believed to be clean. > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_91Zyvf21dx+H3Mh9gq+T/Q) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Randy and Daniel,

I agree my wording for the client requirements still need= s some polish - toss it up to writing it up late at night... How about:

    Clients MUST support DNS-SD and/or WS-D= iscovery.


(the math geek in me like= s the intersection version below... :)

Sent from my iPad
<= br>On 2012-08-21, at 12:55 AM, Daniel Dressler <danieru.dressler@gmail.com> wrote:

As a random bystander I can con= firm that "one of X and Y" sounds a bit odd. Although the context does make= it clear.

How about "Clients MUST support either DNS-SD or WS-Disco= very or both" to eliminate any final confusion with English's exclusive or.=

While I'm being usless let me also suggest another wording "The interse= ction between the set of client's supported protocols and the set {DNS-SD, = WS-Discovery} must not be the empty set."

Daniel

2012/8/20 Randy Turner <= ;rturner@ama= lfisystems.com>

 i think I understa= nd the compromise, although I would have worded 1b and 2b a little differen= t

Clients MUST support either DNS-SD or WS-Discovery=E2= =80=A6.

It's just a different use of a contraction
"=E2=80=A6one of DNS-SD AND WS-Discovery"  seemed to use = an AND contraction which implied both - someone might inadvertently parse t= his in a way we didn't expect=E2=80=A6.although I got the gist of the compr= omise.

R.

On Au= g 20, 2012, at 9:16 PM, William A Wagner wrote:

I think this is a practical and reasonable compromis= e. From at least my perspective, this does not put an unreasonable addition= al burden on printers while  making potentially easier for clients to = achieve and claim compliance.
Bil= l Wagner
=  
From: ipp-bounces@pwg.org [mailto= :ipp-bounces@pwg.o= rg] On Behalf Of Michael Swe= et
Sent: Monday, August 20, 2012 9:42 PM
To: ipp@pwg.org
Subject:=  [IPP] IPP Everywhere and "The Great Compromise"
<= u> 
All,
 
We discussed the PWG Last Call comments received thus far at today's IPP WG= conference call.  Two of the comments concerned the client requiremen= ts to support DNS-SD for discovery and both PWG Raster and JPEG for documen= t formats.  After over an hour of spirited debate, the following "grea= t compromise" was proposed to resolve the last call comments:=
 
1. Discovery:
 
   a. Printers MUST support both DNS-SD and WS-Discovery (adds WS= -Discovery)
   b. Clients MUST support at least one of DNS-SD and WS-Discover= y (Clients can choose amongst the two required protocols)
 
2. Document Formats:
&= nbsp;
   a. Printers MUST support both JPEG and PWG Raster (no change)<= u>
   b. Clients MUST support at least one of JPEG and PWG Raster (r= elaxes conformance - previously a Client had to support both)=
 
Please comment on the proposed changes.
 
__________= _______________________________________________
Michael Sweet, Senior Pr= inting System Engineer, PWG Chair
=  

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

-- This message has been scanned for viruses and 
danger= ous content by MailScan= ner, and is 
believed to be clean. _______________________= ________________________
ipp mailing list
ipp@pw= g.org
https://www.pwg.org/mailman/list= info/ipp

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

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



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___________________= ____________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/l= istinfo/ipp

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_91Zyvf21dx+H3Mh9gq+T/Q)-- --===============0892239004== 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 --===============0892239004==-- From ipp-bounces@pwg.org Tue Aug 21 08:13:52 2012 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 E860E21F86B1 for ; Tue, 21 Aug 2012 08:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXvz5w6uO89c for ; Tue, 21 Aug 2012 08:13:51 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4421F86FC for ; Tue, 21 Aug 2012 08:13:51 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 6E3C07921C; Tue, 21 Aug 2012 11:13:29 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id E48ED7921B for ; Tue, 21 Aug 2012 11:13:16 -0400 (EDT) Received: from EEAEX02.us.epson.net ([148.130.64.7]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Aug 2012 08:13:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [IPP] IPP Everywhere and "The Great Compromise" Date: Tue, 21 Aug 2012 08:13:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPP] IPP Everywhere and "The Great Compromise" Thread-Index: Ac1/PjQ62VNdYnLaR76o0K6hUjQjSgAbli+w References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> From: "Petrie, Glen" To: "Michael Sweet" , X-OriginalArrivalTime: 21 Aug 2012 15:13:13.0639 (UTC) FILETIME=[7BC90B70:01CD7FAF] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0680089067==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 6E3C07921C.A9C2D X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============0680089067== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD7FAF.7B70D661" This is a multi-part message in MIME format. ------_=_NextPart_001_01CD7FAF.7B70D661 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike (all) =20 The change below pushes the burden to the printer (at an increased cost to the printer) while the Client, a software entity, has less burden. What is wrong with=20 =20 1. Discovery: =20 a. Clients MUST support DNS-SD and WS-Discovery=20 b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED to support both. =20 2. Document Formats: =20 a. Clients MUST support both JPEG and PWG Raster=20 b. Printers MUST support either JPEG or PWG Raster and RECOMMENDED to support both. =20 This change to the printer requirements could mean a faster time to market since printers are already support one of the discoveries and documents formats but may not support both discoveries and document formats.=20 =20 As was discussed in the meeting, if either discovery or document format change in the future, the backward compatibility burden would have to be on the Client to deal with legacy printers. There 'may' be an issue of Client legacy but I content that is still easier to update Clients rather than printer firmware. In the event of a Cloud Print Service or a Print Manager; then, I would assume the "RECOMMEDED" support of both would be implemented.=20=20 =20 Glen =20 =20 ________________________________ From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet Sent: Monday, August 20, 2012 6:42 PM To: ipp@pwg.org Subject: [IPP] IPP Everywhere and "The Great Compromise" =20 All, =20 We discussed the PWG Last Call comments received thus far at today's IPP WG conference call. Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats. After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments: =20 1. Discovery: =20 a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols) =20 2. Document Formats: =20 a. Printers MUST support both JPEG and PWG Raster (no change) b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both) =20 Please comment on the proposed changes. =20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair =20 --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner , and is believed to be clean.=20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CD7FAF.7B70D661 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike (all)<= /p>

 

The change below pushes the burden to the printer (at an increased cost to the printer) while the Client, a softw= are entity, has less burden.  What is wrong with =

 

1. Discovery:

 

   a. Clients MUST support DNS-SD and WS-Discovery

   b. Printers MUST suppor= t either DNS-SD or WS-Discovery and RECOMMENED to support both.

 

2. Document Formats:

 

a.      = = Clients MUST support both JPEG and PWG Raster

b.      = Printers MUST support either JPEG or PWG Raster and RECOMMENDED to support both.

 

This change to the printer requireme= nts could mean a faster time to market since printers are already support one of the discoveries and documents formats but may not support both discoveries = and document formats.

 

As was discussed in the meeting, if = either discovery or document format change in the future, the backward compatibili= ty burden would have to be on the Client to deal with legacy printers.   Th= ere 'may' be an issue of Client legacy but I content that is still easier to update Clients rather than printer firmware.   In the event of a Cloud P= rint Service or a Print Manager; then, I would assume the "RECOMMEDED" support of both would be implemented.  

 

Glen

 

 

From: ipp-boun= ces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf = Of Michael Sweet
Sent: Monday, August 20, 201= 2 6:42 PM
To: ipp@pwg.org
Subject: [IPP] IPP Everywher= e and "The Great Compromise"

 

All,

 

We discussed the PWG Last Call comments received thus far at today's IPP WG conference call.  Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG f= or document formats.  After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments= :

 

1. Discovery:

 

   a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)

   b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols)

 

2. Document Formats:

 

   a. Printers MUST support both JPEG and PWG Raster (no change)

   b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both)=

 

Please comment on the proposed changes.

 

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

 


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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CD7FAF.7B70D661-- --===============0680089067== 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 --===============0680089067==-- From ipp-bounces@pwg.org Tue Aug 21 08:28:46 2012 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 27B5321F8757 for ; Tue, 21 Aug 2012 08:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxihwqRz3DZo for ; Tue, 21 Aug 2012 08:28:45 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7F321F86E4 for ; Tue, 21 Aug 2012 08:28:45 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id EF4EF79221; Tue, 21 Aug 2012 11:28:29 -0400 (EDT) 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 pwg.org (Postfix) with ESMTP id AD1D779220 for ; Tue, 21 Aug 2012 11:28:16 -0400 (EDT) Received: by qaas11 with SMTP id s11so4588157qaa.5 for ; Tue, 21 Aug 2012 08:28:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=x3an0xeV8565S4Ao0ibr+mCzkVHoSA6OsfqmeVIXR5M=; b=Q5FfKlTauIc3e3bjXAQyV7mt2zOMQ6yV1s1UNwwdTQ2vjTxJeGpRCkcY80jhlMvInl K1nUcp4EoziDfPKVtAHzIdrsevWIPNAikd8MCTXUwyJorBmzoMuElIObkUJJfCVYQSED ON9iQOPtyAFKir7vPuffDxQV5+CW0NzkXJA/vb2BDyrZP8QSsKwGFWg4IB9zbre+DWzU 0tk67Eay/5Q9yul7svrenDIXipizJx9zO+u4rQSVZaEnLpi4KIl7Kp+fN3gX0nF9m4JR dB4HjFZ0fZvPoHFk2gr+bwBekvSUTSWtpqQ+MhGmOc35hPKAepTELjQyopnix31RNx32 Wjrg== Received: by 10.224.208.8 with SMTP id ga8mr9691908qab.83.1345562895652; Tue, 21 Aug 2012 08:28:15 -0700 (PDT) Received: from Richard-Grays-MacBook-Pro.local (gateway.plustechnologies.com. [198.136.170.2]) by mx.google.com with ESMTPS id g3sm1365095qah.5.2012.08.21.08.28.14 (version=SSLv3 cipher=OTHER); Tue, 21 Aug 2012 08:28:14 -0700 (PDT) Message-ID: <5033A90D.2050202@plustechnologies.com> Date: Tue, 21 Aug 2012 11:28:13 -0400 From: Rich Gray User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120810 Firefox/15.0 SeaMonkey/2.12 MIME-Version: 1.0 To: "Petrie, Glen" Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnXHOWPiy+jwHmlz6QgzDwTU6eP7dUJvRKtX8qEYttnoi6cN8tic3D9cjQOZDjeDM9xNHyW X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: EF4EF79221.A880E X-pwg-MailScanner-From: ipp-bounces@pwg.org "Printers MUST support X or Y and SHOULD support both." - Rich Petrie, Glen wrote: > Mike (all) > > > > The change below pushes the burden to the printer (at an increased cost > to the printer) while the Client, a software entity, has less burden. > What is wrong with > > > > 1. Discovery: > > > > a. Clients MUST support DNS-SD and WS-Discovery > > b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED > to support both. > > > > 2. Document Formats: > > > > a. Clients MUST support both JPEG and PWG Raster > > b. Printers MUST support either JPEG or PWG Raster and RECOMMENDED > to support both. > > > > This change to the printer requirements could mean a faster time to > market since printers are already support one of the discoveries and > documents formats but may not support both discoveries and document > formats. > > > > As was discussed in the meeting, if either discovery or document format > change in the future, the backward compatibility burden would have to be > on the Client to deal with legacy printers. There 'may' be an issue of > Client legacy but I content that is still easier to update Clients > rather than printer firmware. In the event of a Cloud Print Service or > a Print Manager; then, I would assume the "RECOMMEDED" support of both > would be implemented. > > > > Glen > > > > > > ________________________________ > > From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of > Michael Sweet > Sent: Monday, August 20, 2012 6:42 PM > To: ipp@pwg.org > Subject: [IPP] IPP Everywhere and "The Great Compromise" > > > > All, > > > > We discussed the PWG Last Call comments received thus far at today's IPP > WG conference call. Two of the comments concerned the client > requirements to support DNS-SD for discovery and both PWG Raster and > JPEG for document formats. After over an hour of spirited debate, the > following "great compromise" was proposed to resolve the last call > comments: > > > > 1. Discovery: > > > > a. Printers MUST support both DNS-SD and WS-Discovery (adds > WS-Discovery) > > b. Clients MUST support at least one of DNS-SD and WS-Discovery > (Clients can choose amongst the two required protocols) > > > > 2. Document Formats: > > > > a. Printers MUST support both JPEG and PWG Raster (no change) > > b. Clients MUST support at least one of JPEG and PWG Raster (relaxes > conformance - previously a Client had to support both) > > > > Please comment on the proposed changes. > > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > > > > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Tue Aug 21 08:43:10 2012 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 0499B21F84FC for ; Tue, 21 Aug 2012 08:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYpL3COgmsRR for ; Tue, 21 Aug 2012 08:43:08 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id D043921F85C0 for ; Tue, 21 Aug 2012 08:43:04 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id F1AFB79222; Tue, 21 Aug 2012 11:42:48 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by pwg.org (Postfix) with ESMTP id D7A0679221 for ; Tue, 21 Aug 2012 11:42:36 -0400 (EDT) Received: by lbbgj3 with SMTP id gj3so61964lbb.5 for ; Tue, 21 Aug 2012 08:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4uA7XjMbJbfZXX88cBXk16hqFtnVlalA6KwIlsqUfb8=; b=hhGTXgAawBHqyuixtxbHZqi3bYIer/lvH9OxxtnSKJDEJiwEstIdgCqqBywDuLZshF /DcVht/JeXo5+RiZpY/xZJhPbaJ0soPh//T4tJKgQh1dGqEMaV+sHTMxoCpgafq7JLDs BpK/JeWZR98sPEUnzXYePizcRu03RYmTzSW+9lJziee6cY9771X5kCjQy1PvffXFgF8L OuDnu3BtdKMJzFuiSaQRc1UHlBXqtPqol+yx9/s3C9kcrDjDpgoBq90MhscwB/fkoIIG z+H5IPwPKU88wl4x3TxLA0+2VWkwArg9oJaQsx7J4HVYtgSYxN5NH2OiM6IQKgfYywAc G+BA== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr18268961lab.29.1345563755483; Tue, 21 Aug 2012 08:42:35 -0700 (PDT) Received: by 10.112.128.233 with HTTP; Tue, 21 Aug 2012 08:42:35 -0700 (PDT) In-Reply-To: References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> Date: Tue, 21 Aug 2012 11:42:35 -0400 Message-ID: Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" From: Ira McDonald To: "Petrie, Glen" X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1433228911==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: F1AFB79222.AA773 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1433228911== Content-Type: multipart/alternative; boundary=f46d04088ef5ab139904c7c87969 --f46d04088ef5ab139904c7c87969 Content-Type: text/plain; charset=ISO-8859-1 Hi Glen, I understand why you want to lower Printer implementation burden, but your proposal defeats the essence of the "Great Compromise", which is focused on support of IPP Everywhere by OS vendors (to achieve what the user thinks is "driver-less printing"). As you say, Printer firmware doesn't change often - but if it once supports the two document formats and two discovery protocols it will reliably interoperate w/ all IPP Everywhere Clients in the future. 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 Temporary Cabin *** 2012 only *** 906-494-2523 On Tue, Aug 21, 2012 at 11:13 AM, Petrie, Glen wrote: > Mike (all)**** > > ** ** > > The change below pushes the burden to the printer (at an increased cost to > the printer) while the Client, a software entity, has less burden. What is > wrong with **** > > ** ** > > 1. Discovery:**** > > ** ** > > a. Clients MUST support DNS-SD and WS-Discovery **** > > b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED > to support both.**** > > ** ** > > 2. Document Formats:**** > > ** ** > > **a. **Clients MUST support both JPEG and PWG Raster **** > > **b. **Printers MUST support either JPEG or PWG Raster and > RECOMMENDED to support both.**** > > ** ** > > This change to the printer requirements could mean a faster time to market > since printers are already support one of the discoveries and documents > formats but may not support both discoveries and document formats. **** > > ** ** > > As was discussed in the meeting, if either discovery or document format > change in the future, the backward compatibility burden would have to be on > the Client to deal with legacy printers. There 'may' be an issue of > Client legacy but I content that is still easier to update Clients rather > than printer firmware. In the event of a Cloud Print Service or a Print > Manager; then, I would assume the "RECOMMEDED" support of both would be > implemented. **** > > ** ** > > Glen**** > > ** ** > > ** ** > ------------------------------ > > *From:* ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] *On Behalf Of *Michael > Sweet > *Sent:* Monday, August 20, 2012 6:42 PM > > *To:* ipp@pwg.org > *Subject:* [IPP] IPP Everywhere and "The Great Compromise" > **** > > ** ** > > All,**** > > ** ** > > We discussed the PWG Last Call comments received thus far at today's IPP > WG conference call. Two of the comments concerned the client requirements > to support DNS-SD for discovery and both PWG Raster and JPEG for document > formats. After over an hour of spirited debate, the following "great > compromise" was proposed to resolve the last call comments:**** > > ** ** > > 1. Discovery:**** > > ** ** > > a. Printers MUST support both DNS-SD and WS-Discovery (adds > WS-Discovery)**** > > b. Clients MUST support at least one of DNS-SD and WS-Discovery > (Clients can choose amongst the two required protocols)**** > > ** ** > > 2. Document Formats:**** > > ** ** > > a. Printers MUST support both JPEG and PWG Raster (no change)**** > > b. Clients MUST support at least one of JPEG and PWG Raster (relaxes > conformance - previously a Client had to support both)**** > > ** ** > > Please comment on the proposed changes.**** > > ** ** > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair**** > > ** ** > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean. **** > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean. > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --f46d04088ef5ab139904c7c87969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Glen,

I understand why you want to lower Printer implementation b= urden,
but your proposal defeats the essence of the "Great Compromi= se",
which is focused on support of IPP Everywhere by OS vendors (t= o
achieve what the user thinks is "driver-less printing").

A= s you say, Printer firmware doesn't change often - but if it once
s= upports the two document formats and two discovery protocols it
will re= liably interoperate w/ all IPP Everywhere Clients in the=A0future.

Cheers,
- Ira


Ira McDonald (Musician / Soft= ware Architect)
Chair - Linux Foundation Open Printing WG
Secretary -= IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-C= hair - TCG Trusted Mobility 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
Temporary Cabin= *** 2012 only *** 906-494-2523
=



On Tue, Aug 21, 2012 at 11:13 AM, Petrie= , Glen <glen.petrie@eitc.epson.com> wrote:

Mike (all)<= /u>

=A0<= /u>

The change bel= ow pushes the burden to the printer (at an increased cost to the printer) while the Client, a softw= are entity, has less burden.=A0 What is wrong with =

=A0<= /u>

1. Discovery:<= u>

=A0<= /u>

=A0 =A0a. Clie= nts MUST support DNS-SD and WS-Discovery

=A0 =A0b. Prin= ters MUST support either DNS-SD or WS-Discovery and RECOMMENED to support both.=

=A0<= /u>

2. Document Fo= rmats:

=A0<= /u>

a.=A0=A0=A0=A0=A0=A0 Clients MUST support both JPEG and PWG Raster

b.=A0=A0=A0=A0=A0 = Printers MUST support either JPEG or PWG Raster and RECOMMENDED to support both.<= /u>

=A0<= /u>

This change to= the printer requirements could mean a faster time to market since printers are already support one of the discoveries and documents formats but may not support both discoveries = and document formats.

=A0<= /u>

As was discuss= ed in the meeting, if either discovery or document format change in the future, the backward compatibili= ty burden would have to be on the Client to deal with legacy printers.=A0=A0 There &#= 39;may' be an issue of Client legacy but I content that is still easier to update Clients rather than printer firmware.=A0=A0 In the event of a Cloud Print Service or a Print Manager; then, I would assume the "RECOMMEDED" support of both would be implemented. =A0

=A0<= /u>

Glen=

=A0<= /u>

=A0<= /u>

From: ipp-bounces@pwg.org [mailto:ipp-bounce= s@pwg.org] On Behalf Of = Michael Sweet
Sent: Monday, August 20, 201= 2 6:42 PM


To: ipp@pwg.org
Subject: [IPP] IPP Everywher= e and "The Great Compromise"

=A0

All,

=A0

We discussed the PWG Last Call comments received thu= s far at today's IPP WG conference call. =A0Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG f= or document formats. =A0After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments= :

=A0

1. Discovery:

=A0

=A0 =A0a. Printers MUST support both DNS-SD and WS-D= iscovery (adds WS-Discovery)

=A0 =A0b. Clients MUST support at least one of DNS-S= D and WS-Discovery (Clients can choose amongst the two required protocols)=

=A0

2. Document Formats:

=A0

=A0 =A0a. Printers MUST support both JPEG and PWG Ra= ster (no change)

=A0 =A0b. Clients MUST support at least one of JPEG = and PWG Raster (relaxes conformance - previously a Client had to support both)

=A0

Please comment on the proposed changes.

=A0

____= _____________________________________________________
Michael Sweet, Senior Printing System=A0Engineer, PWG Chair

=A0


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


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

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



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --f46d04088ef5ab139904c7c87969-- --===============1433228911== 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 --===============1433228911==-- From ipp-bounces@pwg.org Tue Aug 21 08:49:21 2012 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 8819A21F8568 for ; Tue, 21 Aug 2012 08:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi2EkLSZ926i for ; Tue, 21 Aug 2012 08:49:18 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4521F8449 for ; Tue, 21 Aug 2012 08:49:18 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id CDCEE79227; Tue, 21 Aug 2012 11:48:58 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by pwg.org (Postfix) with ESMTP id 3FBA179221 for ; Tue, 21 Aug 2012 11:48:43 -0400 (EDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7LFmffZ020024 for ; Tue, 21 Aug 2012 11:48:41 -0400 Authentication-Results: cm-omr1 smtp.user=ptykodi@tykodi.com; auth=pass (LOGIN) X-Authenticated-UID: ptykodi@tykodi.com Received: from [24.34.47.110] ([24.34.47.110:55935] helo=TCS2010LAPTOP) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0F/DC-06143-8DDA3305; Tue, 21 Aug 2012 11:48:41 -0400 From: "Paul Tykodi" To: "'Petrie, Glen'" References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> In-Reply-To: Subject: RE: [IPP] IPP Everywhere and "The Great Compromise" Date: Tue, 21 Aug 2012 11:48:41 -0400 Organization: Tykodi Consulting Services LLC Message-ID: <01b401cd7fb4$701a1210$504e3630$@tykodi.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-Index: AQH+txeNgYooz1HBlyqPB78/bpVDpgKYMOsBlu03l+A= X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ptykodi@tykodi.com List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1839490056==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: CDCEE79227.A9930 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multipart message in MIME format. --===============1839490056== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B5_01CD7F92.E90D2D00" Content-language: en-us This is a multipart message in MIME format. ------=_NextPart_000_01B5_01CD7F92.E90D2D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Glen, Do you think accepting your proposal for the device (i.e. printer) and making it available to both the client and the printer could work? It means that not all IPP Everywhere conforming clients and printers would necessarily be interoperable and it would support Justin's position that in this specific area market need should drive the discovery and the document formats a particular vendor found their customers reported were must haves. Just a thought . Best Regards, /Paul -- Paul Tykodi Principal Consultant TCS - Tykodi Consulting Services LLC Tel/Fax: 603-343-1820 Mobile: 603-866-0712 E-mail: ptykodi@tykodi.com WWW: http://www.tykodi.com From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Petrie, Glen Sent: Tuesday, August 21, 2012 11:13 AM To: Michael Sweet; ipp@pwg.org Subject: RE: [IPP] IPP Everywhere and "The Great Compromise" Mike (all) The change below pushes the burden to the printer (at an increased cost to the printer) while the Client, a software entity, has less burden. What is wrong with 1. Discovery: a. Clients MUST support DNS-SD and WS-Discovery b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED to support both. 2. Document Formats: a. Clients MUST support both JPEG and PWG Raster b. Printers MUST support either JPEG or PWG Raster and RECOMMENDED to support both. This change to the printer requirements could mean a faster time to market since printers are already support one of the discoveries and documents formats but may not support both discoveries and document formats. As was discussed in the meeting, if either discovery or document format change in the future, the backward compatibility burden would have to be on the Client to deal with legacy printers. There 'may' be an issue of Client legacy but I content that is still easier to update Clients rather than printer firmware. In the event of a Cloud Print Service or a Print Manager; then, I would assume the "RECOMMEDED" support of both would be implemented. Glen _____ From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet Sent: Monday, August 20, 2012 6:42 PM To: ipp@pwg.org Subject: [IPP] IPP Everywhere and "The Great Compromise" All, We discussed the PWG Last Call comments received thus far at today's IPP WG conference call. Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats. After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols) 2. Document Formats: a. Printers MUST support both JPEG and PWG Raster (no change) b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both) Please comment on the proposed changes. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_01B5_01CD7F92.E90D2D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Glen,

 

=

Do you think accepting your proposal for the de= vice (i.e. printer) and making it available to both the client and the prin= ter could work?

 = ;

It means that not all IPP Eve= rywhere conforming clients and printers would necessarily be interoperable = and it would support Justin’s position that in this specific area mar= ket need should drive the discovery and the document formats a particular v= endor found their customers reported were must haves.

=

 

Just a thought …

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

Best Regards,=

 <= /p>

/Paul

--

=

Paul Tykodi
Principal Consultant
TCS = - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:&nb= sp; 603-866-0712
E-mail:  pty= kodi@tykodi.com
WWW:  http://www.tykodi.com

From: ipp-bounces@pwg.org [mailto:ipp-bou= nces@pwg.org] On Behalf Of Petrie, Glen
Sent: Tuesday, Aug= ust 21, 2012 11:13 AM
To: Michael Sweet; ipp@pwg.org
Subjec= t: RE: [IPP] IPP Everywhere and "The Great Compromise"

 

Mik= e (all)

 

The change b= elow pushes the burden to the printer (at an increased cost to the printer)= while the Client, a software entity, has less burden.  What is wrong = with

 

1. Discovery:<= o:p>

 

   a. Clie= nts MUST support DNS-SD and WS-Discovery

  &n= bsp;b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED t= o support both.

 

2. D= ocument Formats:

 

a.       Client= s MUST support both JPEG and PWG Raster

b.      <= span style=3D'font-family:"Cambria","serif";color:blue'>Printers MUST suppo= rt either JPEG or PWG Raster and RECOMMENDED to support both.

 

This change to the printer requir= ements could mean a faster time to market since printers are already suppor= t one of the discoveries and documents formats but may not support both dis= coveries and document formats.

<= span style=3D'font-family:"Cambria","serif";color:blue'> 

As was discussed in the meeting, if either discovery or documen= t format change in the future, the backward compatibility burden would have= to be on the Client to deal with legacy printers.   There 'may' = be an issue of Client legacy but I content that is still easier to update C= lients rather than printer firmware.   In the event of a Cloud Pr= int Service or a Print Manager; then, I would assume the "RECOMMEDED&q= uot; support of both would be implemented.  

<= o:p> 

Glen

 

 

From: ipp-bounces@pwg.org [= mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet
Sen= t: Monday, August 20, 2012 6:42 PM
To: ipp@pwg.org
Subject: [IPP] IPP Everywhere and "= The Great Compromise"

=  

All,

 

We discus= sed the PWG Last Call comments received thus far at today's IPP WG conferen= ce call.  Two of the comments concerned the client requirements to sup= port DNS-SD for discovery and both PWG Raster and JPEG for document formats=  After over an hour of spirited debate, the following "great com= promise" was proposed to resolve the last call comments:

 

1. Discovery:

 

   a. Printers= MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)

   b. Clients MUST support at l= east one of DNS-SD and WS-Discovery (Clients can choose amongst the two req= uired protocols)

 <= /o:p>

2. Document Formats:

 

   a. Printers MUST support both JPEG and PWG Raster= (no change)

   b. = Clients MUST support at least one of JPEG and PWG Raster (relaxes conforman= ce - previously a Client had to support both)

 

Pleas= e comment on the proposed changes.

 

__________= _______________________________________________
Michael Sweet, Senior Pr= inting System Engineer, PWG Chair

 


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


--
This me= ssage has been scanned for viruses and
dangerous content by MailScanner, and is
believed t= o be clean.


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_01B5_01CD7F92.E90D2D00-- --===============1839490056== 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 --===============1839490056==-- From ipp-bounces@pwg.org Tue Aug 21 08:52:31 2012 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 D276121F8780 for ; Tue, 21 Aug 2012 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA7VMpH-2aIZ for ; Tue, 21 Aug 2012 08:52:31 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 294C521F86DE for ; Tue, 21 Aug 2012 08:52:30 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id C61A37922F; Tue, 21 Aug 2012 11:52:09 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 94D0079229 for ; Tue, 21 Aug 2012 11:51:57 -0400 (EDT) MIME-version: 1.0 Received: from relay15.apple.com ([17.128.113.54]) 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 <0M94002263W4IW50@mail-out.apple.com> for ipp@pwg.org; Tue, 21 Aug 2012 08:51:54 -0700 (PDT) X-AuditID: 11807136-b7fed6d000005bf5-8d-5033ae99477c Received: from [17.151.78.83] (Unknown_Domain [17.151.78.83]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 74.C0.23541.99EA3305; Tue, 21 Aug 2012 08:51:54 -0700 (PDT) Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" From: Michael Sweet In-reply-to: Date: Tue, 21 Aug 2012 11:51:53 -0400 Message-id: References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> To: "Petrie, Glen" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUiON0vWHfWOuMAg5/X5C22n/3FYnFs30sW iyPfYh2YPbae/MHmcXD+LHaPeYunMwUwR3HZpKTmZJalFunbJXBlPHg+g6XgfGTFiyV5DYw3 fbsYOTkkBEwkOt4tY4WwxSQu3FvP1sXIxSEkMJlJYvmk5WAJYQEbie8XVrOD2LwCehKz2+ew gNjMAgkSt85cZQSx2QTUJH5P6gOr5xTwkvhy/CuYzSKgKvFvVTsrRD2/xMHeD8wQc2wk5s8B mcMBtKxK4v5PLZCwiIC+xKePm5kg7pGV+H74PNsERr5ZSDbPQrIZwtaWWLbwNfMsoEnMAjoS kxeiCUPYH88fYVrAyLaKUbAoNSex0tBUL7GgICdVLzk/dxMjKGQbCs12MO74K3eIUYCDUYmH 90GvUYAQa2JZcWXuIUYJDmYlEd6iycYBQrwpiZVVqUX58UWlOanFhxilOViUxHmnlQFVC6Qn lqRmp6YWpBbBZJk4OKUaGNsmCa8vW6B6Q8rcdWaY3Yzr1y896Z29SZ2N6WPRkV37bBYwv1/H tTM89V2bsY8lewdD9LcFdhMezM7dw3hkz5PaiWVWjD2f94SwfLx/3OPpzJ95/7iLjD994YhN 4Ds3x2Q7j9zF1ff/Xlwovu546b3nVyzueGR2zddW3Tr5d4Jd6o1nd4KNL2QosRRnJBpqMRcV JwIATFfG2lUCAAA= X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1326708825==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: C61A37922F.A96E1 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1326708825== Content-type: multipart/alternative; boundary="Boundary_(ID_IapSHSyXQIRe1PMauaDYUg)" --Boundary_(ID_IapSHSyXQIRe1PMauaDYUg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Glen, Comments inline... On Aug 21, 2012, at 11:13 AM, "Petrie, Glen" wrote: > Mike (all) > > The change below pushes the burden to the printer (at an increased cost to the printer) while the Client, a software entity, has less burden. What is wrong with > > 1. Discovery: > > a. Clients MUST support DNS-SD and WS-Discovery > b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED to support both. Pretty much all printers already support DNS-SD and WS-Discovery, which is why we opted to put the "burden" on the printers (since they already carry that burden). > 2. Document Formats: > > a. Clients MUST support both JPEG and PWG Raster > b. Printers MUST support either JPEG or PWG Raster and RECOMMENDED to support both. I personally would rather just see a single format (PWG Raster) be required since it is the only simple raster format that works for text, graphics, and photos. However, Justin objected to PWG Raster because Microsoft currently does not support it. Thus the "great compromise". Many printers already support JPEG via dedicated hardware, and PWG Raster uses the same compression algorithm that is used by most vendor PDLs, so again I am not sure we are really increasing the burden for printers and the printer requirement to support both has been in the spec for over a year now... > This change to the printer requirements could mean a faster time to market since printers are already support one of the discoveries and documents formats but may not support both discoveries and document formats. I would argue that document formats and discovery protocols are not the hard parts - doing a GOOD implementation of IPP is much more difficult, as the interoperability reports can attest. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_IapSHSyXQIRe1PMauaDYUg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Glen,

Comments inline...
=


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --bcaec552428a58074004c7e4b687-- --===============1969799579== 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 --===============1969799579==-- From pwg-announce-bounces@pwg.org Wed Aug 22 18:30:46 2012 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 9D46B21F8543 for ; Wed, 22 Aug 2012 18:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp0TkwQA89+C for ; Wed, 22 Aug 2012 18:30:45 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 515BA21F8541 for ; Wed, 22 Aug 2012 18:30:45 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 67DB479217; Wed, 22 Aug 2012 21:30:25 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by pwg.org (Postfix) with ESMTP id D761879214 for ; Wed, 22 Aug 2012 21:30:12 -0400 (EDT) Received: by lbbgj3 with SMTP id gj3so130667lbb.5 for ; Wed, 22 Aug 2012 18:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6YFPS+BaVQTpv7BW/TBWSKr2vkzMk3w4kFMD0xKN6vw=; b=ZqwpULSvcxGn4/9sgsFWaCZalOxGlJ9i6b/w/ssFQGpgvilD8PbfV6U/Ae5v0+IlCy iICw3iUcm84uEp6ORm28Hi1rFpKcierz1jnkNuM6cZ1uA718+U/c4kpRVhcYN7LIr5PD R9fPycctp94LFlULqDOoWfMIXnsBkaGMT2ruC+sjDjCy+uPVfoGhIdpVlaxWLstYBxUp qEwO1CX3cnqpPZoJQ8h2izX9V/FC5DflZgLLAGb8re+uGKvzWMBnG4aEAhMBLT4Xp709 ZtRQA9xDuPPLdW3jJBWae4L1F6iDSM+t61QURtFM1UgExc/qEcHZGj0yxKL2bGgp8NGB QUXg== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr23582668lab.29.1345685411619; Wed, 22 Aug 2012 18:30:11 -0700 (PDT) Received: by 10.112.128.233 with HTTP; Wed, 22 Aug 2012 18:30:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Aug 2012 21:30:11 -0400 Message-ID: From: Ira McDonald To: Michael Sweet , Ira McDonald X-pwg-MailScanner: Found to be clean, Found to be clean Cc: pwg-announce@pwg.org Subject: [Pwg-Announce] REMINDER - PWG Last Call of IPP Everywhere (ends 8/24/12) X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1182988427==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 67DB479217.ADFA3 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============1182988427== Content-Type: multipart/alternative; boundary=f46d04088ef5f0649c04c7e4cc11 --f46d04088ef5f0649c04c7e4cc11 Content-Type: text/plain; charset=ISO-8859-1 Hi, Reminder to all to acknowledge their review of IPP Everywhere spec by *this* Friday (24 August 2012). We still need *two* more PWG Last Call responses to achieve quorum and move on to PWG Formal Vote in September. All those in the room or on the phone at the PWG F2F IPP Everywhere review, please take a moment to send your acknowledgement. Cheers, - Ira (PWG Secretary) 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 Temporary Cabin *** 2012 only *** 906-494-2523 On Fri, Aug 17, 2012 at 1:59 PM, Ira McDonald wrote: > Hi, > > Reminder to all to acknowledge their review of IPP Everywhere spec > by next Friday (24 August 2012). > > All those in the room or on the phone at last week's IPP Everywhere > review, please take a moment to send your acknowledgement. > > Cheers, > - Ira (PWG Secretary) > > 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 > Temporary Cabin *** 2012 only *** 906-494-2523 > > > > On Wed, Jul 25, 2012 at 2:53 PM, Michael Sweet wrote: > >> [THIS TIME WITH THE CORRECT URL...] >> >> All, >> >> [This PWG Last Call starts today Tuesday July 24, 2012 and ends Friday >> August 24, 2012 at 10pm US PST.] >> >> This is the formal announcement of the PWG Last Call for the IPP >> Everywhere specification, located at: >> >> ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20120724.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 voting members >> must acknowledge a PWG Last Call (with or without comments), before any >> document can progress to PWG Formal Vote. This PWG Last Call is NOT a >> Formal Vote but it DOES require your review acknowledgment. >> >> >> HOW TO RESPOND >> >> Send an email with *exactly* the following subject line format: >> Subject: has reviewed the IPP Everywhere 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 >> Everywhere 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 >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by *MailScanner* , and >> is >> believed to be clean. >> >> _______________________________________________ >> pwg-announce mailing list >> pwg-announce@pwg.org >> https://www.pwg.org/mailman/listinfo/pwg-announce >> >> > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --f46d04088ef5f0649c04c7e4cc11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Reminder to all to acknowledge their review of IPP Everywhere sp= ec
by *this* Friday (24 August 2012).=A0

We still need *two* mor= e PWG Last Call responses to achieve quorum
and move on to PWG Formal V= ote in September.

All those in the room or on the phone at the PWG F2F IPP Everywhere
= review, please take a moment to send your acknowledgement.

Cheers,
- Ira (PWG Secretary)


Ira McDonald= (Musician / Software Architect)
Chair - Linux Foundation Open Printing = WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO P= WG 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
Temporary Cabin= *** 2012 only *** 906-494-2523
=



On Fri, Aug 17, 2012 at 1:59 PM, Ira McD= onald <blueroofmusic@gmail.com> wrote:
Hi,

Reminder to all to acknowledge their review of IPP Everywhere sp= ec
by next Friday (24 August 2012).

All those in the room or on t= he phone at last week's IPP Everywhere
review, please take a moment = to send your acknowledgement.

Cheers,
- Ira (PWG Secretary)

Ira McDonald (Mu= sician / Software Architect)
Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG I= PP 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
Temporary Cabin *** 2012 only *** 906-494-2523
=



On Wed, Jul 25, 2012 at 2:53 PM, Michael= Sweet <msweet@apple.com> wrote:
<= div>[THIS TIME WITH THE CORRECT URL..= .]

= All,

[= This PWG Last Call starts today Tuesday July 24, 2012 and ends Friday Augus= t 24, 2012 at 10pm US PST.]

This is the formal announcement of th= e PWG Last Call for the IPP Everywhere specification, located at:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10= -20120724.pdf

A= ll required attributes and values defined in this document have been protot= yped by Apple and/or other vendors. The IPP WG has completed extensive revi= ew of the various revisions of this document and an IPP WG last call.

T= he PWG Process/3.0 requires that a quorum (30%) of PWG voting members must = acknowledge a PWG Last Call (with or without comments), before any document= can progress to PWG Formal Vote. =A0This PWG Last Call is NOT a Formal Vot= e but it 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 Everywhere specification and has [no] comments


WHERE TO SEND YOUR RESPONSE
Please send your response to *all* of the f= ollowing email addresses (replacing "dot" with '.' and &q= uot;at" with '@'):

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 Everywhere E= ditor)

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


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

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




--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --f46d04088ef5f0649c04c7e4cc11-- --===============1182988427== 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 --===============1182988427==-- From ipp-bounces@pwg.org Thu Aug 23 02:21:44 2012 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 842CA21F8594 for ; Thu, 23 Aug 2012 02:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOPOQ-NTQJ4p for ; Thu, 23 Aug 2012 02:21:44 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id ECC7821F8550 for ; Thu, 23 Aug 2012 02:21:43 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id ACA1779246; Thu, 23 Aug 2012 05:21:28 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from USA7109MR005.ACS-INC.COM (usa7109mr005.acs-inc.com [63.87.171.174]) by pwg.org (Postfix) with ESMTP id 529A37923F for ; Thu, 23 Aug 2012 05:21:13 -0400 (EDT) Received: from usa7109ht002.na.xerox.net ([13.41.230.32]) by USA7109MR005.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 23 Aug 2012 04:21:13 -0500 Received: from USA0300GW001.na.xerox.net (13.135.209.15) by USA7109HT002.na.xerox.net (13.41.230.32) with Microsoft SMTP Server id 14.1.355.2; Thu, 23 Aug 2012 04:21:12 -0500 Received: from USA7061MS04.na.xerox.net ([13.151.235.15]) by USA0300GW001.na.xerox.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 05:21:12 -0400 Received: from 13.151.235.15 ([13.151.235.15]) by USA7061MS04.na.xerox.net ([13.151.235.15]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Aug 2012 09:21:10 +0000 Date: Thu, 23 Aug 2012 05:21:06 -0400 Message-ID: thread-topic: Xerox has reviewed the IPP Everywhere specification and has no comments thread-index: Ac2BEKI4NoZB9n7dTzeDBsuSPDYFyA== Importance: normal From: "Zehler, Peter" To: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2012 09:21:12.0131 (UTC) FILETIME=[A3363130:01CD8110] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Xerox has reviewed the IPP Everywhere specification and has no comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "peter.zehler" List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1759897821==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: ACA1779246.A97A7 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1759897821== Content-Type: multipart/alternative; boundary="--_com.android.email_365159868591040"; charset="utf-8" ----_com.android.email_365159868591040 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGV0ZXIgWmVobGVyCgoKLS0gClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZApkYW5nZXJvdXMgY29udGVudCBieSBNYWls U2Nhbm5lciwgYW5kIGlzCmJlbGlldmVkIHRvIGJlIGNsZWFuLgoK ----_com.android.email_365159868591040 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9k eT48ZGl2PlBldGVyIFplaGxlcjwvZGl2PjxkaXY+PGJyPjwvZGl2PiA8YnIg Lz4tLSAKPGJyIC8+VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9y IHZpcnVzZXMgYW5kCjxiciAvPmRhbmdlcm91cyBjb250ZW50IGJ5CjxhIGhy ZWY9Imh0dHA6Ly93d3cubWFpbHNjYW5uZXIuaW5mby8iPjxiPk1haWxTY2Fu bmVyPC9iPjwvYT4sIGFuZCBpcwo8YnIgLz5iZWxpZXZlZCB0byBiZSBjbGVh bi4KPC9ib2R5PjwvaHRtbD4K ----_com.android.email_365159868591040-- --===============1759897821== 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 --===============1759897821==-- From ipp-bounces@pwg.org Thu Aug 23 07:02:44 2012 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 1F4A921F844E for ; Thu, 23 Aug 2012 07:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyBEXw-kJwTU for ; Thu, 23 Aug 2012 07:02:42 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id E175621F8444 for ; Thu, 23 Aug 2012 07:02:41 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 862DB7924C; Thu, 23 Aug 2012 10:02:28 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id AF06D7924A for ; Thu, 23 Aug 2012 10:02:12 -0400 (EDT) MIME-version: 1.0 Received: from relay15.apple.com ([17.128.113.54]) 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 <0M97006U1OBJ4ZG2@mail-out.apple.com> for ipp@pwg.org; Thu, 23 Aug 2012 07:02:09 -0700 (PDT) X-AuditID: 11807136-b7f6b6d00000741d-d2-503637d97785 Received: from [17.151.75.143] (Unknown_Domain [17.151.75.143]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id E8.05.29725.1E736305; Thu, 23 Aug 2012 07:02:09 -0700 (PDT) Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" From: Michael Sweet In-reply-to: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> Date: Thu, 23 Aug 2012 10:02:03 -0400 Message-id: References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> To: "ipp@pwg.org" X-Mailer: Apple Mail (2.1486) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiON27X/ehuVmAwbFOI4tj+16yWBz5FuvA 5LH15A82j3mLpzMFMEVx2aSk5mSWpRbp2yVwZfQ+XslacNihYuuxyAbGfeZdjJwcEgImEn1N C5khbDGJC/fWs3UxcnEICUxlkriw8DobSIJZIEFi5ZFDTF2MHBy8AnoSp/cmgISFBWwkvl9Y zQ5iswmoSfye1McKYnMK2Eocv7eSBcRmEVCVeLZ5EZjNC1S/ZWoHmC0EZP98dgJsr4iAvMTa tqlMEDfISuy/v49xAiPvLCSbZyFshghrSyxb+JoZJMwsoCMxeSEjqjCE/fH8EaYFjGyrGAWL UnMSKw1N9RILCnJS9ZLzczcxgoKwodBsB+OOv3KHGAU4GJV4eC2MTQOEWBPLiitzDzFKcDAr ifB6cZoFCPGmJFZWpRblxxeV5qQWH2KU5mBREud9FQ5ULZCeWJKanZpakFoEk2Xi4JRqYOyx C1HIEDd6/Mavqn5nlOUMtRVrJWpvLJ9if+HbhcVtlfVLVxj2GejXBp08xvqFq25Jc9q37R8U 9q75wrvLQPHA5wcHWy+dkW5x5cvNUPZZ3xkedeb3G5sL2SWzvVM9eIqe7TOammRQe1D7xWTz OwHbeJ/2TIt7cWd9KvMKi625dzQneTNPyVJiKc5INNRiLipOBABZxOFTPgIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1017590902==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 862DB7924C.A9B07 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1017590902== Content-type: multipart/alternative; boundary="Boundary_(ID_ayYc5euNpt/NbUnLAv44ig)" --Boundary_(ID_ayYc5euNpt/NbUnLAv44ig) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT After letting this sink in over the past couple days, I have to pull my support for allowing a client to only support JPEG. Aside from the quality issues, JPEG does not support multiple page content and so does not satisfy the requirements set forth in the IPP Everywhere spec and current charter. That leaves us with: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support DNS-SD and/or WS-Discovery (Clients can choose amongst the two required protocols) I humbly suggest that the <1000 lines of code (CUPS' implementation is 830 lines for both read and write) needed to generate PWG Raster is not an undue burden on clients to implement support for and conform to IPP Everywhere. Please comment, and we will review this at the next IPP conference call on September 10th. On Aug 20, 2012, at 9:42 PM, Michael Sweet wrote: > All, > > We discussed the PWG Last Call comments received thus far at today's IPP WG conference call. Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats. After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments: > > 1. Discovery: > > a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) > b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols) > > 2. Document Formats: > > a. Printers MUST support both JPEG and PWG Raster (no change) > b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both) > > Please comment on the proposed changes. > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_ayYc5euNpt/NbUnLAv44ig) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable After letting this sink i= n over the past couple days, I have to pull my support for allowing a clien= t to only support JPEG.  Aside from the quality issues, JPEG does not = support multiple page content and so does not satisfy the requirements set = forth in the IPP Everywhere spec and current charter.  That leaves us = with:

1. Discovery:
   a. Print= ers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)
   b. Clients MUST support DNS-SD and/or WS-Discovery (Clients c= an choose amongst the two required protocols)

I hu= mbly suggest that the <1000 lines of code (CUPS' implementation is 830 l= ines for both read and write) needed to generate PWG Raster is not an undue= burden on clients to implement support for and conform to IPP Everywhere.<= /div>

Please comment, and we will review this at the nex= t IPP conference call on September 10th.


On Aug 20, 2012, at 9:42 PM, Michael Sweet <msweet@apple.com> wrote:

All,

We discussed the PWG Last Call comments recei= ved thus far at today's IPP WG conference call.  Two of the comments c= oncerned the client requirements to support DNS-SD for discovery and both P= WG Raster and JPEG for document formats.  After over an hour of spirit= ed debate, the following "great compromise" was proposed to resolve the las= t call comments:

1. Discovery:

   a. Printers MUST support both DNS-SD and WS-Discovery (a= dds WS-Discovery)
   b. Clients MUST support at least o= ne of DNS-SD and WS-Discovery (Clients can choose amongst the two required = protocols)

2. Document Formats:

   a. Printers MUST support both JPEG and PWG Raster (no c= hange)
   b. Clients MUST support at least one of JPEG = and PWG Raster (relaxes conformance - previously a Client had to support bo= th)

Please comment on the proposed changes.
<= div>
MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/l= istinfo/ipp

_________________________________________________= ________
Michael Sweet, Senior Printing System Engineer, PWG Chair<= /div>


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_ayYc5euNpt/NbUnLAv44ig)-- --===============1017590902== 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 --===============1017590902==-- From ipp-bounces@pwg.org Thu Aug 23 10:23:43 2012 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 3D99521F8555 for ; Thu, 23 Aug 2012 10:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoBu6LkklqcI for ; Thu, 23 Aug 2012 10:23:42 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93321F855E for ; Thu, 23 Aug 2012 10:23:42 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7536C79251; Thu, 23 Aug 2012 13:23:27 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail4.sharplabs.com (mail4.sharplabs.com [216.65.151.214]) by pwg.org (Postfix) with ESMTP id BABF579250 for ; Thu, 23 Aug 2012 13:23:14 -0400 (EDT) X-ASG-Debug-ID: 1345742592-02080805ffd7e50001-ml9GHW Received: from WABCASP2.sharpamericas.com ([172.29.224.252]) by mail4.sharplabs.com with ESMTP id cfFdYHMaRE9fYn52; Thu, 23 Aug 2012 10:23:12 -0700 (PDT) X-Barracuda-Envelope-From: jmurdock@sharplabs.com Received: from WABEXCHP1.sharpamericas.com ([fe80::f930:84ca:49e6:2cbd]) by WABCASP2.sharpamericas.com ([172.29.224.3]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 10:23:12 -0700 From: "Murdock, Joe" X-Barracuda-Apparent-Source-IP: fe80::f930:84ca:49e6:2cbd To: "ipp@pwg.org" , "Ira McDonald (blueroofmusic@gmail.com)" , "ptykodi@tykodi.com" , "Michael Sweet (msweet@apple.com)" Thread-Topic: Sharp has reviewed the IPP Everywhere specification and has no comments X-ASG-Orig-Subj: Sharp has reviewed the IPP Everywhere specification and has no comments Thread-Index: Ac2BU+mxEzXXJH58TIeOH+xbOpDKRg== Date: Thu, 23 Aug 2012 17:23:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.229.74] MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.29.224.252] X-Barracuda-Start-Time: 1345742592 X-Barracuda-URL: http://mail4.enet.sharplabs.com:8000/cgi-mod/mark.cgi Received-SPF: none (sharplabs.com: jmurdock@sharplabs.com does not designate permitted sender hosts) X-Virus-Scanned: by bsmtpd at sharplabs.com X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.106501 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Sharp has reviewed the IPP Everywhere specification and has no comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0541856451==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 7536C79251.A8FD7 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0541856451== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E301B2F12DBCCF4394DEA69FD0E703700CAF5E0Bwabexchp1sharpa_" --_000_E301B2F12DBCCF4394DEA69FD0E703700CAF5E0Bwabexchp1sharpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --------------------------------------- Joe Murdock Principal Engineer and Researcher Chair IEEE/ISTO Printer Working Group Imaging Device Security Sharp Labs of America 5750 NW Pacific Rim Blvd Camas, WA 98607 (360) 817-7542 jmurdock@sharplabs.com --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_E301B2F12DBCCF4394DEA69FD0E703700CAF5E0Bwabexchp1sharpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

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

Joe Murdock

Principal Engineer a= nd Researcher

Chair IEEE/ISTO Prin= ter Working Group Imaging Device Security

Sharp Labs of Americ= a

5750 NW Pacific Rim = Blvd

Camas, WA 98607=

(360) 817-7542<= /o:p>

jmurdock@sharplabs.com

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_E301B2F12DBCCF4394DEA69FD0E703700CAF5E0Bwabexchp1sharpa_-- --===============0541856451== 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 --===============0541856451==-- From ipp-bounces@pwg.org Thu Aug 23 12:31:23 2012 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 00E3321F86AA for ; Thu, 23 Aug 2012 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASlYFjWUsn83 for ; Thu, 23 Aug 2012 12:31:22 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9721F86B8 for ; Thu, 23 Aug 2012 12:31:21 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A934479258; Thu, 23 Aug 2012 15:31:06 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from r2-10.ricohsv.com (r2-10.ricohsv.com [140.239.88.4]) by pwg.org (Postfix) with ESMTP id 1B2EE79257 for ; Thu, 23 Aug 2012 15:30:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by r2-10.ricohsv.com (Postfix) with ESMTP id 8F6D38C0B8; Thu, 23 Aug 2012 12:30:34 -0700 (PDT) Received: from r2-10.ricohsv.com ([127.0.0.1]) by localhost (r2-10.ricohsv.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AR2ewkWCk2i; Thu, 23 Aug 2012 12:30:34 -0700 (PDT) Received: from [172.30.10.48] (unknown [172.30.10.48]) by r2-10.ricohsv.com (Postfix) with ESMTP id 19C5A8C07F; Thu, 23 Aug 2012 12:30:34 -0700 (PDT) Message-ID: <503684D7.30702@ricohsv.com> Date: Thu, 23 Aug 2012 12:30:31 -0700 From: Brian Smithson Organization: Ricoh Americas Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ira McDonald , Paul Tykodi , Michael Sweet , ipp@pwg.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Ricoh has reviewed the IPP Everywhere specification and has no comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: A934479258.A8CEF X-pwg-MailScanner-From: ipp-bounces@pwg.org -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Thu Aug 23 13:36:28 2012 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 58B8A21F854A for ; Thu, 23 Aug 2012 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkUSti8zDF6d for ; Thu, 23 Aug 2012 13:36:27 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9710A21F8549 for ; Thu, 23 Aug 2012 13:36:27 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 705C67925E; Thu, 23 Aug 2012 16:36:15 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-gw.okidata.com (mail-gw.okidata.com [207.77.135.74]) by pwg.org (Postfix) with ESMTP id 6A9A67925D for ; Thu, 23 Aug 2012 16:36:03 -0400 (EDT) To: Ira McDonald , Paul Tykodi , Michael Sweet , ipp@pwg.org MIME-Version: 1.0 X-KeepSent: 135AAE98:47532EC4-85257A63:006BE309; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: Nancy.Chen@okidata.com Date: Thu, 23 Aug 2012 16:36:13 -0400 X-MIMETrack: Serialize by Router on ODA-SMTP-MTA/OKIDATA/OKI_DATA_CORP/OKI_ELECTRIC/US(Release 8.5.1FP5|September 29, 2010) at 08/23/2012 04:36:03 PM, Serialize complete at 08/23/2012 04:36:03 PM X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Oki Data has reviewed the IPP Everywhere specification and has no comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1131067667==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 705C67925E.A8C49 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multipart message in MIME format. --===============1131067667== Content-Type: multipart/alternative; boundary="=_alternative 007138E785257A63_=" This is a multipart message in MIME format. --=_alternative 007138E785257A63_= Content-Type: text/plain; charset="US-ASCII" -Nancy --------------------------------------------------- Nancy Chen Principal Engineer Solutions and Technology Services & Solution Business - US Oki Data 2000 Bishops Gate Blvd. Mt. Laurel, NJ 08054 Phone: +1 (856) 222-7006 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=_alternative 007138E785257A63_= Content-Type: text/html; charset="US-ASCII" -Nancy
---------------------------------------------------
Nancy Chen
Principal Engineer
Solutions and Technology
Services & Solution Business - US
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: +1 (856) 222-7006
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --=_alternative 007138E785257A63_=-- --===============1131067667== 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 --===============1131067667==-- From ipp-bounces@pwg.org Thu Aug 23 15:13:12 2012 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 38AB921F8487 for ; Thu, 23 Aug 2012 15:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPB8GCvpSWNp for ; Thu, 23 Aug 2012 15:13:11 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9023721F847F for ; Thu, 23 Aug 2012 15:13:10 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id AF97079265; Thu, 23 Aug 2012 18:12:55 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail5.sharplabs.com (mail5.sharplabs.com [67.52.115.54]) by pwg.org (Postfix) with ESMTP id 7CE1D7925E for ; Thu, 23 Aug 2012 18:12:43 -0400 (EDT) X-ASG-Debug-ID: 1345759961-0313f60aceafc00001-ml9GHW Received: from WABCASP1.sharpamericas.com ([172.29.224.253]) by mail5.sharplabs.com with ESMTP id g7OvxsFjEeCAj93Z for ; Thu, 23 Aug 2012 15:12:41 -0700 (PDT) X-Barracuda-Envelope-From: jmurdock@sharplabs.com Received: from WABEXCHP1.sharpamericas.com ([fe80::f930:84ca:49e6:2cbd]) by Wabcasp1 ([172.29.224.2]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 15:12:40 -0700 From: "Murdock, Joe" X-Barracuda-Apparent-Source-IP: fe80::f930:84ca:49e6:2cbd To: "ipp@pwg.org" Subject: RE: [IPP] IPP Everywhere and "The Great Compromise" Thread-Topic: [IPP] IPP Everywhere and "The Great Compromise" X-ASG-Orig-Subj: RE: [IPP] IPP Everywhere and "The Great Compromise" Thread-Index: AQHNfz42QzNtAvf+OE2YVHG8E0ZZX5dn5pqAgAATUZA= Date: Thu, 23 Aug 2012 22:12:39 +0000 Message-ID: References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.229.74] MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.29.224.253] X-Barracuda-Start-Time: 1345759961 X-Barracuda-URL: http://172.29.222.36:8000/cgi-mod/mark.cgi Received-SPF: none (sharplabs.com: jmurdock@sharplabs.com does not designate permitted sender hosts) X-Virus-Scanned: by bsmtpd at sharplabs.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.0082 1.0000 -1.9675 X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=CN_BODY_332, HTML_MESSAGE, INFO_TLD, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.106521 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 INFO_TLD URI: Contains an URL in the INFO top-level domain 0.00 HTML_MESSAGE BODY: HTML included in message X-pwg-MailScanner: Found to be clean, Found to be clean X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530074154==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: AF97079265.AACA3 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1530074154== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E301B2F12DBCCF4394DEA69FD0E703700CAF60F8wabexchp1sharpa_" --_000_E301B2F12DBCCF4394DEA69FD0E703700CAF60F8wabexchp1sharpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with the proposed changes device supports DNS-SD and WS-Discovery a= nd JPEG and PNG-Raster. From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael= Sweet Sent: Thursday, August 23, 2012 7:02 AM To: ipp@pwg.org Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" After letting this sink in over the past couple days, I have to pull my sup= port for allowing a client to only support JPEG. Aside from the quality is= sues, JPEG does not support multiple page content and so does not satisfy t= he requirements set forth in the IPP Everywhere spec and current charter. = That leaves us with: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support DNS-SD and/or WS-Discovery (Clients can choose a= mongst the two required protocols) I humbly suggest that the <1000 lines of code (CUPS' implementation is 830 = lines for both read and write) needed to generate PWG Raster is not an undu= e burden on clients to implement support for and conform to IPP Everywhere. Please comment, and we will review this at the next IPP conference call on = September 10th. On Aug 20, 2012, at 9:42 PM, Michael Sweet > wrote: All, We discussed the PWG Last Call comments received thus far at today's IPP WG= conference call. Two of the comments concerned the client requirements to= support DNS-SD for discovery and both PWG Raster and JPEG for document for= mats. After over an hour of spirited debate, the following "great compromi= se" was proposed to resolve the last call comments: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients= can choose amongst the two required protocols) 2. Document Formats: a. Printers MUST support both JPEG and PWG Raster (no change) b. Clients MUST support at least one of JPEG and PWG Raster (relaxes con= formance - previously a Client had to support both) Please comment on the proposed changes. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_E301B2F12DBCCF4394DEA69FD0E703700CAF60F8wabexchp1sharpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with the proposed= changes device supports DNS-SD and WS-Discovery and JPEG and PNG-Raster.

 <= /p>

From: ipp-boun= ces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Thursday, August 23, 2012 7:02 AM
To: ipp@pwg.org
Subject: Re: [IPP] IPP Everywhere and "The Great Compromise&quo= t;

 

After letting this sink in over the past couple days= , I have to pull my support for allowing a client to only support JPEG. &nb= sp;Aside from the quality issues, JPEG does not support multiple page conte= nt and so does not satisfy the requirements set forth in the IPP Everywhere spec and current charter.  That leave= s us with:

 

1. Discovery:

   a. Printers MUST support both DNS-= SD and WS-Discovery (adds WS-Discovery)

   b. Clients MUST support DNS-SD and/or W= S-Discovery (Clients can choose amongst the two required protocols)

 

I humbly suggest that the <1000 lines of code (CU= PS' implementation is 830 lines for both read and write) needed to generate= PWG Raster is not an undue burden on clients to implement support for and = conform to IPP Everywhere.

 

Please comment, and we will review this at the next = IPP conference call on September 10th.

 

 

On Aug 20, 2012, at 9:42 PM, Michael Sweet <msweet@apple.com> wrote:



All,

 

We discussed the PWG Last Call comments received thu= s far at today's IPP WG conference call.  Two of the comments concerne= d the client requirements to support DNS-SD for discovery and both PWG Rast= er and JPEG for document formats.  After over an hour of spirited debate, the following "great compromise"= ; was proposed to resolve the last call comments:

 

1. Discovery:

 

   a. Printers MUST support both DNS-SD an= d WS-Discovery (adds WS-Discovery)

   b. Clients MUST support at least one of= DNS-SD and WS-Discovery (Clients can choose amongst the two required proto= cols)

 

2. Document Formats:

 

   a. Printers MUST support both JPEG and = PWG Raster (no change)

   b. Clients MUST support at least one of= JPEG and PWG Raster (relaxes conformance - previously a Client had to supp= ort both)

 

Please comment on the proposed changes.

 

________________________________________= _________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 


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

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

 

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

 


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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_E301B2F12DBCCF4394DEA69FD0E703700CAF60F8wabexchp1sharpa_-- --===============1530074154== 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 --===============1530074154==-- From ipp-bounces@pwg.org Thu Aug 23 15:24:41 2012 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 A26F021F8540 for ; Thu, 23 Aug 2012 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6sQ4-3jegDy for ; Thu, 23 Aug 2012 15:24:40 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 428A021F8525 for ; Thu, 23 Aug 2012 15:24:40 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id A2B7B79268; Thu, 23 Aug 2012 18:24:23 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-gw.okidata.com (mail-gw.okidata.com [207.77.135.74]) by pwg.org (Postfix) with ESMTP id 29E5979265 for ; Thu, 23 Aug 2012 18:24:10 -0400 (EDT) In-Reply-To: References: <344643D3-5B0A-4381-9EAE-0084F6D1EAEE@apple.com> To: ipp@pwg.org Subject: RE: [IPP] IPP Everywhere and "The Great Compromise" MIME-Version: 1.0 X-KeepSent: B0CEA411:B7644AE7-85257A63:007ACEB8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: Nancy.Chen@okidata.com Date: Thu, 23 Aug 2012 18:24:09 -0400 X-MIMETrack: Serialize by Router on ODA-SMTP-MTA/OKIDATA/OKI_DATA_CORP/OKI_ELECTRIC/US(Release 8.5.1FP5|September 29, 2010) at 08/23/2012 06:24:10 PM Content-Type: multipart/mixed; boundary="=_mixed 007B227885257A63_=" X-pwg-MailScanner: Found to be clean, Found to be clean X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: A2B7B79268.A9CCE X-pwg-MailScanner-From: ipp-bounces@pwg.org --=_mixed 007B227885257A63_= Content-Type: multipart/alternative; boundary="=_alternative 007B227885257A63_=" --=_alternative 007B227885257A63_= Content-Type: text/plain; charset="US-ASCII" Same here - device supports DNS-SD and WS-Discovery and JPEG and PNG-Raster. -Nancy --------------------------------------------------- Nancy Chen Principal Engineer Solutions and Technology Services & Solution Business - US Oki Data 2000 Bishops Gate Blvd. Mt. Laurel, NJ 08054 Phone: +1 (856) 222-7006 "Murdock, Joe" Sent by: ipp-bounces@pwg.org 08/23/2012 06:12 PM To "ipp@pwg.org" , cc Subject RE: [IPP] IPP Everywhere and "The Great Compromise" I agree with the proposed changes device supports DNS-SD and WS-Discovery and JPEG and PNG-Raster. From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet Sent: Thursday, August 23, 2012 7:02 AM To: ipp@pwg.org Subject: Re: [IPP] IPP Everywhere and "The Great Compromise" After letting this sink in over the past couple days, I have to pull my support for allowing a client to only support JPEG. Aside from the quality issues, JPEG does not support multiple page content and so does not satisfy the requirements set forth in the IPP Everywhere spec and current charter. That leaves us with: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support DNS-SD and/or WS-Discovery (Clients can choose amongst the two required protocols) I humbly suggest that the <1000 lines of code (CUPS' implementation is 830 lines for both read and write) needed to generate PWG Raster is not an undue burden on clients to implement support for and conform to IPP Everywhere. Please comment, and we will review this at the next IPP conference call on September 10th. On Aug 20, 2012, at 9:42 PM, Michael Sweet > wrote: All, We discussed the PWG Last Call comments received thus far at today's IPP WG conference call. Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats. After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments: 1. Discovery: a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery) b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols) 2. Document Formats: a. Printers MUST support both JPEG and PWG Raster (no change) b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both) Please comment on the proposed changes. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=_alternative 007B227885257A63_= Content-Type: text/html; charset="US-ASCII" Same here - device supports DNS-SD and WS-Discovery and JPEG and PNG-Raster.

-Nancy
---------------------------------------------------
Nancy Chen
Principal Engineer
Solutions and Technology
Services & Solution Business - US
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: +1 (856) 222-7006


"Murdock, Joe" <jmurdock@sharplabs.com>
Sent by: ipp-bounces@pwg.org

08/23/2012 06:12 PM

To
"ipp@pwg.org" <ipp@pwg.org>,
cc
Subject
RE: [IPP] IPP Everywhere and "The Great Compromise"




I agree with the proposed changes device supports DNS-SD and WS-Discovery and JPEG and PNG-Raster.
From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Thursday, August 23, 2012 7:02 AM
To: ipp@pwg.org
Subject: Re: [IPP] IPP Everywhere and "The Great Compromise"
After letting this sink in over the past couple days, I have to pull my support for allowing a client to only support JPEG.  Aside from the quality issues, JPEG does not support multiple page content and so does not satisfy the requirements set forth in the IPP Everywhere spec and current charter.  That leaves us with:
1. Discovery:
a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)
b. Clients MUST support DNS-SD and/or WS-Discovery (Clients can choose amongst the two required protocols)

I humbly suggest that the <1000 lines of code (CUPS' implementation is 830 lines for both read and write) needed to generate PWG Raster is not an undue burden on clients to implement support for and conform to IPP Everywhere.
Please comment, and we will review this at the next IPP conference call on September 10th.

On Aug 20, 2012, at 9:42 PM, Michael Sweet <msweet@apple.com<mailto:msweet@apple.com>> wrote:

All,
We discussed the PWG Last Call comments received thus far at today's IPP WG conference call.  Two of the comments concerned the client requirements to support DNS-SD for discovery and both PWG Raster and JPEG for document formats.  After over an hour of spirited debate, the following "great compromise" was proposed to resolve the last call comments:
1. Discovery:
a. Printers MUST support both DNS-SD and WS-Discovery (adds WS-Discovery)
b. Clients MUST support at least one of DNS-SD and WS-Discovery (Clients can choose amongst the two required protocols)

2. Document Formats:
a. Printers MUST support both JPEG and PWG Raster (no change)
b. Clients MUST support at least one of JPEG and PWG Raster (relaxes conformance - previously a Client had to support both)

Please comment on the proposed changes.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp@pwg.org<mailto:ipp@pwg.org>
https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --=_alternative 007B227885257A63_=-- --=_mixed 007B227885257A63_= Content-Type: text/html; name="C.htm" Content-Disposition: attachment; filename="C.htm" Content-Transfer-Encoding: quoted-printable

I agree with the proposed= changes device supports DNS-SD and WS-Discovery and JPEG and PNG-Raster.

 <= /p>

From: ipp-boun= ces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of Michael Sweet
Sent: Thursday, August 23, 2012 7:02 AM
To: ipp@pwg.org
Subject: Re: [IPP] IPP Everywhere and "The Great Compromise&quo= t;

 

After letting this sink in over the past couple days= , I have to pull my support for allowing a client to only support JPEG. &nb= sp;Aside from the quality issues, JPEG does not support multiple page conte= nt and so does not satisfy the requirements set forth in the IPP Everywhere spec and current charter.  That leave= s us with:

 

1. Discovery:

   a. Printers MUST support both DNS-= SD and WS-Discovery (adds WS-Discovery)

   b. Clients MUST support DNS-SD and/or W= S-Discovery (Clients can choose amongst the two required protocols)

 

I humbly suggest that the <1000 lines of code (CU= PS' implementation is 830 lines for both read and write) needed to generate= PWG Raster is not an undue burden on clients to implement support for and = conform to IPP Everywhere.

 

Please comment, and we will review this at the next = IPP conference call on September 10th.

 

 

On Aug 20, 2012, at 9:42 PM, Michael Sweet <msweet@apple.com> wrote:



All,

 

We discussed the PWG Last Call comments received thu= s far at today's IPP WG conference call.  Two of the comments concerne= d the client requirements to support DNS-SD for discovery and both PWG Rast= er and JPEG for document formats.  After over an hour of spirited debate, the following "great compromise"= ; was proposed to resolve the last call comments:

 

1. Discovery:

 

   a. Printers MUST support both DNS-SD an= d WS-Discovery (adds WS-Discovery)

   b. Clients MUST support at least one of= DNS-SD and WS-Discovery (Clients can choose amongst the two required proto= cols)

 

2. Document Formats:

 

   a. Printers MUST support both JPEG and = PWG Raster (no change)

   b. Clients MUST support at least one of= JPEG and PWG Raster (relaxes conformance - previously a Client had to supp= ort both)

 

Please comment on the proposed changes.

 

________________________________________= _________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 


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

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

 

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

 


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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. = --=_mixed 007B227885257A63_= 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 --=_mixed 007B227885257A63_=-- From ipp-bounces@pwg.org Thu Aug 23 19:19:40 2012 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 789C021F8514 for ; Thu, 23 Aug 2012 19:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51Pv-Ii0i-6R for ; Thu, 23 Aug 2012 19:19:38 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1F60E21F8513 for ; Thu, 23 Aug 2012 19:19:38 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id DFEE779271; Thu, 23 Aug 2012 22:19:19 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id C14717926F for ; Thu, 23 Aug 2012 22:19:03 -0400 (EDT) MIME-version: 1.0 Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M98004LBMDYXQI1@mail-out.apple.com> for ipp@pwg.org; Thu, 23 Aug 2012 19:18:51 -0700 (PDT) X-AuditID: 11807134-b7f486d0000026ad-01-5036e4879316 Received: from [17.151.78.140] (Unknown_Domain [17.151.78.140]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 0A.71.09901.884E6305; Thu, 23 Aug 2012 19:18:50 -0700 (PDT) Subject: Re: [IPP] Minutes from today's conference call From: Michael Sweet In-reply-to: <000001cd7fcb$0c8b0b20$25a12160$@net> Date: Thu, 23 Aug 2012 22:18:46 -0400 Message-id: <11A48EC3-B464-48C0-AAEE-3423A821EDEB@apple.com> References: <000001cd7fcb$0c8b0b20$25a12160$@net> To: William A Wagner X-Mailer: Apple Mail (2.1486) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUiON2vR7friVmAwfJOY4tj+16yWBz5Fmtx 7oKiA7PH1pM/2DwmP57D6DFv8XSmAOYoLpuU1JzMstQifbsErow1y8oL/rQzVXxYcpStgfHW A8YuRk4OCQETiZdbu6BsMYkL99azdTFycQgJTGWSuLN8JzNIQljAXOL1rrcsXYwcHLwCehKn 9yaAhJkFEiQuPd3GAmKzCahJ/J7UxwpSwilgJNH8BWwki4CqxM1z7SwQ5fwSB3s/gE3kFbCR mHfrMDuILSSQJHHiy2U2EFtEQEeiuWEm1DmyEvvv72OcwMg3C2HxLCSLIWxtiWULXzND2JoS +7uXYxHXkOj8NpF1ASPbKkbBotScxEpDE73EgoKcVL3k/NxNjKCQbSg02cF48Cf/IUYBDkYl Ht4D3WYBQqyJZcWVuYcYJTiYlUR45z8GCvGmJFZWpRblxxeV5qQWH2KU5mBREudlTwJKCaQn lqRmp6YWpBbBZJk4OKUaGE2fiU9/fCGov7qUIfWCI/uS/Y2SJgmHv4ubCXJxl/VeUjvSJBn2 lD1/+XXj/Y9ynpmzPf9jcI03wKhwemW8L4tI9U/2xQxa0mG2KdMZ2WQeLrx1y1jyuuSbSd/k ZXqvhR27kLrx9V4VM8l9byeKcjqEyC308dK9freVV7Keye7Fsx8LfH9wKbEUZyQaajEXFScC ADMrQtpVAgAA X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0699165236==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: DFEE779271.AB8AC X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0699165236== Content-type: multipart/alternative; boundary="Boundary_(ID_yLhb/t9TJAJ8ls19EmHOEg)" --Boundary_(ID_yLhb/t9TJAJ8ls19EmHOEg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable BIll, I checked the process document and non-voting members do indeed count towar= ds quorum for last call. See section 8.1 (bold/italic text highlights the = important bits): 8.1 Last Call Last Call represents a final opportunity for issues to be raised against a = document. During this period all PWG members are encouraged to review the f= inal working draft for both technical and editorial content and to provide = comments to the Working Group. The Working Group Chair announces a Last Cal= l on a document with rough consensus of the Working Group. Last Calls are p= osted to all members of the PWG via the PWG-ANNOUNCE mailing list. The Last= Call period may vary, based upon the content, complexity, holidays, or oth= er circumstances, but must be at least 16 full working days (minimum 22 cal= endar days). A working day is a normal business day and is considered to en= d at 10 PM USPST (Los Angeles, CA, USA). For any document transitioning to = Candidate Standard or Standard, Last Call must either conclude at, or span = a PWG Plenary meeting with an overview of the draft or standards document a= nd a review of any current detailed issues and their resolutions. If less t= han 30 percent of the PWG membership have commented, participated, or commu= nicated that they have no comments for a given document during Last Call, t= he Last Call period is automatically extended until that threshold is met. = Within a reasonable period of time following closure of Last Call, all issu= es raised during Last Call must be either resolved or rejected as follows: =E2=80=A2 =E2=8E=AF Resolved - Document updated to reflect the resolution =09 =E2=80=A2 =E2=8E=AF Rejected - No change required in the document All issues and their resolution from the most recent Last Call must be publ= ished in the Formal Approval announcement. According to section 2.1, a non-voting member is still a member and can par= ticipate in everything except voting and serving as an officer of the PWG, = so if it is OK with you I'd like to include these items in the last call co= mments for IPP Everywhere. Thanks! On Aug 21, 2012, at 2:30 PM, William A Wagner wrote: > As requested, I am outlining some of the differences between the IPP Ever= ywhere Use Cases and the revised Cloud Use Cases. First, since the general= position has been that, as a nonvoting member, my comments do not count to= ward the quorum, I make these observations on IPP Everywhere vs. Cloud =E2= =80=9CUse Cases=E2=80=9D as comments on the conference call rather than las= t call comments on the document. Second, I am noting the divergence of the = two use cases from the same original set not as critical comments on the IP= P Everywhere Use Cases, but to indicate the legitimate differences in how = one looks at these cases. I can think of no reason why the two sets of use = cases must be the same in style, form or specifics, provided that they are= realistic and useful in developing requirements. Further, I believe it is = valid to conclude that a requirement evolving from a Use Case need not be = addressed in thesolutions, provided that a reason for the omission is given= . However, in that there were some issues that came up in addressing the IP= P Everywhere use cases that had also been addressed in the Cloud Use Cases,= I offer this summary. >=20=20 > With that preface, I would note that the original Use Cases included both= concise statements of cases where a specific feature would be used (which = I would call Use Cases), and narratives giving a more or less plausible si= tuation (perhaps better called scenarios). The IPP Everywhere spec gives sp= ecific use cases under =E2=80=9CSelect Printer=E2=80=9D , but reverts to m= ore of a scenario approach for the =E2=80=9CPrint=E2=80=9D section. I see n= o problem with this approach although I admit a bias toward stating scenar= ios, with the requirements developed from the scenarios breaking out the de= tails (e.g., specific criteria used for selection). >=20=20 > One line of thinking in the Cloud discussion was that requirements were t= o be developed to address use cases (or scenarios) and the design was to b= e developed to satisfy the requirements. Therefore, it seemed inappropriate= to describe the Use Cases in terms of the elements of the model design. So= the Cloud scenarios were rephrased in terms of the basic elements=E2=80=A6= the User (or more specifically, the potential Job Originator), the physical= printer and the stuff in between (primarily the Cloud , the big black box = in the sky). I do not suggest this as a comment on the IPP Everywhere spec= ification, just as the thoughts that are reflected in the Cloud Rationale = section. >=20=20 > With regard to specific changes in the Cloud vs IPP Everywhere versions o= f what was initially the same use case: >=20=20 > 1. If Common Preconditions in Cloud were important, it was felt tha= t they should be itemized and presented as a distinct section. Once they we= re made more obvious, they were variously considered to be wrongly stated, = obvious, or more appropriately stated in the requirements section. We are = not sure what we will do with them. > 2. Objections to the Common Preconditions also stemmed from the con= fusion of the term =E2=80=9CVisible=E2=80=9D. Even in IPP Everywhere, it is= sort of contradictory to say =E2=80=9Cthe Printer must be Visible to the C= lient in order to be selected, either directly or through an intermediate S= ervice=E2=80=9D when =E2=80=9CVisible=E2=80=9D is defined as the ability to= communicate directly. The other confusion developed from the definition=E2= =80=99s referring to the =E2=80=9Cability=E2=80=9D to communicate, suggesti= ng that at some time under some conditions the connection could exist whil= e the normal sense of the word suggests that the connection does exist. > 3. Print a Document =E2=80=93 no significant difference. Original = statement specifying some relationship of user to printer was considered co= nfusing and was removed. Comments on validating were considered perhaps par= t of requirements or solution. > 4. Print by Reference. =E2=80=93 same comments as Print a Document > 5. Print a Photo/Print Using Loaded Media. =E2=80=93 Titles diverg= ed some time ago. Preconditions were considered more requirements. > 6. Check printing =E2=80=93 Cloud sought to clarify that this did n= ot involve sending a =E2=80=9Cform template=E2=80=9D to the printer. Also, = to include an obvious Cloud scenario, the application is Cloud Based (not n= ecessary for IPP Everywhere). I suggest that, in the IPP Everywhere text, = Client sends the =E2=80=9Cdocument data containing the checks=E2=80=9D mig= ht be confusing, since check usually refers to the printed media. > 7. Print with Special Formatting was dropped from Cloud as not repr= esenting a sufficiently distinct set of requirements. > 8. The original Prescription print case in Cloud was changed to a p= hotoprint involving selection on the basis of geographic location and print= to someone other than the job originator. The prescription case seemed too= loaded with HIPAA problems. > 9. Print and Select was changed to avoid reference to =E2=80=98Foll= owMe=C2=AE=E2=80=9D (a registered trademark of Ringdale) > 10. Print to a Service =E2=80=93 aside from some minor clarification, n= o change. > 11. Job Cancel=E2=80=A6that is canceling a job request after it has bee= n submitted and accepted was taken as a use case rather than an exception. = This may be more appropriate for Cloud since the Cloud model does require i= ntermediaries between the job originator and the printer. > 12. Exceptions: Main change was identifying the exception but not the a= ctions to be taken, under the premise that the way the system reacts is to = be indicated under Requirements and how it does this is to be in the Model. >=20=20 > I would note that Pete indicated that there are User use cases (rather th= an just Job Originator use cases) that have not been covered and may be add= ed, but that is a Cloud problem. >=20=20 > Aside from things that have already been noted in yesterday=E2=80=99s cal= l, I do not think that the divergence in how the use cases are presented re= presents a problem. But perhaps some of the wording (such as the treatment = of =E2=80=9CPrint and Select=E2=80=9D) may be of interest when addressing s= imilar issues in IPP Everywhere. > Thanks, > Bill Wagner >=20=20 > Thanks, >=20=20 >=20=20 >=20=20 >=20 > --=20 > This message has been scanned for viruses and=20 > dangerous content by MailScanner, and is=20 > believed to be clean. _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_yLhb/t9TJAJ8ls19EmHOEg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable = BIll,

I checked the process document and non-voting memb= ers do indeed count towards quorum for last call.  See section 8.1 (bo= ld/italic text highlights the important bits):

8.= 1 Last Call

= Last Call represents a final opportunity for issues to be raised against a = document. During this period all PWG members are encouraged= to review the final working draft for both technical and editorial content= and to provide comments to the Working Group. The Workin= g Group Chair announces a Last Call on a document with rough consensus= of the Working Group. Last Calls are posted to all members of the PWG= via the PWG-ANNOUNCE mailing list. The Last Call period may vary, bas= ed upon the content, complexity, holidays, or other circumstances,&nbs= p;but must be at least 16 full working days (minimum 22 calendar days). A&n= bsp;working day is a normal business day and is considered to end at 1= 0 PM USPST (Los Angeles, CA, USA). For any document transitioning to C= andidate Standard or Standard, Last Call must either conclude at, or s= pan a PWG Plenary meeting with an overview of the draft or standa= rds document and a review of any current detailed issues and their resoluti= ons. If less than 30 percent of the PWG membership have com= mented, participated, or communicated that they have no comments for a give= n document during Last Call, the Last Call period is automatically ext= ended until that threshold is met. Within a reasonable period&= nbsp;of time following closure of Last Call, all issues raised during Last = Call must be either resolved or rejected as follows:

=E2=80=A2 =E2=8E=AF  Rejected - No change requ= ired in the document

All issues and their resolution from the most recent = Last Call must be published in the Formal Approval announcement.

According to section 2.1, a non-voting member is still a member= and can participate in everything except voting and serving as an officer = of the PWG, so if it is OK with you I'd like to include these items in= the last call comments for IPP Everywhere.

Thanks= !


On Aug 21, 2012, at 2:30 PM, = William A Wagner <wamwagner@com= cast.net> wrote:

As requested, I am outlining some of the differences between the IPP= Everywhere Use Cases and the revised Cloud Use Cases.  First, since t= he general position has been that, as a nonvoting member, my comments do no= t count toward the quorum, I make these observations on IPP Everywhere vs. = Cloud =E2=80=9CUse Cases=E2=80=9D as comments on the conference call rather= than last call comments on the document. Second, I am noting the divergenc= e of the two use cases from the same original set not as critical comments = on the IPP Everywhere Use Cases, but to indicate the  legitimate diffe= rences in how one looks at these cases. I can think of no reason why the tw= o sets of use cases must be the same in style,  form or specifics, pro= vided that they are realistic and useful in developing requirements. Furthe= r, I believe it is valid to conclude that a requirement  evolving from= a Use Case need not be addressed in thesolutions, provided that a reason f= or the omission is given. However, in that there were some issues that came= up in addressing the IPP Everywhere use cases that had also been addressed= in the Cloud Use Cases, I offer this summary.
 
With that preface, I would note that the original Use = Cases included both concise statements of cases where a specific feature wo= uld be used (which I would call Use Cases), and narratives giving a  m= ore or less plausible situation (perhaps better called scenarios). The IPP = Everywhere spec gives specific use cases under  =E2=80=9CSelect Printe= r=E2=80=9D , but reverts to more of a scenario approach for the =E2=80=9CPr= int=E2=80=9D section. I see no problem with this approach although I  = admit a bias toward stating scenarios, with the requirements developed from= the scenarios breaking out the details (e.g., specific criteria used for s= election).
=  
One line of thi= nking in the Cloud discussion was that requirements were to be developed to= address use cases (or scenarios)  and the design was to be developed = to satisfy the requirements. Therefore, it seemed inappropriate to describe= the Use Cases in terms of the elements of the model design. So the Cloud s= cenarios were rephrased in terms of the basic elements=E2=80=A6the User (or= more specifically, the potential Job Originator), the physical printer and= the stuff in between (primarily the Cloud , the big black box in the sky).=   I do not suggest this as a comment on the IPP Everywhere specificati= on, just as the thoughts that are reflected in the Cloud  Rationale se= ction.
&nbs= p;
With regard to spec= ific changes in the Cloud vs IPP Everywhere versions of what was initially = the same use case:
 
1.       If Common Preconditions in Cloud were important, it was felt that they = should be itemized and presented as a distinct section. Once they were made= more obvious, they were variously considered to be wrongly stated, obvious= , or more appropriately stated  in the requirements section. We are no= t sure what we will do with them.
2.   = ;    Objections to the Common Preconditions al= so stemmed from the confusion of the term =E2=80=9CVisible=E2=80=9D. Even i= n IPP Everywhere, it is sort of contradictory to say =E2=80=9Cthe Pr= inter must be Visible to the Client in order to be selected, either directl= y or through an intermediate Service=E2=80=9D when =E2=80=9CVisible=E2=80= =9D is defined as the ability to communicate directly. The other confusion = developed from the definition=E2=80=99s referring to the =E2=80=9Cability= =E2=80=9D to communicate, suggesting that at some time under some condition= s the connection could exist  while the normal sense of the word sugge= sts that the connection does exist.
3.4.       Print by Refer= ence. =E2=80=93 same comments as Print a Document
5.       Print  a Photo/Print= Using Loaded Media. =E2=80=93 Titles diverged some time ago. Preconditions= were considered more requirements.
6.
7. =       <= /span>Print with Special Formatting was dropped from C= loud as not representing a sufficiently distinct set of requirements.
8.       The o= riginal Prescription print case in Cloud was changed to a photoprint involv= ing selection on the basis of geographic location and print to someone othe= r than the job originator. The prescription case seemed too loaded with HIP= AA problems.
9.   &n= bsp;   <= /span>Print and Select was changed to avoid reference to =E2=80=98Fo= llowMe=C2=AE=E2=80=9D (a registered trademark of Ringdale)
10.   Print to a Service =E2=80=93 aside from= some minor clarification, no change.
11.   Job Cancel=E2=80=A6that is canceling a job request after it = has been submitted and accepted was taken as a use case rather than an exce= ption. This may be more appropriate for Cloud since the Cloud model does re= quire intermediaries between the job originator and the printer.
12.   Exceptions: Mai= n change was identifying the exception but not the actions to be taken, und= er the premise that the way the system reacts is to be indicated under Requ= irements and how it does this is to be in the Model.
 
I would note that Pete indicated that there are = User use cases (rather than just Job Originator use cases) that have not be= en covered and may be added, but that is a Cloud problem.=
 
Aside from things that have already been no= ted in yesterday=E2=80=99s call, I do not think that the divergence in how = the use cases are presented represents a problem. But perhaps some of the w= ording (such as the treatment of =E2=80=9CPrint and Select=E2=80=9D)= may be of interest when addressing similar issues in IPP Everywhere.<= /o:p>
Thanks,
Bill Wagner
 
Thanks,
 
 
 

-- 
This message= has been scanned for viruses and&nbs= p;
dangerous content by&nbs= p;MailScanner, and is 
believed to be clean. ______________= _________________________________
ipp mailing list
ipp@pwg.= org
https://www.pwg.org/mailman/list= info/ipp

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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_yLhb/t9TJAJ8ls19EmHOEg)-- --===============0699165236== 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 --===============0699165236==-- From ipp-bounces@pwg.org Thu Aug 23 21:13:17 2012 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 297A321E803A for ; Thu, 23 Aug 2012 21:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlNdtLUlqluG for ; Thu, 23 Aug 2012 21:13:15 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 26CDB21E8043 for ; Thu, 23 Aug 2012 21:13:15 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 35DC479279; Fri, 24 Aug 2012 00:12:52 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by pwg.org (Postfix) with ESMTP id 65B7179272 for ; Fri, 24 Aug 2012 00:12:27 -0400 (EDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id qU7L1j0060ldTLk55UCWPY; Fri, 24 Aug 2012 04:12:30 +0000 Received: from WagnerVistaPC ([98.216.178.129]) by omta04.westchester.pa.mail.comcast.net with comcast id qU7H1j00R2ntzM63QU7MRp; Fri, 24 Aug 2012 04:07:22 +0000 From: "William A Wagner" To: "'Michael Sweet'" References: <000001cd7fcb$0c8b0b20$25a12160$@net> <11A48EC3-B464-48C0-AAEE-3423A821EDEB@apple.com> In-Reply-To: <11A48EC3-B464-48C0-AAEE-3423A821EDEB@apple.com> Subject: RE: [IPP] Minutes from today's conference call Date: Fri, 24 Aug 2012 00:07:23 -0400 Message-ID: <002101cd81ad$f6f09660$e4d1c320$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2Bn4hKnjctEJVzQfOGCjieDNWXGwADhR5w Content-Language: en-us X-pwg-MailScanner: Found to be clean, Found to be clean Cc: ipp@pwg.org X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0969128348==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 35DC479279.AA3F8 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============0969128348== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CD818C.6FDEF660" Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_0022_01CD818C.6FDEF660 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike, Your are most welcome to use whatever seems appropriate in the Last call co= mments. It does appear the quorum has been reached already, and I think we = are ll looking forward to getting IPP Everywhere passed and in the field. Thanks, Bill Wagner =20 From: Michael Sweet [mailto:msweet@apple.com]=20 Sent: Thursday, August 23, 2012 10:19 PM To: William A Wagner Cc: ipp@pwg.org Subject: Re: [IPP] Minutes from today's conference call =20 BIll, =20 I checked the process document and non-voting members do indeed count towar= ds quorum for last call. See section 8.1 (bold/italic text highlights the = important bits): =20 8.1 Last Call =20 Last Call represents a final opportunity for issues to be raised against a = document. During this period all PWG members are encouraged to review the f= inal working draft for both technical and editorial content and to provide = comments to the Working Group. The Working Group Chair announces a Last Cal= l on a document with rough consensus of the Working Group. Last Calls are p= osted to all members of the PWG via the PWG-ANNOUNCE mailing list. The Last= Call period may vary, based upon the content, complexity, holidays, or oth= er circumstances, but must be at least 16 full working days (minimum 22 cal= endar days). A working day is a normal business day and is considered to en= d at 10 PM USPST (Los Angeles, CA, USA). For any document transitioning to = Candidate Standard or Standard, Last Call must either conclude at, or span = a PWG Plenary meeting with an overview of the draft or standards document a= nd a review of any current detailed issues and their resolutions. If less t= han 30 percent of the PWG membership have commented, participated, or commu= nicated that they have no comments for a given document during Last Call, t= he Last Call period is automatically extended until that threshold is met. = Within a reasonable period of time following closure of Last Call, all issu= es raised during Last Call must be either resolved or rejected as follows: =20 =E2=80=A2 =E2=8E=AF Resolved - Document updated to reflect the resolution =20=20=20 =E2=80=A2 =E2=8E=AF Rejected - No change required in the document =20 All issues and their resolution from the most recent Last Call must be publ= ished in the Formal Approval announcement. =20 According to section 2.1, a non-voting member is still a member and can par= ticipate in everything except voting and serving as an officer of the PWG, = so if it is OK with you I'd like to include these items in the last call co= mments for IPP Everywhere. =20 Thanks! =20 =20 On Aug 21, 2012, at 2:30 PM, William A Wagner wrote: As requested, I am outlining some of the differences between the IPP Everyw= here Use Cases and the revised Cloud Use Cases. First, since the general p= osition has been that, as a nonvoting member, my comments do not count towa= rd the quorum, I make these observations on IPP Everywhere vs. Cloud =E2=80= =9CUse Cases=E2=80=9D as comments on the conference call rather than last c= all comments on the document. Second, I am noting the divergence of the two= use cases from the same original set not as critical comments on the IPP E= verywhere Use Cases, but to indicate the legitimate differences in how one= looks at these cases. I can think of no reason why the two sets of use cas= es must be the same in style, form or specifics, provided that they are re= alistic and useful in developing requirements. Further, I believe it is val= id to conclude that a requirement evolving from a Use Case need not be add= ressed in thesolutions, provided that a reason for the omission is given. H= owever, in that there were some issues that came up in addressing the IPP E= verywhere use cases that had also been addressed in the Cloud Use Cases, I = offer this summary. =20 With that preface, I would note that the original Use Cases included both c= oncise statements of cases where a specific feature would be used (which I = would call Use Cases), and narratives giving a more or less plausible situ= ation (perhaps better called scenarios). The IPP Everywhere spec gives spec= ific use cases under =E2=80=9CSelect Printer=E2=80=9D , but reverts to mor= e of a scenario approach for the =E2=80=9CPrint=E2=80=9D section. I see no = problem with this approach although I admit a bias toward stating scenario= s, with the requirements developed from the scenarios breaking out the deta= ils (e.g., specific criteria used for selection). =20 One line of thinking in the Cloud discussion was that requirements were to = be developed to address use cases (or scenarios) and the design was to be = developed to satisfy the requirements. Therefore, it seemed inappropriate t= o describe the Use Cases in terms of the elements of the model design. So t= he Cloud scenarios were rephrased in terms of the basic elements=E2=80=A6th= e User (or more specifically, the potential Job Originator), the physical p= rinter and the stuff in between (primarily the Cloud , the big black box in= the sky). I do not suggest this as a comment on the IPP Everywhere specif= ication, just as the thoughts that are reflected in the Cloud Rationale se= ction. =20 With regard to specific changes in the Cloud vs IPP Everywhere versions of = what was initially the same use case: =20 1. If Common Preconditions in Cloud were important, it was felt that = they should be itemized and presented as a distinct section. Once they were= made more obvious, they were variously considered to be wrongly stated, ob= vious, or more appropriately stated in the requirements section. We are no= t sure what we will do with them. 2. Objections to the Common Preconditions also stemmed from the confu= sion of the term =E2=80=9CVisible=E2=80=9D. Even in IPP Everywhere, it is s= ort of contradictory to say =E2=80=9Cthe Printer must be Visible to the Cli= ent in order to be selected, either directly or through an intermediate Ser= vice=E2=80=9D when =E2=80=9CVisible=E2=80=9D is defined as the ability to c= ommunicate directly. The other confusion developed from the definition=E2= =80=99s referring to the =E2=80=9Cability=E2=80=9D to communicate, suggesti= ng that at some time under some conditions the connection could exist whil= e the normal sense of the word suggests that the connection does exist. 3. Print a Document =E2=80=93 no significant difference. Original st= atement specifying some relationship of user to printer was considered conf= using and was removed. Comments on validating were considered perhaps part = of requirements or solution. 4. Print by Reference. =E2=80=93 same comments as Print a Document 5. Print a Photo/Print Using Loaded Media. =E2=80=93 Titles diverged= some time ago. Preconditions were considered more requirements. 6. Check printing =E2=80=93 Cloud sought to clarify that this did not= involve sending a =E2=80=9Cform template=E2=80=9D to the printer. Also, to= include an obvious Cloud scenario, the application is Cloud Based (not nec= essary for IPP Everywhere). I suggest that, in the IPP Everywhere text, Cl= ient sends the =E2=80=9Cdocument data containing the checks=E2=80=9D might= be confusing, since check usually refers to the printed media. 7. Print with Special Formatting was dropped from Cloud as not repres= enting a sufficiently distinct set of requirements. 8. The original Prescription print case in Cloud was changed to a pho= toprint involving selection on the basis of geographic location and print t= o someone other than the job originator. The prescription case seemed too l= oaded with HIPAA problems. 9. Print and Select was changed to avoid reference to =E2=80=98Follow= Me=C2=AE=E2=80=9D (a registered trademark of Ringdale) 10. Print to a Service =E2=80=93 aside from some minor clarification, no = change. 11. Job Cancel=E2=80=A6that is canceling a job request after it has been = submitted and accepted was taken as a use case rather than an exception. Th= is may be more appropriate for Cloud since the Cloud model does require int= ermediaries between the job originator and the printer. 12. Exceptions: Main change was identifying the exception but not the act= ions to be taken, under the premise that the way the system reacts is to be= indicated under Requirements and how it does this is to be in the Model. =20 I would note that Pete indicated that there are User use cases (rather than= just Job Originator use cases) that have not been covered and may be added= , but that is a Cloud problem. =20 Aside from things that have already been noted in yesterday=E2=80=99s call,= I do not think that the divergence in how the use cases are presented repr= esents a problem. But perhaps some of the wording (such as the treatment of= =E2=80=9CPrint and Select=E2=80=9D) may be of interest when addressing sim= ilar issues in IPP Everywhere. Thanks, Bill Wagner =20 Thanks, =20 =20 =20 --=20 This message has been scanned for viruses and=20 dangerous content by MailScanner, and is=20 believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/lis= tinfo/ipp =20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair =20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_0022_01CD818C.6FDEF660 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Mike,

Your are most welcome to use = whatever seems appropriate in the Last call comments. It does appear the qu= orum has been reached already, and I think we are ll looking forward to get= ting IPP Everywhere passed and in the field.

Thanks,

Bill Wagner

 <= /o:p>

From: Michael Sweet [mai= lto:msweet@apple.com]
Sent: Thursday, August 23, 2012 10:19 PMTo: William A Wagner
Cc: ipp@pwg.org
Subject: = Re: [IPP] Minutes from today's conference call

<= /div>

 

BIll,

 

I checked the process document and non-voting members do i= ndeed count towards quorum for last call.  See section 8.1 (bold/itali= c text highlights the important bits):

 

8.1 Last Call

 

Last= Call represents a final opportunity for issues to be raised against a docu= ment. During this period all PWG members are encouraged to = review the final working draft for both technical and editorial content and= to provide comments to the Working Group. The Working Gr= oup Chair announces a Last Call on a document with rough consensus of = the Working Group. Last Calls are posted to all members of the PWG via= the PWG-ANNOUNCE mailing list. The Last Call period may vary, based u= pon the content, complexity, holidays, or other circumstances, bu= t must be at least 16 full working days (minimum 22 calendar days). A = working day is a normal business day and is considered to end at 10 PM= USPST (Los Angeles, CA, USA). For any document transitioning to Candi= date Standard or Standard, Last Call must either conclude at, or span = a PWG Plenary meeting with an overview of the draft or standards = document and a review of any current detailed issues and their resolutions.= If less than 30 percent of the PWG membership have comment= ed, participated, or communicated that they have no comments for a given&nb= sp;document during Last Call, the Last Call period is automatically extende= d until that threshold is met. Within a reasonable period = ;of time following closure of Last Call, all issues raised during Last Call= must be either resolved or rejected as follows:

=

 

=E2= =80=A2 =E2=8E=AF  Resolved - Document updated to reflect the resolution

=C2=A0=C2=A0

=E2=80=A2 =E2=8E=AF  Rejected - No chang= e required in the document

 

<= span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>All issues = and their resolution from the most recent Last Call must be published in th= e Formal Approval announcement.

 

According to section 2.1, a non-voting member is still a member an= d can participate in everything except voting and serving as an officer of = the PWG, so if it is OK with you I'd like to include these items in th= e last call comments for IPP Everywhere.

 

Thanks!

 

 

On Aug 21, 2012, at 2:30 PM, William A Wagner <wamwagner@comcast.net> wrote:



As requested, I am outlining some of the differences between the = IPP Everywhere Use Cases and the revised Cloud Use Cases.  First, sinc= e the general position has been that, as a nonvoting member, my comments do= not count toward the quorum, I make these observations on IPP Everywhere v= s. Cloud =E2=80=9CUse Cases=E2=80=9D as comments on the conference call rat= her than last call comments on the document. Second, I am noting the diverg= ence of the two use cases from the same original set not as critical commen= ts on the IPP Everywhere Use Cases, but to indicate the  legitimate di= fferences in how one looks at these cases. I can think of no reason why the= two sets of use cases must be the same in style,  form or specifics, = provided that they are realistic and useful in developing requirements. Fur= ther, I believe it is valid to conclude that a requirement  evolving f= rom a Use Case need not be addressed in thesolutions, provided that a reaso= n for the omission is given. However, in that there were some issues that c= ame up in addressing the IPP Everywhere use cases that had also been addres= sed in the Cloud Use Cases, I offer this summary.

 

<= p class=3DMsoNormal>With that preface, I would note that the origina= l Use Cases included both concise statements of cases where a specific feat= ure would be used (which I would call Use Cases), and narratives giving a&n= bsp; more or less plausible situation (perhaps better called scenarios). Th= e IPP Everywhere spec gives specific use cases under  =E2=80=9CSelect = Printer=E2=80=9D , but reverts to more of a scenario approach for the =E2= =80=9CPrint=E2=80=9D section. I see no problem with this approach although = I  admit a bias toward stating scenarios, with the requirements develo= ped from the scenarios breaking out the details (e.g., specific criteria us= ed for selection).

 

One = line of thinking in the Cloud discussion was that requirements were to be d= eveloped to address use cases (or scenarios)  and the design was to be= developed to satisfy the requirements. Therefore, it seemed inappropriate = to describe the Use Cases in terms of the elements of the model design. So = the Cloud scenarios were rephrased in terms of the basic elements=E2=80=A6t= he User (or more specifically, the potential Job Originator), the physical = printer and the stuff in between (primarily the Cloud , the big black box i= n the sky).  I do not suggest this as a comment on the IPP Everywhere = specification, just as the thoughts that are reflected in the Cloud  R= ationale section.

 

With= regard to specific changes in the Cloud vs IPP Everywhere versions of what= was initially the same use case:

 

1.    &nb= sp;  If = Common Preconditions in Cloud were important, it was felt that they should = be itemized and presented as a distinct section. Once they were made more o= bvious, they were variously considered to be wrongly stated, obvious, or mo= re appropriately stated  in the requirements section. We are not sure = what we will do with them.

2.    &nb= sp;  Obj= ections to the Common Preconditions also stemmed from the confusion of the = term =E2=80=9CVisible=E2=80=9D. Even in IPP Everywhere, it is sort of contr= adictory to say =E2=80=9Cthe Printer must be Visible to the Client i= n order to be selected, either directly or through an intermediate Service= =E2=80=9D when =E2=80=9CVisible=E2=80=9D is defined as the ability to commu= nicate directly. The other confusion developed from the definition=E2=80=99= s referring to the =E2=80=9Cability=E2=80=9D to communicate, suggesting tha= t at some time under some conditions the connection could exist  while= the normal sense of the word suggests that the connection does exist.=

3.        Print a Document =E2=80=93 no significant= difference. Original statement specifying some relationship of user to pri= nter was considered confusing and was removed. Comments on validating were = considered perhaps part of requirements or solution.

4. &n= bsp;     Print by Reference. =E2=80=93 same comments as Print a Document

5.       Print  a Photo/Print Using Loaded Media. = =E2=80=93 Titles diverged some time ago. Preconditions were considered more= requirements.

6.       Check printing =E2=80=93 Clou= d sought to clarify that this did not involve sending a =E2=80=9Cform templ= ate=E2=80=9D to the printer. Also, to include an obvious Cloud scenario, th= e application is Cloud Based (not necessary for IPP Everywhere).  I su= ggest that, in the IPP Everywhere text, Client sends the  =E2=80=9Cdoc= ument data containing the checks=E2=80=9D might be confusing, since check u= sually refers to the printed media.

7.    =    Print w= ith Special Formatting was dropped from Cloud as not representing a suffici= ently distinct set of requirements.

8.    =    The ori= ginal Prescription print case in Cloud was changed to a photoprint involvin= g selection on the basis of geographic location and print to someone other = than the job originator. The prescription case seemed too loaded with HIPAA= problems.

9.       Print and Select was changed to a= void reference to =E2=80=98FollowMe=C2=AE=E2=80=9D (a registered trademark = of Ringdale)

10.   Print to a Service =E2=80=93 aside from some minor c= larification, no change.

11.   Job Cancel=E2=80=A6that is canceling a job= request after it has been submitted and accepted was taken as a use case r= ather than an exception. This may be more appropriate for Cloud since the C= loud model does require intermediaries between the job originator and the p= rinter.

12.  &nbs= p;Exceptions: Main change was identifying the exceptio= n but not the actions to be taken, under the premise that the way the syste= m reacts is to be indicated under Requirements and how it does this is to b= e in the Model.

 

I would= note that Pete indicated that there are User use cases (rather than just J= ob Originator use cases) that have not been covered and may be added, but t= hat is a Cloud problem.

 

Aside from things that have already been noted in yesterday=E2=80=99s call= , I do not think that the divergence in how the use cases are presented rep= resents a problem. But perhaps some of the wording (such as the treatment o= f =E2=80=9CPrint and Select=E2=80=9D) may be of interest when addres= sing similar issues in IPP Everywhere.

Thanks,

Bill Wagner=

 

Thanks,

=

 

 

 


-= - 
This message has been= scanned for viruses and dangerous content by MailSc= anner, and is 
believed to be clean. _______________________________________________=
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listi= nfo/ipp

 

_____________________= ____________________________________
Michael Sweet, Senior Printing Syst= em Engineer, PWG Chair

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_0022_01CD818C.6FDEF660-- --===============0969128348== 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 --===============0969128348==-- From ipp-bounces@pwg.org Fri Aug 24 17:19:58 2012 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 E297621F85AC for ; Fri, 24 Aug 2012 17:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-1.746, BAYES_05=-1.11, HTML_MESSAGE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE1hzbHFwV5D for ; Fri, 24 Aug 2012 17:19:57 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id B512121F85A8 for ; Fri, 24 Aug 2012 17:19:57 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id AB24679277; Fri, 24 Aug 2012 20:19:42 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by pwg.org (Postfix) with ESMTP id 8EFBB7926D for ; Fri, 24 Aug 2012 20:19:29 -0400 (EDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7P0JQ8h028577 for ; Fri, 24 Aug 2012 20:19:26 -0400 Authentication-Results: cm-omr10 smtp.user=ptykodi@tykodi.com; auth=pass (LOGIN) X-Authenticated-UID: ptykodi@tykodi.com Received: from [24.34.47.110] ([24.34.47.110:56428] helo=TCS2010LAPTOP) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B7/22-26049-E0A18305; Fri, 24 Aug 2012 20:19:26 -0400 From: "Paul Tykodi" To: , , , "Ira McDonald" Date: Fri, 24 Aug 2012 20:19:26 -0400 Organization: Tykodi Consulting Services LLC Message-ID: <029901cd8257$4970d770$dc528650$@tykodi.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2CV0jpWmXOeEpPSHORxniZHW12mQ== Content-Language: en-us X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Tykodi Consulting Services LLC has reviewed the IPP Everywhere specification and has no comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ptykodi@tykodi.com List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0209150156==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: AB24679277.AA793 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multipart message in MIME format. --===============0209150156== Content-Type: multipart/related; boundary="----=_NextPart_000_029A_01CD8235.C25F3770" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_029A_01CD8235.C25F3770 Content-Type: multipart/alternative; boundary="----=_NextPart_001_029B_01CD8235.C25F3770" ------=_NextPart_001_029B_01CD8235.C25F3770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Description: Description: header Paul Tykodi Principal Consultant Tykodi Consulting Svcs LLC Phone: (603) 343-1820 3 Lowell Ave Cell: (603) 866-0712 Dover, NH 03820 Fax: (603) 343-1820 USA E-mail: ptykodi@tykodi.com www.tykodi.com Skype: Tykodiconsultingservices Co-Chair - IEEE-ISTO PWG IPP Working Group Vice-Chair - IEEE-ISTO PWG Semantic Model Working Group This e-mail message and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify Tykodi Consulting Services LLC immediately by replying to this message and destroying all copies of this message and any attachments. Thank you -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_001_029B_01CD8235.C25F3770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

3D"Description:

Paul Tykodi
Principal Consultant

Tyk= odi Consulting Svcs LLC

= Phone:<= /o:p>

(6= 03) 343-1820

3 Lowell Ave

Cell:

(603) 866-0712

Dover, NH 03820

Fax:

(603) 343-1820

USA

E-mail:

ptykodi@tykodi.com

www.tykodi.co= m

Skyp= e:

= Tykodiconsultingservices

 

Co-Chair    &n= bsp;          - IEEE-ISTO PWG = IPP Working Group

Vice-Chair  &nb= sp;          - IEEE-ISTO PWG S= emantic Model Working Group

=  

This e-mail message and any attachments are conf= idential and may be privileged.

<= span style=3D'font-size:8.0pt;font-family:"Arial","sans-serif"'>If you are = not the intended recipient, please notify Tykodi Consulting Services LLC

immediately by replying to this message and = destroying all copies of this message

and = any attachments. Thank you

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_001_029B_01CD8235.C25F3770-- ------=_NextPart_000_029A_01CD8235.C25F3770 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4O Dx4WFxIZJCAmJSMgIyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/ 2wBDAQsLCw8NDx0QEB09KSMpPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABSAIEDASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiuR8R+EdQ1vVmuoNUN vFsCrGCwxjr0PrUzbSulc2oU4VJWnLlXfc66ivLta8H6houlTX02su6xAfKH cFiTjHX3qHw94V1PxBppvE1SWFN5QBnc5x361j7aV+Xl1O9ZfRdP2vtly3te z3PV6K88Pw91KMb5ddYRr8zEs4wB170t/wCLNS1u+Gl+GEZY1G3zv4iB3yfu j361aqP7SsebjZUMMlyz5m+iR6A0iJ99lX6nFCurjKsCPY5rg4/hxc3S+ZqW sSNKeSFBYfmTVa88DazpANxo+oyTFOdqko/4DODVc0uxwPEVlq6enrqej1DJ JIikiNSB6viuBv8Ax/deHvBltcXyibVblnSFHXbgKcbmHt+uax9P8EeJvGcK aj4g1ma1imG6OEZJ2nkfKCAorVUHUhzOXKv68mddOalFStuejzazJCT/AKKX A/uSA/yqmfGFrG22e3mQjrjBIri7j4LzRKX0/XpRKOgkjKj8wc07wl4c8RWv iVtN8Rb59OEDOHY71Y5AG1+oPtR9XsrxqX9UdMJ0ftx+5ndweK9InIX7YkTH tL8v6nitZHWRA0bKynoVOQa4TXfh5JIDJpc5YDkwSnr9G/xrnLO71Tw9dGON 5raRD80T/dP4dKahdbnY8HQqQ5qM9ezPYKK5rw94vh1VltrpRBdHpz8r/T0P tXS1LTWjPNnBwdmFFFFIkKKKKAOI+KF75Wj21qDzNLuP0Uf/AF63/Cdl9g8M WMJGGMYdvq3P9a4rxyzar41stOQ52BI/xY5P6Yr0tEEaKijCqMAegrnp+9Ul L5HqYn93g6VPveX+Rx3xI1hrPS4rCFir3RJcj+4O34mtPwboiaPoURKj7RcK JJW789B+Arj/AB83n+MraFj8gjjXB92Oa9PAAAAGAK0jrJs+co/vMROb+zoh aKKK0O88Y+M8E8fiSwuWTNu1vtQnpuDEkfqK9C0Hx3oOsWcJjv4YJioDQTME ZT6c9fwrY1XSLHW7FrTUrdJ4G52t2PqD2NcFqPwV0ydmbT9QuLbPRJFEij+R rqU6c4KM9LAekJIkq7o2VlPdTkU6vCNY8M+Jvh2EvrTUWNruC+ZA52qT0DIe Oa9V8DeJH8U+Gor6ZFS4VzFKF6FhjkfUEVFSjyx5ou6A6KsvXNCt9btDHKAs yj93KByp/wAK1KZJIkMbSSMFRRlmPQCsU7bDjJxd0eOSwyWty8UmVlicqcdi DXp3hfVH1XRY5ZTmaMmNz6kd/wAsV5zq12l9q11coMJJIWX6dq7zwTZva6CH kBBncyAH04A/lXVWj7l2VUqc8rHRUUUVyEBRUN1cC1tpJmAO0ZALBcn0yeKz P7Xubq3fytMuCrArvjmiOPx3UAcV4e/4nXxKuLw/NHG8kgPsPlX+lenVx/hz Rl8PyzT2mn38rTqAWlliIx14wa6D+0ZgQHsZEJ5w0if4+4rCkuSPvbndj68K 1Rez+FJJHE/EvTJY7221SJSYyojdh/CwOR/Oup8O+KLPW7GMmZI7tVAkiZgD n1HqKu3NxHLCYb61Ajl+TZK6Yb25PNcvffDmwnkL2v2m3z/ACrKPpnmpdVRl pf7n/keJKhVp1XUpWae6vY7C4v7W1iMlxcwxIOrO4Armbz4gWazTrYJ9ojt4 JJ5ZT8q4Vc4Hrk4FZsXw5gVwbh72YDsuxc/mTW3baJptlazWceh70lTbKHdG Z1PY5OcVrGbbV9jWMcTOSulFeqbIvDvxE0PX4EzcpaXRHzQTsFIPsTwa6U3U AXcZo9vrvGK801L4XaVeEyWNjqNtnkLHNG6fhuP9azU+ErdHOolP7o8of+zG u1woy1UrHb7KXl96/wAzR+KPi+wvtLGg6XIt5dTyrv8AJ+YLg5ABHViccCut 8A6BJ4c8KW9pcDFw5M0w/us3b8AAK5vQPDJ0Q+doeiW8twPl+1XF0srL9MYC 1qT6T4r1Pi6u44UP8KPgf+O0SlHl5IvQPZW3a+86DU/EWnaUpE86tIOkafMx /wAPxrhdb8T3etnyEUxW5PES8lvr6/Stqz8ARMd13fF8HkRDv9TXR6doOn6X g2tuof8Avt8zfmamMqcNd2RKy2OS8PeDZbiRLnVEMcI5WE/ef6+grvVUKoVQ ABwAO1JvX5vmHy9eelNkuIYVVpZY0DHClmAyfas51HN3ZCViSiiioGVNUt5L rS7mCFUaSRCqh+mTWPd6ZetNNZ6e7Q2i2qoOSoMnzAY9sEE+uAK6OigDmn0n VxYw2yTHequpkScoFfgI+B/CAPufzos9I1FrxLi6JV8oJGM5fcAzM2BjADHa MDsK6WigDEu7G8bUrqVLaCdZolSJ5G/1OM5+Uj1OeKqppGqSWzJJPLGGy+37 UxYMI9o+Yc4LHdgcDArpaKAOZNhrcWoJOjNLEhXKNcld+Fxx2wTycjNMn0PU ZIkd282fcm5hOyH5YyM5HP32Jx7CupooA5u507UbaNriO6kDRqygCRiNojCr 8gHUtls44zU2n2tzLoN2JoZyblm2QS3DblQgDG48joT+Nb1FAHKf2RrQEapI EiGSFjcI4II27yoAbgY6d6vRaTqEM1qBeStEY/8ASi0zFi4IPy56Z6duK3aK AOYGma0tvcjzCbhgWilFwQoBOSu3pnkjcfaptM03U4NSikuJZWt1VtyyTlsE 5IwB9cc56CuhooA5+ay1J7TV4Vt033Tkxyed1U4AHTjgGpBaXZvzPLp8Msbw rGqNKD5OCcjpznI6elblFAGV9o1T/oFwf+BP/wBjRWrRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//2Q== ------=_NextPart_000_029A_01CD8235.C25F3770-- --===============0209150156== 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 --===============0209150156==-- From ipp-bounces@pwg.org Thu Aug 30 08:58:38 2012 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 F193C21F853B for ; Thu, 30 Aug 2012 08:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.598 X-Spam-Level: X-Spam-Status: No, score=-101.598 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqQlsVZuDJ1y for ; Thu, 30 Aug 2012 08:58:38 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3167B21F8535 for ; Thu, 30 Aug 2012 08:58:38 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D23E2791E1; Thu, 30 Aug 2012 11:58:23 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id A3A90791E1 for ; Thu, 30 Aug 2012 11:58:10 -0400 (EDT) MIME-version: 1.0 Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M9K00CCQSBPV2X0@mail-out.apple.com> for ipp@pwg.org; Thu, 30 Aug 2012 08:58:03 -0700 (PDT) X-AuditID: 1180711d-b7fd66d0000072b3-7f-503f8d898cf5 Received: from [17.151.70.146] (Unknown_Domain [17.151.70.146]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 8B.9D.29363.A8D8F305; Thu, 30 Aug 2012 08:58:02 -0700 (PDT) From: Michael Sweet Date: Thu, 30 Aug 2012 11:58:00 -0400 To: "ipp@pwg.org" Message-id: X-Mailer: Apple Mail (2.1486) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUiON1tkm53r32AwVZNi2P7XrJYHPkW68Dk sfXkDzaPeYunMwUwRXHZpKTmZJalFunbJXBlPHkmXLCXr+L6kzWsDYzveboYOTkkBEwkuqc3 sUPYYhIX7q1n62Lk4hASmMokcbqzlRkkwSagJvF7Uh8riM0skCDxbdcuMJtFQFViz/dpTCC2 sICSxMKTG8DqRQTkJda2TQWL8wrYSMw4ugBoAQeQrSdxem8CxC5Zif339zFOYOSehWTqLIQq iLC2xLKFr5lBwswCOhKTFzJChOUltr+dwwxT8vH8EaYFjGyrGAWLUnMSKw2N9RILCnJS9ZLz czcxgkKqoVB2B+P+n/yHGAU4GJV4eL3C7AKEWBPLiitzDzFKcDArifD+6rYPEOJNSaysSi3K jy8qzUktPsQozcGiJM57fBpQtUB6YklqdmpqQWoRTJaJg1OqgVE1b4pQ5lNzid/2y+O1/RT7 pobHdnye8H+zR57Byt37l1h9sA+/ptaZlvrVJcMldbNyT0u/HF/awRd3C490Xneyk2Fc/Mtx 6WPrfRwfZtR/+Bq9bo78kW88wccF99vwpWyf1HL0gvicn+59/ufthCfciVeP+hzxrfTAaoMH i3ckvXzs2OT3vUOJpTgj0VCLuag4EQAzc73BJQIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Noticed a typo in JPS3... X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0427081250==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: D23E2791E1.A7878 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0427081250== Content-type: multipart/alternative; boundary="Boundary_(ID_W3PnEYqLpUmiGR+plyt4+Q)" --Boundary_(ID_W3PnEYqLpUmiGR+plyt4+Q) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, When we figure out how we want to address errata, the following typo in JPS3 somehow sneaked through the process: 6.10 Create-Job, Print-Job, and Print-URI Operations: "ipp-attribute- fidelity", "job-mandatory-elements", and "media-col" "job-mandatory-elements" should be "printer-mandatory-job-attributes" in this section. I must have been reading the SM schema too much when I wrote this... :/ __________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_W3PnEYqLpUmiGR+plyt4+Q) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

When we figure out how we want to address errata, the following typo in JPS3 somehow sneaked through the process:

    6.10 Create-Job, Print-Job, and Print-URI Operations: "ipp-attribute- fidelity", "job-mandatory-elements", and "media-col"

"job-mandatory-elements" should be "printer-mandatory-job-attributes" in this section. I must have been reading the SM schema too much when I wrote this... :/

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_W3PnEYqLpUmiGR+plyt4+Q)-- --===============0427081250== 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 --===============0427081250==-- From pwg-announce-bounces@pwg.org Thu Aug 30 11:22:33 2012 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 4393B21F85AA for ; Thu, 30 Aug 2012 11:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYnw1DKPrXeN for ; Thu, 30 Aug 2012 11:22:32 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 57BA321F85A2 for ; Thu, 30 Aug 2012 11:22:31 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 54B49791ED; Thu, 30 Aug 2012 14:22:16 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id 14D40791E9 for ; Thu, 30 Aug 2012 14:21:59 -0400 (EDT) MIME-version: 1.0 Received: from relay16.apple.com ([17.128.113.55]) 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 <0M9K00CDMYZ7V2A1@mail-out.apple.com> for pwg-announce@pwg.org; Thu, 30 Aug 2012 11:21:59 -0700 (PDT) X-AuditID: 11807137-b7f176d0000023ed-07-503faf45e8e8 Received: from [17.151.70.146] (Unknown_Domain [17.151.70.146]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 8A.78.09197.64FAF305; Thu, 30 Aug 2012 11:21:59 -0700 (PDT) From: Michael Sweet Date: Thu, 30 Aug 2012 14:21:57 -0400 To: pwg-announce@pwg.org Message-id: X-Mailer: Apple Mail (2.1486) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUiON1tkq77evsAg6P/hSyOfIu1WNe6mtmB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgyujonsRWcIOvovPbJKYGxh88XYycHBICJhLz 7h5khbDFJC7cW8/WxcjFISQwlUli8eofbCAJNgE1id+T+sCKmAUSJPq6bjCD2CwCqhJTp2wA s4UFNCUOLOhjB7FFBCQkpnXPA6vnFbCR+NP4BWgOB5CtJ3F6bwLELlmJ/ff3MU5g5J6FZOos hCqIsLbEsoWvwcLMAjoSkxcyQoTlJba/ncMMU/Lx/BGmBYxsqxgFi1JzEisNzfQSCwpyUvWS 83M3MYLCqqHQfAfj9r9yhxgFOBiVeHgvrLMPEGJNLCuuzD3EKMHBrCTC+6sbKMSbklhZlVqU H19UmpNafIhRmoNFSZxXEBjKQgLpiSWp2ampBalFMFkmDk6pBsa5U9xvn495N+1d02G9uUIO P5rlT0x9NSG2azebc8ijCXtbXbzOMojnaFQEJHx7FeS7n6na0nfe5RuXl13UtRXf8/qmn+TW TMEra3IFOKdvkavImTK7qn1u05I1h/f0Tn+ccdrp4QTZx3vDb8/ekXM0fZHDHYnyAzoZs/4/ kz8gfCW7Nivuj80kJZbijERDLeai4kQAl4UVZScCAAA= X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [Pwg-Announce] IPP USB specification needs YOU! X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749758713==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 54B49791ED.AC868 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============1749758713== Content-type: multipart/alternative; boundary="Boundary_(ID_w+GMtWlbV04d9JBQHerSVg)" --Boundary_(ID_w+GMtWlbV04d9JBQHerSVg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, The IPP USB specification under development in the USB Implementers Forum (USB-IF) is nearing completion. Currently only two printer manufacturers are represented in the working group, so all members of the WG are seeking additional participation and review by other printer manufacturers to ensure its success. If you have not done so already, please consider joining the IPP USB working group. Thank you! __________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_w+GMtWlbV04d9JBQHerSVg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

The IPP USB specification under development in the USB Implementers Forum (USB-IF) is nearing completion.  Currently only two printer manufacturers are represented in the working group, so all members of the WG are seeking additional participation and review by other printer manufacturers to ensure its success.

If you have not done so already, please consider joining the IPP USB working group.

Thank you!

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_w+GMtWlbV04d9JBQHerSVg)-- --===============1749758713== 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 --===============1749758713==--

On = Aug 21, 2012, at 11:13 AM, "Petrie, Glen" <glen.petrie@eitc.epson.com> wrote:
Mike (all)
 
The change below = pushes the burden to the printer (at an increased cost to the printer) whil= e the Client, a software entity, has less burden.  What is wrong with<= o:p>
 
1. Discovery:
 
   = a. Clients MUST support DNS-SD and WS-Discovery
   = b. Printers MUST support either DNS-SD or WS-Discovery and RECOMMENED to su= pport both.

Pret= ty much all printers already support DNS-SD and WS-Discovery, which is why = we opted to put the "burden" on the printers (since they already carry that= burden).

2. Document Formats:
 
a.     = ;  Clients MUST suppor= t both JPEG and PWG Raster
b.      Printers MUST support either JPEG or= PWG Raster and RECOMMENDED to support both.

I personally would rather just see a single format (P= WG Raster) be required since it is the only simple raster format that works= for text, graphics, and photos.  However, Justin objected to PWG Rast= er because Microsoft currently does not support it.  Thus the "great c= ompromise".

Many printers already support JPEG via= dedicated hardware, and PWG Raster uses the same compression algorithm tha= t is used by most vendor PDLs, so again I am not sure we are really increas= ing the burden for printers and the printer requirement to support both has= been in the spec for over a year now...

This change to the printer requirements could mean= a faster time to market since printers are already support one of the disc= overies and documents formats but may not support both discoveries and docu= ment formats.

I = would argue that document formats and discovery protocols are not the hard = parts - doing a GOOD implementation of IPP is much more difficult, as the i= nteroperability reports can attest.

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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --Boundary_(ID_IapSHSyXQIRe1PMauaDYUg)-- --===============1326708825== 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 --===============1326708825==-- From ipp-bounces@pwg.org Tue Aug 21 10:06:47 2012 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 0BDEC21F86A1 for ; Tue, 21 Aug 2012 10:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrLp9Qcplioz for ; Tue, 21 Aug 2012 10:06:46 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id D9B6C21F8681 for ; Tue, 21 Aug 2012 10:06:45 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BBDA87922D; Tue, 21 Aug 2012 13:06:26 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from EEAEX01.us.epson.net (eeaex01.eea.epson.com [12.9.144.164]) by pwg.org (Postfix) with ESMTP id 822F77922A for ; Tue, 21 Aug 2012 13:06:12 -0400 (EDT) Received: from EEAEX02.us.epson.net ([148.130.64.7]) by EEAEX01.us.epson.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Aug 2012 10:06:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Aug 2012 10:06:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Epson has reviewed the IPP Everywhere specification and has the following additional comments. Thread-Index: Ac1/v0JwbJPSL9yMSsu/oYoVrBC9NQ== From: "Petrie, Glen" To: , "Ira McDonald" , , X-OriginalArrivalTime: 21 Aug 2012 17:06:12.0752 (UTC) FILETIME=[44739900:01CD7FBF] X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Epson has reviewed the IPP Everywhere specification and has the following additional comments. X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0306951424==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: BBDA87922D.AB1C4 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============0306951424== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD7FBF.44002172" This is a multi-part message in MIME format. ------_=_NextPart_001_01CD7FBF.44002172 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PDF redline document at: ftp://ftp.pwg.org/pub/pwg/ipp/general/wd-ippeve10-20120724-glen-petrie-c omments.pdf=20 =20 The changes in the redline document are "recommended" in most case; thus, should be decided by the author. =20 Some items where discussed/clarified in the August 20, 2012 phone meeting. =20 Glen =20 --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01CD7FBF.44002172 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PDF redline document at:  ftp://ftp.pwg.org/pub/pwg/ipp/general/wd-ippeve10-2012072= 4-glen-petrie-comments.pdf

 

The changes in the redline document are "recommended" in most case; t= hus, should be decided by the author.

 

Some items where discussed/clarified in the August 20, 2012 phone meeting.<= /o:p>

 

Glen

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------_=_NextPart_001_01CD7FBF.44002172-- --===============0306951424== 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 --===============0306951424==-- From ipp-bounces@pwg.org Tue Aug 21 11:31:16 2012 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 D1FB621F86EA for ; Tue, 21 Aug 2012 11:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.736 X-Spam-Level: X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_83=0.6, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaXF46p7RAf9 for ; Tue, 21 Aug 2012 11:31:13 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id C152421F86D0 for ; Tue, 21 Aug 2012 11:31:12 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 34C3179240; Tue, 21 Aug 2012 14:30:54 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by pwg.org (Postfix) with ESMTP id 341187923B for ; Tue, 21 Aug 2012 14:30:38 -0400 (EDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta10.westchester.pa.mail.comcast.net with comcast id pWNW1j0020Fqzac5AWWhpr; Tue, 21 Aug 2012 18:30:41 +0000 Received: from WagnerVistaPC ([98.216.178.129]) by omta08.westchester.pa.mail.comcast.net with comcast id pWWX1j00L2ntzM63UWWbno; Tue, 21 Aug 2012 18:30:35 +0000 From: "William A Wagner" To: References: In-Reply-To: Date: Tue, 21 Aug 2012 14:30:32 -0400 Message-ID: <000001cd7fcb$0c8b0b20$25a12160$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1/PCKqZ3GYB6zuQx6jpha7zbLbJQAGMavQ Content-Language: en-us X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Minutes from today's conference call X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074555806==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 34C3179240.A9EC1 X-pwg-MailScanner-From: ipp-bounces@pwg.org This is a multi-part message in MIME format. --===============2074555806== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CD7FA9.85796B20" Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CD7FA9.85796B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As requested, I am outlining some of the differences between the IPP Everywhere Use Cases and the revised Cloud Use Cases. First, since the general position has been that, as a nonvoting member, my comments do not count toward the quorum, I make these observations on IPP Everywhere vs. Cloud "Use Cases" as comments on the conference call rather than last call comments on the document. Second, I am noting the divergence of the two use cases from the same original set not as critical comments on the IPP Everywhere Use Cases, but to indicate the legitimate differences in how one looks at these cases. I can think of no reason why the two sets of use cases must be the same in style, form or specifics, provided that they are realistic and useful in developing requirements. Further, I believe it is valid to conclude that a requirement evolving from a Use Case need not be addressed in thesolutions, provided that a reason for the omission is given. However, in that there were some issues that came up in addressing the IPP Everywhere use cases that had also been addressed in the Cloud Use Cases, I offer this summary. With that preface, I would note that the original Use Cases included both concise statements of cases where a specific feature would be used (which I would call Use Cases), and narratives giving a more or less plausible situation (perhaps better called scenarios). The IPP Everywhere spec gives specific use cases under "Select Printer" , but reverts to more of a scenario approach for the "Print" section. I see no problem with this approach although I admit a bias toward stating scenarios, with the requirements developed from the scenarios breaking out the details (e.g., specific criteria used for selection). One line of thinking in the Cloud discussion was that requirements were to be developed to address use cases (or scenarios) and the design was to be developed to satisfy the requirements. Therefore, it seemed inappropriate to describe the Use Cases in terms of the elements of the model design. So the Cloud scenarios were rephrased in terms of the basic elements.the User (or more specifically, the potential Job Originator), the physical printer and the stuff in between (primarily the Cloud , the big black box in the sky). I do not suggest this as a comment on the IPP Everywhere specification, just as the thoughts that are reflected in the Cloud Rationale section. With regard to specific changes in the Cloud vs IPP Everywhere versions of what was initially the same use case: 1. If Common Preconditions in Cloud were important, it was felt that they should be itemized and presented as a distinct section. Once they were made more obvious, they were variously considered to be wrongly stated, obvious, or more appropriately stated in the requirements section. We are not sure what we will do with them. 2. Objections to the Common Preconditions also stemmed from the confusion of the term "Visible". Even in IPP Everywhere, it is sort of contradictory to say "the Printer must be Visible to the Client in order to be selected, either directly or through an intermediate Service" when "Visible" is defined as the ability to communicate directly. The other confusion developed from the definition's referring to the "ability" to communicate, suggesting that at some time under some conditions the connection could exist while the normal sense of the word suggests that the connection does exist. 3. Print a Document - no significant difference. Original statement specifying some relationship of user to printer was considered confusing and was removed. Comments on validating were considered perhaps part of requirements or solution. 4. Print by Reference. - same comments as Print a Document 5. Print a Photo/Print Using Loaded Media. - Titles diverged some time ago. Preconditions were considered more requirements. 6. Check printing - Cloud sought to clarify that this did not involve sending a "form template" to the printer. Also, to include an obvious Cloud scenario, the application is Cloud Based (not necessary for IPP Everywhere). I suggest that, in the IPP Everywhere text, Client sends the "document data containing the checks" might be confusing, since check usually refers to the printed media. 7. Print with Special Formatting was dropped from Cloud as not representing a sufficiently distinct set of requirements. 8. The original Prescription print case in Cloud was changed to a photoprint involving selection on the basis of geographic location and print to someone other than the job originator. The prescription case seemed too loaded with HIPAA problems. 9. Print and Select was changed to avoid reference to 'FollowMeR" (a registered trademark of Ringdale) 10. Print to a Service - aside from some minor clarification, no change. 11. Job Cancel.that is canceling a job request after it has been submitted and accepted was taken as a use case rather than an exception. This may be more appropriate for Cloud since the Cloud model does require intermediaries between the job originator and the printer. 12. Exceptions: Main change was identifying the exception but not the actions to be taken, under the premise that the way the system reacts is to be indicated under Requirements and how it does this is to be in the Model. I would note that Pete indicated that there are User use cases (rather than just Job Originator use cases) that have not been covered and may be added, but that is a Cloud problem. Aside from things that have already been noted in yesterday's call, I do not think that the divergence in how the use cases are presented represents a problem. But perhaps some of the wording (such as the treatment of "Print and Select") may be of interest when addressing similar issues in IPP Everywhere. Thanks, Bill Wagner Thanks, -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------=_NextPart_000_0001_01CD7FA9.85796B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As reques= ted, I am outlining some of the differences between the IPP Everywhere Use = Cases and the revised Cloud Use Cases.  First, since the general posit= ion has been that, as a nonvoting member, my comments do not count toward t= he quorum, I make these observations on IPP Everywhere vs. Cloud “Use= Cases” as comments on the conference call rather than last call comm= ents on the document. Second, I am noting the divergence of the two use cas= es from the same original set not as critical comments on the IPP Everywher= e Use Cases, but to indicate the  legitimate differences in how one lo= oks at these cases. I can think of no reason why the two sets of use cases = must be the same in style,  form or specifics, provided that they are = realistic and useful in developing requirements. Further, I believe it is v= alid to conclude that a requirement  evolving from a Use Case need not= be addressed in thesolutions, provided that a reason for the omission is g= iven. However, in that there were some issues that came up in addressing th= e IPP Everywhere use cases that had also been addressed in the Cloud Use Ca= ses, I offer this summary.

 

With that preface,= I would note that the original Use Cases included both concise statements = of cases where a specific feature would be used (which I would call Use Cas= es), and narratives giving a  more or less plausible situation (perhap= s better called scenarios). The IPP Everywhere spec gives specific use case= s under  “Select Printer” , but reverts to more of a scena= rio approach for the “Print” section. I see no problem with thi= s approach although I  admit a bias toward stating scenarios, with the= requirements developed from the scenarios breaking out the details (e.g., = specific criteria used for selection).

 

One = line of thinking in the Cloud discussion was that requirements were to be d= eveloped to address use cases (or scenarios)  and the design was to be= developed to satisfy the requirements. Therefore, it seemed inappropriate = to describe the Use Cases in terms of the elements of the model design. So = the Cloud scenarios were rephrased in terms of the basic elements…the= User (or more specifically, the potential Job Originator), the physical pr= inter and the stuff in between (primarily the Cloud , the big black box in = the sky).  I do not suggest this as a comment on the IPP Everywhere sp= ecification, just as the thoughts that are reflected in the Cloud  Rat= ionale section.

&nbs= p;

With regard to specific chan= ges in the Cloud vs IPP Everywhere versions of what was initially the same = use case:

 

1.    &= nbsp;  If Common Preconditions i= n Cloud were important, it was felt that they should be itemized and presen= ted as a distinct section. Once they were made more obvious, they were vari= ously considered to be wrongly stated, obvious, or more appropriately state= d  in the requirements section. We are not sure what we will do with t= hem.

2. &nbs= p;     Objections= to the Common Preconditions also stemmed from the confusion of the term &#= 8220;Visible”. Even in IPP Everywhere, it is sort of contradictory to= say “the Printer must be Visible to the Client in order to be= selected, either directly or through an intermediate Service” when &= #8220;Visible” is defined as the ability to communicate directly. The= other confusion developed from the definition’s referring to the = 220;ability” to communicate, suggesting that at some time under some = conditions the connection could exist  while the normal sense of the w= ord suggests that the connection does exist.

3.        Print a Document – no significant = difference. Original statement specifying some relationship of user to prin= ter was considered confusing and was removed. Comments on validating were c= onsidered perhaps part of requirements or solution.

4.     &n= bsp; Print by Reference. – same commen= ts as Print a Document

5.       Print  a Photo/Print Using Loaded Media. – Titles diverge= d some time ago. Preconditions were considered more requirements.

6.   =     Check printing – Cl= oud sought to clarify that this did not involve sending a “form templ= ate” to the printer. Also, to include an obvious Cloud scenario, the = application is Cloud Based (not necessary for IPP Everywhere).  I sugg= est that, in the IPP Everywhere text, Client sends the  “documen= t data containing the checks” might be confusing, since check usually= refers to the printed media.

7.       Print with Special Formatting was dropped from Cloud as not r= epresenting a sufficiently distinct set of requirements.<= /span>

8.    &nb= sp;  The original Prescription print ca= se in Cloud was changed to a photoprint involving selection on the basis of= geographic location and print to someone other than the job originator. Th= e prescription case seemed too loaded with HIPAA problems.

9.    &= nbsp;  Print and Select was changed to = avoid reference to ‘FollowMe®” (a registered trademark of R= ingdale)

10.   Print to a Service – asi= de from some minor clarification, no change.

11.   Job Cancel…that is canceling a job request after it has been su= bmitted and accepted was taken as a use case rather than an exception. This= may be more appropriate for Cloud since the Cloud model does require inter= mediaries between the job originator and the printer.

12= .   Exceptions: Main change was identifying the exception= but not the actions to be taken, under the premise that the way the system= reacts is to be indicated under Requirements and how it does this is to be= in the Model.

 =

I would note that Pete indicat= ed that there are User use cases (rather than just Job Originator use cases= ) that have not been covered and may be added, but that is a Cloud problem.=

 <= /p>

Aside from things that have already been not= ed in yesterday’s call, I do not think that the divergence in how the= use cases are presented represents a problem. But perhaps some of the word= ing (such as the treatment of “Print and Select”) may be= of interest when addressing similar issues in IPP Everywhere.

Thanks,

Bill Wagn= er

 

Thanks,

 

 

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ------=_NextPart_000_0001_01CD7FA9.85796B20-- --===============2074555806== 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 --===============2074555806==-- From ipp-bounces@pwg.org Wed Aug 22 18:05:00 2012 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 DB8A721F8512 for ; Wed, 22 Aug 2012 18:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YxrPBHGZw-X for ; Wed, 22 Aug 2012 18:05:00 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 355EE21F84F5 for ; Wed, 22 Aug 2012 18:05:00 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7912A79218; Wed, 22 Aug 2012 21:04:45 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from cusa.canon.com (mailgrd8.cusa.canon.com [146.184.6.82]) by pwg.org (Postfix) with ESMTP id 3EC8979213 for ; Wed, 22 Aug 2012 21:04:33 -0400 (EDT) Received: from ([146.184.20.22]) by mailgrd8.cusa.canon.com with ESMTP with TLS id HQK2RF1.44269503; Wed, 22 Aug 2012 21:04:25 -0400 Received: from RDEXCHMAIL01.sc.rd.canon.com ([fe80::15a8:cc66:e35:f508]) by RDEXCHMAIL02.sc.rd.canon.com ([169.254.1.186]) with mapi id 14.01.0289.001; Wed, 22 Aug 2012 18:04:25 -0700 From: "Yardumian, Rick" To: "ipp@pwg.org" , "blueroofmusic@gmail.com" , "ptykodi@tykodi.com" , "msweet@apple.com" Thread-Topic: Canon has reviewed the IPP Everywhere specification and has no comments Thread-Index: Ac2AyzwqAJSfNhoZQlWJPJpsrkaBJQ== Date: Thu, 23 Aug 2012 01:04:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.184.26.53] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] Canon has reviewed the IPP Everywhere specification and has no comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1624140045==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 7912A79218.A9A61 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1624140045== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_B09B928B11A36543865AFB7D94C2393DBC79174FRDEXCHMAIL01scr_" --_000_B09B928B11A36543865AFB7D94C2393DBC79174FRDEXCHMAIL01scr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_B09B928B11A36543865AFB7D94C2393DBC79174FRDEXCHMAIL01scr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_B09B928B11A36543865AFB7D94C2393DBC79174FRDEXCHMAIL01scr_-- --===============1624140045== 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 --===============1624140045==-- From ipp-bounces@pwg.org Wed Aug 22 18:27:11 2012 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 23A1921F8514 for ; Wed, 22 Aug 2012 18:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2A+t+m5Ulrh for ; Wed, 22 Aug 2012 18:27:08 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 891A621F853E for ; Wed, 22 Aug 2012 18:27:08 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 978F07921E; Wed, 22 Aug 2012 21:26:46 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-lpp01m010-f46.google.com (mail-lpp01m010-f46.google.com [209.85.215.46]) by pwg.org (Postfix) with ESMTP id A300B792C5 for ; Wed, 22 Aug 2012 21:23:53 -0400 (EDT) Received: by lagy9 with SMTP id y9so127292lag.5 for ; Wed, 22 Aug 2012 18:23:52 -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:cc:content-type; bh=xhmzcTXFxn1mBGUaLaVD+8JcKXxAnAdqpaKvj5yxLJY=; b=SI0ceJrtHeZPPowgRlJvy1t3Nb8NmQ9nVgHOd1ndGXmYTk2dZ0Ai27JSWYgjZQo/se HMA4Qh+aBP/PspL62HmtUU1lCaLNQ51PkqVDMeCcXV6mI+kfbftG73+ysackPFn2t70A Cqh+EZeXOcqOAiq2j6iTE8msHvgLelx+ulcJM3mDCwlWGjBCkhFHl9JFBGwDkz9hOagS BTG+jKyP2vX11cRlbwMuV0eIKwCi7id5mR1/EvB/9W2zJhmzTZW3SOvFEG40DLVu83j1 flSw0yWG65R4lPpky5C8jIIT2iTe6NsSgZoX8dnUVQKWtxgTQsfKcrKZt//jgdLlmtCJ grNw== MIME-Version: 1.0 Received: by 10.112.25.100 with SMTP id b4mr72653lbg.55.1345685032535; Wed, 22 Aug 2012 18:23:52 -0700 (PDT) Received: by 10.112.128.233 with HTTP; Wed, 22 Aug 2012 18:23:52 -0700 (PDT) Date: Wed, 22 Aug 2012 21:23:52 -0400 Message-ID: From: Ira McDonald To: ipp@pwg.org, Ira McDonald X-pwg-MailScanner: Found to be clean, Found to be clean Cc: Subject: [IPP] High North has reviewed the IPP Everywhere specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1969799579==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 978F07921E.A8EB0 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1969799579== Content-Type: multipart/alternative; boundary=bcaec552428a58074004c7e4b687 --bcaec552428a58074004c7e4b687 Content-Type: text/plain; charset=ISO-8859-1 Hi, Throughout this specification, the non-standard term "Visible Xxx" (never used in IETF, ITU-T, or IEEE 802.x series standards) should be replaced with explicit and precise words, probably usually just "network accessible host" (the standard IETF term). 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 Temporary Cabin *** 2012 only *** 906-494-2523 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --bcaec552428a58074004c7e4b687 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Throughout this specification, the non-standard term "Visib= le Xxx"
(never used in IETF, ITU-T, or IEEE 802.x series standards)= should
be replaced with explicit and precise words, probably usually j= ust
"network accessible host" (the standard IETF term).

Cheers= ,
- Ira

Ira McDonald (Musician / Software Architect= )
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Pri= nter Working 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
Temporary Cabin= *** 2012 only *** 906-494-2523
2012/8/20 Randy Turner <= ;rturner@ama= lfisystems.com>

=C2=A0i think I understa= nd the compromise, although I would have worded 1b and 2b a little differen= t

Clients MUST support either DNS-SD or WS-Discovery=E2= =80=A6.

It's just a different use of a contraction

"=E2=80=A6one of DNS-SD AND WS-Discovery" =C2=A0= seemed to use an AND contraction which implied both - someone might inadver= tently parse this in a way we didn't expect=E2=80=A6.although I got the= gist of the compromise.

R.

On Au= g 20, 2012, at 9:16 PM, William A Wagner wrote:

I think this is a practical and reasonable c= ompromise. From at least my perspective, this does not put an unreasonable = additional burden on printers while=C2=A0 making potentially easier for cli= ents to achieve and claim compliance.
Bill Wagner
=C2=A0
From:= =C2=A0ipp-bounces@pwg.org=C2=A0[mailto:ipp-bounc= es@pwg.org]=C2=A0On Behalf Of=C2=A0Mic= hael Sweet
Sent:=C2=A0Monday, August 20, 2012 9:42 PM
To:=C2=A0ipp@pwg.org
Subject:= =C2=A0[IPP] IPP Everywhere and "The Great Compromise"= ;
=C2=A0
All,
=C2=A0
We discussed the PWG Last Call comments received thus far at today's IP= P WG conference call. =C2=A0Two of the comments concerned the client requir= ements to support DNS-SD for discovery and both PWG Raster and JPEG for doc= ument formats. =C2=A0After over an hour of spirited debate, the following &= quot;great compromise" was proposed to resolve the last call comments:=
=C2=A0
1. Discovery:
=C2=A0
=C2=A0 =C2=A0a. Printers MUST support both DNS-SD and WS-Discovery (adds WS= -Discovery)
=C2=A0 =C2=A0b. Clients MUST support at least one of DNS-SD and WS-Discover= y (Clients can choose amongst the two required protocols)
=C2=A0
2. Document Formats:
= =C2=A0
=C2=A0 =C2=A0a. Printers MUST support both JPEG and PWG Raster (no change)<= u>
=C2=A0 =C2=A0b. Clients MUST support at least one of JPEG and PWG Raster (r= elaxes conformance - previously a Client had to support both)=
=C2=A0
Please comment on the proposed changes.<= /u>
=C2=A0
__= _______________________________________________________
Michael Sweet, S= enior Printing System=C2=A0Engineer, PWG Chair
=C2=A0

--=C2=A0
This message has been scanned for viruses and<= span>=C2=A0
dangerous content by=C2=A0MailScanner, and is=C2=A0
believed to be clean.

--=C2=A0This message has been scanned for viruses and=C2=A0
danger= ous content by=C2=A0MailScan= ner, and is=C2=A0
believed to be clean.=C2=A0_______________________= ________________________
ipp mailing list
ipp@pw= g.org
https://www.pwg.org/mailman/list= info/ipp